accelint-english-manager

English Manager

使用平实、直接的英语，做到易于阅读、易于浏览、易于执行。

不要只追求简短。在让文本更清晰、更稳定、更难被误读的同时，保留用户的意图、受众、语气和明确约束。

本技能使用一套默认写作体系：

• 平实语言原则，用于直接、具体的措辞
• 偏向 STE 的结构，用于技术清晰度和稳定的术语
• 对 ADHD 友好的塑形，当文本帮助某人完成某事时，提升可浏览性和可执行性

将它们结合使用。它们不是彼此独立的模式。

硬性约束

这些约束优先于风格偏好。

• 在优化措辞之前，先保留用户的含义。
• 保留所要求的语气、对受众的适配以及明确的格式约束。
• 当用户需要时，保留刻意营造的温暖感、节奏、幽默、说服力或品牌声音。
• 保留代码、标识符、命令、文件路径、引用的错误信息、产品名称、API 名称、配置键和法律文本，除非用户明确要求改写它们。
• 保留真实的不确定性、真实的细微差别和真实的义务程度。不要为了让文本听起来更简单而让它变得不那么真实。
• 不要声称符合官方 ASD-STE100 标准。如果用户要求严格的 STE，请说明完全合规取决于官方标准及其词典。

从这里开始

在编辑之前，先选择最小且合适的路径。

第 1 步：先询问模式

对于起草或改写任务，先做这一步，除非用户已经明确指定了模式。

提供以下选项：

• mode=default — 默认进行局部改写，平实而直接
• mode=strict — 更严格的技术控制，必要时允许结构性改写

如果用户没有选择模式，请提出一个简短的澄清问题，而不要自行假设。 完成条件：改写模式已明确，或者该请求明显仅用于审查。

第 2 步：选择输出模式

前提：当请求需要改写模式时，第 1 步已完成。

在编辑之前选择一种输出模式：

• 仅审查 — 审查文本，除非用户要求，否则不改写。
• 仅改写 — 直接返回更整洁的最终文本。
• 审查加改写 — 先给出发现的问题，再给出改写版本。

如果用户只要求改写，就只返回改写版本。除非用户要求，否则不要返回审查说明。 完成条件：输出模式已明确。

第 3 步：保留约束

前提：第 2 步已完成。 在改写或重构任何内容之前，先做这一步。

首先提取并保护以下内容：

• 含义
• 受众
• 语气
• 格式
• 必须保留的准确措辞
• 必须保持原样的引用文本或技术文本

如果某条风格规则与用户的明确约束冲突，以该约束为准。 完成条件：受保护的约束已确定。

第 4 步：通过模式选择范围

前提：第 3 步已完成。

让模式设定默认的改写范围。

• mode=default — 默认进行局部改写。只对给定文本做收紧或澄清。保留源文本结构，除非用户明确要求更完整的成果，或者当前结构掩盖了关键含义。
• mode=strict — 当更强的控制有助于文本发挥其作用时，允许结构性改写。当当前结构掩盖了顺序、逻辑、安全、需求或操作清晰度时，重新组织、拆分或重新标注内容。

不要把 mode=strict 当作随意扩大任务范围的许可。在两种模式下，除非用户明确要求更大范围的改写，否则都保留能解决真正问题的最小改动。 完成条件：允许的改写范围已明确。

默认写作方法

除非任务明显需要更严格的分层处理，否则使用此方法。

1. 尽早说明要点

先讲要点、结果或下一步操作。

• 在说明性文字中，把主要事实放在前面。
• 在操作性文字中，把下一步操作放在前面。
• 在支持或错误帮助中，说明发生了什么、已知原因（如有）以及接下来该做什么。

如果不要引言反而更好，就不要添加引言。

2. 使用直接、具体的措辞

写出你能写出的最清晰、最准确的句子。

• 优先使用具体行动和结果，而不是抽象表述
• 在含义不变时，使用简短、熟悉的词
• 删除填充语、重复性铺垫和浮夸措辞
• 当行为主体重要时，明确指出行为主体
• 当主动语态能提高清晰度时，优先使用主动语态

如果更简单的词会降低准确性，就保留精确的词。

3. 一个概念只用一个术语

为每个重复出现的概念选定一个术语，并保持不变。

