Claude Code 接 WordPress：MCP 為何越窄越穩

週間深夜，後台還亮著：兩百多篇文章等著補 meta 描述，媒體庫塞滿相機原檔，分類標籤多到沒人敢動，隔天早上還有一篇新稿要發。顧過內容站的人都認得這種晚上，真正要動腦的工作沒幾件，時間卻全被這些不用動腦的事吃光。更磨人的是，每件事都簡單到不值得排進行事曆，加起來卻永遠做不完。

對於把 AI 接進 WordPress，常見的想像走向兩個極端。一種把它當成請到萬能總管，一句話下去，後台從發文到改版全都自動完成；另一種把它想成交出大門鑰匙，風險大到碰都不該碰。兩種想像看似相反，錯的是同一個地方：都把連線當成了能力。

連線成功那一刻，AI 的能力其實最小。MCP 從工具宣告、獨立憑證、capability 驗證，到區塊標記與可恢復批次，每一層機制都在收窄模型的行動半徑，而這些收窄，恰恰是自動化能走進正式站的前提。下面由內往外拆完五層機制，再換算成可以照做的判斷：哪些維運值得交辦、成本什麼時候回本、上游的 Relume 怎麼接、哪些訊號出現該退回 wp-cli。期望先劃清楚：這裡不走一鍵產百篇內容的路，只談維運分工與風險設防。五層機制看起來是技術細節，每層對應的其實都是一個可以照做的檢查動作。

快速重點：MCP 接通 WordPress 只解決通訊，不解決授權。模型看得到哪些工具、憑證綁在哪個帳號、內容帶著什麼標記、批次斷了能不能續跑，這些收窄設計才決定自動化敢不敢走進正式站。連線是起點，越窄越穩。

MCP 給模型的是菜單，不是廚房

接上 MCP 之後，模型實際拿到什麼？答案比多數人想的少。MCP 伺服器向模型宣告的是一份介面清單：有哪些工具可呼叫、每個工具要什麼參數、有哪些資源可讀。模型每一輪從清單裡挑一個來用，僅此而已。它拿到的是菜單，不是廚房的使用權；能走進哪道門、能開哪些爐火，是清單外面的事。

這份清單還有第二個作用，常被忽略：它本身就是給模型的說明書。每個工具的名稱、參數格式、用途描述，模型每一輪都讀得到；描述寫得越精確，模型挑錯工具、給錯參數的機率就越低。反過來說，伺服器若把二十個端點全部取成差不多的名字、描述含糊，模型就只能用猜的。評估一個 MCP 伺服器的品質，讀它的工具清單是最快的方法：命名清不清楚、參數收不收斂、有沒有把不該暴露的動作放進來，一目了然。

這份協議的出處先講清楚。Anthropic 在 2024 年 11 月以〈Introducing the Model Context Protocol〉公開這個開放規格，目的是讓模型呼叫外部工具時有一套統一介面，不必每接一個系統就重學一次。WordPress 這一端，被呼叫的仍然是 REST API，端點涵蓋文章、頁面、分類、標籤、媒體與使用者。但「有端點」不等於「全部可讀寫」，實際能力由四件事相乘決定：伺服器暴露哪些工具、端點開放到哪裡、憑證屬於誰、那個帳號有什麼權限。協議的細節可以搭配MCP 的基礎入門先補齊，這裡直接往維運現場走。

清單的長短，由實作 MCP 伺服器的人決定。有的包裝把 REST 端點整批攤開，模型看得到幾十個操作；有的只開三個動作：列文章、讀單篇、寫草稿。兩種選擇沒有對錯，風險面卻天差地遠。「接上等於萬能」的誤解放到這裡檢驗就會破功：模型的上限不是協議給的，是伺服器作者畫出來的。挑伺服器時，工具清單越貼近你真正要交辦的工作，暴露面越小，這也是後面主張自建薄層的理由。

