Claude Code 的 Ultracode：你可能還不知道卻不可或缺的 AI 團隊協作功能

Claude Code 有一個關鍵字，能將單一提示詞轉化為一個團隊。只要輸入「ultracode」，Claude 就會編寫一個小型程式，平行派遣多個代理去閱讀並交叉檢查你的資料，然後將結果回報給你。如果再加入一個協調者會話（coordinator session）來啟動並運行其他會話，一個聊天就能驅動一個包含十個會話的專案。

接下來，我將解釋何時使用 Ultracode 最有價值、如何撰寫提示詞，以及如何從單一工作流程發展成一個會話團隊，並以我的一個專案作為範例。

FT-4 是我嘗試使用 LoRA 和 GRPO（一種強化學習方法）微調 Qwen3.5-9B，使其成為一個能良好運用我記憶系統的個人助理。其中一個目標是開發一個任何人都能運行的小型模型，所以我用我自己的 GTX 1070 Ti（一張幾代前的 8GB 顯示卡）進行 4 位元測試。

在支付訓練 GPU 費用之前，我希望這個計畫能受到最嚴格的審查。我將這項任務交給一個開啟 Ultracode 的 Claude Code 會話，並要求它扮演反對者的角色。在兩小時內，它回報了「建議修改」並列出十個阻礙。大約 45 小時內，包括夜間暫停，它運行了四個工作流程並啟動了九個會話（其中一個又啟動了第十個），而我只輸入了大約 20 次指令，大部分是「yes」或「resume」。

其中兩項發現改變了整個專案：訓練腳本會給每個答案零獎勵，以及我未經訓練的輔助程式（harness，負責將每次對話儲存到記憶體並讓模型在回答前進行搜尋的程式碼）得分已落在預期訓練模型的範圍內。協調者「FT-4 紅隊審查」及其啟動的會話，都巢狀顯示在 Claude Code 桌面側邊欄中。

Ultracode 的作用是，只要在你的提示詞中加入「ultracode」這個詞，該次對話就會變成多代理編排（詳見文件）。Claude 會編寫並運行一個工作流程腳本，該腳本會根據任務需求分派子代理，例如平行閱讀者或質疑者。他們的結果會回傳到你的聊天中。

輸入 /effort ultracode 可以讓 Ultracode 在整個會話中保持開啟，然後 Claude 會決定哪些任務需要工作流程；/workflows 則會列出正在進行和已完成的運行。我的協調者在整個過程中以極高努力度（xhigh effort）運行 Opus 5.5 並開啟 Ultracode，每個實質性任務都獲得了一個工作流程。

協調者本身不需要關鍵字。桌面應用程式中的會話可以互相尋找和傳送訊息（詳見文件，適用於原生 Windows v2.1.234 或更高版本），而且 Claude 會自行進行這些呼叫，所以我從未輸入工具名稱。在我的運行中，協調者更進一步：它啟動了新的會話，為每個會話編寫了簡報，並且每當其中一個會話完成一次對話時，它都會收到一個簡短的通知。

這些子會話會巢狀顯示在側邊欄中，就像上面的截圖一樣，這是一種我尚未在文件中找到的佈局。

何時使用 Ultracode 在三種情況下，Ultracode 會帶來顯著效益。首先，當資料量過大無法單一上下文處理，但又能清晰地分割，讓每個閱讀者負責一部分時。其次，當某些主張需要專門負責反駁的代理進行審查時。最後，當遺漏某個步驟會導致實際金錢損失，例如租用一天的 GPU 時。

FT-4 專案就具備這三種情況：有大量記錄、輔助程式碼、備忘錄、運行檔案和論文需要閱讀；一個充滿預測的計畫需要被嚴格審查；以及尚未支付的訓練租賃費用。請根據問題調整工作流程的大小。/config 中的「Dynamic workflow size」設定會告訴 Claude 目標規模（預設為 medium，表示少於 10 個代理，但 Claude 可能會超出此限制），當代理數量超過 25 個或預計消耗 150 萬個 token 時，會出現「Large workflow」警告。

