後臺與並行智慧體

一旦你在劃定範圍的任務上信任某個智慧體，下一步就顯而易見：一次執行好幾個。現代工具讓你能啟動後臺智慧體——各自在自己的分支或工作樹（worktree，專案的一份單獨的工作副本，這樣一個智慧體的改動永遠不會和另一個的相撞）上——這樣在你做別的事時，三四個劃定範圍的任務都在推進。

這是真正的提速，但僅限於獨立的工作。你拿來交換的代價是協調。兩個智慧體編輯同一個檔案會產生衝突的 diff，手動合併它們可能比你省下的還貴。

• 按邊界拆分，而非按行數。 給每個智慧體一塊與其他不重疊的部分——不同的模組、不同的功能、不同的檔案。「智慧體 A 做匯出功能，智慧體 B 寫文件」很乾淨。「兩個智慧體都編輯 app.js」是預約了一場合並頭疼。
• 隔離工作空間。 讓每個智慧體在自己的 git 分支或工作樹上執行，使它們踩不到彼此未提交的改動。一次合併一個回來，每次合併時都執行你的檢查。
• 誠實地控制數量。 你仍然必須審查每一個結果。四個智慧體在跑，就是四份要讀的 diff 和四套要信任的測試。超過一小撮之後，瓶頸就成了審查佇列，而不是智慧體。

每個智慧體都在自己隔離的 worktree 裡工作，於是它們的編輯永不碰撞；你一次合併回一個，並在每道關卡跑檢查：

              ┌─────────────────────────────┐
              │  你按邊界拆分               │
              └──────────────┬──────────────┘
            ┌────────────────┼────────────────┐
            ▼                ▼                 ▼
   ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
   │ 智慧體 A     │ │ 智慧體 B     │ │ 智慧體 C     │
   │ worktree-a/  │ │ worktree-b/  │ │ worktree-c/  │
   │ 匯出功能     │ │ 文件         │ │ 設定頁面     │
   └──────┬───────┘ └──────┬───────┘ └──────┬───────┘
          │ branch-a       │ branch-b       │ branch-c
          └────────────────┼────────────────┘
                           ▼
                  ┌──────────────────┐
                  │  逐個合併        │  每次合併都跑檢查
                  │  → main          │
                  └──────────────────┘
   隔離副本 = 無衝突   · 審查佇列才是真正的瓶頸

錯誤在於把並行當成免費。它不是——你把工作從編寫挪到了審查與整合。這常常是筆很好的交易，但前提是你真的去審查。