規模感順手補上。依 W3Techs 的長期追蹤，2026 年 6 月的快照顯示，全世界超過四成的網站都跑在 WordPress 上。這個數字說明批次維運與權限安全是整個生態的公共課題，站的大小都躲不掉；把護欄想清楚再開寫入，比任何加速技巧都值得。

三個名字的分工壓成一段就夠：Claude Code 是坐在終端機前的執行者，讀寫檔案、下指令、來回對話都做得到；MCP 是它與外部系統溝通的共用介面；WordPress 是被操作的那一端。組合的入門與產品全貌，分別有Claude Code 的起步教學與Claude 產品線的完整指南可以對照，這裡不再展開。

驗證通過，為什麼還是被拒絕？

連線除錯時最磨人的狀況，是憑證明明驗證成功，請求卻還是被擋。原因在於 WordPress 端有三道關卡要逐一過：憑證回答「你是誰」，角色決定這個帳號帶著哪一組 capability，端點再從裡面檢查它要求的那一項。三道全過，請求才會成立；驗證通過只代表第一道過了，後面兩道隨時可能把請求擋下來，而錯誤訊息長得就像連線壞掉。

把它變成可操作的排查順序：先打需要登入的唯讀端點，官方〈REST API 驗證指南〉示範的「/wp/v2/users/me」就是現成例子，這步通過，代表憑證與網路都沒問題；文章列表取代不了這一步，公開文章匿名就讀得到，憑證對不對根本沒被驗到。再打單篇讀取，通過，代表角色至少有讀的權限；接著開一篇測試文章做寫入，被拒，問題就鎖在角色的寫入權限，或該端點要求的 capability。同一套邏輯放到 SEO meta 這類外掛提供的欄位上也成立：讀得到設定、改不動設定，缺的不是連線，是那個欄位背後的額外權限。分層走完，多數「連線異常」都會現出原形。

憑證這道關，正確做法是使用 WordPress 5.6 起內建的 Application Passwords（應用程式密碼），不要交出後台主密碼。依 2020 年 11 月的〈Application Passwords 整合指南〉，這組憑證可以單獨產生、單獨撤銷，撤銷不影響主密碼，存取紀錄也分得開。實務上按用途開立：「唯讀盤點」「內容維護」「一次性匯出」三種用途各開一組，哪條管線出事就撤哪一組，不必全部重來。密碼從後台的使用者頁面產生，值只顯示一次，之後看得到的只有名稱與建立時間，配密碼管理工具存放，稽核時也對得上線。

憑證開好之後，緊接著要決定它綁在哪個帳號。另開一個服務帳號，權限壓在任務所需的最底線。WordPress 內建角色的權限範圍並不難查，難的是 SEO meta、自訂欄位與外掛端點常自帶額外的 capability 要求，不能預設「編輯者一定改得動」；先用測試帳號逐項驗證讀寫，真的通過再上線。角色與 capability 的對應關係，可對照WordPress 角色與權限的完整解說。

第三道關卡常常不在 WordPress 本身，而在它前面。正式站的 WAF 與安全外掛可能直接攔下 REST 請求，症狀是莫名其妙的 403 或連線重設。要放行，就只開必要的來源與端點，並確認規則真的生效；若為了除錯而把整組 API 全數放行，前兩道關卡的努力等於一次歸零。安全外掛的設定思路可以參考WordPress 防護外掛的調校方向。

把權限收到最小，聽起來像是不信任 AI，方向其實相反。最小權限的價值，在於讓出事時的爆炸半徑可以先算出來：服務帳號最多弄亂幾篇文章、動得到哪些欄位，事前就知道，撤銷憑證就能止血。可回滾、可撤銷，自動化才有資格走進正式站；一組管理員憑證配上全開的端點，再謹慎的模型也扛不住這種配置下的任何意外。

文章欄位的真相：一段文字背後的區塊標記

