AI Agent 做完不等于做对:如何建立验证闭环?

假设你让 AI 给网站增加注册功能。

十分钟后，它告诉你：“已经完成，代码可以正常运行。”

页面确实能打开，按钮也能点击。但你输入邮箱后，验证邮件始终没有收到。

AI 检查了代码有没有报错，却没有真的走完一次用户注册。

很多人遇到这种情况，会再补一句：

“请认真检查一遍。”

AI 重新阅读自己的结果，换一种说法告诉你一切正常。它获得了更多检查要求，却仍然没有获得新的反馈信号。

这就是“只重读结果”和“实际运行检查、根据失败继续修正”的区别。

2026 年 7 月 22 日，Claude Code 团队成员 Delba de Oliveira 介绍了一种方法：把人工检查变成 Agent 能执行、失败后修正并重新检查的循环。

读完本文，你会知道怎样让能连续工作的 AI Agent 检查结果，而非只重读答案；文末还有一份“完成前验证”模板。

原文讨论的是 Agent 编码任务。它通常沿着三个环节循环：

如果验证未通过，Agent 就回到前面补充上下文并继续修正。

原文把这种重复过程称为 verification loop，也就是“验证闭环”。它仍然属于 Agent 检查自己的工作；关键在于实际运行测试、代码规范检查或自定义检查，并根据失败项继续修改。

常见检查结果包括类型检查、代码规范工具、测试和运行错误。

检查失败不是终点，而是下一轮修正的输入

回到注册功能的例子。

“代码已经写完”只是动作完成；“启动网站、提交注册、收到验证邮件，并确认账号状态正确”才接近结果验证。

如果邮件没有到达，Agent 得到的不是一句模糊的“再看看”，而是一个可以继续调查的失败信号。

这里做一个原文之外的补充：验证信号也有强弱。

代码能够编译，不代表功能符合需求；文档没有错别字，不代表论据可靠；表格公式能运行，也不代表引用的数据正确。

信号越接近真实目标，通常越有用。

原文列举了 Claude Code 中已有的六类验证方式：

• `/verify` Skill：构建、运行并观察应用改动；

• 工具链：读取代码规范工具等返回的错误和警告；

• Code Review（研究预览版）：自动审查代码合并请求；

• GitHub Actions：在推送代码或提交合并请求时调用验证 Skill；

• Spec validation：对照书面规格检查并尝试修复违规；

• Claude Managed Agents 的评分规则（测试版）：由另一个评分 Agent 检查，失败后自动返工。

如果你不写代码，只需记住：检查可以来自运行结果、工具报错、书面标准，也可以来自另一个负责评分的 Agent。

这里补充一条原文没有展开的边界：这些检查并不保证结果绝对正确，但会产生可观察的通过或失败结果，供 Agent 继续修正。

信号越接近真实目标，通常越有价值

把这个思路推广到非代码任务，是我根据原文做的延伸。原文主要讨论 Claude Code，并没有证明所有知识工作都能像软件测试一样自动验证。可以尝试追问：

• 数据分析是否重新计算了关键数字？

• 报告中的结论能否回到原始来源？

• 合同摘要是否逐条覆盖指定风险？

• 对外邮件是否满足长度、语气和禁止承诺的要求？

作为本文的判断标准，我更看重可观察的检查结果，而不是 Agent 对自己表现的主观评价。这里的“可观察”不一定来自另一个系统，也可以是当前 Agent 实际运行测试或读取错误后得到的结果。

验证闭环不一定从复杂系统开始。

原文建议先观察一件事：过去一周，你最常在 AI 完成后手动纠正什么？

也许你总要提醒它运行测试，总要检查日志里不能出现用户数据，或者总要确认数据库迁移删除字段前是否安排了数据回填。

这些反复出现的动作，就是最适合被写下来的检查程序。

写法不需要很“像代码”，可以像给新同事交代工作一样。结合原文示例，我把它归纳为下面五项；其中“何时停止并交给人”是本文补充的控制条件：

• 什么情况下执行检查；

• 要看哪些证据；

• 哪些结果算失败；

• 失败后应该怎样修正；

• 什么情况必须停止并交给人。

在 Claude Code 中，可以把这些步骤写成 Skill（可复用的任务说明文件）。之后遇到匹配任务，Agent 就能按同一套步骤执行，不必等人临时提醒。

真正重要的不是文件是否叫 Skill，而是把“我通常会检查”变成“每次完成后都执行”的流程。

规则写好后，还要决定何时启动。原文给出从手动检查走向流程自动检查的四种位置。

结果产出后，由人主动调用检查。适合并非每次改动都需要的项目；缺点是人仍可能忘记。

检查自动成为某个工作流的一部分。例如生成组件后，自动运行代码规范检查并修复错误。它只适合你能编辑的 Skill；内置或插件管理的 Skill 不应直接修改。

一个 Skill 结束后自动调用下一个。原文称，Claude Code 团队成员日常会串联代码审查、修改简化和功能验证；若涉及界面，再对照设计规范检查。

当个人验证链稳定后，可让同一套流程检查每个合并请求。无论作者是否记得手动执行，团队改动都经过相同门槛。

先手动跑稳，再逐步放进自动流程

根据原文的取舍，我把选择原则概括为：越稳定、越高频、失败代价越高的检查，越值得自动触发；仍频繁变化的检查，先保留人工启动。其中，“失败代价越高”是本文补充的判断维度。

原文明确提到，串联会牺牲灵活性并增加模型调用成本，所以应先测试稳定，再推广到整个团队。

下面这份模板是我根据原文原则整理的延伸，并非 Anthropic 原文提供的提示词。

完成【任务】后，不要直接宣布完成。先执行以下验证：

在注册功能场景中，验收标准不能只写“代码没有报错”，而应该包括：页面可打开、表单可提交、邮件能收到、链接能完成验证、重复注册得到正确提示。

这份模板只负责建立反馈流程。真正的验收标准仍然需要懂业务的人定义。

下面几点不是原文列出的限制，而是我基于实践补充的判断。

测试若漏掉关键场景，Agent 可能反复得到“全部通过”；测试环境、数据源、评分 Agent 和脚本本身也需要维护。

文章是否有洞察、设计是否让人信任、对外表述是否合适，通常仍需要读者、用户或领域专家判断。

没有重试上限、成本限制和人工升级规则的 Agent，可能在同一个失败上不断消耗时间与资源。

所以，验证闭环不是取消人的判断，而是让人把注意力放在设计标准、处理例外和作出高风险决定上。

当 Agent 会修改文件、运行代码和调用工具时，可靠交付不能只靠一句“完成了”。更稳妥的做法是：事先写明验收标准，让它执行检查、读取失败，并在限定次数内修正。