用 AI 開發 WordPress 外掛的實戰心得

編譯摘要

用 AI 開發 WordPress 外掛的實戰心得 — 編譯摘要

濃縮

  1. AI 開發 WordPress 的三大挑戰：AI 難理解 WordPress 20 年累積的開發哲學與慣例、產出的 PHP 架構不符合規範導致維護成本爆炸、無法判斷外掛之間的衝突（如 Guzzle HTTP 版本衝突）。
  2. 後端先行的資料結構優先原則：先用 AI 聊天工具討論功能流程 → 拆解資料結構 → 依序實作 CRUD → API/Ajax → 前端，每一步都是「先規劃、確認、再實作」。
  3. 永遠先規劃再實作，別讓 AI 自由發揮：這是一整年實戰驗證的核心結論，特別在區塊開發上，需要先準備好 Skill 文件再給 AI 參考。

質疑

結論 1：AI 難理解 WordPress 開發哲學

  • 前提假設：WordPress 的慣例和規範是必須遵循的。但部分慣例已經過時（如直接操作全域變數），打破慣例有時反而更好。
  • 換技術棧：這個問題在所有歷史悠久的框架（Rails、Django、Spring）都存在，不是 WordPress 獨有。
  • 反例：隨著 AI 訓練資料的更新和微調，AI 對 WordPress 的理解會持續改善。

結論 2：後端先行

  • 前提假設：專案是功能導向的外掛開發。如果是以展示為主的前端專案（佈景主題），前端先行可能更合理。
  • 邊界條件：當需求還不明確時，先做前端原型讓利害關係人確認反而更高效。

結論 3：不讓 AI 自由發揮

  • 前提假設：開發者有足夠的領域知識來撰寫規劃和 Skill 文件。對於正在學習的新手，AI 的自由發揮反而是學習的途徑。
  • 反例：在探索性開發（如 hackathon）中，讓 AI 自由發揮可能產生意想不到的創新方案。

對標

  1. AI 不懂領域慣例 ↔ 新人入職：AI 就像一個技術能力強但不了解公司文化的新員工，需要透過 onboarding（Skill 文件）來校準。
  2. 後端先行 ↔ 資料庫正規化：資料結構決定一切的哲學，和資料庫設計的第三正規化原則一脈相承。
  3. 外掛衝突 ↔ npm 依賴地獄：WordPress 外掛衝突和 JavaScript 的 node_modules 依賴衝突是同構問題。

關聯概念

  • [[AI 開發 WordPress 挑戰]]
  • [[Spec Coding]]
  • [[規格先行開發]]
  • [[WordPress 生態系統]]
  • [[AI 工具選擇策略]]