五層機制的第三層藏在文章欄位裡。WordPress 的內容欄位是一種混合結構，區塊標記與文字內容共存：每個段落、標題、表格前後都帶著成對的 HTML 註解，編輯器靠這些標記辨識區塊的邊界與屬性。依官方對區塊標記的說明，靜態區塊送進編輯器時還會再驗證一次，標記對不上，區塊就會被判定無效。「看起來只是改幾個字」的寫入會出事，根源就在這裡。舉例來說，一段文字在欄位裡的真正長相，是段落註解包著文字、文字後面跟著成對的結束標記；標題、表格、欄位群組各有自己的註解與屬性，層層相嵌。

區塊標記被當成純文字覆寫，是內容寫入最常見的事故。欄位裡存的不是裸文字，而是帶註解的區塊標記與文字內容的組合；模型若把整個欄位當字串重寫，標記一被吃掉，編輯器會跳出無效區塊的驗證警告，前台排版跟著崩壞。安全做法只有兩條：只改文字、原樣保留標記，或先解析區塊結構再修改對應內容，寫回之後到編輯器與前台各驗收一次。

事故發生後的救援也有固定路徑。編輯器出現區塊驗證警告時，先別急著手動重排：切到區塊的程式碼檢視，比對標記是否成對、屬性值是否完整，多數情況是少了成對的結尾註解或屬性被改壞，補回去警告就跟著消失。救不回來的，把該區塊的文字先複製出來，刪掉壞塊，重開一個同型區塊貼回，比逐行修標記快得多。前台已經崩壞的頁面，先從版控或備份拉回上一版，再重做一次寫入，不要在壞掉的版本上疊修。

同樣的資料形態陷阱還有變體。用頁面編輯器類外掛排版的站，版面常存在自訂欄位或專屬標記裡，只改內容欄位，畫面可能完全不動，因為被改的欄位根本不是畫面的資料來源。接這類站之前，先弄清楚版面存在哪裡，跟處理 Elementor 頁面是同一套思路，可參考Claude Code 維護頁面編輯器版面的三條路。

這一層是整條管線最核心的技術點：它決定了「改字」這個最日常的動作，為什麼不能交給把欄位當文字的模型。後面 Relume 一節把設計元件轉成 Gutenberg 區塊時，踩的是同一顆雷，只是方向相反：那時要憑空產生正確的標記，而不只是保留它。

批次跑到一半斷掉，是常態不是意外

第四層是時間。讓模型處理幾百篇文章，中斷不是小機率事件，是設計時就要假設會發生的事：網路斷線、主機節流、額度用完、模型服務暫停，任何一項都會讓批次停在半路。差別只在於，把中斷設計進去的批次，停了可以接著跑；沒設計的，停了就是一團說不清狀態的半成品。把中斷寫進假設，排程會留緩衝、驗收有對照，重跑本身就屬於流程，談不上事故。

把中斷當常態，批次要備妥三件事：分批保存已處理完成的文章 ID、留一份未完成清單供斷點續跑、讓每個寫入可重複（idempotent）。可重複的意思是同一篇重跑一次結果要一樣，重試時才不用擔心把內容改了兩遍。中斷源也不只有網路與額度，模型供應本身會暫停，2026 年 6 月 Fable 5 就曾因出口管制停了 19 天，這類情境的備援與降級規劃值得一起納入。

三件事的落地形式不用複雜：一份進度檔就夠，每處理完一批，把文章 ID 與結果狀態寫進去，重跑前先讀這份檔，跳過已完成的項目。可重複寫入的關鍵在於更新而非附加：先讀現值、比對目標、不同才寫，避開把新內容接在舊內容後面的做法。附加型的寫入最危險，重跑一次就把同一段話加了兩遍；以整個欄位為單位的設定式寫入，天生就是可重複的。

