---
name: execution-verification-before-completion
description: 完成前验证。铁律：没有新鲜验证证据就不声称完成。防止代理说"应该可以了"。
---

# 完成前验证

## 铁律

```
没有新鲜验证证据就不声称完成。
```

## 规则

1. **运行测试** — 不是"应该通过"，是"确实通过"
2. **检查构建** — 不是"应该能构建"，是"确实构建了"
3. **验证行为** — 不是"逻辑上应该对"，是"实际运行对了"

## 验证清单

完成前必须确认：

- [ ] 所有测试通过（`npm test` / `mvn test`）
- [ ] 构建成功（`npm run build` / `mvn package`）
- [ ] Lint 通过（无新增警告）
- [ ] 手动验证关键路径（如果适用）
- [ ] 没有遗留 TODO 或 FIXME

## 合理化防御表

| 你可能的想法 | 现实 |
|-------------|------|
| "应该可以了" | "应该"不是证据。运行测试。 |
| "改动太小不需要验证" | 小改动也能破坏东西。验证。 |
| "测试太慢了" | 不验证就声称完成更慢（返工）。 |
| "我检查了代码逻辑" | 检查逻辑 ≠ 运行测试。 |
| "这个 edge case 不太可能" | 不太可能的事总会发生。 |
| "集成测试就够了" | 集成测试慢且定位困难。两者都需要。 |
| "我先发布再修复" | 修复线上 bug 的成本是开发阶段的 100 倍。 |
| "其他人都验证过了" | 责任在你。自己验证。 |
| "这个模块不重要" | 每个模块对用户都很重要。 |
| "性能问题以后再说" | 性能问题会滚雪球。早处理。 |
| "文档可以后面补" | 后面 = 永远不。现在写。 |

## 红旗

这些想法意味着 STOP — 你正在合理化：

1. **"我觉得应该没问题"** → STOP。验证它。
2. **"这个改动很明显是对的"** → 明显的改动也经常有 bug。验证。
3. **"测试都通过了"** → 测试通过 ≠ 行为正确。检查测试覆盖。
4. **"我手动测试过了"** → 手动测试不可复现。自动化它。
5. **"这个功能很简单"** → 简单功能也会有复杂 bug。
6. **"用户不会这样用"** → 用户总会做你意想不到的事。
7. **"这个错误不重要"** | 错误就是错误。没有"不重要"的错误。
8. **"我先标记为已知问题"** | 已知问题也会让用户流失。
9. **"这个只在特定环境出现"** | 特定环境也是真实环境。
10. **"我昨天测试过了"** | 昨天 ≠ 今天。代码变了。重新测试。
11. **"这个 warning 可以忽略"** | warning 是未来的 bug。现在修复。

## 压力测试

在声称完成前，问自己：

1. 如果输入是空的怎么办？
2. 如果输入是 null/undefined 怎么办？
3. 如果并发 1000 个请求怎么办？
4. 如果网络断了怎么办？
5. 如果磁盘满了怎么办？
6. 如果数据库连接超时怎么办？
7. 如果用户输入包含特殊字符怎么办？
8. 如果配置缺失怎么办？
9. 如果依赖服务不可用怎么办？
10. 如果内存不足怎么办？