跳转至

验证闭环

Vibe Coding 的质量来自验证,而不是来自模型的自信。

AI 生成的代码看起来正确,并不代表它真的正确。验证闭环是每次 AI 完成任务后的标准检查流程,确保结果真正可交付。

为什么必须验证

AI 模型有几个典型的失败模式:

  • 过度自信:给出错误的实现,但解释得头头是道
  • 范围蔓延:顺手修改了规格之外的代码
  • 测试幻觉:声称测试通过,但实际上没有运行
  • 局部正确:改动在当前上下文正确,但破坏了其他模块

验证闭环的作用是:用客观结果替代主观判断

推荐验证顺序

1. 目标测试  →  确认新功能工作
2. 回归测试  →  确认没有破坏已有功能
3. 静态检查  →  确认代码质量
4. 手动验收  →  确认真实场景可用

第一步:目标测试

运行与本次改动直接相关的测试:

# 只跑改动涉及的模块
pnpm test src/auth/
pytest tests/test_auth.py
go test ./auth/...

目标测试失败时,不要继续下一步。先让 AI 修复,再继续。

第二步:回归测试

运行相邻模块的测试,确认没有意外破坏:

# 全量测试或相关模块测试
pnpm test
pytest --tb=short
cargo test

第三步:静态检查

# TypeScript
npx tsc --noEmit
pnpm lint

# Python
mypy src/
ruff check .

# 构建验证
pnpm build

第四步:手动验收

走一遍关键路径,确认在真实环境中工作:

  • 打开浏览器,操作目标功能
  • 检查控制台是否有错误
  • 验证边界情况(空值、错误状态)

验证记录

每次任务完成后,记录三件事:

运行了什么:pnpm test auth && pnpm build
结果:测试 12/12 通过,构建成功
残余风险:OAuth 回调 URL 仅在本地验证,生产环境需要配置

这个记录直接写进 PR 描述或复盘文档,让团队协作更可靠。

快速验证 vs 完整验证

场景 验证级别
单文件小改动 目标测试 + 类型检查
新功能开发 全部四步
重构 回归测试 + 手动验收
安全相关改动 全部四步 + 人工代码审查

不要跳过验证

AI 说"应该没问题"不算验证。只有命令行输出"0 errors"才算验证。

验证失败时的处理

验证失败不是坏事,这正是验证闭环存在的价值。

  1. 把失败信息完整贴给 AI:不要只说"出错了",要贴完整的错误输出
  2. 确认修复范围:AI 修复时可能引入新问题,修复后重新从第一步开始
  3. 两次失败换思路:同一问题失败两次,说明当前方向有问题,需要重新分析根因