Claude Code 接 Elementor：頁面生成與維護 SOP

Claude Code 能不能接 Elementor？能，而且接點比多數人想的清楚：Elementor 的頁面資料本身就是一份標準化的 JSON，官方還提供命令列通道把範本送進站內。分水嶺在另一件事。這份 JSON 活在 WordPress 資料庫的私有欄位裡，佈景主題檔案裡找不到它。工作流的形態因此跟改程式碼完全不同，得繞著資料庫與官方通道來設計。

這套工作流處理兩個實際問題：AI 生成的頁面怎麼安全進到 Elementor 站內，以及日後改版、搬站、批次調整時怎麼不弄壞網站。讀完你會有三樣東西：一份按風險排好的路線判斷、一套範本 JSON 的生成匯入驗收節奏、一份五步維護 SOP。文中的指令與欄位名保留原文，對著自己的站照做就行。

重點先看

• Elementor 頁面的本體是一份標準化 JSON，存在 WordPress 資料庫的私有欄位，官方的正規出口是範本 JSON 檔與整合進 WP-CLI 的命令族。
• Claude Code 能讀寫檔案、跑指令、操作 git，內建工具碰不到 Elementor 編輯器的畫面。能與不能畫清楚，路線就好選。
• 三條路線按風險排：範本 JSON 生成匯入，既有頁面一頁都不動。讀改寫回屬社群實務，要走就配三道護欄。REST 與 MCP 管得到內容，結構層在查證時點的版本不開放。
• Elementor 官方 AI Angie 已上線，免費方案有每日更新額度。編輯器內快速生成交給 Angie，跨站複用、版本控、批次維護交給 Claude Code，兩者可並用。
• 今天就能做：把站上一個現有頁面匯出成範本 JSON，當成餵給 AI 的學習樣本。

為什麼 Claude Code 接 Elementor 跟一般架站不同

頁面資料住在資料庫裡

用 Claude Code 蓋一個 Astro 或靜態站，畫面大概是你打開終端機，它對著一個資料夾工作：讀元件檔、改樣式、跑建置。對 Claude Code 的官方說明文件來說，這正是它的原生棲地，一個能讀程式碼庫、改檔案、跑指令、接上開發工具的代理工具，終端機、IDE、桌面應用與瀏覽器裡都能用。還沒跑過它的人，先讀 Claude Code 入門教學把環境裝起來。Elementor 站的狀況不同，你的頁面放在資料庫一張表的某一列，.php 與 .css 檔案裡都沒有它。

Elementor 官方開發者文件的資料結構說明把這件事講得很白：Elementor 用 JSON 結構化頁面資料，編輯器負責用拖拉介面生成這份結構化資料，前端負責解析它來組出版面。按下儲存時，頁面資料以 JSON 形式存成 WordPress 的 post metadata，本質上是一個 custom field，落在資料庫的 wp_postmeta 表。而且是私有欄位，WordPress 後台介面看不到它。這份文件等於一次把接線條件講完：AI 想碰頁面資料，要嘛透過官方通道把資料拿成檔案，要嘛透過指令。

一個 Elementor 頁面的版面、內容與元件設定，以一份 JSON 存在資料庫裡，彼此的關係由結構自己描述。佈景主題檔案裡找不到這份內容，官方對儲存位置的說明只指向資料庫。複製一個站的設計時，搬動的是資料本身。Elementor 頁面結構的備份因此離不開資料庫，只備份檔案救不回頁面內容。

私有欄位四個字還有另一層意涵。WordPress 對 meta 有保護機制，受保護的鍵不該被隨意讀寫，路線③會看到它的具體規則。官方文件用私有 custom field 描述 Elementor 的資料，後台介面看不到它，直接讀改寫回屬社群實務，因此這套工作流優先走官方範本與 CLI 通道，能不直接碰資料庫就不碰。

所以第一條要畫清楚的線是能與不能。Claude Code 能讀寫本地檔案、能跑指令、能操作 git，官方文件明寫它會暫存變更、寫 commit 訊息、開分支、發 pull request。它內建的檔案與命令工具碰不到 Elementor 編輯器的畫面，拖 container、點工具面板這類動作不在其中。官方另有可開啟的瀏覽器整合能讓它操作網頁，這套工作流不靠那條路。本次查證，Elementor 官方文件未見讓外部程式遙控編輯器畫面的介面，官方對外開的正規通道是標準化的範本 JSON 與整合進 WP-CLI 的命令族。工作流的所有設計，都從這組條件出發。

標準化 JSON 是官方開出來的出口

