文档大纲

用 mattpocock 的 38 个 skill 提升 vibe coding 质量

vibe coding 的尴尬

去年写了个内部工具，昨天被同事翻出来问: 怎么一加新功能就崩?

打开一看，心凉了半截——AI 写的代码，单元测试全过，Lint 全，但任何路径走深一点就抛。我根本没有"边界"概念，只让 AI 写"用户能下单"的 happy path,从来没问过"用户下到一半断网怎么办"。

这就是 vibe coding 的典型症状:代码看着对，跑起来不对;改一处，坏三处;交付时信心为零。

Matt Pocock 给这种现象起了个名字——"vibe coding is not engineering"。他在 2025 年开了个仓库 mattpocock/skills,把自己十几年工程经验做成 38 个可调用的 skill,288k star,几乎成了 Claude Code 用户的标配。

我装上用了两个月，今天分享一下真实使用经验，以及这 38 个 skill 怎么用，才能真正解决问题，而不是变成新一层装饰。

为什么你需要这 38 个 skill

先把丑话说前头:装上 skill 不会让你变强。skill 是脚手架，不是水泥。如果你脑子里没有"反馈环"这个概念，装 380 个 skill 也写不出能改的代码。

但反过来——如果你有意识地在做对的事，却总是做到一半就歪,skill 就是外置的纪律系统，把你拉回正轨。

mattpocock 的几个核心问题诊断，我自己撞过很多次:

"AI 没做我要的" —— 因为我连自己要啥都说不清。解药:/grill-with-docs
"AI 太啰嗦" —— 我和它对术语，各说各话 20 词表达 1 词。解药:/domain-modeling + CONTEXT.md
"代码跑不起来" —— 没有反馈环，AI 在云里雾里。解药:/tdd + /diagnosing-bugs
"代码改不动" —— 设计烂了，改一处坏三处。解药:/codebase-design + /improve-codebase-architecture

每个问题，他都给了一个可调用的 skill,入口统一，行为可预测。这和 superpowers 的 L1-L5 闭环思路不同——mattpocock 是"小而专",superpowers 是"大而严"。

我现在的搭配是:用 superpowers:brainstorming 决定要不要做 → 用 /grill-with-docs 决定怎么做 → 用 /to-tickets 拆活 → 用 /implement 落地 → 用 /code-review 收尾。五步走完，代码能进主分支。

skill 路由器:别背 38 个名字

38 个 skill 怎么用?背?做梦。mattpocock 给了一个路由器:/ask-matt。

它的设计哲学很有意思——你不用记"我现在该用 TDD 还是 diagnosing-bugs",你只说一句"我卡住了",它会反问你两句，然后告诉你用哪个。

我的用法:

我: /ask-matt
Agent: 你想做什么?
我: 我想给订单系统加个导出 CSV 功能
Agent: 这是个工作量不明的活,先 /grill-with-docs 想清楚边界

/ask-matt 内部是一张决策图，核心只有一条主流程:

idea → ship
  │
  ├─ /grill-with-docs (想清楚)
  │    ├─ 需要 prototype? → /handoff 出 → /prototype → /handoff 回
  │    ├─ 多会话大活?    → /to-spec → /to-tickets → 逐 ticket /implement
  │    └─ 单会话小活?    → /implement 直接干
  │
  └─ /code-review (收尾,双轴并行)

其它 30 多个 skill 围绕这条主流程展开，各有定位:

类别	解决什么
设计层	/grill-with-docs /grill-me /domain-modeling /codebase-design
拆分层	/to-spec /to-tickets /wayfinder
执行层	/implement /tdd /prototype /wizard /research
调试层	/diagnosing-bugs /resolving-merge-conflicts
收尾层	/code-review /improve-codebase-architecture
文档层	/handoff /triage /teach /to-questionnaire /wait-what /writing-for-agents

记不住?别记，跑 /ask-matt。这本身就是 skill 设计想鼓励的行为。

实战 1:用 `/grill-with-docs` 治"AI 没做我要的"

/grill-with-docs 是最被低估的 skill。它做两件事:

递归 grill:每轮问所有"前置已定的决策",等你答完再开下一轮
同步写文档:把"用啥术语"写进 CONTEXT.md,把"为啥这么设计"写进 ADR

我最近的实战:给"订单导出 CSV"功能 grill。

❓ Q1 — 谁会导出?
  A. 内部 CS 团队(给客户手动导)
  B. 客户自己在后台导
  C. 系统定时自动导(给财务)
