看不懂 AI 的回答？试试 Karpathy 的 4 种解释方式

把一段陌生代码交给 AI，让它解释原理。定义、流程、术语都齐了，读的时候似乎能跟上。可一问「这个条件变了，程序还会这样运行吗」，又拿不准了。

这时，再追问「能不能讲得更详细」，未必能解决困惑。你可能需要一张图，把几个对象的关系摆出来；也可能需要一个小实验，亲手改改条件。

Karpathy 在 2026 年 10 月 2 日的这条帖子里，分享了四项建议：让文字更清楚，生成图解，制作网页，再尝试定制讲解视频。它们都可以用来追问同一个问题：答案有了，我怎样弄懂它？

Karpathy 原帖开头的英文内容、页面中文译文与 STE 概览配图

原帖局部截图：截图中的「解释一下 ASD-STE100 中的某些内容」应理解为「按 ASD-STE100 的写作要求解释一个问题」。查看原帖。

下面先用一个简单例子读懂四项建议，再看已经做出来的案例。读完可以带走的，是更具体的请求：把你卡住的地方，变成 AI 需要讲清楚的任务。

一、读懂原帖

先用一道小题，把「得到答案」和「理解答案」分开。

下面的水箱例子和配套请求都是本文自拟的，用来说明原帖的几项建议。水箱一开始是空的，能装 10 升。水龙头每分钟向里加 2 升水，进水速度保持不变，没有水流出去。

装满需要多久？答案是 5 分钟。

要弄懂这道题，还得能回答几个问题：为什么用 10 除以 2？进水速度减半，时间为什么翻倍？如果水箱同时漏水，原来的算法该怎样改？

原帖接下来提到的几种表达形式，可以用来解释这些不同的困惑。下文对用途的划分是本文的分析。

文字太绕，先让 AI 把条件说清楚。

Karpathy 的第一项建议，是让模型按 ASD-STE100 写解释。他也会要求放松一些，写到接近规范的「80%」。这里的「80%」说的是写作要求可以放松一些，原帖没有提供评分方法。原帖

ASD-STE100 是一套最初面向航空维护文档的简化技术英语标准，包含写作规则和受控词典。它关注句子结构、词义和术语的一致性；许多清晰表达原则也可以借鉴到其他写作中。官方 FAQ

这个陌生的名字，先理解到这里就够用了：给模型一份具体的写作要求，让人容易看出谁做什么、条件是什么。

例如，同一道加水题可以写成：

在恒定流入速率及不存在液体损耗的条件下，达到容器容量上限所需时长，可由其容量与流入速率的比值确定。

也可以写成：

水箱一开始是空的，能装 10 升。每分钟进入 2 升，没有水流出去。装满需要 10 ÷ 2，也就是 5 分钟。

后一段先交代条件，再给出计算。如果卡在除法这一步，还可以补上：每分钟加进 2 升，10 升需要加 5 份，所以要 5 分钟。

这段中文示例是本文写的，借用了清晰写作的思路，没有检查它是否符合英文 STE 标准。

Karpathy 原帖 STE 概览图的中文译制版，保留英文词条与例句供对照

图 1｜原帖所附 STE 概览图的中文译制版。来源：原帖配图。放大查看 PNG；查看 SVG。图中的词数指英语单词数；个别词条需要回到官方标准核对，第三部分会给出一个具体例子。

这张图可以先看两处：A 区把规则和词典分开，说明「句子怎样写」和「词怎样用」都受约束；B 区把长句拆开，让动作与条件更容易辨认。不必一开始就记住所有条目。

下次遇到「读不出主干」的解释，可以这样问：

请用短句解释这道加水题。先说清水箱的初始状态、进水和出水条件，再用一个具体例子说明为什么要做除法。同一个概念使用同一个名称，保留算法成立的前提。

如果你还不知道什么叫流入速率，就把这个卡点说出来。句子缩短了，必要的知识仍然要补上。

关系拼不起来，就让 AI 画给你看。

接着，Karpathy 建议让模型生成图解或图片。他认为这些形式有时更容易理解。原帖

回到水箱题，文字告诉你「每分钟增加 2 升」。图可以把几个时刻排在一起：第 0 分钟是空箱，第 1 分钟有 2 升，第 2 分钟有 4 升，第 5 分钟装满。

把这些时刻画出来，就能看见时间与水量的关系：比较几个时刻的状态，也能看见水量每分钟增加 2 升。

可以继续请求：

把加水过程画出来，标出第 0、1、2、5 分钟的水量，保持刻度一致。说明图中的每个箭头代表什么，再用几句话告诉我应该怎样读这张图。

