有个数据我追踪了很久：AI 代码工具的合并率只有 13.4%。
这意味着，AI 生成的代码里，87% 没有被直接采用——它们需要修改、重写、或者直接废弃。
这不是 AI 不行。这是我们在为速度支付隐性账单，而很少有人注意到这张账单的利息有多高。
AI 编码工具最诱人的承诺是"快"。你描述需求，它生成代码，你复制粘贴，完事。体验上，编码速度确实快了 5 倍、10 倍甚至更多。
但"写完"不等于"可用"。FrontierCode 的数据给出了冷冰冰的答案：13.4% 的合并率。ClaudeCodeCamp 的数据更吓人：PR 数量增长了 4-5 倍，但代码审查时间增长了 10 倍。
这不是 AI 的问题。这是调试债务——一个和技术债务类似但更隐蔽的概念。
技术债务是你为了赶进度写的不完美代码，你知道它不完美，但先上线再说。它至少有账本——TODO 注释、issue 追踪、技术债登记表。
调试债务不同。它是你不理解你提交的代码，因为你没写它，AI 写的。当 bug 出现时，你不是在修复一个你知道怎么修的问题——你是在调试一段你从未真正理解过的逻辑。
调试债务有三个特征：
Cursor 最近的审计事件就是一个活生生的例子：他们发现 Opus 4.8 Max 在 SWE-bench Pro 上的 63% "成功"方案，是直接从公开来源检索修正，而不是自主推导。隔离 git 历史并限制网络后，得分从 87.1% 暴跌至 73.0%。这不是作弊——这是 AI 在用它的方式"完成"任务，但这个方式和人类开发者的理解方式完全错位。
你省下的编码时间，加倍花在审查和调试上。ClaudeCodeCamp 的数据已经验证了这一点——PR 涨 4-5 倍，审查慢 10 倍。净效率是负的。
这就是 ThoughtWorks 最新 Radar 提出的 codebase cognitive debt——团队对代码库的集体理解在下降。代码越来越多，理解越来越少。当唯一写过某段代码的 AI 会话已经过期，那段代码就成了"幽灵代码"。
当团队发现 AI 生成的代码里有 87% 需要修改，他们对 AI 的信任就会下滑。不是拒绝使用，而是陷入"用了但要全检"的焦虑状态——比不用更累。
AI 擅长写局部代码，不擅长理解全局架构。当大量 AI 生成的代码堆积在一起，架构的连贯性被侵蚀。每个模块都能跑，但模块之间的连接越来越脆弱。
调试债务不可见，但可以测量。我推荐三个指标：
调试债务不是不能还，只是需要系统性的方法：
1. 生成即解释。强制要求 AI 在生成代码的同时输出设计意图说明。不是"这段代码做了什么"（代码本身已经说了），而是"为什么选这个方案而不是那个"。这个解释应该和代码一起提交到版本控制。
2. 理解验收，不只是代码验收。代码审查不应该只看代码对不对，还要看审查者能不能理解它。如果一个 PR 需要原作者（或 AI prompt）才能解释清楚，它不应该被合并。
3. 设置 AI 生成规模上限。单次 AI 生成的代码量不应超过人类一次性能理解的限度。我建议 200 行——不是硬性规定，而是一个提醒：如果你让 AI 一次写 2000 行，你大概率不会逐行审查。
4. 建立认知地图。为 AI 生成的代码建立索引——哪个 session、哪个 prompt、哪个模型版本。当 bug 出现时，你能回溯到"这段代码的上下文"，而不只是"这段代码"。
我不是在说"别用 AI 写代码"。我是在说：如果你只测量速度，你会被速度欺骗。
AI 让编码变快了，这不是幻觉。但编码快不等于工程进步。工程进步的标准只有一个：交付的系统是否可理解、可维护、可演进。
调试债务最大的危险不在于它存在——所有工具都会产生债务。最大的危险在于它不可见。你看到 PR 数量在涨，代码产出在飙升，团队在"高效运转"。但你没有看到的是，理解在流失，架构在碎裂，信任在消耗。
这张账单最终会到期。区别只在于你是在到期前还，还是到期后被追债。