資料庫裡的欄位讀不到，資料照樣拿得到，同一份官方文件給了正規出口：下載 Elementor 的範本檔，會產生一個 .json 檔，內含該頁的完整頁面資料。更關鍵的是下一句，這份 JSON 是標準化的，可以匯出再匯入，把頁面設計複製到不同的頁面、不同的 WordPress 站。頁面的設定、內容與版面關係，都由這份 JSON 結構保存。

兩句官方事實疊起來，工作流的地基就有了。AI 不需要碰資料庫，它只要會生成這種標準格式的檔案，進站交給官方通道處理。再往下一步推，標準化加上可跨站匯入，代表範本 JSON 檔天生適合進 git 做版本控。官方文件沒有把範本進 git 寫成建議流程，這一步是從格式的可攜性推過去的，但風險極低，git 裡擺的只是純檔案，不碰任何站上狀態。

走官方通道還有一個容易忽略的好處，責任邊界清楚。走範本與 CLI，出問題時除錯範圍落在檔案內容與命令參數，官方文件有可對照的規格。繞過通道直接動資料，依賴的是官方文件未點名、由社群實務補足的鍵名與操作細節，出錯時沒有規格可對。長期維運的站，把這條界線一起算進工具選擇。

資料藏在資料庫裡這件事，對工作流反而有利。假如 Elementor 只能靠編輯器畫面操作，AI 就得模擬滑鼠點選，速度慢、容易出錯，成果也難驗收。改成標準化檔案交換之後，生成物可以被檢查、可以退版，整條流程是確定性的。所以用檔案交換的工作流，會比模擬畫面操作來得可靠。

Elementor 本身的操作、佈景與外掛，站上的 Elementor 完整指南處理得更全，接 AI 會用到的只有資料形態與通道兩件事。

Elementor 頁面資料的形態：一份存在資料庫裡的 JSON

動手生成之前，先把範本 JSON 檔的結構看懂。官方開發者文件的General Structure 說明給了完整規格，頂層五個欄位，content 陣列裡每個元件又是固定的物件形態。對生成式 AI 來說，這種欄位有名有姓、巢狀規則明確的格式等於一份現成契約，照著填就對。

範本 JSON 的五個頂層欄位

五個欄位各管什麼，照官方定義列成表格。

type 欄位有個常見誤解。它標記的是文件掛的位置：一般頁面用 page，文章用 post，header、footer、error-404 這些全站部件各有自己的值，popup 也有。生成之前先決定產物的身分，匯入後它才會被放在對的位置上被對待。version 則是格式自帶的版本號，官方載明的最新版是 0.4，照 0.4 填就對。

content 陣列裡的元件長什麼樣

content 陣列裡的每個元件是一個物件，範例裡的形態是固定的。官方範例的 id 呈七到八位十六進位樣式，例如 3130e2cf。elType 標元件層級，範例是 container。isInner 是布林值，官方範例中為 false。settings 放這個元件的設定，可以是空陣列或物件，範例裡的 padding 設定帶單位 px、上右下左四個邊值，加上 isLinked 標記四邊是否連動。elements 放巢狀的子元件。官方文件還把 Page Settings、Page Content、Container Element、Widget Element、Repeaters、Responsive Data、Global Styles 等結構子題拆成獨立說明，生成複雜頁面時照子題往下深挖。

這個結構對 AI 是好消息。格式固定、欄位語意清楚、巢狀有規則，比描述一張設計稿容易生成得多。實務上更有效的做法是餵樣本：先從站上匯出一頁既有頁面的範本 JSON，讓 Claude Code 讀過真實樣本再生成，成品會貼著你站上的慣例走，比憑空照規格生更可用。

拿一個常見的首頁版面設想結構。最外層先想成一個 container，elements 陣列裡放它的子元件，子元件如果又是容器，同樣的形態再巢狀一層。生成前把這個階層想清楚，AI 產出的 JSON 才堆得出你要的版面，而不只是欄位合法。具體的元件類型與巢狀規則，以官方文件的子題說明為準。

page_settings 常被新手忽略。它記的是頁面設定面板的整頁層決定，跟單一元件的 settings 是兩個層次。生成的範本沒有整頁設定時，讓它保持空陣列就好，官方結構本來就允許。version 欄位照 0.4 填，它標的是資料結構的版本，跟 Elementor 產品的版本號無關，兩件事常被混為一談。

資料存在哪個欄位，誰查得到

