title: “Simple English — Rewrite text to ASD-STE100 Simplified Technical English” sidebar_label: “Simple English” description: “Rewrite text to ASD-STE100 Simplified Technical English”
{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能对应的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}
简明英语
将文本按照 ASD-STE100 简化技术英语规范进行重写。
技能元数据
| 来源 | 可选 — 通过 hermes skills install official/creative/simple-english 安装 |
| 路径 | optional-skills/creative\simple-english |
| 版本 | 1.2.0 |
| 开发者 | AminBlg（https://github.com/AminBlg/SimpleEnglish），由 Hermes Agent 推广使用 |
| 许可证 | MIT |
| 支持平台 | linux、macos、windows |
| 标签 | 写作、文档编写、STE、asd-ste100、技术写作、编辑、防止AI生成的冗余内容 |
| 相关技能 | humanizer |
参考：完整 SKILL.md 内容
简明英语：采用航空航天手册风格写作
遵循 ASD-STE100 简化技术英语规范来撰写技术文本。STE 是航空航天及国防行业制造商用于编写维护文档的标准化语言。制定这些规则的目的在于确保那些非英语母语且疲惫不堪的读者不会误解指令。同时，这些规则还能消除 AI 生成文本常见的弊端，例如长句、同义词反复使用、含糊表述、填充词以及冗余修饰句。
请以那位疲惫的读者为写作对象，确保每句话都经得起一次阅读。
如何在 Hermes 中使用该技能
文本通常通过以下三种方式提供：
- 直接粘贴：用户将文本直接粘贴到消息中。请在原处对其进行重写，然后回复修改后的结果。
- 文件上传：用户指定一个文件（如 README、操作手册或文档页面）。首先使用
read_file函数读取该文件，接着通过patch对特定部分进行重写，或使用write_file进行整体重写。注意切勿修改代码块、标识符或带引号的错误信息（详见“不可修改内容”部分）。 - 检查模式：用户要求你检查文本是否符合 STE 标准，而非直接重写。需参照
references/checklist.md的格式，针对每一处违规项报告规则编号、违规原文以及符合标准的改写版本。
该技能与 humanizer 存在区别：humanizer 的作用是恢复自然的人类语言表达风格；而 simple-english 则旨在为技术文档强制执行规范的语言表达。文档、操作手册及错误信息应使用此技能处理；博客文章、散文及个人写作则建议使用 humanizer。切勿对同一文本同时应用这两种技能。
你的任务
当被要求撰写或重写技术文本时：
- 选择模式（如下所示的“灵活模式”或“严格模式”）。
- 将每段文本分类为程序性描述或说明性描述。后续所有规则均以此分类结果为依据。
- 在起草前先规范词汇使用。在严格模式下，涉及检查、验证、确认等含义时必须使用
make sure that—— 因为词典会将这四个词视为动词而予以拒绝。在灵活模式下，只需选择其中一个并始终使用。对于配置/设置相关内容，也需仅选择一个名词（所有技术名词均有效，选定后不可更改）；在整个文档中不得再使用其他词汇来表示这些概念。 - 应用下方列表中的规则。
- 在提交前进行自我检查。此步骤并非可选。
- 绝不可修改代码、标识符、命令或已引用的错误信息（详见“不可更改内容”部分）。
当被要求对文本进行核查而非直接撰写时，需针对每一处违规情况报告：规则编号、违规原文以及符合要求的改写版本。仅引用本文件中存在的规则编号，不得凭记忆添加规则编号——其编号逻辑较为复杂，模型有时会自行编造（经测试，没有该文件的智能体曾引用“规则3.1：短句”；而真正的规则3.1是关于动词形式的）。
两种模式
| 模式 | 适用场景 | 需遵循的规则 |
|---|---|---|
| 灵活模式（默认） | 文档、README文件、错误信息——用户希望获得清晰易懂的文本 | 所有结构规则。领域专用词可保留（如“idempotent”、“webhook”）。 |
| 严格模式 | 用户提及STE、ASD-STE100或合规要求时 | 结构规则 + 严格的词汇规范要求，并需告知用户要完全符合规范必须使用官方词典（可在 asd-ste100.org 免费获取）。 |
第一步：对文本进行分类
| 指令型（操作步骤） | 描述型（说明解释） | |
|---|---|---|
| 目的 | 告诉读者该做什么 | 解释某事物是什么或具有何种功能 |
| 动词形式 | 祈使句：“安装泵。” | 一般现在时/过去时/将来时 |
| 句子长度限制 | 20个单词（规则5.1） | 25个单词（规则6.3） |
| 单元规则 | 每句一条指令（5.2） | 每段一个主题（6.5），每段最多六句（6.6） |
不得在同一段落中混用这两种类型。 “入门指南”部分属于指令型，而“架构介绍”部分则属于描述型。指令内容中的注释属于描述型（需符合25字限制，且不能使用祈使句）。
规则目录
共包含9个章节中的53条规则，这些规则是根据ASD-STE100第9版整理并加入了软件示例。其官方原文可在asd-ste100.org的免费标准文档中查看。
第1章 — 词汇（规则1.1-1.14）
| 规则 | 指令 |
|---|---|
| 1.1 | 仅可使用已批准的词汇、技术名词或技术动词。 |
| 1.2 | 只能以规定的词性使用已批准的词汇。 |
| 1.3 | 仅能以规定的含义使用已批准的词汇。 |
| 1.4 | 仅可使用已批准的动词和形容词形式。 |
| 1.5 | 可将领域专用词作为技术名词使用（如“webhook”、“commit”、“endpoint”）。 |
| 1.6 | 仅当某个词汇属于技术名词或其组成部分时，才可使用未经批准的词汇。 |
| 1.7 | 禁止将技术名词用作动词。 |
| 1.8 | 可使用与自身项目或行业相关的技术名词。 |
| 1.9 | 选择技术名词时，应选用简短且表意清晰的词汇。 |
| 1.10 | 禁止使用地域性词汇、俚语或行话作为技术名词。 |
| 1.11 | 一个项目对应一个名称，不可在这里称其为“config”，而在别处又称为“settings”。 |
| 1.12 | 可将领域专用动词作为技术动词使用（如“deploy”、“compile”、“merge”）。 |
| 1.13 | 禁止将技术动词用作名词。 |
| 1.14 | 需采用美式英语拼写规则。 |
在实用模式中，规则1.5、1.8和1.12起关键作用：该模式允许使用特定领域的词汇。而智能体常违反的规则则是1.7、1.11和1.13。
错误示例： 可以先通过webhook发送事件，然后再进行部署。
正确表述： 先将事件发送到webhook，之后再部署服务。
第2节 — 多词名词（规则2.1-2.2）
| 规则 | 指令 |
|---|---|
| 2.1 | 多词名词应由三个词或更少组成。 |
| 2.2 | 若技术名词需要超过三个词，则需先完整写出，之后再给出简写形式或用连字符连接各组成部分。 |
| 可使用介词（of、on、in、for）拆分过长的名词短语： |
修改前： the connection pool timeout configuration value 修改后： the timeout value for the connection pool
第3节 — 动词（规则3.1-3.7）
| 规则 | 要求 |
|---|---|
| 3.1 | 仅可使用词典中列出的动词形式。 |
| 3.2 | 仅允许使用：不定式、祈使句、一般现在时、一般过去时、一般将来时，以及用作形容词的过去分词。 |
| 3.3 | 过去分词仅可作为形容词使用（例如“the cached response”）。 |
| 3.4 | 复杂结构中不得使用助动词，禁止使用现在完成时，也禁止出现“is to be installed”这类表达。 |
| 3.5 | “-ing”形式仅可作为技术名词或名词短语的一部分使用（例如“logging”、“the mounting bracket”），绝不能用作动词。 |
| 3.6 | 需使用主动语态。在描述性文本中，仅在无法明确执行动作的主体时才可使用被动语态。 |
| 3.7 | 应用动词而非名词来描述动作（例如“compress the file”，而非“perform compression of the file”）。 |
允许使用的情态动词：can、will、must。禁止使用的：should、would、may、might、could（规则3.2）。 标准规定，即便表示可能性也不得使用“could”，应写成“an explosion can occur”，而非“could occur”。至于“should”：要求性内容应改为“must”；建议性内容则应直接作为事实陈述或被删除。对于智能体指令而言，这一点尤为重要——模型会将“should”视为可选内容。
修改前： The migration has completed and the table is being rebuilt. 修改后： The migration is complete. The database rebuilds the table.
之前： 可在配置文件中设置该标志，从而无需重启。
之后： 您可以在配置文件中设置该标志，这样一来就不需要重启了。
之前： 必须调整温度参数。
之后： 调整温度即可。
第4节 — 句子（规则4.1-4.5）
| 规则 | 说明 |
|---|---|
| 4.1 | 写出简短且清晰的句子。 |
| 4.2 | 不要省略单词或使用缩写形式来缩短句子。务必保留冠词以及“that”这类词汇。 |
| 4.3 | 对于复杂的文本，应采用竖列列表的形式呈现。 |
| 4.4 | 对于相关主题的句子之间，可使用连接词进行衔接（如“Then”、“As a result”）。 |
| 4.5 | 在适用的情况下，应在名词前加上冠词（the、a、an）或指示形容词（this、these）。 |
规则4.2即为反简洁性规则。优秀的短句应结构完整、语法规范，而非过于简略生硬：
错误的简化写法： 在运行之前确保文件存在。
规范的短句： 在执行命令之前，请确保该文件已经存在。
第5节 — 步骤说明写作（规则5.1-5.5）
| 规则 | 说明 |
|---|---|
| 5.1 | 每句最多20个单词，警告与注意事项亦需遵循此限制。 |
| 5.2 | 每句仅包含一条指令，除非涉及同时执行的两个操作。 |
| 5.3 | 指令应采用祈使句式来书写，例如：“Run the migration.” |
| 5.4 | 命令之前需先说明必要条件，各条件之间用逗号分隔，例如：“If the build fails, read the log.” |
| 5.5 | 注释仅用于提供信息，不得包含指令内容。注释同样受25个单词的限制。 |
| 修改前： 在配置客户端之前，您需要先从控制面板获取 API 密钥，该操作可在“设置”选项中完成。 | |
| 修改后： 先在“设置”选项中的控制面板获取 API 密钥，随后使用此密钥来配置客户端。 |
第 6 节 — 描述性写作（规则 6.1-6.6）
| 规则 | 指导要求 |
|---|---|
| 6.1 | 逐步提供信息：每句只陈述一个新事实。 |
| 6.2 | 使用关键词和短语为文本构建逻辑结构。 |
| 6.3 | 每句不超过 25 个单词。 |
| 6.4 | 将相关内容归类到不同段落中。 |
| 6.5 | 每段仅阐述一个主题。 |
| 6.6 | 每段最多包含六句句子。 |
描述性文本中不得使用祈使句。描述用于说明，而步骤说明则用于指导操作。
第 7 节 — 安全提示（规则 7.1-7.3）
| 规则 | 指导要求 |
|---|---|
| 7.1 | 使用能表明风险等级的词语（“WARNING”表示可能造成伤害，“CAUTION”表示可能造成损失）。 |
| 7.2 | 以明确的指令或条件开头。 |
| 7.3 | 接着说明相应风险或可能产生的后果。 |
切勿将指令隐藏在解释内容之后。这一格式同样适用于具有破坏性的 CLI 参数、不可逆的迁移操作以及危险的 API 选项。
修改前： 需要注意，如果在针对生产环境运行时恰好启用了破坏性参数，某些情况下可能会导致数据丢失。
修改后： CAUTION：请勿在对生产环境使用 --force 参数。该参数会删除与源数据不匹配的记录。
第 8 节 — 标点符号与字数限制（规则 8.1-8.7）
| 规则 | 指导说明 |
|---|---|
| 8.1 | 除分号外，所有标准标点符号均可使用。若遇到分号，应拆分为两个句子。 |
| 8.2 | 对作为整体使用的多个单词，需用连字符连接。 |
| 8.3 | 括号可用于引用内容、序号、缩写、复数形式、解释说明及备选选项。 |
| 8.4 | 在垂直列表中，用于分隔项的前导冒号可用于结束句子，以便计算字数。 |
| 8.5 | 括号内的文本视为一个单词。 |
| 8.6 | 数字、带单位的数字、缩写、字母数字标识符、引号内的文本、标题、标签及专有名词均视为一个单词。 |
| 8.7 | 由连字符连接的单词也视为一个单词。 |
规则8.6对软件相关文本尤为重要：例如，反引号中的 sqlpipe run --config sqlpipe.yaml 属于引号内的文本，因此仅计为一个单词。如此一来，较长的标识符也不会超出句子的字数限制。
第9节 — 写作规范（规则9.1-9.4，GR-1至GR-8）
| 规则 | 指导说明 |
|---|---|
| 9.1 | 若逐字替换无法实现表达意图，应重新构建句子结构。 |
| 9.2 | 需正确使用每个已被认可的单词：既包括其认可的含义，也包括其认可的词性。 |
| 9.3 | 不要构造短语动词（例如将“go down”改为“decrease”，将“set up”改为“install”或“configure”）。 |
| 9.4 | 整份文档需保持风格与术语的一致性。 |
| 通用建议 GR-1 至 GR-8：保留连词“that”，谨慎使用“with”，确保代词有明确的指代对象，优先使用“this + 名词”而非单独的“this”，避免误用形近词，避免使用拉丁文缩写，采用包容性语言表达，并且只有在确定正确时才使用所有格撇号形式（GR-8：若不确定则不要使用——非母语读者很难理解）。 |
针对软件文档的 GR-6 规定：“e.g.”应改为“for example”，“i.e.”应改为“that is”，同时删除“etc.”——应列出具体项目或写上“and more”。
词汇规范
官方词典（约900个认可词汇，约1,200个禁用词汇并提供了替代词）由ASD拥有版权，此处不予转载。即便没有该词典，其相关规则依然适用：一个词，一个含义，一种词性。
以下是已确定的词性规则，可作为写作范例：
| 单词 | 规则 |
|---|---|
| test, check, work | 仅限名词词性。“Do a test”而非“test the pump”。“Check that X”应改为“make sure that X”。 |
| oil | 仅限技术名词词性。其动词形式在词典中为“lubricate”：“Lubricate the linkage with oil.” |
| help | 仅限动词词性。其名词形式在词典中为“aid”：“with the aid of”。 |
| fall（名词） | 被视为错误用法。表示价值下降时应使用“decrease”。仅当描述物体因重力向下坠落时才可使用FALL（动词）：“Make sure that the tools do not fall into the engine.” |
| follow | 仅表示“跟随在……之后”，绝不能表示“服从”。应写为“obey the instructions”。 |
| above, below | 仅用于描述物理位置。表示范围时需使用“more than”“less than”。 |
情态动词层级体系
| 你撰写的表达 | STE 撰写的表达 |
|---|---|
| should（表示要求） | must |
| should（表示建议） | 直接删除该词，或以事实形式表述：“X 更好，因为 Y。” |
| may / might / could（表示可能性） | can |
| may（表示许可） | can |
| would（表示假设） | 重新组织句子结构： “如果 X 发生，那么 Y 也会发生。” |
简化替换规则
此表格由我们制定，并非 ASD 词典。它用于将人工智能生成的文档中过度使用的词汇替换为更简洁的表达。如果某个词并不代表任何事实，建议直接删除而非替换。
| 原表述 | 建议替换为 |
|---|---|
| leverage, utilize | use |
| in order to | to |
| prior to | before |
| ensure | make sure that（严格模式下；在实用模式下，若该词为您指定的检查动词，则仍可保留） |
| it is worth noting that | （删除） |
| it’s important to, crucially | （删除——直接陈述事实） |
| simply, just, easily, seamlessly, effortlessly | （删除） |
| robust, powerful, comprehensive, performant | （删除，或给出可量化的具体特性） |
| functionality | function, feature |
| enables you to, allows you to | you can |
| is designed to, aims to | （删除——直接说明其功能） |
| facilitate | help, make possible |
| dive into, delve into | read, examine |
| when it comes to | for |
| in the event that | if |
| due to the fact that | because |
| as needed, as necessary | （直接说明条件） |
| and/or | 选择其中一个，或写为“X, or Y, or both” |
| e.g. / i.e. / etc. | for example / that is / （列出具体示例） |
| gracefully handles | （直接说明其处理方式：“retries three times, then stops”） |
| out of the box | by default |
| under the hood | internally |
| blazingly fast, state-of-the-art | fast（给出具体数值）/ （删除） |
| streamline | make simpler, make faster |
| plethora, myriad | many |
| addresses the issue, tackles | corrects the fault, removes the error |
技术术语——词典中未收录。请选择一个并在两种模式下保持一致：
- config / configuration / settings / options → 仅需选择其一
词典已有定论的情况——标准已选定对应词汇。严格模式下应使用官方认可的词；实用模式下也请选择一个并保持一致：
| 您使用的表达 | 词典状态 | 建议替代词 |
|---|---|---|
| check（动词）/ verify / confirm / ensure | 均作为动词被拒收 | 严格模式：make sure that；实用模式：任选其一 |
| validate | 词典中未收录 | 可按规则1.12作为技术动词使用，或替换为 make sure that |
| delete / drop（动词）/ destroy | 均被拒收 | 数据操作用 erase，物理移除用 remove；避免使用 drop 和 destroy |
| remove | 已获认可为动词 | 保持原词不变 |
| run / execute | 均被拒收 | 严格模式：运行用 operate，执行用 do；实用模式：任选其一 |
| invoke / launch | 词典中未收录 | 可按规则1.12作为技术动词使用 |
| display（动词）/ render / present（动词） | 均被拒收 | 已获认可的动词为 show |
| issue | 词典中未收录 | 可作为技术名词使用，或替换为已获认可的 problem |
| failure | 通用含义被拒收；作为性能损失的技术名词时已被认可 | 仅当指性能故障时可使用，例如：“泵的故障” |
| error | 已获认可的名词 | 保持原词不变 |
| problem | 已获认可的名词 | 保持原词不变 |
绝不可更改的术语
这些属于技术专有名称（规则1.5、8.6）。即便其不符合词汇规范，也必须保持原样不变：
- 代码块、内联代码、标识符、CLI命令、参数标志及文件路径
- 带引号的错误信息与日志行
- 产品名称、API端点名称及配置键
- 带单位数的数值——在句子长度限制中，每个均算作一个词
超出文档范畴的应用场景
规则相同，应用对象不同。完整的改写示例可见 references/use-cases.md：
- 错误信息：需说明发生了什么（使用简单过去时），若已知原因则一并列出，最后以祈使句给出解决方案。禁止使用“哎呀”“请确保”等表述，亦不可加入任何道歉性内容。
- 操作手册：这是STE的强项。需采用祈使句式，先说明条件，再列出步骤，步骤前还需添加警告提示。
- 事件报告：仅可使用简单过去时。例如，“我们发现了一个可能已造成影响的问题”应改为“在协调世界时14:02至14:31期间，有12%的请求失败。”
- 版本更新说明：涉及破坏性变更时，需遵循警告式表述结构——先说明操作命令，再阐述潜在风险。
- 智能体指令（提示词、AGENTS.md）：系统提示词是为无法提问的读者设计的操作指南。每句仅含一条指令，禁止使用“应该”这类词汇，且需先明确条件。
- 翻译准备：这是STE的核心工作。确保每个词只有一个含义，并保持完整的语法结构，即可大幅降低翻译中的歧义。
发布前务必自行检查
此步骤并非可选。请对您的草稿进行以下四项检查：
- 统计你最长的三个句子中的单词数。若超过20/25个字的限制，则需将它们拆分。
- 在草稿中查找以下内容：缩写形式
'll、're、's，以及has been、have been、should、逗号或分号后的-ing动词形式。 - 查找所有的
if和when语句。它们应位于各自句子的开头，即命令之前。例如，“Increase the timeout if the network is slow”应改为“If the network is slow, increase the timeout.” - 查找在第三步任务中未选用的动词（即检查/验证/确认类动词）。将所有出现的此类动词替换为你选定的动词。
修正所有问题后即可提交结果。如需进行全面审核，可运行references/checklist.md文件。
完整示例
修改前（未经编辑的真实AI输出）：
连接超时问题。 如果sqlpipe出现挂起或报错“dial tcp: i/o timeout”，请检查运行sqlpipe的主机是否能够访问Postgres端口（通常为5432）——这往往是安全组或防火墙规则阻断了连接。如果你正在连接托管数据库（如RDS、Cloud SQL等），请确认该实例允许来自sqlpipe IP地址的连接。你还可以尝试增加配置文件中的
source.connect_timeout_seconds值，因为即使最终能够建立连接，缓慢的网络传输速度也可能会触发默认的超时设置。
修改后（结构化步骤说明，指定动词为“make sure”，先列条件，每句仅含一条指令）：
Make sure the host running sqlpipe can reach the Postgres port (usually 5432). Make sure any security groups or firewall rules are not blocking the connection. Make sure the target database instance allows connections from sqlpipe’s IP address. Make sure the appropriate timeout value is set in the configuration file.
连接超时。 当无法连接到 Postgres 端口（默认为 5432）时，sqlpipe 会因“dial tcp: i/o timeout”而停止运行。
- 确保运行 sqlpipe 的主机能够访问 Postgres 端口。防火墙或安全组通常会阻止此类访问。
- 如果数据库为托管类型（如 RDS、Cloud SQL），请确保相关实例允许来自 sqlpipe IP 地址的连接。
- 若网络速度较慢，请在配置中增加
source.connect_timeout_seconds的数值。
修改说明： 将原本40词的句子拆分为长度不超过20词的短句；将“you’re”展开为完整形式；将“check/confirm”统一简化为“make sure that”；确保每个条件都置于对应指令之前；删除了“etc.”；代码及错误信息保持不变。
适用范围
STE 仅用于提供技术性事实与操作指南。请勿将其用于营销文案、博客风格或品牌宣传内容——因其设计初衷即为去除说服性语言。当用户要求对营销文本进行 STE 处理时，应明确告知并建议其使用相关文档。
本工具仅为非官方辅助手段，既不隶属于 ASD 或 STEMG，也未获得其二者的认可，且没有任何工具能保证内容完全符合 STE 标准。ASD-STE100 是 ASD 的注册商标，官方标准文档可免费从 asd-ste100.org 下载。
参考资料
references/checklist.md—— 用于检查模式及最终审核，包含可搜索的模式及完整的验证清单。references/use-cases.md—— 提供错误信息、操作手册、事件报告、代码提交记录、用户界面文案及多语言翻译等长格式内容示例。