Comprehension Debt（理解债）
理解债（Comprehension Debt） 是指因过度依赖 AI Agent（智能体） 生成代码、方案或决策，而积累的认知缺口——系统在运转，代码在跑，但工程师不真正理解这份代码的逻辑、约束和边界条件。类比技术债：不是功能坏了，而是出事时没人知道为什么。
为什么会产生理解债
- 生成速度远超理解速度：AI 在几秒内写出几百行，但人理解一段陌生代码需要时间
- 接受偏见：代码能跑、测试通过，就倾向于认为它是对的
- Loop Engineering（循环工程）的惰性副作用：循环自动跑久了，人容易停止思考，直接接受结果
- 没有"被迫理解"的机会：亲手写代码会强制你思考每一个决策；复制 AI 产出不会
理解债 vs 技术债
| 维度 | 技术债 | 理解债 |
|---|---|---|
| 是什么坏掉了 | 代码质量/设计 | 工程师的认知 |
| 能被测试发现吗 | 部分 | 不能——测试通过不代表你理解它 |
| 如何偿还 | 重构 | 深入阅读、手写、调试 |
| 累积速度 | 慢 | 随 AI 使用量线性增长 |
差距的膨胀机制
理解债有一个容易被忽视的特性：它不会自动缩小，只会膨胀。
循环跑得越快，没有亲手写的代码越多，工程师真正理解的代码与实际存在的代码之间的差距就越大。这个差距不会因为循环在运行而缩小——它只随着时间和代码量增长。当生产环境出问题时，你面对的是数千行从未仔细读过的逻辑。
这个机制使理解债与普通技术债的偿还逻辑不同：技术债可以在有空时专门偿还，理解债的窗口在生成时——循环跑得越快，审查每一轮产出的机会就越少，窗口越来越窄。
识别信号
- 修改一段 AI 写的代码时，不确定改动的影响范围
- 系统出问题，无法快速定位原因
- 代码 Review 只看"能不能跑"，不再追问"为什么这样设计"
- 新需求时不知道该改哪里，靠 AI 重新生成整段逻辑
防范方式
- 理解后再接受：AI 产出当作草稿，读懂后再提交
- 小步生成：让 AI 每次只做一小步，而不是一次生成大段代码
- 主动调试：遇到 bug 先自己分析，再让 AI 辅助
- 定期手写：保持亲手写关键路径代码的习惯，不全权委托
- 设计循环时的关键问题：我设计这个循环是为了加速理解，还是逃避理解？
Loop 语境下的缓解措施
Addy Osmani 点明：这些缓解方式都不是技术性的——它们是习惯和纪律，而不是工具配置。
- 读 diff：如果你不读循环每次合并的内容，就是在用复利速率租理解债。循环跑得越快，每轮差异越小，越容易跳过阅读——这正是理解债最快的积累路径。
- 抽查验证门：随机挑几个循环开的 PR，验证那个放行它的测试确实在检测你真正关心的失败模式。验证门会随时间退化（Gate Rot）——通过它的测试可能早已过时，但循环不会告诉你。
- 把循环挡在架构决策之外：只让循环接触小的、机器可验证的变更。一旦允许它触碰判断型工作，理解债就开始加速积累，因为没有外部机器标准能告诉你它做的是不是对的。
- 和队友结对设计循环：一个人设计的循环会把设计者的盲点固化进去，而且循环会永久利用这些盲点。第二双眼睛在设计阶段比在事后排查阶段廉价得多。
一个反直觉的规律：循环越顺，这个问题越严重，而不是越轻。循环顺了，越难察觉理解债在累积；出了问题，才发现没人知道为什么。
核心判断
如果你设计Loop Engineering（循环工程）是为了加速理解，它是工具；如果你设计循环是为了逃避理解，它是灾难加速器。
理解债不是反对使用 AI 的理由，而是提醒：AI 是放大器，放大你的能力，也放大你不理解时的风险。
理解债如果长期未偿还，容易演变为Cognitive Surrender（认知投降）——不只是"看不懂"，而是"不再想看懂"。理解债是认知债务的认知层，认知投降是意志层。