题图：Chris Ried via Unsplash
Matt Pocock 大概是 TypeScript 圈最出名的”老师”之一，Total TypeScript 作者。前几天他把自己在 .agents 目录里用的 skills 全部开源了，叫 skills，我点进去的时候已经 198k stars，skills.sh 上显示 49 个 skill、累计安装量 1260 万次。这个量级在工具类仓库里相当夸张。
作者是谁
Matt Pocock，英国程序员，TypeScript 圈子的头部布道者。让他出名的主要是两件事：
- Total TypeScript（totaltypescript.com）：一套讲 TypeScript 的付费课程和免费内容。他在 Twitter/X 上常年发 TypeScript 进阶技巧，很多”看完恍然大悟”类型的梗图和类型体操都出自他，粉丝量在开发者里属于顶流。
- Zod 等库的维护者：他维护过几个前端生态里常用的类型库，社区认可度很高。
这几年他基本全职在做内容和教育：录视频、写教程、维护 AI Hero（他聚焦 AI 编程的教育品牌），这个 skills 仓库就是 AI Hero 体系的落地。他的特点是不追花活，讲东西喜欢落到工程实践上——这跟这次开源的 skills 的风格是一致的。
它是什么
一句话：Matt 每天用 AI 写真实代码时加载的一组 skill 文件，直接从他个人的 agent 配置里拷出来的。封面写着 “Skills for Real Engineers”，副标题 “not vibe coding”。
现在市面上有很多帮 agent 工作流”接管过程”的方案，比如 GSD、BMAD、Spec-Kit。它们的问题是：过程被框架占死了，你想改也改不动，一旦框架本身有 bug 就很难排查。Matt 的选择是反过来——写一堆小、容易改、可以互相组合的 skill，每个 skill 就是一份 markdown 说明，告诉 agent 在某种情况下该怎么做。
核心的几个 skill
/grill-me 和 /grill-with-docs
这两个是他说的最受欢迎的 skill。核心动作是动手之前，逼 agent 反问你。
我们最常见的问题不是 agent 写不出代码，而是它”没搞懂你要什么”就开写。grill 的流程就是让 agent 扮演一个较真的面试官，把你计划里的每个分支都问一遍，直到它（和你）都确认没歧义了再开工。
这个 skill 的实际行为挺讲究，我看了它的实现：
- 一次只问一个问题，等你答完再问下一个，避免一次抛一堆问题把人绕晕。
- 每个问题都带一个推荐答案，不是空问。
- 能查的事实不问你，原文是 “If a fact can be found by exploring the environment, look it up rather than asking me. The decisions, though, are mine”——该 agent 自己翻代码就能确认的事别浪费你时间，只有决策才需要你来拍板。
grill-with-docs 在追问之外会顺手产出一份 CONTEXT.md，记录这个项目里的”行话”。它在 skills.sh 上单 skill 安装量 61 万，仅次于 grill-me 的 72 万。
CONTEXT.md：共享语言
这是我觉得整个仓库里最妙的一个点。agent 刚进项目时不知道怎么称呼各种概念，于是用 20 个词解释本来 1 个词就能说清的东西。
他在示例里给了个对比：
BEFORE: “There’s a problem when a lesson inside a section of a course is made ‘real’ (i.e. given a spot in the file system)”
AFTER: “There’s a problem with the materialization cascade”
后者是你和 agent 共同维护的行话。好处不止省 token：变量、函数、文件名命名更一致，代码更好导航，agent 思考也更省力。这其实就是 DDD 里 ubiquitous language（通用语言）那套，搬给 AI 用。仓库里甚至有个 skill 直接就叫 ubiquitous-language。
CONTEXT.md 不是一句口号，是带约束的词汇表。拿仓库自己的 CONTEXT.md 举例，它对每个术语都写了”用这个词、别用那些词”：
Issue tracker：The tool that hosts a repo’s issues
Avoid: backlog manager, backlog backend, issue host
还专门留了一节 “Flagged ambiguities” 记录历史纠偏，比如之前 “backlog” 一词既指工具又指工作集合，现在统一拆成了 Issue tracker 和 Issue。这种文档就是给 agent 的唯一真相源，防止它每次自己发明叫法。
/tdd 和 /diagnosing-bugs
围绕”反馈循环”做的。agent 产出垃圾代码，很多时候是因为它在瞎写——不知道写出来的东西到底跑没跑起来。tdd skill 让 agent 先写一个会挂的测试，再让它过，红-绿-重构，把反馈节奏固定下来。
细节上它把”seam（接缝）”作为核心概念：测试只写在预先和用户确认过的公共接缝上，别碰内部实现。它还明确列了测试的反模式——水平切片（先把所有测试写完再写实现，测的是”想象中的行为”）、同义反复（断言用跟实现一样的方式重新算一遍期望值，永远不可能失败）。每一条都对应 agent 写测试时最常犯的错。debug 有专门的 diagnosing-bugs 循环：复现 → 最小化 → 假设 → 打点 → 修复 → 回归测试。
/improve-codebase-architecture
针对”一坨屎”的问题。agent 写代码太快，熵增也快，代码库很容易在几周内变成泥球。这个 skill 会扫描代码库、生成一份可视化的 HTML 报告，然后让你挑一处来做深度优化。作者建议每几天跑一次。
它的理论基础是 John Ousterhout《A Philosophy of Software Design》里的 shallow / deep modules（浅模块/深模块）——“好模块是深的，一小段接口后面藏着大量行为”。skill 会找出那些”接口和实现一样复杂”的浅模块，逐个给你列”深化机会”，每个候选配一张 before/after 示意图，最后用 deletion test 判断：删掉这个模块是把复杂度集中了，还是只是挪了个位置。选中的方案再走一遍 grill 流程细化，过程中新概念顺手写进 CONTEXT.md。
安装方式：两种哲学
安装有两条路，代表了两种心态：
- Claude Code 插件：
claude plugins install mattpocock-skills，装完整个集合作为一个只读的托管 bundle，作者更新你自动跟着更。你是在”订阅”。
- skills.sh：
npx skills@latest add mattpocock/skills，把 skill 文件直接拷进你项目里，随便改，改完归你。你是在”fork”。
作者自己的态度很明确：建议你 hack 这些文件，改成自己的。别把它当圣经。这也是整套东西的设计哲学——skills 是给你的起点，不是终点。
写 skill 本身也是门工程
翻仓库时最让我服气的是 writing-great-skills 这个 skill——它不是给人用的工具，而是教 agent 怎么写好 skill 的方法论。开头那句点题：
A skill exists to wrangle determinism out of a stochastic system.
skill 的存在是为了从随机的系统（模型）里挤出确定性。它不求每次输出一样，只求每次走同一个过程。围绕这个目标，它给了一整套写作纪律：
- context load 预算：每个 skill 的 description 常驻在模型窗口里，多一个字都是成本。所以只有需要 agent 主动触发的 skill 才开放给模型调用（model-invoked），纯手工触发的一律禁掉，省下上下文。
- leading words：用模型预训练里已有的概念词当锚点，比如把”快速、确定、低开销”压成一个词 tight，把”一个你信得过的循环”压成 red（变红=出 bug，一个布尔状态）。用最少的词唤醒模型已有的行为习惯。
- 渐进披露：细节往下推到链接文件里，SKILL.md 顶部只留主干，需要时才展开。
- 去 no-op、防 negation：删除”模型本来就会做”的废话（比如 be thorough 不如 relentless）；不要用否定句式，因为”别想大象”反而会让它想到大象，要直接说该做什么。
这套东西把自己当成要维护的代码来写，有命名、有预算、有反模式。我之前一直觉得”skill 不就是一段提示词吗”，看完才意识到写好一段提示词跟写好一段代码是一回事。
另外它不只有工程 skills。49 个 skill 里有写文章的（writing-shape、writing-beats）、教东西的（teach）、做手记交接的（handoff）、甚至连 caveman 这种不正经名字的都有。这跟 Matt 现在的身份一致——他做内容、做教育，不纯写代码。
我的看法
这套东西本质上不是新发明，它是在把《程序员修炼之道》《领域驱动设计》《A Philosophy of Software Design》里那套老原则，翻译成 agent 能照着执行的动作。它火，不是因为创造了新概念，而是因为终于有人把”怎么跟 AI 协作”这件事，按工程方法而不是玄学来做了。1260 万次安装量也说明这不是自嗨，是真有人拿它干活。
说几个我觉得值得借鉴的点：
- 把隐性知识显性化。共享语言、ADRs、spec、tickets，都是把散落在对话里的决定落成文档。
- 过程可控。框架接管 vs 一堆可组合的小规则，后者的可调试性高一个量级。这也解释了我为什么一直对”全自动流程”持保留态度。
- 强调反馈。没有反馈的 agent 和没有测试的程序员一样，都是瞎写。
要说局限：这套 skill 是 Matt 给自己写的，针对他熟悉的 TS 技术栈和工程习惯，照搬不一定适合所有人。而且它默认 agent 有很强的推理能力，弱模型跑这套流程效果会打折扣。另外 skill 本身只是提示词，质量上限还是取决于底层模型。
无论如何，198k stars 说明很多人和 Matt 有同样的困惑：AI 写代码越来越快，但”怎么让它写对”越来越难。把工程纪律教给 agent，这个方向我认。
链接
