你不是不夠努力——你是用單線工作的習慣在做多線工作。
Parallel AI 要運作得好，需要從心態到機制的一整套重新設計。
接案工程師的多專案管理困境：三個案子做不完一個
小林是自由接案前端工程師，手上有三個案子同時在跑：
- A 案：某電商結帳流程改版，兩週內要上線（急）
- B 案：SaaS 公司的 Dashboard 新功能，月底要看到雛形（中期）
- C 案：長期客戶的部落格 SEO 優化（彈性）
星期一早上打開電腦，三個案子的訊息都在閃——A 案 PM 把結帳 UI 的設計稿傳過來、B 案技術主管丟了新的 API 規格、C 案客戶問上週看的頁面結果出來沒。
他想了三十秒：「先處理急的，A 案。」
開了 Claude Code 跟 AI 一起做結帳流程，兩小時過去進度不錯。
起身倒水時看到 B 案主管在 Slack 追進度，心虛了一下，想說下午切過去做 B 案。
下午真的切了，但光是讓自己「回到 B 案的狀態」就花了快一個小時——重新讀技術文件、把上次寫到一半的程式碼看懂、想起來今天原本要加什麼功能。
剛要動手，A 案 PM 又敲他：API 規格變了，麻煩看一下。
他心想「這十分鐘就能處理」，又切回 A 案。
結果那個「十分鐘」耗了一個小時——改動牽動好幾個元件。
晚上九點結算今天的產出：A 案只推進了計畫的一半，B 案打開五分鐘又關上，C 案完全沒碰。
他盯著螢幕嘆氣：「我明天要更早起、要更專注、不能再被打斷。」
但這個結論，方向是錯的。
小林卡住的原因不是不夠努力，是工作方式——他有三個案子，但還是用做一個案子的方式在工作。
一次只處理一件事、一個時段只給一個案子。
AI agent 本來可以讓他同時推進三個，但他完全沒把這個能力打開。
這篇文章要講的，就是一個個人工作者（接案工程師、獨立開發者、知識工作者）要怎麼從「一次做一件」升級到「同時跑三個」。
這個轉變不是靠努力，是靠重新設計工作方式。
AI agent 平行開發是什麼：同時跑多個 agent 的核心觀念
先說一個你可能沒意識到的事：「一次做一件事」是人類身體的物理限制。
你的大腦結構就是一次只能深度處理一個任務。
幾萬年來，我們用的工作方式——專注在一個目標上、把它做完、再做下一個——都是為了配合這個生理限制。
所以當小林早上想「今天先做哪個」，然後挑一個、專心做，這個直覺並沒有錯。
在沒有 AI 的時代，那是人類能做事的最高效方式。
問題是，這個直覺的前提在 AI agent 時代已經開始鬆動了。
AI agent 讓你的工作時間可以疊加
以前的工作場景是這樣的：
你要寫一個結帳元件，就得自己坐下來，打開編輯器，一行一行打字。
從讀需求文件到寫完元件、測試、commit，中間所有時間你都得在場。
你的工作產出速度，等於你自己打字加思考的速度。
但現在有 AI agent 之後，場景變了：
你要寫一個結帳元件，你把需求交給 Claude Code，花五到十分鐘講清楚要什麼、邊界在哪、用哪些套件。
然後 AI 開始實作，它可能花十五到三十分鐘寫出一個初版。
這段時間你在幹嘛？
如果你還是用「一次做一件事」的習慣，你就坐在那邊盯著 terminal 看 AI 輸出——這樣你的產出速度跟純手工寫差不多，有時還更慢，因為你多了「等 AI」的空窗。
但如果你在 A 案的 AI 在跑的時候，切去開另一個 agent 做 B 案呢？
那你的工作時間就變成兩倍——兩個 agent 同時在推進不同任務，你只是偶爾切進去看看、給個指示、確認方向。
這就是 AI agent 平行開發（parallel AI workflows）的起點：讓 AI agent 的工作時間跟你自己的工作時間疊加起來，而不是排成一條線。
「排成一條線」的意思是：你動手一段、AI 跑一段、你檢查一段、再開下一個任務。
所有時段接在一起，總時間等於每一段加總。
「疊加」的意思是：你下完指令給 A 案的 agent 後，不等它跑完，直接切去 B 案下另一個指令。
這時候兩個 agent 在各自的時間軸上同步工作，等你的注意力再切回 A 案時，它可能已經跑完了。
看圖就很清楚：同樣一段工作時間裡，線性模式要把三個案子的時段接成一條長線，疊加模式則是把三個案子的時間軸重疊在一起。
你自己動手的時間沒有變多（還是你一個人），但 AI 可以在三條線上各自跑。
真正改變的是產出公式：從「你動手的時間」變成「你動手的時間 + 所有 agent 各自跑的時間」。
你一天的上限，不再只被你自己的工作時數決定。
很多人以為 AI agent 平行開發是「AI 幫我加速寫程式」，所以更快做完一個案子。
但它真正的槓桿點不在單案加速，而在同時推進多個案子。
小林的三個案子，A 急、B 中期、C 彈性——這三個案子本來就不需要「一個做完才能做下一個」。
它們只是因為他用單線工作的習慣，硬被排成一條線而已。
把它們從一條線攤成三條線，才是 parallel 的重點。
但這個轉換不會自動發生——你會發現第一次這樣跑，狀態比以前更亂，不是更清晰。
原因不在 AI，在你自己。
心流被打斷的代價：Parallel AI 的切換成本與 Context Drift
人類的大腦還是只能一次專注一件事。
你開了三個 agent，它們不會自己協調，你要在它們之間切來切去。
每切一次，你都要在腦袋裡重新載入一次那個案子的脈絡：需求是什麼、做到哪、剛剛 AI 寫的程式碼合不合理、下一步要做什麼。
這個「重新載入」的成本，在平行工作下會被放大很多倍。
線性工作時你一天可能切 5 次案子——早上 A、下午 B、晚上 C，每次切換都要花時間重新進入狀態，但一天五次而已，總損失還在可承受範圍。
平行工作時不一樣。
你開著三個 agent，每個都在跑，你會忍不住想「去看一下 A 案進度怎樣」「B 案那邊有沒有卡住」「C 案剛剛產出的東西對不對」——一天切 30 次都不誇張。
5 次變 30 次，這就是大多數人第一次跑 parallel 會覺得「比原本還累」的根本原因。
而這個「累」，可以拆成兩個原因——一個在你這邊（心流被打斷），一個在 AI 那邊（Context Drift）。
但在拆解這兩個原因之前，先破除一個常見的誤解。
平行不是多工：先破除一個誤解
聽到「同時跑三個 agent」，很多人第一反應是：「這不就是 multitasking 嗎？」
但平行工作跟多工不是同一件事——這個區分很重要，搞混了會直接放棄。
多工是你的大腦硬切好幾件事，每切一次都有成本、每件都沒做好。
多工是負面詞，因為人腦本來就不適合多工。
疊加不是多工。
疊加是讓 AI 在你不盯的時候繼續工作，你的注意力每個時刻還是集中在一件事上——只是在不同 agent 之間換得比較頻繁。
換句話說：多工是人類硬切，切一次傷一次；疊加是 AI 在背景跑，你只在必要時切進去。
兩者表面上都是「同時做好幾件事」，但內部運作完全不同。
那為什麼還是會累？因為「切進去」這個動作本身就有代價——這就是接下來兩個原因要講的事。
原因一：心流被打斷，平均要 23 分鐘才能回神
心流（flow）是一種深度專注的狀態——你完全沉浸在當下的任務裡，時間感會變慢，解決問題的速度會變快。
這個狀態進入要時間。
研究顯示，一般人從開始工作到進入心流，平均要 15 到 25 分鐘。
而被打斷之後要再回到同樣的深度，平均需要 23 分鐘。
這是「切換成本」真正的意思——不是切換那一秒本身有什麼代價，是切換之後你要花 23 分鐘才能重新進入深度工作狀態。
回到剛剛的數字：平行工作一天切 30 次，每次扣 23 分鐘，理論上要花 11.5 小時才能補回所有的心流損失。
你一天工作時間根本沒這麼多。
結果就是：你整天在切，但每一次切進去都還沒真正進入狀態，就又切走了。
你的大腦從頭到尾沒有進入過深度專注一次。
這就是為什麼很多人跑 parallel 的第一反應是「比原本還累」——不是你做的事變多了，是你再也沒進入過心流。
原因二：Context Drift，AI 那邊也會漸漸走偏
心流被打斷是你這邊的問題。
AI 那邊也有一個對應的問題，叫 Context Drift（上下文漂移）。
每個 AI agent 在一段對話裡會維持一組「當前理解」——它記得你要做什麼、上次討論到哪、有哪些約束條件。
但隨著對話變長，這個理解會慢慢走樣。
可能是你中途加了個新需求，但 agent 還帶著舊需求在寫；可能是你改了架構決策，但 agent 過了幾輪又回到舊的寫法。
單一 agent 在長對話裡自己就會 drift，這是 LLM 的本質問題。
到了平行工作場景，drift 的放大效應出現了：
- 你開著三個 agent，每個都在漂。
- 你中間切去 A 案時，B 案的 agent 還繼續在跟自己的 drift 對話（如果你沒停它的話）。
- 你切回 B 案時，它可能已經「走了很遠」——產出的程式碼跟你原本期待的完全不同。
所以你不只要管自己的心流，還要管三個 agent 各自的脈絡準不準。
兩個原因疊加：切換成本 × Context Drift 的放大效應
分開看，這兩個原因各自的代價是可以估算的：
- 心流成本：每次切換損失 23 分鐘
- Drift 成本：每 N 輪對話 agent 可能開始偏離，要花時間拉回來
疊加起來，它們會互相放大：
- 因為 drift，你更想去檢查每個 agent ——切換頻率上升——心流成本爆炸
- 因為心流被打斷，你判斷力下降，回到 agent 時沒發現它其實已經 drift——產出品質下降，你又要花更多時間救回來
這就是「第一次跑 parallel 會比原本還累」的技術解釋。
不是平行工作本身有問題，是你沒有任何機制去處理這兩個成本。
接下來四個做法，就是專門用來處理它們的。
降低 AI agent 切換成本的 4 個機制
接下來要講的四個機制，都是用來處理前面那兩個成本——心流被打斷跟 Context Drift。
它們不是各自獨立的小技巧，是一套互相配合的工作流。
順序是按上手難度排的，從最簡單、收益最快被感受到的開始，逐步推進到需要對抗本能的那一個。
第一週你不需要全部做完，先把機制一做好，就會有感受。
從機制一開始。
機制一：用 CLAUDE.md 給每個 agent 一份外部記憶
原理
切換最貴的成本是「重新載入脈絡」——你切到 B 案時要花 30 分鐘回憶這個專案做到哪。
Agent 也有同樣的問題，它每次啟動都是一張白紙。
解法是把脈絡外部化——把專案的關鍵資訊寫在一個檔案裡，放在專案根目錄，讓 agent 每次啟動時自動讀這個檔案。
這個檔案叫 CLAUDE.md，是 Claude Code 的官方記憶機制——agent 啟動時會自動掃描幾個固定位置的 CLAUDE.md 並載入內容，不用你手動貼。
CLAUDE.md 實際上分成幾層，從廣到窄：
越具體的層級優先級越高——專案層蓋過全局層、個人層蓋過專案層——所以團隊規範跟個人偏好可以並存不衝突。
對接案者來說最常用的是中間那層「專案 CLAUDE.md」——每個案子一份，承載這個案子的所有脈絡。
下面小林的做法主要在這一層。
小技巧：開好一個新專案，在裡面跑
/init指令，Claude Code 會自動掃描專案結構生成一份 CLAUDE.md 草稿，你再修改即可。
小林的做法
小林為每個案子寫了一份專案 CLAUDE.md，放在各自專案的根目錄：
- A 案的 CLAUDE.md 寫：結帳流程的 UI 規格、後端 API 格式、已完成的元件、目前卡住的 TODO
- B 案的 CLAUDE.md 寫：Dashboard 的資料結構、使用的圖表套件、設計稿連結、下週要做的 feature
- C 案的 CLAUDE.md 寫：部落格的 SEO 規格、目前在改的頁面、客戶的偏好
另外他在 ~/.claude/CLAUDE.md（全局層）寫了一些跨專案的個人偏好：「程式碼一律 2 空格縮排」「優先用 TypeScript 嚴格模式」「commit message 用中文」── 這些是不管做哪個案子他都希望 agent 遵守的事。
每次切去一個案子開 Claude Code，agent 自動讀完這兩層的 CLAUDE.md 之後，就直接進入狀態，不用小林重新教。
關鍵區分
CLAUDE.md 不是 README（給新人工程師看的）。
它是給幾小時後的 agent 看的交接文件。
寫的時候要想像：「如果 agent 完全忘記我們之前的對話，只看這份檔案，它能不能順利接手？」
那些「下一步要做什麼」「目前哪個決定已經定了」「哪個還在討論」都要寫清楚。
另外有三個實務上很重要的細節，是很多人寫 CLAUDE.md 會踩到的坑：
1. 越短越好——目標 500 字內，盡量不超過 1000 字
很多人以為 CLAUDE.md 越完整越好，把專案所有資訊塞進去——錯。
CLAUDE.md 越長，agent 越抓不到重點。
每次 agent 啟動都要把這份檔案讀進 context window，太長會佔掉 token 額度，也會讓重點資訊被稀釋。
實務經驗：500 字內最理想；超過 1000 字就該考慮拆分。
2. 用子目錄 CLAUDE.md 分層管理
前面講過 CLAUDE.md 有「全局個人 / 專案 / 個人專案」三層；單一專案內部其實還可以再細分。
如果你的專案有多個面向（例如前後端），不要把所有規則塞在根目錄那一份 CLAUDE.md。
可以用子目錄 CLAUDE.md：
專案根目錄/
├── CLAUDE.md （全局規則：Git 工作流程、整體架構）
├── backend/
│ └── CLAUDE.md （後端規則：Python、FastAPI）
└── frontend/
└── CLAUDE.md （前端規則：React、Tailwind）當你在 frontend/ 工作時，Claude Code 會自動載入該目錄的 CLAUDE.md，不會讀到後端規則——agent 不會被無關的規則干擾，token 也省。
3. 用 @ 引用其他檔案，不要把細節塞進 CLAUDE.md
CLAUDE.md 應該只放最常用、最核心的規則。
詳細的技術文件（API spec、資料庫 schema、設計稿等）用 @ 引用：
## 資料庫規範
請參考 @docs/database-schema.md 的欄位定義
## API 規格
所有 endpoint 設計遵循 @docs/api-spec.md這樣 agent 平常不會讀到完整的 schema 文件（省 token），但當任務需要時，它會自動展開 @ 引用的檔案。
@ 也可以在終端機直接用：
請根據 @docs/api-spec.md 的規範，修改 user.py 的 API 端點Agent 會直接讀取那份檔案，確保修改符合最新規格。
機制二：切換時讓 agent 先講狀態，你再下指令
原理
機制一處理了 agent 那端的脈絡——它每次啟動會自動讀 CLAUDE.md，知道專案做到哪。
但你那端的脈絡還沒處理。
你切到 B 案時，腦袋還停留在 A 案的細節（剛剛在改的元件、A 案 PM 剛丟的訊息、思考一半的 bug）。
如果直接打開 B 案 terminal 就下指令，指令很容易出包：
- 你給出含糊的需求（因為你還沒想清楚 B 案今天要做什麼）
- 你忘了 B 案上次決定的某個約束（給出跟既有架構衝突的指示）
- 你下指令的口吻還停在 A 案（用 A 案的元件名講 B 案的事）
機制二的解法很簡單：切過去之後，第一句話不要下指令，先讓 agent 把當前狀態完整講一遍給你聽。
讓 agent 摘要三件事：
- 這個專案目前的進度
- 最近一次 commit 改了什麼
- 下一步原本計畫做什麼
Agent 講的時候你做兩件事：
- 大腦從 A 案切換到 B 案 ── 聽 agent 說的內容讓你的注意力被拉回 B 案
- 同時 review agent 說的對不對 ── 如果它講錯（例如「下一步是做 X」但其實 X 你昨天已經做完了），你會發現 CLAUDE.md 該更新了
等 agent 講完，你也回到 B 案的狀態了。
這時候才下指令。
小林的做法
切到 B 案，第一句不是指令而是：
「根據 CLAUDE.md 跟最近的 commit，告訴我 B 案目前做到哪、上次改了什麼、下一步原本計畫做什麼。」
Agent 回覆大概像這樣：
B 案是 SaaS Dashboard 新功能。最近一次 commit 是 3 天前，加了使用者活躍度圖表的前端骨架（用 Recharts），資料還是 mock。下一步要接後端 API（路徑
/api/v2/analytics/active-users），回傳格式跟前端需要的有差，要寫 transform。
讀完這段，小林大腦從 A 案完全切到 B 案，下真正的指令：
「OK，今天我們先處理 transform 那部分。」
這個簡單的步驟把小林每次切換的回神時間從 30 分鐘（自己回想）降到 5 分鐘（聽 agent 說）。
關鍵區分
CLAUDE.md（機制一）跟「讓 agent 講狀態」（機制二）容易搞混，因為都跟「脈絡」有關，但處理的對象不同：
- CLAUDE.md 是給 agent 看的 ── 讓 agent 有脈絡
- 「讓 agent 講狀態」是讓 agent 把脈絡說給你聽 ── 讓你有脈絡
兩個機制是搭配的：agent 啟動時自動讀 CLAUDE.md（機制一），然後在切換點把脈絡完整講一遍（機制二）。
機制一沒做好，agent 講不出有用的東西；機制二沒做，你下指令時還在恍神。
機制三：固定時段批次檢查 agent，不要隨機切
原理
切換頻率直接決定心流成本。
如果你一天想到什麼就切什麼，一天切 30 次，心流永遠建立不起來。
解法是把切換變成「預約好的」——一天安排固定的幾個檢查時段，其他時間專注在當下那個案子上。
但這個機制有一個前置條件：agent 要能在你不在場時繼續跑。
預設的 Claude Code 每寫一個檔案、每跑一個 bash 都會停下來等你按 approve——這種模式下你根本走不開，更別提批次檢查。
更糟的是，當 approval 的次數過多，你會開始不看內容就無腦點 approve——這就是 Permission Fatigue（許可疲勞）。
這時候 permission 反而從安全機制變成風險：你會 approve 掉本來不該 approve 的指令。
要解決這個問題，你需要開啟 Auto Mode（執行 claude --enable-auto-mode 啟用，然後在 session 中按 Shift+Tab 切換進入）。
Auto Mode 是 Anthropic 在 2026 年推出的中間路線：用一個 classifier 自動判斷每個動作安不安全——安全的自動執行、危險的擋下來——比 --dangerously-skip-permissions 安全得多，也比預設模式不打擾你。
安全提醒：Auto Mode 不是完全沒風險。建議在 git 隨時可 revert 的環境下使用；如果處理敏感資料或共享基礎設施，Anthropic 官方建議搭配 container 隔離。
開了 Auto Mode 之後，agent 才能真正在你不看的時候繼續工作，「批次檢查」這個機制才有意義。
小林的做法
小林把一天分成三個檢查窗口：
- 上午 10：00 — 巡視三個 agent，看昨晚留的任務有沒有跑出結果
- 下午 14：00 — 檢查上午啟動的任務，決定下一批
- 傍晚 17：00 — Review 當天所有產出，決定 commit 哪些、退回哪些、明天繼續什麼
每個窗口大約 30 分鐘。
三個窗口之外，他專心做當下那個案子的手工部分——不管其他 agent 在跑什麼。
一天三次深度切換，加起來 1.5 小時；比起原本一天亂切 30 次，心流成本大幅降低。
關鍵區分
這不是「拒絕切換」，是「拒絕隨機切換」。
固定時段切，你的大腦會學會「10 點、2 點、5 點是切換時間，其他時段是專注時間」。
這個節奏建立起來之後，你在專注時段不會想去偷看 agent——因為你知道「反正 2 點會看」。
機制四：AI 互動集中在規劃與 Review 兩個時刻
原理
跟 agent 互動最有價值的兩個時刻是「開始前」和「結束後」：
- 開始前 — 把任務框得清楚（規劃）
- 結束後 — 判斷產出合不合格（Review）
中間過程你一直介入，不但打斷自己的心流，也打斷 agent 的產出連貫性（它會一直被你的問題帶偏，產生 Context Drift）。
這個「規劃 → 執行 → Review」的分工有一個正式名字：Spec-Driven Development（SDD，規格驅動開發）。
它的核心思路是把規格（spec）當作你跟 agent 之間的契約——你花心力把規格訂清楚，agent 根據規格實作，review 只在 phase gate 發生（規格定稿時、實作完成時），不發生在中間。
SDD 的完整流程是 Requirements → Design → Tasks → Implementation 四階段：前三個你跟 agent 一起把規格做出來，第四個讓 agent 去執行。
對個人接案者來說不用照整套跑，但記住核心精神：先把規格框清楚，再讓 agent 跑。
小林的做法
小林的每個任務啟動流程：
- 規劃階段（10 分鐘） — 跟 agent 討論「這個任務要做什麼、邊界在哪、哪些地方不要動」。把這些寫清楚之後，讓它開跑。
- 跑的階段（30-60 分鐘） — 不看。小林去做別的事。
- Review 階段（10-15 分鐘） — Agent 跑完，小林進去看產出。好就 commit，不好就給 feedback，讓它再跑一次。
一個任務 50-90 分鐘的實際工作時間，小林真正花的注意力只有 20-25 分鐘。
剩下那 30-60 分鐘，他是在處理另一個案子。
關鍵區分
這不是「完全不管中間」，是「不該介入中間」。
如果 agent 跑到一半真的卡住（例如它主動跟你說「我不知道這個 API 參數要怎麼填」），當然要介入。
但你不要主動跑去看它有沒有在做對的事——那是監工心態的殘留。
這個機制最容易被破壞，因為它跟你做了多年 Developer 的本能直接衝突——你會忍不住想「我得確認它在做對的事」。
後面會單獨談這個心態問題；現在你只需要記得：每次主動跑去看 agent，就是一次心流被打斷，就是 23 分鐘沒了。
如果你不熟這個技術，先把學習從實作中抽出來
上面講的「不要打斷」適用於你已經懂這項技術、只是想把工作交出去的情況。
但如果你正在學一個新框架、新 API、新領域，你會忍不住想中途打斷 agent ——不是因為不放心，是因為你想搞懂它在做什麼。
這種狀況下「中途介入」其實是錯的解法，正確的解法是把學習動作從實作 session 抽出來，搬到實作之前。
具體做法：
- 另開一個 session 學習 — 不討論你的專案，就單純問這個技術。「OAuth 2.0 的 PKCE 流程怎麼運作？」「React Server Components 跟一般 component 差在哪？」「這個 API 的 rate limit 怎麼處理？」想問多細問多細，這個 session 就是你的家教。
- 在 CLAUDE.md 記下你學到的關鍵決策 — 例如「這個專案的 OAuth 流程用 PKCE 而不用 implicit flow，因為 X 原因」。
- 學完之後，才開實作 session 並讓 agent 跑 — 這時候你看 agent 的產出已經有判斷力，不需要中途打斷。
把學習跟實作分到兩個 session 的好處是：
- 學習 session 不用顧慮心流 — 你愛問多久問多久，反正不是在跑生產任務
- 實作 session 才開始疊加 — agent 跑的時候你不會手癢想中斷，因為你已經懂了
- 學到的東西沉澱在 CLAUDE.md 裡 — 下次切回這個案子，不用再學一次
換句話說：平行工作的前提是你對這個技術已經有判斷力——你能看一眼產出就知道方向對不對。
判斷力沒到位之前，先用單線、學習導向的 session 把技術學起來，再來談平行。
想把 SDD 工作流做得更系統的話：GitHub 的 spec-kit、社群的 cc-sdd 都把 SDD 流程包成 Claude Code 指令，提供
/specify、/plan、/tasks這類指令引導你走完整個 spec 流程。如果手上案子規模偏大、規劃過程容易遺漏細節，這類工具值得評估。
AI agent 平行開發的 4 個機制為什麼缺一不可
看完四個機制，你可能會想：「能不能只用我喜歡的那兩個就好？」
理論上可以，但會撐不久。
這四個機制是一個系統——每個機制解決系統裡的一個漏洞，少任何一個，整個系統會從那個漏洞漏掉。
每個機制補哪個漏洞
- 機制一（CLAUDE.md） 補的是「AI 那端的脈絡」
- 機制二（讓 agent 講狀態） 補的是「你這端的脈絡」
- 機制三（固定時段） 補的是「切換頻率」
- 機制四（規劃 + Review） 補的是「切換深度」
脈絡 × 頻率 × 深度 = 完整覆蓋切換成本的三個面向。
少一個機制會發生什麼問題
少了機制一（CLAUDE.md）
Agent 每次啟動都像新人——它沒有專案脈絡，需要你從頭解釋。
切到 B 案光是讓 agent 進入狀態就要花 15 分鐘，這 15 分鐘還是你自己一字一句打字交代的，效率比直接動手寫程式還低。
機制二也會跟著失效，因為要 agent 「先講狀態」的前提，是它有檔案可讀。
沒有 CLAUDE.md，agent 沒有資料來源，講不出有用的東西。
小林實測過這個情境：沒有 CLAUDE.md 的那幾週，他每天大約有一半時間花在重複解釋專案背景。
少了機制二（切換時讓 agent 先講狀態）
問題從 agent 端轉到你這端——即使 agent 那邊已經準備好了，你的大腦還沒切過去。
切到 B 案的前 15 分鐘你坐在電腦前，但思緒還停留在 A 案。
下指令時用詞含糊、忘了 B 案上次的決定、甚至下出跟既有架構衝突的指示。
Agent 最後產出的東西需要重做，等於這次切換的時間全部白費。
機制一只是讓 AI 那端有脈絡；機制二是讓你那端也有脈絡——兩邊都到位，這次切換才算成功。
少了機制三（固定時段批次檢查）
機制一、二都做好了，但你還是隨時想看 agent。
每五分鐘偷瞄一次 terminal 的習慣不會自己消失。
即使你進入專注狀態，過幾分鐘又會被「不知道 B 案那邊跑得怎樣」的念頭拉走。
心流被打斷的次數沒減少，平行工作的辛苦只是換了形式。
機制一和二處理的是「切換的品質」——讓每次切換不浪費時間。
機制三處理的是「切換的頻率」——讓你不要那麼常切。
三個一起做，才會真的省到時間。
少了機制四（規劃 + Review）
你跟 agent 的對話會變得瑣碎：每寫一段你就忍不住評論一句、每個變數命名你都想干預、每個實作細節你都要確認。
這不是 review，是干預。
每次干預都是一次小 drift，agent 寫出來的程式碼東一塊西一塊，整體缺乏一致性——表面上「每行都按你說的改了」，但合起來看就是不對勁。
機制四要解的就是這個——把你的注意力鎖在規劃跟 Review 兩個時刻，中間放手讓 agent 跑完再評論。
沒有機制四，前面三個機制省下來的時間會被中途的瑣碎干預再花掉。
起手不用一次做四個
四個機制雖然缺一不可，但建立它們不用一次到位。
小林自己也是慢慢加進來的——先做了機制一和三，覺得比原本好很多了，但還是累；加了機制二之後，切換變輕鬆；最後加了機制四，才真正感覺到「一天能做三個案子」的完整體驗。
這是一個演進過程。
但有一件事很多人在這個演進過程中卡住——機制全部都建好了，跑起來還是不順。
原因不在機制本身，在心態。
機制建好之後為什麼還是會失敗：Orchestrator 心態的轉換
到這邊你已經有完整的工具了：四個機制 + 它們互相補位的關係。
但實際做的時候你會撞到一面牆——心態。
具體來說，會出現這三種狀況：
- 你訂下午 2 點才檢查 agent，1 點 50 分就忍不住偷開 terminal 看
- Agent 寫了五行你就想插嘴改一行
- 明明可以放手讓它跑，你還是要每兩分鐘確認一次
你知道不該這樣做，但就是停不下來。
機制本身是對的，但你做不到照著機制走——這是心態問題，不是技巧問題。
從 Developer 變 Orchestrator：你的角色換了
以前你是 Developer——寫程式的人，你的手要實際在鍵盤上，程式才會出現。
現在你是 Orchestrator。
這個字來自 orchestra（管弦樂團），原意比較接近「指揮家」——不是管理員或主管，而是讓多個獨立運作的東西合奏出結果的人。
管理員的工作是盯人，指揮家的工作是協調。
每個樂手其實都會自己演奏，指揮家的價值不在監督他們有沒有偷懶，而在決定整體怎麼合起來、什麼時候誰進、什麼時候誰停。
AI agent 也是這樣。
它不是你的員工，不需要被管——它需要被指揮。
你要決定的不是「它有沒有認真工作」，是「三個 agent 加起來要產生什麼整體結果、哪個該先動、哪個該等一下」。
你的手可以離開鍵盤，但你要同時盯著三個爐火。
用廚房做類比比較好懂：
- 以前是一人廚師：一次只能顧一道菜，從備料到擺盤都你一個人，這道菜做完才能做下一道
- 現在是大廚帶三個徒弟：三個爐火各自在煮不同的菜，徒弟（AI agent）負責實際操作，你主要在巡視、試味道、決定下一步加什麼、哪一鍋快燒焦了要立刻處理
大廚的工作時間密度比單人廚師高很多，但工作內容完全不一樣——不是「煮得更快」，是「同時監督多個煮」。
要從執行者轉成指揮家，光知道概念還不夠——你心裡會有阻力。
執行者心態的三種抗拒
你做了幾年 Developer，心裡有幾個根深蒂固的習慣，這些習慣在平行工作場景會變成阻力。
第一種抗拒：監工焦慮
Agent 在跑的時候，你會忍不住去看。
不是因為有什麼需要處理，就是一種「讓它自己跑我不放心」的感覺。
這種焦慮會讓你平均三到五分鐘就切一次——機制 3「固定時段批次檢查」就是被這個焦慮破壞掉的。
第二種抗拒：掌控感需求
你會想要每一行程式碼都經過你確認。
Agent 寫了一個 function，你會想點進去看它寫的邏輯對不對——即使這個 function 根本不是重要的部分，只是某個 utility。
這種需求會讓你陷入「什麼都要自己盯」的模式——機制 4「只在規劃和 Review 介入」就是被這個需求破壞掉的。
第三種抗拒：放手的恐懼
你會擔心「我沒看著，它會不會跑偏」。
這種恐懼其實跟 Context Drift 是互相增強的——因為 drift 真的會發生，所以你會更想盯；越盯，你越沒時間寫自己的部分。
Orchestrator 心態要接受的三件事
要從執行者轉成指揮家，你要在心裡接受這三件事：
第一：Agent 在你不在場時會繼續工作，而且這是好事
不是「你放手它才能工作」，是「你放手它才能幫你賺時間」。
你一直盯著它，它的工作時間就被壓縮到跟你的工作時間一樣長——你就失去了疊加的好處。
第二：中間過程不完美沒關係，你只要 review 結果
Agent 寫的第一版可能不是最佳解，但那沒關係。
你的介入時機是「它交付一整個單位的產出之後」，不是「它每寫一行」。
這跟 code review 的心態很像——你不會對每個正在打字的同事說「這行改這樣」，你是等他提 PR 你再給意見。
第三：你的價值在「frame 問題」和「判斷產出」，不在「操作每一步」
指揮家不會自己上台演奏。
同樣的，Orchestrator 的價值不在自己寫程式，而在：
- 把問題框得清楚（讓 agent 知道該做什麼）
- 判斷產出合不合格（決定要不要接受）
這兩件事你做得好，agent 跑起來才會有效率。
中間過程你是不是一直在場，其實沒那麼重要。
怎麼練習這個心態
這三件事聽起來簡單，但做起來會很不習慣——特別是前幾週，你會一直想偷看、想介入、想確認。
最有用的提醒是把成本量化：每偷看一次，就是一次心流被打斷，就是 23 分鐘沒了。
把這個換算放在腦袋裡，每次手要伸去切到別的 agent 之前先停一下——「這次切換值不值 23 分鐘？」大多數時候答案是不值。
機制 + 心態到位之後，平行開發才會真的運作起來。
下面看一個完整的工作日長什麼樣子。
從單線到平行：接案工程師的一天怎麼變
把四個機制都上手之後，小林的一天變成這樣：
- 09：00 — 打開三個 Claude Code。每個 agent 先讀自己的 CLAUDE.md，接著小林花 20 分鐘分別規劃今天給 A、B、C 的第一批任務，然後讓它們開跑。
- 09：30 — 切到 A 案，專心寫 A 案今天需要小林手工完成的部分。不看 B 和 C。
- 11：00 — 第一次批次檢查時段。花 10 分鐘看 A 案 agent 的產出、10 分鐘看 B 案、10 分鐘看 C 案。該 commit 的 commit，該退回的退回，順便規劃下一批任務。
- 11：30 — 再切到 B 案，專心做 B 案的手工部分。
- 13：00 — 午餐。
- 14：00 — 第二次批次檢查。同樣 30 分鐘巡一輪三個 agent。
- 14：30 — 專心做 C 案的手工部分（因為早上都沒碰 C）。
- 17：00 — 第三次批次檢查。這次除了 review 產出，還要規劃明天的第一批任務，直接寫進 CLAUDE.md。
- 17：30 — 下班。
同樣八小時，小林今天三個案子都推進了，而且每個案子都有實際產出——不是東碰西碰的假動作，是每個案子都有至少兩個完整的任務 commit 進去。
起手式建議
你不需要明天就全套上身。
照這個順序加進來最順：
- 第 1 週 — 機制一（CLAUDE.md）+ 機制三（固定時段）。這兩個最簡單，收益也最快被感受到。
- 第 3 週 — 加機制二（切換時讓 agent 先講狀態）。前兩週你會習慣 CLAUDE.md 的存在，這時候用它來做切換輔助很自然。
- 第 5 週 — 加機制四（規劃 + Review）。這個最難，因為要對抗監工心態，前面幾週讓大腦慢慢適應「放手」的感覺。
四個機制總表
最後一句話
小林花了五週把這四個機制習慣化。
他的產出不是原本的 3 倍——是 2 倍多一點。
但他下班時間提前了兩小時。
這才是 AI agent 平行開發真正給個人工作者的禮物：不是逼你榨出更多時間，是讓你的時間可以用得更聰明。
回到文章最開始的那句話——你不是不夠努力，你是用單線工作的習慣在做多線工作。
工作方式改了，結果就會改。