AI 编程先别急着改代码：7.2 万 Star 的 Matt Pocock Skills，太强了

如果你现在用 Claude Code、Codex、Cursor，经常觉得 AI 写代码“看起来很快，合起来很虚”，我建议先别急着换模型。

先把工作流补上。

Matt Pocock 这套 skills，我看完后的第一判断是：它不是一组炫技 prompt，也不是让 Agent 更会“自由发挥”的插件包，而是一套专门给 AI 编程踩刹车的工程流程。

截至 2026 年 5 月 12 日，https://github.com/mattpocock/skills 在 GitHub 上已经约 7.2 万 Star、6.2k Fork。这个数字足够吸引人，但我真正关心的不是它火了，而是它为什么会火。

因为它把 AI 编程里最容易被忽略的几件事重新摆上桌面：

需求没讲清，先问。
bug 没定位，先诊断。
逻辑要修改，先写测试。
功能要落地，先写 PRD。
代码要重构，先看边界。

这比“再给我生成一个更强 prompt”更有价值。

Matt Pocock 不是普通的 AI 工具博主

Matt Pocock 值得单独介绍一下。

他在前端圈更早是因为 TypeScript 被很多人认识。GitHub 个人主页里，他的介绍是 TypeScript 方向的教育者，正在做 Total TypeScript，过去在 Vercel 和 Stately 工作过。

Total TypeScript 官网里对他的介绍更完整：他曾经是 XState 核心团队成员，也做过 Vercel 的 Developer Advocate；在做全职教育之前，他当过 lead fullstack developer，也维护过开源库。

这类背景会直接影响一个人做工具的方式。

有些 AI 工具作者喜欢强调“让 Agent 更猛”。Matt Pocock 这套 skills 更像工程师写给工程师的工作规矩。它不鼓励你把所有事情丢给 AI 后等结果，而是把协作拆成一个个可检查的环节。

这也是我觉得它适合传播的地方。

它不是在喊“AI 要取代程序员”，而是在说：AI 写代码越快，你越需要流程把它管住。

这套 Skills 的爆点，是反着劝你别急

现在 AI 编程内容很容易写成两类。

一类是模型越来越强。
一类是某个工具又能自动干多少事。

但真实开发里，最痛的往往不是“AI 不会写”，而是它写得太快，错得也太快。

你让它修一个 bug，它可能直接改组件。
你让它做一个权限系统，它可能直接建表。
你让它重构一个模块，它可能一口气移动几十个文件。
你让它根据聊天记录实现需求，它可能把你已经否掉的想法也写进去。

Matt Pocock 这套 skills 火起来，核心不是名字新，而是它抓到了 AI 编程的真实焦虑：

我们不缺会写代码的 Agent。
我们缺的是一个让 Agent 不乱写的工作流。

GitHub README 里，他把这套东西定位为自己每天用于真实工程的 agent skills，并且强调它们是小的、可调整的、可组合的。

这句话我很认同。

AI 编程真正能长期用下去的，不是“万能流程”，而是你可以按项目习惯改造的流程积木。

grill-me：需求不清楚时，先让 AI 审问你

如果只让我先装一个，我会先装 grill-me。

它的思路很简单：当你提出一个需求时，不让 Agent 马上执行，而是让它先追问你。

这听起来有点反直觉。

很多人用 AI，是希望它“少问点，直接做”。但真实开发里，需求没问清楚就直接做，往往是最贵的。

比如你说：

帮我做一个权限系统。

一个普通 Agent 可能直接开始写角色表、权限表、接口和中间件。

但我更希望它先问：

• 是 RBAC，还是 ABAC？
• 权限控制在接口层、页面层，还是两边都要？
• 是否有多租户？
• 管理员能不能跨组织操作？
• 是否需要审计日志？
• 老数据怎么兼容？

这些问题不是拖慢进度。

它们是在避免后面返工。

我会把 grill-me 用在需求还没有定型的时候，尤其是那种“我大概想做一个什么东西”的需求。它最大的价值，是把你脑子里的模糊判断逼出来。

tdd：别让 AI 用自信代替验收

AI 写代码最麻烦的一点是：它很会把“完成了”说得像真的。

但项目不能靠语气验收。

tdd 这个 skill 对 AI 编程特别适合，因为它把验证顺序反过来了：先写失败测试，再写实现，再跑测试通过。

我会在这类任务里用它：

修复订单金额计算错误。
先写一个失败测试复现问题，再改实现。

或者：

给优惠券叠加逻辑补测试。
覆盖满减券、折扣券、不可叠加券三种情况。

这一步看起来慢，实际更省时间。

因为业务逻辑最怕的是“代码改了，但没人知道到底对不对”。测试先行至少能给 Agent 一个明确靶子，也能让你在 review 时少靠感觉。

如果你让 Codex、Claude Code 改订单、支付、权限、库存、计费这类逻辑，我建议把 tdd 放在前面。

这些地方不是不能让 AI 改。

是不能让 AI 裸改。

diagnose：bug 先定位，再允许它动手

很多 bug 不是难修，而是容易修错地方。

diagnose 的价值，是要求 Agent 先诊断问题，而不是上来就改代码。

这对大项目尤其重要。

比如页面上一个按钮不生效，原因可能是：

• 前端事件没绑定
• 参数没传
• 接口返回错误
• 权限拦截
• 状态更新被覆盖
• 后端字段名变了