不要只是为了避免重复而轮换同义词。

4. 让文本易于扫读

默认使用对 ADHD 友好的轻度塑造方式：

• 让句子和段落保持有界
• 尽可能每句只保留一个主要行动或事实
• 只有当列表能让工作更易跟进时才使用列表
• 在次要问题变得重要之前，将其排除在主路径之外
• 当读者需要行动时，让下一步操作显而易见

不要强行把清单式结构套用到随意、创意或对语气敏感的文本上。

5. 让结构与任务相匹配

使用适合该写作的形态。

• 程序性或操作性写作：使用祈使式步骤、条件先于命令、每步一个操作、将警告写成明确指令
• 描述性写作：每句一个主要事实，将相关事实归为一组，不在说明段落中埋入指令
• 对语气敏感或说服性写作：保留清晰度收益，同时不要压平承担任务的语气

6. 保留必要的细微差别

直白地写，不要夸大确定性或力度。

• 当事实不确定、有条件、为估计或未完成时，保留真实的模糊限定
• 当虚假的模糊限定只会增加迷雾时，将其删除
• 准确保留要求强度、建议强度、许可和能力
• 只有当行为主体未知、无关、对语气敏感或被有意弱化时，才保留被动语态

模式控制

当这些写作模式有实质帮助时，使用它们。

模式	何时使用	应用
mode=default	大多数请求	默认采用平实语言纪律、稳定术语、可扫读结构、在有用时采用行动优先的塑造方式，以及局部改写
mode=strict	用户明确要求 STE、ASD-STE100 风格写作、非常严格的平实语言、高度受控的技术措辞，或对技术文本进行更严格的审查	默认模式 + 更强的 STE 结构、更强的情态纪律、更强的程序性/描述性分离、更严格的术语控制，以及在需要时为清晰度或控制力进行结构性改写

如果用户要求进行严格的 STE 风格审查：

1. 说明你可以进行偏向严格 STE 的审查。
2. 说明官方 ASD-STE100 合规性取决于官方标准和词典。
3. 只加载 references/ste-rules.md 中请求所需的相关部分。
4. 只引用你实际加载的 references/ste-rules.md 部分中的规则编号。
5. 如果你没有加载相关规则文本，就不要引用规则编号。

不要把这些操作合并成一句话。保持顺序明确。

如果用户要求“plain English”“simple English”“clean this up”或类似的泛化清理请求，而没有指定模式，则将其视为平实语言目标，而不是隐含的 mode=strict。

顺序检测与处理

当文本要求读者或 Agent 先做一件事再做另一件事时，把顺序视为行为。

检测并强化以下情况：

• 显式顺序指令 — 编号步骤、first/next/then/finally、before/after/until、requires、depends on、done when、return to
• 隐含的步骤顺序 — 一句话隐藏了多个动作，一个动作依赖另一个动作的输出，或某条警告暗示缺少前置门禁
• 技能文件中的顺序线索 — 先询问模式，交付前先选择输出模式，重写前先保留约束，引用规则参考前先加载它们，交付前先运行自检
• 一般行文中的顺序线索 — 流程、操作说明、支持步骤、入门引导文本、提示词，以及任何把准备、操作、验证和交付混在一起的段落

当顺序很重要时：

• 让顺序显式化
• 对于 2 到 3 个简短有序步骤，使用编号列表
• 对于 4 个及以上有序步骤，使用 ### Step 0 加检查清单，然后使用 ### Step N: Name
• 当某个步骤依赖更早的步骤时，添加 Requires:
• 当后续工作依赖某项成功检查时，添加 Done when:
• 当后续步骤必须等待某项检查通过时，添加具名的失败路径
• 当拆分 do X and then Y 能提高遵从度时，将其拆分为独立步骤
• 当把条件放在动作之前能让时序更清晰时，就这样做
• 仅当后续动作已经依赖更早的检查时，才把仅有强调作用的警告替换为可执行的门禁
• 绝不要把有序工作留在普通项目符号中

在重写或审计任何具有真实工作流顺序、门禁、分支或验证循环的文本之前，加载 references/serial-instruction-guidance.md。保持 SKILL.md 可操作。使用该参考获取更深入的检测逻辑、结构规则和边缘情况。

输出规则

仅审计

