AI Coding 的上半场是生成，下半场是验证｜AI 代码被采纳，不代表需求可验收

Info 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。详见：为什么 Spec 不是终点，而只是中间产物？软件研发正在从 Spec 驱动，走向表示驱动（RDD）

这篇文章讨论验证，其实是在这个问题上再往前走一步。

任务表达不只是为了让 Agent 执行，也是为了让系统能够判断执行结果是否满足目标。

一个任务如果只停留在原始输入里，Agent 也许可以凭模型能力猜出一部分实现路径。 但系统很难稳定判断它的实现结果是否满足任务目标。

因为系统不知道这个任务的目标是什么、修改范围在哪里、哪些行为必须成立、哪些边界不能破坏、哪些验收条件可以被检查，哪些地方允许 Agent 自主决策，哪些地方必须回到人。

所以，任务建模不只是为了让 Agent 执行。 它还有另一层作用： 任务表达让 Agent 知道要做什么，自动化验证让系统知道它有没有满足任务目标。

这两件事其实是一体两面。

如果没有清晰的任务表达，Agent 执行会发散。 如果没有可检查的验收标准，验证只能依赖人最后看一眼。 如果没有结构化的边界和约束，很多判断就无法从经验判断变成系统能力。

这也是为什么端到端自动化不能被简单理解成： 原始输入 → AI → 代码 无论这些输入是需求文档、设计稿、接口文档，还是仓库上下文，中间都需要一层更稳定的任务表示。

它不只是 Codegen 的输入，也是验证的依据。

过去我们讨论 Task IR、需求理解和任务建模，更多是在回答： 如何让 AI 更稳定地执行任务？

现在进入验证问题后，实际上是在继续回答另一个问题： 如何让系统更稳定地判断任务是否完成？

从这个角度看，验证不是任务表达之后额外加上的一个环节。

它是任务表达能否进入工程闭环的另一面。

四、验证不是最后测试一下

在传统研发流程里，测试是验证最常见、也最容易被看见的一部分。

但在 AI 研发自动化里，验证不能被简单等同于测试。

测试更多是在回答： 代码运行后，某些用例是否通过？

而验证要回答的是： 这个任务是否已经满足可验收条件？

这两个问题有交集，但不是一回事。

还是拿列表筛选来说。 如果 Agent 完成了代码修改，页面能打开，构建也能通过，这只能说明它没有在工程层面立刻失败。

但这还不够。

我们还要确认：选中筛选项后传参是否正确，列表数据是否真的被过滤，分页和搜索状态是否符合预期，空态和加载态是否沿用原有规范，是否影响了其它筛选条件。

这些问题，有些可以通过自动化测试覆盖，有些需要结合任务语义、页面状态、设计规范和历史实现来判断。

所以，AI 时代的验证，不是在代码生成后补一道测试工序，而是要进入任务执行和结果确认的全过程。

在这篇文章里，我先把它收敛成两类：执行中验证和交付后验证。

图 1：AI Coding 从生成走向验证

图 1：AI Coding 从生成走向验证

五、先看两类验证：执行中验证与交付后验证

如果先不展开完整分层，端到端自动化里的验证至少可以先看两个位置：一类发生在 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 走到下一阶段，验证会变得越来越重要。

但验证本身还需要继续拆开。

它不是单一动作，而是一组发生在不同阶段、面向不同对象的检查机制。

下一篇，我会继续展开：在端到端自动化里，验证到底应该如何分层？ 从执行中验证，到交付后验证，中间需要哪些检查点，哪些可以自动化，哪些仍然需要人参与判断？