Claude團隊藏了3年的并行技巧：1個Git功能讓AI編碼快2

20分鐘的任務，10分鐘就能跑完——前提是你知道Git有個叫worktree的功能。

這是Claude Code用戶最近挖出來的一個老技巧。不是新功能，Git 2015年就內(nèi)置了，但配合AI編程工具用，效果像是給單核CPU開了超線程。

問題很簡單：Claude Code一次只能干一件事。

你讓它寫6個模塊——認證、測試、儀表盤、API路由、中間件、集成測試——它老老實實排成隊，做完一個再下一個。哪怕這6件事完全不相關，沒有共享文件，沒有依賴關系。

串行執(zhí)行，線性等待。你的咖啡都涼了，它還在第一個模塊里打轉(zhuǎn)。

Git worktree的解法粗暴但有效：同一個倉庫，多個工作目錄，每個目錄獨立分支。就像給AI開了多個隔離的工位，互不打擾，同時開工。

手動版只需要15行shell

核心邏輯不復雜。建worktree、切分支、啟動Claude Code會話、等結果、清理現(xiàn)場。

但"能跑"和"能放心跑"是兩回事。作者列了幾條血淚教訓：

Ctrl+C殺進程，后臺可能殘留孤兒進程；忘記清理，worktree垃圾會堆滿倉庫；合并沖突發(fā)生時，腳本直接掛掉，沒有任何錯誤提示。

這些坑足夠讓大多數(shù)人放棄——直到有人把它包成了一個叫cast-parallel的自動化腳本。

自動化加了什么

干跑模式（dry run）先讓你預覽任務怎么拆分。腳本會讀一個叫"Agent Dispatch Manifest"的JSON塊，自動數(shù)批次，從中點切開。不滿意就用--split N手動指定切分位置。

相比手動版，自動化封裝了四件事：

進程管理用coproc，確保Ctrl+C能干凈收尾；每個worktree配獨立日志文件，方便事后審計；可選的數(shù)據(jù)庫日志記錄五個關鍵事件節(jié)點（啟動、流完成、整體完成、失敗、沖突）；合并沖突時自動暫停并提示，而不是默默崩潰。

如果數(shù)據(jù)庫logger沒配置，這些記錄會靜默跳過，不報錯。

但自動化解決不了所有問題。

作者在前頭就放了三個誠實警告：

批次依賴是硬門檻。如果第4批需要第2批的輸出，強行并行就是找死。你得先畫清楚依賴圖，獨立的才能并行。

邏輯沖突躲不掉。worktree隔離的是文件沖突，不是語義沖突。兩個會話改了同一個函數(shù)的不同地方，合并時該炸還是炸。作者認為這是feature——你寧可它炸出來，也不想它被自動"智能"合并成一鍋粥。

API賬單翻倍。兩個并發(fā)會話就是雙倍的token消耗。6批以上的大計劃，省下來的時間值回票價；3批以內(nèi)的小任務，不如串行慢慢跑。

什么時候值得用

作者給了一個粗糙但實用的判斷標準：

6批以上、批次間無依賴，wall-clock時間線性下降——20分鐘變10分鐘，30分鐘變15分鐘。4批以下，折騰worktree的開銷可能抵消收益。

這個閾值不是算出來的，是作者自己跑出來的經(jīng)驗值。你的代碼庫結構、網(wǎng)絡延遲、Claude的響應速度都會讓它浮動。

一個細節(jié)：腳本默認從中點切分，但用--split可以強制調(diào)整。比如6批任務，你可以前三后三，也可以四二開，取決于你對各批次耗時的估計。

Git worktree本身不是為AI設計的。它原本是給大型項目用的——比如一邊在main分支修bug，一邊在feature分支開發(fā)，不用來回git stash。

AI編程工具把它變成了"并行計算"的廉價替代方案。不需要K8s，不需要Docker，不需要改CI配置。15行shell，或者一個封裝好的腳本，就能讓單用戶的AI會話從單核變多核。

這有點像早年程序員用screen或tmux在遠程服務器上開多個會話——工具是老工具，用法是新用法。

最后留一個作者沒回答的問題：

如果Claude Code官方支持原生并行會話，這個worktree技巧會立刻過時嗎？還是說，隔離的工作目錄本身就有價值——畢竟就算官方支持多會話，你大概也不想讓它們互相踩文件？