别再让 AI「写清楚点」了：Karpathy 用一份 40 年前的航空规范，治好了大模型的废话

你有没有过这种体验：让 AI 帮你写一段操作说明，它洋洋洒洒回你八百字，读完却比不看还晕。问题往往不在内容，而在表达——车轱辘话、模糊的情态词、一句话里塞进三个动作。前特斯拉 AI 总监 Andrej Karpathy 给出了一个反直觉的解法：别再说「写清楚点」，直接让模型遵守一份 40 年前的航空规范。

一分钟速览

• Karpathy 推荐用 ASD-STE100 受控语言来约束大模型的输出
• ASD-STE100 是 1983 年欧洲航空航天协会为飞机维修手册制定的「简化技术英语」，约 900 个批准词、53 条写作规则、约 1200 个禁用词
• 核心规则：一句一个指令、指令句不超过 20 词、只用 can/will/must、一个词只有一个含义
• 开源项目 SimpleEnglish 实测：6 个 Claude 模型、8 项写作任务、96 次生成，STE 违规平均减少 72.9%
• 用法极简，提示词里加一句「Use ASD-STE100」即可

为什么是航空手册？

ASD-STE100（Simplified Technical English，简化技术英语）诞生于 1983 年，服务对象是飞机维修手册。维修手册要交给来自不同国家、英语水平参差不齐的技术人员使用——一句话如果存在两种理解，后果可能就是机毁人亡。于是它把语言压缩到极端可控的状态：词汇表里每个词只有一个含义、一个词性，写作规则则把句长、时态、语态全部规定死。

这套规则恰好戳中 AI 的毛病

把 STE 的规则摊开看，你会发现它逐条对应着大模型的「老毛病」：

• 句长限制（指令句≤20 词、描述句≤25 词）——专治车轱辘话和绕来绕去的长难句
• 一词一义——不再出现 check、verify、confirm、validate 混着用的情况
• 禁用 -ing 与完成时——砍掉「has been updated」这类迂回表达
• 只用 can/will/must——禁用 should、would、may、might，消灭「或许」「大概」「建议」式的模糊 hedge
• 条件前置——先说「如果 X」，再说「做 Y」，避免读到句尾才发现前提
• 词汇替换——utilize 换成 use，prior to 换成 before，commence 换成 start

实测：废话少了七成

开源项目 SimpleEnglish 对这套方法做了系统测试：覆盖 6 个 Claude 模型、8 项写作任务、共 96 次生成，结果 STE 规则违规平均减少 72.9%，各模型区间在 41% 到 82% 之间。项目作者的一句话总结颇为传神——「AI slop 作为副作用一起死掉了。」

怎么用？两种模式

落地时不必一刀切，可以分两档：STE-flavored（约 80% 严格度）适合 README、解释性文字、日常技术文档，保留句长与主动语态的要求，词汇不必完全锁死；Strict 严格模式则把 53 条规则全上，适合程序步骤、工具描述、Agent 之间互相传递的指令，以及误读代价高的场景。

要注意的是：STE 是一套面向英语的技术文档规范，直接硬套到中文并不合适，但它的结构思想——限定句长、条件前置、术语统一、消灭模糊情态词——完全可以直接搬到中文提示词里。换句话说，你不需要真的用英语写文档，只需要把这份「语言纪律」写进你的 System Prompt 或 AGENTS.md。

产品链接

• SimpleEnglish 开源项目

趋势洞察

这件事的价值，不在于又一个「提示词小技巧」，而在于它揭示了一个正在发生的转向：随着模型越来越自主，人类的工作重心正从「动手执行」转向「理解与监督」。而人类阅读文字的带宽极低，面对 AI 生成的海量输出很容易过载。用一套工程化的语言规范去压缩信息，本质上是把「可读性」变成可度量、可检查的硬指标——这比反复叮嘱模型「写清楚点」要可靠得多。

当 AI 开始替我们写文档、写 Runbook、写代码注释，语言规范就不再是写作老师的事，而是工程团队该纳入 CI 的检查项。少一点废话，多一点可执行性——大模型的输出，是时候上「枷锁」了。