# 三個 Claude，一個迴圈：我如何把設計探索接到實作上線 > 很多人以為 AI 工作流是一條直線的「流水線」，但真正的效率來自「迴圈」。本文拆解如何釐清三個 Claude 介面的能力邊界，並透過明確的交接檔案，建立一套從視覺設計到程式上線的自動回饋系統。 - Author: Paul Kuo（郭曜郎） - Date: 2026-06-18 - Pillar: 智能與秩序 / Intelligence & Order - Tags: 多 AI 協作, Claude Design, 設計到開發, 工作流, 能力邊界, 迴圈思維, 人機協作 - Canonical: https://paulkuo.tw/articles/three-claudes-one-loop/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR** — 效率不是來自最強的模型，而是清晰的分工。我讓三個 Claude 介面各自補位：Claude Design 負責視覺發想，網頁版 Claude 負責邏輯批判，桌機版 Claude 負責程式實作。它們之間靠三種檔案（草圖、規格書、真實截圖）作為溝通合約。這不是一條單向的流水線，而是一個迴圈：上線後的真實畫面會回頭修正最初的設計。
▶ 聽摘要
AI 合成語音・作者本人聲線克隆
每當要設計新版面，我的工作流程聽起來都很沒效率：同一件事，我會在三個不同的 Claude 介面之間來回傳好幾圈。先讓 Claude Design 把視覺生出來；再丟給網頁版 Claude 拷問「這合不合理」；接著交給桌機版 Claude 寫進程式碼、上線部署；最後，把線上真實的畫面截圖，重新丟回 Claude Design 看哪裡需要微調。 聽起來很繞路，但我越用越篤定：這個「繞」，才是威力所在。 多數人使用 AI 的直覺，是想找一個足夠強大的全能工具，把所有事情塞給它。AI 廠商也樂於販售這種幻想：一個輸入框，就能把想法變成成品。但我的經驗剛好相反。沒有任何一個介面能獨自走完這條路，硬要它全包，結果就是每一步都做得勉勉強強。關鍵從來不是尋找完美的 AI，而是看清每個介面的能力邊界，然後讓它們在各自擅長的領域裡發揮。 ## 三個 Claude：探索者、批評者與建造者 這三個介面的能力特質截然不同，硬體規格再強，也改變不了介面設計帶來的行為差異。 Claude Design 是探索者。它最擅長讓視覺「長出來」：快速生出畫面草圖（HTML mock）、繪製元件，甚至幫你把設計脈絡寫成框架。自從六月更新搬進桌機 App 後，它能直接讀取你的既有程式碼（codebase），這讓它生出來的設計能直接貼合現有的網站風格，而不是憑空畫一張好看卻不能用的圖。但你要它處理複雜的資料串接或互動狀態，它就顯得吃力。它交付的成果，是一份視覺草圖（mock）。 網頁版 Claude（也就是 claude.ai）是批評者。它不負責產出視覺，但極度擅長進行設計批判：會不斷拷問你「為什麼要這樣設計？有沒有更好的取捨？」，並把模糊的設計語言翻譯成工程師聽得懂的規格說明書（spec）。你若叫它直接去寫程式或畫圖，那是找錯人。它交付的成果，是一份規格。 桌機版的 Claude Code 是建造者，負責動手幹活的那一端，也就是上一篇〈[把網站設計系統餵進 AI](/articles/claude-design-sync-codebase/)〉裡講的 Code 工作流。它讀寫專案檔案（repo）、修改網頁元件、測試並部署上線，把想法真正寫進程式。但美感與視覺發想從來不是它的強項。它交付的成果，是實際的程式碼，以及上線後的真實畫面。 我把這三端的能力邊界，以及它們之間怎麼流動，畫成一張圖。 ![Three Claudes, One Loop：Claude Design（探索）、網頁版 Claude（批判）、桌機版 Claude Code（實作）三端的能力邊界，以及一個 explore → critique → implement → reflect 的迴圈](/images/articles/three-claudes-one-loop.svg) 把它們擺在一起，分工就一目了然：一個負責想像，一個負責挑毛病，一個負責落地。它們不是彼此的替代品，而是彼此的補位。 ## 三種檔案，就是 AI 之間的「通訊協定」 三個介面各玩各的，要怎麼無縫接軌？靠的是三種很具體的檔案。Claude Design 把視覺交給建造者，靠的是一份 mock HTML；網頁版 Claude 把判斷交給建造者，靠的是一份 spec markdown；建造者把成果交回探索者，靠的是部署後的 screenshot。簡單整理如下： | 交接方向 | 交接的檔案 | 核心作用 | |---|---|---| | Claude Design → 桌機版 | mock HTML | 定義視覺外觀 | | 網頁版 Claude → 桌機版 | spec markdown | 定義邏輯與實作規則 | | 桌機版 → Claude Design | screenshot | 反饋線上真實呈現的結果 | 這三種檔案，就是三個介面之間的「合約」。當輸入與輸出的規格被嚴格限縮，下一個 AI 才會清楚知道自己該做什麼。 這套流程之所以不會崩潰，不是因為 AI 有多聰明，而是因為邊界與合約足夠清晰。人類團隊也是如此，協作的混亂往往不是能力問題，而是交接模糊。AI 沒有人類的「默契」，你給的接口有多精準，它們的協作就有多順暢。 值得注意的是，過去這些檔案需要人類手動複製貼上，而 2026 年六月的這波更新，核心就是在消滅這些接縫。透過內建的自動同步（design-sync），「探索」與「實作」之間的轉換變得越來越不費力。系統的迴圈結構沒有變，變的是齒輪轉動時的摩擦力變小了。 ## 為什麼你需要迴圈，而不是流水線？ 人們最容易犯的錯誤，是把這個過程當成單向的「流水線」：設計、評估、寫程式、收工。但真實世界是會對設計開玩笑的。 在草圖裡看起來完美的版面，一旦塞進真實的使用者資料、遇上瀏覽器的字體渲染、切換到不同螢幕尺寸（RWD）時，往往會直接崩壞。 因此，程式碼上線不是終點。我一定會把真實網頁的截圖，重新餵回 Claude Design。這叫反思（reflect），讓下一輪的優化建立在「真實長怎樣」的基礎上，而不是建立在「我的想像」上。 這就是流水線與迴圈的本質差異：**流水線假設你第一次就能做對；迴圈則假設你一定會出錯。** 既然錯誤不可避免，不如在系統裡幫「修正」留一條合法的路，讓真實結果自動滾動回起點。 ## 起點對了，後面才不會白忙 前陣子聊到的[設計同步（design-sync）](/articles/claude-design-sync-codebase/)，本質上就是這個迴圈的「起點校準」。 當你把網站的設計規範（如品牌色、字體間距等 tokens）餵給 Claude Design，是在做什麼？是在教這個「探索者」認得你的家門。它畫出的第一筆線條，就會自帶你網站的基因，而不是散發一股廉價、通用的 AI 味。 起點精準，後面滾動的每一圈才會有品質；如果一開始就歪了，你只是在迴圈裡加速迷路而已。這也是[多模型認知協作](/articles/multi-model-collab-website-rebuild/)的核心：重點不是單一 AI 有多聰明，而是如何建立一個有秩序的結構，讓它們互相補位。 ## 永遠把人留在迴圈中央 看完了這套自動化閉環，你會發現一件有趣的事：三個 Claude 都極具威力，但沒有一個知道「這艘船現在該開往哪裡」。 要往哪個方向修正？哪一項功能取捨才符合商業利益？什麼時候該喊停？這些攸關價值的決策，AI 碰不到，也做不好。 工具負責把每一步走得飛快，而人類負責決定方向。三個 AI 跑完一個迴圈，真正賦予這個迴圈意義的，永遠是坐在中間、制定秩序的那個人。