Matt Pocock 是谁他为什么会做这件事如果你在 TypeScript 圈混过大概率知道他。Total TypeScript 的作者YouTube 频道超过 10 万订阅被社区称为TypeScript 布道者。他不是那种喜欢蹭热点写博客的人——在这个仓库之前你几乎找不到他专门写 AI 工具使用技巧的内容。2026 年 4 月 28 日他把一个仓库推上了 GitHub标题只有一句话Skills for Real Engineers. Straight from my .claude directory.没有博客没有 YouTube 视频没有 Hacker News 帖子。就这么推了出去。24 小时后22000 星。第六天持续登上 GitHub Trending 全球第二。截止目前85800 星7400 个 fork。这是一个在 AI 工具圈很少见的数字——因为大多数prompt 技巧仓库的生命周期通常以周为单位而这个还在持续增长。这种有机生长的背后说明社区踩到了同一个痛点。他说的不是 vibe coding到底是什么意思Vibe coding 这个词现在有点被滥用了但 Matt 想说的很具体让 AI 自由发挥你只是在验收结果——这不是工程是赌博。他的仓库 README 里列了四类常见失败模式我觉得说得相当准失败模式一意图对齐失败。你心里有一个设计agent 心里有另一个设计双方都以为在说同一件事。等代码跑出来才发现南辕北辙。这不是 Claude 的问题是你没有在开始编码之前把需求逼得足够清晰。失败模式二缺乏领域语言反复解释同一件事。每次新开一个对话窗口你都要重新解释我们的项目里 X 是什么意思。积少成多token 浪费是小事命名不一致才要命。失败模式三没有反馈回路靠直觉走。没有测试驱动agent 写代码的方向就像蒙眼走路。它以为过了你以为过了上线了才知道没过。失败模式四架构腐化是个缓慢的过程人感受不到。AI 加速了代码生成也加速了技术债积累。没有定期的架构审视机制六个月后回来看自己的仓库会不认识。这四个失败模式不是 AI 时代的新问题它们本质上是软件工程里从来没解决好的老问题只是 AI 让它们的代价来得更快了。Matt 的 Skill 仓库就是他用来把这四个问题系统性地塞进日常工作流的方式。仓库里有什么18 个 Skill 的全貌仓库里的 Skill 分三类我按实用程度排一下工程类10 个核心中的核心Skill一句话说清楚它干嘛/tdd强制红绿重构循环一次只写一个测试/diagnose六阶段调试法从复现到事后复盘/grill-with-docs拷问你的设计同时更新 CONTEXT.md 和 ADR/grill-me穷举决策树开始编码前逼你想清楚/to-prd把对话上下文转成带 User Story 的 PRD/to-issues把 PRD 拆成可独立执行的竖切 GitHub Issue/triage状态机驱动的 Issue 分类/improve-codebase-architecture定期识别模块边界腐化提炼共享语言/zoom-out让 agent 在陌生代码里先建立系统级理解/prototype快速脏原型终端应用或 UI 变体效率类4 个省 token 省脑力Skill一句话说清楚它干嘛/caveman极度压缩通信token 减少约 75%/grill-me同上设计审查专用入口/handoffagent 换窗口时生成紧凑的上下文摘要/write-a-skill写新 Skill 的 Skill元层杂项4 个git-guardrails拦截危险 git 操作、migrate-to-shoehorn类型断言迁移、scaffold-exercises练习脚手架、setup-pre-commitHusky lint-staged 初始化。装这整套的命令npx skillslatest add mattpocock/skills然后在项目里跑一次/setup-matt-pocock-skills它会问你用 GitHub Issues 还是 Linear问你文档放哪儿问你想激活哪几个 Skill——配置完之后你就有了一套相对完整的工程脚手架。图四类 AI 编程失败模式与对应 Skill 的映射关系值得反复用的 Skill拆开来看看我把其中几个用了一段时间说说真实感受。/grill-me编码前最重要的一步这是整套里我用得最多的一个。本质上很简单你把计划告诉 agent它开始穷举追问你直到双方对需求达成精确共识。第一次用的时候agent 连续问了我 38 个问题。你可能觉得这听起来很烦但我第一次真正意识到那 38 个问题里有将近一半是我从来没有认真想过的边界情况。错误处理怎么设计、第三方集成失败的回退逻辑、用户数据隔离的粒度——这些我都以为自己大概想清楚了实际上完全没有。/grill-me把这个幻觉确认的过程强制外显。你不得不把模糊的想法变成能被质疑的具体描述。一个实用的使用姿势不要在「我想做什么」阶段用它要在「我已经有了第一版方案」之后再用。带着具体的设计去让它质疑比带着模糊想法去让它帮你发散效率高得多。/tdd一次只前进一步TDD 这件事大家都知道但用 AI 做 TDD 和传统 TDD 有个不小的差异agent 天然倾向于一次性写完所有测试然后再一次性实现然后你发现测试验证的是想象中的行为而不是实际需求。/tdd的核心约束只有一条一次只写一个测试写完了才能动实现代码。Skill 里还有几个具体规则我觉得很有价值测试只通过公共接口验证行为不验证内部实现细节重构只发生在所有测试绿了之后绝对不在红灯状态下重构代码只写刚好让当前测试过的最少量——不多写一行这三条规则约束的不只是 Claude同样在约束你自己。你被迫慢下来一次处理一件事而不是用差不多应该行的感觉把一大段代码推进去。/diagnose你永远不会再靠直觉排查 Bug这个 Skill 解决的是一个很具体的问题我们的 Bug 排查往往是跳跃的先试试 A不行再试试 B既没有可复现的信号也没有系统化的假设。/diagnose强制走六个阶段建立反馈回路先构造一个快速、确定性的 pass/fail 信号自动化测试 / HTTP 脚本 / CLI 命令没有这个信号就不开始排查复现确认失败表现和用户描述一致形成假设列出 3-5 个可证伪的假设每个假设预测一个具体现象工具化为每个假设打上有唯一 tag 的日志[DEBUG-a4f2]这种方便后期清理修复 回归测试在正确的架构层写测试先看它红修复后看它绿清理 事后复盘删掉调试日志记录哪个架构改动能预防类似问题这套流程和 Google SRE 的事后分析文化很接近但压缩成了一个可以随时触发的 Skill。真正按这个流程走一遍之后你会发现自己之前大量时间浪费在了没有信号的蒙眼猜测上。/to-issues竖切而不是横切这个 Skill 帮你把 PRD 拆解成 GitHub Issue但它有一个核心观点一定要竖切不要横切。横切是这样的先建一个设计数据库 Schema的 Issue再建写 API再建做前端——每个 Issue 只覆盖一个技术层依赖关系是串行的任何一层卡住全盘停。竖切是另一种逻辑一个 Issue 应该穿透所有层Schema API 前端 测试完成后是一个端到端可验证的功能切片——薄但完整。/to-issues还会把每个 Issue 打上标签HITLHuman In the Loop需要人来做决定agent 不能独立完成AFKAway From Keyboard可以完全交给 agent 跑人去喝杯咖啡这个分类很有意思它迫使你在规划阶段就想清楚哪些决策不能外包给 AI。一个工程师的真正收获是思维框架而不是快捷键用了一段时间之后我的感受是Matt 的 Skill 仓库最有价值的不是那 18 个/命令而是它背后的设计哲学。每个 Skill 的背后都有一个工程原则/grill-me来自传统的需求澄清会议只是把它外包给了 AI/tdd来自 Kent Beck 的极限编程只是把约束显式化/diagnose来自科学方法论只是适配了软件调试场景/to-issues来自 John Ousterhout 的Deep Module理论以及敏捷开发的竖切原则这些都不是新东西。新的是把它们打包成 Skill让 AI 在每次执行时自动执行这些约束——哪怕你累了、哪怕你在赶 deadline。还有一件事我觉得被忽视了CONTEXT.md这个概念。每个项目维护一个领域词汇表把项目里那些说起来要解释半天的概念定义清楚。Matt 举的例子是与其每次说把一个课程分配到文件系统里的实际位置不如定义一个词叫materialization cascade之后 agent 和人说话都用这个词。这个思路直接来自 DDD 里的统一语言Ubiquitous Language。在 AI 协作场景里它有额外的价值减少 token 消耗同时让命名在整个项目里保持一致。这套方法的局限在哪里说公道话这套 Skill 的适用场景是有边界的。它最适合已经有工程化基础的项目。如果你在做原型验证需求每三天变一次强行套 PRD → Issues → TDD 流程只会让你痛苦。Vibe coding 在这个阶段不是坏事是合理选择。它假设你用 GitHub 作为 Issue Tracker。triage、to-issues 这些 Skill 深度绑定 GitHub Issues 的工作流用 Linear 或 Jira 的团队需要自己改造。/grill-me的成本比你想象的高。38 个问题不是个玩笑。如果你在一个节奏很快的团队里每个功能开始前都要做这个流程会遭到抵触。更实际的做法是只对高风险、高耦合的功能模块使用小改动跳过。Skill 本身不等于能力。装了/tdd不会让你自动变成 TDD 高手。如果你对测试驱动开发没有基本的理解Skill 只是给你一个形式填不进去真正的内容。这和学设计模式是一样的道理。常见问题