技术债这个东西，每个团队都有一堆，每个团队都说"下个迭代再还"。然后下个迭代来了，又有新需求要上，技术债继续往后排。年复一年，债越滚越大，大家都知道有问题，但没人愿意第一个动手。

最近看到一个案例挺有意思的。DoorDash有6万多个Feature Flag，每月新增2300个，其中1000多个已经过期了。过期是什么意思？就是这个Flag对应的实验早就结束了，结论早就有了，但代码里那个if/else还在那里，像个没人拆的路障。

Flag为什么会变成债

做过Feature Flag管理的人都知道，加一个Flag只需要五分钟，但清理一个Flag可能需要改5到20个文件。这不是夸张，DoorDash用的依赖注入模式，Flag的定义在一个文件里，客户端调用在另一个文件里，业务逻辑散落在更多文件中。

一个简单的布尔型Flag，你以为找到代码里的true/false改掉就行了？不是。你得搞清楚这个Flag关联的实验结论是什么，目标值是0还是1，移除后默认行为应该走哪个分支，测试用例要不要同步修改。

这就是为什么技术债清理永远排在后面——不是因为它难，是因为它无聊、琐碎、没有成就感。没有人会在绩效自评里写"本季度清理了30个过期Feature Flag"，对吧？大家更愿意写"主导了XX新功能的开发"。

但不清理的代价是真实的。6万个Flag摆在那里，每一个新功能的上线判断都要穿越一堆过期条件分支。新人入职看代码，不知道哪些if是活的哪些是死的；老人改逻辑，要花时间确认哪些Flag还在用。这不是"技术债"三个字能概括的——这是每天每个人都在付的认知税。

DoorDash怎么干的

DoorDash先试了Uber开源的Piranha工具，用AST（抽象语法树）做代码转换。Piranha的思路很经典：识别Flag的语法模式，自动删除死代码分支。但DoorDash发现它搞不定依赖注入模式——Flag和业务逻辑之间的关系是语义层面的，不是语法层面能匹配到的。

换句话说，Piranha能看懂代码的结构，但看不懂代码的意思。这跟用正则表达式做代码重构有点像——能解决20%的简单场景，剩下80%需要理解上下文。

所以他们搭了一个多Agent系统，基于Google的Agent Development Kit，分两个阶段。第一阶段，编排Agent（用Claude Sonnet）从Jira拉取过期Flag工单，搜索相关代码仓库，通过MCP协议查询实验平台获取元数据——发布比例、目标值这些。然后生成一份报告交给工程师审核。注意这里有人工确认环节，不是全自动的。

工程师确认目标值后，第二阶段启动。清理Agent（用Claude Opus）在隔离的Git Worktree里干活，每个仓库最多同时跑4个Agent。Agent定位Flag的所有引用，判断清理策略，修改源码和测试，然后跑构建、测试、JaCoCo覆盖率检查、Detekt静态分析。全部通过后，才创建Pull Request。每个Agent超时1小时。

结果数据：50个Flag的评估中，45个生成了可用PR。31个首次提交就被合并，14个需要小改，5个需要人工介入（都是涉及跨接口参数传递的复杂场景）。简单Flag的一次性成功率100%，中等的94%，复杂的85%。平均每次清理耗时13.8分钟，成本4.79美元。人工估计？1到2小时。

50个变更里没有发现Bug或回归。

这个数据背后藏着什么

乍看之下，这又是一个"AI提效"的案例。但我觉得更有意思的是一个反直觉的观察：AI在这些场景里的价值，不是因为它更聪明，而是因为它不嫌活脏。

技术债清理这件事，最大的障碍从来不是技术难度，而是人的意愿。你让一个资深工程师花两周清理过期Flag，他会觉得在浪费生命。但不清理，整个系统的认知负荷在持续增加，新人上手慢，老人改不动，每次发布都要多过几层if/else。

AI恰好适合做这种活。它不会觉得无聊，不会因为"这事没技术含量"而觉得职业发展受阻，也不需要在绩效里证明自己的价值。它只需要正确的上下文和足够的验证机制。

DoorDash和Piranha的对比也说明了一件事：规则驱动的方法是有上限的。Uber的AST工具能解决"看得懂语法"的部分，但依赖注入模式下Flag和逻辑之间的关系是语义层面的。LLM恰好擅长处理这种"需要理解意思才能动手"的场景。

这让我想到一个更大的问题。

我们是不是在让AI干错的事

目前大部分团队对AI的投入方向集中在"帮我写更多代码"——Copilot、Cursor、各种编码助手。这当然有价值，但我觉得可能忽略了更大的蛋糕。

新功能开发是显性的：有产品经理推动，有KPI支撑，有人盯着。但技术债清理是隐性的：没有明确的需求方，没有人催，没有OKR。结果就是，AI被用来加速已经在快速推进的事情，而那些没人推进的事情继续烂在那里。

换个角度想：如果你的团队有10个工程师，每人每天花30分钟处理跟历史遗留代码相关的事情——理解过期的逻辑分支、更新过时的依赖版本、修复因为配置漂移导致的诡异Bug——这10个人加起来每天5小时，一年250个工作日就是1250小时。按平均人力成本算，这笔账比大多数人想象的大得多。

AI如果能接下这些"脏活"中的一部分，释放出来的不只是时间，还有工程师的注意力和耐心。让想写新功能的人去写新功能，让AI去清理那些"知道该做但不想做"的事。

DoorDash花了精力搭建这套系统，是因为他们的Flag规模已经到了不得不解决的地步——6万个Flag，每月新增2300个，靠人力根本管不住。但大多数公司的Flag问题没这么严重。他们的问题可能是300个没人愿意清理的废弃API，50个没人敢动的过期配置项，或者20个"能跑就别动"的遗留模块。

规模不同，但底层逻辑一样：这些事没人做，不是因为做不了，是因为没人想做。

说回来，我最近一直在想一个还没想清楚的事——如果AI的定位从"帮你写得更快"变成"帮你清理得更干净"，工程师对AI的态度会不会完全不一样？前者让人焦虑"是不是在取代我"，后者让人松口气"那些破事终于有人做了"。

不知道别的团队有没有试过这个方向。有的话，聊聊？