近期一次播客访谈中，负责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编程发展到当前阶段，真正形成差距的已不是谁生成的代码更多，而是生成完成后，如何处理这些代码。