實戰範例 010：用 omc team 並行收集多微服務的 API 清單與測試覆蓋率 · Oh My ClaudeCode

實戰背景

接手一個由 3 個微服務組成的舊專案時，第一件要做的事通常是「盤點」。你要知道每個服務對外暴露哪些 HTTP 端點，以及各自的測試覆蓋率落在哪裡，才能決定下一波重構要從哪裡下手。

痛點與問題描述：這 3 個微服務各自有 30 到 50 個控制器檔案，加起來超過 100 個候選端點。如果用單一 AI 代理循序掃描，大約要花 15 分鐘、燒 3 美元以上的 Token，而且單次會話要載入全部 3 個服務的 AST，context 非常吃緊。

本範例示範如何用 omc team 啟動 3 個隔離的 Worker，唯讀地並行掃描各自的服務目錄，把 API 端點清單與覆蓋率數字寫入各自的報告檔案。與範例 003 的並行「重構」不同，這裡每個 Worker 只產出一份報告，不需要合併程式碼分支，非常適合第一次練習 Team Mode 的新手。

端到端 6 輪並行調查紀錄

── 第 1 輪：初始化 3 個隔離 Worker ──

You:

omc team init --workers=3 --names=auth,billing,notification

AI:

OMC 回傳:
[OMC] Spawning worker: auth          -> worktree at temp/wt-auth
[OMC] Spawning worker: billing       -> worktree at temp/wt-billing
[OMC] Spawning worker: notification  -> worktree at temp/wt-notification
[OMC] Tmux session 'omc-team' created with 3 panes.
每個 Worker 都有自己獨立的 git worktree 與 tmux pane，互不影響。每個 pane 只會載入自己負責的服務目錄的 AST，大幅縮減單一會話的 context 開銷。

── 第 2 輪：分派並行調查任務 ──

You:

在每個 worker 中並行執行同一個調查任務：「掃描自己負責的服務目錄，列出所有 HTTP 路由（method + path + handler），並計算每個 controller 檔案的測試覆蓋率，寫入 reports/<service>.md」。唯讀，不要動原始碼。

AI:
好的，我把同一個調查 prompt 分派給三個 worker。Master 代理會把任務拆分後，發送指令到各個 worker 的 tmux pane 背景執行，每個 worker 各自跑自己的 Sisyphus 迴圈來分頁掃描控制器。

OMC 回傳:
```
[OMC] Dispatched prompt to: auth, billing, notification
[OMC] HUD active. Use 'omc team log --worker=<name>' to inspect.
```
每個 worker 收到的任務 prompt 相同，但 scope 限定在自己的服務目錄。關鍵是任務本身只寫報告檔，不修改原始碼，因此最後不需要 omc team merge 解衝突。

── 第 3 輪：用 HUD 觀察並行進度 ──

You:
```
目前進度如何？
```
AI:
HUD 列即時顯示三個 Worker 的狀態：
```
[HUD auth]          Loop 2/5 | Status: Parsing controllers/UserController.cs
[HUD billing]       Loop 3/5 | Status: Computing coverage for InvoiceService
[HUD notification]  Loop 1/5 | Status: Indexing routes
[HUD budget]        $0.42 / $5.00 (8%) [OK]
```
三個 Worker 各自跑自己的 Sisyphus 迴圈，這裡的 Loop 不是修復編譯錯誤，而是分頁掃描控制器的迭代次數。HUD 同時整合了預算監控，能看到目前總開銷還很健康。

── 第 4 輪：檢視單一 Worker 的細節日誌 ──

You:

omc team log --worker=billing --lines=12

AI:

OMC 回傳:
[billing] [Loop 1] Found 18 controller files in src/Billing/.
[billing] [Loop 2] Extracted 42 routes (GET: 20, POST: 14, PUT/DELETE: 8).
[billing] [Loop 2] Coverage scan: 31% average across controllers.
[billing] [Loop 3] Wrote reports/billing.md (42 routes, 31% coverage).
[billing] [Loop 3] Task complete. Worker idle.
這份日誌顯示 billing 服務有 42 個路由、平均覆蓋率 31%。同時 auth 與 notification 兩個 pane 也在背景跑類似的流程。

── 第 5 輪：收集報告與清理 ──

You:
```
omc team merge && omc team cleanup
```

AI:

OMC 回傳:
[OMC] Merging 3 worktrees (read-only reports, no source conflicts).
  -> reports/auth.md ............... merged (28 routes, 64% coverage)
  -> reports/billing.md ............ merged (42 routes, 31% coverage)
  -> reports/notification.md ...... merged (15 routes, 12% coverage)
[OMC] Cleanup: removed temp/wt-auth, temp/wt-billing, temp/wt-notification.
[OMC] Tmux session 'omc-team' terminated.
因為三份報告檔名各不相同，merge 階段不會碰到任何衝突。omc team cleanup 會把臨時 worktree 與 tmux session 一次清掉，磁碟與背景行程都乾淨。

── 第 6 輪：效益評估 ──

You:

跟單代理循序掃描相比，這次並行調查省了多少？

AI:

模式耗時 Token 費用備註

單代理循序掃描（估計） ~15 分鐘 ~$3.20 三個服務擠在同一個 context

omc team 並行（實測） ~4 分鐘 ~$1.10 每 worker 只載入自己服務的 AST

由於每個 Worker 只載入單一服務的 AST，context 大幅縮小，加上三條平行執行，時間與費用雙雙下降。這正是 Team Mode 在「唯讀調查」類任務上的甜蜜點：風險低、產出明確、沒有合併負擔。

模式	耗時	Token 費用	備註
單代理循序掃描（估計）	~15 分鐘	~$3.20	三個服務擠在同一個 context
omc team 並行（實測）	~4 分鐘	~$1.10	每 worker 只載入自己服務的 AST

關鍵學習點

Team Mode 不等於重構：範例 003 用 Team Mode 並行改程式碼，本範例則是並行做「唯讀調查」。只要任務能拆成互不衝突的子範圍，Team Mode 都能加速，不必害怕合併衝突。
唯讀任務不用怕 merge：給 Worker 設計成只產出檔名獨立的報告（例如 reports/<service>.md），omc team merge 只是把新檔案拉回主工作樹，幾乎不會碰到衝突。
每 Worker 一個服務是黃金切割：讓一個 Worker 只載入一個微服務的 AST，能把單次 context 壓到最小，是 Token 帳單下降的主因，比分時切片更有效率。
HUD 是新手最好的教練：第一次跑 Team Mode 時盯著 HUD 列就能即時看到三條 Worker 的進度與預算，不用切換 pane，能快速培養對「並行」的直覺。