Notion 的设计工程师 Geoffrey Litt 认为还是要看懂，但理由不是为了检查它对不对。他把这场演讲的三套做法都摊开讲了，包括自己每天在用的一个 skill。
2026 年 7 月，Litt 在 AI Engineer 大会上从一句他自己标为 hot take 的话开始：人依然需要看懂 agent 写出的代码。这个立场如今需要专门辩护，因为主流方向正是让人逐渐退出 loop。
他没有回避压力所在。agent 写出的代码越来越多，人很难继续逐行跟上。人们通常通过 diff 查看一次代码改动的前后对照，再完成 code review，但他的判断是，看懂代码并不只有逐行阅读 diff 这一条路。
这场演讲给出三样东西：代码讲解文档、检验自己理解程度的测验，以及可以上手玩的微世界。它们也构成了后面三节的主线。
在他的框定里，代码量涨上来之后，问题不是「还读不读」，而是除了逐行读 diff，还有没有别的读法。
一种自然的疑问是：既然目标已经变成让 agent 自己循环，模型又在持续变强，人是否还需要进入代码细节。Litt 认为，多数人对这个问题的回答其实差了一层。
一个常见答案是，看懂是为了验证，也就是他所说的 understand to verify。人需要判断 agent 是否完成了任务，结果是否符合规格，采用的架构是否合理。无论检查过程多复杂，最终都要落到一个通过或不通过的判断上。
他认为这个答案不足以说明问题：agent 自我验证的能力正在持续变强，而他本人乐见 agent 不出错。但如果验证逐渐由 agent 自己完成，只把理解的价值放在验证上，人的位置就会随之缩小。
他的答案是，看懂是为了参与，也就是 understand to participate。一个项目从来不只有一个 loop，而是由很多个连续的 loop 构成。想出下一个演进方向的能力，一部分就来自人对系统的理解。在他看来，如果脑中没有一套足够丰富的概念，人就难以流畅而有创造性地推动项目，参与项目的能力也会受到实质限制。
“It's never just one loop!”
他用认知债（cognitive debt）解释这种风险。认知债是赶进度时欠在人脑中的债：代码已经交付，参与者却没有理解它在做什么，以后需要修改时便无从下手。这个概念由 Margaret-Anne Storey 和 Simon Willison 推广开来，他的幻灯片将前者署名为 Margaret Storey。
Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.—— Margaret-Anne Storey，Cognitive debt（加粗为 Litt 幻灯片上的加粗）
他把认知债与技术债作类比。技术债是为赶进度留下的代码层面欠账，日后修改或扩展时需要付出更多成本；认知债欠下的则是人对系统的理解。短期内缺少理解未必会阻止代码交付，但项目继续演进时，这笔债终究会影响人的参与。
于是问题转向如何建立理解。他的答案来自教育学：人类早就在研究怎么把理解讲清楚、传给别人；他的问题是，能不能把其中最有效的思路搬到人与 AI 的协作上来。
第一套技术落在一个具体工具上：他自己写的 /explain-diff。这是一个 Claude Code skill，也就是给 coding agent 预置的一套可复用指令，用斜杠命令调起。agent 每完成一段工作，它就为这次改动生成一份讲解文档，他先读讲解，再读代码 diff。
代码 diff 是一次改动最原始的材料，却不是为讲解而组织的。他因此换了一个问法：假设有一个团队，无论由人还是 AI 组成，真的投入精力把这次改动讲明白，他们会交付一份什么样的讲解。他就是照这个问法设计的这个 skill。它是他个人编写并以 gist 形式公开的 skill，不是 Notion 或 Anthropic 的官方产品；他自己每天使用，也提到不少同事认为它有用。
skill 输出三种形态：HTML、markdown、Notion 文档。他认为 Notion 文档适合团队围绕讲解协作和讨论，同时主动说明自己在 Notion 工作、所以有立场偏向。
skill 文件里写死了四个段落，顺序也是固定的，两个变体一致。以下取自公开的 skill 原文，不是演讲讲稿：
他用一次电子游戏视角改动来演示这份讲解长什么样。文档先讲原来有什么，包括这个游戏引擎如何运行；然后在任何代码之前先说明目标，大意是「用二维绘图技巧让这个花园显得有立体感」，并解释等轴测投影这类概念。等轴测投影是一种用二维画面表现三维空间的画法，游戏常用它让平面场景呈现立体感。他说，这样安排是先让他这个人跟上进度，使他能够在理解上成为平等的参与者。
他还在文档里放可交互的小图：拖动花园里的石头，看坐标怎么变，用这个方式建立对等轴测视角的直觉。他提到 Notion 刚上线了页面内嵌可交互 HTML 的功能，这类图示可以直接放进讲解文档。
到了看代码这一步，典型 diff 会按文件名排列改动，往往是多个文件依次展开，没有解释，也没有为理解而设计的阅读顺序。他把自己的组织方式称为 literate diff：把一次改动按讲解顺序重新组织成散文，按一条说得通的顺序逐段讲解，在前后补充解释，并嵌入对应的代码片段。他的判断是，这样比直接阅读原始 diff 更快完成 review。
最终得到的是一份完整的讲解包。他仍然会读代码 diff，但总是先读这份讲解。他也指出其中的反讽：AI 把原本需要交互完成的事情变成一份静态纸质报告，反而让他能够集中注意力。
“It's beautifully ironic: AI turns an interactive activity into a static paper report I can focus on deeply”
不过他自己点出，这里还剩一个问题：阅读本身就是件费力的事。Andy Matuschak 用 books don't work 概括其中的问题，人很容易以为自己已经读懂，实际却没有记住，也没有形成足够清楚的理解。
他的应对受到 Matuschak 和 Michael Nielsen 的工作启发。他们把 spaced repetition 直接放进在线文章。这是一种记忆方法，做法是按逐渐拉长的时间间隔反复考问自己。Quantum Country 就采用了这种设计：测验题嵌在正文中，读者一边读，一边回答与内容相关的问题。
他把这个思路接到代码讲解里。现在每份讲解文档底部都有一道交互测验，五道题，内容都与这次改动有关，由他自己作答。他给自己定的规矩是，在通过测验以前不会把代码发给别人；评审别人的代码时也遵守同一条规矩。
“My rule: I won't send code to others until I can pass the quiz, and I do the same when reviewing others' code.”
“A quiz is a speed regulator.”
这就是 /explain-diff。他把这个 skill 公开了，演讲现场用二维码给出入口，公开版本有两个变体，一个输出 HTML，一个输出 Notion 页面。两个变体在测验的实现上并不相同：HTML 变体要求做成可交互多选题，点击后告知对错并给出反馈；Notion 变体要求每题的选项都配一段解释为什么对或错，用 toggle block 承载，每段解释前用 ❌ 和 ✅ 标出对错。
YYYY-MM-DD- 开头，理由是便于按时间排序、且不会进版本控制<pre>；若改用自定义样式的 div，CSS 里必须有 white-space: pre-wrap，否则浏览器会把换行折成一行；存盘前逐个扫一遍确认Notion 变体也要求带示例数据，但写成了对所有图示的通则，而非只针对系统图。
站内 《找出你的 Unknowns》 里也出现过一条「生成 HTML 报告 + 底部测验，全对才 merge」的 prompt。那篇讲的是动手前怎么把 unknowns 说清楚，测验只是收尾的一条 prompt；本篇给的是完整的 skill 原文，以及「为什么还要看懂」这一层的重构。
第二套技术不要求人直接读代码，而是让 agent 另写一个可以操作的小程序，人通过使用它理解原来的代码在做什么。思路来自教育学者 Seymour Papert。
Papert 的问题是能不能造一个环境，让孩子出于好奇心自然学会数学。Litt 把这个旧想法迁移到代码理解上：能不能造出一些可以进入和操作的世界，让人置身其中，自然领会一个系统如何运行、又在发生怎样的变化。他给了两个亲手做过的例子。
Prolog 是一种逻辑式编程语言，程序由一组规则构成，运行时通过不断匹配规则来推导答案。他特别区分了两件事：做一个工具供自己调试，与让 agent 直接完成调试并不相同。亲手操作和观察，才是他逐步形成理解的过程。
“There's a big difference between making a tool for me to debug and letting the agent debug”
第二个案例来自网站的框架迁移。Claude 写了一个脚本，一次完成了整个迁移，但他不熟悉新框架，很难真正评审结果，当时能说出的全部判断只是「大概看着是对的」。
“I guess that looks about right.”
他在这个指挥台里看着新站一点点活起来。他说这个过程让他对这次迁移的理解，接近亲手做一遍所能达到的程度，但速度快得多，因为每一步已经提前组织好。
在他看来，这件事的分量很重：agent 可以写一些代码，帮助人类理解另一些代码。
在他看来，前面的做法处理的是一个人如何理解代码，而团队工作还需要共同理解。
他的说法是，当两个人脑中有同一个模型时，一套共享词汇就能唤起相近的画面，双方才能接住彼此的思路并继续推进；缺少这些共享结构，沟通会困难得多。他表示自己很关注如何创造一种环境，让团队共同建立理解，并认为这与 Notion 正在做的事情接近。这里涉及他任职的公司，也带有他前面已经说明的立场。
他给的具体例子是，Notion 最近上线了一些让人和 agent 共同工作的功能，目标是让团队形成共同理解，而不是各自在孤立环境中工作。现在可以在 Notion 里运行 Claude 和 Cursor 的 agent，他自己许多编码工作也采用这种方式。当这些 agent 在 Notion 中生成技术方案时，方案默认出现在协作页面上，他可以立即评论并与团队讨论。
“Thinking together, not alone!”
三套技术都在回答怎样理解代码，但在他看来，它们背后还有一个更大的问题：人仍然需要理解事物如何运转。理解不只是为了验证，也是为了参与。
这个想法并不新。五十年前，计算机科学家 Alan Kay 就提出过类似设想。Kay 是个人电脑与图形界面的早期设计者之一，长期主张计算机应该成为一种帮助人思考的新媒介，可以比书更进一步，用来教人、尤其是孩子，怎样理解这个世界。
在他看来，计算机原本追求的就是增强人的能力，而不只是替人完成工作。他说，AI 让做模拟这件事的门槛低了很多，这是件美妙的事；而让 AI 来教我们，是计算机这门技术出现以来最了不起的可能之一。这正是他对未来感到乐观的原因。
“The point was always to augment, not just automate.”
If we build the right tools, we can now understand the world better than we ever could before. We don't have to merely take ourselves out of the loop, we can get deeper in the loop too. It's up to us.—— Geoffrey Litt，演讲收尾
geoffreylitt.com · 2026-07-02 · Geoffrey Litt（Notion 设计工程师）。作者在 2026 年 7 月 AI Engineer 大会的演讲文字版，逐页幻灯片配讲稿共 35 页。本文只整理他的论点与做法，不附加评价、启示或建议；他本人的判断均已挂归因。
/explain-diff skill 两个变体
gist.github.com · 作者本人公开。第三节里「skill 规定了什么」一段取自这两个文件本身，不是演讲讲稿；四个段名与格式规则均按原文分组，共用规则与各变体专有规则已分开列出。这是他个人编写的 skill，不是 Notion 或 Anthropic 的官方产品。
margaretstorey.com · 2026-02-09 · Margaret-Anne Storey（维多利亚大学计算机系教授）。演讲第 9 页引用了这篇，本文据原文核对引文并解释 cognitive debt 的含义。Litt 幻灯片上的署名为 Margaret Storey。
本页 .source-figure 内的图片均为作者演讲幻灯片的引用，逐张注明出处并链回原文。站点内容安全策略不允许外站图片，故存为站内副本引用，未作任何裁剪或修改。概念图（三帧推进、diff 对照、速度阀、两个自制工具界面）为本站按原图重画，图注已标明。