你修了一个小bug，AI帮你顺带改了五层的抽象逻辑。代码多了一堆，bug修好了，但没人知道那些多出来的东西什么时候会爆炸。

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编程走到现在这个节点，真正拉开差距的不再是谁能生成更多代码。而是生成完以后，你拿这些代码怎么办。