打造真实项目的 AI 编程环境:Matt Pocock 的 Skill 工作流完整上手攻略

很多人刚开始用 AI 写代码时，都会有一种错觉：代码生成这么快，开发效率是不是马上就能翻倍？但项目跑起来之后，很快就会发现事情没那么简单。

需求理解有偏差，Agent 会自己补全细节；代码能生成出来，但各种边界情况没考虑；改一个功能，又影响了其他地方；换个会话之后，之前建立的上下文也得重新解释。

这些问题未必是模型不够聪明，更多时候是因为项目缺少一套让 AI 能持续协作的机制。

当所有人都在讨论「AI 能不能帮我多写点代码」的时候，Matt Pocock 给出的答案更像是另一句话：先别急着让 AI 狂奔，先把工程环境搭起来。

2026 年 3 月，TypeScript 社区里大家的老熟人 Matt Pocock 做了一件挺有代表性的事：他把自己日常在 Claude Code 里使用的 .claude/skills 目录直接开源出来，仓库叫 mattpocock/skills^[1]。

仓库副标题也很直白：

Skills for Real Engineers. Straight from my .claude directory.

我第一次看到它的时候，以为这又是一个「全自动 AI 开发框架」。结果点进去才发现，它没有复杂的多 Agent 编排，没有虚拟敏捷团队，也没有试图接管从需求到上线的整个流程。

它本质上就是一组 Markdown 文件，每个 Skill 都对应一种工程实践。

真正让我觉得有意思的是，它关注的不是让 AI 替你做决定，而是把需求澄清、测试验证、问题诊断这些原本就该做的事情，整理成一套可重复执行的流程。

Matt Pocock 的 Skills 到底解决了什么问题

Matt Pocock 这套 skills 提出了一个颠覆性的视角：与其归咎于模型写不出代码，不如说 AI 编程的失败普遍源于工程反馈链的失效。

换句话说，真实项目里那些老问题，到了 AI 编程时代并没有消失，只是被放大了。

问题一：Agent 没有真正听懂你要什么

最常见的翻车现场是：你以为自己说清楚了，Agent 也表现得像听懂了，结果代码生成出来才发现，双方理解的根本不是同一个需求。

Matt 的处理方式直接推翻了「写更长提示词」的传统套路，转而让 Agent 掌握主动权，反过来拷问你。

这里最关键的两个 skill 是：

• • /grill-me：适合非代码类决策，让 Agent 先追问模糊点。
• • /grill-with-docs：适合代码场景，一边澄清需求，一边把领域语言和决策沉淀到文档里。

这一步看似拖慢节奏，实际是在给后面的所有代码生成校准方向。

需求一旦错了，后面写得越快，返工就越贵。

问题二：Agent 太啰嗦，项目语言不统一

很多时候，Agent 的那股啰嗦劲真不是故意的，它只是纯粹卡在了不知道你们团队内部怎么称呼某个概念上。

你们内部可能只说「materialization cascade」，但 Agent 会写一大串解释：「某个 course section 里的 lesson 被放到文件系统中时触发的问题」。

这就是领域语言没有共享的后果。

/grill-with-docs 的价值不只是澄清需求，它还会把这些术语沉淀到类似 CONTEXT.md 的文档中。等下一次 session 开始，Agent 不用重新猜项目里的概念，变量名、函数名、文件名也更容易保持一致。

这件事听起来不酷，但在真实项目里很省 token，也很省沟通成本。

问题三：代码看起来完成了，但其实不 work

AI 很容易生成「形状正确」的代码：文件有了，函数有了，测试也看着有了，但真实行为不一定对。

Matt 用 /tdd 和 /diagnose 来解决这个问题。

/tdd 强调的是严格的 red-green-refactor 循环，而且它反对一次性把所有测试写完再让 AI 实现。更推荐的方式是垂直切片：一个行为，一个失败测试，一个最小实现，再进入下一个行为。

