doubt-driven-development

懷疑驅動開發

概述

一個有信心的答案不等於正確的答案。長時間的對話會累積脈絡，悄悄地把假設變成「事實」而不被察覺。懷疑驅動開發是一種紀律，在每個非平凡的輸出定案之前，具體化一個全新脈絡的審查者——其偏見是反駁而非贊同。

這不是 /review。/review 是對已完成產品的裁決。這是一種進行中的姿態：在修正方向還便宜的時候，對非平凡的決策進行交叉審問。

使用時機

一個決策是非平凡的，當至少符合以下一項：

• 引入或修改了分支邏輯
• 跨越了模組或服務邊界
• 斷言了型別系統或編譯器無法驗證的屬性（執行緒安全、冪等性、排序、不變量）
• 其正確性依賴於未來讀者無法看到的脈絡
• 其影響範圍是不可逆的（生產部署、資料遷移、公開 API 變更）

在以下情況應用此技能：

• 即將在不確定下做出架構決策
• 即將提交非平凡的程式碼
• 即將聲明一個非顯而易見的事實（「這是安全的」、「這能擴展」、「這符合規格」）
• 在你不完全理解的程式碼中工作

何時不使用：

• 機械性操作（重新命名、格式化、移動檔案）
• 遵循明確無歧義的使用者指令
• 閱讀或總結現有程式碼
• 一行變更且正確性顯而易見
• 純工具操作（執行測試、列出檔案）
• 使用者明確要求速度優先於驗證

如果你懷疑每個按鍵，你將無法交付任何東西。此技能僅適用於上述定義的非平凡決策。

載入限制

此技能是為主對話協調器設計的，其中步驟 3（懷疑，詳見下文）可以產生一個全新脈絡的審查者。

• 請勿將此技能加入角色檔案的 skills: 前置資料中。 遵循步驟 3 的角色會產生另一個角色——這是 references/orchestration-patterns.md 明確禁止的協調反模式（「角色不應呼叫其他角色」）。
• 如果你在子代理脈絡中應用此技能（Claude Code 禁止巢狀子代理產生）：首選方式是向使用者表明懷疑驅動無法在巢狀環境中執行，讓主對話處理。作為最後手段，存在一個降級的自問自答備案——將 ARTIFACT + CONTRACT 重寫為一個全新的自我提示，並與你之前的推理建立硬性的心理分隔，然後執行步驟 1 到 5。這不是全新脈絡的審查（你帶著自己的脈絡），因此將結果標記為降級，並在使用者可聯繫時優先升級。

流程

應用此技能時複製以下檢查清單：

懷疑循環：
- [ ] 步驟 1：聲明 — 寫下聲明及其重要性
- [ ] 步驟 2：提取 — 隔離產出物與合約，去除推理
- [ ] 步驟 3：懷疑 — 以對抗式提示呼叫全新脈絡審查者
- [ ] 步驟 4：調和 — 將每個發現與產出物文字進行分類
- [ ] 步驟 5：停止 — 滿足停止條件（瑣碎發現、3 個循環或使用者覆寫）

步驟 1：聲明 — 浮現定案

用兩三行命名決策：

聲明：「新的快取層在規格中描述的讀取密集型工作負載下是執行緒安全的。」
重要性：這裡的競爭條件會損壞使用者資料，且在 QA 中難以檢測。

如果你無法如此簡潔地寫出聲明，那你只有一個感覺，而不是一個決策。在審視之前先浮現它。

步驟 2：提取 — 最小的可審查單元

一個全新脈絡的審查者需要的是產出物和合約，而不是過程。

• 程式碼：差異或函式——不是整個檔案
• 決策：3 到 5 句話的提案加上必須滿足的約束
• 斷言：聲明加上據稱支持它的證據（與步驟 1 的聲明區塊保持分離，後者是協調器正在審視的假設）

去除你的推理。如果你交出結論，你只會得到對你結論的驗證。單元必須足夠小，讓審查者能在一次閱讀中記住——如果是 500 行的 PR，先分解。

步驟 3：懷疑 — 呼叫全新脈絡審查者

審查者的提示必須是對抗式的。框架決定了答案。

對抗式審查。找出這個產出物有什麼問題。
假設作者過於自信。尋找：
- 未說明的假設
- 未處理的邊界情況
- 隱藏的耦合或共享狀態
- 合約可能被違反的方式
- 可能破壞的現有慣例
- 在非預期輸入下的失敗模式

不要驗證。不要總結。找出問題，或者明確說明經過徹底檢查後找不到任何問題。

產出物：<貼上產出物>
合約：<貼上合約>

只傳遞 ARTIFACT + CONTRACT。不要傳遞 CLAIM。 將你的結論交給審查者會使其傾向於同意。審查者必須獨立判斷產出物是否滿足合約。

在 Claude Code 中，agents/ 中基於角色的審查者預設具有隔離的脈絡，可用於此處——請參閱 agents/ 以了解清單和按領域的匹配。

