這陣子在網路上看到許多關於開發用的 Skills 非常方便，實際用過之後效果也還不錯，但覺得跟自己開發 WordPress 的習慣似乎還有一些差距，於是就在想，是不是可以自己重新設計一套開發流程，並整合不同的 AI 工具來進行使用。
回想自己開發的流程，會先從了解客戶的需求開始，整理出每一個主要的項目，然後將每一個功能的使用者故事（驗收標準）定義出來，再將使用者故事拆解成開發清單，如果是全新的外掛，我會先把初始化的環境配置好，包括：
- 建立外掛資料夾結構
- 標頭描述與定義常數
- Composer 自動載入
- 載入多語系檔與初始化類別
- 配置測試、靜態檢查工具等等
AI 時代前的開發流程
我習慣從後端的底層邏輯開始寫起。首先，我會建立這個功能所需要的資料欄位， 如果是要用 Custom Post Type 做，我會使用 ACF 新增 Post Type，並加入所需的欄位。如果該功能要處理的資料量很大且很重視效能，我會傾向自己設計資料表，並加入索引來最佳化查詢效能。
資料儲存結構設計完成後，我會設計一個類別來操作這些資料（像是新增、修改或刪除），這樣的做法好處是每次要查詢這些資料時，不用再重複寫 SQL 語句，只要使用一個方法就能快速取得。
如果是 ACF 也能透過方法的名稱立即知道我現在要取得的是什麼資料，不然欄位一多就要花時間想當初這個欄位是用什麼名稱命名，我會把相關欄位的取得包裝成一個方法，這樣之後要用一樣直接呼叫即可。
完成資料操作的類別後，接下來我會看客戶需求確認是否需要將這些資料的編輯提供給客戶自行操作，如果要的話，就會開始製作設定頁面。設定頁面有兩種類型：
- 全域設定：只要一個頁面就可以搞定，存放在 wp_options，像是 API Key
- 多筆資料的個別設定：像是每一筆資料的標題、描述以及自訂欄位
在全域設定的部分，還可以分為網站設定、特定外掛的全域設定（像是 WooCommerce），這部分就是要看客戶的需求，來確認要把這些設定功能放在哪些頁面。
多筆資料的設定如果是用 Post Type 搭配 ACF，WP 內建的介面就能解決，但如果是要用自訂資料表的話，就必須自行設計資料列表頁以及編輯頁，這部分通常會採用繼承 WP_List_Table 類別來處理，還有一種情境是要將設定欄位插入到既有外掛的資料編輯頁中（像是 WooCommerce 的商品設定）。
處理好資料的儲存後，接下來就是要設計業務邏輯，也就是要看在什麼情境下，要進行資料的新增或修改，有可能是透過以下方式：
- 透過前端的介面，搭配 AJAX 或是 Form 來進行操作，像是表單提交
- 透過外部的 API，當資料取得後，主動將結果寫進資料庫，像是金流串接回傳的交易結果
如果是透過前端的話，就開始設計所需的介面，這個介面有可能存在於給一般使用者操作的前台，或是僅限管理員操作的後台，然後前端在設計時，我都會先用假資料，確保在資料正確無誤的情況下，所有的操作流程以及資料顯示都有符合需求。
確認使用者介面操作無誤後，就會設計 AJAX 的專用類別，來提供前後端的資料串接橋樑，如果是僅限於網站內部使用的 AJAX，我會用 wp_ajax_{$action}，如果是提供給其他網域用的，像是前後端分離的架構，我就會註冊新的 REST API，最後再修改前端來整合後端資料。
如果是透過外部寫入資料，要先設計一個 API 的封裝類別，在類別中會有送出、取得以及寫入資料的方法，然後在適合的時機來觸發這一個類別進行資料的操作。以上開發完成後就能開始實際進行人工測試。
模組化 AI 工具
在梳理自己的工作流程之後，就能針對每一個工作項目設計對應的 AI 工具，這邊以 Claud Code 為範例，他提供了 Skill、Command、Rule、Agent 等工具，簡要說明如下：
- Skill – 封裝知識，只在有需要的時候觸發
- Command – 封裝提示詞，透過一個指令執行
- Rule – 每次 AI 回答時必須要遵循的規範
- Agent – 獨立的上下文環境，用於不同類型的任務
以往我的認知中，這每一個工具都有獨立的使用情境。直到我看到了 Everything Claude Code 這個專案，它把每一個工具進行了深度整合，並且透過 Command 作為使用者呼叫 AI 的入口，執行一個 Command 會先去呼叫 Agent，Agent 會再取得相關的 Skill，這樣就能更加明確讓 AI 知道要做哪些事。
這邊以建立自訂資料表為範例，我預期的流程大概是：
- 使用者執行 Command： /custom-table
- 使用者回答要建立這個自訂資料表所需要的相關資訊
- AI 根據 Rule 得知開發 WordPress 的基本規範
- AI 取得 WordPress 程式碼規範與安全效能的 Skill
- AI 取得 WordPress 建立自訂資料表的 Skill
- AI 完成開發
- 使用者執行 /test-generate 產生測試腳本
- 使用者執行 /verify 呼叫負責程式碼品質的 Agent 進行檢查
透過以上的流程來穩定每次 AI 的輸出，並搭配自動化工具來檢查程式碼品質。
Everything WP
有了這樣的情境後，我把開發每個 WordPress 外掛所需的相關功能都設計成獨立的 Command，包含開發設定頁、REST API、資料列表頁，以及前端的開發任務與 AJAX 串接等等，每個 Command 都有搭配的 Skill 來確保寫出的 WordPress 程式碼是符合安全與效能規範，並採用物件導向的開發原則。
另外還有檢查程式碼品質用的 Command，他們會呼叫 Agent 進行複雜的作業。例如：當測試沒過的時候，會自動去檢查測試腳本及原始碼，來排除測試錯誤的問題，這些測試所需要的工具可以透過執行 /init-plugin Command 就自動安裝完成。
最後，如果想要將外掛提交到 WordPress.org 上，我把官方的上架規範以及之前自己實際提交過兩次外掛時所得到的回覆修改內容，再搭配 Plugin Check 外掛的規則都整理在 Skills 裡面，只要透過 /submit-review 就能開始檢查，讓實際提交時盡可能一次搞定。
Everything WP 具體的使用步驟如下：
1. 複製儲存庫
首先先進入 Github 儲存庫網址：https://github.com/oberonlai/everything-wp
進入後可以看到四個資料夾，分別是 Agents、Commands、Rules、Skills，如果你清楚自己需要用到哪些指令，就將需要的工具複製到專案資料夾底下就好，我會建議 Rules 與 Skills 是必備的，Agents 與 Commands 則看個人需求，如果你不清楚的話就整包下載。
接下來，在你本機的 WordPress 環境中，開啟一個外掛資料夾根目錄，譬如 example-plugin，在這個目錄底下新增一個 .claude 的資料夾，如果使用的是其他 AI 工具，可以參考他們存放 Skills 的目錄路徑，像如果用 Cursor 的話就是 .cursor。
將以上複製的檔案全部貼外掛的根目錄後，這樣可以確保這些工具只有在該資料夾底下開發時才會觸發，如果你的工作是每天都在跟 WordPress 開發打交道，就可以把它貼到全域的路徑之中，這樣子就可以跨專案使用。
我自己最常用的開發工具是 Claude Code，並且搭配 Max 100 美元方案，這對於要開發實際的成品來說是非常夠用的，至於 Pro 方案的話就比較不堪用，因為要跑這些流程需要花費比較多的 Token 來進行回應。
2. 初始化外掛結構
用開發工具直接開啟該外掛資料夾並進入 Claude Code 之後，輸入 /init-plugin 就會自動執行外掛開發環境的設定，AI 會詢問外掛標頭的相關資訊、是否要安裝測試套件以及打包指令，這邊會建議都安裝，這樣在有需要時就不用額外處理。
回答完相關的資訊後，這邊給他一點時間跑一下，系統會自動進行處理 10 個任務，像是外掛基本資料結構的建立、多語系的載入、測試程式碼檢查工具是否安裝正確等等：
3. 進行開發
最後就可以開始運用以下指令來開發相關所需的功能，像是自訂資料表 /custom-table，輸入後就會自動詢問要建立欄位的相關資訊，甚至是哪些欄位需要進行索引，目前支援的功能有以下指令：
- /init-plugin – 初始化外掛開發環境，包含測試套件、GitHub Actions 與建置腳本
- /custom-table – 產生自訂資料表，並建立對應的 Repository 類別以處理 CRUD 操作
- /list-table – 產生用於後台資料顯示的 WP_List_Table 類別
- /option-page – 使用 Settings API 產生 WordPress 設定頁面
- /rest-api – 產生包含驗證與資料驗證機制的 REST API Controller
- /wp-ajax – 產生 AJAX 處理器，內建 nonce 驗證與權限檢查
- /api-wrapper – 產生外部 API Wrapper 類別，支援重試機制與記錄（logging）
- /frontend-page – 產生前端頁面
關於程式碼品質的部分，有以下指令可以使用：
- /verify – 執行所有程式碼品質檢查（PHPStan + PHPUnit + PHPCS）
- /test – 執行 PHPUnit 測試並分析失敗原因
- /test-generate – 為既有程式碼產生 PHPUnit 測試
- /analyse – 執行 PHPStan 靜態分析
- /lint – 執行 PHPCS 程式碼風格檢查（含自動修正）
- /submit-review – 檢查外掛是否符合 WordPress.org 上架審查規範
之後也會根據實務上遇到的狀況再進行調整。為了讓不懂程式開發的朋友也可以完整地利用這些指令，我預計會再另外設計一個 Command，讓 AI 在需求規劃的階段就直接針對工作事項套用適合的指令，讓 AI 可以自行呼叫這些指令來自動進行開發。
結論
感謝 Everything Claude Code 教會我如何搭配各種不同工具來設計完整的開發流程，結合自己多年開發的經驗，讓這些知識能夠落地成為開發組合技，但這專案只是開始，當遇到不同類型的需求時，想必又會有很多地方需要調整，但至少這是我認為在 AI 開發時代讓自己可以重新出發的一個機會。
你目前有設計自己的 AI 工作流嗎？歡迎大大分享一下吧！
