建立可驗證檢查點 法則

法則四：建立可驗證的檢查點 (Verifiable Checkpoints)

四大黃金法則 (Vibe Coding) 第四條。AI 大量產出的功能必須設計成「reviewer 不讀實作也能信任」。

Erik 原話

我們設計系統有清楚的輸入輸出，並用長時間 stress test 驗證穩定性，這樣即使不讀完所有程式碼，也能確認正確性。

規範要求

每一個 AI 大量產出的功能都必須具備：

1. 明確且人類可讀的輸入／輸出規格

• 介面層級的型別 + 文件
• 副作用顯式宣告（不能藏在實作）

2. 可重現的測試

至少擇二：

• Unit test
• Integration test
• e2e test

依 code 類型而定，詳見 可驗證性設計三支柱 的測試覆蓋表。

3. 針對穩定性的壓力測試或長時間執行測試

• 適用於：非同步、stateful、資源密集型功能
• 譬如：批次處理、scheduler、queue worker、跑 10,000 筆 stress test 之類

驗收標準

即使 reviewer 沒有逐行讀實作，也能透過測試與規格判斷正確性。

如果 reviewer 必須讀實作才能信任，那這個 PR 不符合法則四——要嘛重新設計（補三支柱），要嘛降級成「人類主導 AI 輔助」。

落地：可驗證性設計三支柱

法則四的具體實作是 可驗證性設計三支柱：

1. 介面優先 (Interface-First) — 型別 + 文件 + 副作用宣告
2. 測試覆蓋 — 依程式類型分層
3. 可觀測性 (Observability) — log / metric / trace，失敗能被監控察覺

跟其他法則的關係

法則四是 Vibe Coding 的可信度基礎：

• 法則一給 context（input quality）
• 法則二限制範圍（blast radius）
• 法則三規定 review 強度（who & how deep）
• 法則四讓 review 可信（what to verify）

沒有法則四，法則三的 reviewer 沒有抽象層可以驗證——只能逐行讀。

一個對照例子

功能：批次處理使用者匯出請求

✅ 符合法則四：

• Input：JSON list of user_ids（schema 明確）
• Output：每筆寫入 S3，回傳 manifest.json 含每筆狀態
• Verify：跑 10,000 筆 stress test，比對 manifest 數量 vs S3 物件數量
• Reviewer 不讀實作即可信任

❌ 違反法則四：

• Input：散落多個 global 變數
• Output：直接改 production DB，無紀錄
• Verify：只能祈禱

對 PR / Code Review 的影響

AI 編程 PR 模板 內必有「可驗證性檢查」section，要求作者證明三支柱都到位：

- [ ] 介面層級的型別 + docstring 完備
- [ ] Unit / Integration / e2e 至少 2 種測試覆蓋
- [ ] log / metric / trace 完整
- [ ] (若 async/stateful) Stress test 結果附在 PR

違反時的常見症狀

• ❌ 「測試只 cover happy path」→ 沒覆蓋邊界 / 錯誤路徑
• ❌ 「靠 manual smoke test」→ 不可重現
• ❌ 「production 出錯時沒 metric / log」→ 違反觀測性
• ❌ 「介面 doc 只有 type，沒寫副作用」→ 違反介面優先
• ❌ 「reviewer 必須讀完才能 approve」→ 從根本上違反法則四

相關

• Vibe Coding / 四大黃金法則 (Vibe Coding)
• 可驗證性設計三支柱 — 落地實作
• Be Claude’s PM 法則 — 法則一
• 聚焦 Leaf Nodes 法則 — 法則二
• 核心由人嚴格 Review 法則 — 法則三（配套）
• Vibe Coding TDD 三條 e2e 測試
• AI 編程 PR 模板