驗證方法的選擇時機
核心原則
驗證工具的引入時機不該等推理徹底失敗。 靜態 CSS 推理或視覺截圖溝通連續失敗 ≥ 2 次、立刻主動提「我們啟個 server、我用 playwright 看 live DOM」 — 工具的價值是縮短診斷迴圈、不是最後手段。
為什麼要主動提工具
商業邏輯
執行者堅持靠推理 = 把使用者拖進「截圖 - 反饋 - 再試」的長循環。每輪都消耗使用者時間（看截圖、描述問題、回應）— 對使用者是負擔。
主動提工具切換 = 把循環從「視覺溝通」改成「程式量測」。執行者直接讀 live DOM、診斷一輪到位、使用者只需要在最終確認。
主動提的成本是「打一句話建議」、收益是「省 N 輪截圖溝通」。
這次任務的實際情境
觀察
drawer 在 form 內、不是 sibling 這個假設錯誤、靠推理 + 截圖溝通走了多輪：
| 輪 | 溝通方式 | 結果 |
|---|---|---|
| 1 | 推理 + 寫 CSS + 使用者截圖回報 | 失敗、看不出根因 |
| 2 | 改 CSS + 使用者截圖回報 | 失敗、累積錯誤假設 |
| 3 | 加更多覆寫 + 使用者截圖回報 | 失敗、使用者「思路錯了」 |
| 4 | 「我啟個 server 看看」 | 立刻發現 drawer 在 form 內 |
第 4 輪用 playwright browser_evaluate 讀 ancestor chain — 一個 query、一個答案、兩分鐘解。前三輪 ≈ 30 分鐘。
判讀
第 2 輪失敗時就應該主動提：
「我嘗試了兩次都失敗、根因可能在我對 DOM 結構的假設。要不要啟個 server、我用 playwright 直接讀 live DOM 確認？這樣比繼續用截圖溝通快。」
使用者啟 server、我跑 query、一輪解。
執行：主動提工具的 protocol
驗證工具該在這些時機主動提：
| 訊號 | 應該提的工具 |
|---|---|
| 推理連續失敗 ≥ 2 次 | playwright browser_evaluate 讀 live DOM |
| 不確定元素的真實位置 | getBoundingClientRect |
| 不確定 computed style 套到什麼值 | getComputedStyle |
| 不確定 framework 渲染後的 DOM | playwright snapshot |
| 不確定跨 viewport 行為 | playwright 切換 viewport 重測 |
工具引入的成本與價值
內在屬性比較
| 方法 | 起步成本 | 每輪成本 | 涵蓋 |
|---|---|---|---|
| 推理 + 截圖 | 0 | 高 — 截圖、描述、再試 | 有限 — 看截圖看不到 DOM |
| 瀏覽器 DevTools 手動查 | 0 | 中 — 切面板、讀 | 中 — 互動成本高 |
Playwright browser_evaluate | 中 — 起 server | 低 — 寫一段 evaluate | 高 — 任意 JS query |
| Playwright 寫成測試 | 中 — 起 server + 寫測試 | 0 — 自動跑 | 高 + 持續 |
「起步成本」是一次性、「每輪成本」是重複的。第 2 輪以後、playwright 的 ROI 已經正向。
主動提的具體話術
較差的提法
「要不要試試 playwright」
模糊、使用者不一定知道為什麼要試、可能答「先這樣吧」。
較好的提法
「我嘗試了兩次都失敗、根因可能不在 CSS、在我對 DOM 結構的假設。 要不要啟個 server（
python3 -m http.server 8000在 public/）、 我用 playwrightbrowser_evaluate直接讀 ancestor chain 確認？ 這樣比繼續用截圖快很多。」
說明：
- 為什麼提：兩次失敗、推理迴圈成本超過工具迴圈
- 要使用者做什麼：啟 server、給一行指令
- 我會做什麼：用 playwright evaluate 讀
- 預期收益：縮短迴圈
使用者明確知道 trade-off、決定簡單。
工具迴圈的標準流程
11. 使用者啟 server（python3 -m http.server / hugo server）
22. 執行者 navigate 到目標頁面
33. 執行者寫 evaluate fn 讀真實狀態
44. 執行者根據結果定位根因
55. 執行者改 CSS / JS
66. 執行者再 evaluate 驗證修復
77. 使用者目視最後確認（可選）整個流程多數步驟在執行者這邊、使用者只在頭尾參與 — 對使用者負擔輕。
設計取捨：驗證工具引入的時機
四種做法、各自機會成本不同。這個專案選 A（推理 ≥ 2 次失敗主動提）當預設、其他做法在特定情境合理。
本篇是 #42 2 次門檻 抽象原則在「驗證工具切換」這個面向的應用。
A：推理 ≥ 2 次失敗主動提工具切換（這個專案的預設）
- 機制：靜態推理連續失敗 2 次、立刻提「啟個 server、我用 playwright 看 live DOM」+ 附啟用步驟與預期收益
- 選 A 的理由：對使用者透明（看到 trade-off）、縮短診斷迴圈
- 適合：CSS / DOM 行為跟預期不符的除錯
- 代價：執行者要主動辨識「推理迴圈成本」與「工具迴圈成本」的交叉點
B：等使用者要求才用工具
- 機制：執行者繼續推理、使用者覺得太慢時提
- 跟 A 的取捨：B 對使用者更被動、A 主動；B 在使用者不知道有 playwright 選項時、會一直繼續
- B 才合理的情境：使用者明確表達「想用推理練習」、把工具切換當成放棄
C：全程靜態推理、不用工具
- 機制：堅持推理到底
- C 是反模式：推理迴圈成本累積、最後可能需要 4-5 輪才解決
- 看起來吸引人的原因：覺得用工具是「能力不足」、想撐到自己想出來
- 實際發生的代價：時間成本指數放大（每輪推理基於前輪錯假設）、最後還是要切工具
D：一開始就用 playwright、不嘗試推理
- 機制：跳過推理、直接用工具量
- 跟 A 的取捨：D 跳過推理階段省去 2 次嘗試、但前期 setup 成本投入比例較高（簡單問題不值得）
- D 比 A 好的情境：問題明確需要 live DOM 才能診斷（例如「framework 渲染後的結構」）— 推理本來就無法解
判讀徵兆
| 訊號 | 應該主動提的工具 | 提的話術重點 |
|---|---|---|
| 推理 + 截圖溝通 ≥ 2 輪 | playwright browser_evaluate | 我假設可能錯、用工具讀 live DOM 確認 |
| 修了 CSS 但使用者截圖看起來沒變 | playwright getComputedStyle | 確認 CSS 真的套到、不是 cache 問題 |
| 不確定哪個 viewport 下會有問題 | playwright 多 viewport 測 | 一次跑多 viewport、找出哪個壞 |
| 互動狀態下行為不一致 | playwright 模擬互動 + 量測 | 自動操作、量結果 |
| 修好了想固化規範 | playwright 寫測試 | 把這次發現的契約寫成 expect、未來破壞會被抓 |
核心原則：工具引入時機是「推理迴圈成本超過工具迴圈成本」的點 — 大多在第 2 次推理失敗時。早一點提、雙方都省時間。
跟 #68 驗收的時間軸 的關係：本卡是「debug 工具切換時機」、#68 是「驗收動作分散在四個時點」 — 兩者共用「動作該分配到哪個時點才有 ROI」這個結構。本卡的「第 2 次推理失敗就切工具」≈ #68 的「ship 前要設計 E2E case」 — 都是「把高 ROI 的動作放在對的時點、不要延後」。