為什麼我故意讓兩個 AI 工具不知道彼此存在——多工具協作的 Context 隔離原則

用多個 AI 工具完成一件複雜任務，直覺會想讓它們無縫互通。但跑過一輪你會發現，這恰好是整套架構最容易崩掉的地方。真正撐住協作的，是反過來——刻意隔離、共享走檔案系統、人類在中間做橋接。

直覺反過來：別讓 AI 互相講話

想像一個情境：你要改版一個網站，找了三個 AI 工具來協作——一個負責想策略、一個負責畫視覺、一個負責寫程式。直覺會告訴你：「最理想的狀態是這三個工具能即時對話、互相同步、像一個無縫的團隊。」

我自己跑過一次完整的多工具協作（36 小時內把 gwarket.com 從文章集合站升級成編輯部式個人站），結論跟直覺完全相反——讓三個工具能互相對話，是這個架構最容易爛掉的地方。

工具配置：Claude（策略 / PM）、Claude Design（視覺）、Claude Code（執行）、我（總編輯）。核心紀律不是讓四方互通有無、是反過來——故意讓他們看不到彼此的對話。

這個原則我把它叫做 Context 隔離。下面拆三個要件。

Context 隔離的三個要件

要件一：不共享 conversation context

每個工具只在自己的 session 裡跑。Claude Design 不讀 git repo、Claude Code 不看品牌策略討論、PM 不寫具體的 import 路徑。

具體案例：Claude Design 出 mockup 的時候，我沒有把 codebase 餵給它。為什麼？因為一旦讓 Designer 看到「現有實作長什麼樣」，mockup 就會被既有實作污染——本來該是「這個網站應該長什麼樣」的 vision，會悄悄變成「這個 codebase 大概能做出什麼樣」的 reflection。Mockup 是視覺合約、不是 implementation 的鏡子。

反過來也一樣。Claude Code 在實作的時候，我刻意不讓它接觸太多策略 layer 的討論。它的工作是把 mockup 翻成程式碼，不是評斷視覺品味。我也不會越界幫 Claude Code 寫具體的函數簽章 / state 結構。PM 該定義 outcome（「Nav 要支援手機漢堡選單、UX 對應 v4 mockup」）、不該定義 how。一旦越界、Engineer 變成 transcriber、就失去了 push back 的紀律。

要件二：共享資料走檔案系統，不走對話

兩個工具不能直接對話、那要怎麼合作？答案是檔案系統。

具體說：mockup HTML 是 Designer 跟 Engineer 之間的合約檔。Designer 把視覺規格寫進 mockup、Engineer 照 mockup 實作、我在中間仲裁衝突。沒有「Designer 跟 Engineer 開會討論」這種事——所有合作都透過 mockup 這個檔案進行。

「合約」跟「參考」的差別不是字面、是衝突發生時的處理方式：

• 參考模式：Engineer 看到 mockup nav 是兩項、覺得「四項比較豐富」→ 改成四項
• 合約模式：Engineer 看到 mockup nav 是兩項、不能改、要 push back 給 PM「mockup 是兩項、確認照做嗎？」

合約模式的價值是保護設計決策不被執行層稀釋。Designer 為什麼選兩項，他有他的脈絡。Engineer 的「四項比較豐富」是直覺、不該覆蓋脈絡。

這個設計也回頭解決了要件一的副作用——既然兩個工具不能對話、總要有合法溝通的管道。檔案系統就是那個管道。沒有合約檔，要嘛 Designer 被迫看 codebase（污染）、要嘛 Engineer 被迫詮釋設計（角色越界）。合約是讓隔離可運作的機制、不是裝飾。

要件三：人類是橋接層、不是傳訊員

在這套架構裡、人類不是 idle、是核心。但角色不是「forward 訊息」、是「做策略決策」。

差別具體在哪？

• 傳訊員：把 Designer 出的 mockup 整份 forward 給 Engineer、沒判斷
• 橋接層：判斷哪些 mockup 細節是「必須照做的合約」、哪些是「視覺示意可微調」、把策略 layer 加上去再 forward

實務上：v4 mockup 的 hover 動畫顏色是「視覺示意」、不必精確；v4 mockup 的 nav 兩項結構是「合約」、必須照做。這個區分 Designer 沒有寫進 mockup 裡——是我作為總編輯下的判斷。

另一個更具體的例子：上線那一步、我親手做 Cloudflare Dashboard 操作、沒交給 AI。為什麼？因為上線是不可逆 + 對外可見的動作。自動化的 ROI 不夠（一次性決策、不是反覆執行）。