Claude Code + WordPress：MCP 打造 AI 內容管理

回頭想想，不少人都卡在這種日子裡：顧一個好幾百篇文章的 WordPress 站，每個禮拜真正需要動腦的事沒多少，倒是大半時間耗在補舊文章的 meta 描述、檢查結構化資料、掃媒體庫裡那些大到誇張的圖、再幫新文章建分類、拉內部連結。這些活沒有一項困難，但加起來的量足以把人磨成一個 WordPress 的資料輸入員，離內容經營者那個身分愈來愈遠。

經營內容站時，常見維護工作包括補舊文章的 meta 與結構化資料、找出媒體庫大圖、整理分類與內部連結。這些工作有些步驟可以自動檢查或產生草稿，但寫回正式站之前仍要有權限控制、備份與人工驗收。

接下來要談的，就是怎麼用 Claude Code 搭配 MCP（Model Context Protocol，模型脈絡協議）把那個助手真的架起來，讓它直接讀寫你的 WordPress，把機械活吃掉，而你可以保留判斷與經驗。先把一句結論放這裡：MCP 不是要讓 AI 幫你寫更多文章，而是讓 AI 直接走進你的後台，把你早就該自動化的維護工作接管掉。如果你期待的是「一鍵產出五百篇 SEO 長文」，這篇不是給你看的，那條路在演算法與讀者兩端都會反撲。

快速重點整理
‧ MCP 是一個開放協議，讓 Claude Code 透過統一介面讀寫外部資源，WordPress 是其中一個被操作的對象。
‧ WordPress 從 5.6 起內建 Application Passwords，這是外部程式可採用的內建驗證方式之一；不要把後台主密碼交給 MCP server。
‧ 真正適合交給 AI 的是「量大、重複、低判斷」的維護活；刪文、改網址、改權限這類高風險動作要永遠留在自己手上。
‧ 機械活交給 MCP 之後，你的護城河反而更清楚：那些 AI 做不來的第一手經驗，才是內容差異化的來源。

把三個名字先拆開：Claude Code、MCP、WordPress 在這套組合裡各扮什麼角色

很多人把這三個名字混在一起談，好像它們是同一件事，其實角色完全不同。我習慣把它們想成一個三人小組，各有明確分工，湊起來才完整。

第一個是 Claude Code。它是那個會坐在終端機前面、能讀寫檔案、能跑指令、能跟你來回討論的 AI 工作夥伴。跟一般聊天視窗最大的差別在於，它可以直接動你電腦上的東西，回你的不只是一段文字。當你說「幫我把這批文章的 meta 描述補上」，它真的會去開檔案、跑查詢、把結果寫回去，連那份「建議文案」要你自己貼的步驟都省了。

第二個是 MCP。它是 Claude Code 跟外部世界講話的「共用語言」。Anthropic 在 2024 年 11 月以〈Introducing the Model Context Protocol〉一文公開這個開放協議，目的是讓模型不用為每一個工具從頭學一套接法，只要對方提供一個符合規範的 MCP 伺服器，模型就能呼叫它。換句話說，MCP 之於 AI，有點像 USB 之於電腦：你不用為每一台設備生一個專屬插槽，只要符合那個介面就能插上。如果你對協議本身還很陌生，可以先把MCP 的基礎入門看過一遍，再回來這篇看實戰組合會順很多。

第三個是 WordPress。在這套組合裡，它是被操作的對象。WordPress REST API 提供文章、頁面、分類、標籤、媒體與使用者等端點；能否讀寫要看端點、驗證方式、帳號 capability 與外掛設定，不能把「有 API」理解成全部資料都可任意修改（見 WordPress REST API Handbook）。根據 W3Techs 的長期追蹤（2026 年 6 月），WordPress 在所有網站的市占超過四成，因此批次維護與權限安全都不是少數站長才會遇到的問題。

三個角色湊在一起的意義是：你不用再「匯出 CSV、用試算表改一改、再匯入」，也不用每次都寫一個用完即丟的腳本。你用自然語言下指令，Claude Code 透過 MCP 直接驅動 WordPress，把它當成一個可以對話的後台來操作。這個差別聽起來很小，實際用起來會改變你每天的工作節奏。

為什麼我不直接寫外掛或匯出 XML，而要繞一圈走 MCP

講到 WordPress 自動化，多數人第一個念頭是「裝個外掛」或「匯出 XML 再匯入」。這兩條路我都走過，後來才理解為什麼 MCP 是另一個層次的解法。先把四條路線擺在一起比，你會看得很清楚。

