ASD-STE100 Skill 使用说明与原理
1 ASD-STE100 Skill 使用说明与原理
仓库：https://github.com/danyuchn/asd-ste100-skill ｜ SKILL 版本 0.4.0 ｜ 许可 MIT ｜ 默认分支
master｜ 约 5.4k star、314 fork、42 commits（2026-10-22 记录）一句话：把航空航天行业用来禁止误读的受控语言标准 ASD-STE100，改造用来重写面向 AI Agent 的英文（工具描述、报错、Agent 间指令、系统提示、状态报告）。
1.1 一、这是什么
一个 Claude Code skill，输入一段英文，输出一段歧义更少的英文。它的读者假设不是人类，而是另一个没有人类在环、无法追问的解析方。
它做三件事：
- 选一个模式（Strict 或 STE-flavored）。
- 逐句扫描，标记每一处规则违反。
- 在不丢失任何事实、条件、范围限定词和语气强度的前提下重写。
它的能力上限必须先说清楚：它修的是文本的形式，不是内容。一段本来就没内容的文字，改写后只是变成一段干净、简短、标点正确但依旧空洞的文字。
1.2 二、原理：为什么 STE 能用在 Agent 场景
1.2.1 标准的起源
ASD-STE100 由欧洲航空业的行业协会 ASD 发布，1986 年首发（AECMA Document PSC-85-16598），起因是欧洲航空公司的维修技工大多不是英语母语者，却必须照着英文手册作业——读错一条扭矩规格会出人命，而且现场找不到作者问清楚。
标准要消灭的就是两类误读来源：
- 一词多义（
close the valve是动词"关闭阀门"，还是形容词"附近的阀门"？） - 一句多解（被动语态导致执行者不明：到底是谁做的？）
1.2.2 为什么 Agent 处在同一个位置
一个 Agent 解析另一个 Agent 的输出、工具描述或系统提示时，处境和停机坪上的技工惊人地一致：
- 没有 back-channel，不能问 “你是指 X 还是 Y”；
- 没有作者可以澄清；
- 误读有真实代价（错误调用、错误参数、错误的权限判断）。
所以让技工不误读扭矩规格的规则，同样能保护下游 Agent 不误读指令。
1.2.3 标准的结构（Issue 9，2025-01）
| 组成 | 内容 |
|---|---|
| 写作规则 | 53 条，分 9 节：选词、语法、句法、风格 |
| 批准词表 | 约 900 词，每词限一个含义 + 一个词性 |
| 应避免词表 | 约 1200 词，附建议替代词 |
| 术语例外 | 机构可在基础词表之外自定义技术术语表 |
维护方为 Simplified Technical English Maintenance Group（STEMG），自 Issue 6（2013）起免费下载。
1.3 三、关键限制：为什么不包含官方词典
这是使用前必须知道的一点。
Issue 9 第 2 页规定：标准文本"未经 ASD 官员书面授权，不得全部或部分复制或出版"，免费复制权仅授予八类机构（ASD/AIA/AIAC 会员协会及其会员公司与客户、成员国国防部、A4A、适航当局、高校与研究机构的教学用途）。本项目不属于其中任何一类，所以官方 ~900 词表不能进仓库。
后果是这个 skill 的规则被切成两半：
| 类别 | 判定依据 | 强度 |
|---|---|---|
| 结构规则 | 句子形状，可直接描述 | 可以放心理执行 |
| 词法规则 | 完全依赖官方词典 | 只能当作方向，不能声称合规 |
词法规则退化成一种倾向：选最平实、最常用的词，并且每次都这样用。
需要逐字合规（如真正的飞机维修文档），请到官网 https://www.asd-ste100.org/STE_downloads.html 申请（是邮件发链接的申请表，不是直接下载）。
1.4 四、两种模式
| Strict | STE-flavored | |
|---|---|---|
| 适用 | 操作步骤、报错信息、工具/函数描述、Agent 间指令、安全文本 | README、PR 描述、changelog、说明性散文 |
| 定位 | 读错有代价的地方 | 需要可读性但不致命的文字 |
| 词法规则 | 全部强制 | 仅作建议，不算违规 |
结构规则（句长上限、主动语态、简单时态、无短语动词、无分号、无名词化、无营销形容词）两种模式都全量强制。STE-flavored 放弃的是"一词一义"的锁定，因为散文需要词汇变化——把散文改成严格 STE 读起来像换了个人写作，而不是变清晰了。
1.5 五、核心改写规则
1.5.1 结构规则（强制执行）
| 规则 | 应当 | 不应 |
|---|---|---|
| 主动语态 | “The agent deletes the file.” | “The file is deleted."——除非执行者确实未知或无关 |
| 无短语动词（规则 9.3） | “Remove the panel.” / “Start the job.” | “Take off the panel.” / “Spin up the job."——两词动词的含义无法由组成部分预测 |
| 一句一个指令 | “Open the file. Read line 3.” | “Open the file and read line 3, then check if it matches.” |
| 句长 | 指令/步骤 ≤20 词；描述性文字 ≤25 词 | 长的复合句、从句套从句 |
| 无分号（规则 8.1） | 拆成独立句 | 任何分号都不允许。其他标准标点都允许，破折号也不禁——但它通常提示这句该拆了 |
| 名词簇 | 名词性修饰 ≤3 词（“fuel pump valve”） | ≥4 词堆叠（“high pressure fuel pump inlet valve assembly”） |
| 无省略 | 宁可长，也保留主语、动词、冠词 | 为省字数省词——这会产生歧义而不是清晰 |
| 保留情态 | “The request may have failed.” 仍是 “may have” | 把对冲升格成事实（“The request failed."）或凭空添加确定性 |
| 段落 | 一段一个话题，≤6 句 | 多话题混排 |
| 序列用列表 | 3 步以上或条件多于 1 个时用编号/项目符号列表 | 把序列埋在一句散文里 |
1.5.2 词法规则（仅方向）
| 规则 | 应当 | 不应 | 为什么这里更弱 |
|---|---|---|---|
| 一词一义 | 同一动作固定用一个动词（如都用 “check”，不要 check/verify/confirm 混用） | 同一概念轮换同义词 | 文档内一致性可检查；哪个词是官方批准的不可检查 |
| 一词一词性 | “Apply oil to the valve”（名词） | “Oil the valve”（动词） | 取决于词典；两者都通顺时优先名词形式，但不要声称合规 |
| 用动词不用名词（规则 3.7） | “Analyze the log.” | “Perform an analysis of the log.” | 规则 3.7 要求用批准的动词；用动词形式在任何场景都安全，知道是哪个批准词需要词典 |
| 领域术语 | 保留必要的技术名词/动词，非通用英语则定义一次 | 术语从不定义 | 术语例外是真实存在的 STE 条款，但它依赖的基准词典缺失 |
1.5.3 时态：一个带例外的规则
允许：不定式、祈使式、一般现在时、一般过去时、一般将来时、过去分词作形容词。
禁止：现在完成时及其他复合/助动词结构。“We received the report” ✅ / “We have received the report” ❌。
航空手册从不需要现在完成时，排除它对标准毫无损失。其他文本未必如此：
- “The job has completed”（现在已完成、输出此刻可用）与 “the job completed”（过去某时完成）是两个不同的陈述；
- “may have failed” 本身就是对冲，是内容的一部分。
当复合形式承载了简单形式无法承载的信息——当前相关性，或对冲——保留它并标注这处偏离。其他地方遵守规则。
1.6 六、扫描清单（动手改写前先过这六关）
这六条覆盖了机器生成英文大部分难解析的原因，且每条都是机械可判定的——你能指着具体的词或标点说它违反了规则。
- 同义词轮换——同一件事在一篇文档里有多个名字（“the user” / “the customer” / “the client”）。读者无法判断这是一件事还是三件事。修法：定一个名字，全程用它。
- 对冲堆叠——助动词与限定词层层叠加，直到这句话什么也没断言（“it is important to note that this may potentially help to improve”）。修法：直接说出主张，或删掉。
- 名词化——动作被冻成名词（“perform an analysis of”、“provides assistance to”）。修法：还原为动词（analyze、helps）。
- 营销形容词——声称质量而非展示质量的词：seamless、robust、powerful、cutting-edge、effortless、blazing-fast。修法：删掉，或替换成能支撑该说法的度量。
- 长难句——多个想法用分号或破折号串在一起。修法：一个想法一句。
- 软性短语动词——spin up、reach out、dive into、kick off、circle back、touch base。修法：换成单个平实动词（start、contact、read、begin）。
1.7 七、工作流程
选模式（Strict / STE-flavored）。除非用户主动要规则表，否则不声明模式。
通读原文理解含义——没搞懂它必须保留什么之前，不要开始改写。
逐句扫描：标记结构规则违反和上述六项清单。STE-flavored 模式下词法规则标记但不强制。可先跑
scripts/ste-lint.py做机械首轮检查。逐句改写，严格保留原意。如果某个改写会丢掉必要精度（安全条件、范围限定、数字），就保留长句并标注，而不是悄悄简化。
- 提交改写前先检查情态。对冲（may、could、sometimes、is likely to）承载作者信心，而信心就是内容。把对冲升格成事实的"简化"不是简化，是换了一个主张。这是善意的 STE 改写最常见的翻车方式——因为对冲恰恰是长度上限最想让人砍掉的东西。
- 绝不添加原文没有的事实。一个读起来更好的改写，如果它补上了原因、频率或机制，它就已经不是改写了。
输出改写结果，除非用户要看，否则模式选择与规则分析都留在内部。
如果原文本来就合规，就直说——不要强行改。
1.8 八、输出格式
默认：只输出改写后的文本，别的一律不加。 不加前言、不加模式声明、不加违规计数、不加改动总结、不加规则表、不加"需要我解释吗”。
唯一允许的追加：第 4 步刻意保留了长句时，在正文后加一行，以 Kept as-is: 开头，说明保留了哪个短语、避免丢失什么精度。没有需要报告的内容时就不加。
用户要求解释时（“show the diff”、“which rules did it break”、“explain the changes”、“before/after”），改为输出规则表：
表后再加一行说明故意没有简化的地方及原因（通常是"简化会丢失必要精度”）。
1.9 九、配套 linter 脚本
scripts/ste-lint.py：纯标准库、确定性的结构规则检查器。stdin 或文件参数均可，--json 输出结构化结果。
会检查：分号、软性短语动词短列表、名词化、营销形容词、被动语态、现在完成式（含 has run 这类不规则分词）、长句、同义词轮换（按文件作用域检查"一词一义”）、受支持的列表项中的悬空连接词。
不会检查：
- 名词簇长度（需要词性标注）；
- 词典以外的短语动词——所以
take off the panel会通过； - 永远不检查对冲和情态（
--selftest断言 “may have failed” 干净通过）。
参数与退出码：
| 参数 | 作用 |
|---|---|
--baseline N | 容忍 N 处硬性违规（用于接管存量文档时） |
--disable rule1,rule2 | 静音指定规则 |
--json | 结构化输出 |
--selftest | 自检 |
硬性违规超过 baseline 时退出码 1；advisory 类发现（被动语态、复合时态）永不导致失败。
句子长度怎么数：按空白分隔、至少含一个字母或数字的 token。单反引号内的行内代码、列表符号、引用符号、裸标点（如带空格的破折号）不计。
悬空连接词规则的范围：检查行首 0–3 个前导空格 + 标记后为 ASCII 空格的列表标记。支持无序 - * +，以及以 . 或 ) 结尾的数字有序标记（1.、1)）。检查缩进的续行直到最后一行有意义的行。不解析引用块内的列表语法、惰性续行、完整的嵌套列表语义；4 个及以上前导空格的独立行不算列表标记。围栏检测用简单规则：strip 后以三个反引号或三个波浪号开头即切换围栏状态。
仓库自己的文本 lint 不干净是正常的：规则表格里引用了它们禁止的样例，有些句子也确实长。python scripts/ste-lint.py --baseline 36 SKILL.md 用来把这些读作示例而非缺陷。examples/linter-edge-cases.md 是故意写坏的测试夹具，用来演示不完整的 Markdown 列表项（运行应得到两条预期发现），不要拿它当合规范例。
零违规不等于改写正确：linter 只检查结构模式。它不比对原文与改写，不验证要求强度是否保持一致，也不证明语义被保留。“零违规"只说明已配置的结构检查没发现结构问题。
1.10 十、安装
最快（npx skills CLI） ，在项目根目录运行：
该 CLI 会发送匿名安装遥测（仅技能名和时间戳，无个人或设备信息），用于 skills.sh 排行榜；设 DISABLE_TELEMETRY=1 可关闭。
克隆：
放进 ~/.claude/skills/ 后在所有 Claude Code 项目中可用，适合贡献者和想要 git pull 实时更新的用户。
在 SiYuan 中可以直接用内置 skill 安装能力传入
danyuchn/asd-ste100-skill，无需手动克隆。
1.11 十一、使用
用请求触发：
或者直接粘贴文本，要求"disambiguate this” / “apply STE100 to this” / “reduce ambiguity in this output”。
默认只返回改写结果。要看应用了哪些规则，加上 “show the diff” 或 “explain the changes”。
改写前后示例（来自仓库 README）：
| 改写前 | 改写后 |
|---|---|
| “This tool will attempt to synchronize state across the various backends that have been configured, and if a conflict is detected it may resolve it automatically depending on the strategy that has been set, or otherwise it will surface the conflict for manual review.” | “The tool tries to synchronize state across the configured backends. If it finds a conflict, it reads the configured strategy. If the strategy allows automatic resolution, the tool may resolve the conflict without a user. If the tool does not resolve the conflict, it reports the conflict for manual review.” |
| “An error may have occurred while processing your request due to a possible mismatch in the expected data format, which could be caused by an outdated client version.” | “Your request may have failed. The cause may be a data format that does not match what the server expects. An outdated client can cause this mismatch. Check your client version.” |
更多例子见 examples/before-after.md。
1.12 十二、适用与不适用
适合：Agent 间消息、工具/函数描述、报错信息、系统提示、Agent 间指令——任何由机器或非母语读者解析、且没有人类可以追问的英文。
不适合：创意写作、营销文案，以及任何"语气和细微差别本身就是重点"的场景。STE 被刻意做平、做字面。
能力边界（会做） ：
- 把含混密集的英文改写成短句、单义、主动语态；
- 默认只返回改写文本，被要求时说明所用规则；
- 保留原文中的每一个事实、条件和范围限定词；
- 保留每一个对冲的强度，不添加原文没有的主张；
- 为必须保留的领域术语建议一行术语表条目。
能力边界（不会做） ：
- 不假装背下了官方 ~900 词表——始终以官方下载为准；
- 不简化创意、营销、说服性文案；
- 不为缩短句子而悄悄丢掉安全条件、例外或范围限定词——而是标注取舍；
- 不把 “may have failed” 改成 “failed”，也不把 “could be caused by X” 改成 “X is the cause”；
- 不保证产出航空航天/国防级 STE 合规文档——这是受 STE 启发的通用清晰度工具，不是认证编写工具；
- 不让空洞的内容变得有用——如果文本没东西可说，就直说而不是打磨它；
- 不为了短而短。目标是消除歧义，不是压缩。压缩过了头会消耗读者时间而不是节省时间，所以句意无歧义就停，而不是最短才停。
1.13 十三、延伸资源与相关工具
references/writing-rules.md——9 个规则章节与词典结构的完整摘要，附官方与二手来源引用examples/before-after.md——改写实例，含官方 STE 示例和为本 skill 构造的 Agent 输出示例scripts/ste-lint.py——确定性结构规则 linter- rewrite-fidelity-skill——比对原文与改写，标记语义与情态变化。基于模式匹配，每条标记都需要自己核对
- 希伯来语移植版：g4lb/asd-ste100-hebrew-skill（含希伯来语 linter。ASD-STE100 只定义英语，这是改编而非官方标准）
来源：ASD-STE100 官网 ｜ About STE ｜ ASD Europe ｜ Wikipedia ｜ TechScribe ｜ SKYbrary