Notion的设计工程师Geoffrey Litt最近在一场演讲里说了件挺反直觉的事：他每天用一个自己写的工具，逼自己在把AI写的代码发给同事之前，先做一遍五道题的小测验。答不上来，就不发。
这事的反常之处在于：现在的AI编程agent已经越来越擅长自我验证——写完代码自己跑测试、自己挑错、自己回头改。既然机器越来越会查自己的错，人类的审查还有什么用？Litt的答案是：审查的用处正在变小，但理解代码的必要性没有变小，只是换了个理由。
验证在贬值，参与没有
理解代码，过去主要是为了验证：看agent写的东西对不对、合不合规范、架构合不合理。这是个「对/错」的判断题，agent自己就能做得越来越好。
但Litt指出了另一层理由：理解是为了参与。一个项目从来不是一次性交付，而是agent和人之间无数轮迭代。你脑子里对这个系统的理解越丰富，就越有能力想出下一步该怎么改。理解不够，你能提的建议就越贫乏——你只能说「看起来还行」，说不出更具体的东西。
这跟另一个概念直接相关：认知债务（cognitive debt），由研究者Margaret Storey等人提出，逻辑跟技术债务一样——短期不理解可以蒙混过去，但迟早要还。区别是技术债务欠在代码里，认知债务欠在人的脑子里，还债的方式是「重新学一遍」，成本往往更高。
三件套：从教育学里搬来的方法
Litt给了三个具体做法，都不是新发明，而是把教育学的老套路搬进AI协作：
- 解释文档.他做的技能叫/explain-diff，不是甩一个代码diff给你，而是先讲背景、先给直觉、再讲代码——把原始diff重排成一篇「有逻辑顺序的说明文」，读起来比看diff快。
- 理解测验.文档末尾附五道题，答不上来不发代码，也不接收别人没读懂就发的代码。
- 微观世界.让agent专门写一个小工具，帮你「亲手」把变化跑一遍——比如做一个调试器逐步执行逻辑规则，或者做一个「命令中心」让你一步步点着看网站迁移过程，而不是被动看一份写好的diff。
这三招背后是同一个原则：不是agent替你理解，是agent帮你自己理解。前者是外包，后者才是参与。
好方法，但还只是一个人的方法
这套东西听起来漂亮，但得说清楚它现在的分量：这是一个资深工程师的个人实践总结，不是被验证过的团队方法论。没有使用规模数据，没有跟不做测验的对照组比较过维护成本、bug率或团队产出，Litt自己也没有拿出这类证据。
- 风险.解释文档、测验、微观世界这些手法，需要额外花时间生成和消化，一旦代码产出速度继续加快，理解辅助工具本身也可能被甩在后面——造工具的速度追不上agent写代码的速度，认知债务照样越滚越大。
这不是否定它的价值，而是提醒一件事：「借鉴教育学」这个类比只走了三成路。教育学解决的是「一个学生学一门确定的学科」，而AI协作面对的是「一群工程师追一个不断变形的系统」——学生和课本的关系是稳定的，工程师和agent写的代码之间的关系每天都在变。测验能检验你懂不懂昨天的diff，但检验不了你是否还跟得上系统整体的演化速度。
天下熙熙，皆为利来——放在这里稍微歪一点用：agent厂商真正的激励是让产品显得「更省心」，而不是「更需要人类理解」。这也是为什么解释文档、理解测验这类功能，至今主要靠个人自己搭，没有被Cursor、Copilot、Claude Code这类主流工具原生做成默认功能。厂商想让你少操心，Litt想让你多参与，这两个方向本身就有点拧着。
agent会查自己的错，不代表人类可以不懂自己的项目。
这场演讲真正有价值的地方，不是三个技巧本身，而是那个区分：验证的必要性正在被agent吃掉，参与的必要性没有。工程管理者该盯的不是「代码对不对」，而是团队还有没有人真的懂系统整体，还能不能在agent之外提出下一个像样的想法。这件事目前没有量化答案，只能靠每个团队自己观察——如果有一天没人能三言两语讲清楚系统现在的样子，那就是认知债务到期的那一天。