用 Codex 架站：從設計規範檔到 WordPress 主題移交的實戰流程

用 Codex 把網站從無到有蓋出來，再一路走到客戶自己能編輯的 WordPress 佈景主題，中間是一條五段式的工程管線：先把設計決策寫成規範檔，讓模型有單一事實來源；接著從規範生成第一版頁面；然後一次一個區塊地迭代收斂；成品穩定後，把它改寫成 WordPress 認得的佈景主題結構並打包成 ZIP；最後在上傳安裝之後，想清楚哪些東西進模板、哪些留給區塊編輯器，用區塊鎖定把界線畫出來。多數 AI 架站教學停在第三段：你拿到一個看起來不錯的網頁，接下來卻卡住了，託管平臺綁住了輸出，客戶也改不動任何一行字。這篇要把後面兩段補完，因為那才是交付的真實樣貌。

行文順序先給一分鐘答案，把整條管線與每段的交付物攤開；接著處理開工前的三個決定（入口、專案說明書、版本控制），再逐段走進規範檔的寫法、第一版生成、單區迭代、主題化與 ZIP 打包，以及安裝後的可編輯區與鎖定策略；然後談交接後的維護與升級，用一張對照表定位這條路跟其他 AI 架站路線的差別，收在誠實的限制與可以今天就做的下一步。涉及 WordPress 機制的段落都附官方文件出處，改版時以行內標註為準。

一分鐘答案：五段管線，每一段都有明確交付物

先決定路線。網路上談「AI 架站」的內容，大多數停在「生成一頁漂亮的 HTML」；但在真實委案裡，客戶要的通常是一個可以自己改價格、換圖、發文章的網站，這在台灣多數情境意味著 WordPress。用 Codex 走到 WordPress 有兩條路：一條是讓它操作既有網站的外掛與 REST API，屬於維運路線；另一條是讓它把你生成的網站直接做成一份可安裝的佈景主題，屬於建置路線，也是這篇的主軸。兩條路在文章後段會再交會，維運工具的選擇屆時一併討論。

五段管線用一張表先看全貌：

這條管線最有價值的地方在於：前三段產出的是「你的設計資產」，規範檔與頁面原型都是可以帶走的；後兩段只是把資產翻譯成 WordPress 的語言。這也意味著，就算你換掉 Codex、改用別的程式代理，規範檔與管線結構照樣沿用，投資不會浪費。反過來說，跳過規範檔直接叫模型「幫我架一個有質感的網站」，成品品質完全取決於那一輪模型的心情，之後每一次微調都在跟漂移對抗，最後通常會回到重寫一途。

終點選 WordPress 佈景主題，理由有三。第一是編輯權的移交：交付之後客戶要自己營運，版面進模板、內容留編輯器的分工，讓不會寫程式的人也能安心改字換圖。第二是主機與資料的自主：靜態原型多半綁在特定託管服務上，WordPress 站可以搬遷、可以備份、可以換維運廠商。第三是生態：佈景主題、外掛、SEO 工具、多語系，圍繞 WordPress 的維運工具鏈在中文市場完整度最高。什麼時候不需要走到 WordPress，判斷訊號在站上的 ChatGPT Sites 分析裡有完整討論，這裡不重複（見ChatGPT Sites 深入解析）。

開工前的三個決定：入口、專案說明書、版本控制

第一個決定是在哪裡跑 Codex。它有三類主要入口：命令列、IDE 整合，以及雲端任務。架站這種需要反覆來回的工作，建議以命令列或 IDE 為主戰場，因為你會頻繁地看檔案 diff、跑本地預覽、即時修正；雲端任務適合丟一段可獨立驗收的批次工作，例如「照規範檔把剩餘四個頁面模板補齊」。各入口的定位、費用與方案差異，站上的 Codex 總覽文有完整拆解（見OpenAI Codex 完整指南）。