➡️ B. 客户自己导(产品已经定了)

❓ Q2 — 一次最多导多少行?
  A. 1k 以内(同步导完)
  B. 1k-100k(分页 + 进度条)
  C. 100k+(异步任务 + 邮件)
➡️ C. 100k+(用户群里已经有人提过)

(AI 自动派 subagent 去查 ADR #42,问 Q3...)

❓ Q3 — 字段顺序?

注意几个关键点:

AI 不会问我能自己查到的事 —— 它派了 subagent 查仓库的 ADR、历史 issue,而不是把所有问题都甩给我
每轮我只看 frontier —— 已定的决策不会再问，新解锁的问题才出现
grill 完，术语和决策已经写进文件 —— 下次新会话，AI 打开 CONTEXT.md 就能延续

我跟三个朋友推荐过这个 skill。一个说"它比 brainstorming 还啰嗦",一个说"它救了我一个 deadline",一个说"我从此再也不直接 to-spec 了"。

我的评价:grill 是 skill 里最反直觉，但回报最高的。它看起来浪费时间，实际是在把所有假设 surface 出来，省下游的反复返工。

实战 2:用 `/to-tickets` 治"代码改不动"

AI 给我一个 800 行的 spec,我直接让它干，几乎一定跑偏。不是因为 AI 不行，是因为 spec 太粗，大到 AI 没法一次性 hold 住。

/to-tickets 的解法是 vertical slice:

错的切法(horizontal)	对的切法(vertical)
T1: 写所有 model 类	T1: 订单表 schema + 导出接口 + 导出按钮（可独立 demo)
T2: 写所有 API	T2: 异步任务系统 + 进度查询（可独立 demo)
T3: 写所有 UI	T3: 文件下载 + 历史记录（可独立 demo)

每个 ticket 切完整路径——schema + API + UI + tests。完成一个就能 demo,坏一个只坏一个。

更狠的反模式是 wide refactor（全库 rename、retype shared symbol)——它不是 vertical slice,因为一刀切会同时坏 N 个 caller。/to-tickets 会自动切到 expand → migrate → contract 三段:

T1 (expand):   加新字段 + 旧字段保留
T2-T5 (migrate): 分批迁移 caller(按 blast radius 切)
T6 (contract):  删除旧字段

我之前给一个 8 万行的 TypeScript 项目做 type rename,按这个序列做，3 周没出过一次大事故。

最重要的一条:每个 ticket 适配一个 fresh context window。完成一个就 /clear,不要贪。Claude Code 的 context 满了质量就掉，这是物理限制，不是 bug。

实战 3:用 `/diagnosing-bugs` 治"bug 找不干净"

这是 mattpocock 的金句，也是我学到最值的一句话:

"If you have a tight pass/fail signal, you will find the cause. If you don't, no amount of staring at code will save you."

我的翻译:没有紧的反馈环，debug 就是玄学。

/diagnosing-bugs 的核心是 Phase 1:Build a feedback loop。它列了 10 种方法，从最简单的"写个失败测试"到最复杂的"differential 双版本对比",按顺序选。前 90% 的精力花在这上面。

我自己最常用的是 "throwaway harness"——扔掉所有不相关的依赖，起一个最小子集服务，用单函数调用就能复现 bug。听起来很土，但把环境噪声干掉后，bug 的根因经常一目了然。

第二步是 tighten the loop:

能跑 30 秒 flaky 几乎没用，要跑 2 秒 deterministic
缓存 setup,跳过不相关 init
assert 具体症状（不只 assert "不崩")
钉时间、种子 RNG、隔离 fs、冻结网络

我曾经有个 bug 反复修反复出，跑 harness 2 秒、断言精确到第几帧的渲染输出，半小时定位到一个 obscure 的 React concurrent mode edge case。这之前瞪了三天代码。

实战 4:用 `/tdd` 不让 AI 给你写假测试

/tdd 的红绿循环谁都，但 mattpocock 的版本狠狠抓三个反模式:

Implementation-coupled:mock 了内部协作者。重构后测试无意义地红。正确做法是只在 pre-agreed seam 上测。
Tautological:expect(add(a, b)).toBe(a + b)——期望值是用代码算的，测试必然过。期望值必须来自独立真理（已知 literal、worked example、spec)。
Horizontal slicing:先写完所有测试再写实现。想象出来的行为，不是用户面对的。改用 vertical slice。

