git worktree 是什麼？讓 Claude Code、Codex 多開 agent 不打架，AI 產能的瓶頸從來不是模型

想像一下，你早上九點交代 AI 一個任務，按下 Enter。

然後呢？

三十五分鐘後它才跑完。

這不是誇飾。開發者 Owain Lewis 最近拍了一支影片叫 I Built an Agentic Software Factory with Codex and Claude Code，裡面示範的那個任務，實際跑了大約 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。做法很單純：把真實任務隨機分成「可以用 AI」跟「不能用 AI」兩組來比。受試者是 16 位資深開源開發者，246 個真實任務。

結果：可以用 AI 的那組，實際上慢了 19%。

更刺的是自我認知。這些人事前預測 AI 會讓他們快 24%，事後回想覺得快了 20%。實測是慢 19%。

先幫 METR 說句公道話：他們自己註明這份結果屬於 historical，用的是 2025 年初的工具，不代表今天。別拿這份研究去嘴「AI 沒用」。

而且我要誠實一點：這份研究並沒有證明「等待」就是元凶。 METR 自己也列了好幾種可能的解釋。

它真正打臉的只有一件事，但這件事很致命：

主觀覺得變快，跟整體真的變快，是兩回事。

那 39 個百分點的落差在告訴你，AI 工作流裡塞了很多你「感覺不到」的成本。讀 AI 寫出來的東西要成本、來回追問要成本、審查跟返工要成本。而乾等，是裡面最容易被低估的那一種，因為你在等的時候大腦是熱的、注意力是被綁住的，所以你以為自己在工作。

這裡要分清楚兩個完全不同的指標。

單張工單跑多快，跟你一天能完成幾張工單，是兩件事。前者，模型能力當然還是關鍵，模型越強，返工越少、驗收越省事。但當模型已經強到能自己跑完一整條流程之後，你一天的總產出就會卡在另一個地方：

你能同時開幾條互不干擾的線，以及你敢不敢離開現場。

這一題，台灣的工具機廠三十年前就解完了

講產線我就有話講了。

台灣中部那一票 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 導入的單位是觸發器而不是聊天視窗，可以搭著看。

零件二｜隔離：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 章節 就寫在那裡，是內建功能。

工程師的朋友看這裡，非工程師可以直接跳過這五行：

• 打 claude --worktree feature-auth（或簡寫 -w），它直接幫你開一個隔離的工作區，放在 .claude/worktrees/ 底下，自動開一條新分支。
• 換個名字、在另一個終端機再跑一次，那就是第二條線。你要開幾條開幾條。
• 子代理（subagent）可以在設定裡寫一行 isolation: worktree，從此它每次出勤都自帶工位。
• agent 跑的時候系統會把那個工位鎖住，避免被自動清理誤刪；沒有留下未提交工作的空工位，到期會自動掃掉。
• 桌面版更乾脆，每開一個新 session 就自動配一個工位。

一個人的自製流程，被官方直接產品化成預設行為。至少可以這樣說：隔離並行已經不是進階玩家的土法煉鋼，做工具的那一方，已經把它當成正式的使用情境在設計。

但這裡有個很多人會忽略的限制，你一定要知道。

worktree 只隔離程式碼資料夾，它不隔離大家共用的東西。

同一個資料庫、同一個測試環境、同一份 API 額度、同一個暫存區、同一把外部工具的鎖，只要幾條線共用，照樣會撞。這一點我等一下會用自己的慘案跟你說明，因為我就是這樣被雷到的。

零件三｜關卡：每一格都要有自動門檻

第三個零件我寫短，因為它值得單獨一篇，而我也真的寫過了。

一人多機能成立，關鍵是機台會自己停下來報警。放到 AI 產線上，就是每一格都要有一道自動的門檻：測試要過、審查要過、CI 要綠燈，不過就退回上一格重做。

放到行銷或營運也一樣：預算有沒有超過上限、有沒有踩到法務禁語、品牌語氣對不對、必填欄位有沒有漏。不過關就不准進下一關。

沒有這道門檻，你的並行只是「同時生產八份垃圾」。