换成程序，图解可以展示函数之间的调用、数据从哪里来、错误进入哪个分支。画图时最值得说明的是箭头：它表示先后、调用、数据传递，还是因果？箭头的意思不清楚，读者仍然要猜。

想知道条件变了会怎样，就做一个能操作的网页。

原帖再往下，提到要求模型用 HTML 输出，制作交互网页或动画。原帖

HTML 是编写网页的语言。在这里，可以先把它理解成一页用浏览器打开的解释材料。它可以放文字、图形，也可以允许读者操作。

例如，把水箱容量和进水速度做成可以修改的数值，页面根据公式显示装满时间。保持容量 10 升、起始为空且没有出水，只把进水速度从每分钟 2 升改成 1 升，结果就应当从 5 分钟变成 10 分钟。

可以把请求写具体：

做一个解释这道加水题的单文件 HTML 页面。让我修改水箱容量和每分钟进水量，显示计算公式、装满时间和水量变化。容量必须大于 0，进水量不能为负数。明确初始为空、进水恒定且没有出水；进水量为 0 时说明无法装满，并提供重置操作。

你可以先猜会发生什么，再改条件，检查结果和自己的判断是否一致。如果结果不同，就回头看假设和计算。这样就多了一种理解题目的办法。

页面需要明确显示公式和限制，才能帮助读者检查解释。Bret Victor 的《Explorable Explanations》讨论的正是这种阅读方式：让读者调整假设、观察后果，并能查验模型和资料。这个联系来自本文的补充阅读，原帖没有引用这篇文章。

这里说的水箱页面仍是一个设计示例。后面会看一个已经生成的 HTML 产物，检查它实际提供了哪些操作。

卡在变化过程上，让视频带你走一遍。

Karpathy 最看好的是按指定主题定制讲解视频。他举了 3Blue1Brown 风格讲解与旁白配音的请求，也提到可以寻找使用本地计算资源的替代配音方案。这是他的积极体验与期待，帖子没有给出学习效果测试。原帖

同一道水箱题，视频可以从空箱开始，逐步显示水位升高。旁白解释此刻发生了什么，再把进水速度减半，演示两次加水过程的差别。

可以这样提出要求：

围绕这道加水题制作一段讲解视频。先说明为什么用容量除以每分钟进水量，再保持其他条件不变，演示进水速度减半后的变化。画面与旁白说同一步，交代计算前提。请先给分镜；制作完成后，另行交付可播放的成片。

视频把图、声音和时间顺序放在一起：读者跟着一个对象，连续观察它的状态变化。类似做法也可以用于讲解一次请求如何经过几个服务，或一个算法怎样逐步更新数据。

如果观众只想查某个参数的含义，能够直接定位的文字或静态图也有用途。原帖连续引出更丰富的形式，阅读时仍要保留一个判断：当前到底是哪一步需要解释？

Karpathy AI 输出改进指南中文概览：文字、图解、HTML 解释页与讲解视频

中文概览图，用于回看四种解释形式的不同用途。

英文图可通过查看英文概览图打开。来源为 sunick（@Serantych）的引用转发，概括了文字、图解、HTML 和视频四种表达形式；图中的排列与箭头没有证明学习效果逐级提高。

最后一段，把这些做法接回工作的变化。

Karpathy 预期，模型会自主承担更多具体工作，人则需要更多监督与理解。随着生成代码更容易，我们也可以为眼前的问题制作定制网页、讲解视频等临时产物。原帖结尾

放到一个具体场景里：AI 写完一段程序以后，你还需要知道它在哪些条件下能工作、失败时会怎样。于是，可以继续要求它提供解释材料，帮助你检查这些问题。

「用后可弃」也容易理解。为弄懂一道题做的网页，完成解释任务后，可以不再长期维护。它的用途和一个持续运营的产品不同。需要复核的原文、代码版本、假设和计算，仍然值得留下。

模型既能完成工作，也能帮助人理解工作结果，这就是原帖的主线。接下来要检查的，是这些解释材料具体怎样帮助人理解结果。

二、查看实际案例

案例一：把一篇技术文章整理成一页 HTML。

比如读一篇介绍 Agent 的文章，你认识几个术语，却仍想追问：「工具结果回来以后，谁决定继续做什么？」把角色和反馈路径放在同一页上，可以帮你沿着这个问题找答案。

云辰 Cyan 在这条实践帖中引用了 Karpathy 原帖，并介绍了 answer-me-with-html。这个项目让模型先写简短的扩展 Markdown 内容稿，再由配套 CLI 处理模板、面板和图形布局，生成单个 HTML 文件。

可以把它理解成两步：先决定讲什么，再由程序把内容排成页面。模型需要说明关系，排版程序负责把关系画出来。

