如今的 GitHub 上，有一个与 AI 相关的热门项目，其内容几乎全是 Markdown 文本文件，但短短不到半年时间就收获了 18 万 Star。

这个仓库名为 skills，作者 Matt Pocock 是前端 TypeScript 领域颇具影响力的教育者，在 YouTube 上拥有数十万粉丝。他将自己日常使用 AI 编程的工作方法提炼成了一套实用技能——也就是一系列可以直接嵌入 Claude Code、Codex 等 AI 编程工具的指令集，随后将其开源发布。

那么，这套 Skills 究竟包含哪些内容？为何能获得如此广泛的关注？本文将带大家深入揭秘这个仓库，了解如何安装使用，以及其中值得学习的 AI 编程技巧。

Skills 仓库介绍

这个仓库的 Slogan 是「Skills for Real Engineers」，意思是这套工具并非为 Vibe Coding 氛围编程而生，而是为真正从事工程开发的人准备的。

简单来说，这个仓库提供了一套 AI 编程的 标准化操作流程。

使用过 Claude Code 的朋友应该知道，你可以通过编写 CLAUDE.md 文件来指导 AI 如何工作。但大多数人写的要么是一些零散的注意事项，要么是从网上复制来的通用提示词，实际效果往往不尽如人意。

Matt Pocock 所做的，是将真实的软件工程方法论——比如测试驱动开发、代码评审、领域建模等——浓缩成一个个 Skill 文件。安装到本地后，在 AI 编程工具中输入类似 /grill-me、/tdd 这样的斜杠命令，AI 就会按照对应的工程方法来执行任务，而非像往常那样随意发挥。

截至本文撰写时，整个仓库包含数十个 Skill 文件，其中正式推荐使用的有 22 个，其余则处于开发中、作者个人专用或已废弃状态。

这 22 个正式 Skill 分为两大类。一类是工程类，涵盖测试驱动开发、代码评审、Bug 诊断等与编码直接相关的内容；另一类是生产力类，包括头脑风暴、上下文交接，甚至还有一个让 AI 教你学习新知识的技能。

下面先介绍如何将这些 Skill 安装到自己的项目中，再挑选几个最实用的详细讲解。

30 秒快速使用

这个仓库的安装过程非常简单，打开终端，输入一行命令即可完成：

npx skills@latest add mattpocock/skills

运行后，它会让你选择需要哪些 Skill，以及安装到哪个 AI 编程工具中。选定后，对应的 Skill 文件会被复制到你的项目目录或 AI 工具的本地配置目录（例如 ~/.claude/skills/）。

建议勾选 /setup-matt-pocock-skills 这个初始化 Skill，安装完成后在 AI 编程工具中运行一次，比如在 Claude Code 中执行：

AI 会询问几个问题来适配你的项目，例如用什么工具管理 Issue、项目文档保存在哪个目录。为简化操作，这里选择用本地 Markdown 文件管理 Issue，文档保存在默认的 docs/ 目录下，规则保存到 CLAUDE.md 文件中。

如果不想手动管理这些安装到项目中的 Skill 文件，也可以使用 Claude Code 的插件方式安装，这样它会自动保持最新版本，但无法自行修改。

安装完成后，接下来看看这个仓库里最实用的几个 Skill。

/grill-me 需求拷问

这是整个仓库最受欢迎的一个 Skill，也是 Matt Pocock 本人反复推荐的。

它的作用是让 AI 反过来对你进行「灵魂拷问」，帮助你在让 AI 写代码之前把需求和设计考虑周全。

但令人惊讶的是，它的核心内容加起来竟然只有 3 句话！

翻译过来大致如下：

针对我的计划或设计，逐个问题地追问，直到我们达成共识。沿着决策树的每个分支深入，逐一解决分支之间的依赖关系。每个问题都要给出你的推荐答案。

每次只问一个问题，等我回答完再问下一个。一次性抛出多个问题会让人感到不知所措。

能通过查看环境（文件系统、工具等）找到的事实，直接去查，无需问我。但决策由我来做，每个决策都要等我确认。

没错，就是这么简单直接。

但实际使用后，效果确实非常出色。有用户分享说，他第一次使用 /grill-me 时，AI 一口气问了 38 个问题。等问完之后，他发现许多之前从未考虑到的设计细节都被 AI 逼着思考清楚了。

其实对程序员来说，这个思路并不陌生，有点像「小黄鸭调试法」——通过把自己的想法讲给别人听，来帮助自己发现问题。只不过以前这只鸭子不会说话，而如今 AI 这只鸭子能够刁难你了。

而且 /grill-me 的设计有一个关键细节，它要求 AI 一次只问一个问题，等你回答后再问下一个。这样可以避免 AI 一次性抛出大量问题让你不知所措，整个对话体验更像一场真正的需求评审。

如果你正在做一个有代码仓库的项目，可以使用升级版的 /grill-with-docs 技能。它在拷问你的同时，还会将讨论过程中确定的术语和决策记录到 CONTEXT.md 和架构决策记录文件中，为你的项目建立一份专属术语表。