第二個決定是專案說明書。Codex 讀取專案根目錄下的 AGENTS.md 作為工作規則的來源，內容寫的是「怎麼工作」：程式碼風格、檔案結構、驗收方式、哪些事情必須先問。設計規範檔（第①段的產出）寫的則是「做成什麼樣子」：色彩、字級、間距、版面。兩份檔案分工清楚，模型才不會把視覺決策和工作規則混在一鍋。怎麼把說不清楚的需求變成可執行的指令，非工程師的提問框架另有專文（見Codex 零起點提問框架）。

第三個決定是版本控制。從第一版生成開始就初始化 git 倉庫，之後每完成一個區塊的迭代就提交一次。這麼做有三個用途：任何一輪改壞了可以退回；交辦給 Codex 的每一輪改動有明確邊界，diff 就是你的驗收介面；最後打包主題時，倉庫本身就是主題檔案的唯一來源，不用擔心哪個版本的檔案被覆蓋。程式代理的能力邊界在於它會犯錯，版本控制是你犯錯之後的保險，這條紀律值回所有成本。

第①段：設計規範檔，把決策寫下來，模型才有單一事實來源

設計規範檔是一份放進專案根目錄的純文字檔，慣例上命名為 design.md 或 DESIGN.md 這類名稱，內容是這個網站所有視覺決策的清單。它存在的理由很實際：模型沒有品味記憶，你說「質感要好」，它每一輪理解的質感都不一樣；你說「主色用品牌藍、標題 2.5rem、區塊間距 96px」，它每一輪才會做出同一個網站。規範檔把「好看」翻譯成可執行、可檢查的規則，後面四段全部回讀這一份檔案，這是整條管線能收斂的根基。

一份夠用的規範檔至少涵蓋六個區塊：

• 品牌代幣：主色、輔色、前景背景色的具體值，連同無障礙對比的要求。
• 字體階梯：字族、各級標題與內文的字級、行高、字重，標明斷點之間的縮放規則。
• 間距節奏：基準單位與各級間距，讓頁面垂直節奏一致。
• 版面格點與斷點：容器最大寬度、欄位結構、每個斷點的版面變化。
• 頁面清單與內容模型：每頁有哪些區塊、每個區塊裝什麼內容、內容由誰提供。
• 組件清單：表頭、表尾、按鈕、卡片、表單欄位的長相與各種狀態。

放在 WordPress 交付的脈絡裡，規範檔還要加第七項，也是多數教學漏掉的一項：可編輯區標記。在頁面清單的每個區塊上標注它未來的歸屬：這一區會進模板（鎖死）、這一區留在區塊編輯器（客戶自由編輯）、這一區做成可重複插入的圖樣。這個標記現在看只是註記，到第⑤段它就是鎖定策略的直接輸入；在規範階段先想清楚，主題化時才不會邊寫邊猜，把該給客戶的彈性做死，或把該鎖的品牌殼層留成地雷。

寫規範檔有兩個常見的坑。一個是寫成 mood board：貼一堆形容詞（簡約、大器、國際感），模型只能各自解讀，規範檔裡的每一行都應該可以拿去檢查成品，做不到就改寫成做得到的樣子。另一個是寫完就凍結：迭代過程中客戶要求調整、你自己改變主意，都應該同步回寫規範檔，讓它維持是唯一事實來源。規範檔是活文件，第③段的每一輪驗收都會回頭核對它。

示範：一家烘焙品牌官網的規範檔節錄

拿一個夠小的案例走一遍七個區塊的長相。假設客戶是一間做咖啡豆訂閱的烘焙品牌，要一個五頁官網。品牌代幣區塊寫的是：主色深焙棕、輔色奶油白、行動呼籲用焦糖橙，正文與背景的對比要達到無障礙 AA；字體階梯寫：標題用明體系字族、內文用黑體系字族，桌機 h1 到 h4 的字級與行高逐級列出，行動版整體降一級；間距節奏以 8px 為基準單位，區塊之間用 12 單位、區塊內元素用 2 到 4 單位。這些數字本身不重要，重要的是每一格都有數字，而且之後每一輪生成與迭代都對著同一組數字驗收。

