AI生成代码验证实操：从任务定义到可复现证据的闭环流程

当一个 Coding Agent 向我提交补丁时，我不会一开始就拿另一个模型去判断这个 diff 看起来是否合理。这种做法或许能帮我发现风险，但无法证明所请求的行为确实有效。

验证需要从任务出发，以可复现的证据作为终点。

冻结任务与版本

我将请求的预期结果、运行前的仓库版本、以及确切的 Agent 变更记录下来。如果任务本身存在歧义，我会让这种歧义保持可见，而不是默默选择最易实现的解释。

这让后续的每一次检查都有了身份标识。没有这一步，一个绿色的测试结果可能确有其事，却仍然属于错误的版本或需求。

找到行为边界

有价值的问题是：用户或调用者能观察到什么？这可能是浏览器跳转、API 响应、授权拒绝、持久化的记录，或者是必须保持修复的回归问题。

我倾向于围绕这个边界来写检查。只重复实现逻辑的测试有可能通过，但产品行为依然是错的。

运行最小且有权威性的检查

优先使用仓库自有的命令和测试。如果现有测试套件没有覆盖到变更的行为，我会添加一条针对性的浏览器或 API 检查。

证据应当包含命令、环境、退出状态和有边界的输出。没有上下文的通过命令是薄弱的证据。一堆无关的检查也不会自动变得更有说服力。

区分不同类型的失败

Agent 引入的回归、仓库已有的失败、环境问题、超时、以及未经验证的需求，是不同性质的结果。将它们一律标红会掩盖接下来真正需要做什么。

这种区分也防止了不稳定的基础设施导致对产品的错误判定。

我希望审阅者能够无需重建整个运行过程就回答出五个问题：

• 检查的是哪个任务？
• 检查的是哪个版本和变更？
• 运行了哪些命令或路径？
• 哪部分失败了，哪些仍未知？
• 最终判定为何由这些证据得出？

一份机器可读的证据包让这些答案可以流转，而不是散落在终端输出和聊天记录里。

修复后重新检查

变更后的 diff 不是终点。我会重新运行失败的检查以及最小相关的回归集，同时保留先前的失败记录和后续的通过记录。这展示了从问题到证明的完整路径。

这种从任务到证据的工作流正是 CodeVetter 背后的方法。完整的检查清单及其局限性见 https://codevetter.com/verify-ai-generated-code。