很多开发者刚开始使用ChatGPT、Codex时，最关注的是：

AI能不能把任务做出来。

比如：

能不能修Bug。

能不能写完整Feature。

能不能理解大型项目。

能不能自己跑测试。

但当AI开始越来越能独立执行以后，一个新的问题会越来越明显：

AI会做，不等于你能快速确认它做对了。

于是很多人会遇到一种很奇怪的状态。

AI半小时完成了任务。

你却花一个小时确认：

它到底有没有改坏别的地方。

AI一次生成几百行代码。

你真正耗时间的却是：

验证结果。

检查边界。

补测试。

确认业务行为。

最后发现：

AI执行能力已经不是瓶颈。

真正限制效率的是：

这个任务到底有没有办法被快速、可靠地证明“已经完成”。

这就是AI Coding进入Agent阶段以后，一个非常关键的新概念：

Verifiability——可验证性。

未来AI开发效率的上限，可能越来越不是：

AI能做多少。

而是：

AI做完以后，你能多快证明它真的做对了。

---

一、真实场景：AI十分钟改完，你却一个小时不敢合并

假设你让Codex处理一个任务：

“修复订单退款以后库存偶尔没有恢复的问题。”

AI开始分析。

找到退款逻辑。

检查库存更新。

修改事务处理。

补充测试。

运行测试。

最后告诉你：

Done。

总耗时：

20分钟。

看起来效率非常高。

但真正准备合并时，你开始检查：

普通退款是否正常？

部分退款呢？

重复回调呢？

消息队列延迟呢？

数据库事务失败呢？

退款成功但库存服务超时怎么办？

很快你发现：

AI虽然已经完成了代码修改，

但你并不能快速证明：

整个退款链路已经可靠。

于是20分钟的执行，变成了后面一两个小时的人工验证。

这里真正的瓶颈已经不是：

Coding。

而是：

Verification。

---

二、为什么会发生？因为“能执行”和“能证明正确”是两种完全不同的能力

一个任务可以分成两部分。

第一部分：

Execution

把事情做出来。

第二部分：

Verification

证明结果满足要求。

以前人工开发时，两者经常绑定在一起。

因为代码是你自己写的。

你知道：

为什么这样设计。

哪些地方改过。

哪些风险需要注意。

所以验证成本相对可控。

但AI介入以后：

执行过程越来越自动化。

AI可能自己：

搜索。

分析。

修改。

测试。

继续迭代。

人的参与越来越少。

于是任务结束时：

代码已经产生。

但你的“理解状态”未必同步。

这时候就会出现一个差距：

Execution Speed越来越快，但Verification Speed没有同步提升。

真正的吞吐因此被后者限制。

---

三、工程机制：AI开发正在出现Verification Bottleneck

可以把AI Coding系统想成一条流水线。

前半段：

需求 → 分析 → 修改 → 测试。

后半段：

验证 → Review → 验收 → 合并。

AI现在正在显著加速前半段。

但如果后半段没有同步升级，就会出现积压。

例如：

以前一天完成2个任务。

每个任务都能完整Review。

现在Agent一天可以生成8个任务结果。

但你仍然只能认真验收3个。

那么真实产能不是8。

而是：

3。

另外5个只是等待验证的WIP。

所以未来AI开发效率真正应该看的，不只是：

Task Generation Rate。

还要看：

Verified Task Throughput——被可靠验证并进入下一阶段的任务数量。

这才是真实产出。

---

四、为什么“测试通过”还不能等于“可验证”？

因为测试只是Verification的一部分。

测试能够回答：

当前测试覆盖的行为是否符合预期。

但不能自动回答：

任务目标是不是定义正确。

AI有没有改到不该改的范围。

隐藏业务规则有没有被破坏。

未覆盖场景有没有风险。

架构影响是否合理。

所以一个真正可验证的任务，通常需要多种证据。

可以把它理解成：

Evidence Chain——证据链

例如一个Bug修复任务。

至少可能需要：

复现问题的证据。

修复后的行为证据。

回归测试。

边界场景测试。

影响范围说明。

未验证风险说明。

只有这些证据能够串起来，你才能快速判断：

任务是真的完成。

而不是：

“AI说完成了。”

---

五、为什么有些任务天然比另一些任务更适合交给AI？

因为可验证性不同。

比如：

“把这20个接口补上类型定义。”

非常适合AI。

为什么？

因为完成标准明确。

结果容易检查。

可以自动跑类型检查。

验证成本低。

再比如：

“优化整个支付系统架构。”

就完全不同。

什么叫优化？

性能更好？

稳定性更高？

代码更漂亮？

维护成本更低？

很多标准难以量化。

即使AI完成大量修改，你仍然很难快速证明：

这个结果真的更好。

所以Agent任务能不能规模化，不只取决于AI能力。

还取决于：

任务是否天然具有清晰的验证路径。

---

六、为什么未来“可验证性”会越来越成为任务设计的一部分？

以前我们定义任务时，更多关注：

要做什么。

未来可能还要增加一个问题：

怎么证明它做完了？

比如不要只写：

“优化用户接口。”

而应该写：

“把P95响应时间从800ms降到400ms以内，不改变Public API，原测试全部通过。”

这时候：

目标清楚。

约束清楚。

验证方式清楚。

Agent执行完以后，人不需要重新思考：

“这个算不算完成？”

只需要检查证据。

这就是为什么未来任务设计可能越来越接近：

Goal + Constraint + Evidence

而不只是一个Prompt。

---

七、为什么Agent越自主，可验证性反而越重要？

因为自主性意味着：

人看不到更多中间过程。

如果AI每一步都问你：

验证压力其实不大。

因为你一直参与。

