# ASD-STE100 Skill 使用说明与原理

LLMS 索引： [llms.txt](/llms.txt)

---

# 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，输入一段英文，输出一段歧义更少的英文。它的读者假设不是人类，而是**另一个没有人类在环、无法追问的解析方**。

它做三件事：

1. 选一个模式（Strict 或 STE-flavored）。
2. 逐句扫描，标记每一处规则违反。
3. 在**不丢失任何事实、条件、范围限定词和语气强度**的前提下重写。

**它的能力上限必须先说清楚**：它修的是文本的**形式**，不是**内容**。一段本来就没内容的文字，改写后只是变成一段干净、简短、标点正确但依旧空洞的文字。

## 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 六、扫描清单（动手改写前先过这六关）

这六条覆盖了机器生成英文大部分难解析的原因，且每条都是机械可判定的——**你能指着具体的词或标点说它违反了规则**。

1. **同义词轮换**——同一件事在一篇文档里有多个名字（"the user" / "the customer" / "the client"）。读者无法判断这是一件事还是三件事。**修法**：定一个名字，全程用它。
2. **对冲堆叠**——助动词与限定词层层叠加，直到这句话什么也没断言（"it is important to note that this may potentially help to improve"）。**修法**：直接说出主张，或删掉。
3. **名词化**——动作被冻成名词（"perform an analysis of"、"provides assistance to"）。**修法**：还原为动词（analyze、helps）。
4. **营销形容词**——声称质量而非展示质量的词：seamless、robust、powerful、cutting-edge、effortless、blazing-fast。**修法**：删掉，或替换成能支撑该说法的度量。
5. **长难句**——多个想法用分号或破折号串在一起。**修法**：一个想法一句。
6. **软性短语动词**——spin up、reach out、dive into、kick off、circle back、touch base。**修法**：换成单个平实动词（start、contact、read、begin）。

## 1.7 七、工作流程

1. **选模式**（Strict / STE-flavored）。除非用户主动要规则表，否则不声明模式。
2. **通读原文理解含义**——没搞懂它必须保留什么之前，不要开始改写。
3. **逐句扫描**：标记结构规则违反和上述六项清单。STE-flavored 模式下词法规则标记但不强制。可先跑 ​`scripts/ste-lint.py` 做机械首轮检查。
4. **逐句改写**，严格保留原意。**如果某个改写会丢掉必要精度**（安全条件、范围限定、数字），就保留长句并标注，而不是悄悄简化。

   - **提交改写前先检查情态**。对冲（may、could、sometimes、is likely to）承载作者信心，而信心就是内容。把对冲升格成事实的"简化"不是简化，是换了一个主张。这是善意的 STE 改写最常见的翻车方式——因为对冲恰恰是长度上限最想让人砍掉的东西。
   - **绝不添加原文没有的事实**。一个读起来更好的改写，如果它补上了原因、频率或机制，它就已经不是改写了。
5. **输出改写结果**，除非用户要看，否则模式选择与规则分析都留在内部。
6. **如果原文本来就合规，就直说**——不要强行改。

## 1.8 八、输出格式

**默认：只输出改写后的文本，别的一律不加。**  不加前言、不加模式声明、不加违规计数、不加改动总结、不加规则表、不加"需要我解释吗"。

唯一允许的追加：第 4 步刻意保留了长句时，在正文后加**一行**，以 ​`Kept as-is:` 开头，说明保留了哪个短语、避免丢失什么精度。没有需要报告的内容时就不加。

**用户要求解释时**（"show the diff"、"which rules did it break"、"explain the changes"、"before/after"），改为输出规则表：

```markdown
| Rule violated | Original | Simplified |
|---|---|---|
| Present perfect tense | "We have received your request." | "We received your request." |
| Noun cluster (4+ words) | "the agent task queue priority handler" | "the handler that sets task-queue priority" |

Mode: Strict. 7 violations found.
```

表后再加一行说明**故意没有**简化的地方及原因（通常是"简化会丢失必要精度"）。

## 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）** ，在项目根目录运行：

```bash
npx skills add danyuchn/asd-ste100-skill
npx skills update   # 后续更新
```

该 CLI 会发送匿名安装遥测（仅技能名和时间戳，无个人或设备信息），用于 skills.sh 排行榜；设 ​`DISABLE_TELEMETRY=1` 可关闭。

**克隆**：

```bash
git clone https://github.com/danyuchn/asd-ste100-skill ~/.claude/skills/asd-ste100
```

放进 ​`~/.claude/skills/`​ 后在所有 Claude Code 项目中可用，适合贡献者和想要 ​`git pull` 实时更新的用户。

> 在 SiYuan 中可以直接用内置 skill 安装能力传入 ​`danyuchn/asd-ste100-skill`，无需手动克隆。

## 1.11 十一、使用

用请求触发：

```
Disambiguate this tool description
Rewrite this error message so an agent can't misparse it
Apply ASD-STE100 to this instruction
```

或者直接粘贴文本，要求"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](https://github.com/meiluosi/rewrite-fidelity-skill)——比对原文与改写，标记语义与情态变化。**基于模式匹配，每条标记都需要自己核对**
- 希伯来语移植版：[g4lb/asd-ste100-hebrew-skill](https://github.com/g4lb/asd-ste100-hebrew-skill)（含希伯来语 linter。ASD-STE100 只定义英语，这是改编而非官方标准）

**来源**：[ASD-STE100 官网](https://www.asd-ste100.org/) ｜ [About STE](https://www.asd-ste100.org/about_STE.html) ｜ [ASD Europe](https://www.asd-europe.org/standards-specifications/simplified-technical-english/) ｜ [Wikipedia](https://en.wikipedia.org/wiki/Simplified_Technical_English) ｜ [TechScribe](https://www.techscribe.co.uk/techw/asd-simplified-technical-english.htm) ｜ [SKYbrary](https://skybrary.aero/articles/simplified-technical-english-ste)