操作路線	適合的情境	主要痛點
後台手動	單篇文章修改、需要當下判斷的編輯	量大就崩潰，重複動作磨人，容易複製貼上出錯
wp-cli 命令列	批次、可腳本化、結構固定的重複工作	要會寫指令，彈性差，條件一複雜腳本就難維護
自己寫外掛	長期、跨站重複、需要後台介面的功能	開發與維護成本高，跨版本容易壞，過度工程
MCP + Claude Code	半結構化、需要一點判斷、想用自然語言驅動的維護	要顧資安與節流，正式站要設護欄

手動的好處是可控，缺點是它本身就是你要解決的問題。wp-cli 很強，我自己也常用，但它的本質是「你得先知道你要下什麼指令」，條件一複雜，例如「找出過去兩年、分類是 A 或 B、字數少於八百、且沒有特色圖片的文章」，你就得組一串參數或回頭寫 PHP，這對非工程背景的內容工作者並不友善。

寫外掛則是另一個極端。它很適合長期、穩定的需求，但對「我這禮拜想把舊文的 meta 描述補一輪」這種臨時、一次性、又帶點判斷的工作，開一個外掛是過度工程。你會花在寫外掛的時間比直接手動還久，而且外掛一旦寫下去，就跟著 WordPress 的版本更新一起老化。

MCP 可以讓 Claude Code 呼叫 WordPress 相關工具，但實際能力取決於 Server 暴露的操作、認證與底層實作，可能使用 REST API、wp-cli 或其他介面。自然語言適合描述批次條件，例如找出標題含「2024」但內容尚未更新的文章；執行前仍要確認篩選結果、權限與回復方式。若要把研究端接進流程，可參考Perplexity 與 Claude Code 的 WordPress 雙工具工作流。

當然這條路也有它的代價。它要求你對資安與節流有基本認識，也要求你接受「AI 偶爾會誤判、需要你親自攔下來」這件事。如果你今天的需求只是匯出一份靜態報表，或做一次性的資料搬家，老老實實用 wp-cli 反而更直接、更省事。MCP 真正發揮價值的場景，是你預期這類半結構化的維護活會長期、反覆地出現，值得花一次心力把管線架好，之後每次都能用一句話驅動。把這個前提想清楚，你才不會把工具用在不對的地方，回頭再怪工具不好用。

在正式站開 API 之前，先把這三道鎖裝好

要讓 AI 走進你的 WordPress，第一件事不是連線，是設護欄。很多人一聽到「把後台 API 開給 AI」就警鈴大作，這個直覺是對的，但風險完全取決於你怎麼開、開多寬。把下面三件事做好，這套組合的安全水位其實比你想的高。

第一道鎖：用 Application Passwords，不要用主帳密

WordPress 從 5.6 開始內建 Application Passwords（應用程式密碼），讓外部程式使用可單獨撤銷的憑證，不影響後台主密碼（見 2020 年 11 月的〈Application Passwords: Integration Guide〉整合指南）。它是 WordPress 內建選項，不是所有架構唯一可用的驗證方式；無論採哪種方式，都不應直接交出主帳密，並要能撤銷、限制權限與稽核。

實務上，我會為每一個用途各開一組應用程式密碼，例如「Claude Code 唯讀測試」「Claude Code 內容維護」「一次性匯出」各自獨立。這樣哪天發現哪一組被濫用，直接撤銷那一組就好，不用全部重來，也能從存取紀錄回溯是哪一條管線出問題。

第二道鎖：最小權限帳號，不要用管理員

開完應用程式密碼，下一個問題是憑證綁在哪個帳號。另建服務帳號，權限只給到任務需要的最低層級。WordPress 內建角色能做什麼相對明確，但 SEO meta、自訂欄位與外掛端點可能有額外 capability；不要預設「編輯者一定能改」，要先用測試帳號驗證。可參考WordPress 的角色與權限機制。

第三道鎖：防火牆白名單，而且本機優先

正式站的 WAF 或安全外掛也可能攔截 REST API。若確定要放行，應只開必要來源與端點，並確認來源 IP 是否固定、路徑規則是否真的有效；不要為了排錯把整個 API 加入白名單。第一次連線與新工作流應先在本地或預備站驗證，再以最小批次進入正式站。可參考WordPress 安全外掛的設定思路。

一條可重現的最小連線：把 WordPress REST API 接成 MCP 伺服器