節流是另一個要事先排進計畫的阻力。正式站的 REST API 會被主機或安全外掛限制請求頻率，幾百篇連續送出一個下午，換來的可能是封鎖，加速只是錯覺。批次要分批送、留間隔、記進度，被擋下來時先分辨是速率問題還是權限問題，不要誤判成連線壞掉而反覆重試。間隔抓多寬沒有標準答案，跟主機與外掛的設定有關，穩妥的做法是從小批量往上試，把被擋的臨界值找出來，之後照著那個節奏跑。

• 症狀：API 回報寫入成功，前台畫面卻沒變。
• 誤判：以為寫入失敗，再跑一次，甚至回頭改設定。
• 處置：先清快取或等快取過期，再判斷成敗。REST 的寫入通常繞過頁面快取，前台吃的卻是快取。

這組症狀、誤判、處置的劇本值得記下來。批次維運裡最貴的往往不是錯誤本身，而是把快取、節流、狀態欄位的副作用誤判成管線故障，多花一個下午找錯方向。上線前先用小批次演練一次中斷後重跑，結果與單次跑完一致，這條批次才算過關。

管線要不要出本機：stdio 起手，遠端是例外

第五層是部署。MCP 伺服器跑在哪裡，決定這條管線的暴露面。沒有多個客戶端共用、或與 WordPress 同機部署的需求，就用 stdio：伺服器與 Claude Code 同機運行，靠標準輸入輸出對話，不必為了讓模型呼叫工具而多開一個對外的服務端點。邊界同時要畫清楚：stdio 規範的只是模型與這台伺服器之間那一段，WordPress 放在遠端主機時，REST 呼叫與憑證仍然要走 HTTPS 出去，只有連站也同機的本機開發環境，整條路徑才真的不出機器；stdio 省下的是多養一個對外端點，不是所有對外連線。遠端模式不是不能用，而是它多出一個要持續維護的對外資產，理由不夠硬就走 stdio。

↔ 左右捲動檢視完整表格

面向	stdio 本機模式	遠端 HTTP 模式
暴露面	不新增對外服務端點	多一個對外端點要守
憑證存放	留在自己機器	放在遠端伺服器，多一層要守
適用情境	單人或小團隊的站內維運	多客戶端共用、與主站同機部署

真的走到遠端模式，維護清單跟著變長：端點要走加密連線、要能限制來源、token 要定期輪換，伺服器本身的相依套件也要持續更新。這些都做得到，只是每一項都得有人長期負責；stdio 省掉的是這整組端點維運，代價只是伺服器跟客戶端綁在同一台機器，而 WordPress 那一端的憑證衛生，兩種模式同樣要做。多數內容站的維運，用不到跨機器的規模。

token 衛生三條：不寫死在設定檔、不進版控、敏感值收進環境變數，或放在本機的 secrets 檔。設定檔可以進版控，敏感值不行。真的事後發現憑證外洩，先撤銷那一組應用程式密碼再說；回頭清理 commit 紀錄是白工，歷史早就躺在遠端了。輪換同樣可以排程：每季撤一組舊的、開一組新的，管線重新讀一次環境變數就完成，成本接近零。

第一次連線照這個順序走：在本機或預備站起跑，正式站完全不碰；為最小權限帳號開一組命名清楚的憑證；先用需要登入的請求確認憑證生效，再抓最近十篇、列某個分類，確認讀得到、讀得對；讀與寫分梯次解鎖，出狀況時才追得出壞在哪一層。連不上查環境，401 查憑證，端點不存在查伺服器的涵蓋範圍，各對各的回退動作。本機練習場從本機 WordPress 的安裝開始最省事。

伺服器本身的挑選也有三個條件：維護活躍、端點覆蓋你實際要交辦的工作、有需要時能自建薄層把工具清單縮到最小。想理解 Claude Code 在這條管線外的其他用法，用它搭出完整網站的流程與擴充機制的說明各接一條路。維護活躍怎麼判斷？看提交紀錄與議題回覆的頻率，星星數當參考就好；端點覆蓋則拿你的交辦清單逐項對，用不到的工具寧可沒有。自建薄層的門檻也比想像中低：把 REST 包成三五個工具的伺服器，程式量跟一份設定檔差不多，換到的是工具清單完全透明、出事時自己就能修。

