关于 asd-ste100
面向技术写作者和审校人员的技能,用于按 ASD-STE100 Issue 9 编写或检查文本。它强调保留技术含义,并按词性核对受控词汇。
主要功能
- 01将技术文本改写为 STE
- 02检查文本是否符合 STE
- 03区分程序性与描述性文本
- 04按词性核对词汇
- 05保留限定条件和技术含义
适用场景
- 01将维护步骤改写为 STE
- 02检查警告文本中的规则违规
- 03解释词典及写作规则
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ nuelcyoung/ asd-ste100 --skill asd-ste100安装后在 Claude Code 中输入/asd-ste100确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
LICENSEREADME.mdreferences/dictionary-access.mdbackground.mdpos-analysis.mdwriting-rules.mddictionary.mdchecklist.mdmeaning-fidelity.md详细介绍
ASD-STE100 简化技术英语(STE)
依据 ASD-STE100 第 9 版(2025 年 1 月)编写、改写和验证技术文本。STE 是由 ASD(欧洲航空航天、安全与国防工业协会)拥有的一种受控自然语言。它能让技术文本含义明确、易于理解和翻译。该标准分为两部分:9 个章节中的 53 条写作规则(第 1 部分),以及包含约 900 个获准词汇的受控词典(第 2 部分)。
STE 并非供学习者使用的简化英语。它是一项精确的标准,需要扎实的英语能力才能应用。它是对风格指南的补充,而不是替代品。
何时应用此技能
- 将现有技术文本(手册、规程、警告)改写为 STE
- 编写符合 STE 要求的新规程或说明
- 检查文本是否符合 STE 要求,并报告违规之处
- 解释 STE 规则、词典或标准
规则 0:含义高于词汇
在进行任何其他步骤之前:绝不要为了符合词典要求而改变技术事实、删除限定语、删除对象或虚构施事者。 STE 消除歧义,而不是删除内容。一个完全由获准词汇组成、但表达虚假或空洞内容的句子,比保留一个标记词的句子更糟糕。
这是 STE 改写中最容易出现的问题:文本看起来符合要求,读起来也似乎合理,实际却是错误的。请留意自己的输出是否有以下三种迹象:
- 替换为最接近的词。 “data that can be lost” → “data that can decrease”。
decrease是获准词汇,所以被拿来替换;但现在意思是错的。应改为重组句子:“the quantity of data that the system can lose”。 - 截掉对象。 “helps the platform to scale” → “helps the platform to increase”。增加什么?及物动词必须保留其对象,否则句子就没有表达任何意思。
- 删除保留语气。 “can be more important” → “is more important”。删掉情态动词会把带有限定的说法变成绝对说法。(而且
can是获准词汇——见下方动词规则。)
如果没有获准词汇能表达原意,请依次采取以下做法:重组句子;使用获准动词短语(get access to、make sure that、find the cause of);在项目词汇表中声明一个技术名词或动词;或者保留准确的词,并在交付内容中说明原因后标记该词。绝不要虚构词典规定来为替换行为辩解。
完整流程、易错情况表和五项忠实度检查:references/meaning-fidelity.md。每次改写都要加载该文件。
第 1 步:确定文本类型
每条规则都取决于文本是程序性文本还是描述性文本。写作前先分类。
| 程序(指令) | 描述(说明) | |
|---|---|---|
| 目的 | 告诉用户要做什么 | 解释事物如何运作,或发生了什么 |
| 语态 | 只能使用主动语态,采用祈使形式(“Install the pump”) | 尽可能使用主动语态;当施事者未知或不重要时,可以使用被动语态 |
| 句子长度限制 | 最多 20 个词 | 最多 25 个词 |
| 结构 | 每个句子一条指令 | 每段一个主题 |
不要在同一段文字中混用程序性写作和描述性写作。
绝不要为了避开被动语态而虚构施事者。 第 3.5 条要求描述性写作尽可能使用主动语态,而不是不惜任何代价地使用主动语态。如果原文说“backups should be taken frequently”,不要写成“the teams must make backups frequently”——原文从未提到团队,也没有把这项义务分配给他们。要么保留描述性被动语态(施事者未知),要么更常见的是,识别出这段文字其实是伪装成描述的程序,并使用祈使句:“Make backups frequently。”重新分类既能去掉被动语态,也能避免虚构施事者。
第 2 步:应用核心规则
一个词,一种含义,一个词性。 每个获准词都有一种获准含义和一个词性。某个词只有在特定词性下才获准使用。即使一个词在词典中,也仍可能违反句子中的用词规则。示例:
start(动词)获准使用;begin、commence、initiate不获准使用fall(动词)仅表示“因重力向下移动”,绝不表示“减少”check仅作为名词获准使用——写作“do a check of the valve”,绝不写“check the valve”about仅表示“与……有关”,绝不表示“大约”
仅限获准的动词形式: 不定式、祈使式、一般现在时、一般过去时、一般将来时,以及仅用作形容词的过去分词(“the installed component”)。
过去分词遵循其原形动词的规则。 只有当原形动词获准使用,或属于已声明的技术动词时,作形容词用的分词才有效。install(动词)获准使用,因此“the installed component”正确。require 未获准使用,因此“the required parts”不正确——即使它看起来像普通形容词。先将分词还原为不定式,再据此判定。名词化形式也遵循同一规则:install(动词)获准使用,并不代表 installation(名词)也获准使用。
情态动词和助动词——仅 can 和 must 获准;其余均不获准。
| 允许使用 | 用途 | 不允许使用 | 替换为 |
|---|---|---|---|
can(动词) | 能力或可能性:“you can get access to the jacks” | may、might、could | can,或说明条件:“If X, then Y” |
must(动词) | 义务:“you must have the necessary parts” | should、shall、ought to | must,或使用祈使句 |
will | 一般将来时 | would | 改写为一般现在时或使用 can |
从源句中删除 can 或 must 会改变句子所表达的主张。不要为了显得更“简化”而删掉它们——这违反规则 0,并非简化。
不得使用:
- 未获准的情态动词:may、might、could、should、would、shall
- 进行时或复杂动词结构(“must be installing”改为“install”)
- 将 -ing 形式用作动词——仅可将其用作技术名词(“the opening”)或技术名词内部的修饰语
- 操作步骤中的被动语态
- 省略句子成分——保留主语、动词和冠词
结构规则:
- 每句只写一条指令;每段只谈一个主题;每段最多 6 句
- 多词名词:最多 3 个词。这是上限,不是目标——保留合规的 2 词和 3 词组合(“database query times”、“application errors”),仅对包含 4 个或更多词、或容易产生歧义的组合使用介词短语。把每个短组合都改成
of结构,会让文字比原文更冗长 - 将条件放在命令之前:写“如果 X,就执行 Y”,而不是“执行 Y,如果 X”
- 对复杂步骤使用纵向列表
- 描述性文字中的句长和句式要有所变化(规则 6.5)。连续三句都使用相同句式(“The teams must...”)属于违规,而非中性文风
- 冠词既要保留,也要使用正确:不可数名词前不加
a/an(写“high CPU use”,而不是“a high CPU use”),泛指类别前不加the - 安全说明(WARNING、CAUTION、NOTE)必须以明确的命令或条件开头
拼写: 使用美式英语(Merriam-Webster)。将英式拼写转换为美式拼写(例如,将 colour 改为 color)。
技术名词和动词: 公司或领域专用术语(例如,“hydraulic pump assembly”、“to ream”)即使不在词典中,只要来自官方文档或词汇表,也允许使用。尽量少在其中使用未获准词语。
第 3 步:根据词性核对词典中的词语
词汇控制是 STE 审查中最常出问题的环节。仅使用简短的主动句并不足够。每个实义词都必须是获准词(具有一种获准词义和词性),或者是已声明的技术名词或动词。判定词汇时,不要只依赖记忆。
判断词语在句中的用法,绝不只看文本字符串。 只有当该词形列在词典中、其实际词性与词典条目相符,且词义符合唯一获准词义时,才算通过。不标注词性、只对照词表,是不合规文本最常通过审查的原因。例如,"Check all required dependencies" 这句话简短、主动且为祈使句,但仍违反了两项词典规定。完整的标注流程、派生形式规则,以及对该句的完整分析,请参阅 references/pos-analysis.md。请按以下顺序,使用最先可用的来源对照正式词典进行核验:
- 用户提供的官方 PDF(最佳来源)。 请用户提供其持有的 ASD-STE100 规范副本。该规范可从 asd-ste100.org 免费获取:依次进入 Downloads 和 Issue 9,并填写简短的申请表。如果用户提供文件路径或其副本的 URL,请使用 PDF 工具直接阅读第 2 部分(词典):搜索每个有疑问的词,然后应用格式规则——大写表示获准,小写表示不获准;第 2 列给出获准词义或大写形式的替代词。完整查询流程请参阅
references/dictionary-access.md。 - 网页抓取(有限用途)。 仅抓取 asd-ste100.org,以确认当前版本并向用户提供准确的申请页面。词典位于申请表后面,无法抓取。请勿使用网上找到的非官方镜像副本(存在版权和准确性风险)。
- 内置备用来源。 如果没有官方副本,请依据
references/dictionary.md(已知判定及高风险词汇表),并在交付内容中明确说明:"词汇仅依据已知判定和高风险模式进行核查,未对照 ASD-STE100 第 2 部分的官方词典。要完全合规,必须对照官方标准进行核验。"
任何改写或审查都必须遵循以下核验流程:
- 先建立术语表:列出源文本中用于指代每个事物的所有名称(例如,平台、应用程序、系统、软件包)。为每个事物选定一个名称——获准词或已声明的技术名词——记录下来,并在全文中统一使用。
- 从草稿中提取每个实义词(名词、动词、形容词、副词)的每次出现,而不是只提取唯一词项。同一个词在不同句子中可能具有不同词性,因此需要分别判定。排除已声明的技术名词和动词,以及获准的功能词。
- 根据上下文为每次出现标注词性。 留意单纯词表容易漏掉的形式:句首祈使句("Check the valve"——是动词,不是名词)、作动词使用的名词("torque the bolt")、作形容词的过去分词("the required parts")、-ing 修饰语,以及名词化形式。
- 将派生形式还原为词根,并先判定词根。 分词还原为不定式;名词化形式还原为动词;-ing 修饰语还原为其所属的技术名词。词根动词不合规时,其派生形式也不合规。
- 按上述词典来源查询每次出现,并标注词性(
check (n)、install (v)):该词是否列在词典中?词性是否相符?唯一词义是否相符?将判定记录为词项 + 词性——只写 "check: approved" 不算有效结论。 - 根据
references/dictionary.md检查高风险模式——含义模糊的量词、主观形容词、抽象名词化形式、依赖判断的指令。即使句子简短且为主动语态,这些模式仍会导致审查不通过。 - 替换或说明每个未通过的词项。在审查报告中,逐项列出不合规词项及其词性、判定结果和判定来源(官方词典或备用词表)。
步骤 4:转换并验证
将文本转换为 STE 的工作流:
- 盘点源段落中的命题:每个事实、关系和限定语。步骤 12 会根据此列表检查输出(
references/meaning-fidelity.md,第 1 遍) - 将每个段落归类为程序性或描述性内容
- 拆分超过 20/25 个词限制的句子。只拆分,不删除——要问哪个命题需要单独成句,而不是哪些词可以删掉
- 在存在实际执行者时,将被动语态改为主动语态;将未获批准的情态动词和进行时改为获准的动词形式。保留
can和must - 根据上下文标注每个实义词的词性,然后根据其词性核对每次出现的词是否在词典中,并执行术语表(步骤 3)
- 对每处替换执行安全检查:说明源词在上下文中的含义和候选词获准的含义;如果两者不同,就拒绝替换(第 2 遍)。留意反义词陷阱——
decrease不等于“失去”,stop不等于“失败”,find不等于“监控” - 删除含糊的量词和主观措辞;将判断改为“If X, do Y”决策规则(参见
references/dictionary.md中的高风险表格)。如果数量本来就可能变化,则使用“多于一个”,不要贸然采用其他未经核实的同义词 - 将抽象名词化表达改为带有源文提供的执行者的动词短语,或将其声明为技术名词。不要臆造执行者
- 将组合指令拆分为每句一条指令
- 将条件移至句首
- 补全省略的主语、动词和冠词,并检查新增的冠词:不可数名词前不加
a/an,泛指类别前不加the - 忠实度检查。 逐项对照第 1 步的命题清单与输出:内容全部保留、没有改动、没有臆造;所有保留措辞和及物动词的宾语都完整无缺
- 行文检查。 将输出作为文档而非句子来阅读。检查是否反复使用相同的句型框架、是否用合法的 2 词和 3 词名词组合重新构建了
of链,以及各段长度是否过于一致(第 4 遍) - 执行
references/checklist.md中的完整检查清单,然后报告仍然存在的违规项和所有标记为尚未解决的词
转换示例:
| 非 STE | STE |
|---|---|
| "Before acceptance of unit..." | "Before you accept the unit, do the specified test procedure." |
| "Rotate the cover until the jacks are accessible." | "Turn the cover until you can get access to the jacks." |
| "The unit must be installed carefully." | "Install the unit carefully." |
| "Check all required dependencies before you start the installation." | "Before you install the software, make sure that you have all the necessary dependencies." |
最后一行展示了词性问题:草稿简短、使用了主动语态和祈使句式,但仍然有两处错误——check 仅获准用作名词,而 required 是动词 require 的分词形式,该动词并未获准。若不进行词性标注,这两处错误都无法发现。
通过词数检查但仍不合格的改写:
| 看似合规的草稿 | 不合规原因 | 正确写法 |
|---|---|---|
| "the maximum quantity of data that can decrease after a failure" | 用 decrease 替换了“lost”。数据不会在故障中减少——现在定义是错误的(规则 0) | "the maximum quantity of data that the system can lose after a failure" |
| "This architecture helps the platform to increase." | 因删除了非批准词,及物动词的宾语也被删掉了。要增加什么? | "With this architecture, you can add more application instances when the load increases." |
| "A fast increase of the response latency is more important than a high CPU use." | 删除了 can be(表示不确定性的表达,且 can 是批准词);不可数名词“CPU use”前用了 a | "A quick increase in the response latency can be more important than high CPU use." |
| "The teams must do tests of the recovery procedures." | 为避免使用被动语态而臆造了施事者;该段内容是程序性说明 | "Test the recovery procedures." |
| "the times of the database queries" | 一个合法的 3 词词组被拆成了由 of 连接的结构 | "the database query times" |
检查(而非改写)文本时,请报告每处违规,并注明:违反的规则、违规文本、导致其违规的词性,以及合规的改写。
版权与准确性限制
- 本技能是非官方辅助工具,与 ASD 或 STEMG 无关联,也未获其认可。ASD-STE100 是 ASD 的注册商标。
- 完整词典(约 900 个批准词和约 1200 个非批准词)受 ASD 版权保护(欧盟商标 017966390)。请勿在交付内容中重现该词典。阅读用户合法获取的副本以核验词语,属于对该文档的正常使用。可引用个别裁定。请勿批量提取第 2 部分。有关权威信息,请引导用户访问 asd-ste100.org 上的免费官方标准。
- 任何工具(包括本技能)都无法保证符合 STE。最终批准始终由人工撰写者负责。交付已检查的文本时,请说明这一点。
- ASD/STEMG 不认可任何检查工具或非认证培训。
其他资源
参考文件
根据需要加载这些文件。默认情况下不要全部加载:
references/meaning-fidelity.md—— 完整的规则 0:五项忠实度检查(命题清单、替换安全性、臆造的 Agent、行文质量、信息损失)、反义词和易混淆项陷阱表、冠词和可数性规则、过度纠正名词组合的问题,以及一个完整示例。每次改写都要加载。references/writing-rules.md—— 详细说明 9 个规则部分:动词形式、句子结构、多词名词、安全说明、-ing 形式规则、操作步骤与描述references/pos-analysis.md—— 词性标注流程、派生形式规则(过去分词、-ing 形式、名词化、名词转动词)、已确认的词性判定、词性陷阱表、完整示例references/dictionary.md—— 4 列词典格式、查询技巧、已批准和未批准的判定、高风险词形模式表、技术名词和动词references/dictionary-access.md—— 如何通过官方第 2 部分词典核实词语:获取免费的官方 PDF、分级访问方式(本地 PDF、网页抓取、备用方案)、逐词和批量查询流程references/checklist.md—— 完整的合规检查清单(首先进行忠实度检查)、行文质量项目、最常见的写作错误,以及作者和组织的最佳实践列表references/background.md—— 历史、治理(STEMG)、Issue 9 的变更、行业采用情况、培训和认证、工具生态、常见误解,以及与其他受控语言的比较
对于改写任务,请加载 meaning-fidelity.md、writing-rules.md、dictionary.md、pos-analysis.md 和 dictionary-access.md。进行合规审查时加载 checklist.md。只有在询问该标准本身的问题时才加载 background.md。无论是改写还是审查,凡涉及词语层面的判定,都要加载 pos-analysis.md。切勿仅依据 dictionary.md 和 pos-analysis.md 进行改写——这两个文件会促使你进行替换,而 meaning-fidelity.md 能防止替换损害内容。