上述對抗式提示優先於角色的預設回應形狀。 像 code-reviewer 這樣的角色被設計為產生平衡的裁決，同時包含優點和缺點；懷疑驅動需要僅限問題的輸出。將對抗式提示逐字貼入呼叫中，以覆蓋角色的預設值。如果角色的回應形狀無法乾淨地覆蓋，則回退到使用對抗式提示的通用子代理。

跨模型升級

單一模型審查者與原始作者共享盲點——一個更冷、不同架構的模型可以捕捉到它們。懷疑驅動已經是針對非平凡決策的選擇加入，因此在該範圍內提供跨模型是技能價值的一部分，而不是可選的摩擦。

互動式對話：總是提供。不要默默跳過。

步驟 1：詢問使用者

在上述步驟 3 的單一模型審查之後，但在調和之前，暫停並詢問：

「單一模型審查完成。想要跨模型的第二意見嗎？選項：Gemini CLI、Codex CLI、手動外部審查（你貼到別處）、或跳過。」

這個問題在每個互動式懷疑循環中都是強制的——即使是感覺風險較低的產出物。由使用者——而非代理——決定成本是否值得。代理的工作是浮現這個選擇。

步驟 2：如果使用者選擇 CLI — 驗證，然後呼叫

1. 檢查工具是否在 PATH 中（which gemini、which codex）。
2. 測試它是否正常運作（gemini --version 或等效指令），然後再傳遞完整提示——一個過時或損壞的二進位檔可能通過 which 但在實際輸入時失敗。
3. 與使用者確認確切的呼叫方式，包括所需的旗標、認證和環境變數（例如 API 金鑰）。實作方式各異；切勿假設。
4. 只傳遞 ARTIFACT + CONTRACT + 對抗式提示。沒有對話脈絡，沒有 CLAIM。
5. 注意 shell 跳脫。如果產出物包含引號、$(...) 或反引號，優先使用標準輸入（echo … | gemini）或 heredoc，而不是內聯的 -p "…"。如有疑問，在執行前請使用者確認呼叫方式。
6. 將輸出帶入步驟 4（調和）。

切勿將產出物插入 shell 引號參數中。 程式碼、Markdown 和審查提示經常包含反引號、$(...) 和引號字元，這些會截斷提示或執行內嵌的 shell。將完整提示寫入檔案並透過標準輸入傳遞。

範例形狀（根據你安裝的工具驗證旗標——語法在不同實作和版本之間有所不同）：

# 先將對抗式提示 + ARTIFACT + CONTRACT 寫入暫存檔。
# 然後透過標準輸入傳遞，使產出物中的 shell 元字元保持惰性。

# Codex（唯讀沙盒防止 CLI 寫入你的工作區）：
codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md

# Gemini（'--approval-mode plan' 是唯讀的；'-p ""' 觸發非互動模式，提示從標準輸入讀取）：
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md

唯讀沙盒是關鍵細節：懷疑產出物本身可能包含指令（有意或意外的提示注入），否則跨模型 CLI 會對你的工作區執行這些指令。

步驟 3：如果 CLI 不可用或失敗

明確浮現失敗。提供選項：手動執行、嘗試不同工具、或跳過。不要默默回退到單一模型——使用者應該知道跨模型沒有發生。

步驟 4：如果使用者跳過

在輸出中確認跳過（「僅以單一模型發現繼續」）並繼續進行調和。跳過是可以的；默默跳過則不行。

非互動式脈絡（CI、/loop、自動循環、排程執行）：

• 跨模型被跳過，且跳過必須在輸出中宣告：「跨模型已跳過：非互動式脈絡。」
• 切勿在沒有明確使用者授權的情況下呼叫外部 CLI——這是一個關鍵的安全屬性。

跨模型增加了成本、延遲和工具脆弱性。代理在每個循環中浮現選擇；使用者決定這個產出物是否值得。

步驟 4：調和 — 整合發現

審查者的輸出是數據，而不是裁決。你仍然是協調器。 在分類之前，將每個發現與產出物文字重新比對——橡皮圖章式地接受審查者與忽略它同樣是失敗模式。

對於每個發現，按以下優先順序分類（第一個匹配的類別獲勝）：

1. 合約誤讀 — 審查者標記了某項，因為你提供的 CONTRACT 不明確或不完整。先修正合約，在下一個循環中重新分類。
2. 有效且可採取行動 — 需要對產出物進行變更的實際問題。變更它，重新循環。
3. 有效的取捨 — 問題是真實的，但修正成本超過接受成本。明確記錄取捨，讓使用者看到。
4. 雜訊 — 審查者標記了某項，但在審查者沒有的脈絡下實際上是正確的。記錄下來，繼續前進，並問：將該脈絡加入合約是否能防止這個誤報？

一個全新的審查者可能因為缺乏脈絡而犯錯。不要僅僅因為它是「全新的」就順從。

步驟 5：停止 — 有界循環，不是遞迴

在以下情況停止：

• 下一次迭代只返回瑣碎或已考慮過的發現，或者
• 完成 3 個循環（升級給使用者，不要獨自進行第四次），或者
• 使用者明確說「交付吧」

