我的工作方法：怎麼和 coding agent 協作

為什麼需要路由

同一件任務，開場的說法每次都不一樣。有時貼一張票單，有時只丟一句「接著做」，有時是「PR 合併了」。沒有路由時，這句話該走哪個流程，我靠記憶補，agent 靠猜。

路由是把這個判斷寫下來。收到任務，先分流，再動手。結果是同一類開場，不管哪一次、不管哪個 agent，都走到同一份流程。

任務怎麼分流

先路由再動手的概念，我借鑑自 Lauren Tan 的 pstack。它用 poteto-mode 當入口，先判斷任務該走哪一套流程。我照這個想法，寫了自己的分流規則和 Playbook。

分流分兩層。每個任務進來，agent 的第一行字要先寫出「路由：」加上它選的是哪一份流程，兩層都對不到就寫「路由：無」。

• 任務層：看開場，對到一份 Playbook。現在有三份：已有規格的工作、接手先前的工作、合併後收尾。Playbook 是一串步驟，每一步有完成條件，做到了才進下一步。
• 情境層：看當下的情境，對到一個 skill。例如要測試先行的實作、審查一個分支、回報一個症狀。不靠關鍵字，靠判斷。

規格還不清楚的新工作，要看它碰到什麼。碰到公共介面、模組邊界、既有不變式或依賴選擇，就提醒我先跑 grill-with-docs；不碰這些邊界的改動，不論大小，用兩句話講計畫就直接開始。

有幾個流程只提醒，由我親自啟動。agent 判斷到了，就提醒我打那個指令，不替我開始。

路由的規則有回歸測試。改了規則之後，我可以重跑一組開場，看它們是不是還對到原本該去的地方。

從規劃走到實作

規劃到實作的主線，我沒有自己發明。它出自 Matt Pocock 的 mattpocock/skills，我直接拿來用。

1. grill-with-docs：先訪談我，逼我把需求、用語和取捨講清楚。
2. to-spec：把訪談結果寫成規格。
3. to-tickets：把規格切成一張張可以交出去的票單。
4. implement：逐張實作。過程中它自己會用 tdd 先寫失敗的測試，再用 code-review 審查。

這幾個 skill 都出自他，不是我寫的。我自己的部分只有五樣：路由層、Playbook、共通規則、子代理分工規則，以及路由規則的回歸測試。其中路由層的概念借鑑 pstack，分流規則和 Playbook 是我寫的。

子代理怎麼分工

我把工作依性質分給不同的子代理，每一個都有固定的模型層級。

• 搜尋與盤點：haiku 層級的 scout 負責大量搜尋，只回位置和短摘錄，不評斷。
• 實作：implementer 用 sonnet。規格已經清楚才派，例如一張票單、一個要讓它通過的失敗測試；規格含糊時，它回報問題，不猜。
• 審查：code-reviewer 用 opus，看剛寫好或改過的程式碼。
• 架構調查：architect 用 opus，唯讀，只在訪談或規劃中需要盤點整個程式碼庫時才派，回報發現，不下決定。

規劃和邊界決策留在主代理，不交出去。審查意見回給原本寫那段程式的 implementer，因為它還握有那些檔案，換一個新的 agent 得全部重讀。互不相依的派工放在同一則訊息一起送出。

另外有一組共通規則，每個 agent 都適用。例如可以在這台機器上查證的主張，要先查證，並說明這句話是驗證過的、推論的，還是假設。

本站實際走一遍

拿你現在正在看的這個網站當例子。本站是照上面那條主線做出來的。

1. 用 grill-with-docs 訪談。首版問了 11 題，目的、讀者、品牌範圍、頁面範圍，都是在這一步由我逐題確認。
2. 把確認的結果寫成產品規格，再切成 4 張票單，包含共用站框、作品頁、實戰筆記和整合。
3. 票單交給實作的子代理逐張完成，每張都有驗收條件，測試通過才算完成。
4. 建置後檢查生成的 HTML。上線是後來改版時的另一個階段。

這篇文章本身也是同一流程的產物：訪談 13 題，寫成規格，切成 2 張票單，再實作。第一張票單做這篇文章，第二張票單補上了首頁和關於頁的入口。

這些訪談、規格和票單的原始紀錄未公開，所以這裡不附 repo 連結。你看到的是我整理過的流程，不是可以逐行核對的紀錄。

限制與數字口徑

我想讓你知道這些設定有在日常用，不只是躺在檔案裡。所以我數了一次。期間是 2026-09-08 至 2026-10-20，共 558 個 session。

• skill 呼叫 958 次。
• 子代理派工 1426 次，其中審查（code-reviewer）580 次、實作（implementer）416 次。

審查的次數比實作多。我只陳述這件事，不在這裡解讀它。

這些數字怎麼來的，先講清楚。

• 只計模型實際發出的 Skill 與 Agent 呼叫，我自己打的指令不算。
• 包含非公開專案，所以你無法回頭核對。
• 只能回溯我可取得的紀錄範圍，這不是我開始使用這套方法的時間。
• 這是 2026-10-20 算出的固定值，重算會得到不同的結果。

方法本身也有限制。

• 有些流程只提醒，要我親自啟動。我沒打指令，它就不會開始。
• 路由靠模型判斷。規則寫了回歸測試，但模型仍可能把任務判到錯的類別，也就是誤判。
• 子代理派工是 Claude Code 專屬的做法。這篇只寫 Claude Code 這一側。
• 這是我個人的做法，這篇沒有別人用過的證據。

對應的現行 skill

這篇講的是整套做法，能單獨拿去用的是 pm。它在路由裡負責交接：看計畫做到哪，提出下一步和進入的入口。

「單次交接」是這樣運作的：我選了 pm 提出的提案，就等於我親自啟動了那個入口，它直接接續，不用我再貼一次指令。只管這一個提案；它的建議本身不會動手，新的任務也照原本的路由重走。