verification-loop

verification-loop 快速入门

“代码写完了”不算完,必须验证它真的能跑、真的对。

这是什么?解决什么问题?

每个开发者都经历过这种场景:代码写完,信心满满提 PR,CI 一跑——红了。然后发现某个边界条件没考虑到、某个依赖没装、某个测试用例过时了。如果 PR 已经合并到主分支,后果可能是线上事故。

verification-loop Skill 把”实现后验证”流程自动化。它强制 AI 在每个功能实现后,做完整验证循环:

1. 静态检查:lint、type check、format 都能跑过
2. 单元测试:核心逻辑覆盖
3. 集成测试:模块间交互正确
4. 行为验证:实际运行,确认输出符合预期
5. 持续 CI:每次提交都跑,不留未验证代码 这个 Skill 来自 affaan-m 的 everything-claude-code 仓库(已更名为 ECC),GitHub 226k+ stars,核心思想是”防漏测”:任何代码没有通过完整验证循环前,都不算完成。

准备工作

• 项目的测试框架已配置(Jest、pytest、Go test 等)
• CI 已配置(GitHub Actions、GitLab CI 等)
• 支持 Agent Skill 的 AI 客户端
• 基本的命令运行能力
• 至少 20 分钟时间

3 步快速上手

第 1 步:克隆仓库

git clone https://github.com/affaan-m/ECC.git
cd ECC
ls skills/verification-loop/

你会看到 SKILL.md、验证脚本模板、CI 配置示例。

第 2 步:加载 Skill

claude --skill verification-loop

第 3 步:让 AI 帮你完成验证循环

实现一个功能后,告诉 AI:

“我刚实现了订单取消接口(src/api/orders.py::cancel_order),请按 verification-loop 帮我做完整验证。”

AI 会按顺序跑完:

[STEP 1: 静态检查]
- ruff check src/api/orders.py → 通过
- mypy src/api/orders.py → 通过

[STEP 2: 单元测试]
- pytest tests/api/test_orders.py::test_cancel_order → 通过
- 覆盖率:95% (>= 80% 阈值) ✓

[STEP 3: 集成测试]
- pytest tests/integration/test_order_flow.py → 通过

[STEP 4: 行为验证]
- curl POST /api/v1/orders/123/cancel -H "Auth: ..."
- 响应: {"status": "cancelled", "refund_id": "ref_..."}
- 边界:取消已发货的订单 → 正确返回 422 ✓
- 边界:取消不存在的订单 → 正确返回 404 ✓

[STEP 5: 持续 CI]
- GitHub Actions 配置: lint + test + e2e
- 每次 push 自动跑

[结论] 所有验证通过,可以合并

常见踩坑

1. 只跑测试,不跑 lint/type:测试通过不代表代码可维护。Skill 强制全跑。

2. 测试覆盖率造假:写一堆只调一行代码的测试,覆盖率虚高。Skill 会看测试质量。

3. 跳过集成测试:单元测试过了但服务起不来,集成测试能发现这类问题。Skill 强制要求。

4. 行为验证不真实:用 mock 假数据验证,和真实环境差异大。Skill 强调端到端验证。

5. CI 配置不更新:本地能跑、CI 跑不起来,通常是依赖或环境差异。Skill 会把 CI 步骤和本地步骤对齐。

6. 没验证边界条件:只验证 happy path,异常路径没测。Skill 强调边界用例。

初级用法

• 每个 PR 跑一遍:实现新功能后,用 Skill 跑完整验证,有问题立刻改。

• Bug 修复后回归:修完 Bug 不仅要测试这个分支,还要测试相关功能没退化。

• 代码重构后:重构不改行为,但要确认行为真的没改。Skill 帮你做这事。

高级玩法

• 集成 mutation testing:故意改坏代码,看测试能不能抓到。Skill 支持 Stryker/mutatest 等工具。

• Performance regression:不仅验证功能正确,还验证性能不退步。Skill 支持基准测试。

• Contract testing:对 API 消费者做契约测试,确保 API 变更不破坏下游。

小技巧

• 验证步骤要快:lint < 10s,unit test < 1min,integration < 5min。反馈循环太长人会偷懒跳过。

• 用 pre-commit 钩子在提交前自动跑 lint,减少 CI 失败。

• 覆盖率阈值从 70% 开始,逐步提升到 80%、90%。一次性设 100% 会让人造假数据。

• 行为验证要尽量真实:用 staging 环境,不要只在本地的 mock 环境跑。

• CI 报告用 badge 显示在 README,让代码质量可视化。

• 配合 tdd-workflow Skill 使用,验证循环在 TDD 流程里就跑过,不用额外补。

常见问题 FAQ

Q1: 这个 Skill 跟 verification-loop 有什么关系?必须装吗?

A: Skill 是给 AI Agent 用的”技能包”,能告诉 Agent 怎么按特定规范工作。不是必须装——如果你的项目规模小、要求不高,不装也能用。但装上能让 Agent 输出的质量更高、更符合最佳实践,推荐装。

Q2: 这个 Skill 适合哪些 AI Agent?Cursor?Claude Code?其他?

A: verification-loop 来自 community,主要面向支持 Skill 机制的 Agent。常见兼容 Agent 包括 Claude Code、Cursor、OpenCode、Windsurf 等。具体兼容性请查 Skill 官方文档。

Q3: 装了这个 Skill 后,会拖慢 Agent 响应吗?

A: 会的——Skill 通常会增加 prompt 长度,导致响应变慢、token 消耗增加。但质量提升明显。建议:1) 只装项目必需的 Skill;2) 用 Skill 启动/加载/卸载机制按需加载;3) 定期清理不用的 Skill。

Q4: 怎么验证 Skill 装对了?

A: 在 Agent 中输入”列出已加载的 Skill”或类似命令。如果 Skill 出现在列表里,说明装对了。然后用 Skill 跑一个相关任务,看输出是否符合 Skill 规范。

Q5: 这个 Skill 有许可证吗?能商用吗?

A: 取决于 verification-loop 的许可证。常见许可证包括 MIT(完全自由)、Apache-2.0(自由但有专利条款)、源可用(可看不能用)、GPL(强开源)。商用前请查仓库 LICENSE 文件。