本文也說明 Joomla／WordPress 使用 Codex、Claude Code、Cursor 維護網站時該注意什麼。
AI 幫你改完網站，你怎麼知道它真的改對了？
一次 Codex 工作階段的真實稽核紀錄，71 分鐘做了什麼，逐行核對過才知道。
客戶用 Codex 在自己的網站上工作了一個工作階段，前後約 71 分鐘。
畫面看起來動過了，選單順序變了，證書頁也多了些內容。
看起來像是改好了，但我們專業的做法是不看「看起來怎樣」，直接拉出工作階段前後的兩份備份，逐項核對檔案跟資料庫，
才知道 Codex 這次實際做了什麼、哪裡沒做到、哪裡還帶著新的 bug。
這次案例發生在 Joomla 網站，但同樣的問題也很常出現在 WordPress。
只要網站是由 CMS、Theme／Template、Plugin／Extension、Page Builder 與資料庫共同組成，
AI Coding Agent 如果沒有先分清楚「資料層、版型層、外掛層、前端呈現層」，
就很容易把應該修改後台資料的問題，改成前端 JavaScript 或 Template 補丁。
只動了一個檔案，資料庫完全沒改
核對結果，Codex 這次只動了 templates/index.php 這一個檔案，資料庫內容完全沒動。
範圍算清楚，這是好消息，代表沒有意外動到不該碰的地方。
選單改動：合理，但留了視覺垃圾
中文選單把「國際認證」「最新消息」從後段搬到「首頁」後面，英文選單同步調整，
並把 "About Us" 改成 "About"、"Products" 改成 "Products & Technology"；
手機版選單做了同樣的搬移跟新增。這部分改動本身合理，方向沒問題。
但收尾沒做乾淨：
搬移後留下兩行空白的殘留，純視覺垃圾，不影響功能，但代表這次改動沒有仔細清過場。
新增 700 行 JS：補丁，不是修復
檔案最尾端新增了一大段 JS，約 700 行，加了三個函式：tuneCompositeHero()、mountCompanyData()、initCertificationLightbox()，外加幾個隱藏的 的內容區塊。
這根本不是修復，是針對「頁面內容本來就是複製貼上」這個舊問題寫的前端補丁：
依網址判斷目前是哪一頁，硬改共用 Hero 的標題文案，
把隱藏 template 裡的證書圖片用 JS mount 進頁面。
用前端 JS 蓋掉共用內容的重複問題，而不是回到源頭修正頁面結構本身。
如果是 Joomla，應該先確認文章內容、選單、模組、Template Override、SP Page Builder 或其他 Extension 的資料來源；
如果是 WordPress，則要往文章／頁面內容、Theme、Template、Block、Elementor／Divi 等 Page Builder、Plugin 與自訂欄位去查。
兩者的後台架構不同，但原則完全一樣：
資料錯就修資料，版型錯就修版型，不要先用前端 JavaScript 把錯誤遮起來。
補丁本身有 bug
清除錯誤影片的程式碼，抓的 class 是 .ab，但頁面實際的影片 class 是 .a1、hero-video。
AI 選錯了目標，影片自然清不掉，導致證書頁還在播放金屬 3D 列印的影片。
這是典型的「寫了處理邏輯，但目標選錯，程式碼跑了，效果沒出來」的錯誤，光看程式碼可能沒問題，只有實際打開頁面比對才會發現。
覆蓋範圍不完整
這段 JS 的判斷清單只涵蓋約 20 種頁面別名，另外 12 個頁面完全沒被涵蓋，等於這批頁面完全沒補到，問題原封不動留在那裡。
資料庫層面：開過但沒改到什麼
#__menu 表裡，兩筆選單項目被標記成「已由使用者 93 於 07:06 checked out」，
代表 Codex 有登入後台開過這兩個選單項目的編輯畫面，但存的內容看不出實質差異，可能只是打開看過、存檔沒改東西。
這種狀態要留意的是有沒有卡在「已鎖定」不放，如果沒解鎖，之後真人要編輯同一個選單會被擋下來。
網頁編輯器的頁面內容（#__sppagebuilder）完全沒被動過，我們逐位元組核對過，跟原本一模一樣。
Joomla／WordPress 用 AI Coding 維護網站，最容易踩哪些坑？
Joomla 與 WordPress 都不是單純的一堆 HTML 檔案。
頁面最後看到的內容，可能同時來自 CMS 資料庫、Theme／Template、Plugin／Extension、Page Builder、自訂欄位與前端 JavaScript。
AI Coding Agent 如果只看到前台結果，卻沒有先找出真正的資料來源，就很容易在錯的層級修改。
| 問題 | Joomla 常見來源 | WordPress 常見來源 |
|---|---|---|
| 頁面內容錯誤 | Article、SP Page Builder、Module | Post／Page、Block、Elementor／Divi |
| 選單錯誤 | Menu Item | Navigation／Menu |
| 版面錯誤 | Template、Override | Theme、Template |
| 功能錯誤 | Extension／Plugin | Plugin |
| AI 最容易亂補的位置 | index.php、Override、JavaScript | functions.php、Theme JS、Custom Code |
否則很容易從「修一個錯字」變成「新增一套只有 AI 自己看得懂的特判系統」。
對人類的影響是什麼？
AI Coding 最可怕的地方，是它可以把錯誤包裝成「看起來已經好了」。
如果你現在正在用 Codex、Claude Code、Cursor 或其他 AI Coding Agent 維護 Joomla、WordPress 或其他 CMS 網站，
建議記住一件事：不要只驗收畫面。
這次案例是 Joomla，但如果換成 WordPress，情況其實很像。
真正的問題可能在文章內容、Theme、Plugin、Elementor、ACF 或其他 Page Builder
如果 AI 沒有先確認來源，就可能直接跑去 functions.php、Theme Template 或前端 JavaScript 做 workaround。
最後看到的畫面雖然正常，真正的資料與架構問題仍然留著。
這也是為什麼之後人類接手會特別痛苦。
你看到 CMS 裡的內容，跟網站顯示的不一樣；
你改了後台，前台可能又被 JS 蓋回去；
你移除一段 CSS，才發現某個頁面其實靠 alias 特判。
最後真正花時間的不是寫程式，是考古，找出到底誰在什麼地方偷偷改了什麼。
企業導入 AI Coding Agent，建議至少要求每次修改都說明：
修改層級、修改檔案、是否改資料庫、是否新增 workaround、是否存在 hardcode。
不然今天看起來省了一個工程師的時間，幾個月後可能是另一個工程師在凌晨兩點問：
到底是哪個天才在 index.php 塞了 700 行 JS？答案是 AI。
Codex 沒有刪掉或弄丟任何原本的 renderer，這點可以放心。
但它是在「頁面內容本來就是複製貼上錯誤」這個舊坑上面，又加蓋了一層不完整的 JS 補丁，讓部分頁面看起來比較不明顯壞掉，卻沒有真的修好，
而且新增的補丁本身還帶著一個影片選擇器的 bug。
AI 工具做完事情，看起來動過、看起來有改善，不代表真的做對了。
真正能確認的方法只有一個：
把改動前後的檔案跟資料庫拉出來，逐項核對，而不是相信摘要或畫面看起來順不順眼。
用 AI 工具改完網站，想知道它實際做了什麼？
益盛科技提供網站維護、Joomla／WordPress 後台稽核與 AI 輔助開發把關服務。
LINE 諮詢 查看 AI SEO 服務 查看 網頁設計 服務 查看 品牌電商 服務