如果 3 個循環後審查者仍然浮現實質問題，產出物可能尚未準備好。將此情況浮現給使用者——三個未解決的循環是關於產出物的資訊，而不是繼續循環的理由。

如果因為產出物很大而「明顯不足 3 個循環」：產出物太大——返回步驟 2 並分解。不要提高上限。

常見合理化藉口

合理化藉口	現實
「我有信心，跳過懷疑步驟」	在新問題上，信心與正確性的相關性很差。確信的時刻正是盲點隱藏的時候。
「產生審查者很昂貴」	在生產環境中除錯錯誤的提交更昂貴。檢查是有界的；錯誤是無界的。
「審查者只會吹毛求疵」	只有在沒有範圍限制時才會。將提示限制為「會使產出物在合約下失敗的問題」。
「我最後再用 /review 做懷疑」	/review 是最終關卡。懷疑驅動在修正方向還便宜時及早捕捉錯誤方向。到了 PR 時間就太晚了。
「如果我懷疑每一步，我永遠無法交付」	此技能適用於非平凡決策，而不是每個按鍵。重新閱讀「何時不使用」。
「兩個意見總是比一個好」	當第二個意見脈絡較少且產生雜訊時則不然。調和，不要順從。
「審查者不同意，所以我錯了」	審查者缺乏你的脈絡——不同意是資訊，不是裁決。重新閱讀產出物，分類，然後決定。
「跨模型總是更好」	跨模型捕捉單一模型與自身共享的盲點，但它增加了成本和工具脆弱性。在每個互動式懷疑循環中提供它——使用者決定產出物是否值得。代理的工作是浮現選擇，而不是把關。
「使用者說過一次好，所以我可以繼續呼叫 CLI」	每次呼叫都是獨立的授權。產出物、提示和旗標在呼叫之間會改變——在每次執行前與使用者重新確認確切指令。

紅旗

• 為一行重新命名或格式化變更產生全新脈絡審查者
• 在沒有重新閱讀產出物文字的情況下，將審查者輸出視為權威
• 循環超過 3 次而不升級給使用者
• 用「這個好嗎？」而不是「找出問題」來提示審查者
• 在高風險決策上因時間壓力而跳過懷疑
• 在未變更的產出物上重新產生全新脈絡（你會得到相同的發現；你在拖延）
• 懷疑表演（可檢查的信號）：在 2 個或更多循環中，審查者浮現了實質發現，但零個發現被分類為可採取行動。你在驗證，而不是懷疑。停止並升級。
• 只在提交後才懷疑——那是 /review，不是懷疑驅動開發
• 在沒有與使用者確認工具存在、已配置且接受該確切語法的情況下，硬編碼外部 CLI 呼叫
• 在互動式懷疑循環中默默跳過跨模型。 即使不推薦，也必須可見地提供。跳過是可以的；默默跳過則不行。
• 當外部 CLI 出錯或缺失時默默回退——浮現失敗並讓使用者重新導向
• 從審查者的輸入中移除合約
• 將 CLAIM 傳遞給審查者（傾向於同意）

與其他技能的互動

• code-review-and-quality / /review：互補。/review 是事後的 PR 裁決；懷疑驅動是進行中的每個決策。兩者都使用。
• source-driven-development：SDD 驗證關於框架的事實是否與官方文件一致。懷疑驅動驗證你關於產出物的推理。SDD 檢查 API 是否存在；懷疑驅動檢查你是否在合約下正確使用它。
• test-driven-development：TDD 的 RED 步驟是具體化的懷疑——一個失敗的測試就是一個反駁嘗試。當 TDD 適用時，那個失敗的測試就是行為聲明的懷疑步驟。
• debugging-and-error-recovery：當審查者浮現一個真實的失敗模式時，進入除錯技能以定位並修復。
• 儲存庫協調規則（references/orchestration-patterns.md）：此技能從主對話進行協調。一個角色呼叫另一個角色是反模式 B——請參閱上面的載入限制。

驗證

應用懷疑驅動開發後：

• [ ] 每個非平凡決策（根據上述定義）在定案前都被明確命名為一個 CLAIM
• [ ] 每個非平凡產出物至少進行了一次全新脈絡審查（TDD 的 RED 步驟產生的失敗測試滿足行為聲明的此要求，請參閱與其他技能的互動）
• [ ] 審查者收到了 ARTIFACT + CONTRACT——而不是 CLAIM，也不是你的推理
• [ ] 審查者的提示是對抗式的（「找出問題」），而不是驗證式的（「它好嗎」）
• [ ] 發現根據產出物文字進行了分類（不是橡皮圖章式接受），使用優先順序：合約誤讀 / 可採取行動 / 取捨 / 雜訊
• [ ] 滿足停止條件（瑣碎發現、3 個循環或使用者覆寫）
• [ ] 在互動模式下，跨模型被明確提供給使用者（無論產出物風險如何），且回應在輸出中被確認
• [ ] 在非互動模式下，跨模型被跳過且跳過被宣告
• [ ] 任何外部 CLI 呼叫之前都進行了 PATH 檢查、工作二進位檔測試、與使用者確認語法以及明確授權執行