給系統設計者2026.06.16

我沒有自己動手改版，而是指揮了一個 AI 團隊來執行

我把自己的網站做了一次沉浸式改版，三頁上線、SEO 100、網址不變。但這篇不講我怎麼 coding，而是講一件更值錢的事：我沒有自己改版，我是當 PM 指揮一個有明確角色分工的 AI 協作結構。真本事不在會用工具，在於會不會設計協作結構。

會用 AI 不是門檻，會設計 AI 的協作結構才是

現在「用 AI 寫程式」已經不稀奇。會的人很多，工具也越來越好用。如果我這篇文章是要告訴你「我用 Claude Code 改版了網站」，那它沒有任何價值，因為這件事人人都能說。

真正拉開差距的地方在更上游：當你一個人面對一個需要品牌判斷、前端實作、視覺設計三種能力的專案，你怎麼把這些能力組織起來？多數人的做法是把所有問題一股腦丟給同一個對話框，讓 AI 一邊想品牌、一邊寫 CSS、一邊調動畫。結果就是每個角色都做得半吊子，因為它們在同一個 context 裡互相干擾。

我這次的做法不一樣。我把自己定位成 PM，把 AI 拆成幾個有明確職責的角色，讓每個角色守自己的邊界、各自 push back、context 彼此隔離。這篇講的就是這套協作結構怎麼設計、為什麼這樣設計。

先講清楚：哪些是真 agent，哪些是我戴的角色帽

在拆解協作結構之前，我必須先把一件事說清楚，否則整篇文章的可信度會崩掉。

網路上很多「我用 AI 團隊做了 X」的文章，會給你一種「我同時跑了三隻線上 agent、它們自己互相對話」的想像。我這次不是這樣，我也不想把它包裝成那樣，因為這種包裝一被追問就破功。

品牌經理是真的有獨立 agent 定義。它有一份獨立的角色定義檔（已經納入版本控制），有自己的硬規則、自己的驗收模式。這部分可以展示、可以引用，是貨真價實的獨立角色。
前端工程師與美術設計師，是我戴的「角色帽」加上跨階段分工，不是三隻同時在線的 agent。工程角色負責把原型 port 進框架、做實作；美術角色對應場景視覺與動畫（其中場景影片是 AI 生成的素材）。它們是我在不同階段切換的工作模式，不是各自獨立運行的程式。

為什麼要這麼小心地講這條邊界？因為這篇文章真正的價值，從來不在「我跑了幾隻 agent」這個數字，而在「我怎麼切角色、定邊界、設計 push back 與驗收」。把角色帽誠實講成角色帽，反而才是真本事所在——它證明我談的是協作結構的設計，不是工具數量的炫耀。

PM 怎麼拆解：定 outcome，不定 how

指揮 AI 團隊的第一個核心技能，是分清楚「我該下什麼指令」跟「我不該下什麼指令」。

我給每個角色的，是 outcome（要達成什麼結果），不是 how（具體怎麼做）。這兩者的差別，決定了你是在當 PM 還是在當一個越界的工程師。

舉一個導覽列的實際例子：

✓ 我該說的 outcome：「Nav 從 4 項精簡到 2 項，對齊 mockup。」
❌ 我不該說的 how：「在 Layout.js 第 23 行改那個 array、用 useState 管手機選單、再加一個某某 className。」

差別在哪？當我說 outcome，我保留了「該不該這樣做」的判斷權，把「怎麼做」交給負責實作的角色，它可以用它的方式達成，遇到不合理還能反推回來。當我說 how，我其實是把自己降格成一個遠端遙控的鍵盤，AI 只是照打，一旦我的指令有錯，它就默默把錯誤實作出來。

這條紀律在 vault 裡我標記成一個反覆出現的協作失誤：PM 角色越界、跨進 how 的層次。改版這次我刻意守住它——品牌經理不寫 CSS，工程師不替品牌做定位決策，美術不決定資訊架構。每個角色只在自己的職責範圍內做決定。

為什麼我要求每個角色「會頂嘴」

第二個核心技能，是要求 push back。

一個只會照單全收的 AI，是最危險的協作對象。因為它會把你模糊、甚至錯誤的指令，原封不動地實作出來，而你要等到結果出來才發現不對。等到那時候，返工成本已經產生了。

所以我給工程角色的規則是：遇到模糊的指令要先 push back、提出疑問，不要靜默照做。這不是讓它變難搞，而是把「發現問題」這件事提前到實作之前。一個會在動手前說「你這個需求有兩種解法、後果不一樣，你要哪個」的角色，比一個埋頭照做的角色有價值得多。

品牌經理的 push back 設計得更激進。它的角色定義裡有這幾條硬規則，我直接節錄：

「既有文件一律當『待挑戰的假設』，不是已確認的事實。」

