Arc UI MCP 教學：讓 Claude Code 用現成元件做出可維護的網站介面
Arc UI MCP 讓 Claude Code 使用現成元件。本文整理安裝、元件引用、課程報名頁需求與維護檢查，區分免費與 Pro 授權，先做一致的網站介面。
同樣請 Claude Code 做一個網站，有時它會寫出漂亮的首頁，有時卻把每個頁面都塞進相似的圓角卡片。等你要加上表單、錯誤提示與手機版，才發現各頁的按鈕大小、字體與間距都不同。
Arc UI 最近在 X 引起討論，值得看的地方是它把介面元件的文件、原始碼與安裝方式，接到 AI 寫程式的流程裡。
本文從一個課程報名頁出發，說明如何使用 Arc UI MCP、如何區分免費與付費元件，以及完成後應檢查什麼。
這是一份依照 Arc 官方文件整理的操作指南。作者在 X 的展示提供了選題線索，沒有替我們證明每個網站都會變好看。下面的報名頁則是教學情境，沒有宣稱已完成實測。
Arc UI 解決的是元件選擇與實作的一致性
一般的 AI 介面生成流程，是你描述畫面，再讓模型自行決定 HTML、樣式與互動。如果專案已有設計系統，模型卻另外造一套按鈕，後續維護就會出現兩種規格。
Arc 提供可查詢的元件，讓 Claude 先了解有哪些選項，再取得對應的程式碼或安裝命令。你仍然需要決定內容順序、視覺方向與使用者要完成的動作。
MCP 可以理解為 AI 工具讀取外部資料的接線方式。Arc 的遠端 MCP 在官方文件中被描述為唯讀服務。它提供元件資訊，不會因為你連上服務就直接改寫專案。
真正把檔案加入網站，仍是 Claude Code 在你的工作目錄執行安裝或編輯。這兩個階段應分別檢查：先確認選的元件正確，再確認程式改動符合原有架構。
以課程報名頁為例，最重要的內容通常是適合誰、上課時間、費用、報名表單與成功後的下一步。你可以先讓 Claude 畫出這些區塊的順序，再用 Arc 找按鈕、對話框與表單。
這樣做的好處，是每個元件都有用途。不會因為元件庫有很多漂亮示範，就把報名頁變成展示元件的目錄。
開始前先看專案條件
Arc 的文件以 React 19、TypeScript、CSS modules 與共用樣式變數為核心，也涉及 @/* 的路徑別名。
CSS modules 讓元件樣式各自管理，路徑別名則是引用專案檔案的捷徑。已有 React 專案的讀者應先確認版本、檔案位置及別名設定。
若網站使用另一種框架，不能把 React 元件直接複製過去，應先判斷是否真的需要新增一套前端環境。單純的活動介紹頁，原有模板可能已經足夠。
另一個常見誤會，是看到元件庫就以為必須另外安裝 Tailwind。Arc 的安裝文件有自己的樣式方式，應以它的實際依賴為準。
請 Claude 先讀專案的套件清單與共用 CSS，列出要新增哪些檔案、為什麼需要，以及是否會影響既有頁面。這份清單很短，卻能避免為了一個報名頁改動全站樣式。
首次試用最好使用可回復的分支或專案副本。先選一個按鈕、一個表單欄位與一種提示訊息，確認它們在桌機和手機都能正常運作，再把其他頁面接進來。
你要比較的是新舊元件能否共存、原有功能是否正常，以及新增樣式有沒有覆蓋到其他畫面。
把 Arc MCP 接到 Claude Code
官方文件提供的遠端連線命令如下。這裡展示的是設定方法，執行前仍應查看當下文件與你使用的 Claude Code 版本。
claude mcp add --transport http arc https://uiarc.dev/api/mcp
完成後依 Claude Code 的連線與登入提示處理。Arc 文件說明，免費帳號也會涉及驗證。可取得哪些元件，則依帳號方案而定。
登入成功不代表所有 Pro 元件都已包含，也不代表你買了一個帳號就能讓整個團隊共用。先確定目前帳號能讀到什麼，再讓模型產生安裝方案。
接著可以輸入：「請先查詢 Arc 中適合課程報名頁的表單、按鈕與成功提示，列出元件名稱、用途、免費或付費限制，以及安裝命令。現在先不要修改檔案。」
這個階段的產物應是一張簡單的選擇表。若模型只給出大段新程式碼，卻沒有說明使用哪個元件，可以要求它重新查詢文件。
官方列出的工具涵蓋搜尋元件、列出元件、取得元件內容、安裝命令與技能內容。一般讀者不用背工具名稱。重要的是知道模型應先查找，再引用。
當它找到多種表單時，可以請它比較「哪一種符合目前專案的欄位需求」，而非把選擇交給一句模糊的「挑最好看的」。
先裝少量元件，再加入共用樣式
Arc 的安裝流程使用 shadcn CLI 與 registry。官方文件也提醒共用的 foundation 樣式應正確引入。
你可以讓 Claude 根據文件提出確切命令，核對來源域名及要寫入的目錄後再執行。不要從社群留言複製一個不明下載連結，當成同一套元件的替代來源。
安裝完成後，先看檔案變更。檢查按鈕元件的位置、共用 CSS 是否只引入一次，以及路徑別名能否解析。如果網站原本有暗色模式，也要核對新的顏色變數有對應設定。
這些問題比首頁截圖更能反映後續維護成本。畫面能開啟只是第一步，元件應該在你原有的建置流程中正常工作。
第一次組頁可以把需求寫得具體一點：「保留目前網站的字體與品牌色。報名頁只放課程名稱、三項適合對象、日期、費用與報名表單。使用 Arc 的既有元件，不新增其他元件庫。
表單送出前顯示欄位錯誤，成功後提供確認訊息。」這樣的指令把內容、樣式與互動一起交代，模型才有明確的取捨依據。
若專案尚未有 components.json，先執行 pnpm dlx shadcn@latest init。已有設定可跳過初始化。接著在 components.json 加入 registry。已有設定時應合併欄位，避免覆蓋原內容：
{"registries":{"@uiarc":"https://uiarc.dev/r/{name}.json"}}
接著依序安裝共用樣式與元件：
pnpm dlx shadcn@latest add @uiarc/arc-foundation
pnpm dlx shadcn@latest add @uiarc/button @uiarc/dialog
在應用程式入口，例如 Next.js 的 app/layout.tsx 或 Vite 的 src/main.tsx，引入一次 @/components/arc/foundation.css。
不想設定 registry 的讀者，也可以依官方頁面使用完整元件網址安裝。上述按鈕與對話框是起步示範，報名表單仍應依實際欄位挑選。
免費 MIT 與 Pro 授權要分開看
Arc 的免費元件依官方授權說明使用 MIT 授權，相關聲明應保留。Pro 元件則適用另一套商業授權。
官方允許的終端產品使用，不等於可以把元件本身重新包裝成模板庫、元件庫或供他人轉售的資源。若你的交付物正是網站模板商品，應在購買前確認用途是否落在授權範圍。
對接案團隊而言，另一個要點是使用者席次與來源碼存取。能把完成的網站交給客戶，和能讓多位同事共用一個帳號，屬於不同問題。
請把實際參與開發的人數、客戶交付形式與是否轉售模板寫成三行，再對照官方條款。遇到條款沒有明確涵蓋的用途，向供應方確認會比事後重做省力。
如果 Pro 安裝流程要求存取 token，應依官方方法管理，不要把 token 寫進公開的程式碼或聊天範例。
你可以請 Claude 檢查變更是否包含帳號資料，但不要要求它把完整 token 印出來當作驗證。對教學文章與團隊文件，也只需提供欄位名稱與設定位置。
報名頁完成後，檢查真正的使用路徑
第一輪檢查從內容開始。先看讀者能否在不捲動很久的情況下知道課程適合誰、何時上課，以及報名要付多少錢。如果重要資訊被放在漂亮的展開區塊裡，應考慮直接顯示。
元件提供互動選項，但不會替你判斷哪些資訊不能藏起來。
第二輪檢查表單。逐一測試空白欄位、格式錯誤、正確填寫與重複送出。錯誤提示應說明如何修正，而不只是「操作失敗」。成功訊息也要清楚告訴讀者，報名已送出還是付款已完成。兩者不能混用。
若網站尚未接上後端，應讓測試畫面明確顯示這只是介面示意。
第三輪檢查鍵盤與手機。用 Tab 依序走過欄位與按鈕，確認對話框開啟後焦點留在合理的位置。小螢幕的長課程名稱不應把價格推到畫面外，輸入錯誤後也不應需要橫向捲動。
這些檢查不需要大型測試計畫，只需走完一條使用者真的會走的報名路徑。
最後看檔案與建置結果。請 Claude 列出新增依賴、修改的共用樣式與尚未接上的功能，讓你知道交付範圍。若只改報名頁，最小的相關建置與頁面檢查通常已足夠。
發佈前再依專案規則做完整檢查。不要把「AI 寫完了」當作已經可以對外收款的證據。
常見問題：元件庫會讓每個網站長得一樣嗎？
有可能，尤其當你沒有提供內容與品牌方向時。元件庫讓技術規格一致，不會自動產生獨特的視覺概念。想保留個性，可以先決定照片使用方式、標題比例、留白與段落順序，再選元件。
如果把差異只寄託在顏色或圓角，換一套元件庫也可能得到相似結果。
已經有設計系統的團隊，適合把 Arc 當作補充，而非一次替換全站。先找出原系統缺少的互動，例如複雜表單或確認對話框，再評估 Arc 是否降低維護工作。
比較時應包含新增依賴與授權成本。單看一張示範圖，很難知道它是否適合你的產品。
把修改要求寫成元件能回答的問題
當第一版不符合期待，先指出可以觀察的問題。像是「手機版的日期比報名按鈕更不明顯」、「輸入錯誤後不知道應修改哪一欄」，都比「看起來不夠高級」更容易改善。
你可以要求 Claude 每輪只修改一組問題，再提供前後畫面與修改檔案。這能讓你判斷改善來自內容調整、元件選擇還是樣式修改。
如果模型建議新增另一個套件，請它先說明 Arc 現有元件為何不夠用。確實缺少功能時，新依賴可能合理。如果只是為了省去理解現有程式碼，新增套件可能讓整個網站更難維護。
同樣的原則也適用於自製元件：先說清楚差異，再決定是否值得承擔維護工作。
團隊可以留下簡短的使用紀錄，包含元件名稱、來源文件、安裝日期、授權種類與採用理由。之後另一位同事要加上候補報名、取消流程或多語言版本，就不必重新猜測第一版怎麼形成。
這份紀錄只需與專案放在一起，避免把完整私人聊天當成唯一文件。
還有一個容易忽略的地方是中文字體。英文展示中的短標籤，換成中文長課名或付款說明後，行高與換行可能不同。檢查時應放入接近正式長度的文案，不要全部使用「測試」兩字。
若要支援兩種語言，讓較長的那一版也完成同一條報名流程，再決定按鈕是否需要固定寬度。
對第一次使用 MCP 的讀者，完成標準可以設得很小：模型能查到正確元件、安裝來源可追溯、頁面可正常建置，以及一位同事能獨立完成報名測試。
四件事都成立後，才有理由把這套做法帶到下一個頁面。這比一次產生十個畫面，更容易知道工具是否真的節省時間。
把視覺參考與產品內容分開整理
如果你提供其他網站作為參考，請指出希望借用的部分，例如標題大小、表單分組或留白節奏。參考網站的照片、文案與品牌識別不應直接混進自己的頁面。
模型容易把「參考風格」理解為複製整個畫面，明確限定用途能讓它保留結構方向，同時使用你自己的素材與內容。
參考圖最好少而清楚。一張說明排版、一張說明色彩，通常比十張互相矛盾的截圖容易處理。讓 Claude 先說出兩者共有的規則，再開始組頁。
這段確認不需要漫長討論，卻能避免在完成後才發現大家對「簡潔」有不同理解。
Arc UI 最值得先試的，是一個內容清楚、功能有限的頁面。完成後若元件選擇更容易追蹤、錯誤狀態更一致，而且你仍能理解檔案如何組成，再逐步擴大。
這樣得到的是可持續修改的介面，而不只是一張漂亮的 AI 截圖。