/diagnose 则是调试工作流：先复现，再缩小范围，再提出假设，再插桩验证，最后修复并补回归测试。

这里的重点在于，比起纠结「AI 会不会调 bug」这种单点能力，先让 AI 建立起一套高频且稳定的反馈闭环。

没有反馈环的 AI 编程，本质上就是闭眼开车。

问题四：项目很快变成大泥球

AI 提升了写代码速度，也会同步提升架构腐化速度。

以前一个人一天只能写几百行，现在 Agent 可以很快铺出一大片代码。如果每次都只盯着当前功能，项目结构会在不知不觉中变散、变厚、变难改。

Matt 把架构意识放进了几个不同层级的 skill 里：

• • /to-prd：在需求落地前先想清楚影响哪些模块。
• • /to-issues：把任务拆成端到端可验收的垂直切片，而不是按文件拆活。
• • /zoom-out：进入陌生模块时，让 Agent 先站在系统层面解释代码。
• • /improve-codebase-architecture：周期性扫描项目，找可以修剪、加深、收敛的模块。

这也是这套 skills 和很多「自动开发框架」最大的区别：它不抢你的控制权，而是提醒你别忘了工程判断。

30 秒安装：把 Skills 接入你的 Claude Code

安装方式很简单，直接在项目里运行：

npx skills@latest add mattpocock/skills

这个命令会启动一个交互式 CLI，通常会让你选择两件事：

1. 1. 要安装哪些 skill。
2. 2. 要安装到哪个 Agent，比如 Claude Code、Cursor 或其他兼容环境。

如果你是第一次用，我建议不要一上来全装，而是先选一组最能覆盖真实开发流程的核心 skill：

安装完成后，建议先跑一次初始化：

/setup-matt-pocock-skills

这个向导会帮你确认几个关键约定：

• • Issue tracker 用什么：GitHub Issues、Linear，还是本地 Markdown。
• • triage 标签怎么设计：哪些 label 代表待处理、进行中、阻塞、完成。
• • 领域文档放在哪里：比如 CONTEXT.md 和 docs/adr/。

初始化之后，你的项目里通常会多出一组协作文件：领域语言、架构决策记录、标签字典、issue 工作流说明等。

这些文件不是摆设。它们的作用是让 AI 每次进入项目时，不再像一个刚入职的新同事，而是能读到团队已经形成的上下文。

AI 编程环境的第一步，不急着装更多工具，更重要的是让上下文有地方沉淀。

一套真实项目里的标准使用流

如果只把这些 skill 当成零散命令，很容易用着用着又回到随手 prompt 的状态。

更推荐的方式，是把它们串成一条真实项目里的开发流。

第一步：用 /grill-with-docs 先对齐需求

开始一个新需求时，不要直接说「帮我实现某某功能」。

更好的开场是：

/grill-with-docs

然后把你的想法告诉它，让它追问你：目标用户是谁、边界条件是什么、已有模块有哪些约束、哪些决策需要记录下来。

这一步的产物将会是更清晰的需求和领域语言，而不是一上来就追求生产代码。

第二步：用 /to-prd 把对话落成文档

需求澄清后，再让 Agent 把当前对话整理成 PRD：

/to-prd

这一步适合把「我们刚才聊明白的东西」变成可以复查、可以交给别人、也可以继续拆任务的文档。

如果一个需求连 PRD 都说不清楚，直接写代码大概率只是在制造返工。

第三步：用 /to-issues 拆成垂直切片

接下来需要按用户能感知的行为拆任务，而不是按文件拆任务：

/to-issues

比如「新增 GitHub OAuth 登录按钮」是一个切片；「新增 auth utils 文件」不是。

垂直切片的好处是，每个 issue 都能独立验收，也更适合让 AI 在一个较小范围内完成闭环。

第四步：用 /tdd 做最小实现

真正进入编码时，再使用：

/tdd

Matt 对 TDD 的要求很明确：不要先写一堆测试，再一次性生成实现。那种方式看着很完整，实际经常只是在测试函数签名和数据形状。

