13 万星的反 vibe coding 技能库：Matt Pocock 的 skills 为什么值得工程团队研究？
AI 编程真正的分水岭，不是“能不能让 Agent 写代码”，而是“能不能让 Agent 按真实工程纪律工作”。
这两年，AI Coding Agent 的热度已经不需要再解释。
Claude Code、Codex CLI、Cursor、Gemini CLI、各种本地 Agent 框架，都在把“写代码”变成一件越来越便宜的事情。
但便宜也带来了一个新问题：
代码生成变快了，工程失控也变快了。
很多团队已经感受到这种矛盾：
Agent 能很快写出一堆代码，但不一定理解你真正想要什么；
Agent 能补很多测试，但测试可能全都绑在实现细节上；
Agent 能修 bug，但常常是猜测式修改；
Agent 能快速堆功能，但几轮之后代码库就变成一团泥；
Agent 能看懂很多文件，但项目里的业务语言、历史决策、架构约束，它未必真的懂。
最近 GitHub 上有一个项目非常火：mattpocock/skills。
项目地址：
https://github.com/mattpocock/skills[1]
截至 2026 年 6 月，这个仓库已经超过 13 万 Star，Fork 超过 1.1 万。它的作者是 Matt Pocock，TypeScript 社区非常有影响力的工程师和教育者，也是 Total TypeScript 背后的核心人物。
这个项目的 README 一开头就说得很直接：
Skills for Real Engineers.
My agent skills that I use every day to do real engineering - not vibe coding.
翻译过来就是：
给真实工程师用的 Skills。不是 vibe coding，而是真实工程实践。
这句话是理解这个项目的关键。
它不是一个“让 AI 更会写代码”的技巧合集，而是一套试图把真实工程纪律塞进 Coding Agent 的技能系统。
一、它到底是什么？
mattpocock/skills 是一组面向 Claude Code、Codex 等 Coding Agent 的工程技能库。
官方描述是：
Skills for Real Engineers. Straight from my .claude directory.
也就是说，这不是一个为了流量临时包装出来的 Prompt 合集，而是作者从自己日常 .claude 工作目录里抽出来的真实使用技能。
仓库核心数据如下：
GitHub：
mattpocock/skillsStar：约 134,713
Fork：约 11,679
License：MIT
创建时间：2026-02-03
最近推送：2026-06-18
主要语言：Shell
最新版本：
1.0.1安装方式：
npx skills@latest add mattpocock/skills
它当前通过 .claude-plugin/plugin.json 对外暴露 17 个主技能，分为两大类：
Engineering：工程开发技能；
Productivity：通用生产力技能。
此外仓库中还有 misc、personal、in-progress、deprecated 等目录，但真正推荐安装和使用的是 plugin.json 中列出的主技能。
二、它为什么会火？
表面看，这是一个 Skills 仓库。
深一点看，它击中了 AI 编程最核心的痛点：
Agent 不缺写代码能力，缺工程约束。
很多 AI Coding 工具的默认体验，是把 Agent 当成一个很快的初级程序员：你告诉它需求，它就开始改文件、跑命令、修报错。
但真实工程不是这样。
真实工程需要：
对齐需求；
澄清领域语言；
保留架构决策；
小步验证；
测试驱动；
诊断而不是猜测；
设计深模块；
拆出可独立交付的问题；
让下一个 Agent 能接手上下文。
mattpocock/skills 的价值，就是把这些工程纪律拆成可复用的 Skills。
它不是让 AI “更聪明”，而是让 AI 更守规矩。
三、项目的核心思想：反 vibe coding
什么是 vibe coding？
简单说，就是靠感觉驱动 AI 写代码：
“大概帮我做一下这个功能。”
“报错了，你修一下。”
“看起来差不多，继续。”
这种方式在 Demo 阶段很爽，但进入真实项目就会暴露问题。
Matt Pocock 的判断是：
软件工程基本功比以往任何时候都更重要。
因为 Agent 放大了你的工程习惯。
你的流程严谨，Agent 会放大严谨。
你的流程混乱，Agent 会放大混乱。
所以这个项目的目标，不是把 Agent 变成一个“随叫随到的代码生成器”，而是把它纳入一个更可靠的工程工作流。
四、它解决了 AI Coding 的四个典型失败模式
README 里把项目的出发点讲得很清楚：作者想修复 Claude Code、Codex 和其他 Coding Agent 的常见失败模式。
1. Agent 没理解你真正想要什么
这是最常见的问题。
你以为自己讲清楚了，Agent 也表现得像听懂了。结果它写完之后，你才发现方向完全不对。
原因很简单：
人自己也未必一开始就知道自己真正想要什么。
这个项目的解法是 grilling session，也就是让 Agent 在开工前先猛烈追问你。
对应技能是：
/grill-me/grill-with-docs
它们不是马上执行任务，而是先问问题，把计划、约束、边界、分支决策都逼出来。
这点非常关键。
很多人用 AI 写代码失败，不是模型不行，而是开工太早。
2. Agent 太啰嗦，项目语言不统一
Agent 第一次进入一个项目，经常不知道项目里的业务术语。
它会用很长的话解释一个团队内部早就有名字的概念。更糟糕的是，它可能每次都用不同的词，导致代码命名、文档描述、Issue 拆分全部不一致。
Matt 的解法是建立 shared language，也就是共享语言。
对应技能是：
/domain-modeling/grill-with-docs
它会维护 CONTEXT.md，记录项目中的领域术语、关系和歧义。
这和领域驱动设计里的 ubiquitous language 很接近。
一个简单例子：
如果项目里已经把某个过程叫做 “materialization cascade”，Agent 就不应该每次都用二十个词重新描述它。
共享语言的价值不仅是省 token，更重要的是：
函数命名更一致；
文件结构更容易导航；
Agent 更少误解业务概念；
后续会话可以继承更稳定的上下文。
3. Agent 写出来的代码不能工作
很多 Agent 会生成看似完整的代码，但运行起来才发现：测试不对、边界没处理、实现和需求有偏差。
项目给出的核心解法是：反馈循环。
尤其是：
类型检查；
浏览器访问；
自动化测试；
red-green-refactor。
对应技能是：
/tdd/diagnosing-bugs
这里的 TDD 不是“先把所有测试写完，再让 AI 实现”。
它明确反对这种 horizontal slicing。
正确方式是 vertical slice：
一个测试 → 一个实现 → 再下一个测试 → 再下一个实现
这很像 tracer bullet：用一条小的端到端路径证明方向是对的，然后逐步扩展。
这对 Coding Agent 特别重要，因为 Agent 很容易“想象”一个不存在的系统，然后一次性写出一堆并不贴合真实代码的测试。
4. 代码库变成一团泥
AI 写代码太快，会加速软件熵增。
一个原本还算清楚的代码库，经过几轮 Agent 修改后，很容易出现：
浅模块太多；
接口和实现一样复杂；
为了测试抽出一堆没有真实边界的纯函数；
模块之间耦合越来越深；
代码看起来有结构，实际上很难改。
这个项目的解法是强调 codebase design。
对应技能是：
/codebase-design/improve-codebase-architecture
其中 /improve-codebase-architecture 会扫描代码库，找出可以“加深模块”的机会，并生成一个可视化 HTML 报告。
它借鉴了 John Ousterhout《A Philosophy of Software Design》里关于 deep module 的思想：
好模块应该用简单接口隐藏大量复杂行为。
这点非常适合 AI 时代。
因为对 Agent 来说，越清晰、越深的模块，越容易理解和修改；越碎、越浅的模块，越容易让 Agent 在文件之间迷路。
五、最重要的设计：User-invoked 与 Model-invoked
这个项目有一个很值得学习的设计：
它不再简单区分“命令”和“技能”，而是按调用方式分为两类：
User-invoked：只能由人显式调用；
Model-invoked：人可以调用，模型也可以在合适场景自动调用。
这比普通 slash command 设计更精细。
User-invoked：人来启动流程
这类技能通常是编排型流程，比如：
/ask-matt/grill-with-docs/triage/improve-codebase-architecture/setup-matt-pocock-skills/to-issues/to-prd/prototype/grill-me/handoff/teach
它们往往会影响流程方向、写入外部系统、生成文档或改变项目结构，所以必须由人明确触发。
Model-invoked：模型可自动调用的纪律
这类技能是可复用的工程纪律，比如：
/diagnosing-bugs/tdd/domain-modeling/codebase-design/grilling
它们可以被模型在合适任务里自动拿出来用。
例如，当用户说“这个 bug 很难复现”时，模型可以自动进入 diagnosing-bugs 的诊断循环；当用户要求 test-first 时，模型可以自动调用 tdd。
这个划分非常有启发。
它避免了两种极端：
所有技能都必须人工调用，模型不会主动使用；
所有技能都可自动触发，导致流程失控。
它给 Skills 设计提供了一个很好的治理原则：
编排流程由人启动，专业纪律由模型自动复用。
六、核心技能拆解
1. ask-matt：技能路由器
ask-matt 是一个入口技能。
当你不知道该用哪个技能时，可以先问它。
它相当于这个技能库的路由器，帮你判断当前场景应该进入哪个流程。
这对大技能库很重要。
因为当技能越来越多，用户最大的问题会变成：
我现在该用哪一个？
2. grill-with-docs：开工前的深度追问
这是这个项目最有代表性的技能之一。
它做两件事：
通过 grilling session 把需求问清楚；
同步更新项目文档，包括
CONTEXT.md和 ADR。
也就是说，它不是一次普通访谈，而是把对齐过程沉淀成长期上下文。
这解决了 Coding Agent 的一个大问题：每次对齐完就丢，下一次又重新解释。
3. domain-modeling：让 Agent 学会项目语言
这个技能负责维护项目领域模型。
它会：
挑战模糊术语；
识别术语冲突；
用具体场景测试概念边界；
必要时更新
CONTEXT.md；对重大架构/领域决策创建 ADR。
这对长期项目非常关键。
AI 工程协作不是一次性生成代码，而是持续理解一个业务系统。
没有领域语言，Agent 就只能靠猜。
4. tdd：适合 Agent 的测试驱动开发
tdd 技能明确强调：测试应该验证行为，而不是实现细节。
它反对一次性批量写测试，主张一条 vertical slice 一条 vertical slice 地推进。
它的核心循环是：
RED：写一个失败测试 GREEN：写最少代码让它通过 REFACTOR：在绿灯下重构
这对 Agent 非常重要。
因为 Agent 最容易犯的错误，就是为了“完成任务”一次性写太多东西，然后测试也变成对想象中实现的确认。
5. diagnosing-bugs：诊断，而不是猜修
很多 Agent 修 bug 的方式是：看到报错，猜一个原因，改一把，再看结果。
diagnosing-bugs 强调纪律化诊断：
复现 → 最小化 → 假设 → 插桩 → 修复 → 回归测试
这其实是老派调试基本功。
但在 AI 时代，它反而更重要。
因为 Agent 的速度越快，胡乱修改造成的破坏也越快。
6. codebase-design：深模块语言
这个技能提供一套架构词汇：
module；
interface；
depth；
seam；
adapter；
leverage；
locality。
它的目标是让 Agent 不只是“把代码拆小”，而是理解什么叫好的模块边界。
在 AI 编程里，模块设计不只是人类可维护性问题，也是 Agent 可导航性问题。
7. improve-codebase-architecture：代码库体检
这个技能会扫描代码库，找出可以改进架构的机会，并输出一个可视化 HTML 报告。
报告会包含：
涉及文件；
当前问题；
改进方案；
改进收益；
before / after 图；
推荐强度；
最优先建议。
这很适合周期性运行，比如每几天对代码库做一次“结构体检”。
8. to-prd 与 to-issues：从讨论到可执行工作
to-prd 会把当前对话整理成 PRD，并发布到 issue tracker。
to-issues 会把计划、规格或 PRD 拆成可以独立领取的 issues。
这里有一个关键词：vertical slices。
它不是按技术层拆任务，而是按可以独立交付的用户价值切片拆任务。
这对多人协作和 Agent 协作都很重要。
9. handoff：让另一个 Agent 能接手
handoff 是生产力技能，用于把当前对话压缩成交接文档。
这正好对应了 Agent 工作中的常见问题：上下文窗口有限，长任务经常需要换会话、换模型、换人接手。
好的 handoff 能显著降低接力成本。
七、它和 pm-skills 有什么不同？
前面我们调研过 phuryn/pm-skills。那个项目更像是产品经理 AI 操作系统，覆盖 PRD、Discovery、GTM、市场研究、增长等产品管理全流程。
而 mattpocock/skills 更像是工程师 AI 操作系统。
两者都叫 skills，但方向完全不同：
phuryn/pm-skills解决的是产品经理如何用 AI 做决策和交付；mattpocock/skills解决的是工程师如何让 Coding Agent 遵守真实工程纪律。
如果说 pm-skills 的关键词是：
产品方法论 → 工作流 → 决策质量
那么 mattpocock/skills 的关键词就是：
工程纪律 → 反馈循环 → 代码质量
这两个项目放在一起看，很有意思。
它们说明 Agent Skills 正在从“提示词收藏”演化成“职业工作系统”。
八、对我们有什么启发？
这个项目对“小欧”的启发非常直接。
我们之前已经沉淀了不少流程：
内容工厂；
政策产线；
稍后学习；
想法收集；
人脉管理；
公众号配图；
深度调研；
飞书文档交付。
但从 skills 的角度看，它们还可以进一步结构化。
mattpocock/skills 给了几个关键启发。
1. 不要只沉淀“怎么做”，还要沉淀“什么时候不做”
仓库里有 .out-of-scope 文件，明确说明某些场景不属于技能处理范围。
这很重要。
一个好技能不只是告诉 Agent 做什么，也要告诉它不要做什么。
比如公众号文章工作流里就应该写清楚：
没有配图不能直接发；
用户说“直接发”也要遵守最低配图标准；
如果配图风格不符合偏好，应该重发，不要怕草稿变多。
2. 把高频工作变成 User-invoked + Model-invoked 组合
例如公众号流程可以拆成：
User-invoked：
/写公众号并发布Model-invoked：选题判断、事实核验、配图风格选择、发布前检查
人负责启动大流程，模型负责在过程中自动调用专业纪律。
这比一条长提示词稳定得多。
3. 维护长期上下文，而不是每次重新解释
CONTEXT.md 和 ADR 的思路非常值得借鉴。
我们也可以维护：
用户偏好上下文；
公众号视觉风格上下文；
选题禁区；
已发文章记录；
公众号文章结构原则；
环保政策领域术语表。
这会让小欧越来越像一个“长期协作的工作伙伴”，而不是每次重启的聊天机器人。
4. 用工程纪律约束 Agent，而不是只靠模型聪明
mattpocock/skills 最重要的提醒是：
不要迷信模型变强，要设计让模型不容易犯错的流程。
公众号发布也是一样。
不能只依赖“这次我记得配图”。
应该把流程写死：写文 → 配图 → 检查 → 发布。任何一步出错，就重发。
九、适合谁使用？
这个项目最适合四类人。
1. 高频使用 Claude Code / Codex 的工程师
如果你已经把 Agent 放进日常开发，这套 skills 能帮你减少失控。
2. 技术负责人和架构师
尤其适合用 improve-codebase-architecture、codebase-design、domain-modeling 维护长期项目质量。
3. AI 原生创业团队
小团队用 Agent 写代码很快，但更容易技术债失控。这套技能可以作为轻量工程治理机制。
4. 想构建自己 Skills 库的人
这个仓库本身就是一个很好的设计样本：如何拆技能、如何区分调用方式、如何写边界、如何让技能互相调用。
十、怎么开始用？
官方推荐安装方式很简单：
npx skills@latest add mattpocock/skills
安装时选择你想要的 skills 和 coding agent。
官方特别提醒：一定要选择：
/setup-matt-pocock-skills
然后在 Agent 里运行它。
这个 setup 会问你：
用哪个 issue tracker：GitHub、Linear 还是本地文件；
triage 时使用哪些标签；
文档保存在哪里；
域模型和 ADR 如何布局。
完成后，比较推荐先试这几个：
/grill-with-docs /tdd /diagnosing-bugs /improve-codebase-architecture /to-issues /handoff
十一、最终评价
mattpocock/skills 的核心价值不是“帮你更快写代码”。
它真正有价值的地方是：
把真实工程师的工作纪律，封装成 Agent 可以遵守的技能系统。
它反对 vibe coding，不是反对 AI 编程，而是反对没有反馈、没有对齐、没有设计、没有边界的 AI 编程。
AI 写代码越快，工程纪律越重要。
这个项目能火到 13 万 Star，说明很多工程师已经意识到：
下一阶段的 AI 编程，不是比谁更会让 Agent 写代码，而是比谁更会让 Agent 在正确的工程系统里工作。
如果 phuryn/pm-skills 代表了产品经理的 AI 工作系统，那么 mattpocock/skills 代表的，就是工程师的 AI 工作系统。
未来真正有价值的，不是一堆零散 Prompt，而是一套能长期运转、可组合、可迁移、能约束 Agent 行为的 Skills 体系。
这也是小欧后续应该继续进化的方向。
相关链接
GitHub：mattpocock/skills
https://github.com/mattpocock/skills[2]Matt Pocock
https://www.totaltypescript.com[3]
引用链接
[1]https://github.com/mattpocock/skills
[2]https://github.com/mattpocock/skills