Matt Pocock开源AI编程Skills，规范需求、测试与排错流程
如果你写 TypeScript，多半见过 Matt Pocock 这个名字。
他是 Total TypeScript 的创始人，长期做开发者教育，也曾在 Vercel 工作。最近，他把自己平时使用的 AI 编程流程整理成了一套开源 Skills。
这些 Skills 做的事情很具体：把需求澄清、测试、排错和架构检查重新放回 AI 编程流程。
用 AI 写代码，最让人头疼的是它开工太快。需求还有歧义，它已经建好文件；报错刚出现，几个地方先被改了一遍；测试没跑，代码已经铺出去几千行。进度看起来飞快，收尾时却可能要花更多时间拆雷。
Matt 这套 Skills，主要管的就是这些事。
/grill-me
开工前先不让 AI 写代码，让它围着需求继续追问。哪些条件还模糊，边界在哪里，有哪些决定其实还没做，都先聊清楚。省得做到一半才发现，双方一开始理解的就不是同一件事。
/grill-with-docs
一边澄清需求，一边把项目术语、背景和关键决定写进文档。之后换窗口或重开一轮对话，也不用从头解释上下文。
/tdd
按红—绿—重构推进：先写一个会失败的测试，再做刚好够用的实现，通过后再整理代码。这样测试是在约束实现，不是等代码写完后才补几条很难失败的用例。
/diagnosing-bugs
看到报错先别乱改。先复现，缩小范围，列出假设，补充观测；确定原因后再动代码，最后加回归测试。可以少掉很多“这里改一下试试”的碰运气式排错。
/improve-codebase-architecture
扫描那些反复被改、耦合重、难测试的区域，帮你判断重构应该先动哪里。比起看到哪段代码不顺眼就重写，这种做法更适合真实项目。
/caveman
嫌 AI 说话太绕就用这个。客套和重复解释会被删掉，只留下结论、证据和下一步。
这些方法并不新鲜。需求澄清、TDD 和系统排错，本来就是软件工程的基本功。实用之处在于，它们现在被写成了 AI 必须遵守的步骤，不再只靠你临场提醒。
安装命令：
npx skills@latest add mattpocock/skills
GitHub：
https://t.co/fH0KRXQYvS
如果只想先试一个，我建议从 /grill-with-docs 开始，尤其适合需求还比较模糊、后续又会反复迭代的任务。它既能把问题聊清楚，也会留下下一轮还能继续使用的文档。
他是 Total TypeScript 的创始人，长期做开发者教育，也曾在 Vercel 工作。最近，他把自己平时使用的 AI 编程流程整理成了一套开源 Skills。
这些 Skills 做的事情很具体：把需求澄清、测试、排错和架构检查重新放回 AI 编程流程。
用 AI 写代码，最让人头疼的是它开工太快。需求还有歧义，它已经建好文件；报错刚出现，几个地方先被改了一遍；测试没跑，代码已经铺出去几千行。进度看起来飞快，收尾时却可能要花更多时间拆雷。
Matt 这套 Skills，主要管的就是这些事。
/grill-me
开工前先不让 AI 写代码，让它围着需求继续追问。哪些条件还模糊，边界在哪里，有哪些决定其实还没做，都先聊清楚。省得做到一半才发现，双方一开始理解的就不是同一件事。
/grill-with-docs
一边澄清需求，一边把项目术语、背景和关键决定写进文档。之后换窗口或重开一轮对话，也不用从头解释上下文。
/tdd
按红—绿—重构推进：先写一个会失败的测试，再做刚好够用的实现，通过后再整理代码。这样测试是在约束实现，不是等代码写完后才补几条很难失败的用例。
/diagnosing-bugs
看到报错先别乱改。先复现，缩小范围，列出假设，补充观测；确定原因后再动代码，最后加回归测试。可以少掉很多“这里改一下试试”的碰运气式排错。
/improve-codebase-architecture
扫描那些反复被改、耦合重、难测试的区域，帮你判断重构应该先动哪里。比起看到哪段代码不顺眼就重写，这种做法更适合真实项目。
/caveman
嫌 AI 说话太绕就用这个。客套和重复解释会被删掉，只留下结论、证据和下一步。
这些方法并不新鲜。需求澄清、TDD 和系统排错，本来就是软件工程的基本功。实用之处在于，它们现在被写成了 AI 必须遵守的步骤，不再只靠你临场提醒。
安装命令：
npx skills@latest add mattpocock/skills
GitHub：
https://t.co/fH0KRXQYvS
如果只想先试一个，我建议从 /grill-with-docs 开始，尤其适合需求还比较模糊、后续又会反复迭代的任务。它既能把问题聊清楚，也会留下下一轮还能继续使用的文档。