受控中文技术写作（ASD-STE100 中文化）

ASD-STE100 是航空业为了「维修工不可能读错」而做的受控英语：一个词只有一个意思，一句话只有一种结构。 本技能把同一条纪律搬到中文，读者换成没有追问机会的另一方：另一个 agent、翻译管线、非母语读者、 半年后的你自己。

中文的歧义来源和英语不同。英语主要栽在「一个词多个意思」和「一句话多种结构」上；中文主要栽在四件事： 虚动词（进行 / 加以 / 作出 + 名词）、套话（需要注意的是、在一定程度上）、同义轮换 （用户 / 客户 / 使用者 混用）、一句串三件事（用分号、破折号、「并且 / 同时 / 从而」串起来）。 所以下面的规则按中文重写，不是把英文规则逐条翻译过来。

规则分两类，本技能只能把其中一类做到「可核对」：

• 结构规则：讲句子形状，读完描述就能执行，可以放心硬性套用。
• 词汇规则：需要一个受控词表才算标准。中文没有（也不该有）官方词表，所以词汇规则降级成 「方向」——挑最普通、最常见的说法，并在输出里说明这是方向而不是合规声明。

什么时候用

• 一段中文说明、报错、日志、工具描述读起来含混、术语堆砌、或者绕。
• 文本要交给另一个 agent、翻译管线、非母语读者解析，读错有代价。
• 你在写 prompt、system message、工具描述，想在模型看到之前先消掉歧义。
• 你想要前后对照，看清违反了哪条规则、改完为什么更好。要就说 —— 默认输出只有改写后的正文。

不用在：创意文案、营销文案、文学、需要语气与节奏的地方。受控中文是故意平淡、字面化的。

两档模式

改写前先选档。用户没说就按文本类型推断，并在输出里用一句话说明选了哪档。

Strict（严格） —— 程序步骤、报错信息、工具与函数描述、agent 间指令、安全相关文本。 凡是读错有代价的地方，全部规则执行，包括硬性句长上限和「一词一义」。

中文-顺（STE-flavored） —— README、PR 描述、变更日志、解释性文章。结构规则全执行， 词汇规则只作为方向：句长上限、主动语态、简单体貌、不用分号、去名词化、去营销形容词都保留， 但不锁死用词 —— 说明文需要一点弹性，全锁死读起来像换了个作者，而不是变清楚了。

两档和「结构 / 词汇」这条分界线是同一件事的两个方向：分界线说的是哪些规则不依赖词表也能核对， 两档说的是对某类文本该执行到哪一步。

结构规则（执行）

词汇规则（方向）

体貌（中文的「时态」）

中文没有时态，但体标记会泄漏信息：已经……了、正在……中、……过。受控写作默认用最简表述 （「任务已结束」写成「任务结束」），但有当前相关性时必须保留：

• 「任务已完成，结果可以直接读」≠「任务完成过」。前者是状态，后者是历史。
• 「请求可能已失败」里的「可能」是作者给出的置信度，是内容，不是修饰。

凡复合体貌承载了简单体貌给不出的信息（当前相关、或情态），保留它，并在输出里标注这处偏离。 其余地方按规则简化。

扫描清单

下面六种是中文机器味的绝大多数来源。每一种都是机械的：你能指出具体的词或标点，不需要审美判断。 改写之前先把六条都扫一遍。

1. 同义轮换 —— 同一件事在一篇里换了好几个名字（用户 / 客户 / 使用者）。读者分不清是一个东西还是三个。 改法：定一个名字，全篇用它。
2. 套话堆叠 —— 需要注意的是、值得一提的是、在一定程度上、某种意义上、不难看出。删掉，或直接说事。
3. 名词化 —— 动作被冻成名词（进行 / 作出 / 加以 / 予以 + 名词）。改法：用动词（「进行分析」→「分析」）。
4. 营销形容词 —— 宣称质量而不给出证据：无缝、强大、赋能、闭环、极致、丝滑、一站式、颠覆、领先。 改法：删掉，或换成撑得起这句话的测量值。
5. 长句串联 —— 用分号、破折号、「并且 / 同时 / 从而 / 进而」把好几件事串成一句。改法：一句一件事。
6. 翻译腔 —— 「基于……的情况下」「对于……而言」「这是一个……的事实」「不仅……而且……而且」。 改法：说清主语和动作，其余删掉。

流程