哪些維運工作值得交辦，哪些永遠親手按鍵

機制拆完，換成交辦的判斷。一項 WordPress 維護工作能不能交給 AI，看三個條件：出錯可回滾、事後可驗收、量大而重複。三個全過，進交辦清單；缺任何一個，不進。標準不在於你對 AI 信任多少，在於這件事做壞了，救不救得回來。三個條件也決定了交辦的形式：可回滾的工作交批次，可驗收的工作交草稿，量大而重複的工作才值得寫成固定流程。

過得了三關的工作，實務上集中在這幾類：

• meta 描述與 SEO 標題的草稿：找出缺漏的文章，依內文生成候選，人掃過再定稿。
• 結構化資料盤點：依頁面可見內容判斷適用的型別，標出缺漏與標記錯誤。
• 媒體庫大圖候選清單：整理檔案大小，列出超過門檻的項目與所在頁面。
• 內部連結與叢集結構的梳理：讀全站找關聯，建議該補的連結與該併的叢集。
• 分類與標籤整併提案：標出重複與孤立的項目，合併的決策留給人。

用三關逐一檢視這份名單，會看到同一個形狀：meta 草稿動的是單一欄位，寫壞了改回來就好；結構化資料先出盤點表，根本還沒碰到站；大圖清單是純唯讀的產出；內部連結的建議落地成提案，補幾條由人決定；分類整併給的是對照表，合併前還有人工確認。五項全部停在草稿與清單層，正式寫入只發生在核可之後，這就是篩選條件的實際長相。

名單的共通點，是產出以草稿或清單的形式存在，定稿權在人。相對地，五個動作永不自動執行：刪除文章或媒體、改文章的固定網址、改使用者帳號或權限、直接讀寫資料庫、對正式站做未驗證的批次覆寫。它們的共通點是不可逆或影響面太大，模型可以把候選清單整理得再漂亮，收尾那一下點擊都得是人按的。固定網址尤其敏感：一改，外部連結、搜尋結果與社群分享一起失效，等於親手拆掉累積多年的路徑資產；真要改，走重新導向、逐篇人工確認，與自動化無關。

草稿與定稿的界線要落成操作。讓模型一次出十到二十篇候選，集中掃三件事：事實對不對、語氣像不像你的站、意圖有沒有偏。這段掃描就是人的工作本體：模型把體力活吃掉，判斷留下來。研究端的資料收集要接進流程，可以併用Perplexity 與 Claude Code 的分工工作流，一個找資料、一個動手改。事實查核的重點放在數字、專有名詞與連結：模型給的數據要找得到出處，人名與產品名要拼對，內外連結要真的存在，這三樣錯了，讀者一眼就看穿。

效能類的交辦要先把話說窄。載入速度會直接左右使用體驗（web.dev 有專文說明）；頁面體驗在排名系統裡只是眾多訊號之一，地位不凌駕內容相關性（依 Google 2020 年 5 月的〈Evaluating page experience〉）。但一張大圖會不會拖累 Core Web Vitals，要看它是否出現在關鍵頁面，也要看實際測量。模型負責讓問題被看見，修復要照WordPress 圖片優化的正確做法走，先後順序依Core Web Vitals 與 SEO 的關係裡的測量結果排。

這條管線最獨特的紅利，是讓模型讀完一個站之後，回報它看到的結構問題：孤立的支柱頁、失聯的叢集、名實不符的分類。全站層的健檢視野，單獨寫在Claude Code 做 SEO 健檢的用法裡，與單篇修改是兩種不同的工作。這種讀後回報的能力，也是人工盤點最難複製的部分：人看站是一頁一頁看，模型是一口氣讀完再互相對照，遺漏的結構問題自然浮得多。

