过去使用 AI 编程时，很多开发者最期待的一件事就是：

代码生成再快一点。

写接口需要半小时，如果 AI 五分钟能完成，就是明显提效。

但随着 Codex、Claude Code 这类 Coding Agent 开始能够连续修改多个文件、运行测试，甚至同时执行多个开发任务，一个新的问题反而越来越明显：

AI写代码的速度已经很快了，人却开始看不过来了。

上午同时派出去几个任务：

• 一个修Bug；
• 一个补测试；
• 一个重构模块；
• 一个更新依赖。

过一会儿回来，可能已经出现：

十几个修改文件、几百行Diff、多个测试结果。

这时候真正限制开发效率的，已经不再是：

“代码生成得够不够快？”

而逐渐变成：

“这些代码我什么时候才能审核完？”

---

一、以前开发者的瓶颈是“生产代码”

传统软件开发，大量时间花在具体执行上。

例如做一个功能：

理解需求
↓
寻找相关代码
↓
设计方案
↓
修改文件
↓
运行测试
↓
修复报错
↓
提交代码

真正写代码和调试可能占掉很大一部分时间。

因此早期 AI 编程工具只要能做到：

把代码生成速度提高一倍，

价值就已经很明显。

但 Coding Agent 开始改变这个结构。

当你只需要告诉它：

修复订单重复提交问题，保持现有接口兼容，并补充回归测试。

Agent可以自己去：

找文件；

查看调用链；

修改代码；

运行测试；

继续根据报错调整。

于是“生产代码”这一部分开始越来越容易被自动化。

问题随之转移到了下一环：

谁来确认这些修改真的正确？

---

二、AI一次改得越多，人审核的压力反而越大

假设以前开发者自己一天修改：

300行代码

这些代码是自己一步一步写出来的。

为什么这样设计、为什么改这个文件、为什么加入这个条件，自己基本都知道。

审核成本其实没有想象中那么高。

但现在可能同时让3个Agent工作。

结果一天产生：

任务A：修改280行
任务B：修改430行
任务C：修改350行

一天突然多出了1000多行AI生成代码。

真正的问题来了：

这1000行你敢不看就直接合并吗？

显然不合适。

于是AI把“写代码”的成本降低以后，又快速制造出了一个新的工作量：

Review workload，也就是审核工作量。

这也是为什么Agent数量不能简单理解成：

开4个Agent = 开发效率提升4倍。

因为最终这些结果仍然需要人理解和判断。

---

三、真正耗时的不是看Diff，而是理解“为什么这么改”

很多人会说：

看Diff不是很快吗？

如果只是改3行当然很快。

但大型Agent任务经常不是这样。

例如你让Codex：

重构用户权限模块，减少重复权限判断。

结果它修改：

auth.ts
permission.ts
user.ts
middleware.ts
roles.ts
permission.test.ts
package.json

这时候审核并不是简单看看代码有没有语法错误。

你真正需要确认的是：

为什么改 middleware.ts？

为什么新增这个工具函数？

为什么测试预期发生变化？

这个公共方法会不会影响其他模块？

新增依赖真的有必要吗？

原本的权限边界有没有被改变？

也就是说：

AI负责产生Diff，人负责重新建立对Diff的理解。

而理解一个陌生修改，通常比自己写几行代码更费脑。

---

四、Agent越多以后，“上下文切换”开始成为新问题

假设你同时运行4个Agent：

Agent A：修登录Bug
Agent B：重构支付模块
Agent C：升级React依赖
Agent D：补订单测试

每个任务单独看都没问题。

但等四个结果同时回来以后，你需要不断切换脑子里的上下文：

刚刚还在看Token；

下一分钟切到支付状态机；

再切到前端依赖；

然后又回到订单逻辑。

这和传统开发中的多任务切换非常类似。

甚至可能更明显。

因为AI可以比人更快地产生新的待审核工作。

所以多Agent真正的上限，最终可能不是：

电脑能同时运行多少个Agent。

而是：

开发者一天能够高质量审核多少个Agent结果。

---

五、这也是为什么“小任务、小Diff”会越来越重要

以前很多人给AI派任务喜欢写：

优化整个订单系统。

这种Prompt听起来很省事。

但如果Agent真的认真执行，最后可能变成：

23 files changed
+1380
-620

这时候最痛苦的不是Agent。

而是审核的人。

相比之下，如果把它拆成：

任务1

只解决订单重复查询。

任务2

只整理订单状态判断。

任务3

只补订单异常状态测试。

每一次修改都保持在一个比较容易理解的范围内。

审核成本就会明显降低。

