verify

name	verify
description	当用户要验证、确认完成、收尾、检查是否做完，或 implement 实现完成后使用。对照 spec 的 DoD 逐条验证，运行测试，端到端跑通。高回报。关键词：验证、确认完成、收尾、verify、测一下、跑通、做完了吗。

verify — 完成前验证（做对了吗）

触发词

验证、确认完成、收尾、verify、测一下、跑通、做完了吗、检查、验收

概述

在声明"做完了"之前，对照 spec.md 的完成标准（DoD）逐条验证，跑测试，端到端走一遍。这是 Anthropic 实测对 agent 输出质量提升最明显的一类 skill——会自己验收的 agent 和只会交作业的 agent，是两个物种。

何时该用

• implement 完成后，声明"做完了"之前
• 用户问"做完了吗""能用了吗"
• 任何节点要确认某功能是否真的可用

工作流

1. 读 spec.md 的 DoD

把 spec.md 里每个功能的"完成标准（DoD）"列出来。这是验收清单。

若无 spec（小修小补），基于用户最初的需求提炼出可验证的检查点。

2. 逐条验证 DoD

对每条 DoD：

• 明确怎么验：跑哪个测试 / 执行什么命令 / 手动操作什么
• 实际执行：不要"我觉得应该没问题"，要真跑
• 记录结果：通过 / 失败 / 未覆盖

没有验证手段的 DoD = 无法确认完成。先补一个能跑的检查（哪怕一个 assert）。

3. 运行测试

• 跑项目已有测试套件
• 若 implement 产生了新逻辑但没测试，补一个最小的可运行检查（见 coding_principles "留一个可运行的检查"）
• 用 scripts/smoke_test.template 快速搭冒烟测试

4. 端到端走核心流程

不只是单元测试通过，还要把用户视角的核心流程完整走一遍：

• 从入口开始，按真实使用路径操作
• 每一步断言状态符合预期
• 失败的步骤记录下来

例：登录功能——不只测"密码校验函数返回 true"，要真跑"输入账号密码 → 点登录 → 成功跳首页 / 失败显提示"。

5. 产出验证报告

在 .agents/specs/{feature}/verification.md 写入：

# 验证报告

## DoD 逐条验证
| DoD | 验证方式 | 结果 |
|-----|---------|------|
| 用户可用账号密码登录 | 跑 test_login.py | ✅ 通过 |
| 登录失败有提示 | 手动输入错密码 | ✅ 通过 |
| 成功跳首页 | 端到端走一遍 | ❌ 失败：跳转目标写错 |

## 测试结果
- 单元测试：N 通过 / M 失败
- 冒烟测试：通过 / 失败

## 端到端核心流程
1. [步骤1] → ✅
2. [步骤2] → ❌ {问题描述}

## 未通过项
- {问题} → 需修复

## 结论
- [ ] 全部通过，可声明完成
- [x] 有未通过项，需修复后重验

6. 报告给用户

• 全通过：明确说"已验证完成"，列出验证了什么。
• 有失败：列出失败项，问用户是修复还是记为已知问题。

坑点清单（Gotchas）

• "我觉得应该没问题"：没真跑就说通过 = 假验收。每条 DoD 都要实际执行验证。
• 只跑单元测试不跑端到端：单元测试通过不代表用户流程能走通。
• DoD 不可验证：spec 写"支持登录"没法验，要"输入账号密码→成功跳首页→失败显提示"才可验。
• 新逻辑没测试：implement 写了新代码但没留检查，verify 时无法确认。
• 不产出报告：只在对话说"测了没问题"，没存 verification.md，无法追溯。
• 声明完成却留未通过项：失败项要么修要么明确标"已知问题"，不能藏起来。

关键规则

• 必须对照 spec 的 DoD 逐条验证，每条都要实际执行。
• 必须跑测试 + 端到端走核心流程。
• 必须产出 verification.md 存档。
• 未通过项必须修复或明确标注，不得隐藏。
• 声明"完成"前必须本 skill 通过。

脚本

• scripts/smoke_test.template — 通用冒烟测试模板（复制后按项目改）

参考

• .agents/rules/coding_principles.md 第四章 Goal-Driven Execution
• 上游 skill：implement（实现）
• 相关 skill：diagnosing-bugs（验证失败时排查复杂 bug）；简单 bug 走 anti-hallucination Step 5 轻量 log