我原本只是想替 Lukas Lab 換一套比較像自己的顏色。
背景不要那麼死白，改成帶一點溫度的暖白；文字不要只剩純黑，換成比較沉穩的深藍；連結再用藍灰色拉開層次。需求不複雜，也沒有要重做首頁、換主題或大改版面。
那一輪由 AI 協助操作 WordPress 全域樣式。色票建立了，欄位也設定了，編輯器顯示儲存成功，整個流程看起來十分和平。
結果我打開正式前台一看：
網站還是原本的白底黑字。
沒有錯誤訊息，沒有版面爆炸，也沒有按鈕突然消失。最麻煩的地方，正是它看起來什麼事都沒有發生。
如果我只看後台的「已儲存」，或只接受 AI 回報「已完成」，這張工單大概就會被當成施工成功。
幸好，網站最後是給讀者看的，不是給後台看的。
我只是想改顏色，沒有要把整個網站拆掉
這次原本要套用的核心配色只有六項：
| 項目 | 色碼 |
|---|---|
| 網站背景 | #F7F5F0 |
| 一般文字 | #1F2A37 |
| H1、H2、H3 與網站標題 | #1F2A37 |
| 一般連結 | #315676 |
| 按鈕背景 | #1F2A37 |
| 按鈕文字 | #FFFFFF |
另外還準備了中性灰、米色、金棕與淺灰邊線，打算先放進可用色盤，之後再依首頁、文章卡片或資訊元件的實際需要使用。
問題就出在這批自訂色票。
儲存後，全域樣式裡部分顏色引用指向了 custom-，實際輸出的色票變數名稱卻是 custom。只差一個符號，對人眼來說很像同一個東西；對瀏覽器來說，它們就是兩個不同的名稱。
以下是概念化示意，不是完整的網站原始碼：
/* 樣式欄位實際引用 */
color: var(--wp--preset--color--custom-);
/* 頁面真正輸出的色票變數 */
--wp--preset--color--custom: #1F2A37;前者找不到後者，正式前台自然拿不到預期的顏色，視覺上仍維持主題原本的呈現。
這不是「WordPress 改顏色一定會壞」，也不是所有區塊主題都會發生相同問題。它只是這一次施工中，色票名稱與引用沒有對上的具體錯誤。
儲存成功，不代表前台拿到了有效設定
這次翻車讓我重新確認一件很基本、卻很容易被跳過的事：
後台接受了設定，不等於瀏覽器最後讀到的是有效設定。
WordPress 編輯器負責把設定存進去，主題與全域樣式再把它們轉成前台可以使用的輸出，瀏覽器最後才依照那些規則顯示畫面。
這三段只要有一段沒有接好，就可能出現「後台看起來完成，前台卻沒有變」的情況。
所以驗收不能只看：
- 儲存按鈕是否按下。
- WordPress 是否跳出成功訊息。
- AI 是否回報完成。
- 編輯器內的模擬預覽是否看起來正常。
至少還要打開正式前台，確認真正公開的頁面已讀到新設定。
那次我檢查的不是單一頁面，而是首頁、長篇文章、分類頁與一般頁面。因為同一套全域顏色，在不同範本裡可能遇到不同背景、連結、按鈕與文字層級。
為什麼沒有繼續新增色票，試到它正常為止？
發現引用錯誤後，最直覺的做法可能是刪掉再建、換個名稱再建，或者繼續調整 Slug，直到其中一組剛好能用。
我沒有這樣做。
因為當問題已經發生在「色票名稱如何被輸出與引用」，繼續增加自訂色票，只會再增加更多名稱、Slug 與引用關係。表面上像是在修錯，實際上可能只是把更多變數堆到同一個還沒釐清的地方。
而且這次的真正目標只是讓六個核心顏色穩定生效，不是建立一套豪華色票管理系統。
所以我先把工作拆成兩件事：
- 先清掉這次造成的錯誤引用，讓網站回到乾淨狀態。
- 確認原本的字體、版面、範本與導覽都沒被影響，再重套真正需要的顏色。
功能少一點沒關係，狀態要先可理解。
第一步：只復原顏色，不重設整個網站
全域樣式最危險的地方，是它的範圍真的很「全域」。
如果為了修一組顏色，順手把整套樣式重設，可能連字體、字級、行高、內容寬度、區塊間距與其他既有設定一起回到預設值。顏色也許修好了，網站卻多出五個新問題。
因此這次復原有一道很清楚的邊界：
只能復原顏色；如果無法確認影響範圍，就停止。
實際處理順序是：
- 先確認正式前台仍可正常開啟，沒有文字消失、背景異常或版面跑掉。
- 只讀檢查現有自訂色票、色碼、Slug 與各欄位的引用方式。
- 查看樣式修訂紀錄，確認能不能辨識這次施工之前的版本。
- 能明確辨識，就復原至施工前的顏色狀態。
- 若無法辨識完整修訂，但能只重設「顏色」，就只重設顏色。
- 如果介面只能重設全部網站樣式，立即停止，不拿其他設定陪葬。
復原完成後，先儲存一次，再回到正式前台確認：白色背景、深色文字、黑色按鈕都已恢復，頁首、頁尾與版面維持原樣。
這一步沒有品牌感，也沒有完成新設計，但它建立了乾淨的起點。
第二步：不用自訂色票名稱，直接輸入色碼
確認復原完成後，我沒有再次建立那批自訂色票，也沒有繼續碰色票 Slug。
這一輪只在各個全域顏色欄位中直接輸入十六進位色碼，而且不一次改完六項。
第一輪：背景、文字與標題
先修改：
- 網站背景：
#F7F5F0 - 一般文字：
#1F2A37 - 標題：
#1F2A37
儲存後，離開編輯器預覽，實際開啟正式前台。
要確認的不是「大概有變」，而是暖白背景與深藍文字確實出現在公開頁面，且沒有再次輸出無法解析的顏色引用。頁首與頁尾文字也不能因背景改變而失去對比。
第一輪通過，才進入第二輪。
第二輪：連結與按鈕
再修改：
- 一般連結：
#315676 - 按鈕背景：
#1F2A37 - 按鈕文字：
#FFFFFF
再次儲存並驗證正式前台，確認連結可辨識、按鈕文字清楚，而且手機導覽與分類下拉仍能正常使用。
把六個欄位拆成兩輪，看起來多花了一次儲存與檢查；但若第二輪出錯，我至少知道問題只可能落在連結或按鈕，不必回頭猜六個欄位中的哪一個動了手腳。
分次施工不是拖慢速度，而是縮小故障範圍。
哪些情況應該立刻停止？
這次修復真正重要的，不只是做了哪些動作，還包括哪些事情一出現就不再往下做。
我的停止條件是：
- 無法辨識安全的樣式修訂版本。
- 復原顏色會連帶影響字體、版面或範本。
- 無法清除錯誤的自訂色彩引用。
- 編輯器再次產生不一致的 Slug。
- 直接輸入色碼後，仍被轉成無效變數。
- 正式前台與編輯器預覽結果不同。
- 頁首、頁尾或按鈕文字變得難以閱讀。
- WordPress 出現錯誤、警告或儲存衝突。
- 必須修改自訂 CSS、
theme.json、主題檔案或其他範本才能繼續。
這些條件的作用不是讓工作顯得謹慎，而是阻止一個顏色問題擴張成全站事故。
有些任務不是「想辦法完成」最重要，而是先知道自己不能拿什麼當代價。
修復後，網站最後留下什麼？
完成兩輪重套後，Lukas Lab 的核心配色穩定為：
| 用途 | 最終色碼 |
|---|---|
| 背景 | #F7F5F0 |
| 正文與標題 | #1F2A37 |
| 連結 | #315676 |
| 按鈕背景 | #1F2A37 |
| 按鈕文字 | #FFFFFF |
原本準備的中性灰、米色、金棕與淺灰邊線，這一輪完全沒有重新建立。
不是它們永遠不需要，而是當時沒有任何元件真的要用到它們。等首頁區塊、文章卡片或資訊元件出現明確情境，再在能看見實際效果的位置處理，比先把一排色票放著安心更容易維護。
網站最後得到的，不是一套最完整的品牌色盤，而是一套已經證明能正常工作的核心配色。
WordPress 全域樣式安全修改檢查表
如果你也準備修改 WordPress 區塊主題的全域樣式，可以先用這份簡化檢查表：
修改前
- [ ] 記錄目前使用的主題與樣式狀態。
- [ ] 確認這次只要改顏色、字體、版面，還是其他設定。
- [ ] 截圖或記錄修改前的正式前台。
- [ ] 選定首頁、文章頁、彙整頁與一般頁面作為驗證樣本。
- [ ] 先寫下停止條件，不等出錯後才決定。
儲存後
- [ ] 不只看「已儲存」訊息。
- [ ] 打開正式前台，不只看編輯器模擬預覽。
- [ ] 檢查頁首、頁尾、正文、連結與按鈕的對比。
- [ ] 同時檢查桌機與手機。
- [ ] 若前台未生效，先查輸出與引用，不要立刻新增更多設定。
發現錯誤時
- [ ] 先確認網站仍可正常閱讀與操作。
- [ ] 優先只復原出錯的設定域。
- [ ] 無法確認影響範圍時停止，不重設全部樣式。
- [ ] 修正後分批重套，每批都要重新驗證。
- [ ] 保留修改前後紀錄，讓下一次不用重新猜測。
這份清單不保證 WordPress 永遠不會出錯，但至少能避免我們在修一個問題時，順手製造一整排新的問題。
最後，真正通過驗收的是前台，不是回報
這次事故沒有讓網站掛掉，也沒有造成資料遺失。它只是讓一套已經「儲存成功」的配色，沒有真正出現在讀者眼前。
但也正因為畫面沒有爆炸，它更容易被忽略。
AI 可以依照規格填欄位、按下儲存、比對色碼，也可以協助追查輸出與引用。可是哪一個畫面才算完成、出了問題要不要繼續、允許修到哪裡，最後仍然需要人做決定。
網站不是在後台完成的。讀者真正看見的前台，才是最後的驗收現場。
這也是我在這次配色翻車後，真正留下來的東西。