護欄裝好之後，來把連線真的拉起來。我把整個過程拆成五個動作，你照著走就能得到一條可重現、可撤銷的最小連線。這裡的重點不是哪一套現成工具，而是流程本身要可回溯，因為這條連線將來一定會需要重新設定或撤換。

1. 準備一個乾淨的環境。第一次串接不要直接上正式站，用本機的 WordPress 或主機商提供的預備站。本機架站如果還沒碰過，可以從本機 WordPress 的安裝流程開始，先把一個可以隨意玩壞的環境準備好。
2. 開一組應用程式密碼。在後台的使用者設定裡，為那個最小權限帳號產生一組應用程式密碼，命名清楚標記用途，產生完立刻複製到密碼管理工具，不要留在記事本或聊天訊息裡。
3. 挑一個 MCP 伺服器實作。社群已經有不少把 WordPress REST API 包成 MCP 伺服器的開源專案，挑一個維護活躍、支援你需要的端點的來用。如果你會寫一點程式，也可以自己架一個薄層，只暴露你要的那幾個操作，攻擊面會更小。
4. 在 Claude Code 設定檔註冊這個伺服器。設定時，網址、帳號、token 一律走環境變數，絕對不要寫死在設定檔裡，更不能進版控。設定檔可以進版控，但值要走環境變數或本機的 secrets 檔，這是基本衛生。
5. 先用唯讀端點驗證。連線設定好，第一步只做 GET，例如抓最近十篇文章、列出某個分類下的文章。確認能讀、能回正確結果，再慢慢放寬到寫入操作。讀寫分階段開放，出問題時你才知道是哪一層壞掉。

走完這五步，你手上就有一條「Claude Code 講一句話、WordPress 後台就動一下」的管線。接下來的問題不再是「怎麼連」，而是「哪些活值得交給它、哪些不值得」。這才是真正要花腦筋的地方。如果你想更完整理解 Claude Code 本身的工作方式，用 Claude Code 搭網站的實戰流程跟Claude Code 的擴充機制兩篇會補上這部分的脈絡；想把 Claude 整個產品線一次看懂，Claude 完整使用指南則是總覽的起點。

stdio 本機還是遠端連線？這個架構選擇會決定你的風險面

連線拉起來之後，有一個容易被略過的架構決策得談：你的 MCP 伺服器要用哪種傳輸模式跑。這件事聽起來很技術，但它直接決定你的風險面，值得在還沒大量使用之前先想清楚。

第一種是 stdio，也就是 MCP 伺服器跟 Claude Code 跑在同一台機器上，兩者透過標準輸入輸出溝通。這是我最推薦的起手式，因為它整條管線不出本機，token 不會經過網路，外部根本碰不到。對絕大多數內容維護場景，stdio 已經夠用，而且風險最低。

第二種是遠端的 HTTP 或 SSE 模式，伺服器跑在別台機器上，透過網路呼叫。這種模式適合你真的需要讓多個客戶端共用同一個 MCP 伺服器、或伺服器得跟 WordPress 同主機部署的情境。便利的代價是攻擊面變大：遠端端點等於對外開了一扇門，那組驗證用的 token 就成了必須嚴格保護的資產，傳輸過程要加密、端點要設存取限制、token 要定期輪換。除非你有明確的分散式需求，否則沒有必要為了遠端而遠端。

還有一件跟傳輸模式無關、但做批次工作一定要懂的事：可恢復性。當你讓 AI 處理幾百篇文章，最怕的不是它做錯，而是做到一半斷掉。網路中斷、速率限制、token 用完，任何一個都會讓批次停在半路。所以批次工作要有兩個設計：第一是把進度寫下來，每處理完一批就記錄已完成的文章 id，斷線後從斷點續跑，不要從頭再來；第二是讓每個寫入操作可重複，同一篇文章重複跑一次結果要一樣，這樣你重試時不用擔心把資料改兩遍。這兩個習慣看起來囉嗦，卻是區分「玩玩具」跟「真的上線」的關鍵。一個不能續跑的批次，量一大就會從助手變成你的噩夢。

五件我會真的交給 Claude Code 跑的 WordPress 內容工作

連線通了，不代表什麼都丟給它。接下來這五件，是在實際維護流程裡反覆驗證過、值得交出去的工作。它們的共同特色是量大、重複、判斷門檻低，AI 做得又快又比人穩，而你被解放之後可以把時間拿去做真正需要經驗的事。

補舊文的 meta 描述與 SEO 標題

