別再讓 AI agent 直接寫程式了，拜託：Matt Pocock 的 Skills 主流程，把「對齊」放在實作之前
AI coding agent（Claude Code、Codex、Cursor 隨你挑）最常見的死法，不是「寫不出程式」——拜託，它們寫程式比你快多了——而是在錯誤的方向上效率爆表地寫完一坨沒人要的東西。Matt Pocock，TypeScript 社群的傳教士級人物，他那個 skills repo 已經膨脹到 16 萬顆星、750 萬次下載，終於肯拍一支官方教學。而整支影片的核心其實很殘忍：
用 AI skills 的重點從來不是收集一堆炫炮指令，而是建立一條「先對齊、再規格化、才實作」的主流程。
換句話說：大多數人跳過「對齊」直接開跑，等於把架構決策外包給一個只看了你的 codebase 五秒鐘的實習生。然後事後罵 AI 很笨。嗯，誰笨還不一定。
安裝只是起點，別在這裡就開始炫耀
安裝簡單到不行：npx skills@latest add mattpocock/skills（Vercel 的 skills.sh 安裝器），選一選 skills、支援的 agent、安裝範圍就結束了。但有兩個設計判斷值得你停下來想一下：
- 專案級 vs 全域安裝：團隊協作請乖乖用專案級——大家共用同一套 skill 集，可以一起維護；solo developer 愛裝哪裡裝哪裡，反正出事的也是你自己。
- 輕到不可思議的 context 負擔：跟那些塞滿系統提示、把你 context 吃到懷疑人生的 skill 套件不一樣，這 38 個 skills 總共只佔約 660 個 token。因為它們幾乎都是「使用者主動叫用」。看到沒有？不用你的時候就閉嘴，這才是好 skill 的美德。
裝完跑一次 setup-mattpocock-skills，設定三件事：issue tracker（GitHub、Jira、Linear，或像我這種窮人用的純 local markdown）、triage 標籤、domain 文件（context.md + ADR）。順帶一提 repo 內建 ask-matt skill——作者本人被做成了隨叫隨到的使用手冊，連「我該怎麼開始」都能問他。某種意義上挺令人羨慕的。
主流程：Grill → Spec → Tickets → Implement → Review
整個體系的主幹是一條線性工作流，每一環都精準踩在 agent 工作的痛點上。
1. Grill（拷問）：讓 AI 反過來面試你
grill-with-docs 是流程入口。你可以丟一個爛到不行的想法進去——影片中的原話大概就是「我想把內部工具砍一砍，只留公開功能」，就這樣，真的。skill 會反過來拷問你：自己探索 codebase、提出追問，直到你們達成 shared understanding 才放你走。而且它在 repo 內是有狀態的，學到的東西會寫進 context.md 和 ADR。
本質只有一句話：寫程式之前，先用對話解決所有開放性問題。 能用講的講清楚就用講的；非要跑起來才知道答案的，才動用 prototype。二十個拷問式提問，換來的是實作階段不用人肉盯梢——這筆帳怎麼算都划算。
2. To Spec：把討論壓縮成可驗證的終點
工作小到一個 session 做得完？直接 implement，別演了。但如果會跨多個 context window，先跑 to-spec——把整段討論濃縮成文件丟進 issue tracker。Spec 回答的是「我們到底要去哪裡」：問題陳述、解法、user stories、實作與測試決策。
3. To Tickets：把終點切成一塊塊「聰明區」大小的蛋糕
to-tickets 把 spec 拆成一張張 ticket，每張刻意設計成恰好一個 context window。Spec 描述目的地，tickets 描述路徑。兩者合起來，agent 在任何新 session 都擁有完成下一塊工作的全部資訊——不用靠什麼玄學記憶。
4. Implement：一票一清，紀律比熱情重要
實作節奏是紀律問題：做完一張 ticket 就清空 context，再看塞不塞得下下一張。Matt 分享了他的心智模型——模型在 context 超過約 140k tokens 後會明顯退化（注意力下降、開始幻覺），他把 140k 以內稱為「聰明區」（smart zone）。所有工作都安排在聰明區內完成。
聽到了嗎？連 16 萬星 repo 的作者都不敢賭模型的長文能力，而你還在期待 agent 讀完十萬字需求之後「記得就好」。
5. Code Review：剛寫完程式的 agent 是最爛的審查者
implement 收尾時自動觸發 code review，沿兩條軸檢查：逐條核對 spec 的驗收標準，以及對照 repo 自己的 coding standards（沒有的話退回 Martin Fowler 式經典原則找 code smell）。
關鍵細節：review 必須在子 agent 裡執行。為什麼？因為剛寫完程式碼的主 agent 幾乎總是覺得自己寫得棒透了——「OK 這很棒，沒問題。」跟你 code review 時那個只會說 LGTM 的同事一模一樣。只有乾淨 context 的審查者才看得見問題。
就算你不用他的 skills，這套邏輯也躲不掉
Matt 自己的總結樸素得很：「這就是我所有工作都跑的主流程。」其他 skills 都還在實驗、都在伺候這個迴圈。工具年年換，但「先對齊、再切塊、乾淨實作、獨立驗收」這副骨架——大概是 agentic coding 目前唯一站得住腳的工作方式。不服的話，歡迎繼續直接對 agent 說「幫我做個 X」，然後回來跟我哭。