Matt Pocock 的 72K Star 技能库 AI 编程高效指南

看完Matt Pocock这套skills，一个核心判断立刻浮现：这并非一组炫技的prompt，也不是为了让AI袋里更“放飞自我”的插件包。恰恰相反，它是一套专门为AI编程“踩刹车”的工程流程。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

如果你正在使用Claude Code、Codex或Cursor，时常感到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的开发者布道师；在投身全职教育之前，他有过全栈技术负责人的经历，并维护过开源项目。

这样的背景，深刻影响了他构建工具的方式。与一些热衷于鼓吹“让Agent更猛”的AI工具作者不同，Matt Pocock的这套skills更像是工程师写给工程师的“工作守则”。它不鼓励你把所有事情丢给AI然后坐等结果，而是将协作拆解为一个个可检查、可控制的环节。

这也正是其理念值得传播之处：它并非空喊“AI将取代程序员”，而是在冷静地指出——AI写代码的速度越快，你就越需要可靠的流程来约束它。

爆火内核：反其道而行的“劝你别急”

当下的AI编程内容，很容易陷入两种叙事：一是模型能力越来越强，二是某个工具又能自动化完成多少任务。

然而，真实开发中最令人头疼的，往往不是“AI不会写”，而是它写得太快，错得也太快。你让它修复一个bug，它可能直接改动组件结构；你让它实现一个权限系统，它可能二话不说开始建表；你让它重构模块，它可能一口气移动几十个文件；你让它依据聊天记录实现需求，它甚至可能把你已经否定的想法也编码进去。

Matt Pocock这套skills的走红，核心不在于名字新奇，而在于它精准命中了AI编程的真实焦虑：我们并不缺少会写代码的智能体，我们缺少的，是一个能防止智能体胡乱编写的工作流。

在GitHub的README中，他将这套工具定位为自己每日用于真实工程项目的智能体技能，并强调它们是“小巧的、可调整的、可组合的”。这句话切中要害。真正能在AI编程中长期落地应用的，并非某种“万能流程”，而是可以根据项目习惯灵活改造的流程积木。

grill-me：需求模糊时，先接受AI的“审问”

如果只能先安装一个，我会首选grill-me。

它的思路直白却有效：当你提出一个需求时，阻止智能体立即执行，而是强制它先向你提出一系列追问。

这听起来有些反直觉。毕竟，很多人使用AI的初衷，是希望它“少问问题，多做事”。但在实际开发中，需求尚未厘清就仓促动手，往往是代价最高昂的。

例如，当你提出：“帮我做一个权限系统。”一个普通的智能体可能立刻开始编写角色表、权限表、接口和中间件。

而更理想的状况是，它应该先追问：是基于角色的访问控制（RBAC），还是基于属性的访问控制（ABAC）？权限控制是施加在接口层、页面层，还是两者都需要？是否涉及多租户？管理员能否跨组织操作？是否需要审计日志？历史数据如何兼容？

这些问题并非在拖慢进度，而是在避免后续的返工。将grill-me用于需求尚未完全固化的阶段，尤其是那种“我大概想做个什么东西”的模糊想法时，其最大价值在于，能迫使你将脑海中的隐性判断显性化。

tdd：别让AI的“自信”代替实际验收

AI写代码最令人头疼的一点在于，它非常擅长把“完成了”说得像真的一样。但项目交付不能依靠语气来验收。

tdd这个技能对AI编程尤其适用，因为它将验证顺序反转了过来：先编写一个会失败的测试来复现问题，再编写实现代码，最后运行测试确保通过。

它适合用于这类任务：“修复订单金额计算错误。先写一个失败测试复现问题，再修改实现。”或者：“为优惠券叠加逻辑补充测试。覆盖满减券、折扣券、不可叠加券三种情况。”

这一步看似增加了前期耗时，实则更节省整体时间。因为业务逻辑最怕的就是“代码改了，但没人确切知道它到底对不对”。测试先行至少为智能体提供了一个明确的目标，也能让你在代码审查时减少依赖直觉。

如果你让Codex、Claude Code等工具修改订单、支付、权限、库存、计费这类核心业务逻辑，建议将tdd置于流程前端。这些关键环节并非不能由AI修改，而是绝不能让它“裸改”。

diagnose：Bug修复，先定位再动手

很多Bug并非难以修复，而是容易修错地方。diagnose的价值在于，要求智能体先诊断问题根源，而不是一上来就直接修改代码。这对于大型项目尤为重要。

例如，页面上一个按钮点击无效，可能的原因包括：前端事件未绑定、参数未正确传递、接口返回错误、权限拦截、状态更新被覆盖、后端字段名变更等。如果智能体一开始就去改动组件，很可能只是侥幸绕过了问题，并未真正修复。

可以这样使用：“先诊断这个Bug。不要直接修改代码。给出最可能的3个原因、验证方法以及你建议优先检查的文件。”待其诊断站得住脚后，再进入实现阶段。

