---
title: 拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读
summary: 精读 mattpocock/skills 仓库：四个失败模式对应的设计、User-invoked 与 Model-invoked 两类 Skill 全景、idea→ship 主流程，以及盘问、调试、深模块三个最值得抄作业的设计。
tags: [Claude Code, Skills, Matt Pocock, Agent, 工程实践]
source_checked_at: 2026-07-06
---

# 拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读

> 一个人用 Claude Code 做真实工程，把"对齐、反馈、架构"三件最朴素的软件工程基本功，封装成了一套可组合的 Skill。不是花架子，是每天在用的东西。

---

## 先说结论

GitHub 上有个仓库：`mattpocock/skills`。作者 Matt Pocock 是 TypeScript 圈里资深的教育者（Total TypeScript 创始人），他把自己每天用 Claude Code 做真实工程的实践，沉淀成了一整套 Agent Skill。

仓库的 slogan 只有一句：

> My agent skills that I use every day to do real engineering — not vibe coding.

这套 Skill 不是 GSD、BMAD、Spec-Kit 那种"包办整个流程、接管你控制权"的重型框架。它的设计哲学就三个词：**small（小）、adaptable（易改）、composable（可组合）**。任何模型都能用，几十年工程经验浓缩成可复用的纪律。

这篇文章我精读了整个仓库，把它的核心思路、Skill 全景、以及最值得抄作业的几个设计讲清楚。

仓库地址：

https://github.com/mattpocock/skills

---

## 一、为什么会有这套 Skill：四个失败模式

Matt 把 AI 编码最常见的失败，归成四类。这套 Skill 的每一个，都是冲着其中一类去的。

### 失败模式 #1：Agent 没做我想要的

这是软件开发里最高频的失败：**对齐失败（misalignment）**。你以为对方懂了，做出来才发现完全跑偏。AI 时代一样存在这道沟通鸿沟。

解法是 **grilling session（盘问式访谈）**——在动手前，让 Agent 一条一条地问你：到底要做什么、边界在哪、异常怎么处理。把决策树的每个分支都走通，再开工。

对应 Skill：

- `/grill-me`——非代码场景的盘问
- `/grill-with-docs`——代码场景，盘问的同时沉淀文档（Matt 自评最受欢迎的 Skill）

### 失败模式 #2：Agent 太啰嗦

项目初期，开发者和领域专家讲的根本不是一种语言。Agent 被扔进项目里，只能边做边猜黑话，于是用 20 个词说本来 1 个词能说清的事。

解法是 **共享语言（shared language）**——一份文档帮 Agent 解码项目黑话。Matt 举了个自己仓库的例子：

- 改造前：「There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)」
- 改造后：「There's a problem with the materialization cascade」

一个精准的术语，能省下会话反复的开销。Matt 自己说这是整套仓库里"最酷的一个技巧"。

共享语言还有连带收益：变量/函数/文件命名一致 → 代码库更好导航 → Agent 思考更省 Token。

### 失败模式 #3：代码不工作

对齐了还是产出垃圾？问题在 **反馈回路（feedback loops）**。没有运行反馈，Agent 就是蒙眼飞行。

解法是老三样：静态类型、浏览器访问、自动化测试。其中自动化测试要走 **红-绿-重构（red-green-refactor）**：先写失败测试，再写代码让它通过。

对应 Skill：

- `/tdd`——红绿循环，可插入任何项目
- `/diagnosing-bugs`——把调试最佳实践封装成一个循环

### 失败模式 #4：我们造了一坨泥球（Ball of Mud）

Agent 能极大地加速编码，但同样加速了软件熵增。代码库复杂度以前所未有的速度膨胀。

解法是"关心代码设计"这个反直觉的思路。渗透在每一层 Skill 里：

- `/to-prd` 写 PRD 前先盘问你到底要碰哪些模块
- `/improve-codebase-architecture` 定期扫描代码库，找出"加深模块"的机会，每几天跑一次

### 一句话总结

Matt 想说的其实是：

> 软件工程基本功比以往任何时候都更重要。

这套 Skill 就是把这些基本功，固化成可重复的操作。

---

## 二、Skill 全景：两类调用方式

仓库的 Skill 按"谁能调用"分两类。这个区分很重要，决定了你什么时候用、什么时候它自动来：

