[{"data":1,"prerenderedAt":380},["ShallowReactive",2],{"blog-post-/zh/blogs/karpathy-understanding-ai-output":3},{"id":4,"title":5,"body":6,"description":363,"extension":364,"meta":365,"navigation":375,"ogImage":367,"path":376,"seo":377,"stem":378,"__hash__":379},"zh/blogs/zh/37.karpathy-understanding-ai-output.md","Karpathy 的新建议：让 AI 为你做出理解工具",{"type":7,"value":8,"toc":351},"minimal",[9,20,23,26,31,37,40,48,51,58,64,68,80,83,86,89,95,98,101,105,113,116,119,124,127,130,134,140,143,146,149,154,162,170,173,179,184,188,194,197,200,203,206,211,214,222,225,231,234,237,246,252,257,261,264,267,272,275,279,286,299,305,311,317,328,334,342,345,348],[10,11,12,13],"p",{},"Andrej Karpathy 在一条新帖里提出：随着语言模型承担更多具体工作，我们会花越来越多时间理解它们的输出。他给出的建议很具体：让模型使用更清楚的语言，画图，把答案做成交互网页，甚至为一个任意主题制作专门的讲解视频。",[14,15,19],"a",{"href":16,"rel":17},"https://x.com/karpathy/status/2105819303471976479",[18],"nofollow","原帖",[10,21,22],{},"这条帖子吸引我的地方，是它给“怎样用好 AI”增加了一种要求。我们已经习惯让 agent 查资料、写代码、做方案。接下来，还可以让它为接收这些结果的人，制作一个看得懂、能追问、可以动手试的理解工具。",[10,24,25],{},"这会改变我们与 agent 的互动方式。收到一份陌生领域的长报告，过去的反应往往是“再解释一下”。现在，我们可以说：“把这里的关系画出来”“做一个让我改变条件的页面”“用动画带我走一遍这个过程”。理解本身，也可以成为委托给 agent 的一部分工作。",[27,28,30],"h2",{"id":29},"先读清楚他在建议什么","先读清楚：他在建议什么",[10,32,33,34],{},"原帖的顺序是文字、图解、网页、视频。Karpathy 在每一项之后都继续提出更丰富的表达方式；他尤其看好为某个问题专门制作的讲解视频。",[14,35,19],{"href":16,"rel":36},[18],[10,38,39],{},"这里有两层意思。一层是他使用模型时得到的经验：约束写作风格、改变输出形式，可能让内容更容易理解。另一层是他的判断：模型越能自主完成具体工作，人越会转向监督和理解；与此同时，生成代码的成本变化，让过去不值得专门开发的理解工具变得更值得尝试。",[10,41,42,43,47],{},"我把这两层意思连起来看，会得到一个很有用的工作方向：",[44,45,46],"strong",{},"任务交付以后，继续让 agent 帮你接近这项工作。"," 如果答案太远，就请它做一座桥。桥可以是一张图、一页网页，也可以是一段视频。",[10,49,50],{},"原帖没有发布一个完整的 agent 管理体系，也没有提供四种形式的学习效果实验。下面是我沿着他的建议整理的一套可尝试的用法：从自己理解困难的位置开始，一步一步要求 agent 改变交付方式。",[10,52,53],{},[54,55],"img",{"alt":56,"src":57},"同一个问题以文字、图解、HTML 交互和视频四种形式呈现","/blogs-img/2026-10-02-karpathy-01-four-forms-v2.webp",[10,59,60],{},[61,62,63],"em",{},"原创概念图：四种形式各有用途，这里不把它们排成效果名次。",[27,65,67],{"id":66},"第一步让文字把动作和条件讲清楚","第一步：让文字把动作和条件讲清楚",[10,69,70,71,74,75],{},"Karpathy 的第一个技巧，是让模型用 ASD-STE100 解释问题。这是一种受控技术英语，最初服务于航空维护文档的理解。他说，严格的写作约束经常让输出更容易读；有时还会要求模型只靠近规范的八成，以免太僵硬。",[14,72,19],{"href":16,"rel":73},[18],"、",[14,76,79],{"href":77,"rel":78},"https://www.asd-ste100.org/about_STE.html",[18],"ASD-STE100 官方背景",[10,81,82],{},"我认为可借鉴的核心，是给语言加约束。同一个东西始终用同一个名称；把动作、执行者和条件写出来；把复杂句拆开；不要让一个漂亮但含混的词代替具体行为。对中文写作，也可以要求这些原则。中文并不因此成为符合 STE 的技术英语，模型接受了提示也不等于经过规范审核。",[10,84,85],{},"例如，一个 agent 告诉你：“系统通过健壮的幂等性机制确保重试操作的一致性。”这句话看起来很专业，但你可能仍然不知道发生了什么。",[10,87,88],{},"可以接着要求它：",[90,91,92],"blockquote",{},[10,93,94],{},"把这段解释改写给第一次接触这个概念的人。先说谁执行了什么动作，再说动作在什么条件下发生。同一个对象始终使用同一个名称。保留会改变结论的条件。术语第一次出现时，先解释行为再给名称。若用英语，可以借鉴 ASD-STE100 的清楚写法；不必声称符合完整标准。",[10,96,97],{},"它应该更接近这样的说明：“系统收到请求后，执行操作，并保存这次请求的回执。再次收到同一个请求时，返回已有回执，不再执行操作。这里假设回执仍在，而且请求的内容没有改变。”",[10,99,100],{},"这一步很朴素，却为后面所有形式打下基础。没有说清楚的条件，画成图以后也不会自动变清楚。",[27,102,104],{"id":103},"第二步让图给问题一个可以指向的位置","第二步：让图给问题一个可以指向的位置",[10,106,107,108],{},"原帖的配图已经演示了这一点。它把 ASD-STE100 的文档结构、句子改写、词典和写作限制放在同一张总览图上。读者可以比较原句与改写，也可以沿着标注找到一个词为什么不适合那种用法。",[14,109,112],{"href":110,"rel":111},"https://x.com/karpathy/status/2105819303471976479/photo/1",[18],"原帖配图",[10,114,115],{},"图带来的变化，是让关系有了位置。你可以指着某个节点问“为什么经过这里”，指着一个边界问“这部分是否也成立”。一份按段落展开的答案，变成了能同时比较的对象。",[10,117,118],{},"这时向 agent 提要求，应当先说明要看哪种关系：因果、依赖、时间顺序，还是分类。否则，它很容易给你一张装饰漂亮、信息堆满的总览。",[90,120,121],{},[10,122,123],{},"把刚才的解释画成一张图，只展示第一次请求与重试的路径。使用“请求、操作、回执”三个对象。用不同的路径说明第一次执行和再次返回。每条箭头必须有明确含义。把成立条件放在图旁，先别加入其他系统组件。",[10,125,126],{},"这类图的审阅也很具体：箭头是否表示真实关系？方向是否正确？同一个对象是否换了名字？如果去掉旁边的解释，图是否仍然表达我们想讨论的那个问题？",[10,128,129],{},"我们可以学习原帖配图的组织方式，但总览图会压缩细节。查具体规范时，仍要回到原始文档。",[27,131,133],{"id":132},"第三步让网页把如果变成一个动作","第三步：让网页把“如果”变成一个动作",[10,135,136,137],{},"Karpathy 接着建议要求模型用 HTML 输出。他看好模型制作漂亮前端、交互和动画的能力。对我而言，网页最有意思的地方，是读者可以改变一个条件，立即看到模型会怎样回应。",[14,138,19],{"href":16,"rel":139},[18],[10,141,142],{},"到这里，再用一个小案例演示。仓库有十件货，请求 A 预留三件，库存变成七件。但返回给你的确认消息丢了。你看到超时，决定重试。第二次操作是否还会扣库存，取决于这个系统怎样处理同一请求。",[10,144,145],{},"我们为解释设定一个简单模型：保存回执时，重试 A 返回旧结果，库存仍是七件；删掉回执再重试，它会再次执行，库存变成四件。这个模型只演示我们定义的规则，暂时不处理真实系统里的并发和故障恢复。",[10,147,148],{},"可以让 agent 把问题做成这样一个页面：",[90,150,151],{},[10,152,153],{},"基于刚才的模型，创建一个本地可打开的单文件 HTML。显示库存、请求编号和回执状态。提供“发送 A”“重试 A”和“保留回执”控件。让我先预测，再点击查看结果。增加重置按钮，并在页面上写出模型假设。使用示例数据，控件只改变页面内的教学状态。",[10,155,156,157,161],{},"我们已经做出了",[14,158,160],{"href":159},"/learning/karpathy-understanding-ai-output/understanding-lab.html","这一个可操作的案例","。你可以保留回执，也可以把它删掉；还可以使用新的请求编号 B，或保留 A 的编号却改变请求数量。后两种操作让人继续追问：请求的“同一性”到底由什么决定？",[10,163,164,165],{},"这就是交互的价值。听到“重试不会重复执行”之后，你不必停在记住一句话。你可以把一个条件拿走，看看结论还在不在。现实接口的行为需要查它自己的文档；例如 Stripe 的幂等请求说明就明确列出了请求参数和记录保留时间的条件。",[14,166,169],{"href":167,"rel":168},"https://docs.stripe.com/api/idempotent_requests",[18],"Stripe 文档",[10,171,172],{},"用 agent 做这种页面，最值得检查的是规则和状态。按钮能动，只证明界面能响应。我们还要确认，每次变化都符合定义：保留回执时是否仍是七件，改变请求内容时是否明确拒绝，新编号是否执行新的操作。",[10,174,175],{},[54,176],{"alt":177,"src":178},"在定义的教学模型中，保留回执后重试留下七件；删除回执后重试留下四件","/blogs-img/2026-10-02-karpathy-02-retry-condition-v2.webp",[10,180,181],{},[61,182,183],{},"同一请求、不同条件。上排七件，下排四件；这是本文设定的教学规则。",[27,185,187],{"id":186},"第四步让视频带着注意力走过过程","第四步：让视频带着注意力走过过程",[10,189,190,191],{},"Karpathy 最看好的形式，是为任意主题制作定制讲解视频。他给出的尝试方向包括 3Blue1Brown 式的解释，以及用 ElevenLabs 做旁白；也提到可以寻找使用本地计算的免费替代方案。",[14,192,19],{"href":16,"rel":193},[18],[10,195,196],{},"视频适合解决另一个障碍：读者可能看到了所有对象，却不知道应该先注意哪个变化。",[10,198,199],{},"在刚才的案例里，最值得演示的瞬间是：操作已经成功，确认却没有到达。让观众跟着请求进入仓库，看到三件货被预留、回执被保存，再跟着返回消息走一段，直到它消失。画面停下来，观众才会同时理解两边的状态：发送者以为失败，接收者已经完成。",[10,201,202],{},"这里的 3D 和运镜有具体作用。空间位置帮助人记住请求、库存和回执；镜头沿着消息路径移动，表现先后顺序；拉回全景，让人把两边放在一起看。文字标签应当停得住，不能让读者一边追镜头、一边读解释。",[10,204,205],{},"向 agent 提要求时，也应该说明这份教学任务：",[90,207,208],{},[10,209,210],{},"为刚才的模型制作一段讲解视频。先让我看到任务已经完成、确认却丢失的差别，再演示同一请求如何重试。沿用同一组对象和编号。动画只表现状态或路径变化。给观众一次预测暂停，并在结尾说明模型没处理的情况。先交付旁白、分镜和一段有代表性的样片，再扩展成完整视频。",[10,212,213],{},"分镜、样片和暂停点，是我接着原帖建议加入的制作方法。它们让我们能在制作过程中审阅，而不是到最后才发现影片把错误讲得很顺。",[10,215,216,217],{},"Grant Sanderson 在 3Blue1Brown 的教学建议里强调具体例子，也提醒创作者避免让文字和公式无必要地移动。我很喜欢这个约束：每一次动画都应当有一个观众需要看懂的变化。",[14,218,221],{"href":219,"rel":220},"https://www.3blue1brown.com/about/",[18],"3Blue1Brown 官方建议",[27,223,224],{"id":224},"一次性软件为什么值得认真做",[10,226,227,228],{},"原帖里还有一个重要判断：模型可以为你生成专门的、用完即可丢弃的软件。过去，为一次讨论做网页，为一个概念做视频，制作成本往往不合算。现在，我们可以更频繁地试试这种交付。",[14,229,19],{"href":16,"rel":230},[18],[10,232,233],{},"这与长期产品开发有不同的目的。一个理解工具可以只服务于一次会议：帮团队看清某个假设，帮助一个学生理解变量，或者让接收研究的人找到结论依赖的条件。问题解决了，页面可以归档；经过讨论的判断和假设留下来。",[10,235,236],{},"它真正拓宽的是个人能提出的要求。面对陌生领域，你可以让 agent 为你量身定做一条进入它的路径。遇到难题时，除了要求“多写一点”，还可以要求“让我看见”“让我试试”“带我走一遍”。",[10,238,239,240,245],{},"我们之前做 ",[14,241,244],{"href":242,"rel":243},"https://www.aaronguo.com/blogs/your-dot-real-work",[18],"OpenAI Dot 的小世界"," 时，回放让人能指着一个时刻讨论发生了什么。Karpathy 这条帖让我更想把这种能力用在日常学习和工作中：接收一个结果的时候，也接收一条可以进入结果的路径。",[10,247,248],{},[54,249],{"alt":250,"src":251},"一张为一次讨论制作的小型纸面交互原型，放在两张工作椅之间","/blogs-img/2026-10-02-karpathy-03-one-question-v2.webp",[10,253,254],{},[61,255,256],{},"AI 生成的概念场景：一个理解工具，可以只为一个问题存在。",[27,258,260],{"id":259},"怎样把它用进下一次-agent-任务","怎样把它用进下一次 agent 任务",[10,262,263],{},"不必一次要求四种形式。先告诉 agent，你在理解上遇到了什么障碍，然后选一种能解决它的交付物。核对条件时用文字，比较关系时用图，探索变量时用交互，理解过程时用视频。任务简单，就让交付也简单。",[10,265,266],{},"我会在委托时加上这一段：",[90,268,269],{},[10,270,271],{},"完成任务后，请帮助我理解你的结果。我需要用它来作出什么判断？先解释结论、关键关系和假设，再选择能帮助我解决当前疑问的表达形式。如果适合交互，让我改变一个重要条件；如果适合动画，让我跟上真实的过程变化。保留来源，并给我一个可以检查理解的反例或预测问题。",[10,273,274],{},"接收时，我也需要做自己的那一部分：先说出预测，再操作；检查变化是否符合规则；找到结论依赖的条件；需要作决定时，回到来源、代码或运行记录。解释可能与原答案共享遗漏，换一种形式并不会自动增加独立证据。",[27,276,278],{"id":277},"用一个真实问题试试四种交付","用一个真实问题，试试四种交付",[10,280,281,282,285],{},"最后，用一个不需要编程背景的问题试试：",[44,283,284],{},"为什么詹姆斯·韦伯太空望远镜，要去地球外约 150 万公里？"," 这是 NASA 实际任务中的设计选择。我们借它做解释练习；下面的页面和分镜由我们制作。",[10,287,288,289,74,294],{},"NASA 的说明给出两条关键线索：韦伯在日地 L2 附近绕太阳运行；这个位置让太阳、地球和月亮能保持在遮阳板的同一侧。望远镜观测微弱红外信号，需要冷而稳定的环境，遮阳板帮助它隔开这些光与热。",[14,290,293],{"href":291,"rel":292},"https://science.nasa.gov/mission/webb/orbit/",[18],"NASA 轨道说明",[14,295,298],{"href":296,"rel":297},"https://science.nasa.gov/mission/webb/webbs-sunshield/",[18],"遮阳板说明",[10,300,301,304],{},[44,302,303],{},"文字，先让我们抓住原因。"," 可以让 agent 这样说：“韦伯需要保持很冷。太阳、地球和月亮都会带来光与热。L2 附近的位置让它们位于望远镜的同一侧，因此遮阳板可以挡在它们与望远镜之间。”不必先背下来“拉格朗日点”，先知道这项设计解决什么问题。",[10,306,307,310],{},[44,308,309],{},"图解，再让我们看清位置。"," 在同一张图上，把太阳、地球和月亮放在一侧，把遮阳板放在中间，把望远镜放在另一侧。读者就能指出：“原来要一起挡住的是这几个热源。”这是一张关系示意图，距离和大小没有按比例绘制。",[10,312,313],{},[54,314],{"alt":315,"src":316},"韦伯遮阳板的关系示意图：太阳、地球和月亮在热源一侧，遮阳板位于它们与望远镜之间；距离与大小不按比例","/blogs-img/2026-10-02-karpathy-04-webb-sunshield-v3.webp",[10,318,319,322,323,327],{},[44,320,321],{},"交互，让我们检查一个条件。"," 在",[14,324,326],{"href":325},"/learning/karpathy-understanding-ai-output/webb-output-lab.html","四种输出形式的实际演示页","里，可以分别显示三个热源的示意线，再隐藏遮阳板。观察原本止于遮阳板的线怎样延伸到望远镜，你就能回答：“只离地球很远，能代替遮阳板吗？”页面演示的是位置与遮挡关系，不能计算真实温度。",[10,329,330,333],{},[44,331,332],{},"视频，让我们沿着同一条理由走一遍。"," 先给出望远镜需要冷却的问题；再把三个热源放进画面；接着出现遮阳板，隔开两侧；拉远镜头，交代 L2 附近的位置。然后停下来，让观众预测隐藏遮阳板会发生什么。顺序和注意力都有了方向，事实仍然是刚才那一组。",[10,335,336,337],{},"这里还值得保留一个准确的细节：韦伯绕 L2 附近的轨道运行，并非固定停在那个点上。我们的图也没有把它画成躲在地球阴影里的望远镜。",[14,338,341],{"href":339,"rel":340},"https://science.nasa.gov/mission/webb/faqs-full/",[18],"NASA FAQ",[10,343,344],{},"把这份任务交给 agent，可以先指定来源和读者：“只基于这些 NASA 页面，帮没有天文学背景的人理解遮阳板与轨道位置的关系。先交回一段短解释，再做关系图和一个能检查遮挡条件的页面，最后据此写视频分镜。四种形式保持同一组事实，分别标明做了什么简化。”",[10,346,347],{},"同一个真实问题，文字给原因，图解给位置，交互给检查条件的机会，视频给观看顺序。这样使用 agent，我们既能学会一件具体的事，也能学会怎样要求它帮助我们理解下一件事。",[10,349,350],{},"这条帖让我兴奋，是因为它把 agent 的创造能力与人的理解需要连接了起来。我们可以让更多问题变得可见、可试、可接近。AI 做得越多，这样的交付就越值得认真设计。",{"title":352,"searchDepth":353,"depth":353,"links":354},"",2,[355,356,357,358,359,360,361,362],{"id":29,"depth":353,"text":30},{"id":66,"depth":353,"text":67},{"id":103,"depth":353,"text":104},{"id":132,"depth":353,"text":133},{"id":186,"depth":353,"text":187},{"id":224,"depth":353,"text":224},{"id":259,"depth":353,"text":260},{"id":277,"depth":353,"text":278},"认真读 Karpathy 关于 AI 输出形式的新帖：从清楚的文字、图解和交互网页，到定制讲解视频，怎样让 agent 帮你真正理解它完成的工作。","md",{"date":366,"image":367,"alt":368,"category":369,"tags":370,"youtube":374,"published":375},"2nd Oct 2026","/blogs-img/2026-10-02-karpathy-00-cover-v5.webp","一份答案展开成帮助理解的工具","ai-native-systems",[371,372,373],"karpathy","ai-workflow","visual-explanation","https://youtu.be/tVHBak748ik",true,"/blogs/zh/karpathy-understanding-ai-output",{"title":5,"description":363},"blogs/zh/37.karpathy-understanding-ai-output","fB23xHqRHcdWa-vPx1R29OxdQCpDh5LWKJ3kC0K4i4A",1791039244576]