後面四個區塊繼續填：版面格點寫容器最大寬 1200px、手機單欄、平板起雙欄；頁面清單列首頁、訂閱方案、豆單、品牌故事、聯絡五頁，每頁的區塊從上到下列出來，例如首頁是 hero、當月豆單三卡、訂閱流程三步、見證輪播、常見問題、電子報報名；組件清單定義按鈕三種尺寸與四種狀態、卡片圓角與陰影、表單欄位的提示文字規則。最後是可編輯區標記：hero 標語進模板、當月豆單三卡留在編輯器並註冊成圖樣、訂閱流程三步進模板但每步的說明文字開放編輯、常見問題整組做成圖樣。這份節錄不到一頁，但它足以讓任何一輪生成產出同一個網站，也足以讓第⑤段的鎖定策略照單施工，這就是規範檔的及格線。

第②段：從規範生成第一版，先生成什麼、怎麼驗收

生成階段的第一個選擇是直接生成 WordPress 主題，還是先生成單純的 HTML 原型。建議永遠從 HTML 原型開始，理由是除錯成本：原型階段你面對的是一頁可以直接打開的檔案，改壞了看得到、看懂了改得快；主題階段你面對的是模板結構、佇列註冊與快取的組合，問題會多好幾層。先在原型上把視覺與版面收斂到滿意，第④段的主題化只是結構翻譯，風險大幅下降。

給 Codex 的第一輪指令，結構上可以照這個骨架：「讀 design.md，依其中的品牌代幣與字體階梯，先做首頁。語意化 HTML，樣式寫在單一 CSS 檔，不引入框架。頁面包含規範檔首頁清單列出的區塊，每個區塊用註解標記對應規範檔的哪一節。完成後列出你對規範檔有疑問的地方。」最後那句是關鍵：規範檔第一次實戰一定有漏洞，主動叫模型回報疑問，比事後猜哪裡被它自行腦補可靠得多。

驗收第一版時，逐條對照規範檔，另外檢查四件事：每個斷點下版面都成立；標題層級符合文件結構（一頁一個 h1，其餘按階層）；文字是真的文字，可以選取、可以搜尋，圖片化的文字一律退回；色彩對比達到規範檔標的無障礙要求。這張清單看起來基本，卻是 AI 生成頁面最容易出毛病的地方，而且都是第④段翻譯成主題前必須清乾淨的債。

首頁通過驗收後，再把其餘頁面逐一補齊，一次一頁，沿用同一套指令骨架。這裡適合把「補齊剩餘頁面」這種規格明確、驗收條件清楚的批次工作丟給雲端任務跑，你保留抽查與合併的動作就好。

第一輪的驗收清單，照這張表走

清單用順序走一遍，不合格的項目直接回給模型修，訊息裡引用清單的項目名稱，例如「對比可讀這項，頁尾的淺灰連結在奶油白背景上不足，依規範檔調到過標」。把驗收語言固定下來之後，來回的每一輪都短而精準，這是對話式修正的基本功：講清楚哪裡不對、依據是哪條規範，模型就不需要猜。

第③段：單區塊迭代，一次只改一個區，改完回寫規範

迭代階段最大的紀律是一次只改一個區塊。原因在歸因：模型同時改了表頭選單、hero 區與卡片間距，視覺變好了，但你不知道是哪個改動帶來的改善，更糟的是其中一個改動其實弄壞了別的東西，被其他改善蓋過去。單區迭代讓每一輪的 diff 都可以直接讀懂，好壞都能歸因，退回也有明確目標。

