從零寫一個 WordPress 專用 Skill：站台盤點自動化實作

接手一個別人做的 WordPress 站，最花時間的往往不是修東西，是搞清楚裡面到底有什麼。前一個廠商沒留文件，客戶只知道網站可以開，你得自己一項一項翻：裝了哪些外掛、主題有沒有被改過、PHP 版本多舊、有沒有人偷偷加了 cron、資料庫裡有沒有埋著什麼。這件事每接一個站就要重來一次，而且每次翻的順序都不太一樣，漏掉哪項通常要等到出事才知道。

這種「流程固定但每次對象不同」的工作，就是 Skill 最划算的應用。這篇我們把一個站台盤點 Skill 從空資料夾建到可以跑，包含最容易寫壞的 description、什麼該放進附屬檔案，以及測試的時候怎麼確認它真的被觸發了。

先決定它要交出什麼

寫 Skill 之前先想清楚輸出。這一步跳過的話，寫出來的東西通常會變成一份含糊的指示，跑十次有十種格式。

我們要的產出很具體：一份可以直接貼進交接文件的盤點報告，包含環境資訊、外掛清單與風險標記、主題是否被直接修改、排程任務、以及一份「接手後前三件該做的事」。定義好這個，SKILL.md 要寫什麼就清楚了。

建目錄

Claude Code 的 Skill 走檔案系統，放哪裡決定作用範圍。這個盤點 Skill 我們會在很多專案用到，所以放個人層級：

mkdir -p ~/.claude/skills/wp-site-audit/references
mkdir -p ~/.claude/skills/wp-site-audit/scripts
cd ~/.claude/skills/wp-site-audit

如果是只有這個專案要用的，改放 .claude/skills/，跟著 git 走，團隊 clone 下來就有。兩者的差異與各介面的分享範圍，Agent Skills 是什麼那篇有完整對照。

SKILL.md 的本體

這是主檔，內容是流程本身。注意 name 只能用小寫英文、數字與連字號，而且不能包含 claude 與 anthropic 這兩個保留字。

---
name: wp-site-audit
description: 盤點一個 WordPress 站台的環境、外掛、主題、排程與風險，產出可交接的報告。當使用者說要接手網站、盤點網站、看看這個站有什麼、檢查客戶的站、做交接文件時使用。
---

# WordPress 站台盤點

## 前置
確認能執行 wp-cli，且目前目錄是 WordPress 根目錄。不確定就先跑 wp core version 驗證。

## 盤點順序

1. 環境：WordPress 版本、PHP 版本、資料庫版本、記憶體上限
2. 外掛：列出全部外掛與啟用狀態，標出三類風險（見下方判斷）
3. 主題：確認啟用的主題，檢查是否為子主題，比對核心檔案有無被直接修改
4. 排程：列出所有 cron 事件，標出非預設的
5. 使用者：列出管理員層級帳號，標出最後登入超過半年的
6. 資料庫：檢查 wp_options 的 autoload 總量與最大的十筆

## 外掛風險判斷
- 高：兩年內無更新，或已從官方目錄下架
- 中：與目前 WordPress 版本相容性未經測試
- 低：其餘

判斷邏輯的細節與查詢方式見 references/plugin-risk.md。

## 輸出
用表格輸出前五項，最後給一段「接手後前三件該做的事」，按風險排序。
每個風險標記都要寫出判斷依據，不要只給結論。

## 界線
只做讀取。不要執行 wp plugin update、wp db、rm 或任何寫入指令。
發現問題就寫進報告，不要自己動手修。

description 是整份檔案裡最重要的一行

這句話值得單獨拉出來講，因為它是我們自己踩最多次的地方。Skill 沒有反應的時候，八成問題出在這裡。

判斷機制是拿使用者說的話去比對描述，所以描述裡必須出現使用者實際會講出口的說法，而不是你腦中的功能名稱。「執行 WordPress 站台的結構化盤點與風險評估」這種寫法看起來很專業，但沒有人會這樣講話，於是它永遠不會被觸發。

比較有效的寫法是把功能與觸發時機都塞進去，觸發時機那段直接寫白話：

寫的時候可以想像它在做關鍵字比對，把你和同事平常會怎麼開口講這件事寫進去，就不會寫得太文青。描述欄位上限是 1024 字元，空間很夠，不用省。

把細節挪到附屬檔案

