用 Claude Code 設計 AI 程式碼審查機制：以 Payload CMS 為例

編譯摘要

用 Claude Code 設計 AI 程式碼審查機制：以 Payload CMS 為例 — 編譯摘要

濃縮

核心結論：

  1. AI 寫程式碼的盲區在於「框架特有的注意事項」——AI 能讓功能跑起來，但不一定遵守框架的安全性、效能和資料庫變更最佳實踐。
  2. Claude Code 的 Command / Agent / Skill 三層架構應按「知識和流程的更新頻率」分開——Skill 存知識（會隨框架版本更新），Agent 定義流程（基本不變），Command 是入口。
  3. 噪音過濾是審查報告可用性的關鍵——只報告信心度 > 80% 的問題，同類問題合併，否則開發者會忽略所有警告。

關鍵證據：

  • Payload CMS 三個風險維度：安全性（內部 API 預設不檢查權限）、效能（depth 關聯查詢）、資料庫變更（欄位改名 = 先刪後建，資料會消失）。
  • 五個指令拆分：日常 4 個（check/review/perf/migrate）+ 定期 1 個（audit）。
  • Skill 中每個檢查項目配「錯誤 → 正確」程式碼對照，光文字描述 AI 無法精準辨識。

質疑

結論 1：AI 不了解框架特有注意事項

  • 前提假設：框架的最佳實踐已寫在官方文件中。但新框架可能文件不完整，或最佳實踐還在社群摸索中。
  • 換技術棧：成熟框架（如 WordPress、Rails）的常見陷阱已被模型訓練資料覆蓋，AI 可能已經知道。
  • 反例：如果團隊的 Skill checklist 過時或有錯，反而會產生錯誤的信心。

結論 2：三層架構分離知識與流程

  • 前提假設：審查流程是通用且穩定的。但不同團隊可能需要不同的報告格式或審查步驟。
  • 邊界條件：如果 Skill 文件太大（> 1000 行），AI 可能無法完整載入或遺漏部分檢查項目。

結論 3：80% 信心度門檻

  • 前提假設：AI 能自我評估信心度。實際上 AI 的 calibration 可能不準確——可能對某些真正危險的問題信心度反而低。
  • 反例：「我不確定」的問題有時候恰恰是最危險的。

對標

  1. 航空業的 checklist 文化：飛行員的起飛前 checklist 按嚴重程度分級（critical / non-critical），與 Skill 的 CRITICAL / HIGH / MEDIUM / LOW 分級邏輯相同。
  2. 靜態分析工具（ESLint、SonarQube）：AI 審查可視為「框架特定的動態靜態分析」——靜態分析查語法規則，AI 審查查框架慣例。
  3. 醫療的臨床指引（Clinical Guidelines）：醫療指引也是知識（最佳實踐）與流程（診斷步驟）分離，知識隨研究更新，流程相對穩定。

關聯概念

  • [[Claude Code 三層架構]]
  • [[Claude Code Skill 系統]]
  • [[AI 程式碼審查]]
  • [[品質評分機制]]