同時用 3 個 AI Coding Agent 唔使癲：跨平台規則同步同任務隔離實戰

我哋好快會去到一個世界——其實已經係——一個 developer 同時用幾個 AI coding agent 係常態，而唔係例外。Cursor 寫 frontend，Windsurf 做 refactoring，Claude Code 處理 backend 架構。每個 agent 各有強項，各自獨立運作，諗落好完美。但現實係：用咗三個禮拜之後，你 Discovery 撞到嘅最大樽頸唔係任何一個 agent 嘅能力，而係每次切換 agent，你都要重新教佢一次你嘅規則。Project 嘅 coding convention、技術棧選擇、測試策略——呢啲 context 全部散落喺唔同 platform 嘅設定檔入面，冇人同步，冇人維護。而當你喺 Cursor 改咗一條 rule，Windsurf 嘅 agent 下次開嘅時候依然我行我素，寫出嚟嘅 code 完全唔同風格。呢個唔係效率問題，呢個係基建問題。

問題根源：每個 Agent 都係一個封閉島

Cursor 嘅 .cursorrules、Windsurf 嘅 .windsurfrules、Claude Code 嘅 CLAUDE.md——每個 platform 用自己嘅格式、自己嘅路徑、自己嘅加載機制。表面上只係 config file 嘅差異，但實際影響深遠。一個中型 project 嘅 custom rules 閒閒地幾百行，涵蓋 code style、architecture patterns、dependency management、testing requirements。當你維護三個版本，每次更新都要改三次，好自然就會「是但啦，下次先」——然後 rules 就慢慢發霉，agent 寫出嚟嘅 code 品質開始 drift，到最後你要手動 review 每一個 PR 去修正 agent 嘅「壞習慣」。

更深層嘅問題係：Rule 嘅更新唔係線性嘅。你可能喺 Cursor 入面 debug 咗三個鐘，發現某個 pattern 成日出錯，於是你喺 .cursorrules 加咗一條「永遠唔好咁樣做」。但 Windsurf 嘅 agent 唔知呢件事，佢下個 session 繼續犯同一個錯。呢種「多 agent 記憶碎片化」令到成個 workflow 嘅可靠性大幅下降。你以為用多個 agent 等於 parallel processing，但實際上你花咗大量時間喺 overhead 上面：同步規則、fix 重複錯誤、重新灌 context。

解決方案：AI Rules Sync 作為基建層

我喺自己嘅 project 入面逐步建立咗一套叫 AI Rules Sync 嘅工作流，核心係「一個 source of truth，多個 render target」。概念好簡單：所有 custom rules 用一個統一中間格式（我揀咗 YAML）集中管理，然後用 scripts 自動轉譯成各個 platform 需要嘅格式。

具體做法係咁嘅：喺 project root 開一個 _ai_rules/ 目錄，入面放一個 rules.yaml，按類別分組——style.md 放 code style，architecture.md 放架構規則，testing.md 放測試要求，workflow.md 放開發流程約定。然後寫一個好短嘅 Node.js script（或者用你鍾意嘅任何語言），用 yaml 解析 rules.yaml，分別 render 成 .cursorrules、.windsurfrules 同 CLAUDE.md。行一個 command 就搞掂三個 platform。

呢個做法嘅好處唔止係「唔使改三次」咁簡單。更重要嘅係，你逼使自己思考乜嘢規則係跨 platform 通用，乜嘢係 platform-specific。通用規則例如「用 TypeScript strict mode」、「所有 public function 必須有 JSDoc」、「error handling 用 Result type 唔 throw」呢啲放喺 rules.yaml。Platform-specific 嘅嘢例如 Cursor 嘅 Composer 行為設定或者 Claude Code 嘅系統 prompt，就放返喺各自嘅 config 入面。呢種 separation of concerns 本身就改善咗你對 project 規則嘅理解。

任務隔離：Agent Tower 的應用

Rules 同步搞掂之後，下一個問題係：唔同 agent 之間點樣避免撞車？ 我見過最常見嘅場景係：Cursor 同 Claude Code 同時改同一個檔案，結果 merge conflict 多到令人崩潰。解決方法唔係「只用一個 agent」，而係引入 Agent Tower 概念——每個 agent 有明確嘅責任範圍同檔案邊界。

Agent Tower 嘅做法係喺 project 層面定義「agent domains」：Frontend Agent 只可以掂 src/frontend/ 同 src/components/，Backend Agent 管 src/api/ 同 src/services/，Testing Agent 負責 tests/。呢啲邊界寫入 shared rules 入面，每個 agent startup 嘅時候自動 load。必要嘅時候用 git hooks 或者 CI 做 enforcement：如果 Frontend Agent 嘅 commit 改咗 backend 檔案，CI 就自動 fail 並提醒開發者檢查。

配合 Git 嘅 worktree 或者 feature branch isolation，你可以做到 真・parallel development。三個 agent 各自開一條 feature branch，同時開發唔同模組，最後由你做 human review 同 merge。呢個 workflow 嘅 throughput 遠超單 agent 或者單人開發——我試過一個 weekend 用呢個 setup 完成咗平時要一星期先寫完嘅功能。

落地技巧：Hermit 同 Skill Flow 整合

講到實際執行層面，有兩個工具幫咗我好大忙：Hermit 同 Skill Flow。

Hermit 係一個跨 platform 嘅環境管理工具，佢嘅殺手鐧係可以幫每個 project 自動切換 toolchain version——呢個表面上同 AI agent 冇直接關係，但實際上，當你嘅 agent 用緊唔同嘅 runtime 環境（例如一個用 Node 18，另一個用 Node 22），寫出嚟嘅 code 可能有兼容性問題。Hermit 確保每個 project 嘅 agent 都喺一致嘅環境入面執行，eliminate 咗一個 major 嘅變數來源。

Skill Flow 就更加直接相關。我將每個 agent 嘅「skill」——即係特定領域嘅知識同 workflow——寫成可重用嘅 flow 檔案。例如 frontend-component-flow.md 定義咗點樣用 React + Tailwind 寫一個新 component，包括 file structure、test pattern、accessibility check。呢啲 flow 檔案同樣放喺 _ai_rules/ 目錄入面，由 AI Rules Sync 一併管理。每次 agent startup，佢哋唔單止 load 咗 rules，仲 load 咗完整嘅「點樣做嘢」指南。結果係：唔同 agent 寫出嚟嘅 code 風格一致，架構一致，連 commit message 嘅格式都一致。

結尾：From Chaos to Infrastructure

多 agent 開發嘅未來係必然嘅。問題唔係「應唔應該用多個 agent」，而係「你嘅基建 ready 咗未」。我建議由今日開始做三件事：

第一，建立一個 unified rules repository。就算你而家只係用一個 agent，呢個習慣都可以幫你更清晰地定義 project 嘅開發規則。第二，定義 agent boundaries。唔好俾 agent 亂改嘢，畀佢哋一個清晰嘅責任範圍。第三，將 rules 嘅同步自動化。任何需要人手做嘅同步最終都會被放棄，直接寫 script 解決。

AI coding agent 嘅真正威力唔係來自單一 agent 嘅能力，而係嚟自多個 agent 協作嘅系統效率。做好 rules sync 同 task isolation，你先至可以真正解放多 agent 嘅 production power。