一個人管十個 AI 同時幹活，是什麼體驗？
整理版優先睇
用 git worktree 同時跑多個 Claude Code，一個人管十個 AI 實戰唔係夢
呢篇文章係整理李不凱分享嘅工作流，講佢點樣用 git worktree 同時運行多個 Claude Code 實例，實現一個人管理多個 AI 任務。佢想解決嘅問題係：開發者得一個工作目錄，遇到緊急 bug 時冇辦法唔打斷進行中嘅重構，Git checkout 會搞冧曬上下文。
李不凱提出用 git worktree 將時間上串行嘅操作變成空間上並行：每個工作區獨立檢出一個分支，共享同一份 git 歷史，但檔案互相獨立，Claude Code 實例亦都獨立運行。整體結論係：呢個方法令到開發者從「寫 code 嘅人」變成「管 AI 嘅 leader」，只要每個任務有清晰邊界，就可以並行處理，效率翻倍。
文章強調呢啲方法唔係新發明，git worktree 本身係 2015 年 Git 2.5 嘅功能，本來用嚟解決人類團隊協作，而家直接用喺 AI 工作流，證明好多舊工具只要換個角度用，就可以大幅提升生產力。
- 用 git worktree 可以同時開多個獨立工作區，每個 Claude Code 實例各做各嘅任務，完全唔互相干擾。
- 做法好簡單：行 git worktree add 命令，將不同分支檢出到獨立目錄，然後喺每個目錄啟動 Claude Code。
- 串行變並行：唔使等一個任務完先開始另一個，而且切換工作區唔會丟失上下文，因為每個實例嘅檔案狀態係獨立嘅。
- 呢個做法令開發者由「一個人寫 code」變成「一個 leader 管理多個 AI agent」，結構上等同管一個細團隊，但無溝通成本。
- 成功嘅前提係每個任務有清晰邊界同明確目標，否則模糊需求落去並行工作流只會搞到更加亂。
一個工作區嘅困局，git worktree 就係答案
做開發成日會遇到呢種情況：Claude Code 幫你處理緊一個複雜重構，跑到一半突然殺出一個緊急 bug，今日一定要搞掂。你唔可以直接切分支——git checkout 會將成個工作區嘅檔案狀態都切過去，打斷曬進行中嘅任務，所有上下文全部報銷。你等重構跑完先處理 bug？緊急嘢唔等人。
如果用一個比喻嚟講，傳統 git checkout 似一部老式收音機，任何時候只可以鎖定一個頻道（一個分支）；git worktree 就好似擺咗一排收音機，每部鎖定一個頻道，各自播放，關一部對其他完全冇影響。技術原理其實好簡單：佢令你同時喺檔案系統檢出多個分支，將時間上串行嘅操作變成空間上並行嘅存在。
三個命令，即刻開始並行
假設你今日要同時處理兩個獨立任務：issue-12 係一個 bug，issue-13 係新功能。首先做一個設置：
echo "worktrees/" >> .gitignore
mkdir worktrees呢個 steps 將 worktrees/ 目錄加入 .gitignore，防止被 git 追蹤，但入面每個工作區嘅檔案仍然受 git 管控。然後為每個任務開一個工作區：
git worktree add worktrees/issue-12 main
git worktree add worktrees/issue-13 main執行完呢兩行，你已經有兩個獨立檔案目錄，都基於 main 分支，但完全隔離。跟住：入 worktrees/issue-12，開 fix/issue-12 分支，啟動 Claude Code，交代任務，等佢跑。你唔使等佢完，即刻入 worktrees/issue-13，開 feat/issue-13 分支，啟動另一個 Claude Code 實例，交代另一個任務。兩個實例可以同時跑。你可以隨時 cd 入去睇進展，或者去做第二啲嘢。等 issue-12 嘅 review 返嚟，再入返嗰個目錄，所有檔案狀態都喺度，上下文冇丟失。改完提交，再返去 issue-13 繼續。成個過程無等待、無切換成本、無「我頭先做到邊度」嘅迷失感。
由開發者變做 AI 管理者
李不凱分享呢個工作流嘅時候講咗一句好有意思：「未來社會嘅主流工作方式，可能就係一個人類管理者，管理住多個 agent 嚟幹活。」呢句聽落似係展望未來，但其實已經係現實——只係大部分人仲未意識到。當你可以同時跑三個 Claude Code 實例，你唔再係一個開發者，而係一個細團隊嘅 leader。一個實例喺度修 bug，一個寫新功能，一個寫文檔。你喺幾個工作區之間來回切換，做嘅嘢係：睇進展、拍決策、畀方向、處理卡點。呢個同管一個三人團隊喺結構上冇本質分別，差別在於你唔使開會、唔使等人、唔使擔心溝通成本。
呢件事畀我一個啟發：現有嘅工具同概念，好多可以直接遷移到 AI 工作流，唔使發明新輪子。提高效率嘅好多機會，其實匿埋喺「換個方式用舊工具」呢件事裏面。試一次就會上癮。下次你等緊 Claude Code 跑一個耗時任務嘅時候，唔好乾坐。開一個新 worktree，啟動第二個實例，將另一個任務都交出去。串行變並行，一倍時間，兩倍產出。
有人每個月喺 Claude Code 度燒幾萬美金。
唔係因為佢哋用 AI 寫咗幾多 code，而係因為佢哋同時開住十幾個 Claude Code 實例，7×24 小時，每個實例各自做各自嘅，互相唔幹擾。
第一個反應：點可能啊？唔同任務唔會撞到咩？
答案係：唔會。
而且呢件事，入門只需要三行 command。
一個令人頭痛嘅問題
做開發嘅人都遇過呢種情況。
Claude Code 正在幫你處理一個複雜嘅重構 task，跑到一半，走咗個緊急 Bug，今日一定要 fix。你唔可以直接 switch branch——git checkout 會將成個 working directory 嘅 file state 都 switch 過去，打斷緊進行緊嘅任務，所有 context 全部冇曬。
等重構跑完先處理 Bug？緊急嘅嘢唔等得。
呢個問題，Git 喺 2015 年已經有咗解決方法。只係大多數人唔知，或者話，直到 Claude Code 出現，先知道佢點解咁重要。
呢個解決方法叫 git worktree。
由「舊式收音機」到「擺滿收音機」
用一個比喻嚟解釋。
傳統的 git checkout，就好似一部舊式收音機。你個 project directory 任何時候，只可以 lock 一個頻道——一個 branch。想轉台，你要先停咗播緊嘅節目，重新調頻，然後仲要等一段時間緩衝（npm install，重新 compile）。
git worktree 唔同。
佢令你從同一個 .git repo 出發，喺外面擺上一排收音機——每部收音機 lock 一個唔同嘅頻道，各自播放，互不幹擾。想聽邊個就聽邊個。熄咗一部，對其他嘅冇任何影響。
技術原理只有一句說話：git worktree 令你可以同時喺 file system 度 checkout 多個 branch，將時間上串行嘅操作，變咗做空間上並行嘅存在。
所有 working directory 共享同一份 git history，但 file 互相獨立，branch 互相獨立，行喺裏面嘅 Claude Code 實例都互相獨立。
三個 command，開啟並行
假設你今日需要同時處理兩個獨立 task：issue-12 係個 Bug，issue-13 係個新功能。
先做一個設定：
echo "worktrees/" >> .gitignore
mkdir worktrees把 worktrees/ 呢個 container directory 加埋入 .gitignore，防止佢本身被 git 追蹤。裏面每個 working directory 嘅 file 仍然完整受 git 管控，唔受影響。
然後，為每個 task 各開一個 working directory：
git worktree add worktrees/issue-12 main
git worktree add worktrees/issue-13 main呢兩行執行完，你就會有兩個獨立嘅 file directory，都基於 main branch，但完全隔離。
接下來：
進 worktrees/issue-12，創建 fix/issue-12 branch，啟動 Claude Code，交代 task，等佢行。
唔等佢行完，即刻入 worktrees/issue-13，創建 feat/issue-13 branch，啟動另一個 Claude Code 實例，交代另一個 task。
兩個實例同時行緊。你可以隨時 cd 入去睇進展，亦都可以去做其他嘢。
等 issue-12 嘅 review 意見返嚟，再入嗰個 directory，所有 file state 都喺度，context 冇丟失。改完 commit，再返去 issue-13 繼續。
成個過程冇等，冇 switching cost，冇「我頭先做到邊度」嘅迷失感。
一個人管理多個 AI，係真實可行嘅
李不凱分享呢個 workflow 嘅時候，講咗一句話令我印象深刻：
未來社會嘅主流工作方式，可能就係一個人類管理者，管理住多個 agent 嚟做嘢。
呢句話聽落好似喺幻想未來，但其實佢描述嘅已經係現實——只係大多數人仲未意識到。
當你可以同時行三個 Claude Code 實例，你就唔再係一個 developer，你係一個小團隊嘅 leader。一個實例喺度 fix Bug，一個喺度寫新功能，一個喺度做 document。你喺幾個 working directory 之間來回 switch，做嘅嘢係：睇進展，拍決定，俾方向，處理 bottleneck。
呢個同管理一個三人團隊，結構上冇本質分別。
分別在於：你唔使開會，唔使等人，唔使擔心溝通成本。
當然，呢個都意味住你對每個 task 要夠清楚——講唔清楚嘅 task，AI 都做唔好。並行嘅前提係每個 task 有獨立嘅邊界、清晰嘅目標。模糊嘅 requirement 交俾並行 workflow，會乘以三倍混亂。
Git 本來就係為協同設計嘅
有一個細節我覺得好有意思。
git worktree 唔係為 AI 設計嘅。佢係 2015 年 Git 2.5 度加嘅一個功能，當時係為瞭解決人類團隊嘅 distributed 協同問題——多人同時喺唔同 branch 上工作，避免互相干擾。
而家，AI 嚟咗，同樣嘅問題出現咗：多個 AI 實例同時喺唔同 task 上工作，點避免互相干擾？
答案都係一樣：worktree，隔離，並行，最後 integrate。
由人人協同，到人機協同，底層 logic 冇變過。
呢件事俾我一個啟發：現有嘅工具同概念，好多都可以直接遷移到 AI workflow 度，唔需要發明新 wheel。提高效率嘅好多機會，藏喺「換個方式用舊工具」呢件事裏面。
試一次就會上癮。
下次當你喺等 Claude Code 行一個耗時 task 嘅時候，唔好齋坐。開一個新 worktree，啟動第二個實例，將另一個 task 都交出去。
串行變並行，一倍時間，兩倍 output。
2026.05.02 09:00
滬·趙巷
📌 聲明：本文由 AI 輔助完成
有人每個月在 Claude Code 上燒數萬美元。
不是因為他們用 AI 寫了多少代碼，而是因為他們同時跑着十幾個 Claude Code 實例，7×24 小時，每個實例各幹各的，互不干擾。
第一反應：這怎麼可能？不同任務不會打架嗎？
答案是：不會。
而且這件事，入門只需要三行命令。
一個讓人頭疼的問題
做開發的人都遇到過這種情況。
Claude Code 正在幫你處理一個複雜的重構任務，跑到一半，來了一個緊急 Bug，必須今天修。你不能直接切分支——git checkout 會把整個工作區的文件狀態都切過去，打斷正在進行的任務，所有上下文全毀。
等重構跑完再處理 Bug？緊急的事情不等人。
這個問題，Git 在 2015 年就有了解法。只是大多數人不知道，或者說，直到 Claude Code 出現，才知道它為什麼重要。
這個解法叫 git worktree。
從"老式收音機"到"擺滿收音機"
用一個比喻來解釋。
傳統的 git checkout，就像一台老式收音機。你的項目目錄在任何時候，只能鎖定一個頻道——一個分支。想換台，你得先停掉正在播的節目，重新調頻，然後還要等一段時間緩衝（npm install，重新編譯）。
git worktree 不一樣。
它讓你從同一個 .git 倉庫出發，在外面擺上一排收音機——每台收音機鎖定一個不同的頻道，各自播放，互不干擾。想聽哪個就聽哪個。關掉一台，對其他的沒有任何影響。
技術原理只有一句話：git worktree 讓你能同時在文件系統裏檢出多個分支，把時間上串行的操作，變成了空間上並行的存在。
所有工作區共享同一份 git 歷史，但文件互相獨立，分支互相獨立，跑在裏面的 Claude Code 實例也互相獨立。
三個命令，開啓並行
假設你今天需要同時處理兩個獨立任務：issue-12 是個 Bug，issue-13 是個新功能。
先做一個設置：
echo "worktrees/" >> .gitignore
mkdir worktrees把 worktrees/ 這個容器目錄加進 .gitignore，防止它本身被 git 追蹤。裏面每個工作區的文件仍然完整受 git 管控，不受影響。
然後，為每個任務各開一個工作區：
git worktree add worktrees/issue-12 main
git worktree add worktrees/issue-13 main這兩行執行完，你就有了兩個獨立的文件目錄，都基於 main 分支，但完全隔離。
接下來：
進 worktrees/issue-12，創建 fix/issue-12 分支，啓動 Claude Code，交代任務，讓它跑。
不等它跑完，立刻進 worktrees/issue-13，創建 feat/issue-13 分支，啓動另一個 Claude Code 實例，交代另一個任務。
兩個實例同時在跑。你可以隨時 cd 進去看進展，也可以去幹別的事情。
等 issue-12 的 review 意見回來，再進那個目錄，所有文件狀態都在，上下文沒丟。改完提交，再回到 issue-13 繼續。
整個過程沒有等待，沒有切換成本，沒有"我剛才做到哪了"的迷失感。
一個人管理多個 AI，是真實可行的
李不凱分享這個工作流的時候，說了一句話讓我印象深刻：
未來社會的主流工作方式，可能就是一個人類管理者，管理着多個 agent 來幹活。
這句話聽起來像在暢想未來，但其實它描述的已經是現實——只是大多數人還沒意識到。
當你能同時跑三個 Claude Code 實例，你就不再是一個開發者，你是一個小團隊的 leader。一個實例在修 Bug，一個在寫新功能，一個在做文檔。你在幾個工作區之間來回切換，做的事情是：看進展，拍決策，給方向，處理卡點。
這和管理一個三人團隊，在結構上沒有本質差別。
差別在於：你不需要開會，不需要等人，不需要擔心溝通成本。
當然，這也意味着你對每個任務要足夠清楚——說不清楚的任務，AI 也做不好。並行的前提是每個任務有獨立的邊界、清晰的目標。模糊的需求交給並行工作流，會乘以三倍混亂。
Git 本來就是為協同設計的
有一個細節我覺得很有意思。
git worktree 不是為 AI 設計的。它是 2015 年 Git 2.5 里加的一個功能，當時是為了解決人類團隊的分佈式協同問題——多人同時在不同分支上工作，避免互相干擾。
現在，AI 來了，同樣的問題出現了：多個 AI 實例同時在不同任務上工作，如何避免互相干擾？
答案還是一樣的：worktree，隔離，並行，最後集成。
從人人協同，到人機協同，底層邏輯沒有變過。
這件事給我一個啓發：現有的工具和概念，很多都可以直接遷移到 AI 工作流裏，不需要發明新輪子。提高效率的很多機會，藏在"換個方式用舊工具"這件事裏。
試一次就會上癮。
下次當你在等 Claude Code 跑一個耗時任務的時候，不要乾坐着。開一個新 worktree，啓動第二個實例，把另一個任務也交出去。
串行變並行，一倍時間，兩倍產出。
2026.05.02 09:00
滬·趙巷
📌 聲明：本文由 AI 輔助完成