但真正高自主Agent会：

自己规划。

自己执行。

自己调整。

自己处理失败。

最后只把结果交回来。

这时候人失去了很多过程信息。

所以为了弥补过程透明度下降，结果必须拥有更强的：

Evidence Density——证据密度。

也就是说：

AI越独立。

最终返回的结果越不能只有：

“完成。”

而应该包含：

改了什么。

为什么改。

验证了什么。

哪些没有验证。

风险在哪里。

这才是真正适合长期运行的Agent输出。

---

八、自测指标：你的任务“可验证性”到底高不高？

这里可以建立一个指标：

可验证性指数

不用精确打分，可以看四个问题。

第一，任务完成条件能不能提前写出来？

如果不能：

可验证性低。

第二，结果能不能通过自动化方式判断？

比如：

测试。

性能指标。

类型检查。

接口契约。

越多，越容易验证。

第三，AI做完以后，你是否还需要重新调查整个过程？

如果经常需要：

说明证据不足。

第四，两个开发者看到同一个结果，是否大概率会得出相同结论？

如果一个人说完成，另一个人说还差很多：

说明验收标准太主观。

可验证性越高，AI任务越容易规模化。

---

九、如何提高AI任务的可验证性？

第一：任务开始前就定义证据

不要等AI做完再想：

怎么验收。

应该提前明确：

哪些测试必须通过。

哪些指标必须达到。

哪些行为不能改变。

比如：

不是：

“修复缓存问题。”

而是：

“问题无法再次复现；相关回归测试通过；缓存失效后数据最终一致；不改变接口行为。”

这样AI从一开始就知道：

它最终需要证明什么。

---

第二：把模糊目标转成可观察结果

“提高稳定性。”

太模糊。

“减少错误率。”

还是模糊。

更好的方式：

“这三类异常不再出现，并增加对应测试和监控。”

可观察，才能可验证。

---

第三：让AI输出Evidence，而不只是Summary

普通Summary告诉你：

做了什么。

Evidence告诉你：

为什么可以相信它。

可以要求AI输出：

测试结果。

关键Diff。

未覆盖场景。

风险假设。

需要人工确认的位置。

这样Review成本会明显降低。

---

第四：高风险任务要保留可回滚性

如果一个结果很难证明绝对正确，至少应该保证：

容易撤销。

容易隔离。

容易恢复。

这其实把：

Verification和Reversibility连接起来了。

因为真实工程里，不可能所有东西都在上线前100%验证。

那就要确保：

错了以后损失可控。

---

十、为什么“可验证性低”时，不应该先追求更多AI产能？

这是很多人容易踩的坑。

如果一个任务：

AI做完以后你要花很久才能确认。

这时候让更多Agent并行，只会得到：

更多待验证结果。

最后会形成：

Agent都在跑。

人一直堵在Review。

看起来AI使用量越来越高。

真实Throughput却没有提高。

所以如果Verification已经是瓶颈：

继续扩大Execution，只会放大积压。

应该先提高：

测试自动化。

Done Criteria。

Evidence输出。

风险分层。

可观察性。

把后半段打通。

---

十一、可验证性高：Plus通常已经能带来很高效率

如果你的日常工作主要是：

明确Bug。

局部功能。

测试生成。

脚本。

接口实现。

并且这些任务都能通过明确规则快速验证，

那么Plus通常已经能够覆盖很多真实开发。

因为你的任务具有：

低验证成本。

AI产生的结果也容易被快速接受。

这种情况下，工作流通常已经比较健康。

---

十二、可验证性低，也不要把问题归因于模型不够强

如果你经常遇到：

AI说完成。

你不敢合并。

测试通过。

仍然不知道风险。

大量任务排队等待人工检查。

那么真正应该优化的是：

Verification System。

而不是第一时间升级AI。

因为更强的执行能力解决不了：

没有验收标准。

没有证据链。

没有自动测试。

没有风险分层。

这些工程问题。

---

十三、什么时候Pro才真正开始匹配？

更接近Pro的状态是：

你的任务已经高度可验证。

复杂任务开始前有明确Done Criteria。

AI输出包含Evidence。

自动测试和检查已经覆盖大量低价值验证。

人工只处理真正高价值判断。

AI任务完成以后能够快速进入Review和合并。

但即使这样，真实工作里仍然持续存在：

大型Repository。

复杂长任务。

高Context工程分析。

多个高价值Agent任务并行。

这时候AI侧容量和执行能力才真正可能成为瓶颈。

所以判断逻辑不是：

“我需要AI做更多，所以我要Pro。”

而是：

“我已经能可靠验证更多AI产出，现在AI执行能力才限制真实吞吐。”

---

最后：AI时代真正值钱的，不只是让任务完成，而是让完成“可以被证明”

未来Agent会越来越强。

它能写更多代码。

做更长任务。

运行更多工具。

甚至独立工作更久。

但真正进入生产环境以后，最终一定要面对一个问题：

我为什么相信这个结果？

如果答案只是：

“AI说它完成了。”

这还不是成熟工程。

真正成熟的系统应该能够给出：

测试证据。

行为证据。

风险证据。

边界证据。

必要时还有：

回滚能力。

所以未来AI开发效率真正的上限，可能不是：

AI一天能完成多少任务。

而是：

一天有多少任务能够被低成本、可靠地证明已经完成。

如果你的任务可验证性高、工作负载适中：

Plus通常已经够用。

如果验证体系已经成熟，而大量复杂Agent任务仍然持续受AI侧能力限制：

Pro才真正开始匹配。

AI越会做事以后，人真正需要设计的，不只是任务本身。

还包括：

这个任务完成以后，我们准备用什么证据相信它。

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