跨專案的開發，我怎麼確保 coder 遵守各自專案的規則？

Make It Work

2026 年 2 月，我在用組織架構圖思考 agents 並應用於自己的 side project。
coder 寫程式、tester 寫測試、reviewer 審核、team-lead 統籌。
開發者只要呼叫 /be-team-lead，需求講完，剩下咱們的領導自己協調。

運行不錯，於是搬進公司的 monorepo。
此 repo 裝的不只是一個 service，是一個平台：
有後端有前端、有為了處理邊緣端的各種 app service，周邊還有一票配套服務，
每個都是獨立 tech stack 的 project，甚至散在外面的舊服務正陸續搬進來。
八成規則一樣，可剩下的兩成都是各專案的細節：用什麼指令跑測試、coding style 長怎樣、哪裡不准碰。

先將平台背後收斂成三端，三端要的知識不一樣，那就每個角色補個前綴，一次長出一整排：

.claude/
└── skills/
    ├── be-coder/SKILL.md
    ├── be-tester/SKILL.md
    ├── be-reviewer/SKILL.md
    ├── be-team-lead/SKILL.md
    ├── fe-coder/SKILL.md
    ├── fe-tester/SKILL.md
    ├── fe-reviewer/SKILL.md
    ├── fe-team-lead/SKILL.md
    ├── edge-coder/SKILL.md
    ├── edge-tester/SKILL.md
    ├── edge-reviewer/SKILL.md
    └── edge-team-lead/SKILL.md

在追求能動的階段，這樣很完美，因為每一份都是完整的檔案：
權限清單、邊界規則、專案知識全寫在同一份裡，結果光一個 be-tester 就 400 行。
把三份 coder 攤開來比對，八成一模一樣：
你是誰、你要幹嘛、你怎麼回報，這些本來就不分端。

猶記得我當時向團隊彙報：

各角色過於臃腫，且只適用單一 project（如 /be-team-lead 底下的描述只能適配後端主專案的流程），
所以未來每進來一個新 project，甚至是新的後端服務，目前都無法適配，要花大量時間維護及新增。

跨專案開發（一張需求同時要動兩個 project），會不知道使用哪個 team lead，或是混用造成不精準的誤用。

想調整 coder 的思路邏輯，同一件事要改三份；
且兩成細節混在字裡行間，連無腦複製貼上都不行。
而 monorepo 的專案還在一個接一個進來，同一端的新服務也套不進舊 skill，每進一個，整排 skill 都要回頭改一輪。

這套能動，但養不起。

Make It Right

某天下班我在健身，腦中正飛速運轉要怎麼讓 agent 處理跨專案規則以及協調。
組間休息的那一剎那，靈光乍現：
這不就 object 寫三遍？ 而且還是 copy paste 大法的三遍。

那為啥不抽出一個 class？ 讓各自的 project 當 instance？
物件導向第一課：上層放抽象，下層放實例，轉眼間就是一個手起刀落。

.claude/
├── skills/
│   ├── be-team-lead/SKILL.md
│   ├── fe-team-lead/SKILL.md
│   └── edge-team-lead/SKILL.md
└── agents/
    ├── coder.md
    ├── tester.md
    └── reviewer.md
projects/
├── backend/
│   └── .claude/
│       ├── coder.md
│       ├── tester.md
│       └── reviewer.md
├── edge/
│   └── .claude/
│       └── …
└── …

這是當時我給團隊的訊息，也是我的運用邏輯：

subagent 使用最上層（root）抽象，最下層（project）賦予實踐的思路。

team lead 派遣的是最上層的抽象 agent，此時他只知道自己是什麼角色，以及最基本的通用準則
（我是一名 coder，我負責寫 code）；

當他被派到 project 層級時，才會去讀真正的實作準則
（我到了後端專案，我用 golang，這個專案的 coding style 是…）。

如此一來，當新 project merge 進 monorepo 時，我們不必再創新的一大包 skill，
只要維護好該 project 各角色要做的事，與其他 project 的 tech stack 彼此獨立，避免 project 之間的實作知識汙染。

一天之內，十幾個 skill 下架到只剩各端的 team-lead 當入口，專職派工；
換上來的是基礎三份角色檔：coder、tester、reviewer。
之後每一次派工，走的都是同一條流程：
team lead 派出一個 coder，派工單上寫著專案路徑；
它先讀頂層的 coder.md：自己是誰、該做什麼以及進了專案後要先讀同名檔案。
進到被指派的專案後，再讀該專案目錄下的 coder.md，
譬如後端專案的 error handler「一律 wrap error 帶 context，禁止裸 panic」；
前端專案「API 失敗統一走 error boundary，不各自 try/catch」。

上下兩份疊起來，才是一個能開工的 coder。
就算後來整套開發流拆掉重蓋過幾次，這批角色以及架構直至今日仍大差不差。
至於一張需求若要動兩個 project，不知派哪個 team lead 的這個痛點，最後收斂成一個 /develop 才真正消失。

Make It Fast

接下來的數月，
加專案，就是 new 一個 instance。
新專案一個接一個 merge 進來，有搬家的舊服務也有新的配套，
每一個帶進 monorepo 的，就只有自己目錄底下那幾份檔案；
翻遍 commit，頂層的抽象角色沒被動過一行，別的專案沒被碰過一字。

修改，就是調整 instance。
我想改後端 coder 的規矩，就只要瞄準 projects/backend/.claude/coder.md，
被派到這個專案的 coder 才會按派工去讀這份規則；
邊緣端、前端的 coder，各自讀自己的。
就算改壞，炸的也只有我這一個專案。

角色之間也是同一種做法。
reviewer 的定義檔裡，工具清單沒有 Edit 跟 Write，職責也只到審查回報。
這問題我審下來覺得很有道理，就想偷偷修，沒門兒。
先回報給 team lead，轉派 coder 去改。

用物理的方式斷絕一切，路徑上走不到，實作上沒工具。
於是維護這套流程，變成一次只做一件事：
進哪個專案，就開那個專案的角色檔，寫完收工，
agent 自己很專注，人類的我也舒舒服服的隨意擴充。
當初進一個專案要回頭改一輪整排 skill，現在只是開個檔、寫幾行便速速解決。

同一個 class；
他 new 他的，我 new 我的。

我跟 edge 端的同事在爭論註解這個老掉牙的話題：
我主張盡量不寫，他覺得 AI 想寫就給它寫。
最後沒個結論，不過也不需要。

因為我在我專案的 coder 檔加了一條規則，他的專案完全由他發揮。
之後他搞他的，我搞我的，各自維護：
我們每天喊同一個名字，而 coder 在我這惜字如金，在他那滔滔不絕。