别人用AI写代码，这家大厂却用它疯狂删代码

Unsplash

几乎所有工程师都在用 AI 工具狂飙代码。但任何负责维护核心系统的架构师都清楚，堆砌代码只是工程的一小部分。真正的苦活是清理垃圾：上个季度就已结束的灰度实验、早就没人用的降级分支，以及已经硬编码为常量的配置项。

这些陈旧逻辑就像散落在代码库里的绊马索。没人愿意碰它们，因为删代码通常不会计入 KPI，可一旦删出 Bug 却要背锅。于是，技术债务越积越厚，拖慢后来的每一个人。

Uber 最近公开了内部系统 AutoClean 的设计。他们没有把 AI 当作代码生成的加速器，而是将其改造成清理陈旧特性开关（Feature Flags）的手术刀。

业务上线了，老分支为什么还在？

特性开关是现代互联网架构的标配，从滴滴的运力调度到淘宝的双十一结算，团队往往靠它来做无缝灰度发布。

比如外卖配送预估时间服务的伪代码：

def estimate_delivery(order, flags):
    if flags.enabled("new_delivery_estimator"):
        return estimate_v2(order)
    return estimate_v1(order)

当 estimate_v2 在全量流量下稳定运行半年后，那个 if 条件和老旧的 v1 逻辑就该彻底退休。但在现实中，老逻辑往往永远留在了仓库里。更致命的是，这类开关会层层嵌套、相互依赖，让原本直观的代码演变成连原作者都不敢碰的迷宫。

核心挑战：如何让“删除”值得信赖？

直接把代码丢给大语言模型让它“帮我删掉老逻辑”，在工业级系统中行不通。LLM 存在幻觉，很容易在删掉老分支的同时，误删关联的单元测试、引发依赖缺失，甚至改动无关的业务上下文。

Uber 的 AutoClean 没有单靠提示词工程，而是设计了一套闭环方案：

1. 意图解析与规划：由 AI Agent 梳理特性开关在整个调用链路中的拓扑关系，判断哪些类、函数与配置文件属于待清理范围。
2. 确定性语法转换：删除动作本身不全靠大模型脑补，而是结合基于 AST（抽象语法树）的确定性重构工具，精准移除无效代码块。
3. 自动化测试与补全：AI 负责修复因删除代码而失效的单元测试，把旧断言更新为当前业务期望的状态。
4. CI 独立验证与人工把关：变更必须无缝通过原有的所有集成测试和静态扫描，最后以规范的 Pull Request 形式交由原团队工程师做最终 Review。

代码越少，系统越稳

过去两年，工程界都在比拼谁能让 AI 快速写出几十万行代码。但代码不是资产，运行中的有效逻辑才是；每一行冗余代码，本质上都是待付的利息。

AutoClean 的实践带来了一个明确的信号：AI 编程的价值不仅在于加速产出，更在于低成本化解复杂的系统熵增。把最繁琐、风险最高的重构工作交给机器验证闭环，人类工程师才能从修修补补的技术债泥潭中抽身。