從頭到尾建立 WordPress 網站
為何需要此方法
當一個代理的回饋循環緩慢時，它的設計品質就會很差。在 WordPress 內部進行頁面佈局，每次迭代需要三到五分鐘——撰寫、儲存、序列化、清除、重新載入、查看。在搭配開發伺服器的本地 HTML 中，相同的循環只需五秒鐘，而設計品質與迭代次數的關聯性遠比任何美學指令都更為可靠。
第二個部分是交付上的限制：客戶在無需撰寫程式碼的情況下編輯網站。這就是為什麼禁止使用原始 HTML 區塊和模板擁有的內容——這限制了轉換，但從不限制繪製。
一句話總結：設計存在於檔案中，而非頁面內容中。WordPress 接收的是一個完成的主題，而不是版面指令。
最重要的兩條規則
規則 0 — 在繪製階段 2 時，假裝階段 4 不存在。 模型不應受到任何轉換限制的影響。在繪製時預先考慮「不能使用 core/html」會悄悄抹去深度、重疊和中心物件；結果雖然能完美轉換，卻無法取悅任何人。
規則 0′ — 不容許任何美學自由偏離參考。 有了參考，模型會傾向於自己的風格：參考是冷白色，它變成暖米色；參考使用一個無襯線字體，它用一個有特色的襯線字體；參考沒有的強調色，它加上一個。從參考中讀取七項註冊不變量並加以重現；若要更改任何一項，必須在編碼前向客戶提出詢問。這些不變量、註冊關卡和測量腳本位於 references/register.md。
十條規則
每一條都來自實際發生過的錯誤。
- 需要視覺參考。沒有參考，輸出會回歸到統計平均值：中性字體、紫色漸層、白色頁面。
- 模型不能沒有真實照片。一個灰色方塊看起來就像一張損壞的圖片。
- 在獲得客戶的兩次核准前，不得將任何內容推向 WordPress 正式環境：核准模型，然後核准部署計畫。
- 首頁是一個頁面，而不是一個模板 —
front-page.html包含頁首、post-content和頁尾。 - 零個
core/html區塊。使用群組、標題、段落、圖片來組合。 - 圖片存放在媒體庫中，每個
core/image都帶有id。 - 所有互動變體都放在頁面中；腳本用於切換類別。
- 設計之下不使用第三方主題。
- 在編輯器中驗收，而不是在前端 — 一個頁面可能完美渲染，但在 Gutenberg 中卻無法使用。
- 像素級精準度是測量出來的，不是靠肉眼判斷：逐個選擇器比較計算後的樣式和幾何屬性。
階段與其關卡
在前一個關卡通過之前，請勿開始下一個階段。
| 階段 | 負責人 | 退出關卡 |
|---|---|---|
| 0 · 工作區 | 代理 | 專案位於使用者的工作資料夾，且有寫入權限 |
| 1 · 簡報 | 客戶 | 參考調查，從參考中提取的調色板和字型，「我需要添加的項目」清單 |
| 2 · 模型 | 迭代式 | 首頁的 HTML，通過註冊關卡，客戶核准 |
| 3 · 頁面集 | 代理 | 每個頁面都從單一的頁首/頁尾來源組合而成 |
| 4 · 區塊主題 + 暫存 | 代理 | 主題建立完成；本地 WordPress 透過可重現工具設定；關卡 1–5 在暫存環境通過 |
| 5 · 部署 | 代理，在客戶核准計畫後 | 在 Web 根目錄外備份，然後在正式環境中執行相同的工具 |
| 6 · 驗收 | 代理 | 關卡 1–5 在正式環境通過，否則回到階段 4 |
階段 0–3 與部署計畫：references/phases.md。HTML 轉區塊轉換：references/block-conversion.md。五項關卡及其程式碼：references/acceptance.md。
暫存是本地端的，而每個變更都是一個工具。 內容和配置是透過冪等 PHP 腳本（tools/install-site.php、tools/configure-*.php）使用 PHP CLI 針對本地副本執行的，絕不會在 wp-admin 中手動輸入。相同的腳本在部署時會於正式環境中重播，而重播同一腳本兩次不會有任何改變——這是經過檢查、而非假設的。
選擇分支
每種網站的方法都相同；不同的是階段 4 之後的內容。
| 網站類型 | 什麼會改變 | 閱讀 |
|---|---|---|
| 展示型網站 | 頁面、表單（Contact Form 7 + Flamingo）、法律頁面 | 本文件與階段文件 |
| 商店 | WooCommerce 區塊模板、商品目錄匯入、產品篩選器、購物車/結帳區塊、同意聲明、付款、電子報、訂單確認 | references/store.md |
| Web 應用程式 | 自訂文章類型、角色、REST、動態區塊、帳戶流程 — 模型仍然驅動所有公開畫面 | references/web-app.md |
references/store.md 是基於實際建置進行測量的（WooCommerce 11.2.2，區塊結帳，區塊主題）。references/web-app.md 則尚未經此驗證：文件中會說明這一點，並引導至適用的技能。
事實屬於客戶
模型會根據簡報創造文案；它從不創造事實。評論、評分、客戶數量、新聞標誌、交貨時間、服務價格、法律條款和公司身分應保留為可見的佔位符 — à compléter 用於只有客戶能提供的資訊，à vérifier 用於在舊網站上讀取但可能已過時的資訊。捏造的評論能通過所有關卡，卻是唯一可能讓客戶承擔法律責任的缺陷。
在評論、提交訊息和報告中，說明哪些主張是測量的（附上日期），哪些是讀取的（附上來源）。
工具
| 檔案 | 使用時機 |
|---|---|
scripts/serve.mjs | 階段 2 — 無依賴的靜態伺服器，當一個埠被佔用時嘗試下一個埠 |
scripts/assemble.mjs | 階段 3 — 從單一的 <head>、頁首和頁尾來源建立每個頁面 |
scripts/fetch-fonts.mjs | 階段 4 — 自架 Google 字型：訪客無需向 Google 發出請求，無需根據 GDPR 申報任何事項 |
scripts/novamira.mjs | 階段 5 — 透過 HTTP 呼叫 Novamira 功能，無需註冊 MCP 伺服器 |
assets/theme-skeleton/ | 階段 4 — 最小區塊主題：帶有 blockGap: 0px 的 theme.json、editor.css、編輯器中的字型 |
參考文件
| 檔案 | 何時閱讀 |
|---|---|
references/register.md | 在階段 1 之前，以及在展示任何模型之前 |
references/phases.md | 階段 0–3，然後是階段 5 的部署順序 |
references/block-conversion.md | 在階段 4 期間，每次都要閱讀 |
references/acceptance.md | 階段 4 和 6 — 五項關卡與測量衛生 |
references/store.md | 任何 WooCommerce 網站 |
references/web-app.md | 會員制、預約、儀表板、任何需要登入使用者執行工作的事項 |
references/pitfalls.md | 只要出現讓你感到意外的症狀時 |
相關技能：wp-theme-block-fse 用於 theme.json 和模板、wp-design-system 用於設計標記、wp-woocommerce 用於鉤子和 HPOS、wp-deploy 用於遷移、wp-plugin-architecture 和 wp-blocks-gutenberg 用於應用程式程式碼、wp-accessibility 和 wp-performance 用於驗收前檢查。