AI 交回來的批次，怎麼驗收、怎麼退回

交辦之後，品質靠驗收規則守住。以十到二十篇為一個核可單位，抽驗三個重點：事實、語氣、狀態欄位。前兩項決定內容能不能見人，第三項決定它會不會在不對的時間見人。沒有驗收規則就上自動化，等於把品質交給運氣，跑得越順，出事時越難察覺。核可單位抓十到二十篇，是掃描品質與節奏的平衡點：再大，人的注意力會滑掉；再小，核可本身變成另一種重複工作。

回滾靠三層疊上去：變更先在預備站驗證、寫入前匯出備份、正式站只收已驗證的變更。這三層與黑名單互為表裡，黑的擋在前面，灰色的靠回滾兜底。核可程序本身不複雜：候選草案集中成一份清單，固定時間掃一遍，檢查有沒有誇大的承諾、關鍵字讀起來自不自然。備份不必求完美，寫入前匯出該批次涉及的文章就夠用，出事時逐篇貼回，比全站還原快得多。

• 症狀：一篇未校稿的草稿突然出現在線上，或一篇流量穩定的舊文無聲消失。
• 誤判：以為遭入侵或外掛衝突，往資安方向查半天。
• 處置：先查該批次的狀態欄位設定，寫入時明確指定狀態，並逐批抽查真實狀態。

繁簡字是繁體中文站的固定關卡。不少工具與模型面對中文時預設吐簡化字，寫入前若沒檢查，一波之間整批文章就換了字集；寫入前固定跑一次繁簡檢查，比事後逐篇修回來便宜太多。檢查本身可以交給腳本：比對字集與常見的簡化字，命中率高的篇章再人工複查，放進流程就不依賴記性。

自動化之後，時間往哪裡投

維運被接手，多出來的力氣才有機會變成差異化。方向只有一個：投到模型做不來的事，親自操作、實測、把只有你寫得出的觀察寫下來。工具放大的是既有積累，變不出你本來沒有的東西；反過來說，量產時代的第一手經驗越稀缺，它換到的注意力就越多。

把經驗變成資產的方法很具體：實測時留下截圖與數據，記下當下的判斷與事後的結果，把踩過的坑寫成可重做的步驟。這些材料模型生不出來，同行也抄不走，累積幾年就是內容站最硬的差異化。維運自動化換到的時間，正是拿來累積這些材料的本錢。

經驗寫進內容時要能被驗證：案例交代情境、限制與觀察方式，數字交代來源與期間；沒有證據支撐的，就老實保留為一般建議，不替作者補造經歷。這條線守得住，自動化省下的時間才會沉積成主題權威，別流於又一批格式整齊的量產文。省下來的力氣往哪裡去，可以循AI 時代的 SEO 經營框架與內容行銷的策略層規劃，把時間花在算得出複利的方向。

站還不存在時，上游從 Relume 開始

前面都在講站已經存在的維運；另一種起點是站還沒有，或準備整個改版，頁面架構與線框都還在紙上。這段上游有專門工具：Relume。依官網的定位，它把一段網站簡介變成 sitemap 與 wireframe，頁面不是模型即興生成的，而是從設計師建立、持續打理的現成元件庫裡挑選拼裝。它在各種 AI 建站服務裡的位置，可以對照七款 AI 網站建立工具的實測，「版面有人把關」是它跟其他生成服務最明顯的分野。

規劃段的產出是草稿，不是定案。sitemap 怎麼切、wireframe 畫到多深，網站架構圖的規劃方法與Wireframe 線框圖的入門提供完整的方法論；Relume 生成之後，併頁、調整層級、對齊轉換動線，這些架構判斷仍然是人的工作。

Library MCP：拿真元件，不是即興 UI

