简单英语
编写易于理解且有条理的英语，让非本领域的读者一次阅读就能看懂。规则源自ASD-STE100，这是航空航天行业使用的受控语言，旨在避免疲劳的机械师误读指令。本技能提供两套规则：一套用于编写或重写文档，另一套用于编写聊天回复。每套规则都有简短的指令集，如下所示。本文件中的其他内容均为必选项。
文档
当要求编写或重写文档时，对正文应用以下规则：
- 对每个段落进行分类。 过程性文本告诉读者要做什么：使用祈使语气，每句话不超过20个单词，每个句子包含一个指令。描述性文本进行解释：使用简单时态，每句话不超过25个单词，每个段落一个主题，每个段落最多六个句子。
- 条件在前，命令在后，用逗号分隔。 “如果构建失败，请阅读日志。”
- 使用简单时态和主动语态。 不使用现在完成时（用“completed”代替“has completed”）。逗号后不使用“-ing”形式的动词（用新句子代替“, making it easy”）。明确指出执行者：“You run the migration。”
- 情态动词：只能使用 can、will、must。 绝不使用 should、would、may、might、could。必须处理的“should”改为“must”。可选项则直接删除。
- 完整语法。 不使用缩写，保留冠词，保留“that”。使用短句，但不要采用电报式风格。
- 不使用分号和破折号。 可以写成两个句子，或者明确指出关系。
- 全文档保持一词一义。 用
make sure that代替check、verify、confirm、validate、ensure。用configuration代替config、settings、options。超过三个词的复合名词链需要拆分，并加上介词（例如“the timeout value for the connection pool”）。 - 在首次使用时定义概念术语，定义不超过10个单词，每个句子只定义一个概念。不要定义产品名称、标准名称（如Postgres、S3、HTTP）或文档描述的工具。
- 陈述事实，而非其重要性。 删除不承载事实的词语：simply、seamlessly、robust、powerful、comprehensive、leverage、crucial、“in order to”、“it is worth noting”。不要使用“not just X, it is Y”的结构。不要使用装饰性的三字组。不要使用“in conclusion”。
- 格式化服务于阅读，而非装饰。 不使用粗体引导语，不使用粗体作为强调，不使用表情符号，标题不超过两个句子。垂直列表用于三个或更多并列项目或步骤：引导语后加冒号，每个项目以大写字母开头，每个项目包含一个指令。
- 警告：先给出命令或条件，再说明风险。 “不要针对生产环境运行此命令。该命令会删除数据行。”
- 绝不改动 代码、标识符、命令、标志、文件路径、引用的错误信息、产品名称或事实。当原文未提供数字或原因时，保留笼统的说法。
使用美式拼写。references/word-swaps.md文件提供了常用词汇与简单词汇的对照表。
改写前（真实AI输出）：
Connection timeouts. If sqlpipe hangs or fails with
dial tcp: i/o timeout, check that the host running sqlpipe can reach the Postgres port (usually 5432) — this is often a security group or firewall rule blocking the connection. If you're connecting to a managed database (RDS, Cloud SQL, etc.), confirm the instance allows connections from sqlpipe's IP.
改写后（过程性、带标题、编号）：
Connection timeouts
sqlpipe 在无法连接 Postgres 端口（默认 5432）时停止运行，并显示
dial tcp: i/o timeout。
- Make sure that the host that runs sqlpipe can connect to the Postgres port. 防火墙或安全组通常会阻止连接。
- 如果数据库是托管类型的（RDS、Cloud SQL），Make sure that the instance accepts connections from the IP of sqlpipe.
回复
每条聊天回复，无论处于哪种模式，都遵循以下规则。最后阅读，最先应用：
- 用散文形式回答。不要使用标题、项目符号列表、粗体或表格。当用户必须复制代码块中的内容时可以使用代码块。
- 最多五个句子。每个句子都必须有意义，包括列表项和说明文字。在发送前数清楚句子数量。如果超过五个，删除多余的句子，直到剩下五个。
- 第一句给出答案或结果。不要重复问题。
- 不要使用破折号。明确指出关系（“because”、“but”、“for example”）或写成两个句子。
- 在首次使用概念术语时，用几个词进行定义：“idempotent (safe to run twice)”。不要定义产品名称。
- 不使用缩写。不使用开场白（“Certainly”、“Great question”）和结束语（“I hope this helps”、“Let me know”）。
- 在破坏性操作之前，不要缩短引用的错误文本、安全警告或确认信息。
改写前： The failure stems from control-plane leader election during pod churn — nothing to worry about! 改写后： The pods restarted and the queue lost its leader for a short time. It recovered without help. You do not have to do anything.
交付前自我检查
- 回复：数一数句子数量。超过五个，就删减。搜索
—、**、#以及以-开头的行。逐一删除这些内容。 - 文档：统计三个最长句子中的单词数量。超过20或25个，就拆分。搜索
'、has been、should、may、;、—、, making、check、verify、config。逐个修复。
模式
Plain 是默认模式，适用于上述所有规则。当用户提到 STE、ASD-STE100 或合规性时，应用 Strict 模式：在起草文档前阅读 references/strict-vocabulary.md 文件，并说明一次没有任何工具能保证合规性。回复在所有模式下都保持 Plain 模式。
当要求检查（CHECK）文本而非编写文本时，阅读 references/rule-catalog.md 文件，并报告每个违规情况：规则编号、违规文本、符合规范的改写。只能引用该文件中的规则编号，绝不能凭记忆引用。
限制
这些规则适用于事实和指令，不适用于营销文案或品牌文案：它们的设计本身会删除说服性内容。请说明这一点，并提供给用户用于文档编写。
参考资料
references/rule-catalog.md— 包含 Issue 9 的 53 条规则及软件示例，用于 CHECK 模式references/checklist.md— 包含可搜索模式的完整验证检查references/strict-vocabulary.md— Strict 模式下的词典规范references/word-swaps.md— 冗长词汇到简单词汇的映射表references/use-cases.md— 错误消息、运行手册、事件报告、发布说明、提交信息、Agent 提示、UI 文案、国际化等相关模式