很多开发者最近遇到一个很矛盾的场景。

以前写代码：

一个功能写一天。

改几十行代码。

提交之前，自己基本知道每一行为什么这么写。

所以Review压力并不大。

---

现在使用Codex以后：

一个需求交给AI。

几十分钟后：

代码生成了。

测试通过了。

Diff看起来也很漂亮。

甚至比自己手写的代码更规范。

但是到了最后一步：

提交。

合并。

上线。

很多人反而开始犹豫。

因为脑子里会出现一个问题：

“代码看起来没问题，但我真的理解它了吗？”

---

这就是AI Coding时代一个越来越明显的变化：

AI正在降低代码生产成本，但正在提高代码信任成本。

以前最大的困难：

写出来。

现在新的困难：

敢不敢让它进入真实系统。

---

一、真实开发场景：AI写完代码以后，为什么反而需要更多确认？

假设你让Codex处理一个Bug。

任务：

修复用户登录偶发失败。

以前：

你自己定位。

修改几个文件。

测试。

提交。

整个过程你对变化范围非常清楚。

---

现在：

Codex开始分析。

它发现：

问题可能涉及：

认证模块。

Token刷新逻辑。

缓存机制。

异常处理。

于是它修改：

5个文件。

增加：

几个辅助函数。

补充：

测试案例。

最后告诉你：

“已完成。”

---

你打开Diff。

每一处修改看起来合理。

但是你开始思考：

为什么这里换成这种方式？

这个异常处理是不是覆盖所有情况？

这个新的抽象以后会不会影响其他模块？

---

问题不是：

AI有没有完成任务。

而是：

你是否拥有足够的信息判断它完成得对。

---

这就是AI时代新的工程问题：

代码生成速度超过人的理解速度。

---

二、为什么AI写得越快，Review反而越难？

因为软件工程里有两个完全不同的过程：

代码生成

回答：

“怎么实现？”

---

代码理解

回答：

“这个实现是否适合整个系统？”

---

AI现在快速提升的是第一部分。

它可以：

生成函数。

补充测试。

修改结构。

寻找依赖。

---

但第二部分仍然需要大量人工判断。

因为真实项目里有很多东西：

不会直接写在代码里。

例如：

为什么这个接口不能改。

为什么这里故意保留重复。

为什么这个模块没有抽象。

为什么这个旧逻辑不能删除。

---

这些信息属于：

工程上下文。

而不是：

代码语法。

---

所以出现一个现象：

AI越来越会写。

但人越来越需要理解。

---

三、背后的机制：AI提高了Code Throughput，但没有同步提高Trust Throughput

可以把AI Coding看成两个速度。

第一个：

Code Throughput

代码产生速度。

AI正在大幅提高。

---

第二个：

Trust Throughput

人能够可靠验证代码的速度。

提升没有那么快。

---

以前：

开发者一天写200行。

晚上Review。

基本匹配。

---

现在：

AI几个小时生成2000行。

但人的理解能力没有增加10倍。

于是产生：

验证排队。

---

这和生产系统很像。

工厂生产速度提升以后，如果质检能力没有提升，最后瓶颈一定会转移。

AI Coding也是如此。

以前瓶颈：

生产。

现在瓶颈：

验证。

---

四、为什么“测试通过”也不能让人放心？

很多人会说：

那让AI跑测试。

测试通过不就好了？

测试当然重要。

但测试只能回答：

“已有规则有没有被破坏。”

它不能完全回答：

“这个设计是不是正确。”

---

例如：

AI优化一个订单模块。

测试全部通过。

但是：

它把两个本来应该独立变化的业务逻辑合并了。

今天没问题。

半年以后：

一个需求变化。

整个模块开始互相影响。

---

测试验证的是：

当前行为。

工程Review考虑的是：

未来演进。

---

所以AI时代：

测试负责发现错误。

Review负责判断方向。

两者不能互相替代。

---

