編碼前先分類任務：提升開發效率與降低AI成本的關鍵

您送往 Claude Code 的每個請求在 API 看起來都一樣：輸入 token，輸出 token。但在您的專案中，每個請求都是不同的工作。有的需要兩行答案，有的需要仔細修復錯誤，有的則是需要先制定規格的新功能，還有的只是耗時一小時卻不產生任何程式碼的腦力激盪。

我見過團隊最昂貴的習慣，就是讓這些請求都走相同的流程。一個簡單的問題可能演變成四個檔案的重構，因為沒有任何指令告訴模型「只回答問題」。一個錯誤修復可能會偏離到無人要求的清理工作。這些都會在月底的 token 帳單上顯現出來。

解決這個問題只需九十秒。在任何工作開始之前，您可以在腦海中完成：選擇通道、選擇模型、決定這個請求是否需要規格。然後再開始。

以下是專案 CLAUDE.md 檔案（每個會話首先讀取的檔案）中的十個通道：

Q (快速問題)：觸發詞如「什麼」、「解釋」、「如何」、「為什麼」。動作是直接回答，使用 Haiku 模型。

B (錯誤)：觸發詞如「錯誤」、「崩潰」、「無法運作」、「修復」。動作是診斷、修復、驗證、記錄開發日誌，使用 Sonnet 模型。

S (小型功能)：少於三個檔案，少於一小時。動作是驗證規格是否存在、實作、記錄開發日誌，使用 Sonnet 模型。

L (大型功能)：新畫面或服務，超過三個檔案。動作是建議使用 Opus 模型，然後進行完整的規格、計畫、任務循環。

R (重構)：觸發詞如「重構」、「清理」、「提取」。動作是分析、提出建議、實作，使用 Sonnet 模型。

T (測試/品管)：觸發詞如「測試」、「品管」、「使用者體驗」、「分析」。動作是執行測試技能，使用 Sonnet 模型。

D (探索)：觸發詞如「腦力激盪」、「設計」、「想法」、「我們應該如何」。動作是建議使用 Opus 模型，然後進行腦力激盪技能。

M (記憶)：觸發詞如「我們做了什麼」、「狀態」、「我們在哪裡」。動作是讀取記憶並回答，使用 Haiku 模型。

O (觀察者)：觸發詞如「優化代理」、「改進工作流程」。動作是進行鏈健康稽核，使用 Sonnet 模型。

E (專家)：觸發詞如「審查」、「第二意見」、「出貨前檢查」。動作是使用專家子代理和領域膠囊，使用 Sonnet 模型。

這張表格位於每個會話在第一次回覆前載入的協定檔案頂部。分類過程是靜默進行的，您看到的只是通道的動作，而不是其名稱。但底層的路由是固定的。每個通道都擅長一項工作。通道上的字母告訴工作者要遵循哪種模式，相同的輸入，根據其落點會產生十種不同的結果。

為什麼是十個而不是三個？我讀過的大多數框架都將其壓縮為三個通道：問題、任務、大型任務。這種簡化正是問題所在。Q (快速問題) 和 B (錯誤) 需要分開。一個快速問題需要最簡短的答案來消除困惑。一個錯誤需要重現步驟、根本原因、修復、驗證以及開發日誌中的一行記錄。將它們混為一談，Haiku 會處理錯誤（緩慢且有風險），而 Sonnet 會處理問題（昂貴且過於冗長）。

L (大型功能) 和 D (探索) 也需要分開。一個大型功能帶著明確的目標而來，例如「交付預訂流程」。一個探索任務則沒有目標，例如「我們應該如何處理預訂？」功能通道運行規格、計畫、任務、建構。探索通道運行腦力激盪、規格草稿、人工決策，然後可能才進行建構。將它們混淆，您可能會為一個尚未確定的問題過早地編寫程式碼。

E (專家) 只有在您建立了相應機制時才會出現。專家通道會載入您專案類型的領域速查表，並根據其進行審查。如果您沒有速查表或子代理，此通道將不會啟動，請求會退回到 R 或 T。如果您是從頭開始，可以跳過 E 幾週而不會有任何損失。這個數字並非為了展示。每個通道都值得擁有自己的一行，因為它旁邊的通道會做得更糟。

每個通道的模型是模式的後半部分，也是最直接影響 token 帳單的部分。在 Q (快速問題) 和 M (記憶) 上使用 Haiku，可以為每個「這個檔案做什麼」和每個「我們在第 14 個衝刺階段進度如何」節省百分之九十的成本。這些是按數量計算最頻繁的通道，將它們推向最便宜的模型是整個協定中最大的成本槓桿。

