Karpathy 的新建议：让 AI 为你做出理解工具

Andrej Karpathy 在一条新帖里提出：随着语言模型承担更多具体工作，我们会花越来越多时间理解它们的输出。他给出的建议很具体：让模型使用更清楚的语言，画图，把答案做成交互网页，甚至为一个任意主题制作专门的讲解视频。原帖

这条帖子吸引我的地方，是它给“怎样用好 AI”增加了一种要求。我们已经习惯让 agent 查资料、写代码、做方案。接下来，还可以让它为接收这些结果的人，制作一个看得懂、能追问、可以动手试的理解工具。

这会改变我们与 agent 的互动方式。收到一份陌生领域的长报告，过去的反应往往是“再解释一下”。现在，我们可以说：“把这里的关系画出来”“做一个让我改变条件的页面”“用动画带我走一遍这个过程”。理解本身，也可以成为委托给 agent 的一部分工作。

先读清楚：他在建议什么

原帖的顺序是文字、图解、网页、视频。Karpathy 在每一项之后都继续提出更丰富的表达方式；他尤其看好为某个问题专门制作的讲解视频。原帖

这里有两层意思。一层是他使用模型时得到的经验：约束写作风格、改变输出形式，可能让内容更容易理解。另一层是他的判断：模型越能自主完成具体工作，人越会转向监督和理解；与此同时，生成代码的成本变化，让过去不值得专门开发的理解工具变得更值得尝试。

我把这两层意思连起来看，会得到一个很有用的工作方向：任务交付以后，继续让 agent 帮你接近这项工作。 如果答案太远，就请它做一座桥。桥可以是一张图、一页网页，也可以是一段视频。

原帖没有发布一个完整的 agent 管理体系，也没有提供四种形式的学习效果实验。下面是我沿着他的建议整理的一套可尝试的用法：从自己理解困难的位置开始，一步一步要求 agent 改变交付方式。

原创概念图：四种形式各有用途，这里不把它们排成效果名次。

第一步：让文字把动作和条件讲清楚

Karpathy 的第一个技巧，是让模型用 ASD-STE100 解释问题。这是一种受控技术英语，最初服务于航空维护文档的理解。他说，严格的写作约束经常让输出更容易读；有时还会要求模型只靠近规范的八成，以免太僵硬。原帖、ASD-STE100 官方背景

我认为可借鉴的核心，是给语言加约束。同一个东西始终用同一个名称；把动作、执行者和条件写出来；把复杂句拆开；不要让一个漂亮但含混的词代替具体行为。对中文写作，也可以要求这些原则。中文并不因此成为符合 STE 的技术英语，模型接受了提示也不等于经过规范审核。

例如，一个 agent 告诉你：“系统通过健壮的幂等性机制确保重试操作的一致性。”这句话看起来很专业，但你可能仍然不知道发生了什么。

可以接着要求它：

把这段解释改写给第一次接触这个概念的人。先说谁执行了什么动作，再说动作在什么条件下发生。同一个对象始终使用同一个名称。保留会改变结论的条件。术语第一次出现时，先解释行为再给名称。若用英语，可以借鉴 ASD-STE100 的清楚写法；不必声称符合完整标准。

它应该更接近这样的说明：“系统收到请求后，执行操作，并保存这次请求的回执。再次收到同一个请求时，返回已有回执，不再执行操作。这里假设回执仍在，而且请求的内容没有改变。”

这一步很朴素，却为后面所有形式打下基础。没有说清楚的条件，画成图以后也不会自动变清楚。

第二步：让图给问题一个可以指向的位置

原帖的配图已经演示了这一点。它把 ASD-STE100 的文档结构、句子改写、词典和写作限制放在同一张总览图上。读者可以比较原句与改写，也可以沿着标注找到一个词为什么不适合那种用法。原帖配图

图带来的变化，是让关系有了位置。你可以指着某个节点问“为什么经过这里”，指着一个边界问“这部分是否也成立”。一份按段落展开的答案，变成了能同时比较的对象。

这时向 agent 提要求，应当先说明要看哪种关系：因果、依赖、时间顺序，还是分类。否则，它很容易给你一张装饰漂亮、信息堆满的总览。

把刚才的解释画成一张图，只展示第一次请求与重试的路径。使用“请求、操作、回执”三个对象。用不同的路径说明第一次执行和再次返回。每条箭头必须有明确含义。把成立条件放在图旁，先别加入其他系统组件。

