Community写作与编辑github.com

ASD-STE100 简化技术英语

根据 ASD-STE100(第9版)简化技术英语规范编写、检查与编辑文档。当用户提及 STE、ASD-STE100、简化技术英语、受控语言,或要求编写/改写程序、操作说明、维护任务、手册、操作指南、用户手册或安全警告,以确保文本清晰、易于翻译或适合非英语母语者阅读时使用。也可用于审计或审查现有文档是否符合 STE 规范。

ASD-STE100 简化技术英语 是什么?

该技能旨在帮助用户严格遵循 ASD-STE100(第9版)规范编写、检查或编辑技术文档。STE(简化技术英语)是一种受控语言,包含53条写作规则以及一个约900个批准词汇的词典,每个词只有一种含义和一种词性。其核心目标是确保英语能力有限的读者或翻译人员对每句话的理解只有一种方式,从而消除歧义。 该技能支持三种工作模式:编写(从笔记或事实创建新文档)、检查(对现有文档生成违规报告而不进行修改)和编辑(将现有文档改写为符合 STE 规范的新文档并提供变更摘要)。它内置了 `scripts/ste_check.py` 检查脚本(仅依赖 Python 3 标准库),能够自动发现可程序化的违规项,但用户需要手动检查脚本无法发现的问题,如长复合名词、错误含义、冠词缺失等。 该技能同时提供了详尽的规则参考(references/rules.md 和 references/dictionary.md),列出了最易导致违规的11条核心规则,并配有大量正反示例。它强调在改写时不能仅做词语替换,而需要重构句子结构。技能还规定了处理非散文文本(代码、命令、路径等)的方式、词汇审批的决策顺序、以及大写规则等。 用户交互方面,该技能要求所有输出(包括建议修改、变更摘要和注释)本身也必须符合 STE 规范,避免教导错误的用法。它反对做出“文档已认证”等绝对性声明,建议在需要正式合规要求时由经过 STE 培训的人员进行评审。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Free-cat/simplified-technical-english/tree/HEAD/skills/ste100

Installed? Explore more 写作与编辑 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

ASD-STE100 简化技术英语 是做什么的?

STE 是一种受控语言:包含 53 条写作规则和约 900 个批准词汇的词典,每个词只有一种含义和一种词性。其目的是让英语能力有限的读者或翻译人员能够以唯一的方式理解每个句子。

选择工作类型

工作类型用户提供您返回
编写笔记、事实、大纲或请求一份新的 STE 文档
检查一份现有文档一份发现报告。不进行重写。
编辑一份现有文档一份 STE 文档,以及变更摘要

如果请求不明确(例如“看一下这个文档”),则执行检查并提供编辑选项。

资源

  • references/rules.md —— 全部 53 条规则及示例。在检查或编辑工作时阅读,并在不确定某条规则时查阅。
  • references/dictionary.md —— 未批准的词汇及批准的替代词、词性陷阱、技术名词和技术动词类别,以及软件文本相关章节。每项工作都要阅读。大多数违规都是词汇选择问题。
  • scripts/ste_check.py —— 查找程序能够发现的违规项。运行它,不要阅读其代码。仅依赖 Python 3 标准库。它会读取一个文件并打印发现结果。它不会更改文件,也不会使用网络。
python3 scripts/ste_check.py <文件> [--type auto|procedure|description] [--terms terms.txt] [--json]

--terms 选项接受一个文件,文件中每行包含一个技术名词或动词(例如 press, torque)。脚本将不再报告这些词汇。

该脚本只是初步检查。它无法发现较长的多词名词、错误含义、缺失的冠词或不一致的术语。它也会报告一些正确的文本(过去分词用作形容词时看起来像被动语态)。请检查每个发现结果。