「你的工作不是整理我說過的話，是逼我做還沒做過的選擇：提供選項與後果，我選，你不替我決。」

這兩條的意思是：我不要一個會幫我複述、幫我整理、讓我感覺良好的助理。我要一個會逼我面對還沒想清楚的決策的對手。AI 的預設行為是迎合，要它做相反的事，必須在角色定義裡明確寫死。

Context 隔離不是限制，是 feature

第三個、也是最反直覺的設計：我刻意讓品牌經理「禁止討論實作」。

它的硬規則寫著：

「禁止討論實作：不談 Three.js、不談 CSS、不談 scroll 實作、不談元件架構。話題被帶向工程時，記下來、拉回品牌問題。」

聽起來像是自廢武功——為什麼要禁止一個角色談技術？答案是：品牌判斷一旦被「這個技術上做不做得到」綁架，就會在「該不該做」還沒想清楚之前，先被「能不能做」打斷。

正確的順序是：先判斷品牌上「該不該」這樣做，這個判斷成立了，再進到工程層討論「怎麼做、可不可行」。如果讓品牌經理一邊想定位一邊想實作，它會在每個品牌決策上自我審查，產出的判斷就被工程可行性稀釋掉了。

同樣的邏輯反過來用在工程角色：它遇到模糊指令要 push back，而不是默默照做，這樣才不會把一個有問題的品牌指令，無聲無息地變成已經寫好的程式碼。

所以 context 隔離的本質，是讓每個角色的判斷力不被其他角色的考量污染。角色邊界 = context 隔離 = 防止「PM 越界寫 how」、也防止「工具搶走人該做的決策」。這不是把手綁起來，是讓每隻手只做它最該做的事。

多視角驗收：同一個成果，用三種眼睛看

角色分工不只用在「做」，也用在「驗收」。

品牌經理的驗收模式，是以品牌視角逐項過 guardrail：通過的項目，用一句話說明為什麼成立；不通過的項目，指出它違反了哪一條品牌決策、給出具體修改方向，並標上嚴重度——blocker（擋上線）、should-fix（該修）、nitpick（小毛病）。

這套驗收的價值，在於它跟「工程驗收」是兩雙完全不同的眼睛。工程驗收問的是「跑不跑得起來、有沒有 bug」；品牌驗收問的是「這個畫面有沒有違反我們的品牌決策」。同一個改版成果，一個能過工程驗收，不代表它能過品牌驗收。多視角驗收抓的就是這種「技術上對、但定位上錯」的缺口。

handoff 損耗：角色之間怎麼傳遞才不失真

當你把工作切成多個角色，就一定會產生角色之間的交接（handoff）。而交接是有損耗的。

角色 A 心裡的 reasoning（為什麼這樣判斷），傳給角色 B 的時候，如果只傳一句摘要，那條 reasoning 的細節就流失了。B 拿到的是一個沒有來龍去脈的結論，它很容易在錯誤的理解上往下做。

我在 vault 裡把這個現象標記成「multi-agent handoff fidelity loss」——多角色交接的保真度流失。對策是兩條：交接時要 structured briefing（結構化的交接說明，而不是隨手一句話），而且要 reference 原始證據，不要只傳摘要。讓 B 能回去看 A 當時依據的原始材料，而不是只能相信 A 給的二手結論。

在這套結構裡，我自己（PM）扮演的是橋接層，不是傳訊員。傳訊員只負責把話從 A 搬到 B；橋接層要負責確保 reasoning 在搬運過程中沒有失真。這個區別，是這整套協作結構能不能成立的關鍵。

我的觀點

我認為，一個人用 AI 的真正天花板，不在於你會不會用最新的工具，而在於你會不會設計協作結構。工具的能力是公開的、人人可得的；協作結構的設計能力不是。前者讓你跟所有人站在同一條起跑線，後者才是拉開差距的地方。

我也認為，這件事跟「跑了幾隻 agent」沒什麼關係。我這次真正獨立運行的 agent 只有品牌經理一個，其他是我戴的角色帽。但這不影響結論——重點從來不是 agent 的數量，而是角色切得夠不夠清楚、邊界守得夠不夠嚴、push back 機制設計得夠不夠到位。一個會設計協作結構的人，就算只用一個 agent 加上幾頂角色帽，也能做出比「同時開五個對話框亂問」更好的結果。

最後，我想說的是：PM 這個角色在 AI 時代不會消失，反而會升值。因為當執行端的能力被 AI 大幅補齊，稀缺的就變成「定 outcome、設計驗收、控制 handoff 損耗、保留關鍵決策權」這些判斷型的能力。這些事 AI 目前做不了，也正是一個人面對 AI 團隊時，最該把自己的時間花在上面的地方。