这次学习做了一次本地实践：将 Tyron 的《什么是 Agent》整理成内容稿，再生成解释页。本次采用的安装命令是：

npx -y skills add QingYunA/answer-me-with-html -g -y -a codex

安装后还需读取 Skill 的使用说明，按内容稿格式调用渲染工具。这条命令只负责安装。

已生成的 HTML 解释页可以直接预览效果，也可以查看源码。页面包含四块内容：

• 核心定义：先交代模型选择下一步、应用执行工具、结果返回模型这几个角色与动作。
• 决策与执行循环：把模型选择、应用执行、工具反馈连成流程图。
• 谁决定下一步：并排比较普通问答、Workflow 与 Agent。
• 常见误区：交代 RAG、记忆、MCP、Skills 各自负责什么。

要检查前面的问题，可以顺着流程图中的工具反馈，回到模型选择，再到原文里核对这条关系。页面把定义、过程、比较和限制放在不同位置，方便读者寻找具体问题。

内容稿也保留了下来，可以和原文、页面一起对照。这次已经生成了内容稿和页面，没有进行读者理解测试。

这个页面主要提供静态概览，能做的操作包括主题切换、明暗切换和复制源稿。它没有水箱示例那种「改变条件，重新计算结果」的控件。所以，要判断 HTML 有什么用，还得看页面实际做了什么。

项目作者还报告了一次小规模基准测试：用同一个模型，对三个主题各做三次。使用配套工具后，输出 token 的中位数和完成时间下降，但报告中的每次费用略有上升。这些数据由作者测量，本次没有复测；它们可以帮助了解模板分工的效果，不能说明读者学会了多少。作者的测量说明

案例二：一段讲解视频，背后还有资料和验收。

想知道「一段看起来顺畅的视频，怎样检查它有没有讲错」，可以看一个公开的制作案例。Vanja Petreski 在《The Explainer Video Is the New TL;DR》中展示了一段 4 分 25 秒的视频，并介绍制作过程：研究资料、核对引用、组织脚本，使用 Kokoro 配音、Whisper 对齐语音，再用 Remotion 制作画面，最后抽帧检查。

这次学习最值得看的细节，是作者怎样核对事实。作者报告，第二次事实检查仍然修改了四条说法；引用与原文逐字匹配，也没有自动解决所有内容问题。作者的过程记录

引文可以抄对，解释却可能推错。资料本身也可能有时效或范围限制。画面与配音做好以后，这些问题仍要检查。

作者还检查了画面的遮挡、拥挤和字幕位置。做视频时，既要处理「讲什么」，也要处理「怎样让人看清」。本次阅读了作者的过程记录，没有逐段播放验收该视频，也没有观众学习效果数据。

这两个案例把原帖中的设想做了出来，也展示了可以复用的制作流程。接下来还得问：材料是否讲对，操作是否有意义，读者是否理解。

三、检查边界

第一道检查：表达变简单以后，事实和条件还在吗？

水箱题里，「开始时为空」「进水速度恒定」「没有水流出去」都决定算法能否适用。缩短句子时如果把这些条件删掉，读者可能记住 5 分钟，却误以为任何情况下都能套用这个答案。

Lucian Ghinda 的公开实验提供了一个有用提醒。他比较不同写作要求下的代码解释，后来发现：自动检查器用关键词和正则表达式判断解释有没有提到某项事实，会把一部分同义表达误判成遗漏。人工复核修正了早期结果，严格 STE 版本也仍有事实遗漏。

所以，检查短句时，要逐项核对实际含义；读到一个「遗漏率」时，也要看检查器怎样认定遗漏。这个实验样本有限，衡量的是解释涵盖了多少事实，不能用来给读者理解程度打分。人工复核说明

原帖配图也适合这样核对。图 1 把 approximately 标为不准用，并建议改成 ABOUT。但 ASD 官方 FAQ 明确说明，ABOUT 的准用含义是「关于」，不能拿它表示「大约」；APPROXIMATELY 本身是准用词。这处概览与官方说明不一致，译制图保留了原图内容，使用词条时应回到标准。官方 FAQ 的词义说明

这件小事也解释了为什么「看起来像规范」和「已经核验规范」需要分开。标准名称、图解与检查工具，都需要与实际规则对照。

第二道检查：展示有没有把关键机制显露出来？

一张图可以有清楚的箭头，但读者仍不知道箭头对应哪一步代码。一个网页可以切换主题，却不让读者修改那些会影响结论的条件。一段视频可以流畅播放，但旁白说的对象已经从画面消失。

检查时，可以问得更具体：

