没测试的代码就是猜测。
任何游戏发布前，我们跑 自动化游戏过场 — 机器人玩游戏，对照第 3 步的计划检查结果。
任何一个测试失败，就不发。先修。
机器人在做什么
期望：球反弹 实际：球穿过
✗ 1 个测试失败 → 部署阻止 先修规格，再试。
/测试
机器人玩游戏。
真点击。真物理。真分数。没有人在看。
每个测试映射到计划中一条规则。规则 #6 失败 = 我们立刻知道哪行坏了、哪个程序员写的。
为什么不让 AI 给自己打分
整个流程最重要的规则。
AI 帮忙写了代码。然后 另一个系统 跑测试。AI 从不决定"测试通过了"。计算机比对实际输出和期望输出。纯数字。
# 机器人完美点 5 次。 # 从屏幕读连击数。
实际连击：5 期望： 5
✓ 匹配 → 通过
# 如果是 4： 实际连击：4 期望： 5
✗ 不匹配 → 失败 不允许"看上去对"。
/无感觉
数字不会撒谎。
检查不是"看上去对" — 是"5 等于 5"。数字不匹配，测试就失败。
这就是为什么我们的游戏不会带着 vibe-coded 应用那种 bug 上线。
每条规则测什么
计划中每条规则至少 2 个测试。"快乐路径"（能用）和"反向路径"（正确失败）。
快乐： 正好顶点点 → 连击 +1 期望：连击 == 1
反向： 顶点 200ms 后点 → 连击 == 0 期望：连击 == 0
边界： 正好 +100ms 边界点 期望：连击 +1（仍在窗口内）
+101ms 边界点 期望：连击 == 0（刚出去）
# 1 条规则 4 个测试。 # Bug 藏在边界情况。
/覆盖
快乐 + 反向 + 边界。
大多数 bug 不是"代码错了" — 是"忘了边界情况"。测试边界（±100ms vs ±101ms）能抓真正的问题。
BOP 的 23 条规则总共约 70 个自动化测试。Tester 90 秒跑完。
常见陷阱
✗ 让 AI 给自己打分（vibe scoring）
✗ 跳过性能测试，"我的 Mac 上很快"
✗ 只测快乐路径
✗ 关掉失败测试而不是修
✗ 把 flaky 测试当"偶尔" — 它们是真 bug
纪律是：测试失败就是真失败。无例外。关掉测试 = 直奔 bug 满天的生产。
你能照搬的
发布任何代码相关：
- 先写规则（第 3 步）。然后写对应规则的测试。
- 不让 AI 自评。 用独立的测试 runner。
- 失败阻止部署。 没"之后再修"。
- 每条规则测快乐 + 反向 + 边界。
- 性能测试用最慢的硬件目标。
第一周会发布得慢。之后，发布无 bug。