Karpathy 分享让大模型输出更易读的技巧：借鉴 40 年前航空规范 ASD-STE100

大模型越写越多，但“多”不等于“好读”。Karpathy 分享的一组技巧，针对的正是这个问题：怎么让大模型越来越多的输出变得更容易理解。他的答案出人意料——不是让模型写得更华丽，而是给它套上一套 40 年前的航空写作规范。

这套规范的源头是上世纪 70 年代的欧洲航空业。当时维修体系越来越国际化，英文维修手册要交给来自不同国家、不同语言背景的技术人员使用，因此要求手册里的每一句话都只能有一种理解。航空业于是开始主动给英语加限制，这套受控英语后来逐步发展为 ASD-STE100。

ASD-STE100 最新 Issue 9 包含 53 条写作规则，配有约 900 个批准使用的基础词，以及约 1200 个建议避免、同时提供替代表达的词。规则本身很朴素：一句程序性指令尽量控制在 20 个词以内；一句话只安排一个操作；尽量用主动语态；同一个概念从头到尾尽量只用同一个名字。

这套思路和大模型的默认倾向正好相反。模型为了让语言更“丰富”，经常轮换使用同义词，但在很多场景下，这种轮换反而制造了阅读障碍。ASD-STE100 不追求词汇变化，也不鼓励漂亮的长句——能叫一个名字，就一直叫这个名字。

Karpathy 发现，把这套规范交给 LLM 之后，输出会变得更清晰易读。但这一判断来自他的个人观察，来源并未给出量化评测，因此更适合被当作一种经验性主张，而非已被验证的结论。

他也没有真的要求模型严格执行一整本航空规范。有时他会要求模型做到“80% 的 ASD-STE100”。原因很直接：完整版是为专业技术文档设计的，日常如果一板一眼全部执行，很容易显得过于僵硬。

“80%”这个说法本身也留有模糊空间——来源没有说明这 80% 具体如何衡量，是规则条数的取舍，还是执行严格度的折扣。可以确定的是，Karpathy 的意图不是照搬规范，而是借用它的约束精神。

Karpathy 的第二个建议是直接让模型生成 diagram 或者 image。理由是图示可以帮助读者组织信息；即使这张图只为你一个人服务、看完之后再没人使用，生成它也依然划算。

再往前一步是网页。他建议直接让模型“用 HTML 输出”。随着代码模型越来越擅长前端，答案可以不再是一段静态内容，而是一个带有布局、动画甚至交互功能的页面。来源举的例子是理解神经网络里的学习率：文字只能告诉你学习率太小收敛很慢、太大又可能震荡，而网页可以直接放一个滑块，让你自己改变学习率，看着一个小球实时改变下降轨迹。这时模型已经不只是在“解释”，它临时做了一个帮助你理解这件事的小工具。

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

他把这类产物称为 large, custom, discardable software artifacts——大型、定制、用完就可以丢掉的软件产物。这个命名的重点在“可丢弃”：当智能和代码越来越便宜，人们已经可以为了一个非常具体的问题，临时生成过去根本不值得专门制作的东西。

Karpathy 刚发出建议，Tibo 就做了一次实测：他只给了一个很简单的任务——“解释一下 Shazam 是怎么工作的”，模型随即生成了一段专门讲解 Shazam 工作原理的视频。需要说明的是，这一实测由二手转述，来源没有提供视频本身或独立验证。

社区对 ASD-STE100 效果的评价并不一致。有人试过后觉得，加入 ASD-STE100 式约束后，复杂 HTML Artifact 的信息结构变得更清楚；但也有人把普通回答和 ASD-STE100 版本放在一起比较，结论是“好像也没什么区别”。

这种分歧其实不难解释。如果只是问一个很简单的问题，模型原本就只需要回答几句话，再套一层规范，也很难出现天翻地覆的变化。从来源的描述推断，这套规范更适合长技术解释、多步骤操作，或者不同 Agent 之间传递的信息——内容越复杂，越容易看到效果。

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

事实上，三个月前就已经有人把 ASD-STE100 做成了开源 Skill，并把这套思路进一步用在 tool description、error message、Agent 之间的指令、system prompt 等场景。

这个开源 Skill 专门分出两种模式。一种是 Strict，适合程序步骤、工具描述、Agent 间指令等误读成本更高的内容；另一种是 STE-flavored，更适合 README、解释性文本等普通场景，保留句长、主动表达、结构清晰等原则，但不会把词汇完全锁死。

这很像把 Karpathy 那句“80% 的 ASD-STE100”进一步产品化了：并不是所有地方都需要最严格的规范。需要提醒的是，该 Skill 的实际效果与适用边界在来源中仅有作者与社区描述，缺乏第三方评测。

Karpathy 最后给出的判断是：随着 LLM 越来越强，越来越多具体工作会被模型自主完成，人的工作则继续向上移动，更多变成监督、检查和理解。

这组技巧恰好落在这个判断上——它们处理的不是“模型能不能完成任务”，而是“模型完成的工作能不能被人读懂”。当智能和代码越来越便宜，人可以为了一个非常具体的问题临时生成过去不值得专门制作的东西；而人要做的事，是判断哪些东西值得生成、哪些规则值得保留。

需要保持的边界是：来源没有说明这些技巧在中文等其他语言输出上的适用性，也没有给出量化评测。它们目前更像一组被社区快速试验和改造的实践，而不是一套已被验证的标准答案。