迭代指令的模板可以這樣寫：「只調整 hero 區：標題字級在行動版降一級、按鈕兩顆並排改上下堆疊、背景圖在手機改用規範檔的行動版裁切。其他區塊不要動。完成後說明你改了哪些檔案的哪些行。」指定區塊、指定屬性、明確禁區、要求回報改動範圍，四個元素到齊，模型的行為才會收斂在你要的地方。

每一輪迭代通過後做三件事：把接受的改動回寫規範檔（規範與實作永遠同步）；截圖存檔建立視覺基準，下一輪對照用；提交一次 git，訊息寫清楚動了哪個區塊。三件事做完，這一輪才算結束。過程會比「叫它全部重做」慢，但重做的路徑每次都從零開始，迭代的路徑每一步都在累積，十輪之後差距非常明顯。

拿烘焙品牌的例子走一輪就懂。你看了首頁覺得當月豆單三卡太擠，指令這樣下：「只調整當月豆單區：卡片內距從 3 單位放大到 5 單位、卡與卡之間的水平間距從 2 單位放大到 4 單位、卡片標題的行動版字級降一級。其他區塊不要動。完成後列出你改動的檔案與行數。」模型回報改了哪些行，你對照截圖與規範檔確認，通過就把間距新值回寫規範檔的組件清單，提交一次 git。整輪來回五分鐘，但每個決定都留下痕跡，一週後客戶問「上次卡片是怎麼調的」，答案就在規範檔與提交記錄裡。

迭代什麼時候該停，給三個訊號：規範檔已經穩定，連續幾輪沒有回寫；每一頁在各斷點都通過同一張驗收清單；客戶看的意見從結構性的調整縮小到單一文案。訊號到齊就進第④段，別在打磨上無限循環，之後的鎖定與維運安排會回頭放大打磨的收益。

第④段：把成品改寫成佈景主題，打包成可安裝的 ZIP

主題化的第一個決定是做區塊主題還是傳統主題。區塊主題的模板用區塊標記語法撰寫，編輯體驗與站點編輯器整合；這條路線在 WordPress 5.9（2022 年 1 月）隨站點編輯器進入核心，同版亮相的預設主題 Twenty Twenty-Two 是 WordPress 史上第一個預設區塊主題，後續的預設主題也多以區塊主題示範這套工作流（見WordPress 5.9 官方發布公告，2022 年 1 月）；傳統主題用 PHP 模板，外掛相容性最廣，老專案與頁面編輯器外掛生態仍有大量需求。給 AI 世代的新站，除非有明確的相容性理由，建議直接做區塊主題，因為第⑤段的鎖定與圖樣機制在區塊主題裡是一等公民。

主題的最低結構有官方規範：所有主題都必須有 style.css，檔案開頭以註解形式寫主題資訊，其中主題名稱是唯一必填欄位，外觀頁顯示的名稱、版本與描述都從這裡讀（見佈景主題手冊的主樣式表說明）。區塊主題的模板放在 templates 目錄，表頭表尾等可重用部分放在 parts 目錄，兩者都用區塊標記語法撰寫。這一段正是 Codex 上場的地方：把第③段收斂後的每個頁面，逐頁翻譯成對應的模板檔，樣式收進 style.css 與 theme.json 的設定，這是大量、機械、規則明確的翻譯工作，恰好是程式代理的主場。

主題化翻譯實際上是三類工作。第一類是模板翻譯：把每個頁面的區塊結構逐段搬進對應模板，hero 進首頁模板、文章列表進彙整模板、表頭表尾抽進 parts，搬的時候只換結構語法，視覺 class 與樣式值原封不動。第二類是樣式收斂：原型階段累積的 CSS 依用途分流，全域設計代幣進 theme.json 的設定與樣式，組件級樣式留在 style.css，站點編輯器裡的調整與主題檔案才不會互相覆蓋。第三類是圖樣抽取：把規範檔標記為圖樣的重複版型包成圖樣檔，供第⑤段使用。三類工作都交給 Codex 逐類跑，每一類完成後用原型的截圖對照驗收，視覺零漂移才算過關。