最容易导致违规的规则

  1. 批准词汇(1.1–1.3)。 使用词典中的词汇及其批准的词性和含义。Check 和 test 是名词(写作“Do a check of…”、“Make sure that…”)。Close 是动词(表示“附近”时写作 "near")。
  2. 技术名词和动词(1.5–1.13)。 学科领域词汇来自词典之外:零件、工具、材料、软件对象、单位(名词),以及具体过程如 drill、weld、click、deploy(动词)。对同一事物使用同一术语。一般动词(verify、perform、utilize)永远不能作为技术动词。
  3. 动词形式(3.1–3.5)。 不定式、祈使式、一般现在时、一般过去时、一般将来时以及用作形容词的过去分词。禁止使用完成时(“has failed”)、进行时(“is running”)以及 -ing 形式,除非它是技术名词(例如 "bearing"、"operating temperature")。
  4. 情态动词。 只能使用 CAN 和 MUST。禁止使用 should, may, might, could, would, shall。
  5. 主动语态(3.6)。 程序中始终使用主动语态。在描述中,仅当动作者未知或不重要时才允许使用被动语态。
  6. 句子长度(5.1, 6.3)。 程序句:20 个单词。描述句:25 个单词。代码、带单位的数字、标签以及括号内的文本各计为一个单词。
  7. 每个句子一个指令(5.2–5.4)。 写一个命令。仅当两个动作同时发生时才能合并。将条件放在前面,然后加逗号。
  8. 不要省略单词(4.2, 4.5)。 保留冠词和“that”。不使用缩写。
  9. 多词名词(2.1)。 最多三个名词。较长的名词串用“of”、“for”、“that”或连字符分隔。
  10. 安全提示与注释(7.1–7.3, 5.5)。 警告或注意以命令或条件开头,说明风险,并放在其适用的步骤之前。注释仅提供信息。如果注释包含指令,则将其改为步骤。安全文本遵守相同的动词规则:“The threads can become damaged”或“This can cause damage to the threads”,而不是“The threads can be damaged”。
  11. 段落(6.4–6.6)。 一个主题,主题句在前,最多六个句子。对于三个或更多并列项,使用垂直列表(4.3)。不使用分号(8.1)。

改变句子结构,而不仅仅是词汇(9.1)。 STE 不是同义词互换。

非 STE差(词汇替换)STE
The system should be allowed to cool down prior to commencing disassembly.The system must be let to cool before start disassembly.Let the system become cool. Then, disassemble the unit.
Having confirmed the valve is closed, proceed with removal of the pump.After you made sure the valve is closed, continue with removal of the pump.Make sure that the valve is closed. Then, remove the pump.
The cache may need to be cleared if stale data is displayed.The cache must possibly be cleared if old data is shown.If the page shows old data, clear the cache.

所有三种工作类型均适用的原则

准确性优先。 STE 改变的是如何表达,而不是表达什么。保留每个事实、数值、公差、条件和范围限制。不要添加源文件中未包含的步骤、警告或数值;将可能的差距列为开放式问题。

不要默默猜测。 如果源文件表述含糊(例如“check the oil”——是指液位还是状况?),选择最可能的含义,并将其列为开放式问题。保持列表简短:只列出那些答案会改变文本的问题。三个好问题可以得到答案,十个则不会。

非散文文本保持不变: 代码、命令、路径、UI 标签、零件号、标牌文字、引用文字、法律文字。

不在 dictionary.md 中的词汇。 该文件只是一个子集,因此大多数词汇都不在其中。按以下顺序判断,且不要列出普通词汇“以待确认”:

  1. 它是否在未批准的表中?使用替代词。
  2. 它是否表示该学科领域的一件事物或一个特定过程?则它是技术名词或技术动词。使用它,并保持一致。
  3. 是否有一个你知道更简单的已批准词汇(核心动词列表,或 STE 示例中的词汇)?使用那个词汇。
  4. 如果以上都不满足,且该词含义简单明了,则使用它。仅当选择错误可能改变含义时才标记一个词汇。

大写字母。 词典文件以大写形式显示已批准词汇,这只是一种表示方式。在文档和报告文本中应使用正常大小写(写“use must”,而不是“use MUST”)。

您为用户编写的所有内容也必须是 STE: 建议修正、变更摘要和注释。一个本身存在违规的修正(例如“is usually done by deploying…”)会教会错误的用法。给出文件名,而不是完整的文件系统路径。

