企业官网建设流程全解析

当AI开始"编造规则编号"：SimpleEnglish压力测试与自检机制深度揭秘

【免费下载链接】SimpleEnglishAgent skill: make LLMs write docs in ASD-STE100 Simplified Technical项目地址: https://gitcode.com/gh_mirrors/si/SimpleEnglish

你有没有让AI引用过一条"不存在的标准条款"？SimpleEnglish 是一个让大模型按航空业受控语言标准 ASD-STE100 写技术文档的 Agent 技能，而它最惊心动魄的发现来自压力测试：不带技能裸写的 AI 会自信地编造规则编号，把"Rule 3.1"说成短句规则，而真实编号完全不是这个意思。本文带你拆解 SimpleEnglish 的压力测试设计与三层自检机制，看看它是如何把"幻觉"关进笼子的 🎯

一、AI"编造规则编号"的瞬间：一个被记录下来的翻车现场

在 pressure-tests.md 里，有一条被永久记录的基线失败案例，值得每个使用 AI 写文档的人读三遍。

测试方法很简单：开一个全新的 Agent 会话，不带任何技能，直接问它："用 ASD-STE100 简化技术英语改写这段话，然后列出你引用的规则编号。"

结果，AI 交出了这样的答卷：

引用"Rule 3.1：短句子"和"Rule 4.2：主动语态"；同时保留被动语态，丢掉 "make sure" 后面的 "that"，还根本不知道 20/25 词的操作型/描述型分界线。

而真实的规则是：Rule 3.1 讲动词形式，Rule 4.2 讲"不得省略单词"。编号、内容，双双编造。

这就是大模型最典型的幻觉形态——不是不知道，而是听起来很有把握地胡说。更危险的是，这种胡说的编号格式完全正确，普通读者根本无从分辨。

二、为什么 AI 偏偏会编造"编号"？

编造规则编号不是偶然，而是三重因素叠加的必然结果：

1. 编号系统反直觉。ASD-STE100 共 9 大节、53 条编号规则，"4.2 管省略词"这种映射没有任何规律可循，模型靠语义猜测必然撞墙；
2. 训练语料里的编号多为噪声。模型见过海量"Rule 3.x""Rule 4.x"样式的文本，学会了格式却学不到映射；
3. 任务本身诱导自信。"列出你应用的规则编号"是一个要求确定性输出的指令，模型宁可编一个像样的编号，也不愿承认"我不知道"。

所以 SimpleEnglish 的作者在技能里写了一句堪称全项目最清醒的话（见 SKILL.md 第 36 行）：

"只引用本文件中真实存在的规则编号。不要从记忆中引用规则编号。编号是反直觉的，编造规则编号是一个已知失败模式。"

一句话定性：不信任模型的记忆，只信任白纸黑字的目录。

三、第一道防线：把真实规则编号"钉"在提示词里

针对编造问题，SimpleEnglish 的答案不是"教 AI 别编"，而是把 53 条规则的完整编号目录直接写进技能文件，让模型"照着抄"而不是"凭记忆说"。

规则目录（THE RULE CATALOG，SKILL.md 第 56 行起）按 9 节组织，每条都有编号和改写示例，比如：

加载技能后重跑同一个"引用规则编号"的压力场景，结果是：每一条被引用的编号都与目录一致——基线会话里编造编号的那个 AI，这次一条都没有编。

此外，技能还要求动笔前先做文本分类：操作型（procedural，≤20 词）还是描述型（descriptive，≤25 词）。这条分类步骤正是裸奔基线完全不知道的分界线，也是编号目录能落地的前提。

四、第二道防线：五步强制自检，"不可跳过"

光有目录还不够——模型可能看了规则却不执行。所以技能把自检做成了流程里不可跳过的一步（SKILL.md 第 33 行原文："This step is not optional."）。

交付前必须执行五项检查（SKILL.md 第 296 行起的 "Self-Check Before You Deliver"）：

1. 数句子：挑出最长的三句话数词数，超 20/25 上限就拆；
2. 机械搜索：全文搜缩写（'ll、're）、has been、should、分号、逗号后的 "-ing" 从句；
3. 条件位置检查：每个if/when必须站在句子开头；
4. 同义词轮换检查：搜出你"没选"的动词（check/verify/confirm/ensure 之间摇摆），统一替换成选定的那一个；
5. 列表机械检查：引导行有没有冒号、条目是否大写字母开头、有没有用逗号分号收尾。

更妙的是压力测试暴露过这套自检的漏洞并修掉了它：第一轮带技能测试中，AI 仍然在 check/confirm 之间轮换、漏了一个句尾条件。作者随即把"选动词"提前到动笔之前，并把"句尾条件"加入搜索清单——修订后全部通过。

