verification-disciplinelisted

# 驗證紀律(Verification Discipline) ## 什麼時候用 任何時候你要說「這個對了 / 通過了 / 沒問題」。驗證的敵人不是「明顯的錯」,是**看起來對的錯**—— 自己驗自己、只驗做過的沒驗漏掉的、單一維度過了就宣稱全對。這技能講怎麼讓「對」是**證明出來的**, 不是**宣稱出來的**。 --- ## 通用法則 ### 法則 1:期望值必來自獨立來源(絕不用被驗者自己算的值) 驗證 = 拿產物的輸出跟**一個獨立的正確答案**比。那個答案**不能是被驗的東西自己產生的**—— 否則就是「自己跟自己比」,永遠相等,證明了個寂寞(套套邏輯)。 - 正確答案的來源:權威發布的範例、人手算、另一個獨立實作、產物注入前就存在的原始基準。 - ✗ 用引擎算一次當「標準答案」,再用同一引擎算一次去對 → 假交叉。 - 若「正確答案」也要靠不可信的第二方,要求**兩方真獨立**(不同來源、沒互相抄)。 ### 法則 2:不信自報的「我驗過了」 「我確認過沒問題」不是證據,**輸出才是證據**。宣稱通過前,實際跑驗證命令、貼出關鍵結果。 - 代理/工具說「real=0 / 全綠」→ 不照單全收,看它憑什麼這樣說(是真比對出來的,還是它自己講的)。 - 尤其是「一個環節自己給自己打分」的設計 → 預設不信,要有外部客觀關卡兜底。 ### 法則 2.5:驗證對象=系統出口,不是中間物;報「系統對」不報「碼對」 「對」只有一種合法定義:**真入口進 → 系統完整跑 → 拿到使用者真正到手的那份出口物 → 對獨立基準零缺陷**。 - **pytest 綠 / 單元測綠 / 內部模組綠 / 中間檔(canonical/暫存)綠 = 手段,不構成任何「對」的宣稱。** 它們證的是「碼的某層沒壞」,不是「系統跑出來的東西對」。 - **不准用「直接呼函式產出」代替真入口路徑**——函式產的 ≠ 系統產的;中間物對 ≠ 出口物對 (出口常經下游步驟再變形,如反推的 delivered 檔由 來源保留步驟 重寫→可能與 canonical 不同)。 - **回報用語(硬規)**:「N 測綠」永遠不寫在結論位;結論位只准寫**「系統出口:X 份對 / Y 份不對」**。 測試綠只能放「手段/佐證」位。把「碼綠」講成「系統對」= 假宣稱。 - 對應姊妹技能 **ui-station-delivery**:一個站是否「能用」看真使用者從入口走到終點,不是清單打勾; 此處把同一原則推到「正確性」面——系統出口的正確性才算數。 ### 法則 3:對帳要精確,數字對得上 驗收後做**對帳**:預期幾項、實得幾項、差在哪。 - 「基準 N + 新增 M = N+M」——加得起來才算數;對不上代表有東西沒被驗到或被吞掉。 - **★一次性成本與穩態成本分列,不得互相掩蓋**:含「首次建置/種快取」的流程,效能數字要**冷(含一次性 成本)/ 暖(穩態)分開報、分開立基準**。拿暖批數字當唯一基準=把冷路徑的真實成本藏掉(換期/來源更新 時冷路徑會真實發生);拿冷批總數嚇人=誤判穩態。兩條各自有各自的斷言。 - 「零差異」的「零」要能說清楚:是**每一格都比過都相等**,還是「沒看到紅字」?後者可能是根本沒比。 - **★基準一律報雙數字,別單報一數**:測試套件的「通過數」和「收集數(含跳過)」是**兩個不同指標**—— 單報一個數,下���拿另一個指標對帳就會出現假矛盾(如 collect 1391 減 passed