这个术语表有什么用呢？大家应该都有过这种经历：每次跟 AI 描述项目里某个操作时，都要写一大段话解释，因为 AI 并不了解你们项目内部的叫法。

Matt Pocock 的做法是在 CONTEXT.md 里提前定义好这些术语。比如他自己有一个课程管理项目，针对「将课程章节中的某节课创建到文件系统」这个操作，他定义了一个术语叫「物化级联」，之后与 AI 沟通时只需要说这个词，AI 就能明白他在说什么。

因为 AI 每次对话都会读取 CONTEXT.md，所以这些术语积累得越多，AI 对项目的理解就越精准，沟通效率也越来越高。

/tdd 测试驱动开发

大家有没有遇到过这种情况？当你要求 AI 用测试驱动的方式开发时，它会一口气先把所有测试写完，然后再写所有代码。

这种方式看似高效，但实际上存在一个严重的坑。

AI 在写测试时，代码还不存在，因此它只能凭想象设计测试的结构。等真正开始写代码时，实际的 API 可能跟它想象的完全不同，结果就是一堆测试需要推倒重写。

/tdd 这个 Skill 正是为了解决这个问题。它强制 AI 采用「垂直切片」的方式工作——先写一个测试让它失败，然后只写刚好能让这个测试通过的代码，通过后再写下一个测试。这就是经典的 Red-Green-Refactor 循环，每次只走一小步，每一步都经过实际验证。

除了循环本身，这个 Skill 中还包含几条值得注意的规则。例如，它要求 只在预先商定的接缝处测试。所谓接缝（Seam）就是代码的公开接口，比如一个函数的入参和返回值。在写任何测试之前，AI 会先跟你确认在哪些接缝处进行测试，而不是到处乱写，这样测试的覆盖重点才能落在真正关键的位置。

此外，这个 Skill 还列出了几种 AI 写测试时容易犯的反模式，相当于给 AI 设定了规矩，一旦发现自己写出了这类测试就必须修正。最典型的一种叫「同义反复测试」，就是把被测代码的逻辑在测试中重新写一遍，例如 expect(add(a, b)).toBe(a + b)，这样的测试永远都能通过，毫无意义。正确的做法是使用独立的数据源作为期望值，比如一个确定的字面量、一个手工算好的例子。

对于团队项目来说，让 AI 按照 TDD 的方式编写代码，代码质量会有明显提升。

/diagnosing-bugs Bug 诊断

遇到 Bug 时，很多人的第一反应都是先看代码，猜测一个可能的原因然后尝试修改。AI 也是如此——大家可能经历过，让 AI 修 Bug 时，它改了半天却越改越乱。

Matt Pocock 认为问题的根源在于 AI 跳过了最关键的一步：先建立一个 能稳定重现 Bug 的反馈循环。

什么叫反馈循环？简单来说，就是一条能稳定重现 Bug 的命令。可以是一个会失败的测试用例、一个 curl 请求，甚至一个 Playwright 浏览器自动化脚本，只要能做到一键运行，并明确告诉你 Bug 是否被触发。

/diagnosing-bugs 这个 Skill 将 Debug 过程拆分为 6 个阶段，其中「建立反馈循环」是第一步，也是整个流程的核心。

在这步完成之前，AI 不允许跳到「猜原因」的阶段。如果 AI 在还没有一条能重现 Bug 的命令时就开始分析代码，Skill 会直接打断它。

等到有了一条稳定重现的命令之后，接下来的步骤就比较常规了：最小化重现场景、提出假设并逐一验证、修复并编写回归测试。

这个思路与 Cursor 内置的 Debug 模式有异曲同工之妙。Cursor 的 Debug 模式也是先通过自动检测和分析错误来定位问题，而不是让 AI 上来就瞎猜乱改。不过 /diagnosing-bugs 更侧重于流程规范，它用一套严格的分阶段方法来约束 AI 的调试行为。先让 AI 建立一个可靠的重现方式，后续的修复效率反而会更高。

/teach AI 辅助学习

前面几个 Skill 都跟写代码相关，但这个仓库里还有一些通用的生产力工具。比如 /teach 技能，作用是让 AI 变成你的私人教师。

按照作者 /grill-me 技能的尿性，本以为这个 Skill 也就几句话，比如经常看到的：

用傻子都能懂的语言，帮我学习 XX 知识点，通过联网搜索获取最新信息

但其实，这个技能不只是让 AI 简单讲个知识那么简单，它背后有一套相当完整的教学方法论。

当你运行 /teach 并告诉 AI 你想学什么之后，AI 会先问你为什么想学这个东西？

然后 AI 会把你的学习目标记录到一个叫 MISSION.md 的文件里。

接着它会去搜索高质量的学习资源，整理成 RESOURCES.md 资源文件。

最后基于收集到的资源给你设计课程，每堂课是一个精美的 HTML 文件，保存在 lessons/ 目录下。