默认给出简洁的评审，除非用户要求更正式的形式。

使用以下形式：

1. 摘要 — 用 1 到 3 句话说明主要的清晰度、语气或可操作性方面的问题
2. 最高风险问题优先 — 尤其是含义偏移、歧义、隐藏动作、义务偏移或结构损坏
3. 针对性发现 — 仅在有帮助时给出源文本、风险和简短说明
4. 可选完整重写 — 仅在用户要求或该段落存在反复出现的问题时才包含

仅重写

当用户只要求重写时，只返回重写内容。

除非用户要求，否则不要在前面加审计说明或解释。

审计加重写

先给出发现，再给出重写。

参考加载映射

仅在参考确实有帮助时加载它们。

• references/serial-instruction-guidance.md — 有序指令、隐含顺序、门禁、分支、验证循环，以及何时应将段落变为显式步骤
• references/substitutions.md — 措辞清理、删除填充词、一致性检查、情态检查
• references/checklist.md — 最终验证检查或详细审计支持
• references/ste-rules.md — 技术、流程、指导或显式 STE 请求；也用于 mode=strict
• references/adhd-patterns.md — 当读者需要执行帮助、低摩擦的下一步，或超出默认的 ADHD 友好格式时，进行更强的行动导向塑造
• references/use-cases.md — 将核心方法适配到文档、提示词、支持回复、事件记录、UI 文案或对语气敏感的写作
• references/rfc-2119.md — 仅用于规范性或定义行为的文本，例如政策、要求、接口契约、治理或流程，其中非正式的严重性标签掩盖了真正的义务
• references/examples.md — 当请求有歧义，或文本把清晰度目标与对语气敏感的约束混在一起时，锚定模式

交付工作流

从零起草时

第 1 步：询问模式

除非用户已经指定了模式，否则先执行这一步。 完成条件：重写模式已明确，或该请求确实仅用于审计。

第 2 步：选择输出模式

要求：当请求需要重写模式时，第 1 步已完成。 在起草之前选择 Audit only、Rewrite only 或 Audit plus rewrite。 完成条件：输出模式已明确。

第 3 步：提取约束

要求：第 1 步和第 2 步已完成。 在起草之前，识别必须保持固定的含义、受众、语气、格式和确切措辞。 完成条件：受保护的约束已识别。

第 4 步：应用模式

要求：第 3 步已完成。 让 mode=default 或 mode=strict 设定默认范围。 完成条件：允许的重写范围已明确。

第 5 步：用直接的英文起草

要求：第 1 步至第 4 步已完成。 用平实、直接的英文写作，保留用户的预期含义、受众、语气和明确约束。 完成条件：草稿与原文发挥相同的作用。

第 6 步：保持重复术语稳定

要求：第 5 步已完成。 一个概念只用一个术语。不要为了风格而轮换同义词。 完成条件：重复出现的概念使用稳定的术语。

第 7 步：让操作路径易于浏览

要求：第 5 步和第 6 步已完成。 当读者必须采取行动时执行这一步。 如果文本包含有序操作，在明确顺序之前加载 references/serial-instruction-guidance.md。 完成条件：有序操作以有序操作的形式呈现。

第 8 步：在交付前运行自检

要求：第 1 步至第 7 步已完成。 第 8 步完成之前不要交付。 如果自检失败，返回到最早受影响的步骤。 完成条件：自检通过。

用于修订现有文本

第 0 步：跟踪进度

当重写工作流包含 4 个或更多实际操作时，在任何其他工作之前先执行这一步。 在工作状态或回复中创建一个简短的清单，并在每一步之后更新它。

• 第 1 步：询问模式
• 第 2 步：保留用户的含义和约束
• 第 3 步：应用模式
• 第 4 步：用最小的安全改动收紧措辞
• 第 5 步：删除填充词、过时表述和可避免的抽象
• 第 6 步：仅在单纯替换无法奏效时，拆分过载的句子或重构
• 第 7 步：重新检查代词、情态动词和不可改动项
• 第 8 步：在交付前运行自检

第 1 步：询问模式

除非用户已经指定了模式，否则先执行这一步。 完成条件：重写模式已明确，或该请求确实仅用于审计。

第 2 步：保留用户的含义和约束