声明。 不要说文档已获得认证或完全合规。应说明您是根据 STE 规则编写或检查的。用一句话简要说明词典的限制,并且只说一次。如果合规是合同要求,建议由经过 STE 培训的人员使用官方规范(可从 asd-ste100.org 免费索取)进行评审。

工作流程:编写

  1. 将每个部分识别为程序(读者要执行操作)或描述(读者要了解知识)。两者的限制不同。
  2. 建立术语表:每件事物对应一个技术名词,每个过程对应一个动词。如果用户有术语表,则使用其术语。
  3. 撰写初稿。
    • 程序:编号步骤,每条一个命令,条件在前。将每个警告或注意紧邻其对应的步骤之前,每个注释在其对应的步骤之后。
    • 描述:短段落,主题句在前。
    • 标题:使用简短的名词短语或命令(例如“Start the unit”),不要使用 -ing 形式。
  4. 运行 scripts/ste_check.py。修正发现的违规项。再次运行。直到每个保留下来的发现结果都是您已检查并接受为止。
  5. 通读初稿,检查脚本无法发现的问题:多词名词、词性、冠词、同一事物使用同一术语、每个步骤只有一个指令。
  6. 交付文档。之后,在回复中(或分隔线下方,标记为作者注释),给出:
    • 来自词典之外的技术名词和动词(不是诸如 remove 或 install 之类的批准词汇);
    • 开放式问题。

工作流程:检查

  1. 阅读 references/rules.md 和 references/dictionary.md。
  2. 对文档运行 scripts/ste_check.py。
  3. 检查发现结果并排除误报。然后通读文档,检查脚本无法发现的问题(编写步骤 5),以及结构问题:警告的位置、注释中的指令、包含多个操作的步骤。
  4. 按以下结构编写报告。保持简短以便于操作:每个有问题的句子一行,对于在多个位置重复出现的问题也各占一行。
# STE 报告:<文件名>

## 摘要
<3-5 句话:文本类型、总体水平、需首先修正的三个最重要问题。>

| 规则 | 主题 | 发现数 |
|---|---|---|
| 1.1 | 未批准词汇 | 12 |

## 发现结果
| # | 位置 | 规则 | 原始文本 | 问题 | 建议的 STE 文本 |
|---|---|---|---|---|---|
| 1 | 步骤 2 | 3.6, 1.1 | "The cover should be removed" | 被动语态。"should" 未批准。 | "Remove the cover." |

## 开放式问题
<仅当存在时才列出。最多五个。>

报告规则:

  • 每行给出一个或多个规则编号。准确引用原始文本。
  • 每行都给出修正,并确保修正遵守规则(长度、动词形式、主动语态、批准词汇)。
  • 如果标题包含三个或更少的名词,则不要将其报告为长句或多词名词。
  • 如果安全提示的级别看起来不正确(例如,对数据丢失使用了“警告”),在行中指出。WARNING 用于人身伤害,CAUTION 用于损坏或数据丢失。
  • 不要包含您如何制作报告(脚本计数、排除的误报、“限制”部分)。在摘要中用一句话说明词典的限制即可。
  • 除非用户要求,否则不要重写整个文档。

工作流程:编辑

  1. 执行检查步骤 1–3。发现结果是您的工作清单,而不是交付物。
  2. 重写文档。保留结构、标题、数字和所有技术内容。拆分长句和多操作步骤。将每个警告或注意移至其对应步骤之前。将注释中的指令改为步骤或安全提示。
  3. 对结果运行 scripts/ste_check.py。修正并再次运行脚本,如同编写步骤 4。
  4. 以与源文件相同的格式交付文档。然后给出简短的变更摘要:主要的变更类型,每种类型带一个“前后”对比示例,每次更改结构或陈述强度的地方(例如 “should” 改为 “must”,注释改为步骤),以及开放式问题。除非用户要求完整的变更日志,否则不要列出每个被更改的句子。

相关技能