在 L (大型功能) 和 D (探索) 上使用 Opus 則是相反的舉動。當輸出將保留數月時，例如規格、計畫、腦力激盪記錄，這是一個刻意升級到更智能模型的步驟。這些文件比會話本身更持久。為它們支付 Opus 的價格，比支付 Sonnet 撰寫一份薄弱規格導致三週返工要便宜。

中間的 Sonnet 是通用通道。大多數鍵盤輸入時間都發生在這裡。

分類還會影響一個決策：這個通道在觸及任何檔案之前是否需要規格？有兩個通道需要：L (大型功能) 和 D (探索)。兩者都在表格中明確說明：「完整的規格、計畫、任務循環」/「腦力激盪、規格草稿」。在這些通道中，除非 specs/<N>-<slug>/ 資料夾中有三個簽核的文件，否則不會進行任何建構。其他所有通道都跳過此門檻。

一個快速問題不需要規格。一個錯誤修復不需要規格，它需要診斷和開發日誌記錄。一個重構需要聊天中快速的提案，而不是衝刺資料夾。這個門檻只在重要通道上觸發，因為將其應用於所有地方將是致命的。想像一下為每個「useEffect 做什麼」打開一個規格資料夾，開銷將會吞噬整個專案。關鍵在於：紀律與通道的重要性相匹配。

我一直搞錯的通道是 D (探索) 和 Q (快速問題)。這兩者在實際情況中看起來幾乎相同，但卻需要相反的東西。「我們應該如何處理快取？」聽起來像個問題，但它不是。這是一個探索，誠實的答案需要權衡，而不是定義。「快取失效是什麼意思？」聽起來很相似，但它是一個問題，誠實的答案是三句話和一個連結。從遠處看，跡象是一樣的。區別在於過程，一個是帶有長椅的短直路徑；另一個則蜿蜒一小時。區別在於正確答案的樣子。

如果誠實的答案以「這取決於您的限制，請告訴我…」開頭，那麼您處於 D (探索) 通道。如果它以「它是 X，它做 Y」開頭，那麼您處於 Q (快速問題) 通道。我問自己的問題是：這需要對話，還是需要答案？如果將 D 誤判為 Q，您會損失一小時。如果將 Q 誤判為 D，您會損失一天，因為模型現在正在為您實際上不想建構的功能起草規格。

這解決了什麼問題？在 /tools 上的七個專案中，一個模式保持不變：當分類到位時，返工量大約減少了十倍。這個十倍的差距在我嘗試的每個專案規模中都保持不變，包括 Flutter 行動應用程式、Next.js SaaS、後端管線。改變這個數字的不是模型，也不是技術堆疊。而是每次請求前的那九十秒。相同的工具、相同的木材、相同的木匠。兩個房間唯一的區別在於是否在切割開始前對訂單進行了分類。

上市時間與感覺相反。對每個傳入請求進行分類的專案比從第一個請求就開始打字的專案更快上市。分類時間在當下感覺不像是在進步，因為沒有任何東西被建構出來，這正是我每次放鬆時，它總是第一個被放棄的紀律。記分卡讓這個差距變得可見。

如何採用？最短路徑：複製表格。打開您的專案 CLAUDE.md，將這十個通道逐字貼上，然後在腦海中處理接下來的二十個請求。其他一切都不變。沒有子代理、沒有規格資料夾、沒有新檔案。只是在每次回覆前問一個問題：這是哪個通道？您會開始注意到您混淆了哪些通道。

完整路徑：安裝協定。執行 curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash。這將安裝分類器、五個入口點技能、規格、計畫、任務的鷹架，以及衡量您是否實際遵循所設定通道的記分卡。

MIT 授權，無需註冊，無遙測。儲存庫：github.com/ruslan4427/claude-shiploop。安裝腳本會合併到您現有的 CLAUDE.md 中，而不會覆蓋現有內容。產生返工率數字的記分卡位於 /tools。我的七個專案，三個層級，每個五個指標。

其中三個顯示在 token 欄位中，因為沒有數據可以計算。這個空白是一個刻意的規則，記分卡拒絕猜測無法衡量的數字。關於發布、安裝流程和「null 是誠實的」規則的完整說明位於 /blog/shipping-claude-shiploop。分類器本身每次請求運行需要九十秒。這就是全部的要求。其他一切都源於這個習慣。