最近使用Codex做复杂任务时会出现一个很有意思的变化。以前AI能力弱的时候大家担心的是“它到底能不能做出来”现在AI越来越强以后问题慢慢变成了“它说做完了我到底能不能相信”比如你让Codex修一个Bug。十几分钟后它告诉你代码已经修改。测试已经通过。相关文件已经检查。任务完成。看起来一切正常。但真正准备Merge的时候你还是会打开Diff。看看它到底改了什么。再检查有没有碰到不该碰的地方。甚至重新跑一遍关键测试。于是出现一个很反直觉的现象AI完成任务的能力越来越强但人对AI结果的确认需求并没有同步下降。甚至在复杂任务里AI越自主人反而越想确认“它中间到底做了什么”为什么问题已经不只是模型准确率。而是Agent进入真实工程以后一个新的能力开始变得重要可验证性。一、以前为什么没有这么明显的“信任问题”因为以前AI承担的任务很小。比如帮你写一个函数。解释一段代码。生成一个SQL。补几个测试。结果就在眼前。你看几分钟大概就能判断对不对。这种情况下生成结果 ≈ 可检查结果。但Agent模式改变了这个关系。现在你可以直接告诉Codex“帮我调查这个Bug找到原因修改代码并运行测试。”然后它自己搜索Repository。读取文件。建立假设。运行命令。修改代码。执行测试。发现问题。再次修改。最后告诉你Done。这时候你看到的已经不是完整工作过程。而是整个长任务被压缩以后留下来的最终结果。问题也随之出现AI执行的过程越来越长而人直接观察到的过程越来越少。这才是“为什么做完了还不敢直接接受”的第一层原因。二、真正变化的不是AI准确率而是“执行距离”可以把这里的变化理解成一个概念人与AI结果之间的执行距离以前你告诉AI写20行代码。AI返回20行代码。执行距离非常短。现在你告诉Agent“修复这个问题。”中间可能发生几十次操作。你的输入和最终结果之间隔着搜索。判断。工具调用。文件修改。测试。重新规划。再验证。执行距离一下变长了。而执行距离越长就意味着中间存在越多你没有直接参与的决策。这时候即使最终测试通过人也会自然产生一个问题“测试通过证明了什么”这其实已经进入了比“AI准确率”更深的一层。三、测试通过为什么仍然不能等于“任务正确”假设Codex修复一个权限Bug。最后告诉你42个测试全部通过。听起来很好。但测试通过只能证明现有测试覆盖到的行为没有失败。它不一定证明修改范围合理。业务规则没有变化。安全边界没有变化。没有引入新的隐藏风险。例如一个权限问题。AI最简单的解决方式可能是放宽某个判断。测试通过了。Bug也消失了。但如果这个判断本身承担着安全边界问题其实不是被“正确修复”。而是限制被绕开了。从代码执行角度成功。从业务角度可能错误。从安全角度甚至可能更危险。所以真正可靠的Agent结果不能只有一个PASS。四、真正的验证不是一个动作而是一条Evidence链这是理解Agent时代非常关键的一点。很多人说“我已经验证过了。”实际上可能只是跑了一次测试。但真实工程中的“验证”至少存在几个不同层面的证据。最基础的是功能证据程序能不能运行测试有没有通过然后是修改证据Diff是否符合原任务有没有修改不相关文件有没有扩大Scope再往后是业务证据结果是不是符合真实业务约束有没有改变没有写进测试里的规则最后还有风险证据权限、安全、数据、兼容性有没有发生变化所以真正能够支持“这个Agent任务可以接受。”的不是一个测试结果。而是一整条Evidence Chain。也就是功能正确→ 修改合理→ 业务符合→ 风险可接受当这条链完整时AI结果才真正接近“可信”。五、为什么Agent越强Evidence反而越重要这看起来有点矛盾。模型越强。不是应该越不需要检查吗恰恰相反。因为模型越强以后我们会把更大的任务交给它。以前让AI改一个函数。失败成本有限。现在让Agent修改多个模块。完成完整Feature。处理数据库迁移。修复复杂线上问题。一次Agent任务影响的系统范围正在扩大。这意味着即使错误率下降单次错误的影响范围也可能上升。这和自动驾驶有一点类似。真正决定系统能不能被大规模使用的不只是“它大多数时候开得对不对。”还包括出现关键情况时我们能不能知道它为什么这样判断。风险在哪里。有没有证据支持这个决策。AI Coding进入Agent阶段以后也开始面对类似的问题。六、未来真正稀缺的可能不是生成能力而是“证明能力”代码生成越来越便宜。Agent执行也会越来越快。那么未来真正昂贵的东西是什么可能是证明AI做的是对的。这会让软件开发的价值链发生变化。以前大量时间花在写代码。未来越来越多时间可能花在定义验收标准。建立测试。检查Diff。验证业务约束。确认风险边界。也就是说开发者的角色会逐渐从代码生产者转向目标定义者 Evidence判断者。这也是为什么随着Agent能力提高测试体系、规则文件、CI、自动化验证的重要性反而会上升而不是下降。因为Agent自主性越高系统越需要可验证性。七、怎么判断自己的AI结果到底“好不好验证”这里可以建立今天第二个自测指标结果可验证度它不是看AI回答得像不像真的。而是看一个Agent任务完成以后你能不能快速回答四个问题。第一它到底改了什么你能不能快速知道修改文件。修改范围。关键逻辑变化。如果需要重新读半小时代码才能知道可验证度已经下降。第二为什么这样改Agent有没有留下足够信息解释问题原因。选择方案。为什么没有选择其他方案。如果只有“任务已完成。”可验证度很低。第三什么证据证明它是对的有没有测试。Lint。类型检查。关键业务验证。安全检查。而不是单纯一句“应该没问题。”第四还有什么没有被验证这是最容易被忽略的。真正好的Agent结果不只是告诉你“我验证了什么。”还应该让你知道“哪些东西我没有验证。”因为未知边界本身就是风险的一部分。八、降低验证成本不是让自己检查更多很多人发现不敢相信AI以后会走向另一个极端每一行都人工检查。这其实会把AI节省的时间重新消耗掉。更好的方法是让验证本身变成Workflow的一部分。比如复杂任务开始前就明确什么算完成。哪些行为不能变化。哪些测试必须运行。哪些文件原则上不能修改。然后任务完成时要求Agent输出修改范围。核心Diff。验证结果。潜在风险。未验证部分。这样做的本质是把原来的“AI做完 → 人从头调查”变成“AI执行 → 同时积累Evidence → 人检查关键证据”。人的角色从重新做一遍任务变成检查证据链是否完整。效率会完全不同。九、为什么这个问题未来会越来越明显因为未来Agent任务会越来越长。如果AI只是写一个函数。结果很好验证。但如果未来一个Agent可以持续工作几十分钟甚至更久读取几十个文件。调用大量工具。修改多个模块。执行多轮测试。那么最终一句“任务完成。”所包含的信息会越来越少。任务越复杂结果和过程之间的信息差越大。这意味着Agent能力越往前发展我们越不能只关注完成率。还要关注可验证率。真正成熟的AI工程系统可能不是那个“永远告诉你任务完成”的系统。而是那个能够清楚告诉你我做了什么。为什么这样做。哪些证据支持结果。哪些风险仍然存在。的系统。十、结果可验证度高Plus通常已经够用如果你的日常任务主要是小功能。Bug修复。局部代码修改。简单项目。AI完成以后Diff很容易理解。测试结果清楚。业务影响范围有限。你几分钟就能判断是否可以接受。那么你的结果可验证度很高。这种情况下核心需求仍然是提高单任务效率。Plus通常已经能够覆盖大量日常使用。没有必要因为“AI偶尔需要Review”就认为自己必须进入更高方案。十一、什么时候Pro才真正开始匹配另一类情况完全不同。每天都在运行复杂Codex任务。大型Repository。长时间Agent Workflow。跨模块修改。多个任务同时推进。每一个任务都产生大量代码。Diff。测试结果。工具执行记录。风险判断。这时候真正的工作负载已经从生成代码变成管理Agent结果和Evidence。如果你已经建立固定验收标准。自动测试。明确任务边界。结果摘要。风险检查。但仍然需要持续运行大量复杂Agent任务那么更高强度使用能力才开始有实际意义。所以判断逻辑不是“我不相信AI所以我要Pro。”而是“我已经把AI结果变得可验证但每天仍然有大量复杂Agent Workflow需要持续运行。”这才是更接近Pro阶段的信号。最后Agent真正成熟的标志不是“做完”而是“能够证明做对了”未来AI Coding会越来越强。“能不能写代码”这个问题的重要性会逐渐下降。接下来真正重要的问题可能变成它做的东西我们能不能快速确认所以以后看到Codex告诉你Task completed.不要只问“测试通过了吗”还应该问为什么这个结果值得接受如果一个AI任务能够留下完整Evidence目标满足。修改合理。业务符合。风险可接受。那么你才能真正放心地把更多工作交给Agent。所以Agent时代真正的信任不应该来自“模型很强。”而应该来自“我有足够证据知道它做对了。”如果你的任务简单、结果透明、Evidence容易建立Plus通常够用。如果你已经进入大量复杂Agent任务并且验证体系本身已经成为日常工程基础设施Pro才开始真正匹配这种工作强度。未来AI Coding真正拉开差距的也许不是谁生成得最多。而是谁能够用最低的验证成本建立最可靠的Evidence链。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型分享稳定的AI会员订阅渠道。