我见过最离谱的 TDD:

// 错
test('orderService calls paymentGateway.charge', () => {
  const spy = vi.spyOn(paymentGateway, 'charge');
  await orderService.checkout(cart);
  expect(spy).toHaveBeenCalledWith(amount);  // 测了实现细节,不是行为
});

重构后这个测试一定会挂,尽管行为没变。

正确写法:

// 对
test('user can checkout with valid cart', async () => {
  const order = await orderService.checkout(validCart);
  expect(order.status).toBe('paid');  // 走 Stripe webhook fixture 真实路径
});

测试名写行为，不写实现。"user can checkout with valid cart" 比 "calls paymentGateway.charge" 价值高 10 倍——前者 refactor 后还在，后者必死。

实战 5:`/code-review` 收尾，双轴并行

/code-review 是我收尾必跑。它派两个并行 sub-agent:

Standards 轴:对照 CODING_STANDARDS.md,叠加 Fowler 代码味道基线(Mysterious Name / Duplicated Code / Feature Envy / Data Clumps / Primitive Obsession / Repeated Switches)
Spec 轴:对照原 issue / spec,看实现是否忠实

两份报告并列，互不污染我的上下文。

我用 three-dot diff:git diff <fixed-point>...HEAD,比较的是 merge-base,不是直接父 commit。

关键 trick:sub-agent 用独立 context,所以我能在主会话继续读别的文件——并行效率 + 隔离上下文，双 buff。

怎么上手:5 分钟装上

如果你装过 Claude Code,一行命令:

claude plugin install mattpocock-skills@claude-plugins-official

装完 claude plugin list 应该看到 mattpocock-skills ✔ enabled,版本 v1.2.3+。

注意:/setup-matt-pocock-skills 必须在 git 仓库根目录跑（用户根目录跑会报 Unknown skill,这是预期行为，不是装错）。它会问三个问题:

Issue tracker 选啥(GitHub / GitLab / 本地 / Other)
Triage label 词汇（默认 needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix)
文档存哪（默认单 context:CONTEXT.md + docs/adr/)

跑完这个，你才有资格跑 /to-spec /to-tickets /triage——这三个都依赖 issue tracker 配置。

与 superpowers / huashu 怎么搭

我同时装了 superpowers@claude-plugins-official 和 huashu-* 一堆，踩过坑。简单原则:

场景	用谁
创造性 / 模糊任务	superpowers:brainstorming 先，再 mattpocock grill
已 grill 过，需要纪律化执行	mattpocock(/to-spec → /implement → /tdd)
卡 bug	mattpocock(/diagnosing-bugs 反馈环比 superpowers:systematic-debugging 更具体）
收尾 review	mattpocock(/code-review 双轴）
跨项目工程实践 / 流程	superpowers
写新 skill	superpowers:writing-skills + mattpocock:/writing-for-agents 都看
中文场景 / PPT / 演讲	huashu-*

重点是不要两套同场景 skill 都用——mattpocock 自己的 README 第一句话就是 "Pick one per agent, because installing both gives you every skill twice." 我试过，确实会精神分裂，AI 不知道听谁的。

一个月后，我回不去了

我写代码的方式，从"AI 帮我快速出活",变成了"AI 帮我守住工程纪律"。

这之前:我让 AI 写代码，写完跑测试，绿了 commit。三个月后我自己都看不懂。

这之后:每个功能都先 grill,出 spec,拆 vertical slice,逐 ticket TDD,code review。每个 ticket 之间 /clear。代码量没少，但三个月后我自己还能秒改。

mattpocock 自己在 README 里说:"These skills are designed to be small, easy to adapt, and composable. Hack around with them. Make them your own."

我用了一个月，改过 CONTEXT.md 改过标签改过 ticket 模板。它不是黑盒——它是脚手架，你和 AI 一起把它调成你团队的形状。

如果你受够了 vibe coding 的玄学，装上，跑一遍 /grill-with-docs,看看你的下一个 PR 是不是稳一点。

阅读量： 231

vibe coding 的尴尬

为什么你需要这 38 个 skill

skill 路由器:别背 38 个名字

实战 1:用 /grill-with-docs 治"AI 没做我要的"

实战 2:用 /to-tickets 治"代码改不动"

实战 3:用 /diagnosing-bugs 治"bug 找不干净"

实战 4:用 /tdd 不让 AI 给你写假测试

实战 5:/code-review 收尾，双轴并行