| 类型 | 调用方式 | 职责 |
|------|----------|------|
| **User-invoked**（用户调用） | 只能你手动打 `/xxx` 触发 | 编排流程，做指挥 |
| **Model-invoked**（模型调用） | 你能调，任务合适时 Agent 也会自动调 | 持有可复用的纪律 |

一条铁律：**User-invoked 可以调用 Model-invoked，但绝不能调用另一个 User-invoked。** 这是为了避免 Skill 之间互相指挥、形成不可控的调用链。

下面是全部已发布 Skill 的全景。

### Engineering（工程类，日常代码工作）

**User-invoked（手动触发）：**

| Skill | 干什么 |
|-------|--------|
| `ask-matt` | 路由器：问一句"我该用哪个 Skill"，它指路。仓库的入口 |
| `grill-with-docs` | 盘问 + 沉淀领域文档（CONTEXT.md / ADR） |
| `triage` | 把 issue 在状态机里流转：分类、验证、必要时盘问，写出 Agent 能直接上手的简报 |
| `improve-codebase-architecture` | 扫描代码库找"加深机会"，生成可视化 HTML 报告，再盘问你选的那个 |
| `setup-matt-pocock-skills` | 一次性配置：issue 跟踪器、triage 标签、文档布局 |
| `to-issues` | 把计划/PRD 拆成"可独立认领的 issue"，按垂直切片 |
| `to-prd` | 把当前对话综合成 PRD，发布到 issue 跟踪器（不再访谈，只做综合） |

**Model-invoked（自动可调）：**

| Skill | 干什么 |
|-------|--------|
| `prototype` | 一次性原型回答一个设计问题（状态/逻辑用终端小程序，UI 用多套变体） |
| `diagnosing-bugs` | 硬 bug 的诊断循环：复现 → 最小化 → 假设 → 插桩 → 修复 → 回归测试 |
| `research` | 后台 Agent 查一手资料，产出带引用的 Markdown 文件 |
| `tdd` | 红-绿-重构，一个垂直切片一个垂直切片地做 |
| `domain-modeling` | 主动构建和打磨领域模型，挑战术语、写 ADR |
| `codebase-design` | 深模块设计的共享词汇表（module/interface/depth/seam/adapter） |
| `code-review` | 双轴评审：Standards（规范）+ Spec（需求），并行子 Agent 跑 |

### Productivity（生产力类，非代码工作流）

**User-invoked：**

| Skill | 干什么 |
|-------|--------|
| `grill-me` | 无代码库版的盘问（不沉淀任何东西，无状态） |
| `handoff` | 把当前对话压缩成交接文档，让另一个 Agent 接手 |
| `teach` | 跨多个会话教你一个新技能/概念，当前目录当教学工作区 |
| `writing-great-skills` | 写好 Skill 的参考手册：什么词汇和原则让 Skill 可预测 |

**Model-invoked：**

| Skill | 干什么 |
|-------|--------|
| `grilling` | 盘问的底层循环，`grill-me`、`grill-with-docs`、`triage`、`improve-codebase-architecture` 等多个 Skill 共用的原语 |

---

## 三、主干流程：从点子到上线，一条路走到底

Matt 把大多数工作抽象成一条 **主流程（main flow）**：idea → ship。`ask-matt` 这个路由器 Skill 把它画得很清楚。

```
┌──────────────┐   ┌──────────────┐   ┌──────────────────────────────┐
│ /grill-with- │──▶│   原型分支?   │──▶│  多会话构建?                  │
│   docs       │   │  (需要可运行  │   │  Yes: /to-prd → /to-issues   │
│  (盘问对齐)   │   │   的答案时)   │   │   → 每个 issue 新会话 /implement│
└──────────────┘   └──────────────┘   │  No: 当场 /implement          │
                    ▼                  └──────────────────────────────┘
            /handoff 出去                       │
            /prototype 探路                     ▼
            /handoff 回来               ┌──────────────────────┐
                                        │ /implement            │
                                        │  ├─ 内部驱动 /tdd      │
                                        │  └─ 收尾 /code-review  │
                                        └──────────────────────┘
```

几个关键设计：

**1. 上下文卫生（Context hygiene）**

