內容目錄
前言：AI 編碼不是「一句 Prompt 就完成」
用 Claude Code、Codex、Cursor、Gemini CLI 或其他 AI Coding Agent 來開發
一開始看起來很神奇：
輸入需求，AI 產生程式碼；
丟進錯誤訊息，AI 幫忙修 Bug；
給它一個功能描述，它甚至可以幫你改好整個模組。
但實際進入專案後，問題也很快浮現：
AI 寫出來的程式碼不一定符合需求。
AI 常常講太多，卻沒有抓到專案真正的語言。
AI 產出的程式碼看起來合理，但跑不起來。
AI 加速了開發，也同時加速了技術債。
這正是 Matt Pocock 開源 skills 專案想解決的問題。
Matt Pocock 在官方 GitHub 專案中寫下這句話：
Skills for Real Engineers. Straight from my .claude directory.
這句話很關鍵。
它不是在說「給 AI 更多 Prompt」。
而是在說：把真實工程師每天會做的判斷、流程、檢查與紀律，包裝成可重複使用的 Skill，讓 AI Agent 不是單純寫程式，而是按照工程流程做事。
什麼是 Matt Pocock Skills？
Matt Pocock 的 skills 是一組為 AI Coding Agent 設計的工作流指令集。
它可以安裝到支援 Skill 機制的 AI 編碼工具中，例如 Claude Code 或其他類似 Agent 工具，讓 AI 在不同任務中使用特定工作流。
官方快速安裝方式如下：
npx skills@latest add mattpocock/skills
安裝後，使用者可以選擇需要的 Skills，並在 Agent 中執行：
/setup-matt-pocock-skills
這個設定流程會詢問：
- 你使用哪一種 Issue Tracker，例如 GitHub、Linear 或本地檔案
- 你的需求或任務如何標籤化
- 文件與決策紀錄要存放在哪裡
- Agent 之後要如何理解你的專案上下文
也就是說，這套工具不是讓 AI 直接「衝去寫程式」，而是先建立專案語言、工作流與交付紀律。
核心概念：不要 Vibe Coding，要工程化 AI Coding
很多人使用 AI 寫程式時，採用的是 Vibe Coding 模式。
所謂 Vibe Coding，大概就是：
我有一個想法 → 丟給 AI → 讓 AI 自己改 → 看起來可以就合併
這種方式在 Demo、原型、小工具上很快。
但放到真實產品，就容易遇到幾個問題：
- 需求沒有講清楚，AI 直接做錯方向
- 程式碼越改越亂，沒有人負責架構
- 沒有測試，AI 不知道自己是否改壞東西
- 對話太長，Agent 開始忘記前面的脈絡
- 任務太大，AI 一次修改太多地方
- Review 負擔轉移給人類，結果工程師更累
Matt Pocock 的 Skills 工作流，本質上是在提醒開發者：
AI 編碼不是取代軟體工程，而是更需要軟體工程。
AI 編碼痛點一：Agent 沒有真正理解需求
問題
AI Coding 最常見的失敗，不是語法錯誤，而是「它做的不是你要的」。
你可能請 AI 做一個後台報表頁面。
AI 可能很快生成 UI、API、資料表與測試。
但等你看完結果才發現：
- 欄位不是老師真正需要看的欄位
- 查詢條件不符合業務流程
- 權限設計漏掉角色差異
- 空狀態、錯誤狀態、邊界案例沒有處理
- 它理解的「報表」跟你理解的完全不同
這不是 AI 不聰明，而是需求沒有對齊。
對應 Skill：/grill-me 與 /grill-with-docs
Matt Pocock 的解法是：
在寫程式前，先讓 AI 反問你。
/grill-me 的精神是讓 Agent 不急著產出方案，而是先進行一輪深入訪談。
它會逼你釐清目標、限制、使用者情境、輸入輸出、例外狀況與成功標準。
/grill-with-docs 則更進一步。
它不只問問題，還會協助建立專案文件，例如：
- 專案上下文
- 領域用語
- 架構決策紀錄
- 需求背後的取捨
- 模組與資料流說明
這讓 AI 不是只靠當前聊天室的上下文做判斷，而是能逐步累積專案知識。
實務建議
在真實專案中，不要一開始就叫 AI：
幫我做一個學生作業批改頁面
更好的做法是先執行需求釐清：
/grill-with-docs
然後讓 AI 問你：
- 主要使用者是誰？
- 他最想完成什麼？
- 哪些步驟不能捲動？
- 成功送出前需要哪些驗證？
- 什麼情況下不能開始批改？
- 結果要如何呈現？
- 這個頁面未來會不會支援批次上傳？
等這些問題釐清後，再讓 AI 產出 PRD、Issue 或程式碼。
這樣做看起來比較慢，但通常可以避免後面大規模重工。
AI 編碼痛點二：Agent 太囉嗦，專案語言不一致
問題
AI 很常「講得很多，但不精準」。
在一個真實產品中，團隊內部通常會有自己的領域語言。
例如教育產品裡可能有：
- 模板
- 答案卷
- 評分規準
- 批改結果
- 班級
- 學生作業
- 題目配分
- AI 批改任務
如果 AI 沒有掌握這些詞，它就會用很長的描述代替一個簡短的專案術語。
長期下來會造成幾個問題：
- 變數命名不一致
- 文件描述不一致
- Agent 每次都重新解釋一次
- Token 消耗增加
- 新功能接不上既有架構
- 不同 Session 產出的程式碼風格不一致
對應 Skill：共享語言與 CONTEXT.md
Matt Pocock 的 Skills 強調建立 Shared Language，也就是共享語言。
共享語言的概念很接近領域驅動設計，也就是讓工程師、產品人員、領域專家與 AI Agent 使用同一套詞彙。
在 Skills 工作流中，這些資訊可以被整理進 CONTEXT.md 或 ADR 文件中。
例如原本 AI 可能會寫：
當老師上傳某個學生的作業圖片後，系統會根據題目和答案資訊產生評分結果。
但如果專案已經定義好術語，它就可以更精準地寫成：
Grade Job 會根據 Submission 與 Answer Key 產生 Grading Result。
這樣不只是文字變短，而是整個專案開始有穩定的語言系統。
實務建議
導入 Skills 時，建議先建立一份 CONTEXT.md，內容包含：
# Project Context ## Domain Terms - Submission：學生上傳的單份作業 - Template：批改模板，包含題目結構與答案格式 - Answer Key：標準答案與配分 - Grade Job：一次 AI 批改任務 - Grading Result：批改完成後產生的分數、評語與錯誤分析 ## Product Principles - 教師應能在不捲動頁面的情況下完成單份作業批改 - 主按鈕只用於最重要的批改行為 - 介面應避免學生向玩具風，保持教師專業感
這份文件不是給人看的而已，也是給 AI Agent 看的。
當 AI 有了穩定的詞彙，它就比較不容易每次都重新發明一套命名方式。
AI 編碼痛點三：程式碼看起來對，但實際不能用
問題
AI 產生的程式碼常常有一種錯覺：
看起來很完整，但一跑就壞。
常見情況包括：
- TypeScript 型別通不過
- API 欄位名稱對不上
- 資料庫 Schema 沒同步
- 測試沒有涵蓋邊界情境
- UI 看似完成，但實際操作失敗
- 修一個 Bug 又打壞另一個功能
這是因為 AI 如果沒有回饋迴路，就像閉著眼睛寫程式。
它需要知道：
- 型別檢查是否通過
- 測試是否通過
- 瀏覽器畫面是否正常
- CLI 指令是否成功
- 錯誤訊息是什麼
- 哪個 Commit 造成回歸
對應 Skill：/tdd 與 /diagnosing-bugs
Matt Pocock 的解法是把測試與診斷流程變成 Skill。
/tdd 強調 Red-Green-Refactor：
- Red：先寫一個失敗的測試
- Green：寫最小程式碼讓測試通過
- Refactor：在測試保護下重構
這讓 AI 不只是「寫出看起來合理的程式碼」，而是用測試證明功能真的成立。
/diagnosing-bugs 則適合處理 Bug。
它會要求 Agent 依照更有紀律的流程處理問題：
- 重現錯誤
- 最小化案例
- 提出假設
- 加入觀測與紀錄
- 修正問題
- 補上回歸測試
這比直接叫 AI「幫我修掉」穩定很多。
實務建議
當你要讓 AI 修改功能時，可以這樣要求：
使用 /tdd 幫我完成這個功能。 請先寫 failing test，再實作功能，最後重構。 不要一次修改太多檔案。
遇到 Bug 時可以改成：
使用 /diagnosing-bugs。 請先重現問題，不要直接猜測修法。 找到 root cause 後再提出修正方案。 最後補上 regression test。
這種方式會讓 AI 的輸出慢一點，但品質通常更好。
AI 編碼痛點四：系統越做越像一團泥球
問題
AI 最大的優點是寫得快。
但它最大的風險也是寫得太快。
如果沒有架構約束，AI 會快速產生：
- 過大的 Component
- 混亂的資料流
- 重複的工具函式
- 不一致的命名
- 隱性耦合
- 到處散落的商業邏輯
- 難以測試的模組
最後專案會變成 Ball of Mud，也就是一團泥球。
功能看起來都有，但每次修改都很痛苦。
對應 Skill：/improve-codebase-architecture 與 codebase-design
Matt Pocock 的 Skills 裡面不只關心「功能做出來」，也關心「系統是否還能長期演進」。
/improve-codebase-architecture 的用途是掃描程式碼庫，找出架構可以改善的地方。
它不是單純叫 AI 重構，而是先分析：
- 哪些模組太淺
- 哪些抽象不夠穩定
- 哪些介面太大
- 哪些責任混在一起
- 哪些地方不容易測試
- 哪些功能應該被拆成更深的模組
codebase-design 則提供一套讓 AI 判斷模組設計的語言。
核心精神是：好的模組應該把複雜行為包在簡單介面後面。
這對 AI Coding 非常重要。
因為 AI 很容易局部最佳化，卻忽略整體設計。
實務建議
如果你的 AI Agent 已經連續幫你開發好幾天，建議定期執行：
/improve-codebase-architecture
可以設定成每幾天做一次架構健檢，尤其是在以下情境：
- 新功能大量加入後
- 多個 Agent 平行開發後
- 頁面開始變得難維護
- 測試越來越難寫
- 開發者開始不確定邏輯應該放哪裡
- 同一種資料轉換出現在很多檔案中
AI 不只應該幫你加功能，也應該幫你守住系統結構。
一張圖看懂 Matt Pocock Skills 工作流
可以把這套流程想成四個階段：
這個流程的重點不是工具本身，而是節奏。
AI 不應該一次吃下整個專案。
AI 應該在明確上下文、明確任務、明確驗證方式下工作。
WordPress 技術文章可用的導入範例
如果你要把這套工作流放進 WordPress 技術團隊或個人開發流程，可以這樣設計：
1. 建立專案上下文
在專案根目錄建立：
CONTEXT.md
內容包含：
- 專案目標
- 使用者角色
- 核心流程
- 領域名詞
- 技術堆疊
- 不可違反的設計原則
- 重要資料表
- API 命名規則
- UI 風格規範
2. 每個功能先做需求釐清
不要直接要求 AI 實作。
先使用：
/grill-with-docs
讓 AI 問清楚需求。
3. 把需求轉成 PRD
需求清楚後，再使用：
/to-prd
讓 AI 產出產品需求文件。
4. 拆成 Issues
接著使用：
/to-issues
把 PRD 拆成可獨立完成的小任務。
每個 Issue 最好具備：
- 明確輸入
- 明確輸出
- 明確驗收標準
- 可測試範圍
- 不超過一個主要模組
5. 實作時使用 TDD
每個 Issue 開始實作時，使用：
/tdd
讓 AI 先寫測試，再寫功能。
6. 定期做架構整理
每完成幾個 Issue，執行：
/improve-codebase-architecture
把 AI 快速產生的程式碼重新拉回可維護狀態。
什麼專案最適合使用 Matt Pocock Skills？
這套 Skills 特別適合以下情境：
- 你正在開發真實產品，不只是 Demo
- 你使用 Claude Code、Codex 或其他 Agent 工具
- 你希望 AI 參與需求、測試、架構與文件
- 你的專案有複雜商業邏輯
- 你需要多人協作
- 你不希望 AI 把程式碼改成不可維護
- 你希望建立可重複使用的 AI 開發流程
例如：
- SaaS 後台
- 教育科技平台
- 金融分析工具
- 電商系統
- 內部管理平台
- WordPress 外掛
- API 服務
- 多 Agent 開發流程
如果只是一次性的簡單腳本，這套流程可能會顯得偏重。
但只要專案會長期維護，它的價值就會越來越明顯。
常用 Skills 整理
/setup-matt-pocock-skills
第一次導入時使用。
用來設定 Issue Tracker、標籤、文件位置與專案工作流。
/grill-me
讓 AI 針對你的想法進行深入提問。
適合非程式碼需求、產品想法、設計方向。
/grill-with-docs
進階版需求釐清。
除了問問題，也會協助建立上下文文件與架構決策紀錄。
/to-prd
把目前對話整理成 PRD。
適合在需求已經大致釐清後使用。
/to-issues
把 PRD、計畫或規格拆成可執行的 Issues。
重點是拆成垂直切片，而不是技術分工清單。
/tdd
用測試驅動開發方式完成任務。
適合功能開發與 Bug 修復。
/diagnosing-bugs
用紀律化方式診斷 Bug。
適合複雜錯誤、效能問題與回歸問題。
/improve-codebase-architecture
掃描程式碼庫並提出架構改善方向。
適合定期做技術債整理。
git-guardrails-claude-code
設定 Git 安全防護，避免 Agent 執行危險 Git 指令。
例如阻擋 reset --hard、clean 或不該執行的 push 行為。
為什麼這套方法值得關注？
Matt Pocock Skills 的重點，不是發明一個全新的 AI 工具。
它真正有價值的地方，是把「工程師本來就該做的事」變成 AI 可以遵循的工作流。
它提醒我們：
AI 不缺寫程式碼的能力。
AI 缺的是上下文、回饋、邊界、命名、架構與驗證。
而這些東西，正是軟體工程的核心。
如果你只把 AI 當成程式碼產生器，它很快會帶來混亂。
如果你把 AI 當成需要被管理、被引導、被驗證的工程協作者，它就能變成很強的開發加速器。
AI Coding 的下一步，是工作流工程化
AI 編碼正在從「Prompt 技巧」進入「工作流設計」。
早期大家在比較誰的 Prompt 寫得好。
現在真正重要的是：
- 有沒有清楚的需求釐清流程
- 有沒有穩定的專案上下文
- 有沒有測試回饋
- 有沒有架構守門
- 有沒有 Issue 拆解
- 有沒有安全邊界
- 有沒有讓人類重新介入審查的節點
Matt Pocock 的 Skills 專案，正好提供了一個很好的起點。
它不是叫你把專案完全交給 AI。
它是讓 AI 回到工程流程裡，成為一個更可控、更可靠、更能被驗證的協作者。
如果你已經開始使用 Claude Code、Codex 或其他 AI Coding Agent，這套 Skills 很值得安裝到你的專案裡試試看。
官方 GitHub：
https://github.com/mattpocock/skills
下載 Skills：
https://github.com/mattpocock/skills/archive/refs/heads/main.zip
快速安裝：
npx skills@latest add mattpocock/skills
建議第一批先選這 8 個
在安裝的畫面裡，先用空白鍵勾選這些：
setup-matt-pocock-skillsgrill-with-docsto-prdto-issuestdddiagnosing-bugsimprove-codebase-architecturecodebase-design
這 8 個是最適合「真實專案開發」的主流程。
為什麼先選這些？
1. setup-matt-pocock-skills
第一次一定要選。
這是初始化 Matt Pocock Skills 工作流用的，會幫你建立專案設定、issue tracker、文件位置等基本配置。
2. grill-with-docs
用來讓 AI 先問清楚需求，不要一開始就亂寫 code。
很適合你現在的 AI Grader、WordPress、SaaS、工具頁面開發。
3. to-prd
把討論內容整理成 PRD。
適合把「想法」轉成產品需求文件。
4. to-issues
把 PRD 拆成一個一個可執行的 issue。
這很重要，因為 AI 最怕一次任務太大。
5. tdd
用測試驅動開發方式實作。
讓 AI 先寫測試，再寫功能，比較不容易寫出看起來對、實際不能跑的程式碼。
6. diagnosing-bugs
Debug 專用。
遇到錯誤時，不要讓 AI 直接亂猜修法，而是要求它先重現、分析、找 root cause。
7. improve-codebase-architecture
定期檢查專案架構。
AI 寫久了很容易讓專案變成一團泥球，這個 skill 用來做架構整理。
8. codebase-design
用來建立或檢查程式碼設計原則。
適合你要讓 AI 理解「這個專案的架構應該怎麼長」。
第二批可以考慮加裝
等你開始穩定使用後，再加這些：
grill-metriageprototypereviewimplementgit-guardrails-claude-codesetup-pre-commitrequest-refactor-plan
用途如下：
| Skill | 適合情境 |
|---|---|
grill-me | 還沒有文件，只是想法階段，讓 AI 先問你問題 |
triage | 分析 bug、issue、需求優先級 |
prototype | 快速做原型 |
review | 請 AI 做 code review |
implement | 根據 issue 實作功能 |
git-guardrails-claude-code | 防止 Claude Code 亂下危險 git 指令 |
setup-pre-commit | 設定 pre-commit hooks |
request-refactor-plan | 先產生重構計畫，不直接動手改 |
其中我特別建議你後面一定要補：
git-guardrails-claude-codereviewimplementsetup-pre-commit
因為你會讓 AI 寫真實專案，Git 安全與 review 很重要。
暫時不用選的
這些可以先跳過：
ask-mattteachhandoffdomain-modelingdecision-mappingdesign-an-interfaceedit-articleobsidian-vaultscaffold-exerciseswriting-beatswriting-fragmentswriting-shape
不是不好，而是它們比較偏教學、寫作、知識整理或特殊用途。
你現在如果目標是 AI Grader / WordPress / SaaS / Claude Code 開發流程，先不用裝那麼多。
實戰開發組合的選法
可以先這樣選：
[x] setup-matt-pocock-skills[x] grill-with-docs[x] to-prd[x] to-issues[x] tdd[x] diagnosing-bugs[x] improve-codebase-architecture[x] codebase-design[x] git-guardrails-claude-code[x] review[x] implement[x] setup-pre-commit
近期留言