{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Simple English

把文本改写成 ASD-STE100 简化技术英语。

Skill 元数据
来源可选 — 通过 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
标签writing, documentation, ste, asd-ste100, technical-writing, editing, anti-ai-slop
相关 skillhumanizer

参考：完整 SKILL.md

INFO

以下是 Hermes 在触发本 skill 时加载的完整 skill 定义。这是 agent 在 skill 激活时所看到的指令内容。

Simple English：像航空手册一样写作

用 ASD-STE100 简化技术英语的规则写技术文本。STE 是航空航天和国防制造商写维护文档时用的受控语言。这些规则存在的意义，是让一个疲惫的、非英语母语的读者不会误读一条指令。它们顺带去掉了 AI 生成文本的常见痕迹：长句、同义词轮换、含糊措辞、填充词和装饰从句。

为那个疲惫的读者写作。每个句子都必须经得起一遍读。

如何在 Hermes 中使用

文本通常三种方式之一到达：

  1. 内联。 用户把文本贴进消息。就地改写并把结果回复。
  2. 文件。 用户指向一个文件（README、runbook、docs 页）。用 read_file 加载，然后用 patch 做针对性小节改写，或 write_file 做全文改写。绝不碰代码块、标识符或引用的错误信息（见不可碰项）。
  3. 检查模式。 用户让你审查文本是否符合 STE，而不是改写。用 references/checklist.md，把每条违规报告为：规则编号 + 违规文本 + 合规改写。

本 skill 与 humanizer 的区别：humanizer 恢复自然的人声；simple-english 为技术指令强制一套受控语言。文档、runbook、错误信息用本 skill。博客、散文、个人写作用 humanizer。不要把两者用在同一文本上。

你的任务

当被要求写或改写技术文本时：

  1. 选模式（下面的 pragmatics 或 strict）。
  2. 把每段分类为程序性或描述性。其他每条规则都依赖这个。
  3. 起草前先校准词汇。 strict 模式下，check/verify/confirm/ensure 概念用 make sure that——词典把这四个都作为动词拒了。pragmatic 模式选一个并保持。config/settings 选一个名词（都是合法技术名词——选一个并保持）。全文里这些概念不用其他词。
  4. 应用下面目录里的规则。
  5. 交付前做自检。 这一步不可选。
  6. 绝不碰代码、标识符、命令或引用的错误信息（见不可碰项）。

当被要求检查文本而非写它时，把每条违规报告为：规则编号、违规文本、合规改写。只引用本文件里存在的规则编号。不要凭记忆引规则编号：编号不直观，模型会编造（已测——一个没本文件的 agent 引了"Rule 3.1：短句"；真正的 Rule 3.1 是关于动词形式的）。

两种模式

模式何时应用什么
Pragmatic（默认）文档、README、错误信息——用户要清晰文本所有结构规则。领域词保留（"idempotent"、"webhook"）。
Strict用户点名 STE、ASD-STE100 或合规结构规则 + 完整词汇纪律，并告诉用户完整合规需要官方词典（asd-ste100.org 免费）。

第 1 步：给文本分类

程序性（指令）描述性（解释）
目的告诉读者做什么解释一个东西是什么或做什么
动词形式祈使："Install the pump."一般现在/过去/将来
句子上限20 词（规则 5.1）25 词（规则 6.3）
单元规则每句一条指令（5.2）每段一个主题（6.5），每段最多六句（6.6）

不要在一段里混用两者。"Getting started" 节是程序性。"Architecture" 节是描述性。过程里的一条 note 是描述性（25 词上限，无祈使）。

规则目录

9 节 53 条规则，按 ASD-STE100 Issue 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用美式英语拼写。

pragmatic 模式下，规则 1.5、1.8、1.12 挑大梁：你的领域词汇是合法的。agent 常违反的是 1.7、1.11、1.13。

之前： You can webhook the event, then do a deploy. 之后： Send the event to the webhook. Then deploy the service.

第 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"；建议陈述为事实或删掉。这对 agent 指令加倍重要——模型把 "should" 读成可选。

之前： The migration has completed and the table is being rebuilt. 之后： The migration is complete. The database rebuilds the table.

之前： The flag can be set in the config file, making restarts unnecessary. 之后： You can set the flag in the config file. Then a restart is not necessary.

之前： The temperature must be adjusted. 之后： Adjust the temperature.

第 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 是反电报腔规则。STE 是语法完整的短句，不是电报体：

错误缩短： Ensure file exists before running. STE： Make sure that the file exists before you run the command.

第 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.5note 给信息，绝不指令。note 用 25 词上限。

之前： You'll want to grab the API key from the dashboard before configuring the client, which you can do under Settings. 之后： Get the API key from the dashboard, under Settings. Then configure the client with this key.

第 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 选项。

之前： Note that data loss may occur in some circumstances if the destructive flag happens to be enabled when running against production. 之后： CAUTION: Do not use the --force flag against production. The flag deletes rows that do not match the source.

第 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 批准词，约 1200 禁用词带替代）版权归 ASD，不在此复刻。其机制无需词典也适用：一个词，一个意思，一个词性。

已知的词性裁定，可作模式：

词裁定
test, check, work仅名词。"Do a test"，不是 "test the pump"。"Check that X" 变 "make sure that X"。
oil仅技术名词（TN）。动词用词典给的 "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 is better because Y."
may / might / could（可能性）can
may（许可）can
would（假设）重构："If X occurs, Y occurs."

套路到简朴的替换表

这张表是我们的，不是 ASD 词典。它把 AI 文档过度使用的词映射到平实替代。若该词不承载事实，删掉而非替换。

套路改写为
leverage, utilizeuse
in order toto
prior tobefore
ensuremake sure that（strict 模式；pragmatic 模式下，ensure 若是你选定的那个 check 动词则可用）
it is worth noting that（删）
it's important to, crucially（删——陈述事实）
simply, just, easily, seamlessly, effortlessly（删）
robust, powerful, comprehensive, performant（删，或给可度量属性）
functionalityfunction, feature
enables you to, allows you toyou can
is designed to, aims to（删——说它做什么）
facilitatehelp, make possible
dive into, delve intoread, examine
when it comes tofor
in the event thatif
due to the fact thatbecause
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 boxby default
under the hoodinternally
blazingly fast, state-of-the-artfast（给数字）/（删）
streamlinemake simpler, make faster
plethora, myriadmany
addresses the issue, tacklescorrects the fault, removes the error

一致性过一遍

把同义词轮换各归约成一个词（规则 1.11、9.4）。下面两张表用法不同。

技术名词——不在词典里。选一个并保持一致（两种模式）：

  • config / configuration / settings / options → 选一个

词典裁定——标准已经选好。用批准词（strict 模式）；选一个并保持一致（pragmatic 模式）：

你写了词典状态改用
check（动词）/ verify / confirm / ensure都作动词拒了make sure that（strict）；选一个（pragmatic）
validate不在词典作技术动词用（规则 1.12），或换 make sure that
delete / drop（动词）/ destroy都拒了erase（数据）、remove（物理）；避 drop 和 destroy
remove批准动词保留
run / execute都拒了run 用 operate，execute 用 do（strict）；选一个（pragmatic）
invoke / launch不在词典作技术动词用（规则 1.12）
display（动词）/ render / present（动词）都拒了show（批准动词）
issue不在词典作技术名词用，或换 problem（批准）
failure一般用法拒；作性能损失的 TN 批准仅当指性能错误时用："a failure of the pump"
error批准名词保留
problem批准名词保留

不可碰项

这些是技术名（规则 1.5、8.6）。即使违反词汇规则也原样保留：

  • 代码块、行内代码、标识符、CLI 命令、标志、文件路径
  • 引用的错误信息和日志行
  • 产品名、API 端点名、配置键
  • 带单位数字——在句子上限里各算一个词

文档之外

同套规则，不同对象。完整适配见 references/use-cases.md：

  • 错误信息：说发生了什么（一般过去），已知原因则说，然后祈使给修法。无"Oops"、无"Please ensure"、无道歉填充。
  • Runbook：STE 的主场。祈使步骤，条件在前，警告在步骤前。
  • 事故报告：仅一般过去。"We have identified an issue that may have impacted" 变 "Between 14:02 and 14:31 UTC, 12% of requests failed."
  • 发布说明：破坏性变更走警告模式——命令在前，风险在后。
  • agent 指令（提示词、AGENTS.md）：系统提示是给不能提问的读者的过程。每句一条指令，无"should"，条件在前。
  • 翻译准备：STE 的本职。一词一义加完整语法消除多数翻译歧义。

交付前自检

这一步不可选。对你的草稿跑这四项检查：

  1. 数你最长三个句子的词。超过 20/25 上限 → 拆。
  2. 在草稿里搜：'ll、're、's（缩写）、has been、have been、should、逗号后的 -ing 动词、分号。
  3. 搜每个 if 和 when。每个都站在句首、命令前。"Increase the timeout if the network is slow" → "If the network is slow, increase the timeout."
  4. 搜你在"你的任务"第 3 步没选的动词（check/verify/confirm 那组）。把每个命中换成你选的动词。

修掉发现的问题，再交付。完整审查跑 references/checklist.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. You can also try increasing source.connect_timeout_seconds in your config, since a slow network path can trip the default timeout even when the connection eventually succeeds.

之后（分类为程序性，动词 = "make sure"，条件在前，每句一条指令）：

Connection timeouts. sqlpipe stops with dial tcp: i/o timeout when it cannot reach the Postgres port (5432 by default).

  1. Make sure that the host that runs sqlpipe can reach the Postgres port. A firewall or security group usually blocks it.
  2. If the database is managed (RDS, Cloud SQL), make sure that the instance accepts connections from the IP of sqlpipe.
  3. If the network is slow, increase source.connect_timeout_seconds in the configuration.

改了什么：40 词句子拆到 20 以下；"you're" 展开；"check/confirm" 归约为 "make sure that"；每个条件移到命令前；删 "etc."；代码和错误串原样。

局限

STE 用于技术事实和指令。别用在营销文案、博客声口或品牌写作上——它按设计删掉说服力。当用户要把 STE 用在营销文本上，说明这点，转而提议用在文档上。

本 skill 是非官方辅助。它不隶属 ASD 或 STEMG，也不受其背书，没有工具能保证 STE 合规。ASD-STE100 是 ASD 的注册商标。官方标准可在 asd-ste100.org 免费下载。

参考

  • references/checklist.md——带可搜索模式的完整验证过一遍，用于检查模式和最终审查
  • references/use-cases.md——长-form 适配：错误信息、runbook、事故报告、commit、UI 文案、i18n