自检清单不是写完的，是被失败喂出来的。

五、第三道防线：确定性自检 linter，让"干净"可计算

人会看走眼，提示词会被忽略，所以 SimpleEnglish 的最后一道防线是一个纯确定性、零依赖的 Python 检查器ste_lint.py。它用正则表达式扫描文本，把十类机械违规逐个数出来：

几个设计细节体现了工程诚意：

• 代码块和标识符先剥离再检查，--force这种 CLI 参数不会被误判成破折号（ste_lint.py）；
• 自带自测：python3 evals/ste_lint.py --self-test用一段"典型 AI 腔脏文本"和一段"干净文本"当夹具，断言前者必须报出一堆违规、后者必须为零；
• --gate模式：违规数大于 0 时退出码为 1，可以直接挂进 CI 当门禁；
• 诚实声明天花板：文件开头就写明它是正则扫描而非语法解析器，抓不到被动语态和词性问题，"数字可用于同一版本下的横向对比，但不构成合规判定"（ste_lint.py 第 1-19 行）。

六、压力测试怎么做：一套"先证明基线会死"的方法论

pressure-tests.md 的设计哲学值得单独拿出来看，因为它回答了一个更普遍的问题：如何证明一个提示词技能真的有用？

方法只有两句话：

1. 每条场景提示词在全新会话里跑两遍——不带技能（基线）与带技能；
2. 对照客观清单打分。而且文档里有一句狠话："如果某个标准在基线上就能通过，那它什么都证明不了；有价值的标准是基线会挂的那些。"

五个场景分别瞄准一种典型翻车：

• 场景 1（自然文档任务）：30-40 词长句、缩写、", making it easy" 从句、同义词轮换——AI 腔全家桶；
• 场景 2（引用规则编号）：就是本文开头的编造编号现场；
• 场景 3（"尽量短"压力）：诱饵是"电报体"——AI 为求短会丢掉冠词和 "that"，而 STE 恰恰禁止这种省法（Rule 4.2）。结果带技能的 AI 在极限施压下仍输出 "Make sure that a backup exists. Then run the migration." 并主动引用 Rule 4.2 作为理由；
• 场景 4（越界测试）：要求给营销落地页套 STE，考验 AI 会不会明知不合适也硬套；
• 场景 5（错误信息）：错误信息不许说 "Oops"、不许道歉，直接给修复命令。

这套方法还刻意避开了"自证"陷阱：判分标准是数得出来的（词数、缩写数、if 位置都是客观量），而不是一句"读起来更清楚了"。

七、规模化验证：7 模型 × 8 任务，112 次生成全量留底

单场景通过只是个案，SimpleEnglish 把验证规模拉到了矩阵级。run_bench.py 用无头 CLI 对 7 个 Claude 模型 × 2 种条件（基线/带技能）× 8 个写作场景逐一生成，每份输出立刻过 ste_lint 打分，原始 JSON 全部落盘在 evals/results/raw/，每一个报告数字都能从原始文件重算。

核心结果（RESULTS.md）：

项目同样诚实地写明了 caveat：linter 会少算（抓不到被动语态）、判官是单一模型可能存在家族偏好、每个单元格只跑了一次生成。想复现？python3 evals/run_bench.py一条命令；想给任意一批文本打分？python3 evals/score_text_dir.py <目录>，脚本见 score_text_dir.py。

八、三个可以搬回家的设计启示

这套压力测试与自检机制的真正价值，超出了"让 AI 写文档"本身：

1. 对抗幻觉，靠目录不靠说教。模型记不住的东西，就把它写进上下文让它照抄。"不要编造"这句话本身无效，"这里有一份真实编号表"才有效；
2. 自检要写成流程，而且先想好它会被怎么钻空子。"不可跳过"只是第一层；真正有用的是把已发现的绕过方式（动词轮换、句尾条件）逐一加进搜索清单；
3. 验证要用确定性工具 + 可复现留底。提示词会漂移、模型会换版本，但正则计数和原始文件不会。没有留底的"效果提升 75%"只是故事，有留底的才是证据。

下次当你的 AI 自信地甩出一条"Rule 3.1"时，你至少已经知道该怀疑什么了 🕵️

延伸阅读：完整检查清单见 checklist.md，AI 腔词替换表见 word-swaps.md，改写前后对照见 before-after.md。

【免费下载链接】SimpleEnglishAgent skill: make LLMs write docs in ASD-STE100 Simplified Technical项目地址: https://gitcode.com/gh_mirrors/si/SimpleEnglish