老站常見的債，是部分文章沒有 meta 描述，或標題已不符合目前內容。Claude Code 可透過 MCP 找出候選文章、依內文產生描述草稿，再由人員確認搜尋意圖、事實與語氣。能省多少時間取決於文章品質與驗收規則；AI 給的是草稿，不是定稿。

這個工作流的關鍵，在於把草稿與定稿的界線畫清楚。我自己的做法是讓 AI 一次產生十到二十篇的候選 meta，集中丟進一份清單，再花十分鐘親自掃一遍：語氣順不順、有沒有誇大不實的承諾、關鍵字塞進去讀起來自不自然。看起來像多一道手續，這十分鐘恰恰是我這個人最該花時間的地方。AI 把八成的體力活吃掉，我只剩下那兩成需要判斷的部分要顧，產出反而比我從頭硬寫五百篇更穩，因為人不會寫到第三十篇就開始交差了事。這個節奏是實際跑過幾輪之後才會摸索出來的，建議你用小批核可的方式上線，不要一開始就讓它一次跑全站。

補結構化資料

結構化資料是另一個長期欠債區。可依頁面可見內容判斷是否適用 Article、Product 等型別，並依 Google 文件補建議屬性；Article 沒有必填屬性。FAQ 結構化資料仍可表達內容語意，但 Google 已於 2026 年 5 月停止顯示 FAQ 複合式搜尋結果（見 Google 的 FAQ 複合式搜尋結果說明文件），不能再把它當成取得 FAQ 搜尋外觀的方法。這類修改仍要走「AI 提案、人類核可」，避免標記不存在或使用者看不到的內容。

媒體庫大圖掃描與壓縮建議

未壓縮的大圖可能拖慢載入。AI 可透過 API 整理媒體清單與檔案大小，標出超過門檻的候選檔案；是否影響 Core Web Vitals 還要看圖片是否實際出現在關鍵頁面、載入方式與真實測量。後續可參考WordPress 圖片優化的完整做法。

內部連結與主題叢集梳理

內容一多，內部連結就會亂。有些新文章沒連到相關舊文，有些支柱頁面孤立在角落沒人指過去，整站的主題叢集散成一盤沙。這種梳理工作需要「理解每篇文章在講什麼、彼此的關係是什麼」，正好是 AI 拿手、而人類做到崩潰的事。你可以讓它分析全站文章，建議該補哪些內部連結、哪裡該有支柱頁、哪些文章其實該併成一個叢集。這也是我一直強調的主題權威做法，想深入可以讀AI 時代的 SEO 完整指南，把叢集策略跟 AI 工具搭在一起看會更有感。

分類與標籤整併

分類與標籤是維護越久越亂的兩個地方。一開始大家隨手建，三年後回頭看，會發現同義的標籤建了三四個、有些分類只有一篇文章、有些分類名稱根本重複。這種清理需要讀懂每個分類標籤底下文章的脈絡，再決定怎麼併，AI 在這裡可以幫你把候選清單整理出來、標出重複與孤立項目，你來做最後的合併決策。合併分類會牽動網址與選單，所以這一步一樣要人工核可，不要讓 AI 直接動手。

五件我絕對不讓 AI 自動執行的高風險動作

把可以交出去的講完，更要緊的是講清楚哪些千萬不能交出去。我把它列成一張黑名單，這些動作的共同點是「後果不可逆，或影響層面太大」，再省時間都不能讓 AI 自己跑。

禁止自動執行的動作	為什麼危險
刪除文章或媒體	資料一旦消失救回成本極高，AI 對「該不該刪」的判斷不夠穩，必須逐筆人工確認
改動文章的固定網址（slug）	網址一改，所有外部連結、搜尋結果、社群分享立刻失效，等於自斷 SEO 資產
修改使用者帳號或權限	權限變更直接影響安全邊界，這是只有網站管理者自己在清醒時才能做的事
直接讀寫資料庫	繞過 WordPress 抽象層動資料表，一個欄位寫錯整站可能掛掉，永遠走官方 API
對正式站做批次覆寫	沒走預備站驗證的批次寫入，一旦邏輯有誤就是全站受害，正式站永遠只收經驗證的變更

這張表的精神只有一句話：凡是不能輕易回滾的動作，都要一個人類按下確認鍵。AI 可以把要刪的、要改網址的、要調權限的清單整理得漂漂亮亮，但最後那一下點擊，永遠是你的。這不是不信任 AI，是對不可逆動作的基本尊重。一個內容站累積好幾年的東西，值得你在高風險操作上多花十秒鐘親自看一眼。