官方提供的 Relume Library MCP，讓取件這步不必離開模型。接法沒有特別之處：在設定檔登錄端點、以 Relume 帳號完成登入授權，再照官方說明頁把路徑別名與 preset 這類一次性設定走完。之後用自然語言描述需求，模型會在元件庫裡檢索，指名 slug 拿到該元件的原始碼，落地成專案裡可直接編輯的 React 檔案。被 AI 幻覺 UI 困擾過的人會懂這個設計的分量：生出來的版面起碼經過設計師之手，響應式也已經處理好。按 slug 取件的價值在於確定性：同一個 slug 拿到的永遠是同一份元件，版本與程式碼可控，不會這次拿到 A、下次拿到 A 的變體。

計價先講原則再講數字。免費方案可以跑規劃與體驗，匯出受限；訂閱落在每月十幾到四十美元的區間，依方案與人數浮動。以上是 2026 年 9 月底從官網定價頁抄下的數字，實際售價以頁面即時顯示為準。對走 WordPress 路線的人，更關鍵的事實是：匯出目標只有 Figma、Webflow、React 三條，沒有 WordPress。這不是缺陷，是分工，補上這段轉譯的正是 Claude Code。免費額度夠做完一次完整評估：跑一輪規劃、試一次匯出、抓幾個元件，值不值得付費，走完自然有答案。

從 React 到 Gutenberg 的轉譯關卡

轉譯段是上游鏈的技術核心，踩的正是前面區塊標記那顆雷，方向相反：那裡要保留既有標記，這裡要憑空產生正確的標記。React 元件不能直接貼進 WordPress，落地時讓 Claude Code 拿元件的畫面結構當藍圖，以群組、多欄、標題、段落、按鈕這幾種核心區塊把版面重搭一次，樣式收進佈景或自訂 CSS，寫入後先查編輯器有無區塊驗證警告，再到前台確認響應式。視覺流程若在 Figma，先匯出到 Figma 再交給模型也是一條路，做法參考Figma MCP 的串接實作；從設計稿一路到上線的另一條完整工作流，見Stitch 設計稿接 Claude Code 的案例。轉譯後的自查清單是固定的：編輯器沒有驗證警告、前台桌機與手機各看一遍、按鈕與連結點得動、圖片有替代文字，清單跑完才輪到寫入。

用一個假設情境把全鏈走一遍。假設接到一個單車配件品牌的官網案，預算只夠做五頁：把品牌定位與主打賣點寫成一段簡介交給 Relume，生成的 sitemap 長出首頁、產品線、規格比較、品牌故事、常見問題；把常見問題併進產品線、把規格比較改名對照表，使資訊層級貼著轉換動線走。接著由模型經 Library MCP 取用定價表與 FAQ 兩個元件，翻成 Gutenberg 區塊，先在預備站把頁面組起來、調好響應式、確認零驗證警告，整套過關才落回正式站。全程跑完，最耗工的環節落在資訊層級與文案，而這正是該有的狀態：版面勞務被壓縮，人的判斷升為主角。轉譯前先把元件對照表寫下來：哪個元件對應哪些核心區塊、樣式放在哪裡，五頁的案一頁一頁過，比事後整套修省力。

划算與不划算的分界

並非每種情境都值得走這條路。每月固定接行銷站的工作室、需要快速迭代Landing Page 原型的團隊、主力本來就在 Tailwind 技術棧上的班底，訂閱費攤進報價通常划算；一年只改一次版的單一站長，用免費額度把流程玩過一輪就夠。評估方法很樸素：把訂閱費當成版型產能的外包支出，跟它換到的可審版型數量比一比，值不值得一目了然。另一種算法是機會成本：每月花在手刻版型的時間，若拿去多接一個小案或寫一篇實測文，產值往往超過訂閱費；站少、改版少的人，這筆錢就只是閒置支出。