官方說法到「私有 custom field」為止。儲存位置與私有性質是官方事實，前面引過了，實際的欄位鍵名在官方開發者文件站內搜尋不到。社群實務與 Elementor 官方 GitHub 倉庫的討論裡，看得到這個鍵名，叫 _elementor_data。它存的是頁面的元素樹，跟範本匯出檔的五欄位結構不同，整頁設定另有自己的欄位。這個分界之後還會用到：儲存機制是官方規格，鍵名是社群實務。路線②會直接用到它，到時再展開。

鍵名為什麼重要，等到要下指令就有感。讀取與寫回都要指定這個鍵，它等於 Elementor 頁面在資料庫裡的身分證。指令認鍵名，工具對不對症，看的就是這個。

三條接線路線：按風險排成一個階梯

接線方式有三條。①與②排成一個階梯，對頁面資料的控制力往上遞增，風險跟著遞增，對官方介面的依賴遞減。③是另一個工作面，管的是內容生產的自動化，查證時點的已發布版本碰不到 Elementor 的結構層。正確的姿勢是照自己的風險忍受度與工程能量選一條走，遙控編輯器這條路，本次查證未見官方支援。

三條路線的做法、風險與適合的人，先擺在一起看。

挑法用條件句想。站是客戶的、壞不起，待在路線①是合理選擇，生成新頁的需求在這層就能完成。自己有測試站、懂 WP-CLI、備份回滾都熟，路線②能把批次修改的自動化做起來。手上多個站要養、內容更新量大，路線③加上範本化管理是長期解。三條路不互斥，同一個專案裡混用很常見。

三種處境對應三種典型選擇。接案設計師面對客戶的正式站，頁面壞一天都是事故，路線①加編輯器微調就是全部，簡單而且責任清楚。公司行銷團隊自己管站，有權限也有測試空間，可以往路線②推進，把定期的例行改版做部分自動化。代理商養著多個客戶站，內容生產與範本派發是日常，三條路線一起上，用一個 git 庫當所有站範本的中樞。

階梯的順序本身就是紀律：任何修改先問能不能在低層解決，能就不要往上爬。爬到路線②之前，先把路線①走順，護欄裡的備份與樣本，都來自範本匯出的日常習慣。

控制力與風險同向上升，原因在修改目標離備份越來越遠。路線①動的是自己電腦裡的檔案，路線②動的是資料庫裡的活資料，路線③雖然不碰結構，卻常把修改的頻率放大，頻率本身也是風險。把這三個維度放在心裡，之後遇到新工具或新情境，自己就能判斷它落在階梯的哪一層。

路線①範本 JSON 的生成與匯入

從官方結構出發，讓 Claude Code 生成

這條路給 Claude Code 三樣輸入：官方 General Structure 文件的內容或截選、站上既有頁面匯出的範本 JSON 當樣本、這個新頁面要放什麼內容的描述。它出手的地方在生成：讀樣本、比對結構、寫出一個 .json 檔，五個頂層欄位齊全，content 裡的元件照 elType 與 elements 的規則巢狀。生成的檔案放在你指定的資料夾，進不進站由你決定，這就是這條路風險低的來源。

給描述時，把判斷寫成具體條件，少用形容詞。與其說要做一頁大氣的服務頁，不如說最外層兩個 container，第一個放標題與副標，第二個放三欄服務項目，欄距照樣本裡的設定。形容詞對生成沒有約束力，結構與數量才有。描述裡可以直接引用樣本的欄位慣例，讓 AI 對著你站上的真實資料抄格式。

生成之後先做機器檢查再進站。請 Claude Code 用本機工具驗 JSON 能不能被解析器讀開、五個欄位在不在、每個元件有沒有 id 與 elType、version 是不是 0.4、type 用對了沒。這層檢查很快，能把格式層的錯誤在進站之前就攔下。

要批次生成多頁，把多個 JSON 檔包成一個 ZIP 一次匯入，CLI 吃這種整包格式。檔名紀律從第一天就建立，名稱前後一致、看得出對應的頁面，範本庫裡的東西才找得到。

匯入站內的兩個入口

第一個入口是命令列。Elementor CLI（WP-CLI 命令族）的官方總覽把它定位成讓開發者不開瀏覽器、直接從命令列執行特定 Elementor 任務的命令集，2026 年 9 月 10 日查證時共有十七個命令，語法以 wp elementor 開頭，細節可用 wp help 與 wp help elementor 查。範本匯入用 Library Import 的官方說明：wp elementor library import <file-path>，可以上傳單一範本 JSON 檔，或一個 ZIP 裡裝多個 JSON 檔批次進站。--returnType 可用 ids 或 info，預設 info，指定 ids 會回傳匯入項目的 id，方便後續腳本接手。官方說明頁給的範例檔名是 elementor-12345-2022-03-04.json，匯入目的地是範本庫。

