name: 验证 description: “在声称完成前进行验证。在说工作完成、测试通过或构建成功之前使用。”
在声称结果之前运行相关的验证命令。
何时使用
- 在说“测试通过”、“构建成功”或“bug已修复”之前
- 在报告任何具有可测试结果的任务完成之前
- 当用户问“它工作吗？”或“完成了吗？”时
- 修复失败的测试或构建错误之后
何时不使用
- 对于仅涉及文档更改且无可测试结果的情况
- 当用户明确说“相信我，跳过验证”时
- 对于没有通过/失败标准的探索性工作
使用示例
/verify
/verify (在声称重构完成之前)
工作流程
- 识别 什么命令能证明你的声称
- 仔细思考 通过的结果是什么样子——以及假阳性会是什么样子——然后再运行
- 运行 命令（全新运行，不是之前的结果）
- 阅读 完整输出；检查退出代码，统计失败次数
- 报告 带有证据的实际结果
切勿重用之前运行的输出。始终全新运行。
声称到证据映射表
| 声称 | 所需证据 |
|---|---|
| 测试通过 | 测试命令输出显示 0 个失败 |
| 代码检查干净 | golangci-lint run 输出显示 0 个错误 |
| 构建成功 | go build 退出代码为 0（仅代码检查通过是不够的） |
| Bug 已修复 | 原始症状不再复现 |
| 回归测试通过 | 红绿循环：没有修复时测试失败，修复后测试通过 |
| 所有检查通过 | make audit 输出显示所有步骤都通过 |
| 文件匹配 | diff 显示无差异（例如，模板文件与实时文件） |
将模糊任务转化为可验证的目标
开始之前，将任务重写为可测试的结果：
| 给定的任务 | 可验证的目标 |
|---|---|
| “添加验证” | 为无效输入编写测试，然后让它们通过 |
| “修复这个 bug” | 编写一个能复现它的测试，然后让它通过 |
| “重构 X” | 确保重构前后测试都通过 |
| “提高性能” | 测量 -> 更改 -> 测量 -> 比较 |
对于多步骤工作，将每个步骤与其检查配对：
1. [步骤] -> 验证: [检查]
2. [步骤] -> 验证: [检查]
强有力的成功标准让你可以独立循环。 弱标准（“让它工作”）需要不断澄清。
示例
好的
- 运行
make audit：“所有检查通过（格式、vet、lint、测试）” - 运行
go test ./...：“34/34 个测试通过” - 运行
diff live.md template.md：“无差异” - 运行
go build -o /dev/null ./cmd/ctx：“退出代码 0”
不好的
- “现在应该通过了”（没有运行任何东西）
- “看起来正确”（目视检查不是验证）
- “测试之前通过了”（过时的结果；代码后来改变了）
- “构建有效”（你真的运行了吗？）
与 /qa 的关系
/qa 告诉你要运行什么。/verify 提醒你在声称结果之前实际运行它。
质量检查清单
在声称已验证之前：
- [ ] 验证命令是全新运行的（未重用）
- [ ] 检查了退出代码（不仅仅是扫描输出）
- [ ] 声称与证据匹配（构建退出代码 0 不能证明测试通过）
- [ ] 如果有多个声称，每个都有其自己的证据