指令骨架照抄管線的紀律：「讀 design.md 與首頁原型，把首頁翻譯成 templates/index.html，表頭表尾抽成 parts/header.html 與 parts/footer.html。主題資訊按規範檔的品牌欄位填入 style.css 檔頭。不更動任何視覺決策，有歧義先問。」翻譯與創作要明確切開：這一段允許模型做的只有結構轉換，任何視覺調整都退回第③段處理，兩條線混在一起，收斂好的設計會在翻譯途中被悄悄改掉。

打包成 ZIP 時，最常見的失敗有三種，都出在結構：壓縮時多包了一層資料夾，解開後主題資料夾外還有一層，外觀頁會找不到主題；style.css 檔頭漏了主題名稱或格式跑掉，WordPress 會直接判定不合法；新主題與既有主題同名，安裝時把別的主題覆蓋掉。正確的結構是 ZIP 解開後第一層就是主題資料夾，裡面直接是 style.css 與 templates 等內容。上傳的路徑是外觀、佈景主題、新增、上傳主題，選 ZIP、安裝、啟用，然後逐一打開每個模板核對與原型的一致。

打包這段有兩條官方替代路，值得知道。從 WordPress 6.0 起，站點編輯器可以把整個主題連同你在編輯器裡做的修改，一次匯出成主題 ZIP，模板與設定都會存進檔案（見WordPress 6.0 佈景主題匯出的開發日誌，2022 年 5 月）。官方的 Create Block Theme 外掛則進一步提供把修改存回主題、另存子主題等功能，適合喜歡先在編輯器裡調整再固化成檔案的工作方式（見Create Block Theme 外掛頁）。對以 Codex 為主的管線，手動打包仍是主路，這兩條是備援與交叉驗證的工具。

第⑤段：安裝之後，哪些進模板、哪些留編輯器、鎖定怎麼下

主題裝好只是半成品，交付前要把編輯邊界設計好，否則兩週後客戶在 Gutenberg 區塊編輯器裡把首頁 hero 刪掉半個區塊，求助電話就來了。分類的方法直接沿用規範檔第①段就標好的可編輯區標記，原則一句話：品牌殼層進模板，頁面內容留編輯器，重複版型做圖樣。

品牌殼層進模板：表頭、表尾、導覽列、首頁 hero 的版式結構，這些承載品牌一致性，改動應該走主題更新流程（回到 Codex 管線），把它們放進模板，客戶在頁面編輯器裡根本看不到，天然防手滑。頁面內容留編輯器：文案、圖片、價格、案例內容，這些是客戶日常要動的東西，做法是在 page 與 single 模板放 Post Content 區塊，文案圖片留在頁面內容，模板只管外框與可重用版面，更換內容不需要碰結構。重複版型做圖樣：服務卡片、常見問題組、見證輪播這類會重複出現或跨頁使用的版型，註冊成圖樣（pattern），客戶要用的時候從圖樣庫插入，拿到的是預先排版好的整組區塊，不需要每次從空白排起。

用烘焙品牌的標記走一遍成品：表頭表尾與導覽進模板，客戶完全碰不到；首頁 hero 整組進模板，品牌句與背景圖在頁面編輯器裡看不到，按鈕的連結目標則透過區塊綁定（block bindings）對到頁面的自訂欄位（post meta），客戶改的是欄位值、模板碰不到，品牌句不被改寫，促購連結可以自己換（見區塊編輯器手冊的 Block Bindings 說明，WordPress 6.5 起）；當月豆單三卡做成圖樣並設為內容限定，每個月換豆子、改文案、換照片，版式動不了；常見問題整組做成圖樣，新增一題就是插入一份同款版型。分類做完，客戶拿到手的編輯介面裡只剩他真正需要碰的東西，這種介面的可預測性，就是交接品質本身。