我的首次審查需要閱讀所有內容，使用了 17 個代理。而關於租用哪種 GPU 的問題，只需要三個代理，他們將單一 H200 列為首選，因為訓練是在單一 GPU 上運行，並且 GRPO 的記憶體決定了選擇。對於單行修正或當你已經知道答案只剩下輸入時，請跳過 Ultracode：每個子代理都會消耗自己的上下文，因此一個工作流程的成本遠高於一次仔細的對話。

這個關鍵字在 -p 運行中不會觸發，而 Alt+W（macOS 上是 Option+W）可以讓它在單一提示詞中失效，這在你的文本中因其他原因出現「ultracode」這個詞時很有幫助。

如何撰寫工作流程的提示詞 告訴它失敗的樣貌。代理會尋找你要求它們尋找的內容，「審查這個計畫」這樣的指令沒有明確指出任何目標。我的簡報要求它找出哪些因素會使結果失效、混淆或削弱，是否有更便宜的方法能達到相同目標，以及 2025 至 2026 年的主要來源說了什麼。

在第一個工作流程開始七分鐘後，唯讀閱讀者就發現我未經訓練的輔助程式已經在預測範圍內，並且一個評分器在結果出來後被修改過。給予代理角色，並讓其中一些成為質疑者。在我的運行中，Claude 自行選擇了角色：只能閱讀的閱讀者、閱讀論文全文而非摘要的代理，以及預設任務是反駁的驗證者。

你可以透過名稱要求任何這些角色。第二個工作流程派出了十個質疑者，每個負責一組主張，並被告知「你的任務是盡可能反駁它們」。他們確認 FT-4 不存在 GRPO 獎勵碼，這就是我在花費任何 GPU 時間之前得知零獎勵問題的方式。Claude 會為你編寫這個腳本。

以下是我的驗證流程的偽程式碼。函數名稱（phase、parallel、agent、log、args 全域變數）和 schema 選項（讓代理返回 JSON 而非散文）來自文件；這裡的確切簽名是我的近似值。

// 偽程式碼：我的驗證流程的結構，非實際腳本。

phase("Verify");

const verdicts = await parallel(args.claimClusters.map((cluster) => () => agent(你是一個質疑者。紅隊審查的主張：\

${cluster}\

你的任務是盡可能反駁它們。請自行閱讀引用的檔案。, { schema: { type: "object", properties: { verdict: { enum: ["confirmed", "refuted", "partly"] }, evidence: { type: "string" } }, required: ["verdict", "evidence"] } })));

phase("Critic");

const missed = await agent(將此審查與簡報進行比較。列出它未涵蓋的內容。);

log(${verdicts.length} verdicts in, critic done);

return { verdicts, missed };

透過結構描述（schema），每個質疑者都會返回一個「verdict」欄位，協調者無需解析散文即可合併答案。最後，加入一個完整性評論者：一個代理會將結果與你的簡報進行比較，並列出沒有被要求檢查的內容。在我的第二個工作流程中，評論者根據我的簡報審查了報告，最終報告列出了十個阻礙、27 項發現和五個實驗。

之後的一個規劃工作流程，在最終修訂前加入評論者，修正了 26 項主張，增加了 18 個遺漏項目，並留下了五個只有我能做出的決定。你可以在需要時停止並稍後恢復，因為暫停的工作流程會保留每個完成代理的工作。我的規劃工作流程進行到一半時，我逐字輸入了「stop we resume tomorrow」。

第二天早上我輸入「resume」，只有一個檢查和最終修訂再次運行；閱讀者和綜合結果都來自快取。你可以從 /workflows 選擇運行並按下 p 來恢復，或者要求 Claude 重新啟動它，只要你保持在同一個會話中即可。

從單一工作流程到協調者 當發現的內容超出單一聊天會話的範圍時，將每個部分轉化為獨立的會話，並附上一個新的會話可以依據的簡報。一個好的簡報會列出首先要閱讀的發現、交付成果、會話不得觸碰的檔案，以及每個依賴項的負責人。審查結束後，我輸入了一行指令，要求針對所有問題建立獨立會話。

在八分鐘內，協調者啟動了八個會話，自行編寫了每個簡報，並發布了一個表格，將每個會話映射到其負責的阻礙。每次只允許一個寫入者操作每個共享檔案。我的八個會話在同一個工作區（checkout）中運行，沒有使用工作樹（worktrees），因此在啟動它們之前，協調者與持有最繁忙檔案的會話協商了一份檔案所有權清單。