• 图中的一个节点，对应原文或代码里的什么？
• 修改页面中的一个条件，计算和解释会怎样更新？
• 动画里的状态，来自真实记录、模型计算，还是教学示意？
• 需要核对一句主张时，能否找到它的来源和适用范围？

这些问题是要看解释具体做了什么。教学示意也有用途，前提是明确告诉读者它简化了哪些条件。

第三道检查：离开材料后，能不能自己说明？

可以把水箱示例稍微改一下：仍然从空箱开始，容量 10 升，恒定地每分钟进水 2 升、同时流出 1 升。先别看解释，试着说出装满需要多久，以及算法为什么改变。

关键在于能否说明：水量每分钟净增加 1 升，所以装满需要 10 分钟。如果流出速度等于进水速度，水量就不会增加，空箱无法按这个设定装满。

这个小练习只是帮助发现自己卡在哪里，不能代表对一个主题的完整掌握。它比单问「看懂了吗」多了一件可以检查的事：你能否独立解释条件与结果的关系。

Digital.gov 的释义测试指南也建议让读者用自己的话说明材料，再追问据此会做什么。本文借这个思路检查自己的阅读，没有把它作为已经完成的实验。

可以分别看三个结果：内容与依据是否一致，展示是否帮助找到关系，自己是否能说明或使用这些关系。页面生成成功，只能说明页面做出来了。

四、形成自己的理解

这次阅读之后，原帖里最值得带走的，是一种提出解释要求的方法：先说清自己卡在哪里，再选择能够显露那个问题的表达形式。

如果卡在一句话里，就请模型交代主语、动作和条件；如果卡在几个对象的关系上，就让它画出关系；如果卡在「换个条件会怎样」，就需要可检查的计算与操作；如果卡在连续变化上，可以尝试按时间展开的讲解。

下面把这件事放进两个使用场景。提示词都是本文拟写的建议，不把它们当作已经验证效果的模板。

场景一：读一篇陌生的技术文章。

本地 HTML 案例已经展示了一条可执行的路径：读取原文，组织内容稿，生成概览页。下一次使用时，还可以具体说出自己缺哪一部分知识。比如，知道几个术语，却不知道它们怎样连起来，可以这样请求：

请根据这篇原文解释我圈出的这一段。先说明理解它所需的前提，再用一个具体例子走完过程。把原文直接说明的内容与你补充的解释区分开，保留来源位置。遇到原文没交代的地方，请指出缺口。

读完以后，如果仍然拼不出关系，再追加：

把刚才的过程画成一张图。节点对应具体对象，每条箭头标明它表示的动作。再拿一个输入沿图走一遍，说明每一步发生了什么。

需要反复对照定义、流程和区别时，可以继续整理成 HTML 概览页。随后关掉页面，用自己的话说明过程，再回原文检查遗漏的条件。这些步骤是本文的建议。

场景二：检查 AI 刚写完的一段程序。

假设 AI 写了一段批量处理程序，你最担心的是「处理到一半失败，已经完成的部分会怎样」。这个场景直接对应原帖结尾的监督需求：代码有了，还需要判断它的行为。

可以先把要解释的范围说清楚：

根据这份实际代码，解释一个批次从输入到结束的过程。重点说明中途失败后的分支、已完成状态和重试行为。引用相关函数或代码位置；代码没有实现的行为，请明确指出。

如果文字仍然难以追踪，可以追加：

用一个具体输入逐步展示状态变化。将根据代码推导的结果、实际运行记录和教学简化分别标清。存在不确定行为时，说明还需要检查什么。

生成的说明可以帮助你找到需要检查的地方。要确定程序真正会怎样运行，仍需根据实际代码、配置和合适的运行验证来判断；教学动画不提供一次真实执行记录。

这两个场景都需要让解释围绕一个可回答的问题展开。读陌生文章时，要能连接原文里的概念；检查程序时，要能追踪一个输入和失败分支。判断一种形式是否有用，可以看自己能不能做出这些具体动作。

原帖对生成能力的乐观，让这种做法有了新的可能。本次学习给它补上的使用习惯是：保留原文和假设，核对解释中的条件，再用自己的说明、预测或操作检查理解。

下次遇到一份看不懂的 AI 输出，可以从一句具体的话开始：

我卡在这一点。请把它讲清楚，并给我一个能检查自己是否理解的例子。

之后得到的图、网页或视频，才有了一个明确的任务。

本文的行文参考了 ChallengeHub 的相关文章：从读者的困惑切入，把建议接到具体请求。原帖解读与案例核验仍依据文中所列的一手来源，水箱示例和请求由本文拟写。

karpathy-knowledge-panorama.png