AI写东西有个通病:动不动就是"无缝对接""得益于强大架构",报错信息永远是"抱歉,似乎出现了问题,请稍后重试"。GitHub上一个叫SimpleEnglish的开源项目盯上了这个毛病,给AI装了一套写作紧箍咒——不是自创规则,而是直接搬来1983年航空业定下的ASD-STE100简化技术英语标准,那套让疲惫的飞机维修工不会看错说明书的语言规范。项目作者说,在6个Claude模型、96次生成测试里,套上这套规则后,AI的写作违规率平均降了72.9%。
举个原项目给的例子最直接:同一个模型,不套规则时把数据库连接失败写成"抱歉,似乎出现了问题,请检查您的凭据并重试";套上规则后变成"连接数据库失败:用户app的密码不正确。将DB_PASSWORD设置为正确的值,然后重新连接。"前者是客服话术,后者是能照着做的说明书。
这套规矩从哪来的
ASD-STE100不是为AI设计的。它是航空制造业1983年定下的受控语言标准,专门写给维修手册和操作说明,现行版本是2025年1月的Issue 9,由行业组织ASD维护——目的很单纯:让读者不可能理解错。核心规矩不多但很硬:
- 每句指令最多20个词,描述句最多25个词
- 一个词只能有一个意思,全文统一(不能"检查""核实""确认"轮着换着用)
- 只用简单时态,不用被动语态,不用"-ing"结构
- should/would/may/might这类模糊情态词禁用,can/will/must可以留
- 条件从句要放在指令前面,不能读者做到一半才发现有前提
SimpleEnglish把53条规则打包成一个Agent Skills技能,兼容Claude Code、Cursor、VS Code Copilot、OpenAI Codex、Gemini CLI等约30种支持这套标准的工具,一行npx skills add命令就能装,不依赖任何库,MIT协议开源。不支持技能安装的工具比如ChatGPT网页版,也能把系统提示词整段贴进自定义指令里用,只是没有原生技能加载那么顺手。
72.9%是怎么算出来的
数字扎眼,但得看清口径。测试范围是6个Claude模型(从opus-4-8到sonnet-4-6)×8种写作任务×2种条件,一共96次生成,用同一套确定性正则检测器给两边打分,降幅从41%到82%不等,平均72.9%。
项目自己也说清楚了:这是自测,不是第三方复核;检测器是根据自家规则写的正则表达式,不是STE官方审定的判定标准。降幅也不齐——表现最弱的opus-4-8只降了41%,不到平均值的六成。换成别的模型、别的语言(比如中文),会是什么结果,目前没有数据。
- 风险.72.9%是项目自测的平均数,单个模型、单次任务的实际降幅可能低得多,也没有跨模型、跨语言的独立复现。
我的判断
治得了句子的毛病,治不了内容的病。
这个项目真正做对的一件事,是把"写清楚"从一句没法验证的夸奖,变成了一条能用正则表达式检查的规格。你让AI"写清楚一点",它给你的是主观判断;你告诉它"一句不超过20个词、一词一义、条件在前",它至少能对着规则改。这对写报错信息、运行手册、事故报告这类容错率极低的文档,是实打实的改进——原项目给的例子里,"我们注意到一个可能影响部分用户使用体验的问题,对此带来的不便深表歉意"这种公关话术,被换成了"14:02到14:31之间,12%的请求失败,起因是14:00的一次部署删掉了缓存预热步骤,14:27已回滚"。后者才是工程师真正想看到的东西。
但这套规则解决不了AI最要命的毛病:它不知道自己在瞎说。句子变短、用词变准,不代表内容变对。项目自己测试时就撞见过这种情况:没套技能的基线模型不仅写40词的长句,还自信地引用了一条"3.1条:句子要短"的规则,而真正的3.1条讲的是动词形式,跟句子长短毫无关系。控制句法管得住嘴,管不住脑子里的事实错误。
也别指望它能通吃所有场景。项目自己划了红线:不做STE认证,因为ASD根本不认证任何工具;不适用于营销文案、品牌文案、博客口吻,连它自己的README都被点名"违反了一半规则",因为宣传语本来就不在STE的管辖范围里。
对写代码报错、运行手册、事故复盘的团队,这是个便宜好用的紧箍咒。对写产品文案、发布通稿的人,它压根不想管你。