第 1–3 步（盘问 → PRD → issue 拆分）要放在**同一个不中断的上下文窗口**里完成，不要中途压缩或清空。因为 PRD 和 issue 都建立在盘问的思考之上。

每跑一个 `/implement` 再开新会话，从单个 issue 起步。这样既保住了思考的连贯，又避免了长上下文导致模型"变钝"。Matt 给这个"变钝阈值"起了个名字叫 **smart zone**（大约 12 万 token）。

**2. 两个入口斜坡（On-ramps）**

有些工作不从"点子"来，而是从外部涌进来的，再汇入主流程：

- **bug 和请求堆积** → `/triage`，产出 Agent 能直接上手的 issue，再被 `/implement` 接走
- **东西坏了** → `/diagnosing-bugs`，专治难缠的 bug；它的复盘会交接给 `/improve-codebase-architecture`，当真正的发现是"没有合适的接缝把 bug 锁住"时

**3. 底层词汇表**

两个 Model-invoked 的 Skill 在最底层，提供单一权威词汇源：

- `/domain-modeling` 管领域语言（CONTEXT.md、ADR）
- `/codebase-design` 管架构语言（深模块、接缝、适配器）

其他 Skill 都来"拉取"这套词汇，保证全仓库用语一致。

**4. 跨会话：handoff vs compact**

- `/handoff`：**分叉**。把对话压成 markdown 文件，开新会话引用它。要新会话又想保留上下文时用。
- `/compact`（Claude Code 内置）：**继续**。留在同一对话里，把早期轮次总结掉。在阶段之间用，不要在阶段中间用——会丢线索。

---

## 四、三个最值得抄作业的设计

我把整套仓库翻完，挑出三个设计最精巧、最值得直接借鉴的。

### 4.1 盘问（Grilling）：一次只问一个

`/grilling` 是整个仓库的核心原语，全文只有几行：

> Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
>
> Ask the questions one at a time, waiting for feedback on each question before continuing.

三个细节决定它好用：

1. **一次只问一个**——同时甩一堆问题会让人懵
2. **每个问题附推荐答案**——降低你的决策负担，你只需确认或纠正
3. **能查代码就别问**——如果一个问题翻代码能答，就去翻代码，别用嘴问

这套思路完全可以照搬进你自己的 Skill：任何"开工前对齐"的场景，本质都是把决策树走一遍。

### 4.2 调试（Diagnosing Bugs）：先建回路，再谈假设

`/diagnosing-bugs` 最反直觉、也最关键的一句话是：

> **Phase 1（建立反馈回路）才是这个 Skill 的全部。其他都是机械操作。**

它明确禁止"先读代码建理论"——**没有一条能复现这个 bug 的命令，就不许进入 Phase 2。** 这恰恰是大多数人的本能做法，也是这套 Skill 要纠正的失败模式。

它的诊断循环是这样的：

```
Phase 1  建立能变红的回路（一条命令，跑出用户描述的症状）
   │     ← 把回路当产品打磨：更快、更准、更确定性
   ▼
Phase 2  复现 + 最小化（一个个删，删到只剩必需）
   ▼
Phase 3  生成 3–5 条可证伪假设（单条假设会锚定）
   ▼
Phase 4  插桩验证（一次只改一个变量，日志打 DEBUG 标签便于清理）
   ▼
Phase 5  修复 + 回归测试（先写测试，再修复）
   ▼
Phase 6  清理 + 复盘（追问：什么架构能预防这个 bug？）
```

几个细节非常工程化：

- **变红的判定标准**：回路必须能复现"用户的精确症状"，而不是"没崩"。一条 30 秒的 flaky 回路几乎等于没有；2 秒的确定性回路是"调试超能力"。
- **非确定性 bug**：目标在于**提高复现率**，而非一次干净复现。1% 复现的 bug 不可调，把复现率拉到 50% 就能调。
- **日志标签**：所有调试日志打 `[DEBUG-a4f2]` 这种唯一前缀，清理时一条 grep 搞定。
- **找不到合适的测试接缝，本身就是发现**——记下来，交给 `/improve-codebase-architecture`。

### 4.3 深模块（Codebase Design）：把词汇统一了

`/codebase-design` 是个纯词汇表 Skill，但它做对了一件难事：**强制全仓库用同一套词**。

它定义了 7 个术语，并明确禁止替代词：

