用 AI 開發 WordPress 外掛的實戰心得
用 AI 開發 WordPress 外掛和開發其他產品很不一樣。AI 預設會用 React 搭配 Tailwind CSS 設計前端、資料庫使用 Supabase 等第三方服務。但對於擁有成熟後台管理系統的 WordPress 來說，這些預設選擇反而是最大的變數。
AI 開發 WordPress 的三大挑戰
1. AI 很難理解 WordPress 的開發哲學
WordPress 已發展超過 20 年，它有獨特的開發邏輯與大量依賴慣例。技術文件隨版本演進，舊寫法與新寫法並存，AI 不一定能掌握最新最正確的開發方式。這在開發區塊（Block）時最為明顯。
2. 外掛架構與 PHP 寫法影響可維護性
實際踩雷集中在三個層面：外掛整體架構設計不合理、PHP 寫法不符合 WordPress 程式碼規範、資料結構與職責劃分混亂。這些問題在初期寫功能時看不出來，到了測試與擴充階段，時間成本直接爆炸。即使再三強調遵循規範，AI 仍容易寫出超過一千行的檔案。
3. 外掛之間的衝突 AI 幾乎無法判斷
在 WordPress 世界裡，你的功能可能會跟其他外掛、主題甚至 Composer 套件產生衝突。像我們就遇過 Guzzle HTTP 在不同外掛間的版本衝突，請 AI 修正檢查了數十次、燒完好幾天的 Token，最後只能繞一大圈改用外部服務解決。
我們的 AI 開發原則
根據專案選擇工具
自用小工具採用 Cursor 或 Antigravity 進行直覺式開發，不在意程式碼細節，能運作就好。產品或客戶專案採用 PhpStorm 搭配 Claude Code——PhpStorm 是完整開發環境，內建程式碼自動修正、重構、品質檢查，對 WordPress 支援度極佳，可直接點擊 Hook 名稱查看定義位置。Claude Code 使用 MAX 方案，搭配多個終端機分頁同時執行任務。
後端先行：從資料結構開始
核心原則是先設計資料結構。先在 ChatGPT 或 Gemini 討論功能流程，從中拆解所需欄位，確認後依序實作：
- 設計資料庫版本升級策略
- 建立單一職責的資料表 CRUD 類別（先規劃 → 確認 → 再實作）
- 建立 API 或 Ajax 專用類別，強制使用 CRUD 類別
- 實際執行驗證資料操作正確性
前端開發策略
前端使用假資料先確保操作流程與顯示正確，再整合後端 API。區塊開發方面，先研讀 WordPress 官方區塊文件，準備好 Skill 再給 AI 參考。最重要的是——永遠先規劃再實作，別讓 AI 自由發揮。
這套方法論經過一整年的實戰驗證，讓我們在 AI 輔助開發的浪潮中，維持了程式碼的品質與可維護性。