这类图的审阅也很具体：箭头是否表示真实关系？方向是否正确？同一个对象是否换了名字？如果去掉旁边的解释，图是否仍然表达我们想讨论的那个问题？

我们可以学习原帖配图的组织方式，但总览图会压缩细节。查具体规范时，仍要回到原始文档。

第三步：让网页把“如果”变成一个动作

Karpathy 接着建议要求模型用 HTML 输出。他看好模型制作漂亮前端、交互和动画的能力。对我而言，网页最有意思的地方，是读者可以改变一个条件，立即看到模型会怎样回应。原帖

到这里，再用一个小案例演示。仓库有十件货，请求 A 预留三件，库存变成七件。但返回给你的确认消息丢了。你看到超时，决定重试。第二次操作是否还会扣库存，取决于这个系统怎样处理同一请求。

我们为解释设定一个简单模型：保存回执时，重试 A 返回旧结果，库存仍是七件；删掉回执再重试，它会再次执行，库存变成四件。这个模型只演示我们定义的规则，暂时不处理真实系统里的并发和故障恢复。

可以让 agent 把问题做成这样一个页面：

基于刚才的模型，创建一个本地可打开的单文件 HTML。显示库存、请求编号和回执状态。提供“发送 A”“重试 A”和“保留回执”控件。让我先预测，再点击查看结果。增加重置按钮，并在页面上写出模型假设。使用示例数据，控件只改变页面内的教学状态。

我们已经做出了这一个可操作的案例。你可以保留回执，也可以把它删掉；还可以使用新的请求编号 B，或保留 A 的编号却改变请求数量。后两种操作让人继续追问：请求的“同一性”到底由什么决定？

这就是交互的价值。听到“重试不会重复执行”之后，你不必停在记住一句话。你可以把一个条件拿走，看看结论还在不在。现实接口的行为需要查它自己的文档；例如 Stripe 的幂等请求说明就明确列出了请求参数和记录保留时间的条件。Stripe 文档

用 agent 做这种页面，最值得检查的是规则和状态。按钮能动，只证明界面能响应。我们还要确认，每次变化都符合定义：保留回执时是否仍是七件，改变请求内容时是否明确拒绝，新编号是否执行新的操作。

同一请求、不同条件。上排七件，下排四件；这是本文设定的教学规则。

第四步：让视频带着注意力走过过程

Karpathy 最看好的形式，是为任意主题制作定制讲解视频。他给出的尝试方向包括 3Blue1Brown 式的解释，以及用 ElevenLabs 做旁白；也提到可以寻找使用本地计算的免费替代方案。原帖

视频适合解决另一个障碍：读者可能看到了所有对象，却不知道应该先注意哪个变化。

在刚才的案例里，最值得演示的瞬间是：操作已经成功，确认却没有到达。让观众跟着请求进入仓库，看到三件货被预留、回执被保存，再跟着返回消息走一段，直到它消失。画面停下来，观众才会同时理解两边的状态：发送者以为失败，接收者已经完成。

这里的 3D 和运镜有具体作用。空间位置帮助人记住请求、库存和回执；镜头沿着消息路径移动，表现先后顺序；拉回全景，让人把两边放在一起看。文字标签应当停得住，不能让读者一边追镜头、一边读解释。

向 agent 提要求时，也应该说明这份教学任务：

为刚才的模型制作一段讲解视频。先让我看到任务已经完成、确认却丢失的差别，再演示同一请求如何重试。沿用同一组对象和编号。动画只表现状态或路径变化。给观众一次预测暂停，并在结尾说明模型没处理的情况。先交付旁白、分镜和一段有代表性的样片，再扩展成完整视频。

分镜、样片和暂停点，是我接着原帖建议加入的制作方法。它们让我们能在制作过程中审阅，而不是到最后才发现影片把错误讲得很顺。

Grant Sanderson 在 3Blue1Brown 的教学建议里强调具体例子，也提醒创作者避免让文字和公式无必要地移动。我很喜欢这个约束：每一次动画都应当有一个观众需要看懂的变化。3Blue1Brown 官方建议

一次性软件为什么值得认真做

原帖里还有一个重要判断：模型可以为你生成专门的、用完即可丢弃的软件。过去，为一次讨论做网页，为一个概念做视频，制作成本往往不合算。现在，我们可以更频繁地试试这种交付。原帖