第二個入口在後台。官方說明中心列的步驟是：開範本庫（Template Library）、點 Templates、點上傳圖示、選檔案、確認匯入。不碰終端機的人走這裡，五個動作點完，效果等同 CLI 匯入。

兩個入口怎麼挑，看你在誰的電腦上做事。自己的開發機、有終端機權限，CLI 快而且能進腳本。客戶的後台、拿不到終端機，就走範本庫的上傳圖示。生成端不受影響，Claude Code 在你本機產檔，檔案怎麼進站是另一件事。

Claude Code 端的準備很輕。開一個專案資料夾，放官方結構的參考、範本樣本與生成輸出三個子目錄，它就在這個資料夾裡工作。同一個資料夾也給 git 用，生成的範本從第一次就受版本控保護，歷史從起點開始累積。

匯入之後，回到編輯器驗收

匯入完成不等於收工。到範本庫把剛進站的範本打開，進編輯器檢查：元件有沒有缺、settings 有沒有帶到、間距與 responsive 的表現對不對。官方連 Angie 生成物的說法都是 every generation is editable，生成物進編輯器微調是被設計進流程裡的常態，AI 生成的範本同理。

驗收時特別看三個地方。元件樹的階層是不是跟你要的一致，container 巢狀的層數錯了，後面調樣式會處處卡。responsive 的表現，生成的範本在桌機好看、手機疊成一團是常見狀況。內容是不是照描述放也要檢查，AI 偶爾會熱心多補你沒要的東西。

範本驗收通過，套用到新頁面，這條路就走完了。過程中站上的既有頁面一頁都沒被碰到。

走順之後把它變成循環。生成、匯入、編輯器微調，把微調完的滿意成品再匯出成新的範本 JSON，它就成為下一輪生成的樣本。樣本庫越養越貼近你自己的設計語言，AI 的生成品質跟著收斂，這是路線①真正的長期價值。

路線②既有頁面的讀取、修改與寫回

先講清楚這條路的性質：它是社群實務，官方文件沒有背書。官方的正規通道是範本匯出與 CLI 匯入。直接讀寫頁面資料的欄位，是社群技術文件與 Claude 使用技巧分享裡長出來的操作模式。能用，但風險自己扛，防護措施一項都不能省。

社群實務的操作節奏

操作節奏分四拍。先用 wp post meta get 把目標頁面的 _elementor_data 導出成 JSON 檔，把檔案交給 Claude Code 並說清楚要改什麼，它改完存檔，你用 wp post meta update 把新值寫回。命令選項是官方規格：wp post meta update 的值參數可以省略，省略時從 stdin 讀入。--format 有 plaintext 與 json 兩個值，預設 plaintext，_elementor_data 的讀出與寫回都用 plaintext，讓 JSON 字串原樣進出。指定 json 會把值解成陣列再序列化存入，Elementor 前端就解析不了，這個坑要先繞開。導出、修改、寫回三段都是檔案與指令，正是 Claude Code 拿手的那側。

一個典型應用是全站 footer 改版。假設站上一批頁面的 footer 要換新的按鈕文字與連結，動手前照規矩先備份。逐頁讀出資料，讓 Claude Code 在每份 JSON 裡找到對應的 widget，改文字與連結後存檔。人工看過 diff 沒問題，再逐頁寫回，跑一次 flush-css，進編輯器抽驗其中幾頁。同構的修改反覆出現時，這套流程省下的時間就很明顯。

人工檢查這一段有個訣竅：看 diff，不看成品的 JSON。Claude Code 改完檔案後，用檔案比對看它動了哪些行，改動應該集中在預期的欄位，例如按鈕文字與連結。diff 裡出現大範圍重新排版或非預期欄位的變動，先停下來問原因，再決定寫不寫回。

這條路的易錯點社群文件有記載：JSON 的跳脫與 slashing 細節容易出錯，一個引號處理錯，整份寫回的資料就壞了。照抄別人的指令序列之前，先在自己的備份環境跑一遍，拿官方命令頁對選項，不要憑記憶拼。

環境紀律比指令細節更重要。先在測試站或預備環境跑完整流程，確認讀出、修改、寫回、CSS 重生成四段都通，再碰正式站。正式站挑流量低的時段動手，改完立刻驗收。這些習慣不會出現在官方文件，因為官方文件裡沒有這條路，它們來自社群的實際經驗。

