Karpathy用40年前航空规范治AI废话

AI 常被批评“爱说废话”。Karpathy 为此分享了一组让大模型输出更易理解的技巧，核心方法出人意料：借用一套 40 年前的航空写作规范。

上世纪 70 年代，欧洲航空业为让不同语言背景的技术人员准确理解英文维修手册，开始主动限制英语，后发展为 ASD-STE100。最新 Issue 9 包含 53 条写作规则、约 900 个批准基础词，以及约 1200 个建议避免并附替代表达的词。规则很朴素：程序性指令尽量控制在 20 词以内；一句只安排一个操作；尽量用主动语态；同一概念从头到尾只用同一个名字。大模型常为语言“丰富”而频繁换同义词，反而造成阅读障碍；ASD-STE100 则相反，不追求词汇变化，能叫一个名字就一直叫。

Karpathy 发现，把这套规范交给 LLM 后，输出会更清晰易读。但他并不要求模型严格执行整本航空规范，有时只要求做到“80% 的 ASD-STE100”，因为完整版为专业技术文档设计，日常全盘执行会显得僵硬。

他的第二个建议是：能画图就别全写成字，直接让模型生成 diagram 或 image。图示能帮助读者组织信息，即使只服务一个人、用完即弃也划算。更好的形式是网页，让模型“用 HTML 输出”。随着代码模型更擅长前端，答案可以不再是静态内容，而是带布局、动画甚至交互的页面。比如解释神经网络学习率，网页可直接放滑块，用户改变学习率，看小球实时改变下降轨迹。此时模型不只是“解释”，而是临时做了一个帮助理解的小工具。评论区还补充：数学和技术内容可要求 Agent 用 TeX 输出 PDF 技术报告，公式、代码、图表和示意图排版更合适。

Karpathy 目前最看好的形式，是为任何主题生成完全定制的讲解视频。他给出具体案例：让模型“制作一段 3b1b 风格的视频解释”，再接入 ElevenLabs API 生成旁白；没有 API，也可让模型寻找本地免费替代方案。3b1b 即 3Blue1Brown，特点是用程序化动画把抽象概念一步步“演”出来并配合讲解。

这些技巧都着眼于把模型已完成的工作，重新变成人更容易理解的东西。Karpathy 判断，随着 LLM 越来越强，越来越多具体工作会被模型自主完成，人的工作继续向上移动，更多变成监督、检查和理解。AI 也可继续帮助人完成这部分工作。当智能和代码越来越便宜，已可为一个非常具体的问题，临时生成过去根本不值得专门制作的东西。他称之为：large, custom, discardable software artifacts，即大型、定制、用完就可丢掉的软件产物。

Karpathy 发出建议后，Tibo 马上实测：只给一个简单任务“解释一下 Shazam 是怎么工作的”，模型便生成了一段专门讲解其原理的视频。有人试用后觉得效果意外明显，尤其面对较复杂的 HTML Artifact，加入 ASD-STE100 式约束后信息结构更清楚。但也有人把普通回答与 ASD-STE100 版本比较，结论是“好像也没什么区别”。这并不奇怪：简单问题原本只需几句话，再套规范也难有大变化。该规范更适合长技术解释、多步骤操作或不同 Agent 之间传递的信息，内容越复杂越容易看到效果。

还有网友发现，整套规则直接搬来仍可能太严格，更好方法是挑出适合自己场景的部分。于是有人让模型随机抽取过去一周十段交互，用 ASD-STE100 逐条检查：哪些回答不够清楚？哪里产生不必要歧义？应用某条规则是否更易理解？最后把真正有效的规则写进用户级 AGENTS.md。

事实上，三个月前已有人把 ASD-STE100 做成开源 Skill，用于 tool description、error message、Agent 间指令、system prompt 等场景，并分出两种模式：Strict 适合程序步骤、工具描述、Agent 间指令等误读成本更高的内容；STE-flavored 更适合 README、解释性文本等普通场景，保留句长、主动表达、结构清晰等原则，但不完全锁死词汇。这很像把 Karpathy 那句“80% 的 ASD-STE100”进一步产品化。有开发者还做了可立即使用的 Claude Skill，并把代码放上 GitHub。