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问题。

安全漏洞也是如此。AI生成的代码中并不少见OWASP Top 10问题，仅凭人工检查可能无法全面发现，安全修复器则能够进行系统化扫描和修复。

至于依赖版本冲突、过期依赖和冗余依赖，这些属于Sweeper级别的重复工作，Jar依赖修复器能够解决大部分。

还有单元测试补全：单元测试生成器按照“环境检测→生成→编译→运行→修复”五步形成闭环，把补充测试这一典型Sweeper任务转为自动化流程。

若分别来看，这些任务全部属于Boris Cherny定义中Sweeper或Maintainer负责的工作。飞算JavaAI的AI工具箱包含十款工具，核心方向正是处理这些事务：不再比拼“写新代码”，而是着力“收拾旧代码”。

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

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

这条路径与Andrew Ambrosino提出的“更擅长删代码”具有相同的底层逻辑。区别在于，它不是直接要求AI删除代码，而是让AI判断哪些地方该删、该修或该重构，再进行批量执行。

能够运行并非终点

Andrew还在访谈中提出另一个观点：过去，人们担忧“想法没人实现”；如今，AI让实现成本接近于零，这种恐惧已经消失。新的问题却随之出现，几十个团队可能同时产出几十个原型，但没有人判断哪一个值得继续推进。

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

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

而无论哪一层问题，都无法仅靠速度更快的代码补全来解决。

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