想深入的話，可以看我寫過的怎麼幫 AI 設計一條完成條件明確的驗收迴圈，還有怎麼把手動品管寫成一個 Claude Code skill、讓 AI 每次自動跑。

Owain 的流程裡還用了一個很聰明的動作：讓一隻 agent 去審另一隻 agent 的產出。這招我在讓 AI 專門找自己碴（對抗式代理）那篇拆得更細。

還有一個細節我很喜歡。他把整條工作流寫成進版本控管的檔案，而不是每次隨口打 prompt。他的原話大意是：你用哪一隻 agent，其實沒有大家想的那麼重要，重要的是工作流。

這句話我完全同意。決定成敗的是模型外面那層編排，這件事我在Agent Harness 是什麼那篇談得更完整。

翻成生意人的話：SOP 進制度，不要進某個資深員工的腦袋。

我自己的產線，翻車現場：八隻 agent 共用暫存區與全域鎖

講別人容易，講自己的坑比較有說服力。

我這個部落格現在就是用一條 AI 產線在跑。前陣子我一次讓八篇文章並行生產，結果踩了兩個坑，而且巧得很，剛好就是上面那兩個零件缺一個死一個。

第一個坑：沒有隔離工位。

八隻 agent 共用同一個暫存資料夾。它們各自寫暫存腳本，檔名剛好取一樣，然後互相蓋掉。前一隻寫好的東西，後一隻直接洗掉，兩邊都覺得自己沒問題，出來的東西莫名其妙。這就是我剛剛講的那份 Google Sheet，只是換成 AI 在改。

第二個坑：沒有排隊機制。

我的生圖工具是一把全域的鎖，同一時間只能有一隻 agent 用。後面排隊的等不到，時間到就報一個逾時錯誤。

我看到錯誤訊息的第一反應是什麼？「這工具壞了。」

我還真的去查了半天工具的問題。查到後來才發現，工具好得很，是塞車。沒有排隊機制的系統，會把塞車回報成故障，然後你就會去修一個根本沒壞的東西。

我不是敗在 AI 不夠聰明。

我是敗在我把八條線塞進一個工位。

幾個煞車：factory 這個開源專案還不能拿去跟老闆提案

這篇如果你看到這裡覺得很興奮，先讓我潑幾盆水。這幾盆水有一半是 Owain 自己潑的，他在影片後半講得很誠實。

第一，那個開源專案還很早期。 他示範用的 factory 是 Rust 寫的、MIT 授權，我今天（2026-07-30）去查 GitHub API，91 顆星，2026 年 7 月 16 日才建立，也就是大約兩週前的東西，最近還在天天推更新。他自己在影片裡就說了 still very early stages，不適合現在所有人用。這是一個實驗，不是一個產品。別拿去跟老闆說我們要導入這個。 要玩，先用 GitHub Actions 做一個小的就好，他自己也說那條路完全可行。

第二，不是每張單都能進工廠。 適合外包出去的，是機械性的那一批：安全性套件升級、明確的 bug 修復、重複又煩人的瑣事。需要判斷、需要取捨、需要跟人吵架的，你自己來。

第三，文化沒配套會被濫用。 Owain 特別提醒，把這套引進團隊，你要有辦法讓大家不濫用這條管線。不然你只是把「隨便做」的速度加快了八倍。這件事的分寸怎麼抓，我在規則、agent、人這三種角色該怎麼擺那篇講過。

第四，成本沒有你想的那麼可怕，但也不是免費。 這套設計裡，常駐輪詢的部分是寫死的程式邏輯，沒工單的時候不燒 token，只有真的有活才叫 agent 起來做。所以它可以 24 小時掛著。但真的有工單的時候，一個跑 35 分鐘、還會叫子代理的任務，token 是實實在在在燒的。

這禮拜可以做的四件事：從算乾等時間到開兩條線

► 一、算一下你的「乾等時間」。
接下來三天，每次你叫 AI 做事，在旁邊記一筆：這次等了幾分鐘、這幾分鐘你在做什麼。三天之後你會有一個很難看的數字。那個數字就是你的改善空間。