三道護欄：備份、重生成 CSS、修訂版本

第一道，動手前備份。至少把目標頁面的範本 JSON 匯出留底，這是官方通道給的原生做法。嚴謹一點就做整站備份。沒有備份，出錯時就沒有退路。

第二道，寫回後重生成 CSS。Elementor 的樣式存在資料庫，系統再依這些資料生成 CSS 檔，放在 /wp-content/uploads/elementor/css/ 資料夾，前端載入的是這些檔案。Flush CSS 命令的官方說明給了兩段式行為：wp elementor flush-css 不帶參數只刪舊的快取檔，新檔等下一次頁面瀏覽時生成。帶 --regenerate 則立刻用資料庫裡最新的設定重建，多站網路要全站處理時加 --network。寫回資料後樣式沒變，第一個該查的就是這裡。

第三道，修訂版本（revisions）。History 面板的官方說明把它拆成兩個頁籤：Revisions 列存在資料庫裡的頁面版本，Actions 列上次儲存之後的變更。官方的定位句直說：修訂版本是 WordPress 的原生功能，Elementor 只是讓還原不同版本變得容易。寫壞了，進編輯器退回前一版，前提是站上修訂版本功能開著、寫回前的版本還留在歷史裡。CLI 直接寫入不會自動產生新修訂，第一道的檔案留底因此不能省。

三道護欄都到位，路線②才從探險變成工程。少任何一道，建議退回路線①。

為什麼 CSS 一定要重生成

機制單獨拆出來講，因為它同時解釋一堆改了沒生效的困惑。你在編輯器裡調的樣式，儲存時進的是資料庫，瀏覽器拿到的是按這些資料預先生成的 CSS 檔。繞過編輯器直接改資料，資料庫更新了，CSS 檔不知道。flush-css 做的就是強制讓檔案層追上資料層。急著驗收就帶 --regenerate 立刻重建。不急，讓下一次頁面瀏覽自然觸發也行。

同樣的機制也提醒你驗收要看對地方。前台樣式不對，先確認 CSS 檔有沒有重生成，再懷疑 JSON 內容。

這條路適合誰

判斷條件攤開來比結論有用。你有 WP-CLI 環境、會備份、知道怎麼回滾，可以走。你接案要批次改既有頁面，例如全站 footer 換 CTA，路線②加上範本化管理比逐頁手點省得多。你只有一個站、只改一頁，直接在編輯器裡改。

走完路線②之後有個收尾動作：把改好的頁面匯出成範本。之後同構的調整就能回頭交給路線①處理，不必反覆對活頁面的資料庫動刀。

路線③REST 與 MCP 的能力邊界

REST 能碰到什麼

WordPress 的 REST API 官方手冊寫得明白：REST 端點代表 posts、pages、分類等內容類型，應用程式對端點收發 JSON，就能查詢、修改、建立站上內容。權限邏輯同前台，公開內容可直接讀取，私有內容、密碼保護內容、使用者資料、自訂文章類型與 meta 要驗證，或由站方特別設定開放。驗證用 Application Passwords（應用程式密碼），WordPress 5.6 起內建，官方驗證說明寫明它在後台 Edit User 頁生成、搭配 https 上的 Basic Auth 傳給 REST 請求。Claude Code 這側不用新工具，跑 curl 或寫小腳本就是它的日常。

實際形態不難想：應用程式對 posts、pages 這類端點收發 JSON，就能查詢、修改、建立內容，驗證靠應用程式密碼完成。這層能力跟 WordPress 內容管理有關，Elementor 版面這一側不歸它管，界線畫在資料類型上，很乾淨。

這條路發揮的地方在批次與流程化。一次要建一批服務據點頁、定期把表格資料生成分類頁、把別的系統的內容同步進 WordPress，這類工作交給 REST 加 Claude Code 的組合，比手動後台貼文貼到半夜合理。生成出來的頁面如果要用 Elementor 版面，再接路線①的範本套用。

meta 的白名單制與底線鍵保護

邊界出現在 meta 這層。官方文件的規則有兩條。register_meta 把既有 custom meta 登記成 REST 可存取的白名單，show_in_rest 設為 true，欄位值才會出現在端點回應的 .meta 鍵裡，官方範例註明預設是 false。另一條，is_protected_meta 的判定是鍵名第一個字元為底線即受保護，這個函式自 WordPress 3.1.3 引入。兩條疊起來看 Elementor 的結構層資料：在查證時點的已發布版本裡不在 REST 白名單，鍵名又以底線開頭。REST 對內容層能查詢、修改、建立，Elementor 的結構層資料在這些版本裡則不在 REST 的開放範圍。這套工作流不把受保護的欄位註冊進白名單，結構層的修改因此不走 REST。

