mcpField
A
asd-ste100

asd-ste100

github.com/nuelcyoung文档处理4142 次安装10 周前更新
代码仓库

关于 asd-ste100

面向技术写作者和审校人员的技能,用于按 ASD-STE100 Issue 9 编写或检查文本。它强调保留技术含义,并按词性核对受控词汇。

主要功能

  1. 01将技术文本改写为 STE
  2. 02检查文本是否符合 STE
  3. 03区分程序性与描述性文本
  4. 04按词性核对词汇
  5. 05保留限定条件和技术含义

适用场景

  1. 01将维护步骤改写为 STE
  2. 02检查警告文本中的规则违规
  3. 03解释词典及写作规则

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/nuelcyoung/asd-ste100 --skill asd-ste100

安装后在 Claude Code 中输入/asd-ste100确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

LICENSE
README.md
references/
dictionary-access.md
background.md
pos-analysis.md
writing-rules.md
dictionary.md
checklist.md
meaning-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、couldcan,或说明条件:“If X, then Y”
must(动词)义务:“you must have the necessary parts”should、shall、ought tomust,或使用祈使句
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。请按以下顺序,使用最先可用的来源对照正式词典进行核验:

  1. 用户提供的官方 PDF(最佳来源)。 请用户提供其持有的 ASD-STE100 规范副本。该规范可从 asd-ste100.org 免费获取:依次进入 Downloads 和 Issue 9,并填写简短的申请表。如果用户提供文件路径或其副本的 URL,请使用 PDF 工具直接阅读第 2 部分(词典):搜索每个有疑问的词,然后应用格式规则——大写表示获准,小写表示不获准;第 2 列给出获准词义或大写形式的替代词。完整查询流程请参阅 references/dictionary-access.md。
  2. 网页抓取(有限用途)。 仅抓取 asd-ste100.org,以确认当前版本并向用户提供准确的申请页面。词典位于申请表后面,无法抓取。请勿使用网上找到的非官方镜像副本(存在版权和准确性风险)。
  3. 内置备用来源。 如果没有官方副本,请依据 references/dictionary.md(已知判定及高风险词汇表),并在交付内容中明确说明:"词汇仅依据已知判定和高风险模式进行核查,未对照 ASD-STE100 第 2 部分的官方词典。要完全合规,必须对照官方标准进行核验。"

任何改写或审查都必须遵循以下核验流程:

  1. 先建立术语表:列出源文本中用于指代每个事物的所有名称(例如,平台、应用程序、系统、软件包)。为每个事物选定一个名称——获准词或已声明的技术名词——记录下来,并在全文中统一使用。
  2. 从草稿中提取每个实义词(名词、动词、形容词、副词)的每次出现,而不是只提取唯一词项。同一个词在不同句子中可能具有不同词性,因此需要分别判定。排除已声明的技术名词和动词,以及获准的功能词。
  3. 根据上下文为每次出现标注词性。 留意单纯词表容易漏掉的形式:句首祈使句("Check the valve"——是动词,不是名词)、作动词使用的名词("torque the bolt")、作形容词的过去分词("the required parts")、-ing 修饰语,以及名词化形式。
  4. 将派生形式还原为词根,并先判定词根。 分词还原为不定式;名词化形式还原为动词;-ing 修饰语还原为其所属的技术名词。词根动词不合规时,其派生形式也不合规。
  5. 按上述词典来源查询每次出现,并标注词性(check (n)、install (v)):该词是否列在词典中?词性是否相符?唯一词义是否相符?将判定记录为词项 + 词性——只写 "check: approved" 不算有效结论。
  6. 根据 references/dictionary.md 检查高风险模式——含义模糊的量词、主观形容词、抽象名词化形式、依赖判断的指令。即使句子简短且为主动语态,这些模式仍会导致审查不通过。
  7. 替换或说明每个未通过的词项。在审查报告中,逐项列出不合规词项及其词性、判定结果和判定来源(官方词典或备用词表)。

步骤 4:转换并验证

将文本转换为 STE 的工作流:

  1. 盘点源段落中的命题:每个事实、关系和限定语。步骤 12 会根据此列表检查输出(references/meaning-fidelity.md,第 1 遍)
  2. 将每个段落归类为程序性或描述性内容
  3. 拆分超过 20/25 个词限制的句子。只拆分,不删除——要问哪个命题需要单独成句,而不是哪些词可以删掉
  4. 在存在实际执行者时,将被动语态改为主动语态;将未获批准的情态动词和进行时改为获准的动词形式。保留 can 和 must
  5. 根据上下文标注每个实义词的词性,然后根据其词性核对每次出现的词是否在词典中,并执行术语表(步骤 3)
  6. 对每处替换执行安全检查:说明源词在上下文中的含义和候选词获准的含义;如果两者不同,就拒绝替换(第 2 遍)。留意反义词陷阱——decrease 不等于“失去”,stop 不等于“失败”,find 不等于“监控”
  7. 删除含糊的量词和主观措辞;将判断改为“If X, do Y”决策规则(参见 references/dictionary.md 中的高风险表格)。如果数量本来就可能变化,则使用“多于一个”,不要贸然采用其他未经核实的同义词
  8. 将抽象名词化表达改为带有源文提供的执行者的动词短语,或将其声明为技术名词。不要臆造执行者
  9. 将组合指令拆分为每句一条指令
  10. 将条件移至句首
  11. 补全省略的主语、动词和冠词,并检查新增的冠词:不可数名词前不加 a/an,泛指类别前不加 the
  12. 忠实度检查。 逐项对照第 1 步的命题清单与输出:内容全部保留、没有改动、没有臆造;所有保留措辞和及物动词的宾语都完整无缺
  13. 行文检查。 将输出作为文档而非句子来阅读。检查是否反复使用相同的句型框架、是否用合法的 2 词和 3 词名词组合重新构建了 of 链,以及各段长度是否过于一致(第 4 遍)
  14. 执行 references/checklist.md 中的完整检查清单,然后报告仍然存在的违规项和所有标记为尚未解决的词

转换示例:

非 STESTE
"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 能防止替换损害内容。

评论

支持 Markdown