这与长期产品开发有不同的目的。一个理解工具可以只服务于一次会议：帮团队看清某个假设，帮助一个学生理解变量，或者让接收研究的人找到结论依赖的条件。问题解决了，页面可以归档；经过讨论的判断和假设留下来。

它真正拓宽的是个人能提出的要求。面对陌生领域，你可以让 agent 为你量身定做一条进入它的路径。遇到难题时，除了要求“多写一点”，还可以要求“让我看见”“让我试试”“带我走一遍”。

我们之前做 OpenAI Dot 的小世界 时，回放让人能指着一个时刻讨论发生了什么。Karpathy 这条帖让我更想把这种能力用在日常学习和工作中：接收一个结果的时候，也接收一条可以进入结果的路径。

AI 生成的概念场景：一个理解工具，可以只为一个问题存在。

怎样把它用进下一次 agent 任务

不必一次要求四种形式。先告诉 agent，你在理解上遇到了什么障碍，然后选一种能解决它的交付物。核对条件时用文字，比较关系时用图，探索变量时用交互，理解过程时用视频。任务简单，就让交付也简单。

我会在委托时加上这一段：

完成任务后，请帮助我理解你的结果。我需要用它来作出什么判断？先解释结论、关键关系和假设，再选择能帮助我解决当前疑问的表达形式。如果适合交互，让我改变一个重要条件；如果适合动画，让我跟上真实的过程变化。保留来源，并给我一个可以检查理解的反例或预测问题。

接收时，我也需要做自己的那一部分：先说出预测，再操作；检查变化是否符合规则；找到结论依赖的条件；需要作决定时，回到来源、代码或运行记录。解释可能与原答案共享遗漏，换一种形式并不会自动增加独立证据。

用一个真实问题，试试四种交付

最后，用一个不需要编程背景的问题试试：为什么詹姆斯·韦伯太空望远镜，要去地球外约 150 万公里？ 这是 NASA 实际任务中的设计选择。我们借它做解释练习；下面的页面和分镜由我们制作。

NASA 的说明给出两条关键线索：韦伯在日地 L2 附近绕太阳运行；这个位置让太阳、地球和月亮能保持在遮阳板的同一侧。望远镜观测微弱红外信号，需要冷而稳定的环境，遮阳板帮助它隔开这些光与热。NASA 轨道说明、遮阳板说明

文字，先让我们抓住原因。 可以让 agent 这样说：“韦伯需要保持很冷。太阳、地球和月亮都会带来光与热。L2 附近的位置让它们位于望远镜的同一侧，因此遮阳板可以挡在它们与望远镜之间。”不必先背下来“拉格朗日点”，先知道这项设计解决什么问题。

图解，再让我们看清位置。 在同一张图上，把太阳、地球和月亮放在一侧，把遮阳板放在中间，把望远镜放在另一侧。读者就能指出：“原来要一起挡住的是这几个热源。”这是一张关系示意图，距离和大小没有按比例绘制。

交互，让我们检查一个条件。 在四种输出形式的实际演示页里，可以分别显示三个热源的示意线，再隐藏遮阳板。观察原本止于遮阳板的线怎样延伸到望远镜，你就能回答：“只离地球很远，能代替遮阳板吗？”页面演示的是位置与遮挡关系，不能计算真实温度。

视频，让我们沿着同一条理由走一遍。 先给出望远镜需要冷却的问题；再把三个热源放进画面；接着出现遮阳板，隔开两侧；拉远镜头，交代 L2 附近的位置。然后停下来，让观众预测隐藏遮阳板会发生什么。顺序和注意力都有了方向，事实仍然是刚才那一组。

这里还值得保留一个准确的细节：韦伯绕 L2 附近的轨道运行，并非固定停在那个点上。我们的图也没有把它画成躲在地球阴影里的望远镜。NASA FAQ

把这份任务交给 agent，可以先指定来源和读者：“只基于这些 NASA 页面，帮没有天文学背景的人理解遮阳板与轨道位置的关系。先交回一段短解释，再做关系图和一个能检查遮挡条件的页面，最后据此写视频分镜。四种形式保持同一组事实，分别标明做了什么简化。”

同一个真实问题，文字给原因，图解给位置，交互给检查条件的机会，视频给观看顺序。这样使用 agent，我们既能学会一件具体的事，也能学会怎样要求它帮助我们理解下一件事。

这条帖让我兴奋，是因为它把 agent 的创造能力与人的理解需要连接了起来。我们可以让更多问题变得可见、可试、可接近。AI 做得越多，这样的交付就越值得认真设计。