AI越会写代码，越没人愿意"删代码"

近期一次播客访谈中，负责OpenAI Codex应用落地的Andrew Ambrosino说出了一句颇有意思的话。

当主持人问“你希望AI编程工具最应该加强什么能力”时，他没有选择生成速度、上下文理解或多文件编辑。思考片刻后，他说：“我希望模型更擅长删代码。”

在今天的行业语境下，这句话近乎反叛：大家都在比拼“谁生成得更多、更快、更完整”，掌管Codex落地的人关注的却是“删”。

然而，他的焦虑并非没有道理。

AI修完bug，你可能反而更睡不着

Andrew列举了几个十分具体的场景。

让AI修复一个bug时，它可能顺便调整相关抽象层。功能实现了，逻辑也成立，可原本三个类能完成的事情，却变成六个类互相调用。你没有要求它改这么多，它的“责任心”却交付了更复杂的结果。

又比如让AI补充一个边界条件，它可能选择绕远路：不在触发点附近修补，而是在整条调用链上逐层拦截，最终代码量翻倍、可读性下降。

这并非AI故意作恶，而是模型的底层逻辑使然。大语言模型从海量代码中学到的是“一个功能需要什么”，而非“一个功能不需要什么”，因此天然偏向“添加”。作为反向推理，删代码远比加代码困难。

Andrew指出：“模型通常会增加复杂度。”这不是一句吐槽，而是一项工程观察。

那么，谁来负责收拾？

程序员群体中长期流传着一种分类法，最近又被人们拿出来讨论。

前Google工程师Boris Cherny将未来产品团队成员分为五类：Prototyper（原型者）、Builder（建造者）、Sweeper（收尾者）、Grower（增长者）、Maintainer（维护者）。

受到AI冲击最大的是前两类角色。快速做出可运行成果，再把原型扩展为可交付工程，正是原型者与建造者的工作，而AI对此已相当擅长并仍在加速。过去编码一个功能要两天，如今可能只需一杯咖啡的时间。

但Sweeper怎么办？

Sweeper负责把AI半成品整理到真正可上线：消除重复逻辑、拆除古怪抽象层、补全遗漏的边界条件、统一割裂的UI风格、补上缺失测试，并把“能跑但改不动”的代码重构为可维护状态。这才是AI编程最令人头疼的环节。

OpenAI内部曾出现一个非常极端的案例。

视频编辑团队的同事Brent，尝试用Codex来编辑Codex自己的发布视频。Codex检测到他正在用PremierePro，先通过编辑软件背后的文件完成了部分操作。但当遇到纯GUI操作时，Codex的自动化能力不够用了。

它如何应对？它为自己编写了一个PremierePro扩展，再借助该扩展控制Premiere界面中的标记。

这个案例常被视为Codex“灵活调度外部工具”的经典demo。换个角度看，它也揭示了事实：AI解决问题的路线常比预想更迂回，产出的不仅是结果，还包括大量完全无法预见的中间产物。

95%的Token都让Codex吃了

另有一项数据可以证明这种“生成量膨胀”的趋势。

OpenAI内部99.8%的Token消耗都来自Codex，不是ChatGPT、API调用或DALL·E，而是Codex。公司约90%的人都在使用：设计师开始编写简单脚本，产品经理调用接口验证想法，工程师自然更不例外。

每个人都在生成。

然而，生成越多，“待清理”的积压也越多：代码库不断扩大，抽象层持续加深，绕路逻辑增加，未清干净的旧代码堆叠。这些“生成后遗症”的处理速度，远远落后于生成速度。

于是形成了一种反直觉局面：AI编程工具能力越强，维护工作反而越重。AI将“写”的门槛降至地板，却把“删”与“理”的压力全部留给人。

把Sweeper的工作交给工具

当然，这并不代表AI面对Sweeper只能认输。换个思路，是否也能借助工具解决Sweeper的工作？

以编译错误为例，AI生成的代码运行后可能出现满屏红字。手动逐个修复很费力，一键修复器却能扫描全部编译错误，依次交给AI分析和修复，完成后再自动运行验证。

再看代码规范，面对Checkstyle几千条违规，人工修改令人疲惫；代码整洁器能够批量检测并自动修复，同时清理冗余代码和SAST问题。

安全漏洞也是如此。OWASP Top 10问题在AI生成代码中并不少见，个人排查可能无法覆盖全部，而安全修复器可以进行系统性扫描和修复。

依赖版本冲突、过期依赖及冗余依赖等Sweeper级体力工作，Jar依赖修复器也能处理得七七八八。

单元测试补全同样可以自动化：单元测试生成器采用“环境检测→生成→编译→运行→修复”五步闭环，处理这一典型Sweeper任务。

拆开来看，这些工作都属于Boris Cherny定义的Sweeper或Maintainer职责。飞算JavaAI的AI工具箱包含十款工具，重点正是处理这些任务：不在“写新代码”上竞争，而是专注“收拾旧代码”。

飞算 JavaAI AI工具箱是由 AI 驱动的智能开发辅助工具集，可覆盖多个复杂的软件开发场景。它不是单一功能，而是持续扩展的工具矩阵，目前已上线 9大核心工具，包括项目文档生成、单元测试、框架升级、代码整洁、安全修复及依赖管理等高频场景。

概括而言，就是把重复、繁琐且容易出错的开发任务交由 AI 自动处理。

这条路线与Andrew Ambrosino所说的“更擅长删代码”具有相同底层逻辑。不过，它并非直接让AI删除代码，而是让AI识别哪些地方该删、该修或该重构，再统一批量执行。

能够运行并不是终点

Andrew在访谈中还提出：过去，人们担忧“想法没人实现”；如今AI让实现成本几乎降至零，这种恐惧消失了。新的担忧是，几十个团队可能同时生成几十个原型，却没人判断哪个值得继续。

“taste”和“curation”——也就是品味与筛选——已经成为比技术实现更稀缺的能力。

这与Sweeper问题其实是一体两面：“没人删代码”留下的是执行层面的债务，“没人判断该删什么”造成的则是决策层面的真空。

这两个层面的问题，都无法只靠速度更快的代码补全解决。

走到当前阶段，AI编程真正形成差距的已不是谁能生成更多代码，而是代码生成之后，你将如何处理它们。