界線之內還有第二層控制：區塊鎖定。容器區塊（群組、封面、欄、欄位項目、導覽等）支援 templateLock 屬性，常用的值有三個：all 禁止移動、移除或插入區塊，但區塊內容與設定仍可編輯；insert 禁止插入新區塊，既有內容照常編輯；contentOnly 內容限定模式，把排版結構整個收起來，只留文字與圖片可編輯（見佈景主題手冊的圖樣與區塊鎖定說明）。contentOnly 最適合交接給客戶自營的重複版型：把整個服務區包起來設成內容限定，客戶看到的就是幾個乾淨的文字欄與圖片欄，改錯結構的機會直接歸零。

三個值怎麼選，用一張表對照：

選擇的原則是信任遞減：客戶越常碰的區域，鎖得越「內容化」；客戶一年不會碰一次的區域，直接 all 或乾脆進模板。把三種值都想成同一個光譜上的刻度，安排鎖定時就不會陷入全開或全關的二選一，而能按每個區域的實際使用頻率給出恰當的自由度。

鎖定的粒度還可以到單一區塊。從 WordPress 5.9 起，任何區塊都可以個別設定鎖定移動與鎖定移除，而且區塊層級的設定會覆蓋上層繼承的鎖定值，等於容器先劃大範圍、個別區塊再微調（見WordPress 5.9 區塊鎖定的開發日誌，2022 年 1 月）。實戰上我會鎖三種東西：品牌殼層裡的標誌與導覽（防誤刪）、收錄在圖樣裡的裝飾性區塊（防拆散）、任何一拿掉就會弄壞排版骨架的結構區塊。文案與圖片永遠開放，鎖定的對象是結構，內容留給人。

安排鎖定時有一個心態要擺正：鎖定是可用性設計，防的是手滑與迷失，它不是權限控制。具備管理員身分的人可以解除鎖定，真正的安全邊界在使用者角色與權限的配置。給客戶的帳號開編輯者角色，再配合模板與鎖定設計，兩層加起來才是穩定的交接；把鎖定當安全管理，會在第一次有人拿管理員帳號進來時破功。

交接之後：維護、升級與內容維運

管線走完，工作型態從建置轉維運，三個安排先講好。第一，內容與結構分離是 WordPress 的既定設計：頁面內容存在資料庫，版面存在主題檔案，主題換版、重裝都不動內容，這正是第④⑤段辛苦分工的回報。第二，未來的設計變更走原管線：規範檔更新、Codex 改模板、重新打包，客戶的日常內容完全不受影響；要避免的事是在編輯器裡手改模板副本，那會讓主題檔案與線上狀態分岔，之後沒有人敢升級。第三，客製需求用子主題承接，升級路才不會被自己的修改堵死。

主題的版本管理沿用倉庫那套就夠了：每次改版把版號寫進 style.css 檔頭、git 打上標籤，改了什麼從提交記錄直接可讀；客戶端的升級在測試站先跑一輪，核對模板與鎖定行為沒有被核心更新改變，再推上正式站。這套節奏跟傳統主題開發沒有兩樣，差別在改動的源頭多了一個代理：Codex 照規範檔產出修改，你驗收 diff，流程裡多了一層審核，責任仍然在你。交接文件也值得花半小時寫：規範檔放在哪、改版流程怎麼走、哪些區域被鎖定以及為什麼，這份文件接手的任何人都看得懂，交付才算真的完成。

日常的內容維運可以再往上加一層自動化：把 WordPress 的 REST API 接成模型可操作的介面，批次改文案、健檢文章、產生報告都交給代理跑，人保留審核與發布。這條維運路線的工具選擇與風險邊界，站上的 MCP 實戰文有完整拆解（見Claude Code 加 WordPress 的 MCP 工作流），建置與維運兩篇合起來，就是從零到長期營運的完整地圖。

這條路跟其他 AI 架站路線怎麼選

AI 架站的方法論這兩年快速長出好幾條路線，各自有不同的強項與終點。用一張表定位：