五、为什么未来这个问题会越来越明显？

因为AI正在从：

代码助手。

变成：

代码执行Agent。

---

以前：

AI建议。

人执行。

风险小。

---

现在：

AI可以：

搜索项目。

修改多个文件。

运行命令。

调整方案。

持续迭代。

---

任务范围越大：

一次错误影响越大。

---

比如：

修改一个函数。

影响范围：

几十行。

容易检查。

---

让Agent重构一个模块。

影响范围：

多个文件。

多个依赖。

多个业务流程。

---

这时候：

“AI写得快”

和：

“人能确认得快”

之间的差距会越来越明显。

---

六、可以用“AI修改信任成本”判断自己的阶段

这里建立一个自测指标：

AI修改信任成本

简单理解：

一次AI完成任务以后，你需要花多少成本确认：

它真的可以上线。

---

可以观察三个问题。

---

第一：

你打开AI生成的Diff以后，多久能理解？

如果：

几分钟。

说明修改范围可控。

---

如果：

需要重新阅读大量代码。

说明信任成本增加。

---

第二：

AI修改以后，你主要检查什么？

如果只是：

格式。

语法。

测试。

说明风险低。

---

如果需要判断：

架构。

业务影响。

隐藏逻辑。

说明任务已经进入工程级协作。

---

第三：

你是否经常出现：

“代码没错，但是我不敢合。”

如果经常出现：

说明你的瓶颈不是生成。

而是信任。

---

七、如何降低AI代码的信任成本？

第一：

控制修改范围。

不要让AI一次解决整个问题。

复杂任务拆小。

让每次变化容易理解。

---

第二：

让AI解释修改理由。

不要只要求：

“改好。”

要求：

说明：

为什么修改。

影响范围。

风险点。

验证方式。

---

第三：

建立自动验证链。

包括：

测试。

Lint。

类型检查。

CI。

安全扫描。

让机器先过滤问题。

---

第四：

让AI先提出方案。

复杂任务：

先分析。

再修改。

先确定方向。

再执行。

---

第五：

保持明确边界。

告诉AI：

哪些地方不能动。

哪些接口必须保持。

哪些优化不属于当前任务。

---

八、AI修改信任成本低：Plus通常够用

如果你的情况：

AI主要负责：

补代码。

修小Bug。

生成测试。

完成明确任务。

修改范围有限。

你可以快速理解Diff。

那么你的核心需求：

是提高开发速度。

Plus通常已经能够满足。

---

九、AI修改信任成本高：Pro价值开始体现

另一类用户：

每天使用Codex处理：

大型项目。

复杂模块。

多文件修改。

长时间Agent任务。

AI已经成为主要开发生产力。

---

但关键不是：

AI写多少。

而是：

你是否已经建立：

测试体系。

Review流程。

任务拆分。

风险控制。

---

如果这些已经成熟，而你的主要瓶颈变成：

AI产出太多。

复杂任务太多。

需要持续处理大量AI生成代码。

那么更高强度使用方式才开始体现价值。

---

最后：未来开发者不是减少Review，而是改变Review方式

AI时代，很多人期待：

“以后AI写代码，人不用管。”

但真实方向可能不是这样。

未来人不会逐行检查AI写的每一行代码。

那效率太低。

真正变化是：

从：

检查代码。

变成：

检查决策。

---

人关注：

为什么这样改。

影响哪里。

风险是什么。

是否符合长期方向。

---

AI负责：

快速实现。

快速验证。

快速探索。

---

所以未来优秀开发者，不一定是：

最会写代码的人。

而是：

最会判断AI代码是否值得进入系统的人。

---

如果AI只是辅助开发：

Plus通常够用。

如果AI已经成为主要生产力，而你的瓶颈变成：

理解、验证、管理大量AI生成代码：

Pro才开始真正匹配。

AI Coding真正的挑战，不是让AI写更多代码。

而是：

让人类能够放心地使用更多AI生成的代码。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。