同質化是共享元件庫的代價，上千個元件大家都在用。務實的緩解，是把品牌色彩、字級、間距先整理成設計系統；Relume 也提供把設計系統匯入 Claude Design 的匯出功能，讓後續產出跟著你的規範走，不再套預設樣式，與Claude Design 的功能對照著看會更完整。三段交接口沒有一個是全自動：從架構取捨、品牌識別、區塊驗收到寫入護欄，每個關卡都要人點頭。整理設計系統的過程，本身也是一次品牌盤點：色彩、層級、間距的規則被迫寫清楚，這份副產品對外包設計同樣有用。

什麼時候該退回 wp-cli，什麼時候根本別架

工具用順之後，要練的反而是收手。三個訊號出現，這條管線就是繞遠路：條件結構固定，例如固定匯出全部文章，命令列最快；需要當下閱讀與判斷，例如單篇內容的取捨，回後台讀完再動手；動作不可逆，刪除、改網址、改權限，永遠人工逐筆。自然語言下條件的價值，在條件複雜時才兌現：跨欄位的組合篩選、要讀上下文才能判斷的清理，這種工作命令列寫起來痛苦，才是模型上場的位置。

工具的界線也值得看清楚。wp-cli 處理結構固定的工作又快又準，條件一複雜就得回頭寫篩選程式；模型補的正是這一段，把「三年以上、沒有特色圖、分類互相重疊」這類描述直接翻成行動。界線畫在哪裡，看你的條件有多常改、有多難寫成指令；工具新不新，排在後面。

值不值得架，用成本換算回答。建置成本是一次性的：環境、服務帳號與憑證、伺服器挑選或薄層自建、驗收與回滾規則的制定，全是前置投入，之後每次複用。收益端是每月投入的時間乘上出現頻率。只有長期反覆出現的半結構化維運，才攤得平這筆建置；一次性需求，wp-cli 或手動反而省事。把這筆帳算過，很多「好像該自動化」的念頭會自己退場。試算可以很粗：每月花在這類工作的小時數，乘上你的時間成本，跟一次建置的投入比大小就好，不需要憑感覺決定。

回到主軸：單純的事配單純的工具，不可逆的事配最慢、最笨的做法。收窄之後，模型能做的變少，判斷浮上來變成主要工作。這不是損失，是把人放回正確的位置。

五個問題定案，第一天從唯讀開始

走到這裡，給自己一個明確的 go 或 no-go，依序問五個問題。順序有講究：先確認有沒有值得解決的痛點，再確認工作性質可交辦，接著才輪到護欄與規則，成本放在收尾把關。順序反了，容易變成為了用工具而找工作。

↔ 左右捲動檢視完整表格

問題	通過標準	未過時先補什麼
痛點量大而重複嗎	每月累積出可觀的維運時間	先記錄一個月的維運清單
工作出錯可回滾嗎	有備份與預備站可驗證	先建預備站與備份流程
憑證帳號端點三層設防了嗎	服務帳號、最小權限、白名單就位	補應用程式密碼與測試帳號
驗收與回滾規則寫好了嗎	核可單位、抽驗重點、回滾三層成文	把規則寫成一頁清單
成本攤得平嗎	建置成本低於長期節省	退回 wp-cli 或手動

五問全過，從唯讀任務開跑；任一未過，先補齊再說，不急著開寫入權限。第一天不碰寫入，不是保守，是讓每一層護欄都有單獨驗證的機會：環境對不對、憑證通不通、讀回來的資料準不準，一次驗一項。推進順序如下：

1. 把預備站跑起來，正式站完全不碰。
2. 開好最小權限帳號與命名清楚的憑證。
3. 跑一個唯讀盤點任務，感受模型讀全站的視野。
4. 挑十篇做小批試水，完整走一遍核可與回滾。

接通之後能力最小，收窄之後自動化才穩。這套組合最終換到的不是更多文章，是一種分工：重複的維運交給工具，可回滾的批次交給護欄，判斷與第一手經驗留在人這端。第一天從唯讀開始，這條線就畫對了。