從那以後，會話之間自行處理。輔助程式會話要求評分器會話「回覆『已釋出』或指出仍屬於你的部分」，並收回了附帶必須遵守規則的檔案。當第三個會話針對該檔案發送五個變更請求時，評分器會話將它們轉發，以確保「只有一個寫入者持有該檔案」。在不同儲存庫中工作的一個會話則使用了自己的工作樹。

讓協調者進行轉發，並以固定格式詢問狀態。我的參與縮減為簡短的回答，協調者會逐字轉發給正確的會話。當我輸入「where we are」（我們進度如何）時，它發送了九個相同的請求，要求以四個部分（已完成、遺漏、需要我決策、運行中）在 200 字內回覆，並將它們合併成一個清單，顯示了哪些任務阻礙了哪些任務。

它還捕捉到停滯情況：一個會話閒置了 90 分鐘，承諾的工作尚未完成，在一次提醒後，它在 11 分鐘內交付了。每次只允許一個持有者使用每個付費資源。我的會話共享在 vast.ai 上租用的 GPU、我的 VPS 和我自己的顯示卡。當第一個租賃的 RTX 5090 完成實驗後，我逐字告訴協調者：「send a message to other session: one of them need the gpu, so we don't waste money」（發送訊息給其他會話：其中一個需要 GPU，這樣我們就不會浪費錢）。

它將顯示卡提供給七個會話，訓練管線會話在其上運行了兩個任務，然後我才結束租賃。第二個租賃則用於處理佇列中的實驗。每個任務只有在前一次運行的報告顯示通過後才啟動，因為即使失敗，報告檔案也存在，所以找到檔案並不能證明什麼。當 GPU 忙碌時，協調者會給閒置的會話分配不產生額外費用的工作。

將金錢決策權掌握在自己手中，並設定硬性上限。所有 API 費用都透過一個我自行創建並儲值、上限為 50 美元的 OpenRouter 金鑰支付；會話可以請求使用它，但不能創建它。我的 VPS 上的夜間佇列只有在金鑰餘額至少還有 9 美元時，才會運行最後一個實驗。

支出批准也不會在會話之間傳遞。一個會話拒絕運行由另一個會話轉達我的「yes」的實驗，協調者告訴我，有兩個會話需要我在它們各自的聊天中輸入「go-ahead」（同意）。這讓我多切換了幾次聊天，但我希望如此：一個會話要花我的錢，就必須直接從我這裡聽到「yes」。

預期結果 首先，預期決策能夠經得起考驗。在第一個工作流程完成兩天後，在租用 GPU 上的一次運行證實了其未經訓練的輔助程式的發現：一個未經訓練的輔助程式「在所有閱讀和搜尋指標上都已與訓練後的範圍相符」。這只剩下一個訓練仍能增加價值的地方，那就是模型決定儲存到記憶體中的內容，而我在支付任何訓練費用之前就學到了這一點。

這些會話也建立了一些東西。在兩天內，它們產生了一個評分器和獎勵模組，其中 189 個新的測試案例在至少一個故意的程式碼破壞下都失敗了；一個新的、具有密封測試分割的使用者模擬世界；以及一個 4 位元服務的修復。一個會話甚至啟動了自己的會話，以確保實驗運行能夠精確重播。

當網路錯誤同時停止了協調者和兩個子會話時，我輸入了「Riprova」（重試），每個會話在重做任何事情之前都檢查了已經完成的部分。整個過程中，目標始終是那張小顯示卡：一旦租賃完成，最後的模型擬合運行就在我的 GTX 1070 Ti 上進行。

何時單一會話就足夠 當任務可以在一個會話中完成，或者你無法像十個會話產生結果那樣快速審查時，就可以跳過協調者；我是所有結果的唯一審批者。我沒有測量 token 的花費，所以無法提供具體的成本數字。在長時間運行中，協調者自己的上下文會被填滿：我的在第二天就用完了，然後從摘要繼續運行。

第一步 選擇一個你即將執行的計畫，例如設計或預註冊，然後輸入類似「ultracode: try to refute this plan, one skeptic per claim, refute by default, read-only」（ultracode：嘗試反駁這個計畫，每個主張一個質疑者，預設反駁，唯讀）的內容。