如果 Agent 一上来就改组件，很可能只是碰巧绕过问题，没有真正修掉。

我会这样用：

先诊断这个 bug。
不要直接修改代码。
给出最可能的 3 个原因、验证方式和你建议先查的文件。

等它的诊断站得住，再进入实现。

这个 skill 很适合和浏览器工具、日志、测试命令一起用。它本质上是在提醒 Agent：不要把第一个猜测当结论。

这也是 AI 编程里很容易省掉、但最不该省的一步。

triage：把混乱 Issue 变成可执行任务

triage 更偏团队协作，但我觉得个人项目也能用。

一个 Issue 经常不是一个清楚任务，而是一段抱怨、一张截图、几句复现描述，甚至还有评论区里的补充信息。

这时候直接让 Agent 改代码，风险很高。

更合理的流程是先 triage：

• 问题是否可复现
• 缺哪些信息
• 影响范围是什么
• 是 bug、需求，还是使用问题
• 应该归到哪个模块
• 是否值得现在处理

我会这样用：

读取这个 Issue，先做 triage。
输出：问题摘要、复现信息、缺失信息、可能模块、建议优先级。
不要直接写代码。

这个 skill 的价值不是生成代码，而是把混乱输入变成可处理任务。

在真实团队里，这一步经常没人愿意做，因为它不像写代码那么有成就感。

但它决定后面写代码是不是在解决正确的问题。

to-prd：别把半小时聊天当需求文档

to-prd 我会放在复杂功能前面。

很多 AI 协作会有一个问题：前面聊了半小时，最后真正落地时，只剩下一句“按刚才说的实现”。

这很危险。

聊天记录不是 PRD。它里面有试探、有否定、有临时想法，也有很多上下文噪音。

to-prd 的价值，是把已经讨论清楚的内容整理成产品需求文档。

我会要求它输出：

• 背景
• 用户目标
• 功能范围
• 非目标
• 交互流程
• 边界情况
• 验收标准

示例：

把我们刚才关于会员系统的讨论整理成 PRD。
必须写清楚非目标和验收标准。
不要加入没有讨论过的新功能。

这一步对复杂功能特别有用。

它能防止 Agent 在后面实现时自由发挥，也能让你在动手前发现：有些地方其实还没有定。

improve-codebase-architecture：AI 越快，架构越要踩刹车

我对“让 AI 重构代码”一直比较谨慎。

不是因为 AI 不会改，而是它太容易把重构变成大面积移动文件。

improve-codebase-architecture 这个 skill 的方向是对的：先看架构边界，再提出改进，而不是上来就重写。

我会把它用于这些场景：

• 一个文件越来越大
• 模块职责混在一起
• UI、业务逻辑、请求层互相缠绕
• 多个地方重复实现同一套逻辑
• 测试很难写

但我不会让它一次性改完整个项目。

我会先让它输出架构观察：

先审查这个模块的架构问题。
只输出问题、影响、建议拆分边界。
不要改代码。

确认方向后，再拆成小 PR。

AI 提升了写代码的速度，也会同步放大坏架构扩散的速度。重构最怕的不是慢，而是一次改太多，最后没人敢合。

write-a-skill：进阶价值是沉淀你自己的流程

write-a-skill 我会单独提一下。

它不在我这篇“先装 6 个”的主表里，但它很值得保留。

因为它提醒了一件事：如果某类工作你反复做，就应该把流程沉淀下来。

比如：

• 我的公众号文章改稿流程
• 我的 Java 面试题整理流程
• 我的 PR review 流程
• 我的前端页面验收流程
• 我的数据库变更检查流程

这些东西每次靠 prompt 手打，很容易漏。

写成 skill 后，就能让 Agent 按同一套标准执行。

对我来说，skills 最有价值的用法不是“装别人的”，而是把自己的工作方法固化下来。

Matt Pocock 这套 skills 更像一个提醒：你不一定要照抄他的流程，但你应该开始拥有自己的流程。

如果是我来装，会先选这 6 个

Matt Pocock 这套 skills 里，如果只让我先选 6 个，我会这样排：

这个排序不是按热度排。

如果纯看传播和安装热度，write-a-skill、to-issues、grill-with-docs 也都值得看。

但如果目标是让 AI 编程结果更稳，我会先装上面这 6 个。因为它们刚好覆盖了从需求、诊断、实现、验证到架构的关键环节。

最后我的判断

Matt Pocock 这套 skills 最值得学的，不是某一个 skill 名字。

而是它背后的使用习惯。

需求不清楚，先问。
bug 不明确，先诊断。
逻辑要修改，先写测试。
Issue 很混乱，先 triage。
复杂功能要做，先转 PRD。
重构要动手，先看架构边界。

这套流程对 Claude Code、Codex、Cursor 都适用。

如果你现在用 AI 编程经常觉得结果飘，我建议先别急着换模型，也别先去找更神的 prompt。

先把工作流收紧。

很多时候，模型不是不能干活，而是你没有给它一个可靠的干活方式。

最后推荐一下我再使用的 Unity2.Ai 中转。它支持标准 OpenAI 和 Anthropic 格式，接插件、IDE 和各类现成工具会比较省事，适合想尽快跑起来的人。注册地址：https://unity2.ai/register?ref=TvkMJGTU&source=wechat。

注册后新增 codex 分组的 apikey 即可。