► 二、挑一種爛單，做一次分流。
不用寫程式。拿你們最常見的一類需求單（客服的、行銷的、業務的都行），寫一個 300 字的模板：要達成什麼、背景是什麼、怎樣叫做完了。然後讓 AI 幫你把最近十張單，一張一張補成這個格式。你會馬上看出哪幾張其實根本不該開。

► 三、開兩條線，逼自己離開現場。
工程師版：claude --worktree 開兩個工位，一邊做功能一邊修 bug，中間去倒杯咖啡。
非工程師版：把「同時只能有一個人動的檔案」找出來（那份報價單、那份素材清單、那份文案 Google Doc），改成每人一份副本、最後統一合併。你會發現能同時跑的事情變多了。

► 四、把你的流程寫下來，存成檔案。
不是存在誰的腦袋裡，也不是每次重新交代。寫成一份可以被翻出來、被改、被版本控管的文件。這一步做完，你才真正擁有一條產線，而不是一個很會用 AI 的員工。

再往前看一步。

當 agent 越來越可靠，我們會忍不住把更大、更完整的任務交給它。所以真正會拉長的，是你敢交出去的任務範圍。高價值的那一批任務，會越來越常以半小時、一小時，甚至一個下午來計算。

到那個時候，能不能把工作切成互不干擾的並行任務、能不能設計一條讓任務自己往前走的產線、能不能忍住不去盯著螢幕，會比「你 prompt 寫得多漂亮」值錢得多。

這件事的另一半我在當執行變便宜，能力就換成誰定義得清楚那篇講過。你要練的不是打字，是調度。

從操作員，變成巡線的那個人。

常見問題 FAQ

Q1：git worktree 是什麼？跟直接開分支差在哪？
git worktree 讓同一個專案在你電腦上同時存在好幾個獨立的工作資料夾，每個在自己的分支上，共用同一份版本歷史。切換分支是「同一個資料夾換內容」，一次只能有一個狀態；worktree 是「多個資料夾同時存在」，可以真的並行。對 AI agent 來說，這個差別決定了你能不能同時開好幾隻。

Q2：怎麼判斷一張單能不能丟進並行產線？
看三個條件，缺一個就先別放進去：輸入夠清楚（有背景、有要達成什麼）、驗收可檢查（有人或程式能判定過不過）、失敗可回滾（做錯了能退回去，不會造成不可逆的損失）。三個都成立的單，通常也就是那些機械性、你自己做起來也很煩的活。

Q3：Claude Code 要怎麼一次跑好幾個任務？
依照 Claude Code 官方文件，用 claude --worktree <名字>（或 -w）就會建立一個隔離工作區並在裡面開工；換個名字在另一個終端機再跑一次，就是第二條線。子代理也可以設定成每次都自帶隔離工位。

Q4：什麼工作可以丟進去自動跑，什麼不行？
可以的：機械性、規則明確、驗收標準寫得出來的，例如套件升級、格式整理、明確的 bug 修復、重複的報表與上架。不行的：需要商業判斷、需要取捨、錯了代價很高的。Owain 自己也強調人的判斷仍在每一步。

Q5：這樣搞 token 成本會不會爆掉？
看你怎麼設計。輪詢等工單這件事可以用寫死的程式做，沒工作就不燒 token，所以可以整天掛著。但真的執行一個 35 分鐘、還會叫子代理和跑審查的任務，成本是實在的。給經營者一句實在話：別只問 token 貴不貴，去算「一份合格產出」的總成本，那等於 token 加上人工審查再加上返工。這個數字才是你該拿去比較的。

Q6：同時開很多 agent，品質會不會更難控？
會，所以順序不能反。並行的正確做法是先有工單、先有隔離、先有關卡，三個都到位了才開始放大數量。缺一個就衝到八條線，你得到的只是「同時出包八次」，而且更難查是誰出的包。

Q7：我們公司沒有工程師，這套跟我有關嗎？
有，而且第一步不用寫任何程式。客服：把「東西怪怪的」這種單，先過一層補齊模板再派工。行銷：需求單一律要寫清楚「怎樣叫做完了」才准開工。營運：把那份大家搶著改的報價表或素材清單，改成每人一份副本、最後統一合併。這三件事就是工單佇列、自動關卡跟隔離工位的最小版本。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。