這個預設對 AI 工作流是保護。要是任何 meta 都能直接從 REST 讀寫，一個寫錯的請求就能把頁面資料改成無效 JSON，而且沒有編輯器的儲存流程把關。預設白名單把結構層資料擋在外面，自動化要動結構，就得回到標準化範本與官方 CLI 通道。

內容管理交給 MCP

MCP 是連接 AI 工具與外部資料源的開放標準，Claude Code 原生支援。套用到 WordPress，實際能力取決於 MCP 伺服器暴露的工具；常見做法是讓 Claude Code 用自然語言建立內容、改文與查詢狀態。這套怎麼建、怎麼跑，站上的Claude Code 與 WordPress MCP 整合有完整說明。同一套協定也能承接設計稿，把 Figma 設計稿接進 Claude Code 的完整流程談的正是整備、連線與驗收。若使用一般 WordPress MCP，內容層的建立與更新可交給 MCP，Elementor 結構層仍回到路線①與②；若使用 Elementor 官方目前開放測試的 MCP Beta，Claude、Codex 等工具已能直接建立與編輯 Elementor 原生結構。Beta 目前需要網站管理員權限、最新測試版本與 Atomic Editor，實際資格與功能仍以官方文件為準。

路線③也不能取代①與②的驗收責任。經 API 建立的內容，一樣要檢查。工具越多，驗收標準越要一致，否則自動化只是把錯誤放大得更快。路線③產出的內容若還要套 Elementor 版面，再進編輯器驗收，檢查這一步不因工具不同而省略。

Claude Code 跟 Elementor 官方 AI Angie 的分工

談 AI 生成 Elementor 頁面，不能假裝官方自己沒有做。Angie（Elementor 官方 AI）已經上線，產品頁在 2026 年 8 月下旬更新過，2026 年 9 月 10 日查證時的樣貌如下。

Angie 已經能生成什麼

官方定位是 agentic AI for all WordPress sites，超越對話式建議，能動 themes、plugins 與 Elementor 元件。生成物清單有四類。完整頁面：描述你要的頁，它建 sections、內容與樣式。設計系統：給它 screenshot 或 reference，產出顏色、字型與可重用的 Classes 和 Variables。表單：描述欄位與版面，它建真實的 Atomic Form。Loop：建動態封存頁含版面、項目與分頁。表單與 Loop 需要 Elementor Pro。官方對生成物的強調點在可編輯性：每次生成都是可編輯、可自訂的 Elementor 原生內容，不是鎖死的匯出檔，進編輯器可以手動細調每個部分。

使用條件照官方頁列的：登入需要 Elementor 帳號，Elementor 編輯器本身不需要。安裝走後台 Plugins → Add New 搜尋 Angie，裝完另需 Elementor 本體並啟用連接。額度方面，免費方案有每日更新的 AI 額度，產品頁並註明目前無法加購額度。

從能力清單看得出 Angie 的目標用戶：在編輯器裡工作、用自然語言描述需求、期望成品直接出現在站上的人。設計師跟客戶開會時現場生一版版面，行銷人員自己組一頁活動頁，這類場景它用起來順手，因為它就是為這個環境做的官方工具。

分工的判斷條件

兩個工具的差異在工作位置與產出形態。Angie 的位置在編輯器內，生成物直接進站。跨站複用與版本追溯的需求，落在檔案與 git 那一側。用好兩者的答案是並用。

人在編輯器裡、要快速生成一個頁面或表單的當下，Angie 直接可用，不用離開瀏覽器。

要把生成物當資產養，跨站複用、版本控、批次維護，Claude Code 路線的形態正好合用，生成物是檔案，直接進檔案庫。

表單與 Loop 的 Angie 生成需 Elementor Pro。Pro 版範圍還有做全站 CSS 與 JS 片段的 Custom Code（Pro 功能），入口在後台 Elementor > Custom Code。這條界線畫到哪，Elementor Pro 完整指南整理得更全。

並用是常態走法。Angie 在編輯器內生成，滿意的成品匯出成範本 JSON，進 Claude Code 側的檔案庫與 git，官方標準化格式讓這條搬運路成立。