外掛風險的判斷邏輯有點長，塞進主檔會把重點稀釋掉。這種「偶爾才需要查」的內容適合放到 references/：

cat > references/plugin-risk.md <<'EOF'
# 外掛風險判斷細則

## 查詢方式
wp plugin list --format=json --fields=name,status,version,update,update_version

## 高風險
- 最後更新距今超過 24 個月
- 已從 wordpress.org 外掛目錄移除
- 已知有未修補的 CVE

## 中風險
- 官方頁面標示未在目前 WordPress 版本測試過
- 超過 12 個月未更新

## 例外
自行開發或客製的外掛不套用更新頻率判斷，改為確認有無版控與交接文件。
EOF

這樣寫的好處是主檔保持精簡，而這份細則只有在真的要判斷外掛風險時才會被讀進去，沒用到就完全不佔成本。

把固定查詢寫成腳本

有些查詢每次都一樣，讓 AI 每次現場拼指令既慢又容易有出入。寫成腳本更穩，而且腳本的程式碼不會進到對話，只有輸出會：

cat > scripts/collect.sh <<'EOF'
#!/bin/bash
echo "== 環境"
wp core version
php -v | head -1
echo "== 外掛"
wp plugin list --format=csv --fields=name,status,version,update
echo "== 排程"
wp cron event list --format=csv --fields=hook,next_run_relative
echo "== autoload 總量"
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS mb FROM wp_options WHERE autoload='yes';"
EOF
chmod +x scripts/collect.sh

然後在 SKILL.md 裡指向它，讓流程直接呼叫。wp-cli 更完整的用法我們整理在WP-CLI 指令實戰大全。

測試：怎麼確認它真的被用到了

寫完重開 Claude Code 讓它掃到新目錄，然後用你平常會講的話去試，例如「幫我看看這個站裡面有什麼」。

重點是要確認它是「讀了你的 Skill」而不是「自己憑常識做了類似的事」。最簡單的驗證方式是在 SKILL.md 裡放一個只有你的流程才有的特徵，例如指定輸出最後那段叫「接手後前三件該做的事」。如果輸出裡出現這個標題，代表它確實讀到了；如果它給你一份格式漂亮但沒有這段的報告，那是它自己發揮的，Skill 根本沒被觸發。

沒被觸發的排查順序：先看 description 有沒有寫使用時機，再檢查 name 是否踩到保留字或用了大寫，最後確認目錄位置對不對。這三項排除掉之後就很少有其他原因了。

常見的三個問題

它跳過了某些步驟。通常是因為步驟寫得像建議而不像指令。把「可以檢查一下排程」改成「列出所有 cron 事件，標出非預設的」，並在流程開頭寫明「不要跳項，跳過的要說明原因」。

每次輸出格式都不一樣。輸出格式要寫死，包含用表格還是條列、欄位有哪些、風險等級怎麼標。含糊的地方它每次都會自由發揮。

它自己動手修了。這個要靠權限，不能只靠指示。SKILL.md 裡的界線是防呆，真正的防線是執行身分本來就沒有寫入權限。盤點這種工作用唯讀帳號跑就好。

做完之後

一個能用的盤點 Skill 大概二十行主檔加一份細則就夠了，真正花時間的是把你自己的判斷標準寫清楚。這也是它的價值所在：那些你接了十個站之後才累積出來的判斷，寫下來之後團隊裡每個人都拿得到，不用再各自踩一輪。

下一步可以往兩個方向走，一是把它加進版控讓團隊共用，二是針對特定客戶的站再寫一份客製的。維運面的延伸應用我們在WordPress 維運交給 AI 代理人那篇談過哪些能交、哪些不要。

這些做法我們實際用在客戶的站上，成品可以看作品案例，像立朋工業、集羽珠寶、辰羿起重這幾個都是 WordPress 做的，維運也一起接手。

如果你的團隊接案量已經大到每次交接都在重複同樣的盤點，想把這套流程標準化卻不確定從哪裡切，這正是我們AI 自動化開發實際在做的事。跟我們聊聊你們現在的交接流程。

延伸閱讀

• Claude Skills 是什麼？SKILL.md 寫法與使用時機
• WordPress 維運交給 AI 代理人：哪些能給哪些不要
• WP-CLI 指令實戰大全：部署、快取與更新
• 企業級 WordPress 開發完整指南