所以Agent时代一个很值得养成的习惯是：

不要只追求Agent一次做更多，而要追求一次产生更容易审核的Diff。

---

六、以后“任务拆分”可能首先服务于审核，而不是AI能力

很多人理解任务拆分，觉得是因为：

AI能力不够，所以要把大任务拆小。

但随着模型越来越强，这个理由可能会慢慢发生变化。

未来即使Agent真的有能力一次完成一个大型重构，也未必应该让它一次完成。

为什么？

因为：

人审核不过来。

例如Agent可以一次修改50个文件。

但如果开发者需要两个小时才能理解所有修改，那么任务粒度依然太大。

所以任务拆分的标准可能逐渐从：

AI一次能不能做完？

变成：

人一次能不能快速审核完？

这其实是一个很重要的变化。

---

七、测试能减少审核压力，但不能完全替代Review

有人可能会想：

既然人看不过来，那就全部交给自动测试。

测试当然会变得越来越重要。

例如：

单元测试；

集成测试；

类型检查；

Lint；

构建；

性能测试。

它们都可以快速告诉开发者：

有没有明显问题。

但测试存在一个天然限制：

它只能检查已经被定义出来的预期。

例如：

Agent把一个接口实现错了；

同时又修改了对应测试。

最后：

100 tests passed

从机器角度看全部正常。

但业务逻辑已经偏了。

所以测试更适合解决：

“有没有违反已知规则？”

而代码审核还要解决：

“整个修改方向到底对不对？”

这两件事不能完全互相替代。

---

八、未来Code Review本身也会越来越Agent化

既然一个Agent可以写代码，自然也可以让另一个Agent审核。

于是工作流可能慢慢变成：

Agent A
负责实现功能

↓

Agent B
检查代码逻辑

↓

自动测试
检查已知规则

↓

开发者
最终审核

这比开发者从头逐行检查所有代码要省很多时间。

甚至可以针对不同任务设置不同审核Agent：

安全Review；

测试Review；

性能Review；

架构Review。

但即使这样，人依然需要决定：

哪些问题真的重要。

因为多个Agent也可能提出大量建议。

如果一个任务最终产生20条Review意见，人还是需要判断哪些要接受。

所以AI Review实际上不是完全消灭审核工作。

更可能是把人的审核进一步提升到：

判断和决策层。

---

九、开发者以后可能需要关注一个新的指标：审核负载

以前衡量AI编程效率，经常看：

一天能完成多少代码；

多少Issue；

多少任务。

但Agent时代可以增加一个新的判断：

审核负载。

可以很简单地问自己：

Agent一天产生的修改，我需要多少时间才能确认可以合并？

如果：

Agent工作2小时；

自己Review只需要15分钟。

说明这套工作流很健康。

但如果：

Agent并行跑了4小时；

最后自己需要6小时才能审核。

那就说明：

Agent产出速度已经超过你的审核能力。

这时候继续增加Agent数量反而没有意义。

真正应该优化的是：

任务粒度；

Diff大小；

自动测试；

验收标准；

Review流程。

---

十、未来开发效率的关键可能不是“生成更多代码”

这一点其实非常重要。

当AI写代码越来越便宜以后，代码本身就不再是最稀缺的东西。

真正稀缺的开始变成：

正确的判断。

哪些代码应该写？

哪些改动不应该做？

这个方案有没有破坏系统边界？

这个依赖值得增加吗？

这个重构真的有必要吗？

这部分工作目前依然高度依赖开发者。

所以未来真正高效的开发者，未必是：

一天让AI生成最多代码的人。

反而可能是：

能够让AI只生成真正需要的代码，并且可以快速判断哪些结果值得合并的人。

---

最后

Codex任务越来越多以后，开发瓶颈正在慢慢发生转移。

以前是：

需求很多，但代码写不完。

以后可能变成：

Agent已经写完了，但Diff看不完。

于是AI编程下一阶段真正需要优化的，就不只是：

更快的模型；

更强的Coding Agent；

更多的并行任务。

还包括：

更小的任务边界；

更明确的验收标准；

更完整的自动测试；

更高效的Code Review流程。

当AI开始拥有非常强的代码生产能力以后，人真正需要保护的，反而变成自己的：

审核能力和判断力。

未来AI编程的效率上限，很可能不再取决于：

“Agent一天能写多少代码？”

而是：

“你一天能够放心合并多少AI写出来的代码？”

---

持续更新 Codex、AI Agent、多Agent协作与大模型开发工作流实战内容，更多深度内容欢迎搜索关注「孤狼GPT」。