理解语言模型的输出：Karpathy 的四层格式

Andrej Karpathy 在 2026-10-02 写：模型越强，人越要把时间花在看懂它的输出上。他按「一层比一层好读」排了四种格式：受控英语、图、网页、讲解视频。

原文：We’ll be spending a lot more time trying to understand the outputs of language models。

ASD-STE100 速查：文档结构、句子解剖、动词形式、词典、长度上限与简史

配图是帖子附的 ASD-STE100 速查。下面按这张图和正文，把方法收成可以直接开口要的提示。

他想说的两件事

模型会自己干越来越多的粗活。人的工作往上走一层：监督、核对、理解。
智能和代码都变便宜了。可以让模型做大的、定制的、用完即弃的软件（网页、讲解视频）。以前不值得专门做的东西，现在值得开口要。他把这类东西叫 discardable software artifacts。

四层格式

层	让模型交什么	什么时候用
1 写作	ASD-STE100，或「八成靠近 STE」	要读懂一段解释、步骤、定义
2 图	一张能单独看懂的图	关系、流程、结构比句子好记
3 网页	一个完整 HTML 文件	要交互、对照、动画，看完可以扔
4 讲解视频	3Blue1Brown 风格的专题视频	一个具体题目，想一遍看懂

第 4 层是他最看好的。他说这已经开始能用了。

1. 写作：ASD-STE100

ASD-STE100 是 Simplified Technical English（简化技术英语）。航空维修手册用的受控语言，现在由 ASD 的 STEMG（Simplified Technical English Maintenance Group）维护。规范分两块：写作规则，和一本批准词典。

配图上值得记住的约束：

规则	上限或做法
词典	约 900 个批准词。一个词只保留一个词性、一个意思
用词	未批准的词换成批准词。commence → START，ensure → MAKE SURE，prior to → BEFORE
语态	主动语态。程序句里进行时、完成时、被动不批准
程序句	最多 20 个词，一句一个动作
描述句 / 段	一句最多 25 个词，一段最多 6 句
名词串	最多 3 个词
冠词	the、a、this 留着，不省

规范很严。他的用法是先按 STE 要；太硬就改口要 80% of the way to ASD-STE100。

1
2
3

Explain <主题> in ASD-STE100 (Simplified Technical English).
Use short sentences, active voice, and one meaning per word.
If that is too strict, write at 80% of the way to ASD-STE100.

题目用中文也行，只要声明输出走 STE：

1
2
3

用 ASD-STE100 解释：<主题>。
句子短，主动语态，一词一义。
如果规范太硬，就写到「八成靠近 ASD-STE100」。

规范站点：asd-ste100.org。配图上的简史：1979 年 AECMA 开始做航空受控英语，1986 年第一版指南，2004 年 AECMA 并入 ASD，2005 年改称 ASD-STE100。

2. 图

一段文字读着累，就改要一张图。流程、对照、从属关系，图更好扫。

1 2	不要写长文。为 <主题> 做一张图。每个框写清它是什么，每条箭头写清关系。这张图要能单独看懂。

3. 网页

直接要 HTML。模型做前端已经够用，交互、动画、对照可以一次生成。页面看懂就扔，不必当正式项目维护。

1 2	用一个 HTML 文件讲清楚 <主题>。单文件，CSS 和 JS 内联。要能交互，把关系做成可以点的结构。

4. 讲解视频

针对任意题目，做一条专门的讲解视频。参照 3Blue1Brown：用图形把论证走一遍，旁白跟着图形走。配音可以用 ElevenLabs；没有 key，就让模型找能吃本机算力的免费替代。

1
2
3

Create a 3Blue1Brown-style video explainer on <主题>.
Use visuals to carry the argument. Narrate in clear, short sentences.
If you need speech, use a local TTS. Do not ask me to paste an API key into the chat.

密钥放在环境变量或本机配置里。

怎么往上要

先要 STE，把概念钉成短句。结构还是糊，就要一张图。还是进不去，就要一个 HTML，自己点。这个题目值得看一遍，再要讲解视频。每一层都是一次性的，不满意就重做。

原文

We’ll be spending a lot more time trying to understand the outputs of language models. A few thoughts, tips & tricks:

Writing. Something I’ve had success with: Ask your LLM to explain something in ASD-STE100, it’s a controlled language specification originally developed for aerospace maintenance documentation. LLMs well-versed in this language and it comes with heavy constraints on clean writing style that I often find a lot more readable. Sometimes I’ve tried to soften it a bit e.g. ask for “80% of the way to ASD-STE100” because the spec is quite stringent. But even better:

Diagrams / images. Instead of writing, ask your LLM to create a diagram. These can be a lot easier to process, parse, and understand. But even better:

Web pages. Ask for output “in HTML” to get a beautiful, interactive webpage. LLMs are getting really good at frontend and can create beautiful experiences, animations, etc. But even better:

Explainer videos. The output format I am most bullish on is fully custom / bespoke explainer videos generated on any arbitrary topic. Experiment with things like “Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration”. (you’d need an API key for the latter or you can ask your LLM to find you decent free alternatives that use your local compute). This is actually starting to work!

In summary:

As LLMs get better, they will do more and more of the legwork autonomously, and a lot more of our work will rise up the abstractions into oversight and understanding.

Luckily, LLMs can help here too because as intelligence and code are increasingly abundant, you can ask for large, custom, discardable software artifacts (e.g. web apps, video explainers) that would have never made sense to create before. Push the boundaries here and you’ll be surprised.

帖子下面

Erick P. 照这个做法，做了一条随机微积分的 3Blue1Brown 风格讲解。
Grady Booch 在「要图」下面补了一句：UML 早就在做这件事。