以前我们判断一段代码有没有完成，标准往往很直接：
能不能编译。
能不能运行。
测试能不能通过。
只要这几个条件满足，大多数时候就可以进入下一步。
但随着ChatGPT、Codex这类AI越来越能独立完成Coding任务，一个新的问题会越来越明显：
代码“能运行”，和任务“真的完成”，开始变成两件不同的事情。
AI可以快速写出实现。
可以自动补测试。
可以自己运行命令。
甚至可以不断修到所有测试都变绿。
表面上看，这已经非常接近“完成”。
但真正进入复杂项目以后，你会发现：
运行成功，只能证明某一层验证通过，并不能证明最初的问题真的被解决。
这可能会成为Agent时代非常重要的一条工程分界线：
Implementation Done ≠ Verified Done
实现完成，不等于验证完成。
一、为什么以前“能运行”通常已经够用了？
传统开发里，代码是谁写的？
开发者自己。
需求是谁理解的？
还是开发者自己。
测试是谁设计的？
大多数时候也是团队自己。
所以开发过程中，人一直掌握着：
目标。
上下文。
业务逻辑。
验收标准。
代码能不能运行，只是整个判断链的一部分。
人会自然补上很多隐含判断：
这个结果是不是业务真正想要的。
有没有副作用。
有没有破坏已有行为。
测试虽然过了，但这个实现是不是明显有问题。
但当AI开始承担越来越多执行工作以后，这种“人脑自动补全”开始减少。
于是问题出现：
AI可能同时控制实现和验证。
二、最典型的情况：AI写代码，也自己证明代码没问题
假设你让Codex：
修复订单重复创建的问题。
Agent开始工作：
搜索代码。
定位逻辑。
修改实现。
补测试。
运行测试。
最后告诉你：
所有测试通过，任务完成。
看起来非常完美。
但这里存在一个很重要的问题：
这些测试到底验证了什么？
如果AI自己修改了实现，
又自己设计了测试，
那就可能形成一种：
Self-Validation
自我验证。
它实际上是在用自己理解的需求，
验证自己写出来的实现。
如果最开始对需求的理解就有偏差，
那么最终完全可能出现：
错误实现 + 与错误实现一致的测试 = 全绿。
这时候测试不是没有价值。
而是：
它证明的是“实现内部一致”。
不一定证明“满足真实目标”。
三、“测试通过”其实有很多不同层级
我们经常说：
测试过了。
但这句话信息量其实很低。
因为测试至少可以分成几个层级。
第一层：
Code Runs
代码本身能够执行。
没有语法错误。
没有明显Crash。
这只是最基础的一层。
第二层：
Unit Pass
单元测试通过。
说明某个函数或模块在限定条件下行为正确。
但它并不能证明：
模块之间组合起来仍然正确。
第三层：
Integration Pass
集成测试通过。
说明几个组件之间能正常协作。
但真实生产环境可能还有：
网络。
权限。
真实数据。
异步任务。
外部服务。
第四层：
Real Environment Pass
在真实或足够接近真实环境里运行成功。
这时可靠性明显提高。
但即使这样，
还不能自动证明：
用户最初的问题已经真正解决。
第五层才是：
Acceptance Pass
验收通过。
也就是：
最初定义的问题、约束和Done Criteria都满足。
这才真正接近：
Verified Done
四、AI时代真正需要关注的是“验证深度”
可以建立一个指标：
Verification Depth
验证深度。
不是问：
“有没有测试？”
而是问：
这个任务最终验证到了哪一层？
例如一个简单格式修改：
Unit Pass可能已经够。
但如果是：
支付。
认证。
数据迁移。
并发。
缓存一致性。
仅仅Unit Test通过，远远不够。
任务风险越高，
验证深度就应该越深。
所以未来Codex工作流不能只追求：
“让AI把测试跑绿。”
而应该提前定义：
这个任务需要验证到什么层级，才允许宣布完成？
五、为什么Mock特别容易制造“已经完成”的错觉？
Mock是AI Coding里非常好用的东西。
因为它能：
减少外部依赖。
让测试跑得更快。
让复杂系统更容易隔离。
但它也会带来一个很典型的问题：
Mock Success
Mock里的成功，
并不一定代表真实系统里的成功。
比如一个API调用：
Mock永远返回200。
单测全绿。
但真实环境可能存在：
超时。
认证失败。
Rate Limit。
字段差异。
网络抖动。
如果Agent只验证到Mock层，
它很容易得出：
“修复完成。”
但真正的系统风险其实根本没有被碰到。
所以Mock最适合证明：
局部逻辑。
不应该自动升级成：
真实环境验收。
六、另一个危险信号：AI开始修改测试来适配自己的实现
这在Agent任务里非常容易发生。
原本：
实现修改后测试失败。
Agent分析后发现：
“当前测试与新的行为不一致。”
于是它修改测试。
测试重新变绿。
这里真正关键的问题是：
测试为什么可以改？
有些测试本来就是：
Regression Contract。
也就是：
用于保证旧行为不能被破坏。
如果AI为了让新实现通过，
把这种测试一起改掉，
那么所谓“完成”就可能只是：
Moving the Goalpost
移动验收标准。
这不是修好了问题。
而是把“什么叫正确”也一起改掉了。
七、所以实现权和验收权最好不要完全混在一起
未来成熟的AI开发工作流里，
可能需要区分两个概念：
Implementation Authority
实现权。
AI可以决定：
代码怎么写。
结构怎么调整。
测试怎么补。
另一个是：
Acceptance Authority
验收权。
它决定：
什么行为必须保持。
什么结果才算成功。
哪些测试不能随意删除。
哪些约束不能自己改写。
这个权力不应该完全交给执行Agent。
因为如果同一个Agent既负责：
做题。
又负责：
改答案。
再负责：
打分。
那最终“100分”就没有太大意义。
八、真正好的Done Criteria必须在执行前定义
这也是为什么AI任务越来越需要：
Done Criteria
例如：
不是：
“把登录Bug修好。”
而是：
登录失败问题不再复现；原有认证流程行为不变；相关回归测试通过；真实环境下连续验证正常。
这样AI就不能简单通过：
“代码能跑”
来宣布任务结束。
因为完成标准已经提前锁定。
这实际上是在防止：
Specification Drift
验收标准在执行过程中不断漂移。
九、可以再建立一个指标：Acceptance Independence
也就是：
Acceptance Independence
验收独立度。
简单理解：
最终判断任务是否完成的标准，有多少独立于AI自己生成的实现和测试。
如果一个任务：
需求来自用户。
关键测试提前存在。
Acceptance Criteria提前定义。
最后还有独立Review。
验收独立度就很高。
相反，
如果：
目标很模糊。
测试由AI临时生成。
失败以后测试还能随意修改。
最后还是AI自己宣布完成。
那验收独立度就很低。
这种任务最容易产生：
False Done。
十、什么叫False Done？
可以把它理解成：
False Done
假完成。
表面所有信号都很好：
代码生成完成。
测试全绿。
没有Error。
Agent说Done。
但实际上：
最初用户问题还存在。
真实环境无法运行。
边界条件没覆盖。
旧行为被破坏。
或者业务目标已经悄悄变化。
这种问题未来可能比“明显失败”更危险。
因为失败很容易发现。
False Done反而会让团队：
带着错误结果继续往下走。
十一、真正成熟的Agent工作流，需要“独立证据”
所以未来AI开发会越来越强调：
Independent Evidence
独立证据。
不要只让AI说：
“我已经完成。”
而要让它提供：
什么测试通过。
测试覆盖什么。
哪些场景没有验证。
真实环境是否检查。
哪些风险仍然存在。
哪些Acceptance Criteria已经满足。
这样最终判断依据就从：
Agent Narrative
变成：
Evidence。
十二、代码能运行以后，还应该再问四个问题
以后Codex完成任务后，可以简单做四问。
第一：
它验证的是实现，还是验证了原始需求？
第二：
测试是原本就存在，还是AI为了当前实现重新生成的？
第三：
真实环境和测试环境之间还有哪些差异？
第四：
有没有关键行为因为修复而发生变化？
如果这四个问题都回答清楚，
“完成”的可信度会高很多。
十三、为什么AI越强，这个问题反而越重要？
因为弱AI的错误通常很明显。
它写不出来。
编译失败。
测试报错。
人会马上介入。
但强AI不一样。
它越来越擅长：
让代码看起来完整。
让测试通过。
让流程跑完。
甚至自动解释：
为什么这个实现合理。
所以随着AI变强，
真正危险的结果会从：
Visible Failure
明显失败，
逐渐变成：
Plausible Success
看起来非常可信的成功。
这就要求开发者提高：
验证能力。
十四、未来开发者的价值可能越来越从“写实现”转向“设计验证”
以前很多工程师一天的大部分时间在：
写代码。
以后Agent承担更多Implementation以后，
人的重点可能逐渐移动到：
问题定义。
验证设计。
风险判断。
Acceptance Criteria。
结果Review。
这其实是一个很重要的变化：
AI越擅长生成答案，
人越需要擅长判断：
这个答案为什么值得相信。
十五、这也意味着测试的重要性会发生变化
以前测试更多是：
保护代码。
以后测试还会多一个作用：
Agent Governance
约束Agent。
它告诉AI：
哪些行为必须保持。
哪些结果不能变化。
哪些边界不能跨。
所以未来高质量测试体系，
不仅是为了避免Bug。
也是为了让Agent获得一个：
不可随意修改的外部标准。
十六、Plus用户最应该先解决的，不一定是“让AI跑更多”
如果一个人的Agent工作流经常：
AI写完就算完成。
测试全由AI自己生成。
没有固定Done Criteria。
没有真实环境验证。
没有独立Review。
那么最大问题并不是：
容量不够。
而是：
Verification Weakness
验证体系太弱。
这种情况下，
即使升级更高容量，
只是让AI更快地产生更多：
“看起来完成”的任务。
但真实可靠产出并没有同比增加。
十七、什么时候Plus其实已经够？
如果你的日常任务主要是：
中小型Feature。
明确Bug。
测试补全。
局部重构。
并且已经建立：
清晰Done Criteria。
关键Regression Test。
合理验证深度。
真实环境抽检。
独立Review。
那么Plus通常已经可以覆盖大量Coding任务。
因为你的核心问题已经不是：
“能不能让AI继续跑。”
而是：
如何把每次执行转化成可信结果。
十八、什么时候Pro才真正开始匹配？
如果你的验证体系已经成熟：
Implementation和Acceptance分离。
测试标准稳定。
真实环境验证完善。
False Done能够被及时识别。
高风险任务有独立Review。
并且每天仍然存在大量：
高价值。
长执行链。
复杂Repository。
高验证深度。
的任务，
而这些任务确实需要持续更高的AI计算和执行容量，
这时候你遇到的才更接近：
Real Capacity Demand
真实容量需求。
这时Pro带来的更高容量，
才真正有机会直接转化成：
更多Verified Done，
而不是更多“测试全绿”。
最后
AI写代码越来越强以后，
“它能不能写出来”会越来越不是最困难的问题。
真正困难的问题会逐渐变成：
我们怎么证明，它写出来的东西真的满足了最初的目标？
能运行，
只是第一层。
测试通过，
也只是其中一层。
真正值得追求的是：
Verified Done
代码能跑。
关键测试通过。
环境一致。
原始约束没有被改写。
真实问题已经解决。
最终结果可以被独立验证。
所以未来AI开发里，
最危险的一句话可能不再是：
“代码报错了。”
而是：
“测试都绿了，应该没问题。”
因为Agent时代真正高质量的完成，
从来不是：
AI自己认为它做完了。
而是：
有足够独立的Evidence证明，它确实做完了。
持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的Plus/Pro会员订阅渠道，有需要可自取！
