你給 Claude 一個任務，它需要七分鐘。你會怎麼做？
大多數人會等待。他們看著終端機輸出滾動，也許滑滑手機。七分鐘後 Claude 完成了。他們檢視輸出，草擬修正，再傳回去。又七分鐘。一小時下來，實際工作只有四個循環。
直覺上會想優化 Claude — 更好的提示詞、更好的上下文、更少的 token 浪費。這很重要。但主要的瓶頸不在 Claude 的處理速度。而在那七分鐘裡，你什麼都沒做。
解決方法很明顯：在 Claude 運作時處理別的事情。執行平行工作階段的工具已經存在。但執行它們並不是難事。
回來才是難事。你剛才要求了什麼？你原本要檢查什麼？接下來要做什麼？你自己的上下文視窗是有限的，而且不像 Claude，沒有 token 計數器警告你它滿了。Claude Code 的創作者描述了他的工作流程：「我同時執行 5 個 Claude，將分頁標記為 1-5，並使用系統通知來知道何時有 Claude 需要輸入。」標記的分頁和通知。這就是人類方面的最新技術。
所以人們不切換。他們要嘛等待 — 要嘛走向另一個極端：讓 Claude 完全自主，透過 GitHub PR 評論進行互動。這能讓事情繼續進行，但以 PR 評論的節奏 — 你每小時檢查一次，而不是每七分鐘檢查一次。Claude 變成了一個你異步管理的同事，而不是一個你直接使用的工具。你浪費了大部分的處理能力。
問題不在於你無法執行多個工作階段。而在於你無法管理它們。
解決方案是外部化你的狀態。當你切換到另一個工作階段時，你需要恢復所需的一切都應該已經寫下來了。
這不是額外的工作。這是你本來就應該做的審查工作，只是在正確的時間完成。當 Claude 完成一個任務時，你審查差異，注意到一些事情，寫下修正。這些筆記就是你下一個循環的指示。將它們寫入一個持久的地方，而不是記在腦中，你就可以離開並回來而不會遺失。
你在審查時做的每一個註解，都少了一件你需要記住的事情。當你準備好發送時，指示就自己寫好了 — 它是你注意到的所有事情的總和。
在我建立這個工具之前，我試圖在 Zed 中手動完成。我已經調校好了 — 使用自訂的快捷鍵在面板之間切換焦點，左邊是差異，右邊是 TODO.md，底部是終端機面板，每個 Claude 工作階段都有一個分頁。我使用大綱選擇器跳到 TODO 中的正確工作階段標題。我寫了巨集。我進行了優化。它仍然在三個地方崩潰。
首先，筆記。你在一個面板中審查差異，需要在另一個面板的 TODO 中寫下修正。你按下快捷鍵跳到 TODO 面板，使用大綱選擇器找到正確的工作階段標題，滾動瀏覽訊息歷史記錄找到 WAIT 部分，然後輸入你的筆記。寫一行筆記需要四個動作。這足夠的摩擦力讓你停止這樣做。你將修正記在腦中。如果你切換到另一個工作階段：它們就消失了。
其次，通知。Claude 完成了，但什麼都沒發生。沒有 Dock 圖標角標，沒有聲音，編輯器裡也沒有任何指示。你必須輪詢 — 檢查每個終端機分頁，記住哪些正在運行。一半的時間你發現 Claude 已經完成了三分鐘，而你一直在閱讀已經被更改的程式碼。另一半的時間沒有變化，你根本不應該去查看。
第三，導航。兩個專案中有六個終端機分頁。哪個分頁是身份驗證重構？哪個是測試修復？你給它們命名了，但名稱無法告訴你哪些需要注意。你點擊分頁尋找那個正在等待權限批准的分頁，等你找到它時，你已經失去了你原本在做什麼的思路。
這個做法是可靠的。手動實現到處都存在漏洞。
這就是 jc 所做的。它是一個原生的 macOS 應用程式，用於協調跨專案的多個 Claude Code 工作階段。
每個工作階段在 TODO.md 檔案中都有一個區塊。一個 ### WAIT 標記分隔了你已發送的內容和你正在草擬的內容。當你審查差異並注意到一些事情時，按下一個鍵，輸入一個筆記，它就會出現在 WAIT 下方。當你閱讀 Claude 的終端機輸出時，也是一樣。當你瀏覽程式碼時，也是一樣。
當你準備好時，按下 Cmd-Enter，筆記就會被發送。它們會被儲存為對話歷史記錄中的一個編號訊息 — ### Message 0, ### Message 1，依此類推 — 所以當你幾小時或幾天後回來時，你可以確切地看到你問了什麼。你切換到另一個工作階段。
一個單一的快捷鍵會按照優先順序循環處理問題 — 先是權限提示，然後是未審查的差異，然後是未發送的筆記。你不是選擇一個工作階段；你選擇下一個問題。
每小時四個循環和十二個循環之間的差異，不是因為 Claude 變快了。而是因為你變好了。
jc 是開源的。如果你有改進，請讓你的 Claude 對我的程式碼提出 PR。我不接受人類編寫的程式碼。