三個月 53k 星：Matt Pocock 這 17 個 skill，我拿一個真業務跑了一遍
整理版優先睇
用 Matt Pocock 嘅 17 個 skill 實戰優惠券需求，展示點樣將判斷力工具化，避免 AI 編程翻車
呢篇文章係作者分享佢點樣用 Matt Pocock 開源嘅 17 個 skill，拎一個真實嘅優惠券需求由頭到尾跑咗一次。作者本身喺度摸索 skill 嘅定義，踩過唔少坑，見到 Matt 嘅 repo 三個月 53k 星，就決定深入研究。Matt 係 Total TypeScript 作者，佢呢套 skill 針對 AI 編程最常見嘅「對唔齊」問題，每個 skill 都係一個具體嘅紀律工具。
作者讀完 17 個 skill 之後，按 4 個易錯環節重新組織：需求未諗清楚就開工、AI 寫一半就停、AI 一味附和、三個月後啲 code 變成一坨。然後用優惠券需求實戰，從裝機 setup-matt-pocock-skills，到 grill-with-docs 拷問需求，再到 to-prd 壓 PRD、to-issues 垂直切片、tdd 紅綠重構，中間遇到 bug 用 diagnose 強制復現同假設驗證，遇到代碼糾纏用 zoom-out 跳出問題，最後用 improve-codebase-architecture 做防腐。
整體結論係：AI 編程嘅樽頸唔係模型，而係缺乏紀律。Matt 呢套 skill 將「判斷」呢種抽象能力工具化，令工程師同 AI 都唔易跑偏。作者對比咗輕量派（Matt）同重流程框架（superpowers），指出兩者各有適用場景。最後強調，貴嘅係判斷，唔係 token；而判斷可以被 skill 化。
- 結論：AI 編程最大嘅問題係 AI 太順你，容易附和；Matt 嘅 skill 係一套紀律，將判斷工具化。
- 方法：用 grill-with-docs 拷問需求，將術語同決策寫入 CONTEXT.md 同 ADR，擋住後期返工。
- 差異：輕量派（信任工程師）vs 重框架（管理工程師），適用場景唔同；垂直切片（to-issues）比水平拆解更實用。
- 啟發：diagnose 強制復現同假設驗證，避免猜謎式除錯；刪除測試（improve-codebase-architecture）判斷模塊深度。
- 可行動點：個人項目可先試 grill-me 同 tdd；團隊協作需要 grill-with-docs 同 to-issues；建立 CONTEXT.md 同 ADR 係基本功。
Matt Pocock Skills 開源倉庫
mattpocock/skills，三個月 53k 星，包含 17 個 Claude Code skill。
刪除測試——判斷模塊深度
improve-codebase-architecture skill 中用嘅工具：問自己「如果刪掉呢塊 code，系統會點？」；冇事就係冗餘，要改一行就係淺模塊，成個崩就係深模塊。
AI 編程嘅「對唔齊」問題
作者自己搞咗一段時間 skill，成日諗 skill 係咩——比 prompt 複雜，比 agent 簡單，又唔似流程咁定型。佢用 Claude Code 踩過唔少坑，上週見到 Matt Pocock 開源咗佢 .claude 裡面嘅 17 個 skill，三個月 53k 星，就決定拎一個真實優惠券需求由頭到尾跑一次。Matt 係 Total TypeScript 作者，寫工程內容寫到被各路框架作者主動轉推。
最高頻失敗模式係 misalignment，對唔齊。
Matt 呢 17 個 skill 對住 AI 編程嘅易錯環節設計，按 4 個環節組織：需求未諗清楚、AI 寫一半就停、AI 一味附和、三個月後 code 變一坨。
- 1 需求未諗清楚就開工：grill-me 同 grill-with-docs 拷問需求，記錄決策。
- 2 AI 寫一半就停：to-prd、to-issues、triage 將需求拆成垂直切片。
- 3 AI 一味附和：diagnose 強制調試紀律，tdd 紅綠重構，zoom-out 跳出死衚衕。
- 4 三個月後 code 變一坨：improve-codebase-architecture 用刪除測試做防腐。
用 grill 同診斷紀律跑通優惠券
產品同學甩咗句「做個優惠券」，作者決定從頭到尾跟 Matt 套 skill 走。先跑 setup-matt-pocock-skills 裝機，兩分鐘搞掂，所有 skill 共享一份上下文。
grill-with-docs 問咗二十幾分鐘，問出四個關鍵分叉：滿減定百分比折扣、可唔可以疊加、軟刪除定硬刪除、優惠碼生成方式。
拷問完，CONTEXT.md 多咗三個新術語，docs/adr/0007-no-stacking.md 記錄點解唔允許疊加。呢一步無寫 code，但擋住後面 80% 返工。
- 1 Issue 1：運營喺後台創建一張滿減券（schema + API + 後台表單 + 測試）。
- 2 Issue 2：用戶喺結算頁選擇應用已領取嘅券。
- 3 Issue 3：用戶喺個人中心睇到已使用同未使用嘅券。
- 4 Issue 4：運營批量發券俾一個用戶羣。
每個 issue 都標記 HITL 或 AFK，交易鏈路相關嘅一律等作者點頭。跟住用 tdd 紅綠重構，強制唔準跳過紅，確保寫嘅 code 有測試做證據。
輕量定重框架——信任 vs 管理
Matt 嘅 grill-me 得 11 行 SKILL.md，superpowers 做 brainstorming 要 165 行，仲有 <HARD-GATE> 強制步驟。呢個差距背後係哲學差異：一邊信任工程師，一邊管理工程師。
護欄冇錯，但用錯場景就變成束縛。
- 維度：Matt 輕量派 vs 重流程框架（superpowers / BMAD）
- 門：冇 HARD-GATE，想跳就跳 vs 有，未出 spec 唔準寫 code
- 角色儀式：唔分角色 vs 入嚟先揀 PM / Architect / Dev
- 沉澱路徑：handoff 寫 OS 臨時目錄，唔污染 git vs spec 要 commit 入 git
- 配置層：docs/agents/ 一次配置多 skill 共享 vs 整套吞下，接受目錄結構
- 適合誰：已有項目語言嘅工程師 vs 仲未建立項目語言嘅團隊
作者自己之前都試過全套流程，後尾發現門檻太高冇人用，砍成獨立小工具反而得。早期模糊期用輕量派，多人協作用重框架，各有位置。
卡住時嘅兩種分流
實戰優惠券唔會一帆風順。作者至少卡咗兩次，兩次解法唔同。第一次係 Issue 2 結算頁折扣計錯，AI 試咗三種修法都錯。
diagnose 強制寫最小復現腳本，列五個可證偽假設，一次只改一個變量。第三個中咗：cache 冇失效。
diagnose 比起直接貼 log 畀 AI 睇，多咗嘅就係擋住 LLM 附和傾向。例子：作者直覺係字段名拼錯，真兇係緩存。仲有一個工程問題：要造穩定復現嘅反饋迴路，就得剝離出目標模塊，用 stub 替換依賴。
優惠券上線兩週後，作者跑 improve-codebase-architecture，用刪除測試發現優惠券校驗邏輯散喺三個地方，建議合併成 coupon_eligibility 深模塊，三個頁面各少 60 行 code。
貴嘅係判斷，唔係 token
Matt 呢 17 個 skill 就係做緊呢件事：將判斷從玄學變成一套可以反覆用嘅工具。Vibe coding 有佢嘅位，但你要寫一個會喺生產跑、會俾人接手、會俾半年後嘅自己維護嘅系統，就需要呢套紀律。
前排我喺度搞自己一套 skill，日日都諗：skill 呢樣嘢到底係啲乜。比 prompt 複雜，比 agent 簡單，又唔似流程咁定型。
我用 Claude Code 做嘢有一段時間啦，該踩嘅窿都踩過一次，都係未諗通呢件事。上個禮拜見到 Matt Pocock 將佢 .claude 目錄入面嘅 17 個 skill 全部開源咗，repo 叫 mattpocock/skills，三個月儲咗 53k 粒星。
我將 17 個 skill 逐個讀曬，再拎一個真實嘅優惠券需求由頭到尾行咗一次成個流程。
Matt 係 Total TypeScript 作者，React/TS 圈寫工程內容寫到被各路框架作者主動轉推嗰類人。佢嘅 README 第一句係「Skills for Real Engineers. Straight from my .claude directory.」乾淨俐落，冇廢話。
讀完呢 17 個，我有幾個判斷。
17 個 skill，按場景串一次
Matt 喺 README 提過，軟件開發最高頻嘅失敗模式係 misalignment，對唔齊。佢呢 17 個 skill 每一個都對住 AI 編程裏面一個容易走歪嘅環節，逐個擋住。
我將佢哋按 4 個易錯環節串埋一齊。
需求都未諗清楚就畀 AI 行
個腦入面有個模糊嘅想法，就掟畀 Claude Code。佢即刻開工，500 行代碼放喺你面前。你望住啲代碼先發現，要嘅唔係呢樣嘢。
但係你已經畀佢嘅方案帶住走咗。重新諗清楚自己想要乜，仲難過一開始就諗清楚。
Matt 為呢件事配咗兩把刀，叫 grill-me 和 grill-with-docs。
grill-me 字面意思就係將你擺上炭爐烤。佢唔會讚你，唔會順住你講，係咁追問你點解咁設計、邊界條件點算、如果用戶反過來用又點。問到決策樹每個分支都由你自己答返清楚為止。
grill-with-docs 係工程版本。拷問嘅同時將對齊結果寫入項目嘅兩份文檔：CONTEXT.md 裝術語表，docs/adr/ 裝架構決策記錄。
我用過幾次。第三輪問答之後，原本以為已經諗清楚嘅需求，會被佢問出至少兩個我從未諗過嘅盲點。
AI 平時太順你意，順到你以為自己諗清楚曬。
AI 寫到一半就停咗
需求諗清楚咗，下一關係點樣餵畀 AI。
好多人鍾意一次過畀一個大需求，例如叫 AI 幫自己做一個支援電郵登入、社交登入、雙因素認證嘅用戶系統。
AI 接到呢啲嘢有兩種死法。一種係由頭到尾鋪一層架，前端、後端、數據庫各鋪一層，行完成塊都冇真正用得。一種係揀一塊猛寫，剩低幾塊爛尾。
水平切片完成 75% 等於完成 0%。
呢句出自 Matt 嘅 to-issues skill。前端做咗後端未接，後端做咗數據庫未遷，任何一個都拎唔出街。
Matt 呢度串咗三個 skill。to-prd 將對齊嘅成個對話壓成一份 PRD 發到 issue tracker。to-issues 拎到 PRD 按垂直切片拆，每個 issue 端到端，前端後端數據庫測試全部行通，揀一個做完就可以 merge。triage 係分診：邊個先做、邊個應該閂咗佢。
三個 skill 擺埋一齊，由對齊到拆解嘅鏈路就閉環咗。
AI 只係喺度附和緊你
呢一關最易令人懷疑 AI 係咪有用。
測試炒咗，貼 error 畀 AI。AI 望一眼話可能係某個 field 冇 serialization，幫你改一段。再行又炒。你再貼，佢話可能係 cache 冇失效。改完行，又炒。
呢個係猜謎。AI 順住你嘅猜測接落去，你順住 AI 嘅猜測改落去，兩個人一齊向個窿度行。
diagnose 強制行一套調試紀律：先復現，再最小化，再形成假設，再加埋點驗證，最後先動手改，改完寫回歸測試。AI 平時 skip 咗嘅就係復現同最小化，佢會由你嘅描述跳到一句猜測。diagnose 物理上擋住呢種猜測。
呢個係我讀完成個 repo 最有共鳴嘅地方。AI 編程絕大多數炒車嘅根因，就係佢喺度附和。
另外兩個配套。tdd 行紅綠重構紀律，令 AI 永遠喺一個明確嘅目標下寫 code。zoom-out 係救火 skill，AI 卡死喺某段 code 入面出唔到嚟，叫佢退一步睇清楚自己喺系統嘅邊一層。
三個月後，啲 code 變成一 pat
每次單睇一個 AI 寫嘅功能都仲 ok。儲咗三個月之後，整個 codebase 變成一 pat：抽象層次混亂、模塊之間偷偷耦合、改一處扯到八處。Matt 喺 README 話，AI 加速咗編碼，亦加速咗軟件熵增。
improve-codebase-architecture 係為呢件事設計嘅。背後嘅哲學來自 John Ousterhout：好嘅模塊都係深嘅，細 interface、深 implementation。
Matt 喺呢個 skill 入面塞咗一個工具叫刪除測試。拎到一段 code，問自己一個問題：如果將呢忽成個 delete 咗，系統會點？
答案係乜事都冇，佢根本唔應該存在。
答案係 caller 要改一行，佢係一個淺模塊，抽象嘅價值仲不如直接 call。
答案係成個系統會冧，因為呢度封裝咗一 pat 複雜嘅嘢，呢個係深模塊，留低。
呢個判斷工具係我印象最深嘅部分。一句話擋住所有為咗抽象而抽象嘅 code。AI 寫 code 最常見嘅毛病就係過度抽象。
幾個唔分場景嘅 skill
handoff 解嘅係對話太長嘅問題。Claude Code 一個 session 開耐咗 context 會變得好腫。呢個 skill 將當前 session 壓成一份交接文檔，下一個 session 開起嚟讀呢份文檔繼續做。我以前係手動做嘅，存一份 上次聊到哪了.md，每次開 session 先 cat 一次。Matt 將佢工具化咗。
caveman 叫 AI 切換到穴居人模式講嘢，cut 曬啲客套嘢，慳 75% token。setup-matt-pocock-skills 係裝機用嘅，set 好 issue tracker、triage 標籤、文檔落點，所有 skill 共享呢份配置。
CONTEXT.md 同 ADR 比任何一個 skill 都重要
呢兩份文檔比任何一個 skill 都更根本。所有 skill 都喺度讀寫佢哋。
CONTEXT.md 係項目術語表。例如 user 指註冊賬號、account 指賬單實體，人腦會模糊處理，AI 唔得。佢冇記憶，你唔寫低佢每次都亂估。
docs/adr/ 係架構決策記錄。例如點解用 PostgreSQL 唔用 MySQL。呢啲決策嘅理由比決策本身更重要——新接手嘅 AI 睇唔到理由，就會成日想推翻決策。
配置點樣俾各個 skill 拎到？CLAUDE.md 充當一塊廣告牌。Claude Code 啟動時自動注入 CLAUDE.md，裏面有指向 docs/agents/ 嘅索引，各個 skill 按圖索驥去讀。倉庫特定嘅事實一定要放喺固定位置，等所有 skill 都可以按統一約定讀到。
AI 冇記憶。如果你信呢件事，成個工具鏈設計都會變。
11 行 vs 165 行：差嘅唔係篇幅
Matt 呢套 skill 都幾輕身。一個 SKILL.md 通常得十幾行。
上個禮拜我想諗通一件事：我手上一個小項目入面有個模塊到底要唔要拆出嚟獨立做。心入面得一個模糊嘅方向，想揾個人傾嚇。
我裝咗一個最近好紅嘅 superpower 框架。打開嚟，第一步：你要先用 brainstorming skill。佢彈出 9 項 TodoWrite，要先列問題陳述、要 propose 2-3 個 approach、要落到 docs/superpowers/specs/XXX-design.md、要 git commit、最後要轉交俾 writing-plans skill 行下一階段。
我望住呢 9 步睇咗一陣。
諗清楚呢件事本來 5 分鐘就夠。行完呢套流程半個鐘起步，仲多咗一份我根本唔需要嘅 spec 文件躺喺 git history 度。
我退返出嚟，開咗個空白對話框，問 Claude：你幫我諗嚇，呢個模塊要唔要拆，先問我一個問題就得。
傾咗 15 分鐘就諗清楚咗。
兩種哲學，兩個假設
Matt 嘅 grill-me，SKILL.md 加埋得 11 行。
superpowers 嘅 brainstorming，SKILL.md 加引用文檔接近 165 行。
第一個反應可能係 Matt 偷懶。睇完兩邊嘅內部就知，背後係哲學差異。
11 行寫嘅係：你要被訪問，AI 一次問你一個問題，每個問題畀你 2-3 個推薦答案，你隨時可以跳。完。冇強制步驟，冇規定輸出物。
165 行寫嘅係：第一步做乜、第二步做乜、第四步要 propose approaches、最終產物要落喺邊個目錄、要 commit、要轉交俾邊個 downstream skill。甚至有一個叫 <HARD-GATE> 嘅嘢，未出 spec 之前唔準鬱 code。
一邊係信任你，一邊係管理你。
護欄本身冇錯。某啲場景，護欄就係正確答案。但用錯咗場景，護欄就變成束縛。
Matt 假設用 skill 嘅係工程師，知道自己要乜。重框架假設用 skill 嘅人會亂咁走，所以提前整好路、裝好護欄。
沉澱路徑嗰條最有興趣。
同樣係記錄傾過啲乜，一種當成項目歷史嘅一部分，未來要可以追溯。一種當成兩個人頭先傾咗下，留個 memo，下次再傾。
應該用邊個，睇你而家卡喺邊
我自己之前整工具時，最早都想做全套，由需求收集到 code generation 到測試到部署，一條龍。
後來發現冇人用。老實講功能冇問題，門檻就嚇親人——用一次成本太高。
將佢 cut 成幾個獨立小工具，反而開始有人用。呢件事教精咗我：一個工具嘅價值唔在於佢做到幾多嘢，而在於對目標用戶嚟講摩擦有幾細。
返去 Matt 呢套同重流程框架嘅對比。
早期模糊期、個人項目，用輕量派。重框架嘅強制落檔會將探索推到一個具體方向太早，呢個時候你需要流動性。
多人協作、需要留檔、大型項目分階段，重框架嘅強制落檔反而係優勢。spec 要 commit 入 git，等後來加入嘅人可以追溯當初點解咁決策。呢種共同語言對一個人開發嘅項目意義唔大，但對一個 5 人團隊就係必需品。
一個人主力開發但希望將來可以移交，Matt 嗰個 grill-with-docs 係甜點區。喺 grill-me 流動性基礎上選擇性將決策落到 CONTEXT.md 同 ADR 度。
一個人寫 code 用重框架係大炮打蚊子，5 個人協作用 grill-me 係各自各講嘢。
兩邊都啱，用錯地方就兩邊都錯。
真係做一次：產品隨口講句「整個優惠券」
剩係講理論太虛。
前幾日產品同事拋咗一句過嚟：「我哋整個優惠券啦。」
如果係半年前，我大概會直接叫 CC 幫我寫 schema，再順手寫幾個 API。然後寫到一半發現滿減可唔可以疊加都未諗清楚，要推倒重來。
今次我決定由頭到尾跟 Matt 嗰套行。
裝機
跑一句 setup-matt-pocock-skills。佢問我三件事：issue 放邊、triage 標籤用乜、文檔落喺邊。我都用默認值。兩分鐘搞掂。
由呢刻開始，所有 skill 都有一份共同嘅 context 可以讀寫。AI 唔會再問 user 係乜意思呢類問題。
grill-with-docs 拷問需求
產品隨口講咗句「整個優惠券」.
以前嘅話我就開工啦。今次我先行 grill-with-docs。佢掃咗一次 CONTEXT.md 同 docs/adr/，然後開始問。
佢問咗大約廿幾分鐘。關鍵嘅幾個分叉係呢啲：
• 滿減定百分比折扣？兩個都要。 • 可唔可以疊加？唔允許。stacking rule 一旦放開，後期派券要計笛卡爾積。 • 領咗未用完係軟刪除定硬刪除？軟刪除。 • 批量派券撤回係全部撤定係只撤未使用？只撤未使用。 • 優惠碼係用戶領取時生成定預先生成？呢個我當場未諗清楚。
中間俾佢問到停咗落嚟諗咗三四次。
拷問完，CONTEXT.md 入面多咗三個新術語 coupon、redemption、stacking-rule。docs/adr/0007-no-stacking.md 入面多咗一條決策，記錄點解唔允許疊加。
呢一步表面睇冇寫任何 code，但係將後面 80% 嘅返工擋喺門口。你諗下，疊加呢件事如果寫到一半先發現未定，前後端訂單計算邏輯全部要重做。
to-prd 壓成 PRD
跑 to-prd。佢讀完前面嗰段對話，自動生成一份 PRD 提交做 GitHub issue。
中間佢問我一句關鍵嘅：呢次改動會鬱到邊啲模塊？
我列了 order、user、promotion、admin-panel。佢將呢個範圍寫入 PRD 頂部。由呢刻開始，後面所有 skill 都會睇實呢個範圍。一旦 AI 想去鬱 payment 模塊，佢會停低問你。
呢個 skill 產出嘅 PRD 嚴格按教科書定義嚟講係唔純嘅，裏面撈咗 implementation 同 testing decisions。教科書 PRD 應該只講 what 同 why，唔講 how。
但係單人加 AI 呢個場景下，呢種全景文檔對餵飽 Claude 嘅價值反而更大。AI 一次過食曬 context，比分三份文檔嚟回揾有效率好多。
只係命名上有啲問題，呢舊嘢喺多人協作嘅正規場合唔可以叫 PRD。私底下自己用，叫乜都得。
to-issues 拆垂直切片
PRD 到手，下一步係拆任務。
我以前嘅拆法係水平嘅：先將所有 schema 寫曬，再將所有 API 寫曬，再將所有 UI 寫曬。行咗 to-issues 先發現方向錯咗。
垂直拆法係咁樣：
• Issue 1：運營喺後台創建一張滿減券（schema + API + 後台表單 + 測試，端到端行得通） • Issue 2：用戶喺結算頁揀應用已領取嘅券 • Issue 3：用戶喺個人中心見到已使用同未使用嘅券 • Issue 4：運營批量派券畀一個用戶羣
每個切片都端到端，每個切片做完都可以畀產品演示。
to-issues 行完會主動問粒度、依賴、係咪合併、每個 issue 係 HITL（人介入審核）定 AFK（agent 自己行完）。交易鏈路相關嘅我都標 HITL，其餘標 AFK。
呢個標記決定後續 skill 嘅行為：AFK 嘅 issue 一口氣由測試寫到 code merge；HITL 嘅每個關鍵節點停低等我點頭。
tdd 紅綠重構
拎 Issue 2「用戶喺結算頁可以揀應用已領取嘅券」做例子。
AI 先寫一個測試：用戶有滿 100 減 20 嘅券落單 150，預期結算頁顯示 130。行一次，紅。
再寫最少嘅 code 令測試通過。注意係最少。佢唔會順手將百分比折扣都實現埋，就算佢知道跟住就要做。
最後重構，確認測試仲過。
關鍵紀律係唔準 skip 紅。失敗嘅測試係一個證據，證明呢個 bug 存在。冇呢個證據，你唔知你寫嘅 code 到底解決咗乜。
卡住時兩種分流
真係做起嚟一定會卡。優惠券呢個需求我至少卡咗兩次。兩次解法唔同。
測試過唔到，AI 俾嘅修復係估，唔係查。
Issue 2 跑到一半，結算頁死計唔啱折扣。AI 試咗三種改法，每種都係喺 controller 度加多一個 if 判斷，全部錯。
我跑了 diagnose。佢冇急住畀修復建議，先逼我寫一個最小復現 script：撳一次就穩定觸發 bug，唔依賴任何其他狀態。
寫完復現 script，AI 列咗五個可證偽假設：field 名串錯、serialization 漏咗、cache 冇失效、middleware 吞咗、ORM 關係冇建立。每次只改一個變量，行一次復現 script。
第三個中咗。配置 cache 冇失效，前端拎到嘅係舊嘅優惠券規則。
老實講，diagnose 相比直接貼 log 畀 AI 分析，多做咗嘅係擋住 LLM 嗰種附和傾向。貼 log，佢順住最顯眼嗰行畀你估。diagnose 迫你列 3-5 個假設、寫最小復現、一次只改一個變量、改完先寫回歸測試。
我直覺係 field 唔認得就肯定係 field 名串錯。真兇係 cache。呢種 bug 剩係睇症狀去估，可以估到天荒地老。
仲有一個工程問題。多服務環境下，點樣造一個可以穩定復現嘅反饋迴路？答案係剝離加替身，而唔係複製成個生產環境。
要測優惠券計算呢一段，將佢由訂單服務剝出嚟。依賴嘅用戶服務同促銷服務用 stub 代替，只保留要測嗰塊行真 code。一部機器上一秒觸發一次。
剝離係 diagnose 可以成立嘅前提。
AI 喺某個 file 度鑽牛角尖。
寫到優惠券同訂單嘅金額計算耦合嗰忽，AI 喺 order_service.rb 度改完又改，每次改完都引入新嘅邊界 bug。
我打咗一句：「I don't know this area of code well. Go up a layer of abstraction.」
這是 zoom-out 嘅觸發詞。AI 即刻跳出嚟，畫咗一張領域 context 圖，將 order、promotion、payment 三個模塊嘅關係用領域語言描咗一次。
然後畀咗我一句判斷：問題在 promotion 模塊冇曝露一個乾淨嘅 calculate_discount interface，order 喺度硬讀 promotion 嘅內部狀態。
跳出嚟一睇，問題在邊界，唔在 implementation。
improve-codebase-architecture 防腐
優惠券上線兩星期，我行咗一次 improve-codebase-architecture。
佢基於 CONTEXT.md 入面嘅 coupon、redemption、stacking-rule 呢啲詞去 codebase 度揾深模塊機會。
提咗一條：優惠券校驗邏輯散喺三個地方，商品詳情頁、結算頁、訂單確認頁。每個地方都重新行咗一次呢張券用得唔用得嘅判斷。建議合併成一個 coupon_eligibility 深模塊。
用刪除測試判斷深淺。假裝刪咗 coupon_eligibility，三個 call site 都要各自維護一套過期檢查、用戶資格檢查、商品適用檢查、互斥規則檢查。呢個係真深模塊。
合併完，三個頁面嘅相關 code 各少咗 60 行。
最後
讀完成套之後我諗咗好耐 Matt 嗰句 slogan：real engineering, not vibe coding。
Vibe coding 有自己嘅位置：快速試想法、做 prototype、玩。
但你要叫 AI 寫一個會喺 production 行、會俾人接手、會俾自己半年後返轉頭維護嘅系統，vibe 唔夠用。呢個時候需要嘅唔係更強嘅 model，而係一套令到人同 AI 都唔易走歪嘅紀律。
越用 AI 寫 code 我越覺得，貴嘅係判斷，唔係 token。係知道應該叫 AI 做啲乜、唔應該叫佢做啲乜。
判斷亦唔係一種心態，而係一系列具體動作：拷問需求、記錄決策、強制復現、刪除冗餘、定期審視架構。呢啲動作可以 skill 化。一旦工具化咗，判斷就由一種玄學變成一種可以重複用嘅工具。
Matt 呢 17 個 skill，做嘅就係呢件事。
前陣子我在折騰自己的一套 skill，每天都在想：skill 這個東西到底是什麼。比 prompt 複雜，比 agent 簡單，又不像流程那麼定型。
我用 Claude Code 工作有一段時間了，該踩的坑都踩過一遍，還是沒把這件事想透。上週看到 Matt Pocock 把他 .claude 目錄裏的 17 個 skill 全開源了，repo 叫 mattpocock/skills，三個月攢了 53k 星。
我把 17 個 skill 一個個讀完，又拿一個真實的優惠券需求把整套流程從頭跑了一遍。
Matt 是 Total TypeScript 作者，React/TS 圈寫工程內容寫到被各路框架作者主動轉推的那一類。他的 README 第一句話是「Skills for Real Engineers. Straight from my .claude directory.」乾淨，沒廢話。
讀完這 17 個，我有幾個判斷。
17 個 skill，按場景串一遍
Matt 在 README 裏說過，軟件開發最高頻的失敗模式是 misalignment，對不齊。他這 17 個 skill 每一個都對着 AI 編程裏一個容易跑偏的環節，一個個擋。
我把它們按 4 個易錯環節串起來。
需求都沒想清楚就讓 AI 跑了
腦子裏有個模糊的想法，甩給 Claude Code。它立刻開幹，500 行代碼擺面前。你看着代碼意識到，要的不是這個。
但你已經被它的方案帶着走了。重新想清楚自己要什麼，比一開始就想清楚還難。
Matt 給這件事配了兩把刀，叫 grill-me 和 grill-with-docs。
grill-me 字面意思就是把你架在火上烤。它不誇你，不順着你說，一直追問你為什麼這麼設計、邊界條件怎麼辦、如果用戶反過來用呢。問到決策樹每個分支都被你自己回答清楚為止。
grill-with-docs 是工程版本。拷問的同時把對齊結果寫進項目的兩份文檔：CONTEXT.md 裝術語表，docs/adr/ 裝架構決策記錄。
我用過幾次。第三輪問答之後，原本以為已經想清楚的需求，會被它問出至少兩個我從來沒想過的死角。
AI 平時太順着你了，順到你以為自己想清楚了。
AI 寫一半就停了
需求想清楚了，下一關是怎麼把它餵給 AI。
很多人喜歡一次性給一個大需求，比如讓 AI 幫自己做一個支持郵箱登錄、社交登錄、雙因素認證的用戶系統。
AI 接到這種活有兩種死法。一種是從前到後鋪一層架子，前端、後端、數據庫各鋪一層，跑完哪塊都沒真正能用。一種是挑一塊猛猛寫，剩下幾塊爛尾。
水平切片完成 75% 等於完成 0%。
這話出自 Matt 的 to-issues skill。前端做了後端沒接，後端做了數據庫沒遷，任何一個都不能交付。
Matt 這裏串了三個 skill。to-prd 把對齊的整個對話壓成一份 PRD 發到 issue tracker。to-issues 拿到 PRD 按垂直切片拆，每個 issue 端到端，前端後端數據庫測試全走通，挑一個幹完就能 merge。triage 是分診：哪個先做、哪個該關掉。
三個 skill 擺一起，從對齊到拆解的鏈路就閉上了。
AI 只是在附和你
這一關最容易讓人懷疑 AI 是不是有用。
測試掛了，貼報錯給 AI。AI 看一眼說可能是某個字段沒序列化，給你改一段。再跑還掛。你再貼，它說那可能是緩存沒失效。改完跑，又掛。
這是猜謎。AI 順着你的猜測往下接，你順着 AI 的猜測往下改，兩個人一起往坑裏走。
diagnose 強制走一套調試紀律：先復現，再最小化，再形成假設，再加埋點驗證，最後才動手改，改完寫回歸測試。AI 平時跳過的就是復現和最小化，它會從你的描述跳到一句猜測。diagnose 物理上擋住這種猜測。
這是我讀完整個 repo 最有共鳴的地方。AI 編程絕大多數翻車的根因，就是它在附和。
另外兩個配套。tdd 走紅綠重構紀律，讓 AI 永遠在一個明確的目標下寫代碼。zoom-out 是救火 skill，AI 卡在某段代碼裏出不來，叫它後退一步看清楚自己在系統的哪一層。
三個月後，代碼就變成一坨
每次單看一個 AI 寫的功能都還行。攢了三個月之後，整個代碼庫變成一坨：抽象層次混亂、模塊之間偷偷耦合、改一處牽動八處。Matt 在 README 裏說，AI 加速了編碼，也加速了軟件熵增。
improve-codebase-architecture 是為這件事設計的。它背後的哲學來自 John Ousterhout：好的模塊都是深的，小接口、深實現。
Matt 在這個 skill 裏塞了一個工具叫刪除測試。拿到一段代碼，問自己一個問題：如果把這塊整個刪掉，系統會怎樣？
答案是啥事沒有，它根本不該存在。
答案是調用方要改一行，它是個淺模塊，抽象的價值還不如直接調用。
答案是整個系統會崩，因為這裏封裝了一坨複雜的東西，這是個深模塊，留着。
這個判斷工具是我印象最深的部分。一句話擋住所有為了抽象而抽象的代碼。AI 寫代碼最常見的毛病就是過度抽象。
幾個不分場景的 skill
handoff 解的是對話太長的問題。Claude Code 一個會話開久了上下文會變臃腫。這個 skill 把當前會話壓成一份交接文檔，下一個會話開起來讀這份文檔接着幹。我以前是手動做的，存一份 上次聊到哪了.md，每次開會話先 cat 一遍。Matt 把它工具化了。
caveman 讓 AI 切換到穴居人模式說話，砍掉客套，省 75% token。setup-matt-pocock-skills 是裝機用的，配 issue tracker、triage 標籤、文檔落點，所有 skill 共享這份配置。
CONTEXT.md 和 ADR 比任何一個 skill 都重要
這兩份文檔比任何一個 skill 都更根本。所有 skill 都在讀寫它們。
CONTEXT.md 是項目術語表。比如 user 指註冊賬號、account 指賬單實體，人腦會模糊處理，AI 不行。它沒記憶，你不寫下來它每次都瞎猜。
docs/adr/ 是架構決策記錄。比如為什麼用 PostgreSQL 不用 MySQL。這些決策的理由比決策本身更重要——新接手的 AI 看不到理由，就會反覆想推翻決策。
配置怎麼被各個 skill 拿到？CLAUDE.md 充當一塊廣告牌。Claude Code 啓動時自動注入 CLAUDE.md，裏面有指向 docs/agents/ 的索引，各個 skill 按圖索驥去讀。倉庫特定的事實必須放在固定位置，讓所有 skill 都能按統一約定讀到。
AI 沒記憶。你要是信這件事，整個工具鏈設計都會變。
11 行 vs 165 行：差的不是篇幅
Matt 這套 skill 都挺輕的。一個 SKILL.md 經常就十幾行。
上週我想琢磨清楚一件事：我手上一個小項目裏有個模塊到底要不要拆出來單做。心裏就一個模糊的方向，想找個人聊一下。
我裝了一個最近很火的 superpower 框架。打開來，第一步：你要先用 brainstorming skill。它彈出 9 項 TodoWrite，要先列問題陳述、要 propose 2-3 個 approach、要落到 docs/superpowers/specs/XXX-design.md、要 git commit、最後要轉交給 writing-plans skill 走下一階段。
我盯着這 9 步看了一會。
想清楚這個事本來 5 分鐘夠。過完這套流程半小時起步，還多出來一份我並不需要的 spec 文件躺在 git 歷史裏。
我退出來，開了個空白對話框，問 Claude：你幫我想想，這個模塊要不要拆，先問我一個問題就好。
聊了 15 分鐘想清楚了。
兩種哲學，兩個假設
Matt 的 grill-me，SKILL.md 加起來 11 行。
superpowers 的 brainstorming，SKILL.md 加引用文檔接近 165 行。
第一反應可能是 Matt 偷懶。看完兩邊的內部就知道，這背後是哲學差異。
11 行寫的是：你要被採訪，AI 一次問你一個問題，每個問題給你 2-3 個推薦答案，你隨時可以跳。完了。沒有強制步驟，沒有規定輸出物。
165 行寫的是：第一步做什麼、第二步做什麼、第四步要 propose approaches、最終產物要落在哪個目錄、要 commit、要轉交給哪個下游 skill。它甚至有一個叫 <HARD-GATE> 的東西，沒出 spec 之前不準動代碼。
一邊在信任你，一邊在管理你。
護欄本身沒錯。某些場景，護欄就是正確答案。但用錯了場景，護欄就成了束縛。
Matt 假設用 skill 的人是工程師，知道自己要什麼。重框架假設用 skill 的人會亂跑，所以提前修好路、裝上護欄。
沉澱路徑那一條最有意思。
同樣是記錄聊了啥，一種當成項目歷史的一部分，未來要可追溯。一種當成倆人剛才嘮了下，備個忘，下次接着嘮。
該用哪個，看你現在卡在哪
我自己之前搭工具時，最早也想做全套，從需求收集到代碼生成到測試到部署，一條龍。
後來發現沒人用。說實話功能沒問題，門檻把人擋在外面了——用一次的成本太高。
把它砍成幾個獨立小工具，反而開始有人用了。這件事教育了我：一個工具的價值不取決於它能做多少事，取決於它對目標用戶來說摩擦有多小。
回到 Matt 這套和重流程框架的對比。
早期模糊期、個人項目，用輕量派。重框架的強制落檔會把探索往一個具體方向推得太早，這時候你需要流動性。
多人協作、需要留檔、大型項目分階段，重框架的強制落檔反而是優勢。spec 要 commit 進 git，讓後來加入的人能追溯當初為什麼這麼決策。這種共同語言對一個人開發的項目意義不大，對一個 5 人團隊卻是剛需。
一個人主開發但希望未來可移交，Matt 那個 grill-with-docs 是甜點區。在 grill-me 流動性基礎上選擇性把決策落到 CONTEXT.md 和 ADR 裏。
一個人寫代碼用重框架是大炮打蚊子，5 個人協作用 grill-me 是各說各話。
兩邊都對，用錯地方就兩邊都錯。
真做一遍：產品扔了句「做個優惠券」
光講理論太虛。
前幾天產品同學甩過來一句話：「我們做個優惠券吧。」
要是擱半年前，我大概會直接讓 CC 給我寫 schema，再順手寫幾個 API。然後寫到一半發現滿減能不能疊加都沒想清楚，推倒重來。
這次我決定從頭到尾按 Matt 那套走。
裝機
跑一句 setup-matt-pocock-skills。它問我三件事：issue 放哪、triage 標籤用什麼、文檔落到哪裏。我都用默認值。兩分鐘。
從這之後，所有 skill 都有一份共同的上下文可以讀寫。AI 不會再問 user 是什麼意思這種問題。
grill-with-docs 拷問需求
產品丟了一句「做個優惠券」。
換以前我就開幹了。這次我先跑 grill-with-docs。它掃了一遍 CONTEXT.md 和 docs/adr/，然後開始問。
它問了大概二十多分鐘。關鍵的幾個分叉是這些：
• 滿減還是百分比折扣？兩個都要。 • 能不能疊加？不允許。stacking rule 一旦放開，後期發券要算笛卡爾積。 • 領到沒用完是軟刪除還是硬刪除？軟刪除。 • 批量發券撤回是全撤還是隻撤未使用？只撤未使用。 • 優惠碼是用戶領取時生成還是預生成？這個我當場沒想清楚。
中間被問得停下來想了三四次。
拷問完，CONTEXT.md 裏多了三個新術語 coupon、redemption、stacking-rule。docs/adr/0007-no-stacking.md 裏多了一條決策，記錄為什麼不允許疊加。
這一步看起來什麼代碼都沒寫，但它把後面 80% 的返工擋在了門口。你想一下，疊加這件事要是寫到一半才發現沒定，前後端訂單計算邏輯全要重做。
to-prd 壓成 PRD
跑 to-prd。它讀完前面那段對話，自動生成一份 PRD 提交為 GitHub issue。
中間它問我一句關鍵的話：這次改動會動哪些模塊？
我列了 order、user、promotion、admin-panel。它把這個範圍寫進 PRD 頂部。從這一刻起，後面所有 skill 都會盯着這個範圍。一旦 AI 想去動 payment 模塊，它會停下來問你。
這個 skill 產出的 PRD 嚴格按教科書定義看是不純的，裏面混了 implementation 和 testing decisions。教科書 PRD 應該只講 what 和 why，不講 how。
但單人加 AI 這個場景下，這種全景文檔對餵養 Claude 的價值反而更大。AI 一次性把上下文吃完，比分三份文檔來回找有效率得多。
只是命名上有點問題，這玩意兒在多人協作的正規場合不能叫 PRD。私底下自己用，叫啥都行。
to-issues 拆垂直切片
PRD 拿到手，下一步是拆任務。
我以前的拆法是水平的：先把所有 schema 寫完，再把所有 API 寫完，再把所有 UI 寫完。跑了 to-issues 才意識到方向錯了。
垂直拆法長這樣：
• Issue 1：運營在後台創建一張滿減券（schema + API + 後台表單 + 測試，端到端能跑通） • Issue 2：用戶在結算頁選擇應用已領取的券 • Issue 3：用戶在個人中心看到已使用和未使用的券 • Issue 4：運營批量發券給一個用戶羣
每個切片都端到端，每個切片做完都能給產品演示。
to-issues 跑完會主動問粒度、依賴、是否合併、每個 issue 是 HITL（人介入審核）還是 AFK（agent 自己跑完）。交易鏈路相關的我都標 HITL，剩下標 AFK。
這個標記決定後續 skill 的行為：AFK 的 issue 一口氣從測試寫到代碼合併；HITL 的每個關鍵節點停下來等我點頭。
tdd 紅綠重構
拿 Issue 2「用戶在結算頁能選擇應用已領取的券」舉例。
AI 先寫一個測試：用戶有滿 100 減 20 的券下單 150，期望結算頁顯示 130。跑一遍，紅的。
再寫最少的代碼讓測試通過。注意是最少。它不會順手把百分比折扣也實現了，哪怕它知道接下來就要做。
最後重構，確認測試還過。
關鍵紀律是不允許跳過紅。失敗的測試是一個證據，證明這個 bug 存在。沒有這個證據，你不知道你寫的代碼到底解決了什麼。
卡住時兩種分流
真做起來一定會卡。優惠券這個需求我至少卡了兩次。兩次解法不一樣。
測試過不了，AI 給的修復在猜，不在調。
Issue 2 跑到一半，結算頁死活算不對摺扣。AI 試了三種修法，每種都是在 controller 裏多加一個 if 判斷，全錯。
我跑了 diagnose。它沒急着給修復建議，先逼我寫一個最小復現腳本：按一下就能穩定觸發 bug，不依賴任何其他狀態。
寫完復現腳本，AI 列了五個可證偽假設：字段名拼錯、序列化漏了、緩存沒失效、中間件吞了、ORM 關係沒建立。每次只改一個變量，跑一次復現腳本。
第三個中了。配置 cache 沒失效，前端拿到的是老的優惠券規則。
說實話，diagnose 相比直接貼日誌讓 AI 分析，多做的就是擋住 LLM 那種附和傾向。貼日誌，它順着最顯眼那行給你猜測。diagnose 強迫你列 3-5 個假設、寫最小復現、一次只改一個變量、修完先寫回歸測試。
我直覺是字段不識別那肯定是字段名拼錯。真兇是緩存。這種 bug 只看症狀去猜，能猜到天荒地老。
還有一個工程問題。多服務環境下，怎麼造一個能穩定復現的反饋迴路？答案是剝離加替身，而不是複製整個生產。
要測優惠券計算這一段，把它從訂單服務剝出來。依賴的用戶服務和促銷服務用 stub 替掉，只保留要測的那一塊跑真代碼。一台機器上一秒觸發一次。
剝離是 diagnose 能成立的前提。
AI 在某個文件裏鑽牛角尖。
寫到優惠券和訂單的金額計算耦合那塊，AI 在 order_service.rb 裏改了一遍又一遍，每次改完都引入新的邊界 bug。
我打了一句：「I don't know this area of code well. Go up a layer of abstraction.」
這是 zoom-out 的觸發詞。AI 立刻跳出來，畫了一張領域上下文圖，把 order、promotion、payment 三個模塊的關係用領域語言描了一遍。
然後給了我一句判斷：問題在 promotion 模塊沒有暴露一個乾淨的 calculate_discount 接口，order 在硬讀 promotion 的內部狀態。
跳出來一看，問題在邊界，不在實現。
improve-codebase-architecture 防腐
優惠券上線兩週，我跑了一次 improve-codebase-architecture。
它基於 CONTEXT.md 裏 coupon、redemption、stacking-rule 這些詞去代碼庫裏找深模塊機會。
提了一條：優惠券校驗邏輯散在三個地方，商品詳情頁、結算頁、訂單確認頁。每個地方都重新跑了一遍這張券能不能用的判斷。建議合併成一個 coupon_eligibility 深模塊。
用刪除測試判斷深淺。假裝刪掉 coupon_eligibility，三個調用方都得各自維護一套過期檢查、用戶資格檢查、商品適用檢查、互斥規則檢查。這是個真深模塊。
合併完，三個頁面的相關代碼各少了 60 行。
最後
讀完整套之後我想了挺久 Matt 那句 slogan：real engineering, not vibe coding。
Vibe coding 有自己的位置：快速試想法、做原型、玩。
但你要讓 AI 寫一個會在生產裏跑、會被別人接手、會被自己半年後回頭維護的系統，vibe 不夠了。這時候需要的不是更強的模型，是一套讓人和 AI 都不容易跑偏的紀律。
越用 AI 寫代碼我越覺得，貴的是判斷，不是 token。是知道該讓 AI 幹什麼、不該讓它幹什麼。
判斷也不是一種心態，是一系列具體動作：拷問需求、記錄決策、強制復現、刪除冗餘、定期審視架構。這些動作可以被 skill 化。一旦工具化了，判斷就從一種玄學變成一套可以反覆用的工具。
Matt 這 17 個 skill，做的就是這件事。