組合拳的一個樣板：新客戶要一批頁面。先用 Angie 在編輯器裡把首頁的視覺方向快速試出來，客戶點頭後，把定案的首頁匯出成範本 JSON，交給 Claude Code 當樣本，批次生成其餘內頁的初稿，再逐頁匯入微調。官方 AI 負責探索與定調，命令列代理負責量產與管理，各自站在擅長的那一側。這種把「視覺探索」與「工程量產」分給不同工具的分工邏輯，跨出 WordPress 也成立，Stitch 設計稿轉 Claude Code 的跨生態分工就是同一原則的另一種實作。

日後維護 SOP：五個步驟

維護 SOP 把三條路線串成固定的執行順序，五步一輪，每步有明確機制與驗收標準。

五步的做什麼、用什麼機制、怎麼算過關，一張表先看全貌。

第一步：盤點與匯出

盤點先於一切：站上哪些頁面是 Elementor 頁、哪些範本該進庫、哪些只是死資產，先列清單再動手。匯出分兩種粒度。單頁或單一範本，用範本匯出，拿到一個 .json 檔。整站層級，Kit Export 的官方說明提供打包出口：內容、範本與網站設定可以包成一個網站套件（kit），後台或命令列都能匯出。CLI 是 wp elementor kit export，--include 可指定 content、templates、site-settings 三類，不指定就全部納入，輸出是 zip 檔。驗收標準很樸素：檔案打得開、解析得掉、數量對得上。

清單跟著改版週期更新。大改版前做一次全量匯出，平常定期把新增頁面補進庫裡。清單可以用一個簡單的表格維護：頁面、用途、範本檔名、最近匯出日期。這份清單本身就是日後批次維護的作戰地圖，哪些頁面同構、哪些該淘汰，看表就知道。

第二步：範本進版本控

匯出檔進 git 資料夾，這一步的根基是官方的標準化承諾：JSON 可跨站匯入，檔案才有版本控的意義。Claude Code 對 git 的操作是官方列明的能力，從暫存到發 pull request 都在日常範圍。commit 訊息記三件事：哪一頁、改了什麼、為什麼改。工作資料夾裡放一份專案說明檔（CLAUDE.md），寫明範本放哪、指令怎麼跑、驗收看什麼，Claude Code 每次工作階段開始都會先讀它，慣例就固定下來了。跨站要複用範本，雲端範本庫的角色在 Elementor 雲端範本庫指南另有一份說明。

兩種版本機制各管一段，要分清楚。修訂版本跟著頁面活在資料庫，記的是編輯歷程。git 跟著檔案活，記的是資產的演化。範本屬於資產，它的版本故事應該寫在 git 裡，可以 diff、可以回溯到任何時間點，這些是資料庫修訂版本給不了的。頁面層的問題用修訂版本回退，資產層的問題用 git 回退。

commit 之外，分支紀律也要早點建立。大改版開分支，驗收過再併回主線，範本庫的穩定版永遠可用。單人作業也一樣，分支強迫你把實驗與穩定分開，主線不受影響。這套作法在軟體工程裡行之有年，套在範本管理上同樣可行。

第三步：依風險選路線修改

修改階段回頭用路線判斷。新頁面、新範本，路線①，生成匯入微調。既有頁面的小改動，開編輯器手改就好。同構的批次修改，路線②加三道護欄。內容層的批次生產，路線③。選擇的依據是風險忍受度與工程能量。過關標準固定：動手前後各留一份對照，改動只落在預期欄位，這一步才算完成。

第四步：驗證

驗證有兩層。編輯器層：開頁檢查元件樹、樣式、responsive，這是官方生成物也逃不過的關卡。資料層：只要動過資料庫裡的頁面資料，就跑一次 flush-css，帶 --regenerate 立刻看結果。驗收標準固定下來：前台頁面樣式正確、編輯器元件樹完整、沒有預期外的元件出現。

把驗證當關卡，不要當善後。SOP 裡的驗證沒過，就不進下一步。這條規則說來簡單，實務上容易鬆掉，因為改完的興奮會催你趕快看下一頁。把驗收標準寫進專案說明檔，讓 Claude Code 在每次修改後回報機器查得到的項目，JSON 解析、diff 範圍、命令執行與 CSS 重生成的結果。編輯器與前台的最終檢查由人完成。

第五步：回滾

回滾是整套 SOP 的保險絲，分兩層。資料庫層：修訂版本（revisions）是 WordPress 原生功能，Elementor 的 History 面板讓還原變得容易，Revisions 頁籤列資料庫裡的頁面版本，Actions 頁籤列上次儲存後的變更。檔案層：範本 JSON 在 git 裡，退版就是 revert。兩層各退各的，互不依賴，任一層出事都有路可退。保險要平時演練，出事才跑得動：挑一頁不重要的小頁，完整走一次回滾，看流程卡在哪裡。