1. 选档（Strict / 中文-顺）。只有用户要规则表时才说明选了哪档，见「输出格式」。
2. 通读一遍原文，先弄清它改完之后还必须说什么。没读懂不要动笔。
3. 逐句走。对照「结构规则」「词汇规则」两张表与「扫描清单」标出每一处违规。中文-顺档中标出词汇规则 但不强制。机械首查可以跑 scripts/ste-lint-zh.py（stdin 或文件参数，--json 出结构化结果）： 它查分号串联、超长句、名词化、营销形容词、套话、同义轮换、被动语态、复合体貌、含糊词、半角标点。 --baseline N 容忍 N 处硬违规（用于存量文档接入）；--disable 规则名,规则名 关掉指定规则。
4. 重写每一处违规句，原意一个字不能变。如果改短会丢掉必要的精度（安全条件、范围限定、数字）， 保留长的写法并在输出里标注，而不是悄悄简化。
   • 动笔前先看情态。 「可能 / 也许 / 有时 / 倾向于」承载作者的置信度，置信度是内容。 改短却把「可能」升成事实，那不是简化，是换了一个结论。这是受控改写最常见的翻车方式， 因为句长上限最容易引诱人删掉的正是这些词。
   • 不要添加原文没有的事实。改写之后读起来更顺，是因为它补了一个原因、频率或机制 —— 那已经不是改写。
5. 按「输出格式」给出改写后的正文。档位选择与规则分析留在内部，除非用户要看。
6. 原文本来就合规，就直说合规，不要硬改。

输出格式

默认：只给改写后的正文。 多数调用方要的是能直接粘进工具描述、报错串或 prompt 的结果。 把改写后的文本单独打印。不要加技能介绍、档位声明、违规计数、变更摘要、规则表，也不要结尾再问一句 「需要我解释吗」。

唯一允许的附加：第 4 步故意保留了较长的写法时，在正文后加一行，前缀 保留原样：， 写明保留的短语和会丢掉的精度。没有这种情况就不加。

用户要求时：规则表。 当用户说「给我看 diff」「违反了哪些规则」「解释一下改了什么」「前后对照」， 输出这张表：

| 违反的规则 | 原文 | 改写后 |
|---|---|---|
| 名词化 | 「对日志进行分析」 | 「分析日志」 |
| 分号串联 | 「先开票；再发货」 | 「先开票。再发货。」 |

档位：Strict。共 7 处违规。

表后加一行说明故意没有改的地方和原因（通常是：改短会丢精度）。

边界

会做：

• 把含糊、啰嗦的中文改写成短句、单义、主动语态的句子。
• 默认只给改写后的正文；用户要求时列出用到的规则。
• 保留原文的每一个事实、条件、范围限定。
• 保留每一处情态的强度，不添加原文没有的断言。
• 给必须保留的术语提一行术语表写法。

不会做：

• 声称符合某个官方中文受控词表 —— 中文没有这样的标准，本技能只提供规则与方向。
• 改写创意、营销、说服性文案 —— 那里的语气和留白才是重点。
• 为了短而悄悄删掉安全条件、例外、范围限定 —— 会标注这个取舍。
• 把「可能已失败」改成「失败」，把「可能是 X 导致的」改成「X 是原因」 —— 丢情态就是换结论。
• 保证「合规文档」。这是受控写作思路的通用清晰化工具，不是认证工具。
• 把空内容变有用。受控写作修的是形式，不是内容。一段空话改完会变成一段干净、简短、 标点正确的空话。文本本身没东西可说，就直说，不要粉饰。
• 为了短牺牲可读性。删字不是目的，消歧才是。压到某个程度之后，省下的时间会被读者重新花回去 —— 句子没有歧义就停手，不要追求最短。

附加资源

• references/writing-rules.md —— 规则全集：结构规则、词汇规则、中文特有的坑、与上游 ASD-STE100 九节 53 条的对应关系，附引用。
• examples/before-after.md —— 前后对照例子：工具描述、报错信息、agent 间指令、状态汇报、 PR 描述、README。
• scripts/ste-lint-zh.py —— 仅用标准库的确定性 linter。硬违规超过 --baseline（默认 0）时退出码 1； 建议类发现（被动语态、复合体貌、含糊词、半角标点）永不导致失败；--disable 关闭指定规则。 它永远不挑情态（可能 / 也许 / 大概）：那是内容不是风格，--selftest 里有「请求可能已失败」必须干净的断言。