| 术语 | 含义 | 禁止替代 |
|------|------|----------|
| Module | 有接口和实现的任何东西 | unit / component / service |
| Interface | 调用者必须知道的一切 | API / signature |
| Implementation | 模块内部的代码体 | — |
| Depth | 接口背后的行为密度 | — |
| Seam | 改行为不用改原地的那条缝 | boundary |
| Adapter | 填某个接缝的具体角色 | — |
| Leverage / Locality | 深度给调用者/维护者的回报 | — |

核心判断叫 **删除测试（deletion test）**：

> 想象删掉这个模块。如果复杂度消失了——它是个透传层；如果复杂度在 N 个调用方重新出现——它值得存在。

```
深模块（好）：小接口 + 大实现
┌─────────────────────┐
│   Small Interface   │  ← 方法少，参数简单
├─────────────────────┤
│  Deep Implementation│  ← 复杂逻辑藏起来
└─────────────────────┘

浅模块（避免）：大接口 + 薄实现
┌─────────────────────────────────┐
│       Large Interface           │  ← 方法多，参数复杂
├─────────────────────────────────┤
│  Thin Implementation            │  ← 只是透传
└─────────────────────────────────┘
```

为什么值得单独抽出一个 Skill 来管词汇？因为 **语言一致 = 思考一致**。`/tdd` 和 `/improve-codebase-architecture` 都说这套话，整个仓库就不会出现"一个人叫 service、一个人叫 component、一个人叫 boundary"的混乱。

---

## 五、30 秒装上，开箱即用

这套 Skill 用 skills.sh 安装，安装时可选目标 Agent（Claude Code、Codex 等）：

```bash
npx skills@latest add mattpocock/skills
```

选你要的 Skill 和目标 Agent，**务必勾上 `/setup-matt-pocock-skills`**，然后在 Agent 里跑一次它。它会问你三件事：

1. 用哪个 issue 跟踪器（GitHub / Linear / 本地文件）
2. 你 triage 时贴哪些标签（`/triage` 依赖标签）
3. 文档想存在哪

跑完就能用了。每个 Skill 在本地是仓库的符号链接，`git pull` 一下就保持最新。

如果你懒得读一长串 Skill，直接在 Agent 里打 `/ask-matt`，告诉它你的处境，它会把你路由到合适的流程。

---

## 六、能学到什么

这套仓库的价值，不在于某个具体 Skill 写得多炫，而在于它示范了一种"用工程纪律驯服 Agent"的方法论：

- **对齐先行**：任何改动前先盘问，把决策树走通——`/grill-with-docs`
- **反馈回路优先**：没有能复现的命令，不许谈假设——`/diagnosing-bugs`
- **词汇统一**：领域词和架构词各有唯一权威源——`/domain-modeling` + `/codebase-design`
- **流程可组合**：User-invoked 编排，Model-invoked 复用，互不越界
- **上下文卫生**：主流程一个窗口走完，每段实现另开新会话

你可以只拿走 `/grilling` 一个原语，也可以把整条主流程搬过来。Matt 自己的总结是：

> 这些 Skill 是我把工程基本功，凝练成可重复实践的最佳尝试，帮你写出职业生涯最好的应用。

对每个想把 Claude Code 从"玩具"变成"生产力"的工程师，这个仓库值得一读再读。

**仓库地址：**

https://github.com/mattpocock/skills

一个人用 Claude Code 做真实工程，把"对齐、反馈、架构"三件最朴素的软件工程基本功，封装成了一套可组合的 Skill。不是花架子，是每天在用的东西。

拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读

软件研发

开发工具

编程语言

后端

MattPocock的ClaudeCode技能库将软件工程基本功封装成可组合的Agent技能，解决AI编码四大痛点：对齐失败、啰嗦表达、代码质量差和架构混乱。核心技能包括盘问式访谈、共享语言、TDD测试和深模块设计，强调工程纪律比AI工具更重要。这套技能可快速安装，帮助开发者将ClaudeCode从玩具变成生产力工具。

软件工程

代码解释

回归测试

软件开发

TypeScript

路由器

GitHub

路由

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读-腾讯云开发者社区-腾讯云

拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读

拒绝 Vibe Coding：Matt Pocock 的工程级 Claude Code Skills 仓库精读

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