1. AI生成代码之后，技术债务的形态变了
去年我参与排查过一起线上事故，最后定位到的问题代码，组里没人能说清楚它是谁写的、为什么这么写——只有一条孤零零的注释写着“根据某个需求调整逻辑”，而那个需求文档早在半年前就归档了。后来翻提交记录才发现，这段代码是当时某位同学用AI辅助生成、人工确认了五分钟就合进去的。
这事让我想了很久。我们团队引入AI辅助编码之后，交付速度肉眼可见地快了，但三个月后再回看代码库，很多人心里其实都在犯嘀咕：这里面到底有多少代码是“真懂的”，有多少是“大概懂的”，还有多少是“完全没人懂的”？这就是AI时代技术债务最微妙的变化——债务不再只是“代码写得烂”，而是“代码的认知归属权”变得模糊了。
传统意义上说技术债务，大家脑子里浮现的都是什么？圈复杂度爆炸的函数、复制粘贴五遍的相似逻辑、没有测试的遗留模块。经典的定义里有个很重要的区分：写烂代码赶工期，属于“有意的、已知的债务”——你清楚自己欠了债，后面还就行。最危险的其实是另一种：你根本不知道自己欠了债。AI生成代码正好把这个“未知债务”的比例急剧放大了。
AI生成代码的特点是语法正确、结构平庸、语义存疑。单看每一段都“好像没问题”，但合在一起，没有人具备对它的完整心智模型。老代码常有所谓的“部落知识”——某个模块为什么要这样设计，文档里不写，但在老员工的脑子里。AI代码没有这种传承，它的知识只存在于生成它的那一刻，之后就是一段无主代码。
我见过几个典型的AI债务场景，列出来大家可以对号入座：
- 死代码膨胀：AI为了“完整”会生成一堆看似有用的工具函数，但实际只被调用了一次，甚至从来没被调用过，后续也没人敢删。
- 过度抽象：为了“通用性”搞出一套多层封装，实际业务场景只有一个，阅读理解的成本远远超过它省下的重复代码。
- 复制粘贴变体：AI反复生成几段高度相似但略有差异的逻辑，后续修改时漏改一处，就成了定时炸弹。
- 注释与实现脱节：AI生成的注释写得像官方文档一样漂亮，但实际代码逻辑和注释对不上，这种比没有注释更坑。
我把这类问题统称为“AI幻觉债务”。它的可怕之处在于，传统的代码评审流程很难拦住它——因为评审者面对AI代码时，大脑默认会降低警惕，“机器写的应该比人靠谱吧”。但事实恰恰相反，AI对业务语义的理解是非常浅层的，它擅长的是模式匹配，不是因果推理。
所以回到开头那个事故，本质上不是某一个人的问题，而是整个工作流的问题：我们允许AI以极高的速度生产代码，却没有同步建立一套机制去管理“这些代码产生的理解债务”。这才是AI时代技术债务管理和传统做法的最大分水岭。
2. 别等债务爆雷：先建一套能用的度量基线
聊债务管理，最怕的就是拍脑袋。你说这个模块有债务，他说那个模块要重构，各执一词，最后谁嗓门大听谁的。我在实践中踩过这个坑，必须承认：没有量化，债务治理就是一次茶话会。
但量化不等于堆指标。一开始我也试过传统的静态代码扫描，什么圈复杂度、代码行数、重复率，跑完出一大堆报告，看着很专业，实际上根本没法指导行动。为什么？因为这些指标是“代理指标”，它们只能说明代码长什么样，不能说明代码库在承受什么。
这么说吧，圈复杂度只告诉你一个函数有多绕，但绕不绕和你该不该重构它是两回事。一段圈复杂度20的代码如果稳定运行了五年、没人动过它，你去重构它反而是在制造新债务。代码行数就更糟糕了，它甚至不能算质量指标。我见过一堆“评分很高”的代码库，出事之后连根因都找不到。
真正让我觉得有指导价值的，是三个维度的交叉：
- 变更热区：用版本管理日志统计每个文件/模块的改动频率和失败率。改动频繁的代码，就是债务容易爆的地方——因为每次改动都在扰动它的边界，而频繁失败说明这个模块的坑已经被踩过很多次了。
- 耦合度：分析“改了它之后还连带改了谁”，衡量一个模块的牵连面。高耦合模块是最不敢动的，越不敢动，越容易腐烂。
- 知识覆盖：用测试覆盖率和必要文档覆盖度作为代理。这里说的知识覆盖不是“有没有测试”，而是“如果有人改了这块逻辑，能不能通过测试和注释快速理解它的契约”。覆盖率极低的模块，稍微改一行都是在赌。
我实际跑项目时，是先把这三个维度的数据各自取出来，然后画三个集合的交集。三个维度都落红的模块，基本就是全库最应该优先处理的高危债。给大家一个真实案例：某项目里有一个支付回调模块，三个月内被改了14次，其中3次上线后出现问题；它的近邻耦合模块有6个；单测覆盖率只有15%。这三个数摆出来，不需要任何领导拍板，全组人都会同意这是第一优先级。
有了度量，下一步是定基线和阈值。这个很关键，我见过不少团队栽在“追求绝对完美”上。债务度量的目标不是清零，而是建立相对排序和趋势判断。我的做法是连续观察8到12周的数据，然后用第80百分位作为“热区红线”——只有改动频率排进全库前20%的模块才算热区。红线之上，才进入债务候选池；红线之下，先放着。
阈值也不是定死不变的，每到季度复盘我就调一次。代码库是活的，债务水位也是波动的，基线的作用是让你能感知到“这个月比上个月恶化了”，而不是追求一个静态的分数。
我总结了一下这套度量组合的实际价值：它把技术债务从“谁都觉得有、但说不清在哪”变成了“一张有坐标的地图”。地图上的坐标不完美，有噪声，但至少你能指着一个模块说“我们下个迭代还这笔”，而不是天天喊“咱们要提高代码质量”。
3. 还债也要讲策略：把治理嵌进迭代节奏
度量只能告诉你债务在哪，真正难的是“怎么还”。这方面我观察下来，大多数团队是两种极端：要么完全不还，债务像雪球一样滚到系统崩溃的那一天；要么憋大招搞“大重构月”，把全组人按在工位上三周，推倒重来，最后项目延期、回归测试炸了一地。
我试过之后觉得，真正可靠的路子是把债务治理嵌进日常迭代节奏里，像还房贷一样分期还，而不是等爆雷了再一次性清盘。
第一个机制是“还款预算”。具体做法很简单：每个迭代划出固定比例的时间预算专门用来还债。我习惯定在10%到20%之间，也就是一个两周的迭代里，留出半天到一天的时间做债务偿还。这个比例的妙处在于，它不是可做可不做的“机动时间”，而是和需求开发一样被纳入排期的正式任务。如果不这样，任何“等有空了再还”的念头最后都会变成“永远没空”。
有了预算，就要有人决定“这笔预算花在哪”。这就涉及到优先级判定，我用的规则很简单，三个因子打分：
- 影响面：这个债务如果爆了，会影响多少功能、多少用户？
- 年龄：这笔债存在多久了？存在越久，知识折旧越严重，还债成本越高。
- 认知度：现在团队里还有几个人能说清楚这块代码的来龙去脉？
三个因子的分数乘起来排序，分数最高的先还。这里有个反直觉的点：影响面其实不是最该优先的，认知度更关键。我处理过一个工单系统的案例：某个模块影响面不大，只关联一个内部报表，但这笔债已经三年了，全组没有人能独立解释它，每次改都得找一位已经半离职状态的老同事远程看。这种债不还，成本随时间是加速上升的——因为认知是折旧的，今年还能问人，明年就没得问了。反而是那些影响面大但团队很熟的模块，可以往后放一放，反正大家熟，出问题能快速反应。
然后是“怎么动手改”的问题。我不推荐大爆炸式重构，尤其在AI时代代码量膨胀得厉害，大重构的回归面太广，你根本兜不住。我实践的思路是绞杀者模式：一个模块的改造分三步走——替身、迁移、下线。先在旁边搭一个新的实现做“替身”，用特征开关或者路由策略把线上流量逐步切过去，切一小部分就观察，观察没问题再切多一点，直到旧实现彻底没了流量，才把老代码删掉。每一步都是独立可合入的提交，每一步代码库都处于可发布状态。
强调一点，整个还债过程必须用测试网兜底。我见过太多重构是“代码改完了、人脑模拟逻辑没问题”，结果上线就把核心流程干挂了。没有测试覆盖的重构，本质上是给系统注入新的高风险代码，这不是还债，是又借了一笔高利贷。
还款预算、优先级打分、绞杀者改造，这三样凑齐，债务治理才算真正落了地。它不是某一次轰轰烈烈的净化运动，而是一个细水长流的财务安排——你每个月固定还一点，利息就不会滚成雪崩，系统也就有了持续改善的节奏感。
4. 用AI还债的正确姿势：工具链实战与避坑
前面聊的都是管理思路，这一节重点说说AI时代特有的红利：用AI去识别和偿还技术债务。毕竟AI是债务的重要制造者，你肯定不能只让它生产，不让它干活。
先说AI在债务管理里擅长做什么，不擅长做什么。这个边界如果不划清，很容易踩坑。我自己的经验是这样：
AI擅长的是模式层面的工作：识别重复代码、生成单元测试、解释冷门模块的基本逻辑、自动分类历史提交、做代码相似度聚类。这些任务本质上是“模式匹配”，往里灌代码，往外吐归纳，AI干得又快又准。
AI不擅长的是语义层面的判断：比如说“这段代码到底还需不需要”，这种问题AI永远答不了。因为业务语义在代码之外——在一个需求的演化史里，在某个深夜会议的决定里，在用户反馈的某条评论里。AI没有这个上下文，问它等于问一个没参加过讨论的实习生。
明白了这个边界，工具链的设计就比较清晰了。我在这类实践里做的三件事给大家做个参考：
第一件事：给代码库做“债务普查”。用AI批量扫描全库，把相似的代码片段聚类。一开始跑出来的结果很有意思：某消息处理模块里，有七段逻辑几乎一模一样的回调处理，只是字段名和错误码不同。这种问题人肉找要看好几天，AI十分钟全部聚出来。聚类结果出来之后，老团队一看就知道哪些是历史遗留的复制粘贴债，该合并的合并，该抽象的抽象。
第二件事：让AI当代码评审的“预筛器”。具体是在持续集成流水线里加一个AI评审节点，但它不堵塞合并，只输出报告。触发条件严格限定为“仅对本次变更文件做增量扫描”，不做全量扫描。检查清单也聚焦在AI容易识别的项：注释与实现不一致、异常分支未处理、魔法数字集群、复制粘贴变体。人工评审只看报告，再结合业务判断要不要返工。
这里有个细节：AI评审报告的支持信息里一定要附上“这是一个预筛提示，不是强制要求”，这句话看着轻飘飘，实际对信任建设特别重要。我见过团队把AI评审设成硬门槛，结果AI误报把所有人的耐心耗光，最后整个机制被抵制。AI评审必须是助理，不能是裁判，这是血泪教训。
第三件事：用AI做债务记账。让AI把历史提交信息和工单系统关联起来，给每个模块自动打上“债务标签”——比如“频繁返工”“耦合严重”“测试缺失”“无人认领”。季度复盘的时候，把这些标签汇总成一张债务热力图，哪块的标签又多又红，哪块就是下个季度的重点还债对象。这套记账系统不需要额外人力去维护，AI自动跑就行。
再单独说说避坑。AI工具链最大的坑不是没用，而是变成了新的噪音源。我实际跑的某团队，第一周AI评审的误报率在40%左右——一半的提示都是废话，什么“建议增加日志”之类的万金油建议。后来我们做了三件事把误报压到15%以下：一是调整提示词，告诉模型“只报告可明确判定的问题，不要给泛泛建议”；二是只对变更文件做增量分析，不做全库对比；三是每次评审后人工对AI的建议打“有用/无用”标签，让反馈回流调整权重。
还有一点经验：别追求评审覆盖率百分之百。AI评审宁可漏报，不可乱报。漏报了，最多错过一个潜在问题，人肉评审还能补上；乱报了，整个团队对AI报告的信任会崩塌，以后真的发现重要问题时也没人看了。信任这个东西，一旦透支比没有还麻烦。
AI还债还有一个很实际的应用：自动生成单元测试。让AI先读代码、读懂代码，然后生成一组基础的单测，人工只做评审和补漏。很多团队不敢给遗留代码补测试，就是因为写测试的时间成本太高。现在AI能在几秒内生成一个模块的基础测试集，哪怕只有60%能用，也足以把“完全没测试”的裸奔状态拉回到“有基础防护”的状态。这个配合第三部分说的绞杀者重构，简直绝配——你重构前先用AI把旧代码的测试补齐，重构后跑旧用例对比行为一致性，回归风险直接降一大截。
当然，AI生成的测试也有它的毛病：断言写得稀烂、边界值覆盖得差、只顾着跑通不管对不对。所以我的经验是“AI生成、人工定义契约”——AI负责搭测试框架、铺基础用例，但核心接口的输入输出预期必须人工确认。这个协作模式跑顺之后，补测试这件事从“没人愿意干”变成“每天自动产出一批待审核”，效果非常明显。
5. 关于认知带宽，最后说几句
我做了几年技术债务治理，越到后面越觉得，真正稀缺的其实不是工具、不是流程，而是团队的认知带宽。技术债管理说到底是在管理“人对代码的理解差距”——AI时代代码生成的速度越来越快，这个差距被拉大了，所以管理这件事的重要程度也在快速上升。
如果你现在还处于“知道有债但不知道债在哪”的阶段，我的建议很实际：先选一个你觉得最憋屈的小模块，把前三章的度量方法跑一遍，给它建个简单的债务账本——改了多次、测试多少、谁懂它，每周花半小时看一眼。跑上一个月，你会发现团队对那个模块的讨论质量完全不一样了，至少大家都开始说具体问题，而不是嚷嚷“这块很乱”。
工具上的事，让AI当副驾驶，别当驾驶员。它能翻代码、聚类、找重复、写基础测试，这些都是好帮手；但还哪笔债、怎么还、什么时候停，这些决策必须由懂业务的人来做。AI可以让你省掉大量机械劳动，但它替代不了“对系统的责任感”。
最后分享一个小技巧：债务账本里每还完一笔，就顺手在代码里加一句“为什么当初要这么写”的注释。这些话对于未来接手的同事，价值比任何文档都大。技术的债可以慢慢还，但理解要趁热留下来。
