本周看到一个很值得推荐的开源仓库：mattpocock/skills。

作者是 Matt Pocock，很多前端工程师应该知道他。他长期做 TypeScript 教学，这次公开的是自己日常使用 AI 编程工具时积累的一套 agent skills。

项目地址是：

github.com/mattpocock/skills

这个仓库现在已经有 8 万多 star。skills.sh 上显示，它包含 34 个 skills，总安装量超过 130 万次。其中安装量最高的几个是 grill-me、improve-codebase-architecture、tdd、grill-with-docs、to-prd、diagnose。

它最值得看的地方，不是“又多了一批 提示词”，而是换了一个看 AI 编程的角度。

很多人第一次接触 AI 写代码，会把它当成一个“会自动完成任务的工具”。你输入一句话，它输出一堆代码。看起来很像魔法。

但在真实项目里，更准确的理解是：

AI 不是神，它更像一个手很快的新同事。

这个同事读过很多代码，反应很快，也很勤奋。你说“帮我做一个登录功能”，它马上就能写出接口、页面、状态管理和错误处理。

问题是，它并不知道你真正想要什么。

登录是手机号登录，还是邮箱登录？ 错误提示给用户看，还是只打日志？ 是否要兼容老用户？ 权限信息放在 token 里，还是每次请求后端校验？ 现在项目里有没有已有的登录模块？

这些 问题 没问清楚，代码写得越快，返工越快。

这就是 mattpocock/skills 想解决的问题：不要让 Agent 上来就 改代码。

AI 编程本来该是什么样子

正常的软件工程，本来就不是“想到什么写什么”。

一个靠谱工程师动手前，通常会先做几件事：

这些动作并不新。

过去我们叫它 工程习惯。现在到了 AI 编程时代，它们需要被写成 AI 能执行的流程。

这就是 skills 的价值。

它不是让 AI “更聪明”，而是让 AI “更守规矩”。

它解决的第一个痛点：需求没对齐

grill-me 是这个仓库里最值得先看的 skill。

它的作用不是写代码，而是 追问。你提出一个想法，它会围绕目标、边界、异常情况、依赖关系一直问，直到双方对问题有共同理解。

这听起来有点慢。

但很多 AI 编程的失败，恰恰是因为开始得太快。

你以为自己已经说清楚了，Agent 以为自己已经理解了。等代码生成出来，双方才发现说的不是一回事。

grill-me 像一个刹车。

它提醒你：真正节省时间的，不是少问几个问题，而是少返工几轮。

它解决的第二个痛点：没有反馈回路

tdd 是我最推荐认真读的一个。

很多人让 AI 写代码，是这样用的：

“帮我实现这个功能。”

AI 写完以后，人再去看能不能跑。

这是一种很弱的反馈方式。因为代码看起来对，实际行为却不对。尤其是 复杂业务 里，错误不会马上暴露。

tdd 的思路是反过来：

先写一个失败测试，再写最小实现，让测试通过，然后继续下一个行为。

它强调的不是“多写测试”，而是让 AI 每走一步都有一个清楚的 pass/fail 信号。

这点很关键。

AI 最怕的不是任务难，而是反馈模糊。没有测试、没有命令、没有复现脚本，它只能靠猜。

而一旦有了 反馈回路，它就能在一个更可靠的轨道里工作。

它解决的第三个痛点：调试靠猜

diagnose 也很实用。

很多时候，AI 修 bug 会直接给一个原因：

“可能是状态没有更新。”

“可能是缓存问题。”

“可能是异步顺序导致的。”

这些说法听起来都合理，但合理不代表正确。

diagnose 要求先建立 复现循环，再缩小范围，再提出假设，再加观测，最后修复并补回归测试。

它最重要的一句话可以概括成：

没有可重复的失败信号，就不要开始猜原因。

这也是人类工程师调试时最容易忽略的地方。AI 只是把这个问题放大了。

这件事的本质是什么

mattpocock/skills 的本质，不是提示词工程。