更好的方式是：

RED → GREEN：行为 1 → 最小实现 1RED → GREEN：行为 2 → 最小实现 2RED → GREEN：行为 3 → 最小实现 3

每次只推进一个可观察行为，反馈更快，偏航也更容易发现。

第五步：遇到 bug 切到 /diagnose

如果一个 Bug 复现半天都复现不出来，日志也看不出问题，那就别指望 Agent 靠猜测给出正确答案。

切到：

/diagnose

它会强制按照固定的调试流程来处理问题：先找到稳定的复现方式，再缩小排查范围，然后提出假设、验证假设，最后再动手修复。

其中最关键的一步，是先准备一个足够快的反馈机制。理想情况下，一个命令就能在几秒内告诉你结果是成功还是失败。

调试效率很大程度上取决于反馈速度，而不是阅读代码的速度。

第六步：定期用 /improve-codebase-architecture 修剪项目

功能做完不代表工程结束。

每隔几天，或者每完成一组相关需求后，可以跑一次：

/improve-codebase-architecture

它做的不是大重构，而是顺手把代码整理得更舒服一些：重复的代码收一收，职责不清的模块理一理，该命名的概念补上名字，该记录的设计决策补进 ADR。

如果你正在进入一个陌生模块，也可以先跑：

/zoom-out

让 Agent 先从系统层面解释这块代码，而不是直接钻进某个文件里改。

这套流程连起来就是：

/grill-with-docs  ↓/to-prd  ↓/to-issues  ↓/tdd 或 /diagnose  ↓/zoom-out 或 /improve-codebase-architecture

它不神秘，本质上就是把「先对齐、再计划、再小步实现、再验证、再整理」这套工程基本功，变成 Claude Code 能跟着执行的节奏。

它和 GSD、BMAD、Spec-Kit、Superpowers 该怎么选

Matt Pocock skills 不是唯一的 AI 编程工作流。现在常见的还有 GSD、BMAD、Spec-Kit、Superpowers 等方案。

它们没有谁一定比谁强，关键还是看项目处于什么阶段、团队需要解决什么问题。

如果你只是想让 AI 帮忙写个脚本，这些流程可能显得有些重。

但如果你做的是一个会持续迭代的项目，Matt Pocock Skills 值得试试。它没有试图接管你的开发流程，也不会用一套框架替代你的判断，而是把几个容易被忽略但又很重要的环节固定下来：需求澄清、文档记录、任务拆分、测试验证、问题诊断和代码整理。

我的使用建议是：

• • 日常开发：优先用 Matt Pocock Skills
• • 跨天的大型任务：可以考虑 GSD
• • 从 0 到 1 的产品开发，且流程要求较重：BMAD 更合适
• • 特别重视测试质量：可以参考 Superpowers
• • 需求和规范驱动的企业项目：Spec-Kit 更贴近实际场景

回到最开始的问题：什么样的环境更适合 AI 参与真实项目开发？

这些年的实践给我的一个感受是，问题往往不在模型能力，而在协作方式。

很多团队花了大量时间研究模型、提示词和 Agent，却很少花时间思考怎么把 AI 放进现有的工程流程里。

而 Matt Pocock Skills 最有价值的地方，恰恰是把一些关键环节标准化了。它不会让项目自动成功，但能减少很多因为缺少约束和反馈带来的混乱。

AI 写代码越来越容易，真正困难的部分其实一直没变：需求是否清晰、反馈是否及时、测试是否完善、决策是否被记录。

这些事情做好了，模型换成谁都能发挥作用；这些事情做不好，再强的模型也很难长期稳定地产出高质量代码。

如果你想体验一下这套工作方式，可以从下面这条命令开始：

npx skills@latest add mattpocock/skills

先把 grill-with-docs、tdd、diagnose 这三件套跑起来。

引用链接

[1] mattpocock/skills: https://github.com/mattpocock/skills