範圍也要先分清楚：單頁壞了，用修訂版本退那一頁就好。同一批寫回造成多頁異常，先停手，用各頁的修訂版本與 git 裡的範本資產分別追查，評估影響頁數再決定退法。回滾動作本身也留紀錄，寫進 commit 訊息，日後要追溯原因，看 commit 紀錄就有答案。

邊界與地雷

大型 JSON 不要塞進對話

跟 AI 協作頁面 JSON，常見的壞習慣是把整份檔案貼進對話。Claude Code 的 MCP 文件給了明確數字：工具輸出超過 10,000 tokens 會先警告，預設上限 25,000 tokens。超過上限的純文字結果不會進對話，會被存成檔案、以路徑取代。官方連退路都設計好了，做法只有一個：用檔案路徑交換。把 JSON 放進工作資料夾，叫 Claude Code 讀檔、改檔、存檔。它有檔案系統，這正是它跟聊天視窗的差別。

檔案交換的實際長相是這樣：資料夾裡放 exports 與 drafts 兩個子目錄，匯出的範本進 exports，AI 生成的初稿進 drafts。對話裡只談意圖與判斷，要動手時叫它開特定路徑的檔案。整份 JSON 的內容不出現在對話裡，對話空間留給決策。

範本資產也要定期健檢。每隔一陣子從 exports 資料夾隨機抽幾個範本，匯入測試站確認還能解析、還能套用。範本會不會隨著工具演進失準，與其猜，抽樣驗證一次就知道，壞掉的範本當場淘汰或重匯。

官方文件沒有背書的路要自己扛

能與不能再對一次帳。Claude Code 能讀寫檔案、跑指令、操作 git，內建工具不能操作 Elementor 編輯器的畫面。查證時點，Elementor 對外的正規通道是標準化範本 JSON 與 CLI 命令族，結構層的 MCP 通道還在 roadmap 上。路線②直接讀寫頁面資料是社群實務，官方沒有背書，走它就要把三道護欄當成入場費。匯入與寫回之後，編輯器驗收是固定動作，官方對 Angie 生成物強調的也是進編輯器可細調，同一條標準套用到 AI 生成的範本。

這套工作流不採用的高風險做法

三種做法看起來快，這套工作流都不採用。直接對資料庫下 SQL 改頁面資料，格式與跳脫細節容易出錯，一個字元錯了整頁報廢。把受保護的 meta 用 register_meta 註冊進 REST 白名單、讓外部請求直接讀寫頁面結構資料，是官方文件列明的擴充機制，做不做屬於風險選擇，這套工作流基於前面講過的邊界選擇不走。來路不明的第三方工具宣稱能遙控 Elementor，先自己驗過再說，本次查證範圍沒有涵蓋任何這類工具。

資產心態是全部地雷的共同解法。範本在 git 裡、頁面有修訂版本、匯出有留底，出事的下限就被鎖住了。高風險做法的吸引力，來自官方通道還沒走順。

跟站上其他文章的分工

這個主題在站上是一組文章，各管一段。Claude Code 架站總覽處理整體流程：專案說明檔、Skills、MCP、品質閘與部署。外掛的挑選、安裝與權限設定，則可以看Claude Code 外掛怎麼挑怎麼裝。Elementor 資料層的生成、匯入、版本控與維護 SOP，落在更聚焦的這一層。頁面上線之後搜尋端的批次工作，站上另有一篇SEO 批次審計與內鏈自動化的工作流整理。卡在 AI 架站整體怎麼組織，讀總覽。卡在頁面怎麼生成、怎麼維護，讀到這裡應該已經有答案。

下一步

從最小的一步開始。今天把站上一個現有 Elementor 頁面匯出成範本 JSON，放進一個資料夾。讓 Claude Code 讀它，生成一頁新的 Elementor 範本，匯入範本庫，再進編輯器驗收。走完這一輪，判斷三條路線時就有自己的實作結果可依據。之後每次改版，都可沿用這五個步驟。

第一次走全程，常見的卡點很好辨認。匯出後的 JSON 打開來會眼花，這是正常的，你不需要讀懂每一行，AI 會讀。匯入後的範本在編輯器裡跟想像有落差，也正常，微調本來就是流程的一部分。卡關的價值在於，下一次你會知道往哪個欄位看。