“理解债务”（Comprehension debt）由 Jason Gorman 于 2025 年提出，并由 Addy Osmani 于 2026 年推广，指系统中代码量与人类真正理解其内容的程度之间日益扩大的差距。这种债务的产生，是因为 AI 代理生成代码的速度远超人类理解其内容的速度，从而打破了延续七十年的“代码即人类理解”的假设。与技术债务不同，后者是代码本身的属性，而理解债务则是团队与代码之间关系的属性。即使一个模块代码整洁、测试完善，若无人真正理解它，仍可能成为负担，这颠倒了以往“坏代码能运行”到“好代码能运行直至失效”的常规担忧。这种债务之所以长期隐形，是因为现代工具链衡量的是覆盖率、交付速度等指标，却未纳入人类理解程度。代码审查作为最接近的代理指标，本质上仅是一种抽样事件；在 AI 原生吞吐量的环境下，审查变得更为简短，且对真实理解的指示作用减弱。“巴士系数”（bus factor）启发式方法同样失效，因为由代理编写的代码可能具有分数级甚至不存在的巴士系数，意味着无人真正理解其内容。理解债务会积累隐形的持有成本，但在事故、未来变更、人员离职及新工程师入职等关键时刻，将引发残酷的利息支付。这些时刻迫使团队以溢价回购其从未真正获得的“理解”。对理解程度的测量应聚焦于 Git 历史中的可观测信号，例如实质性的审查评论、近期的人类作者身份，以及真正与文件交互过的不同人类数量。围绕这些测量的纪律至关重要：它们必须是确定性的、可分解的、可争议的，并随时间衰减，以反映理解会随时间消退的事实。关键的是，验证工作必须由原作者以外的人员执行，以防操纵系统。团队可以立即着手管理理解债务：为 AI 编写的代码指定人类“记录作者”，禁止对代理生成的拉取请求进行静默批准，并公开讨论系统中哪些部分理解不足。将命名的认知盲区列为待办事项也有助于改善。尽管人工努力有限，但像 Fathohm 这样的工具可以映射整个代码库中的理解债务，提供全面且动态的视图。最终，随着 AI 持续编写代码，是否主动管理理解债务，将决定该代码是否仍能被理解。