一句话定义：理解债（Comprehension Debt）指代码库里堆积的“没人真正读懂、却已经被合入并依赖”的代码所对应的隐性维护成本，其中 AI 生成后未经消化就上线的部分是最主要的来源。
打个比方：家里请人装了全屋智能，开关藏在墙里，说明书也没留。灯亮着的时候一切正常，某天半夜跳闸，你只能拆墙。AI 写代码的速度，远快于人类读懂它的速度，这就是理解债的源头。过去亲手敲一遍，多少被逼着读了自己的逻辑；现在几百行补丁几分钟就能产出，命名规范、格式漂亮、注释齐全，评审时“扫一眼觉得对”就点了合并。流畅的表面掩盖了逻辑的陌生。
它和技术债（Technical Debt）不一样：技术债通常是明知故犯的取舍——为了赶上线先写个糙版本，团队心里有数，也记在待办里；理解债更隐蔽，你不知道自己不知道什么，它不出现在任何待办清单上，只在某次线上故障时一次性收账。
| 维度 | 技术债 | 理解债 |
|---|---|---|
| 是否被意识到 | 通常已知，有记录 | 往往无意识 |
| 产生方式 | 主动妥协 | 被动跳过理解 |
| 典型症状 | 改起来慢、不敢重构 | 出故障没人能定位，只能绕开或重写 |
| 偿还方式 | 排期重构 | 重新读懂、补测试、讲给别人听 |
怎么度量——不用精确到小数点，看三个信号就够：改一个线上问题，从“看到报错”到“知道为什么”平均要多久；随机抽一段最近合入的代码，作者能否在五分钟内讲清它的输入边界、失败路径、以及为什么不用更简单的写法；代码库里有多少文件“没人认领”——删掉时没有任何一个人紧张。
怎么还债——评审规则上：PR 模板里标注哪些是 AI 生成、哪些经过验证；评审者必须能用自己的话复述这段逻辑，复述不出就不批准，“看起来对”不算评审意见；一次合入的核心逻辑超过某个规模就要求拆分，并配一段人写的说明和测试——测试是理解的书面形式，写不出测试通常意味着没读懂。
代码测验（code quiz）上：每周花二十分钟，从近期合入的代码里抽一两段，作者讲、其他人提问，重点问“这里输入是空的会怎样”“为什么不用现成的那套”。讲解人轮换，别让理解只停在一个人脑子里。这不是考核，是集体还债的仪式。另外，最便宜的还债方式永远是删代码：没人用的功能直接删掉，债就没了。
对不写代码的人也一样：AI 帮你写的方案、邮件、报表，签了字就是你的责任。检验标准相同——不看原文，能否用自己的话讲清它的关键假设和出错时会怎样。