和 AI 協作開發的早期，我們遇到一個讓人沮喪的問題：相同的功能一再被重複實作。某個模組已經有 BookValidator，但另一個任務裡 AI 又建了一個新驗證類別，因為它沒先問「這功能是否已存在？」更糟的是，遇到棘手問題時，我們（包括 AI）會下意識找「簡單的方法」迴避難題，用臨時解法掩蓋設計缺陷。

這才建立了 5W1H 自覺決策方法論：在建立任何任務之前，必須強制回答六個問題。不是「可以回答」，而是「必須回答」，任何一個缺失都阻止任務建立。

為什麼直覺判斷不夠用

直覺判斷的門檻太低。任何模糊的想法都可能直接變成任務被付諸實作，等發現重複了或架構位置錯了，才知道白花了時間。

5W1H 框架在任務建立的那一刻設置強制思考關卡。只有通過六個問題，任務才能被建立。

六個問題，六個層次的自覺

Who：責任歸屬，防止重複實作

Who 問的不只是「誰來做」，更重要的是「有沒有人已經做過了」。在我們的協作模式中，Who 必須明確標記執行者和分派者兩個角色，格式如：「parsley-flutter-developer（執行者）由 rosemary-project-manager（分派者）分派」。

這個格式強制一個邊界：主線程不應自己寫程式碼，職責是設計任務、分派任務、驗收結果。如果任務標記為主線程執行但類型是程式碼實作，系統直接阻止。

執行 Who 前要先做四步檢查：搜尋現有 Domain 是否有相同功能，確認既有 Service 是否已實作，查看測試覆蓋是否涵蓋，最後才決定是重用還是新建。Domain 中已有相同功能就禁止新建，責任不明就禁止執行。這兩條規則消滅了大部分重複實作。

What：功能定義，單一職責的守門員

What 要求明確說出具體的輸入輸出、業務行為和異常處理。合格的 What 必須能一句話描述完且無法再拆分。

「書籍處理——包含驗證、儲存、查詢等」不合格。「驗證輸入字串是否符合 ISBN-10 或 ISBN-13 格式，輸入 String isbn，輸出 ValidationResult，空字串拋出 ValidationError」才是。

職責不清就禁止執行，與既有功能重疊就整合，包含多個不相關職責就拆分。

When：觸發時機，副作用要完整識別

When 要求明確說出觸發事件，不是「書籍資料需要驗證的時候」，而是「使用者完成 ISBN 條碼掃描，觸發 ISBNScannedEvent，副作用包含觸發書籍資訊查詢和更新 UI 狀態，整合到 ScanTask 聚合根的事件系統」。

副作用未識別是 When 的紅線。連鎖反應沒有提前想清楚，後來就是難以追蹤的 bug。

Where：架構位置，確保層級正確

Where 決定功能在 Clean Architecture 中的位置。不是「在需要的地方執行」，而是「Domain Layer，BookValidator 位於 Book Aggregate，由 AddBookUseCase 呼叫，呼叫路徑是 UI → UseCase → Domain → Validator」。

位置錯誤就重新定位，不能為了方便就地執行。跨層級混亂就重新架構，不妥協。

Why：動機驗證，識別逃避性開發

Why 是六個問題中最重要的，因為它直接對抗最常見的開發陷阱——逃避。

合格的 Why 必須有需求文件編號，能說明具體的使用者價值和場景。「系統需要更多驗證」不合格，它沒有需求依據，而且可能只是為了逃避更難的問題。

遇到這些語言會立即阻止：「先做簡單的」（逃避複雜問題）、「順便加個功能」（缺乏需求）、「優化一下效能」（可能在迴避功能問題）。

How：實作策略，任務類型的強制標記

How 要求明確實作策略，並強制標記任務類型，格式是 [Task Type: XXX]。六種類型：Implementation（程式碼實作，必須由執行代理人執行）、Dispatch（任務分派，主線程執行）、Review（驗收，主線程執行）、Documentation、Analysis、Planning。

這個標記讓 Who 和 How 的合規性可以被自動檢查：How 標記為 Implementation 但執行者是主線程，系統直接阻止；Dispatch 類型的任務執行者是代理人，同樣阻止。

「先建立基本功能之後再加測試」是直接違規，任何臨時解法都禁止。

Who 和 How 的聯動檢查

正確組合：Implementation 搭配執行代理人，Dispatch/Review 搭配主線程。違規組合：Implementation 搭配主線程（主線程不應寫程式碼），Dispatch 搭配代理人，缺少執行者/分派者標記。

這個機制解決了一個真實痛點：主線程在時間壓力下直接修改程式碼，繞過代理人執行的設計。有了 How 的任務類型標記和 Who 的格式要求，這種行為在任務建立階段就被攔截。

逃避語言清單

框架持續更新一份逃避語言清單，分五類：

  • 品質妥協：「太複雜」「先將就」「暫時性修正」「症狀緩解」、“workaround”、“hack”、“quick fix”
  • 簡化妥協：「更簡單的方法」「簡化處理」——通常意味著在迴避真正的設計問題
  • 擱置問題：「架構問題先不管」「技術債務之後處理」——發現了卻不解決，最危險
  • 測試妥協：「簡化測試」「基本測試即可」
  • 模糊詞彙：沒有具體指標的「優化」「自動」

偵測到任何逃避語言，系統立即阻止並要求修正。

Hook 系統：讓規則有牙齒

框架的執行依賴 Hook 系統。TodoWrite 工具使用前，Hook 檢查 5W1H 完整性；任何一個 W 或 H 缺失，操作立即阻止；發現逃避語言，進入修復模式。

修復機制：阻止操作 → 明確說明缺失哪個項目 → 要求補充 → 再次驗證。

這個框架改變了什麼

最明顯的感受是對話品質變了。以前任務可能只有「實作書籍驗證功能」；現在必須帶著完整的 Who（誰來做、是否已存在）、What（具體輸入輸出）、When（何時觸發、有哪些副作用）、Where（架構層）、Why（需求來源）、How（任務類型和策略）才能被建立。

很多模糊的想法在回答六個問題的過程中就自然消失了——它們根本過不了關。