表裡每一列站上都有對應的深入專文。以 Claude Code 走通用開發流蓋形象站、部署到靜態託管的完整流程，含專案說明書、技能與 MCP 的搭配（見Claude Code 架站實戰）；把 Gemini 生態的設計工具與代理實作串成雙打工作流的做法（見Gemini 網頁設計工作流）；跨陣營把設計工具的產出交給 Claude Code 實作的串接經驗（見Stitch 配 Claude Code 的設計工作流）；用對話驅動做出 3D 與互動感網站的方法與其邊界（見Vibe Coding 架站教學）。這篇與它們的差別在終點：別人停在可部署的網頁，這篇走到可交接、可自營的 WordPress 主題，兩者可以接力，前期用任何路線做原型，定案後交給這條管線主題化。

選路線時問自己兩個問題就夠了。第一個：這個網站交付之後由誰維護？客戶自己要營運、要常常改內容，WordPress 主題這條路的價值最大；你自己維護、以行銷活動為主的短期站，靜態部署反而輕省。第二個：設計資產會不會重複使用？會的話，規範檔驅動的管線值得從第一個案子就開始累積，同一份代幣與組件清單，改個品牌色就是下一個客戶的起點。兩題的答案都指向這條管線時，就照下面的段落開工。

把管線交辦出去：OpenAI 工具實戰軸的分工

這條管線的五段裡，②③④都適合逐步交給代理自主跑，而 OpenAI 自己的工具軸剛好把這件事變得更順：持續性的監測與排程交給個人代理，獨立的批次實作交回 Codex 雲端任務。例如把「每週核對規範檔與線上首頁的偏差、彙整差異清單」交給代理盯，發現漂移後再開一個雲端任務照規範檔把模板修正回來，人在中間只做驗收。代理交辦的方法論、權限分層與驗收紀律，站上的 Dots 實戰文有完整拆解（見ChatGPT Dots 完整指南）；它如何把工作下派給 Codex 任務、額度怎麼計，文中同場看得到。

一個更完整的交辦樣貌是三層接力：第一層代理負責盯，把「規範檔說卡片間距 4 單位、線上實測是 2 單位」這類偏差整理成清單；第二層 Codex 雲端任務負責修，照規範檔產出修正後的模板與 diff；第三層是你，看完 diff、合併、打包、推測試站。三層各做自己最擅長的事，人的時間只花在判斷上。這個結構現在就能搭，而且不依賴任何單一廠商：清單與規範檔都是純文字資產，換工具時整組搬走。

交辦的邊界與第③段的紀律一致：交出去的是規格明確、驗收條件清楚、失敗可逆的段落；規範檔的修訂、設計決策的取捨、對客戶的承諾，留在人手上。管線自動化的程度越高，這條線越要劃得清楚，否則你省下的時間會在事後的清理裡加倍吐出來。

誠實的限制與下一步

這條管線能走的邊界也要老實交代。生成品質仍需人工驗收，模型對規範檔的遵循度再高，對比、斷點與互動細節的把關責任仍在人；WordPress 核心與區塊編輯器仍在演進，鎖定與模板機制的行為可能隨版本調整，升級前要在測試環境核對；外掛相容性要個別確認，快取、SEO、多語系外掛與自製主題的互動，是交接前最後一輪健檢的重點；最後，區塊鎖定防手滑，真正的權限治理要靠使用者角色配置，兩者搭配才完整。

下一步很具體：開一個空資料夾，寫下你手頭專案的設計規範檔，七個區塊填滿，特別是可編輯區標記；讓 Codex 從首頁原型開始跑第一輪，用逐條對照的清單驗收；滿意後照單區紀律迭代，再走主題化與打包，裝進測試站，把鎖定策略設好，找一個完全不碰程式的人試改一段文案。那份規範檔會是你這條管線裡活得最久的資產，從第一頁原型跟到你第十個客戶的網站。