Karpathy：让大模型输出更容易理解的四种技巧
来源：Andrej Karpathy 的原推文，发布于 2026-10-02。 本文总结原帖观点；提示词示例、格式选型和实践步骤是据此整理的应用建议。
Karpathy 提醒：随着语言模型承担更多具体工作，人类会花更多时间理解模型的产出，并在更高层面监督和判断。模型除了完成任务，也可以帮助我们理解任务结果。
他给出四种值得尝试的输出方式：用受控语言写清楚、用图表达关系、用网页提供交互、用视频逐步讲解。其中，他最看好为任意主题定制的讲解视频。
四种技巧一览
| 输出方式 | Karpathy 的建议 | 可以怎样使用 |
|---|---|---|
| 文字 | 要求按 ASD-STE100 写作，或放宽到接近该规范的风格 | 让解释更清楚，减少复杂表达和歧义 |
| 图解 / 图片 | 直接要求模型画图 | 展示组件关系、流程或信息结构 |
| HTML 网页 | 明确要求输出为 HTML | 用交互、动画和布局帮助阅读与探索 |
| 讲解视频 | 为具体主题生成专属视频，可配语音旁白 | 按时间顺序演示推导、变化和因果过程 |
选择时可以从当前的理解障碍出发：文字太绕就约束语言，关系难记就画图，需要试参数就做网页，需要看过程就做视频。
1. 文字：借助 ASD-STE100，让解释更清楚
ASD-STE100（Simplified Technical English，简化技术英语）源自航空维修文档，是一种受控自然语言标准。它包含写作规则和受控词典，用明确的用词及句式约束，降低技术文档的理解难度与歧义。ASD-STE100 官方介绍
Karpathy 发现，要求 LLM 用这种语言解释问题，往往比普通回答更易读。他也尝试过把要求放宽为“接近 ASD-STE100，大约做到 80%”，以保留清楚的表达，又减轻严格规范带来的限制。
可复用提示词：
Explain [topic] in a style about 80% of the way to ASD-STE100.
Use short, direct sentences and consistent terminology.
Define technical terms when they first appear.
Keep the important assumptions, conditions, and limitations.如果希望中文输出，可以借用其中的表达原则：
请用中文解释 [主题]，接近 ASD-STE100，大约做到 80%：
使用短句和明确的主语；一个句子尽量说明一件事；
同一概念始终使用同一个名称，首次出现时解释术语；
保留必要的条件、例外和技术细节。“80%”是宽松的风格描述，没有正式的合规评分含义。中文示例也是对表达原则的借鉴。即使模型声称熟悉 STE，生成结果仍需依据正式规则与词典审查；官方也提醒，看起来清楚的 AI 文本未必正确遵循标准。ASD-STE100 官方说明
2. 图解：把需要记忆的关系画出来
Karpathy 建议直接让模型创建图解或图片。有些信息通过空间布局就能看清，读者不必在多个段落之间来回拼接关系。
例如，系统包含哪些组件适合用架构图，请求如何经过多个服务适合用时序图，任务有哪些分支适合用流程图。
可复用提示词：
请用一张图解释 Kubernetes Pod 从提交到完成调度的过程。
标出主要组件、交互顺序和关键决策点。
每条箭头说明传递的信息或触发的动作。
提供可编辑的 Mermaid 或 SVG，并附一段简短说明。图解是否有用，取决于它能否准确表达关系。检查时重点看箭头方向、执行顺序、条件分支和图例含义；配图的说明应保留图中难以容纳的限制条件。
3. HTML 网页：让读者可以操作解释
Karpathy 的下一步建议是明确要求输出“in HTML”。网页可以组合排版、图形、动画和交互，让同一份解释支持更多阅读方式。
例如，在图中突出当前步骤，用按钮逐步展开过程，或通过滑块调整参数并观察结果。这些交互可以帮助读者主动检验自己的理解。
可复用提示词：
请把 [主题] 做成一个自包含的交互式 HTML 讲解页面。
面向初学者，先给出核心概念，再展示具体例子。
用图说明主要关系，并提供“下一步”按钮逐步演示过程。
如果有可调整参数，请展示参数变化如何影响结果，
同时说明演示采用的假设与简化。
内联 CSS 和 JavaScript，使页面可以直接在浏览器中打开。这里的“自包含”和分步交互是实践时可加入的交付要求。使用交互页面时，应确认每个按钮、滑块和动画都有助于解释问题，并且演示结果与所述假设一致。
相关实践见 Effective HTML 页面工作流。
4. 讲解视频：为当前问题制作专属解释
Karpathy 最看好的形式，是为任意主题生成完全定制的讲解视频。他举的例子是：要求模型制作一段 3b1b（3Blue1Brown）风格的讲解视频，并使用 ElevenLabs API Key 生成语音旁白。
这种尝试把文字、图形和时间顺序组合起来：画面逐步展示变化，旁白解释每一步为什么发生，适合需要跟随推导或过程才能理解的主题。
可复用提示词：
请制作一段面向初学者的 [主题] 讲解视频。
参考 3Blue1Brown 的讲解方式：先建立直觉，再逐步展示过程，
让画面变化与旁白解释相对应。
先提供讲解脚本和分镜，再生成动画、旁白、字幕并导出视频。
旁白可使用我已配置的 ElevenLabs API Key。
如果无法使用该服务，请先寻找适合本机计算资源的免费替代方案，
说明硬件需求和限制，再选择实现方式。原帖提到两条语音路线：使用 ElevenLabs，需要 API Key；或者让模型寻找利用本地计算资源的免费替代方案。它没有指定本地工具，因此实际制作时还需核对语言支持、硬件要求和可用性。
完整视频需要动画或视频生成、语音合成及导出能力。可以把任务拆成脚本 → 分镜 → 动画 → 旁白与字幕 → 视频导出，逐步核对画面、讲解和时间是否一致。3b1b 风格只是讲解形式的参考，内容正确性仍要单独检查。
相关实践见 AI 科普动画实践。
如何把这些技巧用起来
先明确自己需要理解什么，再让模型制作相应的解释。例如，同一个系统可以先用短文说明职责，用架构图展示依赖，再用网页或视频演示一次请求的完整过程。每种产物都应围绕同一个问题，并保留事实来源与关键假设。
Karpathy 的进一步判断是：随着模型能力提高，智能与代码更容易获得，过去制作成本过高的大型、定制、用完即弃的软件产物也会变得值得尝试。为了理解一次分析，可以专门生成一个网页；为了弄懂一个概念，也可以制作一段只服务于当前学习需求的视频。
这类产物的价值在于帮助人理解、检查和判断模型结果。是否采用更复杂的格式，可以用一个实际标准决定：它是否让当前问题更容易看清。
相关笔记
- HTML 取代 Markdown：Anthropic 工程师的建议：早期围绕 HTML 输出格式的讨论。
- Effective HTML 页面工作流：交互页面的制作与检查流程。
- AI 科普动画实践：动画生成的相关实践。
- 提示词工程：通过目标、约束、输出形式和验收标准减少任务歧义。