更准确地说，它是在做一件事：

把资深工程师的工作习惯，拆成 AI 可以重复执行的小流程。

以前，工程经验藏在人脑里。

比如什么时候该先问需求，什么时候该写测试，什么时候该停下来整理架构，什么时候不能继续猜。

这些判断，对新人来说很难学，对 AI 来说更难凭空领会。

skills 把这些 判断 显性化。

它告诉 Agent：遇到需求不清，不要写代码，先追问；遇到功能开发，不要一口气写完，先建立测试反馈；遇到 bug，不要猜，先复现。

这就是它比普通 prompt 更有价值的地方。

普通 prompt 像一句提醒。 skill 更像一张 检查清单。

提醒容易被忽略，检查清单可以反复执行。

应该怎么学习和应用

如果你刚开始用 AI 编程，不建议一口气安装所有 skill。

先学三个就够了：

这三个正好对应开发里的三个关键阶段：

开始前，先对齐。 开发中，小步验证。 出问题，建立复现。

你可以这样练习：

第一次，让 AI 用 grill-me 帮你追问一个需求。不要急着写代码，只看它问出了哪些你没想过的问题。

第二次，让 AI 用 tdd 做一个很小的功能。重点不是功能多复杂，而是观察它有没有做到“一条行为、一个测试、一个实现”。

第三次，找一个真实 bug，让 AI 用 diagnose 处理。重点看它有没有先建立复现信号，而不是直接给结论。

举一个更具体的小例子。

假设你在做一个后台管理系统，要加“文章发布权限”。

项目结构可以是这样：

如果不用 skill，你很容易直接对 AI 说：

这句话太宽了。Agent 往往会直接去改页面按钮、接口调用和权限判断，但它不知道真正的 业务规则。

用 grill-me，它应该先问：

这些问题问完以后，需求会变成更清楚的一句话：

只有 editor 和 admin 可以发布文章；前端按钮置灰并提示原因；真正权限判断放在 modules/auth/permissions.ts，页面只调用统一函数。

然后再进入 tdd。

第一条测试可以很小：

这时 Agent 只需要写最小实现：

接着再加页面行为测试、按钮状态、错误提示。每次只推进一个 行为。

如果上线后发现“编辑点发布偶尔失败”，就不要让 AI 直接猜。

用 diagnose，应该先建立复现方式：

或者写一个最小脚本，固定输入用户角色、文章状态、接口返回值，确认失败是否能 稳定出现。

只有复现出来以后，再让 Agent 排查：

这个小例子说明了 skills 的实际用法：

grill-me 负责把需求问清楚。 tdd 负责把需求变成可验证行为。 diagnose 负责在出问题时停止猜测，先建立复现。

这样用几次以后，你会发现自己对 AI 编程的理解会变化。

你不再只是问“AI 会不会写代码”，而是开始问：

我有没有给它一个能正确工作的流程？

需要什么能力，才能看懂它的价值

这个仓库对完全没做过项目的人，一开始不容易看出价值。

因为它解决的不是“怎么让 AI 输出更多代码”，而是“怎么让 AI 少制造错误代码”。

要真正理解它，至少需要一点 工程直觉：

如果你还没有这些经验，也没关系。

可以把它理解成一个很朴素的东西：

这句话对第一次接触 AI 的人也成立。

你可以把 AI 想成一个反应很快的助手。你给它任务，它马上行动。但越是重要的事情，越不能只靠它“感觉懂了”。

你要给它规则、步骤、检查点 和验收方式。

这不是限制 AI。

恰恰相反，这是让 AI 真正变得可用。

最后

mattpocock/skills 给我的最大启发是：

AI 编程真正的门槛，不只是会不会写 prompt，而是能不能把自己的工程经验，拆成 AI 可以执行的流程。

未来优秀工程师做的事，不只是写代码。

还包括写工作流、写约束、写检查清单，让 Agent 在正确的 轨道 里工作。

从这个角度看，mattpocock/skills 不只是一个资源仓库。

它更像一个样板：