AI Coding 的上半场是生成，下半场是验证？AI 代码被采纳，不代表需求可验收
AI Coding 最先降低的，是写代码的成本。
但它很快带来另一个问题：代码生成得越快、越多，谁来确认这些实现结果是可接受的？
很多团队最早感受到这个问题，不是在生成阶段，而是在 Review 阶段。
AI 可以很快生成一大段代码，但如果每一次都要研发人员逐行读完，再判断有没有问题、能不能合入，那种体验并不轻松，甚至有点反人性。
这意味着，AI Coding 的上半场，是让代码可以被生成、被采纳。
AI Coding 的下半场，是让生成结果可以被验证、被修正，并最终进入稳定的工程闭环。
很多团队在落地 AI Coding 时，会先从 Code Review、Diff 解读、风险检查开始。
这个选择并不意外。
因为 Review 是研发流程里天然存在的验证入口。
它面对的不是“AI 会不会写代码”，而是“这次变更是否可以被接受”。
当 AI 开始承担越来越多实现工作后，人的压力并没有消失，而是从“亲手写代码”，转向“判断 AI 写的代码能不能用”。
过去，研发人员写代码的时候，理解、实现、检查往往是交织在一起的。
他一边写，一边判断这段逻辑是否符合需求；
一边改文件，一边确认有没有破坏原有逻辑；
一边调试，一边补齐边界场景。
但 AI 参与之后，这个过程被拆开了。
**AI 负责生成。
**人负责确认。
如果确认这件事仍然主要依赖人逐行看代码、逐段理解 diff、逐个判断风险，那么 AI Coding 带来的效率提升，很容易在 Review、测试和返工阶段被重新消耗掉。
这就是验证问题开始浮出水面的地方。
一、AI 降低了生成成本，也转移了验证压力#
AI Coding 最容易被感知到的变化，是生成速度变快了。
一个过去需要研发人员手写半天的页面逻辑，现在可能几轮对话就能生成主体代码。
一个过去需要来回查找的组件用法，现在 AI 可以根据仓库上下文直接补齐。
一个过去需要手动串起来的状态、接口、页面交互，现在 AI 也能给出一版实现。
这些变化带来了直接价值。
但在真实研发流程里，代码被写出来，只是任务进入了下一步。
它还要被确认。
确认它是否理解了需求，是否改在正确范围内，是否符合团队规范，是否保留了历史逻辑，是否覆盖了关键边界，是否可以进入 Review、提测和发布流程。
这些判断不会因为代码由 AI 生成就自动消失。
相反，当 AI 能一次性生成更多代码、修改更多文件、覆盖更多逻辑时，验证压力会变得更突出。
因为人面对的不再是自己刚刚写下的代码，而是一组由 AI 生成的变更结果。
人需要重新理解它、判断它、确认它。
必要时，还要指出问题，让 AI 再修正。
所以，AI Coding 的一个真实变化是：
生成成本下降之后，验证成本开始显性化。
这也是为什么只讨论“AI 能不能写代码”已经不够了。
下一阶段更关键的问题会变成：
AI 生成的实现结果，如何被确认是可接受的？
二、代码被采纳，不等于需求可验收#
在一些 AI Coding 实践语境里，团队会用“出码率”来衡量 AI 代码的采纳深度。
也就是，一个需求最终提交或进入仓库的代码里，有多少来自 AI。
这个指标有价值。
它能说明 AI 是否真的参与了实现，而不是只停留在建议、补全或对话阶段。
如果 AI 代码最终没有进入提交结果，它更多还是辅助。
如果 AI 代码大量进入提交结果，说明它已经开始承担一部分真实研发工作。
但出码率主要衡量的是“采纳”。它不能替代验证。
因为代码被采纳，只说明它成为了这次实现结果的一部分；而一个需求是否可验收，还要看它是否满足任务目标、业务语义、交互预期、工程规范和回归要求。
比如一个看似简单的列表筛选需求。
AI 可能已经完成了主要代码修改：新增筛选项、补充状态值、调整接口参数、更新列表请求逻辑。
从代码层面看，它已经产生了实现结果。
但进一步看，还会有很多问题需要确认。
这个筛选项是否和已有筛选条件保持一致？状态值是否和后端约定完全对齐？切换筛选条件后，分页和搜索状态是否符合预期？空数据时是否沿用团队统一的空态组件？是否影响了其它筛选条件或历史逻辑？
这些问题决定了这个需求是否可验收。
所以，出码率越高，验证越重要。
不是因为出码率不重要，而是因为当越来越多实现由 AI 完成，团队就越需要一套机制来确认：这些变更是否可接受，哪些问题可以自动发现，哪些风险必须交给人判断。
否则，出码率可能会变成一个孤立数字。
它能说明 AI 写了很多代码，却不能说明这些代码是否可靠、是否可交付、是否适合规模化复用。
三、生成和验证之间，仍然需要任务表达#
在前面的文章里，我一直在讨论一个问题：当 AI 开始承担执行，研发任务不能只停留在需求文档、设计稿、接口文档和自然语言描述里，而需要被整理成更稳定的任务表达，也就是 Task IR。
这篇文章讨论验证，其实是在这个问题上再往前走一步。
任务表达不只是为了让 Agent 执行，也是为了让系统能够判断执行结果是否满足目标。
一个任务如果只停留在原始输入里，Agent 也许可以凭模型能力猜出一部分实现路径。
但系统很难稳定判断它的实现结果是否满足任务目标。
因为系统不知道这个任务的目标是什么、修改范围在哪里、哪些行为必须成立、哪些边界不能破坏、哪些验收条件可以被检查，哪些地方允许 Agent 自主决策，哪些地方必须回到人。
所以，任务建模不只是为了让 Agent 执行。
它还有另一层作用：
任务表达让 Agent 知道要做什么，自动化验证让系统知道它有没有满足任务目标。
这两件事其实是一体两面。
如果没有清晰的任务表达，Agent 执行会发散。
如果没有可检查的验收标准，验证只能依赖人最后看一眼。
如果没有结构化的边界和约束，很多判断就无法从经验判断变成系统能力。
这也是为什么端到端自动化不能被简单理解成：
原始输入 → AI → 代码
无论这些输入是需求文档、设计稿、接口文档，还是仓库上下文，中间都需要一层更稳定的任务表示。
它不只是 Codegen 的输入，也是验证的依据。
过去我们讨论 Task IR、需求理解和任务建模，更多是在回答：
如何让 AI 更稳定地执行任务？
现在进入验证问题后，实际上是在继续回答另一个问题：
如何让系统更稳定地判断任务是否完成？
从这个角度看，验证不是任务表达之后额外加上的一个环节。
它是任务表达能否进入工程闭环的另一面。
四、验证不是最后测试一下#
在传统研发流程里，测试是验证最常见、也最容易被看见的一部分。
但在 AI 研发自动化里，验证不能被简单等同于测试。
测试更多是在回答：
代码运行后，某些用例是否通过？
而验证要回答的是：
这个任务是否已经满足可验收条件？
这两个问题有交集，但不是一回事。
还是拿列表筛选来说。
如果 Agent 完成了代码修改，页面能打开，构建也能通过，这只能说明它没有在工程层面立刻失败。
但这还不够。
我们还要确认：选中筛选项后传参是否正确，列表数据是否真的被过滤，分页和搜索状态是否符合预期，空态和加载态是否沿用原有规范，是否影响了其它筛选条件。
这些问题，有些可以通过自动化测试覆盖，有些需要结合任务语义、页面状态、设计规范和历史实现来判断。
所以，AI 时代的验证，不是在代码生成后补一道测试工序，而是要进入任务执行和结果确认的全过程。
在这篇文章里，我先把它收敛成两类：执行中验证和交付后验证。
五、先看两类验证：执行中验证与交付后验证#
如果先不展开完整分层，端到端自动化里的验证至少可以先看两个位置：一类发生在 Agent 执行过程中，另一类发生在开发结果形成之后。
前者更像过程纠偏，后者更像质量闸口。
5.1 执行中验证：让 Agent 不要沿着错误方向走太远#
执行中验证，发生在 Agent 执行过程中，或者每一轮执行完成之后。
它关注的不是最终交付物是否已经满足发布要求，而是这一轮执行有没有朝着正确方向推进。
比如，Agent 是否理解了任务目标，是否改在了正确范围内，是否引入了无关变更，关键行为是否已经实现，验收标准是否基本满足，是否需要继续反馈给 Agent 修正。
这类验证更靠近任务本身，也更靠近 Agent 的执行过程。
它的作用，是尽早发现偏差，避免 Agent 沿着错误方向走得太远。
如果没有执行中验证，Agent 可能在任务理解偏掉之后继续生成大量代码。
等到最后再 Review，人面对的就不只是一个小问题，而是一整组需要重新理解、重新判断、重新修正的变更。
这也是为什么 AI Coding 的验证不能只放在最后。
**越早发现偏差，越容易修正。
**越晚发现偏差，越容易变成返工。
5.2 交付后验证：让实现结果进入工程质量体系#
交付后验证，发生在一轮开发结果已经形成，准备进入提测、Review 或发布流程时。
这里的“交付后”，不是指发布之后才验证，而是指对已经形成的实现结果，进行工程质量和交付可接受性的检查。
它更接近工程交付体系里的质量保障。
比如，构建是否通过，类型和 lint 是否满足要求，单元测试和覆盖率是否达标，E2E 是否覆盖关键路径，视觉回归是否发现明显偏差，已有功能是否被破坏，是否具备进入提测或发布流程的条件。
执行中验证解决的是：
Agent 这一轮有没有做完、做偏、做错。
交付后验证解决的是：
这次开发结果能不能进入工程体系。
这两类验证的位置不同，作用也不同。
**执行中验证更像是过程纠偏。
**交付后验证更像是质量闸口。
前者减少 Agent 沿着错误方向继续执行的概率。
后者减少问题进入后续研发流程甚至线上环境的概率。
如果说 AI Coding 的上半场，是让 AI 承担更多实现工作，那么下半场就必须解决：
这些实现结果，如何在过程中被纠偏，在交付前被确认。
六、验证闭环的价值，是让错误有去处#
验证不只是发现这次哪里错了。
更重要的是，发现问题之后，错误要有去处。
当验证发现任务没有完成，它应该反馈给 Agent，触发下一轮修正。
当验证发现某类错误反复出现，它应该沉淀为规则、约束或 Skill。
当验证发现输入缺失，它应该反向推动输入检查。
当验证发现 Task IR 表达不完整，它应该补充字段和验收标准。
当验证发现某类需求无法自动判断，它应该沉淀为人工验收点。
当验证发现一个失败样本具有代表性，它应该进入后续的 Benchmark 样本库。
这样，验证就不再是最后“验一下”。
它会成为整条链路持续改进的机制。
这也是端到端自动化和普通 AI Coding 的差别。
普通 AI Coding 可以依赖人的经验不断对话修正。
但端到端自动化要追求的是：
把这些经验、判断和反馈，尽可能沉淀进系统里。
只有这样，下一次遇到类似任务时，链路才有机会变得更稳定。
七、下半场的核心，是建立判断能力#
越往真实研发流程里走，越会发现一个问题：
代码可以由 AI 生成，也可以被团队采纳，但它是否可接受，不能只靠人最后凭经验判断。
什么叫完成？
什么叫可验收？
什么叫符合规范？
什么叫没有破坏已有逻辑？
什么叫可以进入交付流程？
什么情况下需要重新执行？
什么情况下必须交给人判断？
这些问题过去主要由研发人员承担。
现在，如果希望 AI 不只是辅助个人，而是进入研发流程，承担一类可复用、可度量、可规模化的工程任务，这些判断就必须逐步显性化。
这也是验证问题真正重要的地方。
它不是在讨论测试工具多不多，也不是在说要不要补几条 E2E。
它真正讨论的是：
当执行者从人变成 Agent，研发体系如何重新建立判断能力。
如果说 AI Coding 的上半场，是让我们看到代码可以由 AI 生成，并被团队采纳。
那么下半场要证明的是：
AI 生成的实现结果，能否被稳定确认、持续修正，并纳入工程流程。
这一步比生成更难。
因为它要求我们重新整理研发过程里那些过去依赖人脑完成的判断：
需求是否清楚，边界是否明确，上下文是否充分，任务是否被正确表达，执行是否偏离目标，结果是否满足预期，失败是否能够回流，经验是否能够复用。
这些问题连在一起，才构成真正的端到端自动化。
所以，后续看 AI Coding，不能只问：
它生成了多少代码？
还要继续问：
它生成的代码如何被验证？
验证失败后如何修正？
修正经验如何沉淀？
下一次同类任务，链路会不会变得更好？
当这些问题开始被认真回答，AI Coding 才会从工具提效，走向系统提效。
也只有到这个阶段，端到端自动化才不再只是一次成功的 Demo，而会变成一套可以评估、可以复用、可以规模化推进的工程能力。
这篇先回答的是：为什么 AI Coding 走到下一阶段，验证会变得越来越重要。
但验证本身还需要继续拆开。
它不是单一动作，而是一组发生在不同阶段、面向不同对象的检查机制。
下一篇，我会继续展开：在端到端自动化里，验证到底应该如何分层？
从执行中验证，到交付后验证，中间需要哪些检查点，哪些可以自动化，哪些仍然需要人参与判断？