機械活交給 MCP，經驗留給自己：E-E-A-T 才是護城河

把上面這些工具用順之後，你會慢慢發現一件有趣的事：當機械活被接走，你反而更有時間做那些 AI 真的做不來的事。而那些事，恰恰是搜尋引擎與讀者最在意的部分。

E-E-A-T 裡的 Experience 指第一手經驗。AI 可以整理素材，但不能替作者捏造做過的專案或搜尋結果變化。若要加入案例，應提供可驗證的情境、限制與觀察方式；沒有證據時，就保留為一般建議。

所以我一直有一個看法：MCP 之於 WordPress 的真正價值，不是讓你產出更多內容去跟別人比量，而是讓你從重複維護裡脫身，把精力集中在你獨有的經驗與觀點上。當所有人都在用 AI 量產格式整齊但空洞的內容時，那個願意花時間把親身經歷寫進去的人，反而會被演算法與讀者同時看見。也因此，我會建議你把省下來的時間，投到內容行銷的策略層，別再拿去堆更多文章。

把這件事再講具體一點。機械活被接走之後，多出來的時間最該拿去做的，是那些 AI 複製不來的事：親自跑一趟服務現場、把一個外掛實際裝起來玩一輪、把自己操作過的觀察寫成只有你寫得出的觀點。這些事沒有捷徑，也沒有任何 API 可以呼叫，但它們累積出來的厚度，正是讀者在 AI 內容氾濫的時代裡願意停下來看的理由。把例行維護交給機器，把判斷與經驗留給自己，這條分工線一旦畫清楚，你的內容就會多出一層別人怎麼抄都抄不走的東西。這也是我對這類工具始終保持的一個態度：它們放大的是你本來就有的東西，如果你本來就沒有累積經驗，工具也變不出來。

效能與 SEO 不是順便：MCP 幫你看見問題，修復要走路徑

把 AI 接進 WordPress 之後，它會順便變成你最好的「網站健檢助手」。因為它能讀到全站的結構，那些你平常懶得看的技術債，會被它一項一項攤在陽光下。但這裡有一個分寸要拿捏：AI 適合負責「發現問題與排序」，修復這一步要照規矩來，不能因為它建議了就貿然動手。

速度直接影響使用體驗（見 web.dev 的說明），頁面體驗也是排名系統眾多考量之一，但不會取代內容相關性（依 Google Search Central 部落格 2020 年 5 月的〈Evaluating page experience〉）。透過 REST API 可盤點圖片與部分設定；要判斷載入速度或外掛衝突，仍需搭配瀏覽器與效能測量工具。先理解Core Web Vitals 與 SEO 的關係，再依測量結果排序修正。

這個分工很值得記下來：AI 負責讓問題被看見，人類負責讓修復走對路徑。前者交給 MCP，後者交給你跟正確的指南。兩邊各自做好本分，網站的技術體質才會真的變好，儀表板上的數字也才會是貨真價實的進步。

踩坑清單：token 外洩、快取誤判、Gutenberg 區塊被吃掉

這套組合用久之後，有些坑你遲早會踩。以下把常見的坑列出來，讓你少走幾步冤枉路。這些都不是理論，是實際會讓你多花一個下午找蟲的狀況。

token 進了版控。最常見也最致命的失誤。設定檔看起來乾淨，但 token 被你寫進去之後一次 commit 就出去了。養成一個習慣：所有敏感值走環境變數，commit 之前掃一眼差異，任何看起來像亂數字串的東西都要攔下來。一旦發現外洩，第一個動作是撤銷那組應用程式密碼，不是去改 commit 紀錄，因為歷史早就在遠端了。

快取外掛讓你以為沒改成功。你明明寫入了，前台卻還是舊的，於是你以為連線壞了又改一次，結果改了好幾遍。REST API 的寫入通常會繞過頁面快取，但前台是吃快取的，改完要記得清快取或等它過期，不要在這一步誤判成連線問題。

Gutenberg 區塊標記被吃掉。這是寫入內容時最容易出事的點。WordPress 的文章內容其實是一堆帶註解的區塊標記，如果 AI 把整段內容當成純文字覆寫回去，那些區塊結構就壞了，前台可能直接排版崩潰。處理內容欄位時，要嘛只動文字本身、保留標記，要嘛用區塊解析的方式處理，千萬不要把整段內容當字串硬塞回去。