这个技能非常适合与浏览器开发者工具、日志系统、测试命令结合使用。它本质上是在提醒智能体：不要把第一个猜测当作最终结论。这是AI编程中极易被跳过、却最不该省略的一步。

triage：将混乱的Issue转化为可执行任务

triage更偏向团队协作场景，但个人项目同样适用。一个Issue往往不是一个清晰的任务，而可能是一段抱怨、一张截图、几句复现描述，甚至夹杂着评论区的补充信息。此时直接让智能体修改代码，风险极高。

更合理的流程是先进行问题分诊：问题是否可复现？缺少哪些关键信息？影响范围有多大？属于Bug、新需求还是使用问题？应归属到哪个代码模块？是否值得立即处理？

可以这样指令：“读取这个Issue，先进行分诊。输出：问题摘要、复现步骤、缺失信息、可能涉及的模块、建议优先级。不要直接编写代码。”

这个技能的价值不在于生成代码，而在于将混乱的输入转化为可处理的任务。在真实团队中，这一步常常无人愿意承担，因为它不像编写代码那样能立刻带来成就感。然而，它恰恰决定了后续的编码工作是否在解决正确的问题。

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

to-prd建议在复杂功能开发前使用。许多AI协作存在一个通病：前期讨论了半小时，最终落地时却只剩一句“按刚才说的实现”。这非常危险。

聊天记录不是产品需求文档。其中包含了试探、否定、临时起意以及大量的上下文噪音。to-prd的价值，在于将已经讨论清楚的内容，整理成结构化的产品需求文档。

可以要求它输出：项目背景、用户目标、功能范围、非目标（明确不做什么）、交互流程、边界情况、验收标准。

示例指令：“将我们刚才关于会员积分系统的讨论整理成PRD。必须写清楚非目标和验收标准。不要加入任何未讨论过的新功能。”这一步对于复杂功能尤为有用，既能防止智能体在实现过程中“自由发挥”，也能让你在动手前发现：某些细节其实尚未确定。

improve-codebase-architecture：AI越快，架构越需“踩刹车”

对于“让AI重构代码”这件事，一直需要保持谨慎。并非AI不会修改，而是它太容易将重构演变成大规模的文件移动。

improve-codebase-architecture这个技能的方向是正确的：先审视架构边界，再提出改进建议，而非上来就重写。它适用于以下场景：单个文件膨胀过大、模块职责混淆、UI层/业务逻辑层/请求层相互缠绕、多处重复实现同一逻辑、测试难以编写等。

但不应让它一次性修改整个项目。更好的做法是，先指令其输出架构观察报告：“先审查这个模块的架构问题。只输出问题描述、潜在影响、建议的拆分边界。不要修改代码。”确认方向后，再拆分成多个小型拉取请求逐步实施。

AI提升了编码速度，同时也同步放大了糟糕架构扩散的速度。重构最可怕的不是进展缓慢，而是一次改动过多，最终导致无人敢合并。

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

write-a-skill值得单独一提。它虽然不在下文“优先安装6个”的主列表里，但极具保留价值。因为它揭示了一个更深层的理念：如果某类工作你反复进行，就应该将流程沉淀下来。

例如：你的技术文章修订流程、Ja va面试题整理流程、代码审查流程、前端页面验收流程、数据库变更检查流程……这些工作如果每次都靠手动输入prompt，很容易遗漏步骤。将其编写成自定义技能后，就能让智能体按照同一套标准执行。

可以说，skills最有价值的用法，并非“安装别人的”，而是将自己的工作方法固化下来。Matt Pocock这套工具更像一个提醒：你不必完全照搬他的流程，但你应该开始建立并拥有自己的流程。

实战选择：如果是我，会先装这6个

在Matt Pocock这套skills中，如果只优先选择6个安装，可以按以下顺序考虑：

1. grill-me（需求澄清）
2. diagnose（问题诊断）
3. tdd（测试驱动开发）
4. triage（问题分诊）
5. to-prd（需求文档化）
6. improve-codebase-architecture（架构审视）

这个排序并非依据流行度。如果单纯看传播和安装热度，write-a-skill、to-issues、grill-with-docs也都值得关注。但如果目标是让AI编程的结果更稳定、更可靠，那么上述6个技能值得优先配置，因为它们恰好覆盖了从需求澄清、问题诊断、实现验证到架构审视的关键协作环节。

核心洞见：习惯重于工具

Matt Pocock这套skills最值得学习的，并非某一个具体的技能名称，而是其背后蕴含的使用习惯：需求不清楚，先追问；Bug不明确，先诊断；逻辑要修改，先写测试；Issue很混乱，先分诊；复杂功能要做，先转化为PRD；重构要动手，先审视架构边界。

这套协作流程，对于Claude Code、Codex、Cursor等主流AI编程工具同样适用。如果你当前使用AI编程时常感到输出结果“飘忽不定”，那么建议不必急于更换模型，也不必立刻去寻找更“神奇”的prompt。不妨先收紧你的工作流。

很多时候，问题不在于模型不能干活，而在于你没有为它提供一个可靠、可控的干活方式。