要求：第 1 步已完成。 在任何重写之前执行这一步。 完成条件：含义、受众、语气、格式和不可改动项已识别。

第 3 步：应用模式

要求：第 1 步和第 2 步已完成。 让 mode=default 或 mode=strict 设定默认范围。 完成条件：允许的重写范围已明确。

第 4 步：用最小的安全改动收紧措辞

要求：第 1 步至第 3 步已完成。 执行一次安全的重写，保留原文的作用、含义、语气、受众和明确约束。 完成条件：在不改变作用的前提下，草稿更加清晰。

第 5 步：删除填充词、过时表述和可避免的抽象

要求：第 4 步已完成。 删除只增加迷雾而不增加含义的措辞。 完成条件：剩余的措辞要么承载含义，要么承载控制。

第 6 步：仅在单纯替换无法奏效时，拆分过载的句子或重构

要求：第 4 步和第 5 步已完成。 如果原文隐藏了顺序、门控或分支逻辑，在明确重写顺序之前加载 references/serial-instruction-guidance.md。 如果顺序检查失败，返回到第 4 步。 完成条件：该工作流不会被读成无序的建议。

第 7 步：重新检查代词、情态动词和不可改动项

要求：第 4 步至第 6 步已完成。 完成条件：指代对象清晰，且义务强度仍与原文一致。

第 8 步：交付前运行自检

要求：第 1 至 7 步已完成。 第 8 步完成前，不得交付。 如果自检失败，回到受影响的、最早的步骤。 完成条件：自检通过。

用于检查文本，而不是重写文本

第 1 步：先识别最高风险的问题

把含义漂移、歧义、隐藏操作、义务漂移和顺序薄弱放在最前面。 完成条件：最高风险的问题已排序。

第 2 步：让审查与请求相匹配

要求：第 1 步已完成。 完成条件：审查深度与请求相匹配。

第 3 步：仅当用户要求或文本影响重大时，才使用更严格、基于规则的审查格式

要求：第 1 和第 2 步已完成。 完成条件：审查形式与风险和请求相匹配。

第 4 步：在引用之前加载正确的参考文件

要求：第 3 步已完成。 如果用户要求进行 STE 检查，只加载你所需的 references/ste-rules.md 中的相关部分。不要杜撰规则编号。 如果文本包含有序操作或薄弱的顺序线索，在判断顺序是否足够清晰之前，先加载 references/serial-instruction-guidance.md。 完成条件：每一条被引用的规则都来自已加载的参考文件。

第 5 步：交付前运行自检

要求：第 1 至 4 步已完成。 第 5 步完成前，不得交付。 完成条件：自检通过。

冲突解决

当规则相互冲突时，使用以下优先级顺序：

1. 用户含义、受众、语气和明确约束
2. 不可改动项和必须精确的措辞
3. 清晰性和可执行性
4. 技术写作规范
5. 简洁

具体处理方式：

• 当文本依赖关系语气、说服力、节奏或品牌契合度时，保留温度或声音
• 把类似 STE 的规范用作清晰性工具，而不是创意写作或混合写作的形式覆盖
• 去除虚假的模糊措辞，但保留真实的不确定性
• 默认使用主动语态，但当分寸、不确定性或刻意强调很重要时，保留被动语态

交付前必须进行的自检

交付前，请确认：

1. 重写后的文本仍然为同一受众完成同样的任务。
2. 关键术语保持稳定。
3. 义务、许可、能力和不确定性没有漂移。
4. 不可改动项保持精确。
5. 任何明确或隐含的有序指令仍然作为有序指令可见。
6. 任何必需的关卡、依赖或验证步骤仍然清晰地阻断后续步骤。
7. 最终答案与请求的输出模式一致。
8. 最终答案与请求的重写模式一致。
9. 任何剩余的定性措辞仍然具有明确的执行作用，且不作为隐藏关卡。

如需更深入的机械式检查，请加载 references/checklist.md。

限制

本技能提升清晰性和执行就绪度。它不能替代主题准确性、法律审查、品牌审查或官方 ASD-STE100 认证。

它也是一种写作技能，不是事实核查或政策制定技能。改进行文，但不要杜撰新的要求、承诺或产品行为。

当你应用本技能时，请以严谨的英文为目标进行优化：保持精确、真实、易于浏览、易于执行。