速率限制與節流。正式站的 REST API 不是讓你無限狂打的，主機或安全外掛都會節流。批次工作要分批、要睡一下、要記錄進度，不要一次幾百篇連續送，否則你會被自己人多請求觸發的封鎖擋在外面，還以為連線壞了。

繁簡轉換誤判。繁體中文站要特別小心，有些工具或模型預設輸出簡化字，一波寫入下去，整批文章就跑了簡體。寫入前固定做繁簡檢查，確保輸出是繁體，這條在台灣站是非遵守不可的地雷。

草稿與發佈狀態被搞混。透過 API 寫入時，狀態欄位要明確指定，不然很容易把一篇還在草稿的東西寫成發佈，或把已發佈的舊文改回草稿。批次操作前先把目標狀態講清楚，寫完逐批抽查，確認文章的真實狀態跟你預期的一致。這個錯誤不會讓網站掛掉，卻可能讓一篇沒校稿完的內容突然上線，或讓一篇流量穩定的舊文莫名從前台消失，兩種都很難在第一時間發現。

把這些坑記下來，你的工作流會比從零摸索的人快上好幾個月。

五種情境的決策表：什麼時候 MCP、什麼時候 wp-cli、什麼時候手動

工具用順之後，真正的功力展現在「知道什麼時候用什麼」。這三條路線不是互相取代，而是各有戰場。這張表是實務上累積下來的判斷原則，給你一個可以照著走的起點。

情境	我會選的路線	理由
單篇文章的內容判斷與修改	後台手動	需要當下的閱讀與判斷，自動化反而礙事
結構固定、條件單純的批次（例如全部文章匯出）	wp-cli	條件單純時命令列最快最穩，不用繞自然語言
條件複雜、需要一點判斷的維護（例如補 meta、梳理內部連結）	MCP + Claude Code	用自然語言描述意圖最省事，AI 補上判斷這一塊
任何不可逆的動作（刪除、改網址、改權限）	後台手動，人工逐筆	後果太重，再麻煩都要人類親自按下確認
需要跨文章理解脈絡的整站健檢	MCP + Claude Code	讀全站找關聯是 AI 最強而人類最累的工作

這張表的精神是：沒有哪一條路線是萬用的，厲害的人是三條都會，然後依情境切換。剛開始你可能什麼都想丟給 MCP 試試，這很正常，但用久之後你會自然而然回到「簡單的事用簡單的工具、危險的事用最慢的工具」這個原則。工具是為你服務的，不是你為工具服務的。

你的下一步行動方案

看完這一長串，細節記不完也沒關係，先記住操作順序。接下來這六步從最小、可回滾的範圍出發，不要一開始就在正式站大幅修改。

1. 本機或預備站先跑起來。挑一個你可以隨意弄壞的環境，正式站這個階段完全不碰。把 WordPress 裝好、確認後台能進、REST API 能回應。
2. 開一組應用程式密碼、建一個最小權限帳號。這是整條流程裡最便宜也最重要的一道護欄，五分鐘就能做完，卻能擋掉九成的風險。
3. 挑一個 MCP 伺服器實作，完成最小連線。用唯讀端點驗證，確認能讀、能回正確結果，再談寫入。token 全程走環境變數。
4. 挑一件低風險的維護活試水。我最推薦從「列出缺 meta 描述的文章」這種純唯讀、純分析的任務開始，先感受 AI 讀全站能給你什麼樣的視野。
5. 把黑名單寫下來貼在螢幕邊。刪文、改網址、改權限、動資料庫、正式站批次覆寫，這五項永遠人工確認。養成這個反射動作，你會省下無數個救火的夜晚。
6. 把省下來的時間投到經驗上。機械活被接走之後，去寫那篇你一直想寫、帶著第一手經驗的深度文章，那才是這整套工具最終要服務的目的。

這條路走起來不會一帆風順，你一定會踩到快取誤判、踩到區塊被吃掉、踩到 token 差點外洩的那種心跳時刻。但每一次踩坑都是在幫你的工作流加固，等到你把護欄全部裝好、把黑名單內化成直覺，你會發現自己從一個被維護活綁架的人，變成一個真正能把心力放在內容與策略上的人。工具換了，你的角色也跟著升級，從 WordPress 的資料輸入員，回到你一開始想成為的那個內容經營者。這才是 Claude Code 搭配 MCP 真正能給你的東西，不是更多的文章，而是更像你自己的工作方式。