我覺得用 AI 開發 WordPress 外掛和其他產品很不一樣，AI 在沒有特別指定的情況下，它會用 React 搭配 Tailwind CSS 來設計前端介面，資料庫的部分則是使用第三方服務像是 Supabase，後台內容管理系統（CMS）通常不會有。
對於已經擁有非常成熟後台管理系統的 WordPress 來說，使用 AI 開發就是一個很大的變數，如果是只有單一幾個檔案的小外掛，還不會發現到什麼問題，但如果今天是架構比較龐大，並且會牽涉到外部 API 以及前端的 AJAX 資料互動時，以下的問題就很容易被放大：
1. AI 很難真正理解 WordPress 的開發哲學
WordPress 已經發展超過 20 年，它不只是一個框架，而是一整套有歷史包袱的生態系，它有自己獨特的開發邏輯與哲學，也有大量依賴慣例，並且技術文件會隨版本演進，舊寫法與新寫法並存，但問題在於 AI 不一定能即時掌握最新、最正確的 WordPress 開發方式，這部分在開發區塊（Block）的時候最為明顯。
2. 外掛架構與 PHP 寫法，會直接影響後續可維護性
實際踩雷最多的地方，集中在三個層面：
- 外掛整體架構設計不合理
- PHP 寫法不符合 WordPress 程式碼規範
- 資料結構與職責劃分混亂
這些問題在一開始寫功能時不一定看得出來，但到了測試、擴充、除錯階段，會讓時間成本直接爆炸，即使一再強調要遵循 WordPress 開發規範、要可測試、可拆分，AI 在實作時還是很容易寫出超過一千行的檔案。
3. WordPress 生態系的衝突，AI 幾乎無法判斷
另一個 AI 幾乎無解的問題是外掛與外掛之間的衝突，在 WordPress 世界裡，你寫的功能，可能會跟其他外掛、主題甚至是 Composer 套件產生衝突，但問題不一定出在你這份程式碼，有時甚至是大家都沒錯，但就是不能一起用。
像我就遇過 Guzzle HTTP 在不同外掛間的版本衝突問題，請 AI 修正檢查了數十次，燒完了好幾天的 Token，但還是沒有辦法解決。最後只能繞一大圈，改用外部服務來解決。
因為上述的問題，我決定把去年一整年用 AI 開發 WordPress 外掛的實戰經驗整理出來，希望能給未來想用 AI 投入 WordPress 開發的朋友有一份參考的資料。
WordPress 的 AI 開發原則
根據適合的專案，選擇穩定的開發工具
如果是做自己用的小工具，我會採用 Cursor 或是 Antigravity 來進行開發。這類的開發方式比較偏向直覺式開發，我不會在意太多 AI 寫出來的程式碼細節，只要可以運作就好，我會用編輯器內建的 AI 功能來進行開發。
早期是用 Cursor，因為當時的方案很佛心，後來漲價之後我就換到 Antigravity。目前用來做一些小東西或是閱讀一些程式碼免費方案是非常夠用的，雖然我後來還是去買了 Pro 版本，至少目前還沒有遇到用量超過而需要被額外收費的狀況。
如果是要開發產品或是客戶的專案時，我採用的編輯器是 PhpStorm 以及 Claude Code，之所以會選擇 PhpStorm，是因為它是一個完整的開發環境，裡面包含很多免費編輯器必須額外安裝擴充才能使用的功能，像是程式碼自動修正、重構、程式碼品質的檢查等等。
再加上它對 WordPress 的支援度很好，我最常用的功能就是可以直接點擊 Hook 名稱去查看定義該 Hook 的地方，這樣就可以透過程式碼來判斷 Hook 的執行點，省去查看文件的時間，另外就是可以直接在存檔時將 PHP 修改成符合 WordPress 程式碼規範的格式，如果之後要上架官方目錄的話，會比較方便。
Claude Code 我使用的是 $100 美元的 MAX 方案，每天大約使用 6 個半小時，以我的開發方式來說這個方案非常夠用。我是直接使用 PhpStorm 內建的終端機來開啟 Claude Code，並且會開啟多個終端機分頁來同時執行多個任務，但極限就是三個，超過三個的話我的大腦會負荷不了 🤯。
以下是我開發產品或客戶專案時所採用的流程：
後端先設計資料結構，再寫資料操作的類別
我在實務上採取的核心原則是先設計資料結構，我會先在 ChatGPT 或是 Gemini 討論我想要的功能需要哪些流程，再從流程中去拆解所需的資料欄位，確認沒問題後，就會回到 PhpStorm 依照以下步驟來進行實作：
- 確認是否需要建立或修改資料表，有的話先設計資料庫版本升級策略
- 建立「單一職責」的資料表 CRUD 類別，先規劃 → 我確認 → 再實作
- 建立 API 或是 Ajax 專用類別，強制使用上一步的 CRUD 類別，一樣先規劃再實作
- AI 寫完後我自己實際執行程式碼來驗證資料操作的正確性，使用的工具是 Tinkerwell 或是 Postman.
- 後端測試沒問題後，請 AI 產出一份給前端用的文件，我用 Claude Code 的 Skills 來進行整理
/clear清空該階段的 session
前端先塞假資料，互動穩了再接後端
前端的部分我會請 AI 設計版面，如果是做後台介面的話，我會要求他符合 WordPress 後台內建的 UI 設計風格以及版面配置，我覺得這對於 WordPress 的使用者來說會是比較友善的，不然依照 AI 的個性，很容易就會設計出花花綠綠的介面，讓使用者不好適應。
在 UI 資料的呈現上，我會請 AI 先使用假資料，確認互動功能以及操作流程都沒有問題，再請 AI 依照後端文件的 Skills 進行串接，測試的部分就是我自己實測並修 Bug。
如果是要開發產品，我都會要求 AI 使用 jQuery 以及原生的 CSS，不要用任何的框架或是元件庫，藉此避免可能的潛在衝突，之前遇過一套我常用的 CSS 框架，竟然跟效能分析軟體 New Relic 的前端監控程式發生衝突。
WordPress 的環境非常多變且與其他服務有整合。為了減少這類衝突，後來我還是盡量使用 WordPress 原生的工具最為保險。另外一個好處是，jQuery 已經原本就內建了，不需要再額外引入，可以進一步減少對第三方套件的依賴。
至於要先做後端還是前端，我覺得是依照個人習慣，之前遇過一位前端工程師的朋友，他說他習慣先從前端開始做，這樣對於整個功能的操作流程與資料流，會比較有清楚的概念，我之前都是先從後端出發，也許下次可以先從前端試看看。
先規劃再執行
在任何功能實作前，我一定會要求 AI 先說明要改哪些檔案，具體會修改哪些內容，為什麼要這樣拆，我確認沒問題才讓它動手寫。這個流程的好處是大幅減少後期來回修改，並且讓我能快速掌握程式碼位置，在除錯時可以直接指定檔案與行為，最重要的是可以讓我學到很多我從來沒有用過的寫法，
至於我的 CLAUDE.md 是用 Cursor directory 上的 WordPress 範本 ，再根據開發時實際遇到的行為來進行補充：
- 前端檔案修改後，必須更新
wp_enqueue_script版本 - Log 一律使用
wc_get_logger，只記錄 error 層級 - 新功能前先檢查是否已有類似實作，禁止重寫
- 單檔超過 800 行，必須拆分
- 遵循 WPCS
- 類別名稱用 camelCase，方法一律用 snake_case
- PHP inline 註解結尾一定要有句點
- 註解一律使用繁體中文
AI 開發應用
使用 MCP 做測試，以及遠端網站的操作
我會搭配 Playwright MCP 或 Claude 內建瀏覽器檢查前端 UI，我會請 AI 在規劃功能時先寫好測試腳本，等到功能完成後，就可以使用這個測試腳本來操作瀏覽器進行測試，如果程式碼有重構的話，會再跑一次測試腳本，確保所有功能正常運行。
由於我都是在本機開發，操作資料庫的行為基本上都是使用 WP-CLI 進行相關作業，遠端的測試環境則是用 WordPress / WooCommerce / MySQL MCP，就能直接在我的 Claude Code 裡面操作遠端主機。
使用 Skills 把寫過的程式碼變成可重複使用的模組
以前每做一個新功能時我都要請 AI 整理文件然後清空上下文，接著做其他功能時 AI 要重新理解程式碼的結構，現在我改用 Skills 後，我先將規劃好的功能與範例程式碼全部放在同一個 Skill 資料夾，開發時直接跟 AI 提及這個 Skills，它就能快速理解所需的知識。
開發完成後，再請 AI 把成果補回 Skill 裡。下次做類似功能可以直接套用省非常多時間，也不會發生已經處理過相關類似的功能，它又再重新寫一個全新的類別增加冗餘。
把重複流程，直接變成 Commands
當初我在開發 OrderChatz 這款外掛的時候，並沒有考慮到多語系，所以事後要再補上的話還蠻瑣碎的，於是我先請 AI 使用 WP-CLI 的指令來翻譯多語系，確認效果以及速度都可以後，我就請他幫我包裝成 Commands。這個 Commands 會自動：
- 取得 text domain
- 檢查缺少的 i18n 字串並翻成英文
- 讓使用者選擇目標語言
- 使用 WP-CLI 編譯語系檔
- 套用台灣正體中文在地化風格
使用方式：
/wp-i18n 檔案1.php 檔案2.php附上完整指令：
https://gist.github.com/oberonlai/ab4784f2c719c826dbdfa0f17d8bc992
心得
用 AI 寫 WordPress 外掛真的是超快的，是我以前開發速度的 10 倍，但是後續的除錯以及功能新增修改，似乎又回到了原本以前自己手刻時候的狀況，為了解決這個問題，遵循著「先規劃、再執行」的流程就會好很多。
所以也不是因為有了 AI 就再也不用學習程式，看得懂程式碼、甚至可以自己做一些快速的修改，有時候反而還會比較省事，而這也是為何有了 AI 之後我還是不敢碰自己不熟悉的程式語言。有了這樣的認知，AI 才會真正成為加速器，而不是技術債製造機。
如果你也在用 AI 開發 WordPress，很歡迎交流你目前遇到的難關與解法喔～
