完成前驗證

概述

在沒有驗證的情況下聲稱工作完成是不誠實，不是效率。

核心原則： 始終證據優先於聲明。

違反這個規則的字面意思就是違反這個規則的精神。

鐵律

code

沒有新鮮驗證證據就沒有完成聲明

如果你在這條訊息中沒有執行驗證命令，你不能聲稱它通過。

閘門函數

code

在聲稱任何狀態或表達滿意之前：

1. 識別：什麼命令證明這個聲明？
2. 執行：執行完整命令（新鮮、完整）
3. 閱讀：完整輸出，檢查退出碼，計數失敗
4. 驗證：輸出是否確認聲明？
   - 如果否：說明帶有證據的實際狀態
   - 如果是：說明帶有證據的聲明
5. 只有然後：做出聲明

跳過任何步驟 = 說謊，不是驗證

常見失敗

聲明	需要	不足夠
測試通過	測試命令輸出：0 失敗	之前的執行，"應該通過"
Linter 乾淨	Linter 輸出：0 錯誤	部分檢查，推斷
建置成功	建置命令：退出 0	Linter 通過，日誌看起來不錯
錯誤已修復	測試原始症狀：通過	程式碼已變更，假設已修復
迴歸測試有效	紅-綠循環已驗證	測試通過一次
代理完成	VCS diff 顯示變更	代理報告"成功"
需求已滿足	逐行清單	測試通過

危險信號 - 停止

•使用"應該"、"可能"、"似乎"
•在驗證前表達滿意（"太好了！"、"完美！"、"完成！" 等）
•即將在沒有驗證的情況下提交/推送/PR
•信任代理成功報告
•依賴部分驗證
•想著"只這一次"
•疲倦且想結束工作
•任何暗示成功而沒有執行驗證的措辭

合理化預防

藉口	現實
"現在應該有效"	執行驗證
"我很有信心"	信心 ≠ 證據
"只這一次"	沒有例外。
"Linter 通過了"	Linter ≠ 編譯器
"代理說成功"	獨立驗證
"我累了"	疲倦 ≠ 藉口
"部分檢查就夠了"	部分什麼都不證明
"不同的措辭所以規則不適用"	精神優先於字面

關鍵模式

測試：

code

✅ [執行測試命令] [看到：34/34 通過] "所有測試通過"
❌ "現在應該通過" / "看起來正確"

迴歸測試（TDD 紅-綠）：

code

✅ 寫 → 執行（通過）→ 還原修復 → 執行（必須失敗）→ 恢復 → 執行（通過）
❌ "我已經寫了迴歸測試"（沒有紅-綠驗證）

建置：

code

✅ [執行建置] [看到：退出 0] "建置通過"
❌ "Linter 通過了"（linter 不檢查編譯）

需求：

code

✅ 重新閱讀計劃 → 建立清單 → 驗證每項 → 報告缺口或完成
❌ "測試通過，階段完成"

代理委派：

code

✅ 代理報告成功 → 檢查 VCS diff → 驗證變更 → 報告實際狀態
❌ 信任代理報告

為什麼這很重要

來自 24 個失敗記憶：

•你的人類夥伴說"我不相信你" - 信任破壞
•未定義的函數被發佈 - 會崩潰
•缺少的需求被發佈 - 不完整的功能
•時間浪費在假完成 → 重定向 → 返工
•違反："誠實是核心價值。如果你說謊，你會被取代。"

何時應用

始終在之前：

•任何變體的成功/完成聲明
•任何滿意表達
•任何關於工作狀態的正面陳述
•提交、PR 建立、任務完成
•移動到下一個任務
•委派給代理

規則適用於：

•確切的短語
•釋義和同義詞
•成功的暗示
•任何暗示完成/正確性的溝通

底線

驗證沒有捷徑。

執行命令。閱讀輸出。然後聲明結果。

這是不可協商的。