> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # git worktree 是什麼？讓 Claude Code、Codex 多開 agent 不打架，AI 產能的瓶頸從來不是模型 - URL: https://growthhackers.tw/blog/git-worktree-parallel-ai-agents/ - Published: 2026-08-03T13:00:00.000Z - Updated: 2026-08-03T13:00:00.000Z - Description: git worktree 是什麼？它讓同一個專案在你電腦上同時展開多個各自獨立的工作資料夾，各在一條分支、共用版本歷史，是 Claude Code、Codex 多開 agent 不互相蓋掉檔案的前提。附 claude --worktree 用法、跟切分支差在哪，以及我八篇文章並行翻車的兩個坑。 - Author: Lewis wang - Tags: Claude Code, git worktree, AI agent, AI 工作流, Codex 想像一下，你早上九點交代 AI 一個任務，按下 Enter。 然後呢？ 三十五分鐘後它才跑完。 這不是誇飾。開發者 Owain Lewis 最近拍了一支影片叫 [I Built an Agentic Software Factory with Codex and Claude Code](https://www.youtube.com/watch?v=AbpyqAfxZ8c&ref=growthhackers.tw)，裡面示範的那個任務，實際跑了大約 35 分鐘。他說他手上典型的任務，agent 大概要跑 20 分鐘到一個小時。 慢的原因不是 AI 打字慢。是它在那 35 分鐘裡，改完程式碼還要自己叫子代理寫測試、自己做 code review（程式碼審查）、等 CI（持續整合）系統回饋、再回頭改。它把一個工程師三小時的流程壓進三十五分鐘。 所以問題來了。 **那三十五分鐘，你在幹嘛？** 老實講，大部分人的答案是：坐在旁邊看它跑。滑一下手機，看一眼終端機，再滑一下手機。 如果你問我，這才是這一波 AI 導入最大的浪費。而且你再換一個更聰明的模型，也救不了它。 > **先給答案：git worktree 是 Git 內建的功能，它讓同一個專案在你電腦上同時展開多個獨立的工作資料夾，每個各在一條分支、檔案互不干擾，但共用同一份版本歷史。它是 Claude Code、Codex 能同時開好幾隻 agent 而不互相蓋掉檔案的前提。想直接看指令，跳到「零件二」。** ## 真正變的不是 AI 的智商，是時間結構：從對話框到工單 我們先把一件事講清楚。 以前你用 ChatGPT，是「問一句、答一句」。輸入到輸出之間隔三十秒，你當然坐在那裡等，因為等待成本很低。 現在你用 Claude Code、Codex 這類 agent，是「交代一件事、它離線做完再回來」。輸入到輸出之間隔三十五分鐘。 同樣的等待姿勢，成本差了七十倍。 這就是我說的「時間結構變了」。工具的形狀從對話框變成了工單，可是大多數人的工作習慣還停在對話框那一格。 講到這裡，我要放一份對「AI 很有用」這個論點很不利的證據。 2025 年 7 月，非營利研究機構 METR 發表了一份隨機對照試驗 [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?ref=growthhackers.tw)。做法很單純：把真實任務隨機分成「可以用 AI」跟「不能用 AI」兩組來比。受試者是 16 位資深開源開發者，246 個真實任務。 結果：可以用 AI 的那組，實際上**慢了 19%**。 更刺的是自我認知。這些人事前預測 AI 會讓他們快 24%，事後回想覺得快了 20%。實測是慢 19%。 先幫 METR 說句公道話：他們自己註明這份結果屬於 historical，用的是 2025 年初的工具，不代表今天。別拿這份研究去嘴「AI 沒用」。 而且我要誠實一點：**這份研究並沒有證明「等待」就是元凶。** METR 自己也列了好幾種可能的解釋。 它真正打臉的只有一件事，但這件事很致命： **主觀覺得變快，跟整體真的變快，是兩回事。** 那 39 個百分點的落差在告訴你，AI 工作流裡塞了很多你「感覺不到」的成本。讀 AI 寫出來的東西要成本、來回追問要成本、審查跟返工要成本。而乾等，是裡面最容易被低估的那一種，因為你在等的時候大腦是熱的、注意力是被綁住的，所以你以為自己在工作。 這裡要分清楚兩個完全不同的指標。 **單張工單跑多快**，跟**你一天能完成幾張工單**，是兩件事。前者，模型能力當然還是關鍵，模型越強，返工越少、驗收越省事。但當模型已經強到能自己跑完一整條流程之後，你一天的總產出就會卡在另一個地方： **你能同時開幾條互不干擾的線，以及你敢不敢離開現場。** ![一條線你在旁邊等，多條線你只管調度：同樣的時間，產出差在能開幾條互不干擾的線。](https://growthhackers.tw/content/images/2026/07/inline-waiting-vs-parallel-v1.png) 一條線你在旁邊等，多條線你只管調度：同樣的時間，產出差在能開幾條互不干擾的線。 ## 這一題，台灣的工具機廠三十年前就解完了 講產線我就有話講了。 台灣中部那一票 CNC 加工廠、工具機廠，早就不會讓一個作業員站在一台機台前面，盯著它跑完一個 40 分鐘的加工循環。太浪費了。 他們的做法叫「一人多機」。一個作業員同時顧好幾台，加工的時候他去巡下一台、去看料、去處理異常。人不是機台的保母，人是巡線的。 問題是，一人多機不是「叫作業員多走幾步」就能成立。它要有三個前提： **第一，自動送料。** 機台跑完這一件，下一件要自己上去，不能等人搬。 **第二，機台彼此獨立。** A 機出狀況不能連累 B 機，兩台不能共用同一塊夾治具。 **第三，異常自動停機報警。** 刀具斷了、尺寸跑掉了，機台自己停下來亮燈，不能默默做出一整籃廢品。 你把這三個前提，一個一個對回 AI agent，答案就出來了： - 自動送料 = **工單佇列，加上會自己拉下一張單進站的觸發器** - 機台彼此獨立 = **隔離工位** - 異常自動停機 = **自動關卡** Owain 講的「軟體工廠」，拆開來其實就是這三個零件。他自己也講，這一整套跟 CI/CD 是同一個道理：以前我們手動部署，緊張、容易錯、每次都不一樣；後來把部署變成一條自動的管線，資淺跟資深工程師走的是同一條線，品質的底線就被整個抬起來。 現在輪到「寫」這件事被抬起來。 ## 零件一｜工單佇列：先做進料檢驗（triage 分流），再上線 Owain 的做法是拿 GitHub issues 當工單佇列的來源，靠 **label（標籤）** 決定每張單現在該進哪一關。掛上 `ready-for-spec` 這個標籤，一個常駐程式輪詢到了，就去跑分流（triage）工作流；掛上 `ready-to-implement`，就去跑實作工作流。 工單自己會在看板上往前走，人只負責決定「這張要不要放行」。 這裡最值錢的是**分流那一關**。 他在影片裡開了一張很爛的工單，內容大概就是「factory 的常駐程式半夜會死掉」。沒有描述、沒有重現步驟、沒有驗收標準。他說得很直白：這種單丟給 agent，它會很認真地做，但它根本不知道自己該做什麼。 於是分流 agent 先上場。它去讀了整份程式碼、自己重現了 bug、找出原因，然後把工單改寫成有明確產出（outcome）、背景（context）、驗收標準（acceptance criteria）的規格，再推到下一格。 看到這裡，你如果是做電商、做行銷、開公司的，應該已經笑出來了。 因為這根本就是你每天在收的單。 客服系統裡躺著一堆「東西怪怪的」「出貨很慢」「跟我想的不一樣」。行銷部門收到業務丟一句「幫我做個活動頁」，做完了才被說「我要的不是這個」。設計師收到「幫我改一下，感覺不對」。 你的團隊之所以低效，很多時候不是執行力差。是你讓一堆沒有驗收標準的單直接上線。 以前這種爛單只能靠一個資深的人在中間翻譯，那個人就變成瓶頸。現在你可以讓一層自動的分流先跑：把單補齊、把問句補上、把「怎樣叫做完了」寫清楚，補不齊的就退回去問。這件事跟寫不寫程式無關，任何一個收單的部門都能做。 順帶一提，這種「靠事件自己觸發、不靠人打字」的模式，我之前寫過一篇專門在講[為什麼 AI 導入的單位是觸發器而不是聊天視窗](https://growthhackers.tw/blog/ai-agent-triggered-not-chat/)，可以搭著看。 ![工單佇列：從進料、規格、實作、驗收到完成，每一關都有自動門檻，不過關就退回上一格。](https://growthhackers.tw/content/images/2026/07/inline-ticket-pipeline-v1.png) 工單佇列：從進料、規格、實作、驗收到完成，每一關都有自動門檻，不過關就退回上一格。 ## 零件二｜隔離：git worktree 是什麼、怎麼用，為什麼它是並行的前提 好，來到這篇的技術核心。非工程師的朋友別跳過，這段我用你聽得懂的話講。 先講痛點。 檔期要上了，你、企劃、業務三個人同時開著同一份報價 Google Sheet 在改。你改 A 欄、他刪 B 列、另一個人整張重排。半小時後打開來，誰也不知道現在哪一版是對的。 這就是「共用同一個工作區」的下場。人只有三個就這樣了，你想像一下八隻 AI agent 同時在同一個資料夾裡動手。 **git worktree（工作樹）是 Git 內建的功能，它讓同一個專案倉庫，在你的電腦上同時展開好幾個各自獨立的工作資料夾，每個資料夾在自己的分支上，檔案互不相干，但共用同一份版本歷史。** 用剛剛的比喻：每個人各自複製一份去改，改完再合併回主檔，而且系統一直知道大家是從同一個母版分出去的，誰動了哪一格都查得到。三個人再也不用擠同一份 Google Sheet。 以前開發者要平行做兩件事，得在同一個資料夾裡切換分支，切一次就要重新裝套件、重新跑環境，還常常把改到一半的東西帶著走。就像你每次換案子，都要把整張桌子清空重擺。 現在 worktree 直接給你好幾張桌子。 ### git worktree 跟切分支（branch）差在哪？三行指令看懂 切分支是「同一張桌子換一批文件」，一次只能存在一個狀態。worktree 是「多張桌子同時攤開」，可以真的並行。指令只要記三行： - `git worktree add ../project-feature-a -b feature-a`：開一張新桌子，順便開一條新分支。 - `git worktree list`：看你現在總共攤開了幾張桌子。 - `git worktree remove ../project-feature-a`：收掉不要的那張。 會這三行，你就能手動幫每一隻 agent 配一個工位了。 而這件事，已經不是某個 YouTuber 的私房技巧了。用白話講：**Claude Code 現在能自動幫每一隻 agent 開一間獨立工作室，不需要你手動複製專案。** 翻 [Claude Code 官方文件的 worktrees 章節](https://code.claude.com/docs/en/worktrees?ref=growthhackers.tw) 就寫在那裡，是內建功能。 工程師的朋友看這裡，非工程師可以直接跳過這五行： - 打 `claude --worktree feature-auth`（或簡寫 `-w`），它直接幫你開一個隔離的工作區，放在 `.claude/worktrees/` 底下，自動開一條新分支。 - 換個名字、在另一個終端機再跑一次，那就是第二條線。你要開幾條開幾條。 - 子代理（subagent）可以在設定裡寫一行 `isolation: worktree`，從此它每次出勤都自帶工位。 - agent 跑的時候系統會把那個工位鎖住，避免被自動清理誤刪；沒有留下未提交工作的空工位，到期會自動掃掉。 - 桌面版更乾脆，每開一個新 session 就自動配一個工位。 一個人的自製流程，被官方直接產品化成預設行為。至少可以這樣說：隔離並行已經不是進階玩家的土法煉鋼，做工具的那一方，已經把它當成正式的使用情境在設計。 但這裡有個很多人會忽略的限制，你一定要知道。 **worktree 只隔離程式碼資料夾，它不隔離大家共用的東西。** 同一個資料庫、同一個測試環境、同一份 API 額度、同一個暫存區、同一把外部工具的鎖，只要幾條線共用，照樣會撞。這一點我等一下會用自己的慘案跟你說明，因為我就是這樣被雷到的。 ![git worktree 隔離示意：共用同一份版本歷史，但每隻 agent 各自擁有獨立的工作資料夾。](https://growthhackers.tw/content/images/2026/07/inline-worktree-isolation-v1.png) git worktree 隔離示意：共用同一份版本歷史，但每隻 agent 各自擁有獨立的工作資料夾。 ## 零件三｜關卡：每一格都要有自動門檻 第三個零件我寫短，因為它值得單獨一篇，而我也真的寫過了。 一人多機能成立，關鍵是機台會自己停下來報警。放到 AI 產線上，就是每一格都要有一道自動的門檻：測試要過、審查要過、CI 要綠燈，不過就退回上一格重做。 放到行銷或營運也一樣：預算有沒有超過上限、有沒有踩到法務禁語、品牌語氣對不對、必填欄位有沒有漏。不過關就不准進下一關。 沒有這道門檻，你的並行只是「同時生產八份垃圾」。 想深入的話，可以看我寫過的[怎麼幫 AI 設計一條完成條件明確的驗收迴圈](https://growthhackers.tw/blog/ai-agent-verification-workflow/)，還有[怎麼把手動品管寫成一個 Claude Code skill、讓 AI 每次自動跑](https://growthhackers.tw/blog/claude-code-skill-verification-loop/)。 Owain 的流程裡還用了一個很聰明的動作：讓一隻 agent 去審另一隻 agent 的產出。這招我在[讓 AI 專門找自己碴（對抗式代理）](https://growthhackers.tw/blog/adversarial-agents-ai-critic-loop/)那篇拆得更細。 還有一個細節我很喜歡。他把整條工作流寫成**進版本控管的檔案**，而不是每次隨口打 prompt。他的原話大意是：你用哪一隻 agent，其實沒有大家想的那麼重要，重要的是工作流。 這句話我完全同意。決定成敗的是模型外面那層編排，這件事我在[Agent Harness 是什麼](https://growthhackers.tw/blog/what-is-agent-harness/)那篇談得更完整。 翻成生意人的話：SOP 進制度，不要進某個資深員工的腦袋。 ## 我自己的產線，翻車現場：八隻 agent 共用暫存區與全域鎖 講別人容易，講自己的坑比較有說服力。 我這個部落格現在就是用一條 AI 產線在跑。前陣子我一次讓八篇文章並行生產，結果踩了兩個坑，而且巧得很，剛好就是上面那兩個零件缺一個死一個。 **第一個坑：沒有隔離工位。** 八隻 agent 共用同一個暫存資料夾。它們各自寫暫存腳本，檔名剛好取一樣，然後互相蓋掉。前一隻寫好的東西，後一隻直接洗掉，兩邊都覺得自己沒問題，出來的東西莫名其妙。這就是我剛剛講的那份 Google Sheet，只是換成 AI 在改。 **第二個坑：沒有排隊機制。** 我的生圖工具是一把全域的鎖，同一時間只能有一隻 agent 用。後面排隊的等不到，時間到就報一個逾時錯誤。 我看到錯誤訊息的第一反應是什麼？「這工具壞了。」 我還真的去查了半天工具的問題。查到後來才發現，工具好得很，是塞車。**沒有排隊機制的系統，會把塞車回報成故障**，然後你就會去修一個根本沒壞的東西。 我不是敗在 AI 不夠聰明。 我是敗在我把八條線塞進一個工位。 ## 幾個煞車：factory 這個開源專案還不能拿去跟老闆提案 這篇如果你看到這裡覺得很興奮，先讓我潑幾盆水。這幾盆水有一半是 Owain 自己潑的，他在影片後半講得很誠實。 **第一，那個開源專案還很早期。** 他示範用的 [factory](https://github.com/owainlewis/factory?ref=growthhackers.tw) 是 Rust 寫的、MIT 授權，我今天（2026-07-30）去查 GitHub API，91 顆星，2026 年 7 月 16 日才建立，也就是大約兩週前的東西，最近還在天天推更新。他自己在影片裡就說了 still very early stages，不適合現在所有人用。**這是一個實驗，不是一個產品。別拿去跟老闆說我們要導入這個。** 要玩，先用 GitHub Actions 做一個小的就好，他自己也說那條路完全可行。 **第二，不是每張單都能進工廠。** 適合外包出去的，是機械性的那一批：安全性套件升級、明確的 bug 修復、重複又煩人的瑣事。需要判斷、需要取捨、需要跟人吵架的，你自己來。 **第三，文化沒配套會被濫用。** Owain 特別提醒，把這套引進團隊，你要有辦法讓大家不濫用這條管線。不然你只是把「隨便做」的速度加快了八倍。這件事的分寸怎麼抓，我在[規則、agent、人這三種角色該怎麼擺](https://growthhackers.tw/blog/ai-agent-team-division-of-labor/)那篇講過。 **第四，成本沒有你想的那麼可怕，但也不是免費。** 這套設計裡，常駐輪詢的部分是寫死的程式邏輯，沒工單的時候不燒 token，只有真的有活才叫 agent 起來做。所以它可以 24 小時掛著。但真的有工單的時候，一個跑 35 分鐘、還會叫子代理的任務，token 是實實在在在燒的。 ## 這禮拜可以做的四件事：從算乾等時間到開兩條線 **► 一、算一下你的「乾等時間」。** 接下來三天，每次你叫 AI 做事，在旁邊記一筆：這次等了幾分鐘、這幾分鐘你在做什麼。三天之後你會有一個很難看的數字。那個數字就是你的改善空間。 **► 二、挑一種爛單，做一次分流。** 不用寫程式。拿你們最常見的一類需求單（客服的、行銷的、業務的都行），寫一個 300 字的模板：要達成什麼、背景是什麼、怎樣叫做完了。然後讓 AI 幫你把最近十張單，一張一張補成這個格式。你會馬上看出哪幾張其實根本不該開。 **► 三、開兩條線，逼自己離開現場。** 工程師版：`claude --worktree` 開兩個工位，一邊做功能一邊修 bug，中間去倒杯咖啡。 非工程師版：把「同時只能有一個人動的檔案」找出來（那份報價單、那份素材清單、那份文案 Google Doc），改成每人一份副本、最後統一合併。你會發現能同時跑的事情變多了。 **► 四、把你的流程寫下來，存成檔案。** 不是存在誰的腦袋裡，也不是每次重新交代。寫成一份可以被翻出來、被改、被版本控管的文件。這一步做完，你才真正擁有一條產線，而不是一個很會用 AI 的員工。 --- 再往前看一步。 當 agent 越來越可靠，我們會忍不住把更大、更完整的任務交給它。所以真正會拉長的，是你**敢交出去的任務範圍**。高價值的那一批任務，會越來越常以半小時、一小時，甚至一個下午來計算。 到那個時候，能不能把工作切成互不干擾的並行任務、能不能設計一條讓任務自己往前走的產線、能不能忍住不去盯著螢幕，會比「你 prompt 寫得多漂亮」值錢得多。 這件事的另一半我在[當執行變便宜，能力就換成誰定義得清楚](https://growthhackers.tw/blog/code-is-free-become-the-driver/)那篇講過。你要練的不是打字，是調度。 從操作員，變成巡線的那個人。 ## 常見問題 FAQ **Q1：git worktree 是什麼？跟直接開分支差在哪？** git worktree 讓同一個專案在你電腦上同時存在好幾個獨立的工作資料夾，每個在自己的分支上，共用同一份版本歷史。切換分支是「同一個資料夾換內容」，一次只能有一個狀態；worktree 是「多個資料夾同時存在」，可以真的並行。對 AI agent 來說，這個差別決定了你能不能同時開好幾隻。 **Q2：怎麼判斷一張單能不能丟進並行產線？** 看三個條件，缺一個就先別放進去：輸入夠清楚（有背景、有要達成什麼）、驗收可檢查（有人或程式能判定過不過）、失敗可回滾（做錯了能退回去，不會造成不可逆的損失）。三個都成立的單，通常也就是那些機械性、你自己做起來也很煩的活。 **Q3：Claude Code 要怎麼一次跑好幾個任務？** 依照 [Claude Code 官方文件](https://code.claude.com/docs/en/worktrees?ref=growthhackers.tw)，用 `claude --worktree <名字>`（或 `-w`）就會建立一個隔離工作區並在裡面開工；換個名字在另一個終端機再跑一次，就是第二條線。子代理也可以設定成每次都自帶隔離工位。 **Q4：什麼工作可以丟進去自動跑，什麼不行？** 可以的：機械性、規則明確、驗收標準寫得出來的，例如套件升級、格式整理、明確的 bug 修復、重複的報表與上架。不行的：需要商業判斷、需要取捨、錯了代價很高的。Owain 自己也強調人的判斷仍在每一步。 **Q5：這樣搞 token 成本會不會爆掉？** 看你怎麼設計。輪詢等工單這件事可以用寫死的程式做，沒工作就不燒 token，所以可以整天掛著。但真的執行一個 35 分鐘、還會叫子代理和跑審查的任務，成本是實在的。給經營者一句實在話：別只問 token 貴不貴，去算「一份合格產出」的總成本，那等於 token 加上人工審查再加上返工。這個數字才是你該拿去比較的。 **Q6：同時開很多 agent，品質會不會更難控？** 會，所以順序不能反。並行的正確做法是先有工單、先有隔離、先有關卡，三個都到位了才開始放大數量。缺一個就衝到八條線，你得到的只是「同時出包八次」，而且更難查是誰出的包。 **Q7：我們公司沒有工程師，這套跟我有關嗎？** 有，而且第一步不用寫任何程式。客服：把「東西怪怪的」這種單，先過一層補齊模板再派工。行銷：需求單一律要寫清楚「怎樣叫做完了」才准開工。營運：把那份大家搶著改的報價表或素材清單，改成每人一份副本、最後統一合併。這三件事就是工單佇列、自動關卡跟隔離工位的最小版本。 --- **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。