| name | bm.verification |
| description | 完成前自验证：声明 done 之前必须列检查清单、跑一遍、看结果。Use before claiming a task is complete, finished, ready, done, 完成, 搞定, 做完, 跑通, ready, done, finish, complete. 防止虚假完成、自欺欺人、提交破损产物。 |
| source | opencrew |
| version | 20260521.01 |
Skill: Verification（完成前自验证）
声明"完成"之前，agent 必须自己跑一遍验证，列证据，不是嘴上说"我做完了"。
适用于代码、文档、设计、报告、配置——任何要交付的产物。
触发时机
强制触发：当 agent 准备说以下任何话之前——
- "我已经完成了 X"
- "X 修好了"
- "可以了，你试试"
- "搞定，已经写入 Y"
- "需求都实现了"
- "Done"
不触发：
- 用户明确说"先这样吧，我自己看"
- 中间产物，未声明完成
三步法
Step 1：列检查清单
根据这次任务的目标，列出可验证的检查项。每条必须是：
- 客观：能用证据回答 yes/no，不是主观判断
- 具体：不是"功能正常"，是"运行 X 命令返回 0"
- 可执行：你（agent）当场就能验证
清单举例：
写代码：
写文档：
修 bug：
配置/安装：
Step 2：实际跑一遍
真的执行，不是想象。常用动作：
| 产物类型 | 验证动作 |
|---|
| 代码 | 跑测试 / lint / typecheck / 实际调用一次 |
| 脚本 | 在 sample 输入上跑一次 |
| 文档 | 通读一次，检查链接和事实 |
| 配置 | 让目标程序加载这个配置 |
| 数据/报告 | 抽样检查若干条目 |
记录每个检查项的实际证据：
- 命令的 exit code 和输出片段
- 文件实际内容片段
- 截图 / 日志关键行
Step 3：呈现验证报告
呈现给用户的格式：
## 完成报告
**做了什么**：一句话说做了啥。
**验证结果**：
- ✅ 文件写入 ./output/report.md（138 行）
- ✅ Markdown lint 通过（0 errors）
- ✅ 所有链接可访问（5/5）
- ⚠️ 一处 [需确认]：原始资料里 X 项数据缺失，已标注
**证据**：
\```
$ wc -l output/report.md
138 output/report.md
$ markdownlint output/report.md
（无输出，通过）
\```
**未覆盖**：
- 没做 Y，因为超出范围
**下一步建议**：
- 你可能想检查一下 ⚠️ 那条
反模式（绝对不要这样）
| 反模式 | 为什么错 | 正确做法 |
|---|
| "应该可以了" / "理论上没问题" | 没真跑过 | 必须跑 |
| 跑了一次没报错就认为 OK | 没看输出，可能是 silent failure | 看实际输出对照预期 |
| 自己觉得对就报完成 | 主观，不可信 | 给客观证据 |
| 验证时降低标准 | 自欺 | 验证标准 = 任务标准 |
| 报告"全部完成"但有项跳过 | 误导用户 | 跳过的项明确标注，给原因 |
| 失败的项藏起来 | 用户后面发现更糟 | 失败项用 ❌ 明确报告，给修复建议 |
边界情况
验证失败时：
- 不要硬报"完成"
- 报告"部分完成"或"未完成"，列出失败项和你的判断（继续修 / 需要用户决策）
无法验证时（比如需要外部环境）：
- 明确说"我无法本地验证 X，因为 Y"
- 给用户简单的验证步骤："请你跑一下
Z，看输出是不是 ..."
验证成本太高时（比如要部署到生产）：
- 退一步：在 staging / 本地复现一个等价场景验证
- 不能验证的部分明确标记
与其他 skill 的协作
文件落点
验证证据/日志 → ./working/verification-{task}.log，必要时附在报告里。