值得一提的是，AI 会区分「流畅度」和「存储强度」这两种学习效果。流畅度就是你当场能回忆起来的感觉，但这不代表你真的记住了。存储强度才是真正的长期记忆。所以它会刻意设计有一定难度的练习，用间隔重复和交错练习等方法来帮你加深记忆，而不是让你产生「我已经学会了」的错觉。

还有个很妙的设计是「最近发展区」，这是教育学里的经典理论。AI 会根据你之前的学习记录来判断你现在的水平，然后设计刚好超出你能力一点点的课程内容，既不会太简单让你感到无聊，也不会太难让你放弃。

而且你的所有学习过程都被保存在当前目录下，下次打开同一个目录继续学习时，AI 就能接着上次的进度继续，有种 AI 时代个性化教育的感觉。

/wayfinder 大项目规划

这个 Skill 专门解决一个问题：当项目大到一个 AI 对话装不下时，该怎么办？

使用过 AI 编程的朋友应该都有体会，如果你强行在一个很长的对话里完成所有事情，AI 的思考质量会随着上下文变长而明显下降。Matt Pocock 把 AI 表现最好的上下文范围称为「智能区间」，大概在 120K tokens 以内。

/wayfinder 的做法是将一个大需求拆解成一张「决策地图」。当你面对一个庞大而模糊的需求时，AI 会先跟你一起把最终目标定义清楚，然后在 Issue 管理工具中创建一张地图，上面列出需要做出的一系列决策，每个决策对应一个独立的 Issue。

这些决策之间存在依赖关系，所以它会自动标注哪些可以先做、哪些需要等待前置决策完成才能启动。

每次你打开一个新的 AI 对话来处理一个决策时，上下文都是干净的，不会被之前的内容污染。

这个思路其实跟企业开发中的「模块化」很像——把一个大项目拆成多个模块分配给不同的开发者，每个人只需要关注自己负责的部分。

这里面还有一个很有趣的设计叫「战争迷雾」，就像游戏里没探索过的地图区域一样。你现在能看到的决策只是一部分，随着前面的决策逐步完成，后面的决策才会逐渐清晰起来。这样可以避免一开始就过度规划那些还不太清楚的事情。

不过这个 Skill 的门槛相对较高，更适合有一定工程经验的开发者使用。如果你的项目规模不大，前面提到的 /grill-me 就足够应付了。

/improve-codebase-architecture 代码架构改进

除了日常的开发流程，Matt Pocock 还建议每隔几天运行一次 /improve-codebase-architecture 技能，相当于定期给代码做一次全面体检。它会深度扫描你的代码库，找出那些结构上可以优化的地方。

代码扫描完成后，AI 会生成一个可视化的 HTML 报告，而不是枯燥的文字。报告中使用 Tailwind 美化样式、用 Mermaid 绘制架构图，每个优化建议都是一张卡片，上面写着涉及的文件、当前的问题、建议的改进方案，以及改进前后的对比图。

每个建议还会标注推荐程度，有些是强烈推荐的，有些是值得探索的，有些只是试探性的。你选择一个感兴趣的建议后，它会启动一轮新的 grilling 对话来跟你讨论具体如何修改。

这个 Skill 背后的核心理念来自《A Philosophy of Software Design》这本书。打个比方，一个好的模块就像微波炉，你只需要按几个按钮就能加热食物，内部的电磁波原理完全不用管。这种叫做「深」模块，接口简单，实现复杂。

但如果一个模块用起来跟自己写一个差不多费劲，那就是「浅」模块了。这个 Skill 要寻找的就是代码库里那些「浅」模块，帮你把它们改造成「深」模块。

/handoff 上下文交接

大家在使用 AI 编程时应该都遇到过这个问题：在一个对话中讨论了很多内容，积累了大量的上下文，但开启新对话时，之前的所有讨论就全丢失了。

虽然可以手动复制粘贴，但比较麻烦，还容易遗漏关键信息。

/handoff 技能就是来解决这个问题的。在你当前对话结束前，它会让 AI 把整个对话的核心内容压缩成一份交接文档，保存为一个 Markdown 文件。

下次开启新对话时，只要让 AI 读取这个文件，它就能接着上次的进度继续工作。

这份交接文档还会标注建议在新对话中使用哪些 Skill，并且会自动去除敏感信息，比如 API 密钥等。

这样一来，多轮对话之间就能够实现无缝协作了。

最后

学习完这个仓库后，感受最深的一点是，这些 Skill 本质上不是提示词技巧，而是把经典的软件工程方法论封装成了 AI 能够执行的格式。

像测试驱动开发、领域建模、架构评审，这些理念在软件工程领域已经存在了二十多年，但以前你需要依靠团队协作和代码评审来落地，而现在通过 Skill 文件就能让 AI 自动按照这些方法来工作。

而且通过这个仓库，你会发现，AI 时代做开源从未如此简单！Matt Pocock 本质上就是把自己电脑里 .agents 目录下的工作方法分享了出来，然后持续迭代打磨，就成了拥有十几万 Star 的项目。也许你也可以把自己积累的 AI 编程工作流或提示词模板整理一下开源出来，持续优化，说不定也能帮到很多人。

果然，行动才是第一生产力。