作者注：以 Addy Osmani 的“认知投降”与“理解债”观点为主线，整理一套 PR 合并前的自检清单与 Prompt 模板，并对比 LobeHub 依赖验收报告的审查思路，帮你按风险选择审查强度。
如果你每天用 Claude Code、Cursor 或 Cline 交付代码，可能已经有过这种体验：Agent 几分钟交出一个几百行的 PR，命名规范、结构清晰、测试全绿，于是你点了“批准”。几周后有人问这段逻辑为什么这么写，你却答不上来。本文围绕 “让 AI 出题考你”等可执行的检查动作，帮你在不逐行审查的前提下，依然对自己批准的每一次改动负责。
这不是一篇劝你回到手写代码的文章。Claude Code 工程师 Addy Osmani 本人就明确表示，没人要求工程师记住整个代码库；问题不在于读不读每一行，而在于你是否知道自己懂什么、不懂什么。
核心价值：读完本文，你将理解“认知卸载、判断让渡、认知投降”的递进过程，拿到一份可直接复制的合并前提问清单和 Prompt 模板，并学会按改动风险选择审查强度。
别给 Agent 盖章：理解债核心要点
据量子位报道（经 36 氪转载），前 Google 工程师、现参与 Claude Code 工作的 Addy Osmani 发文讨论了一个扎心的问题：AI 生成的东西越可靠，人类就越不认真检查。他把这个过程拆成几个递进阶段，并提出了两种新型“债务”。需要说明的是，以下概念均来自媒体转述，具体措辞请以 Addy 原文为准。
| 概念 | 含义 | 典型表现 |
|---|---|---|
| 认知卸载 | 把具体工作交给 AI，但自己仍理解任务、能判断结果 | 让 Agent 写样板代码，你清楚它在干什么 |
| 判断让渡 | AI 的答案逐渐成为下一步工作的默认依据 | 第二次只扫两眼，Agent 说什么就按什么推进 |
| 认知投降 | 连本该自己完成的判断也交了出去 | “AI 说得肯定有道理”，测试全绿直接合并 |
| 理解债 | 代码和系统复杂度增长，开发者的理解却没跟上 | 要改功能时没人摸得清内部结构 |
| 意图债 | 需求中没说清的目标、限制和取舍被 AI 替你决定 | 自己没想清楚要什么，Agent 却交出像样的成品 |
认知投降与理解债的递进过程详解
认知投降不是一夜之间发生的。最初你只是“卸载”具体劳动，这本身并没有问题，就像用编译器而不手写汇编。危险在于第二阶段：当 Agent 的输出连续几次都靠谱，它的结论会悄悄变成你的默认前提，你开始跳过验证。到了第三阶段，“批准”按钮变成了一枚印章，你的角色从工程师变成了盖章员。
Addy 举过一个很典型的例子：Agent 一口气提交 600 行代码，结构清晰、测试通过，开发者放心合并。但 Agent 可能在不起眼的地方改了事务处理顺序，或者调整了某个边界条件。这些改动当时不会报错，等系统真出问题时，开发者才发现自己解释不清代码为什么这么运行。这就是理解债的“利息”，它总在最不方便的时候到期。
意图债则发生在更上游。现在的 Agent 太擅长补全需求了，哪怕你没想明白，它也能交出一份看起来很合理的作品。问题在于，那些你没说清的目标、范围和取舍，已经被 AI 默默替你拍板了。意图债和理解债往往叠加出现：你既不清楚自己当初要什么，也不清楚 Agent 最终做了什么。
偿还理解债的 6 个方法
Addy 在长文中分享了不少实操建议。下面把它们整理成 6 个方法，并标注各自对应的是哪一种债务、在工作流的哪个环节使用。
| 方法 | 使用时机 | 主要偿还 | 一句话动作 |
|---|---|---|---|
| 1. 让 Agent 出题考你 | 大型改动完成后、合并前 | 理解债 | 先总结改动和原因，再出题，全对才合并 |
| 2. 动手前写需求清单 | 写 Prompt 之前 | 意图债 | 写清面向谁、解决什么、不做什么、完成标准 |
| 3. 追问未授权决定 | 长任务结束时 | 理解债、意图债 | 问它做了哪些你没授权的决定、依赖了哪些假设 |
| 4. 追问没测什么 | 看测试结果时 | 理解债 | 先看实际执行的测试和输出，再读 AI 总结 |
| 5. 保留原始材料 | 多 Agent 并行时 | 理解债 | 重要任务保留原始资料和验证依据，审不过来就减并行 |
| 6. 定期离线练习 | 每周、每月 | 能力退化 | 每周一次不依赖 Agent 的编码，每月盘点外包了哪些技能 |
让 AI 出题考你：最核心的理解债检查动作
这是整套方法里最有意思的一招。Agent 完成一项大型修改后，先别急着点通过，而是让它扮演考官：总结这次改了哪些地方、为什么这么改，然后根据修改内容出几道题，并立下规矩，只有全部答对才能合并。它的价值在于把“我大概看懂了”这种模糊感受，变成可检验的结果。答不上来的题，恰好就标出了你理解债的具体位置。
追问未授权决定与没测什么
长时间运行的任务里，Agent 会自行选择默认参数、调整实现范围，甚至在需求冲突时做取舍。这些决定未必会写进最后的总结，因为它们“太自然了”。所以比起问一句“完成了吗”，更有效的是追问：你做了哪些我没明确授权的决定？哪些地方依赖了你自己的假设？还有什么没验证？哪些改动可能影响其他功能？
测试也是同理。Addy 特别提醒，绿色测试只证明测试覆盖到的条件通过了，边界情况没写进测试，报告照样可以很漂亮。正确顺序是先看实际执行了哪些测试、返回了什么结果，再去读 AI 生成的总结。对于高风险修改，还可以让另一个 Agent 从不同角度独立找问题。
合并前自检流程快速上手：别给 Agent 盖章的 5 步
把上面的方法串起来，就是一套可以在每个 PR 合并前执行的流程。它不要求逐行审查，但要求你在每一步都留下“脑子转过”的痕迹。
- 开工前写预期：用自己的话写下需求说明和你预期会发生什么。如果连续调整两轮 Prompt 仍不满意，回头重梳需求，而不是继续堆提示词。
- 要求交代决定：任务结束后，让 Agent 列出未授权决定、假设和未验证项。
- 核对真实测试：看实际运行的测试命令和输出，追问哪些边界没覆盖。
- 让 Agent 出题：基于本次 diff 出题自测，答错的部分回到代码里读清楚。
- 找一件漏检的事：在 Agent 交卷后，主动找出至少一件它可能没检查到的事。
理解债自检极简 Prompt 示例
下面是最常用的“出题考我”Prompt，可以直接粘贴到 Claude Code、Cursor 或 Cline 的对话中使用：
在我合并这次改动之前，请先做两件事：
1. 用不超过 10 条要点总结本次改了哪些文件、每处改动的原因。
2. 根据本次 diff 给我出 5 道题，重点覆盖：事务/调用顺序、
边界条件、错误处理、对其他模块的影响。
先只给题目，等我作答后再批改，并指出我答错的地方对应哪段代码。
规则：我没有全部答对之前，不要建议合并。
查看完整的合并前提问 Prompt 模板
# 阶段 A：开工前（偿还意图债，由我先填写）
需求说明：
- 面向谁：
- 要解决的问题：
- 明确不做的事：
- 完成标准（做到什么程度算完成）：
- 我预期的改动范围和结果：
# 阶段 B：任务结束后（请 Agent 逐条回答）
1. 你做了哪些我没有明确授权的决定？请列出决定内容和理由。
2. 哪些地方依赖了你自己的假设？假设不成立时会发生什么？
3. 还有哪些内容没有验证？
4. 哪些改动可能影响其他功能或模块？
5. 你实际运行了哪些测试命令？请贴出原始输出，而不是总结。
6. 哪些边界情况没有写进测试？
# 阶段 C：出题考核（偿还理解债）
请根据本次 diff 出 5 道题，先只给题目。
我作答后请批改，答错的题请定位到具体代码行。
我未全部答对前，不要建议合并。
# 阶段 D：高风险改动追加（可交给另一个独立会话）
请你作为独立审查者，不参考上一个会话的总结，
只基于原始需求和 diff，找出最可能出问题的 3 个地方。
🎯 使用建议：阶段 A 一定要在开工前由你自己填写，而不是让 Agent 代写。阶段 D 建议新开会话，避免独立审查者被前一个 Agent 的总结“带节奏”，这也呼应了 Addy 关于多 Agent 传话损耗的提醒。
合并前提问清单速查表
| 环节 | 必问问题 | 不合格信号 |
|---|---|---|
| 开工前 | 我能用自己的话说清需求和完成标准吗？ | 写不出“不做什么” |
| 交付后 | Agent 做了哪些未授权决定？ | 回答“没有”，但 diff 明显超出范围 |
| 测试 | 实际跑了哪些测试？没测什么？ | 只有总结，没有原始输出 |
| 考核 | 出题我能全对吗？ | 事务顺序、边界条件类题目答错 |
| 收尾 | 我能找出一件它漏检的事吗？ | 一件都想不出来 |
让 AI 出题考你 对比 验收报告式审查
另一种截然不同的思路来自开源 Agent 协作平台 LobeHub（GitHub 约 8.4 万星）。据白鲸实验室报道，该团队自称“已经几乎不看代码了”，核心看的是 Agent 的多模态验收报告。他们使用自研并于今年 9 月开源的工具 Acceptance：Agent 交付前把需求拆成可直接观察的检查项，在真实产品里逐项运行，配上截图、录屏和日志，汇总成在线报告。人可以整体通过，也可以单独退回某一项。
| 维度 | 让 AI 出题考你 | 验收报告式审查 |
|---|---|---|
| 关注对象 | 代码内部逻辑、未授权决定、假设 | 产品外部可观察行为 |
| 证据形式 | 问答、批改结果 | 截图、录屏、日志、命令记录 |
| 能发现的问题 | 事务顺序、边界条件、隐性取舍 | 界面、交互、功能是否符合需求 |
| 容易漏掉的问题 | 你没想到要出的题 | 不可见的内部逻辑与架构隐患 |
| 前提条件 | 开发者愿意投入理解时间 | 需求能拆成可观察检查项，且有自动化执行环境 |
| 人的角色 | 理解并负责具体改动 | 定义验收标准并做最终判断 |
两种审查思路的对标分析
验收报告式审查的对标分析：验收报告在可观察行为的验证上效率很高，退回意见还能精确到单个检查项。报道中的实测里，审查者只退回了暗色背景一项，Agent 也只改了一行 CSS，其他文件未变。但它依赖需求能被拆成可观察的检查项，且报道同样指出，更复杂的任务中安全、架构和最终质量仍需要人判断，反馈回传也还有需要人工处理的环节。“几乎不看代码”是团队自述，未经独立验证。
出题考你的对标分析：出题考核更擅长暴露事务顺序、边界条件这类“界面上看不出来”的问题，恰好覆盖验收报告的盲区。但它的上限取决于题目质量，也需要开发者真正投入理解时间。两者并不互斥，更合理的做法是用验收报告确认“做对了没有”，用出题考核确认“我懂不懂它为什么这么做”。
按改动风险选择理解债审查强度
不是每个 PR 都值得走完整流程。Addy 也提醒，当你生成的内容已经多到无法负责时，你做的就不再是审查，而是在赌它没问题。下表给出一个按风险分级的参考，具体阈值需要结合团队实际调整。
| 风险等级 | 典型改动 | 推荐审查强度 |
|---|---|---|
| 低 | 文案、样式、独立脚本、原型 | 验收报告或手动点检即可，记录预期 |
| 中 | 普通业务功能、接口新增 | 追问未授权决定 + 核对真实测试输出 |
| 高 | 事务、权限、支付、数据迁移 | 完整 5 步流程 + 出题考核 + 独立 Agent 审查 |
| 超出负荷 | 多 Agent 并行产出、审不过来 | 补自动化检查，或减少并行数量 |
💡 选择建议：如果你所在团队已经有成熟的自动化验收，可以把出题考核集中用在高风险改动上；如果没有，至少在涉及数据一致性和权限的 PR 上坚持“答对才合并”。
常见问题 FAQ
Q1: 什么是理解债？它和技术债有什么区别？
理解债指代码和系统复杂度不断增长，而开发者对代码的理解没有同步增长。技术债通常是代码本身质量不佳，理解债则可能发生在代码质量不错的情况下，问题出在“人不懂”，等到需要修改时才集中暴露。
Q2: 让 AI 出题考你，和直接让 AI 解释代码有什么不同？
让 AI 解释，你是被动接收，很容易产生“看懂了”的错觉。出题考核要求你主动作答，答错的地方会被定位到具体代码，能把模糊的理解变成可检验的结果。
Q3: 别给 Agent 盖章，是不是意味着要逐行审查 AI 代码？
不是。据报道，Claude Code 团队并不要求工程师记住整个代码库，需要修改某部分时会借助 Claude 重新理解相关逻辑。关键前提是你清楚自己懂什么、不懂什么，并按风险决定审查深度。
Q4: 这套方法适合哪些开发场景？
主要适合以下场景：
– **长时间运行的 Agent 任务**：容易产生未授权决定，适合追问清单
– **涉及事务、边界条件的后端改动**：适合出题考核
– **多 Agent 并行开发**：适合保留原始材料并控制并行数
– **团队协作的 Code Review**：可把提问清单写进 PR 模板
Q5: 如何在 Claude Code、Cursor、Cline 中落地这套理解债自检流程？
这套方法与具体工具无关，核心是 Prompt 和流程：
1. 把本文的完整 Prompt 模板保存为团队可复用的片段
2. 开工前手写阶段 A，任务结束后粘贴阶段 B 和 C
3. 高风险改动新开独立会话执行阶段 D
也可以把“答对才合并”写进团队的 PR 检查规范。
Q6: 这些方法有哪些已知限制？
需要客观看待：
– **效果数据**：目前没有公开数据证明这些方法能降低多少缺陷率或提升多少效率
– **时间成本**：完整流程会拉长合并周期，不适合所有 PR
– **题目盲区**：Agent 出题可能回避它自己没意识到的问题，所以“找一件漏检的事”这一步不能省
– **来源说明**：Addy 观点来自媒体转述，原文措辞需自行核实
Q7: 每周离线编码练习真的有必要吗？
Addy 的理由是长期不用的技能可能逐渐退化，偶尔脱离 Agent 独立完成任务，能帮你校准真实水平。每月再盘点一次哪些技能已经交给 AI、哪些必须继续掌握，成本不高但能防止认知投降悄悄发生。
别给 Agent 盖章：理解债核心要点 Key Takeaways
- 认知投降是渐进的：从认知卸载到判断让渡，再到把判断全部交出去
- 理解债在后面收利息：代码越写越快，不懂的部分会在修改时集中爆发
- 意图债发生在上游：开工前自己写需求清单，两轮 Prompt 不满意就重梳需求
- 出题考你是核心动作：让 Agent 总结改动并出题，全部答对才合并
- 测试全绿不等于没问题：先看实际执行的测试输出，再追问没测什么
- 验收报告与出题互补：前者验证外部行为，后者检验你对内部逻辑的理解
- 按风险分级审查：审不过来时补自动化或减少并行，别靠赌
总结
别给 Agent 盖章的核心要点：
- 识别阶段：警惕从“交给 AI 干活”滑向“交给 AI 判断”，理解债和意图债都是这个过程的副产品
- 执行动作：开工写预期，交付追问未授权决定和未测内容，合并前让 AI 出题考你
- 分级取舍：低风险改动用验收报告或点检，高风险改动走完整流程并加独立审查
AI 写代码的速度还会继续提升，但为改动负责的始终是批准它的人。下次点“批准”之前，不妨先让 Agent 出 5 道题，看看自己能答对几道。
📚 参考资料
- 量子位：Claude 工程师 Agent 大教程（36 氪转载）：介绍 Addy Osmani 关于认知投降、理解债、意图债的观点与实操方法
- 链接：
36kr.com/p/4056027738116995 -
说明： 本文方法论主线的来源，属于媒体转述
-
Addy Osmani 原帖：报道中引用的原文出处
- 链接：
x.com/addyosmani/status/2117512471930167377 -
说明： 具体措辞请以原文为准，链接需自行核实
-
白鲸实验室：一家 8 万 Star 的 AI 公司，决定让 AI 接管自己（36 氪转载）：介绍 LobeHub 的主管 Agent 架构与 Acceptance 验收报告实践
- 链接：
36kr.com/p/4056040123945860 - 说明： 验收报告式审查的对照来源，“几乎不看代码”为团队自述
作者: API易 技术团队
