一句话
2026 年 7 月，TypeScript 布道者 Matt Pocock 把自己 .agents 目录里天天在用的 AI 编程技能库开源成 mattpocock/skills，副标题只有四个词——Skills for Real Engineers。两个月时间 Star 数从 8 万一路飙过 18 万，单日增长常态化破千，成为 7 月下旬 GitHub 最受关注的仓库之一。
它不是又一个 Agent 框架，不是又一个「一键生成整个项目」的银弹，而是一堆写好的 Markdown 文件。但恰恰是这堆 Markdown，正在回答 AI 编程时代最尖锐的一个问题：当 AI 能写代码之后，工程师的方法论应该以什么形态存在？
这篇文章我会把这个项目拆开揉碎：Skill 到底是什么、SKILL.md 的结构解剖、核心技能的工作流串联、为什么「小而可组合」赢了「大而全流程」、以及怎么给自己团队沉淀一套私有技能库。
背景：氛围编程的宿醉
先说这个项目为什么会火。
2025 到 2026 年，AI 编程工具完成了从「补全」到「代理」的跨越。Claude Code、Codex、Cursor Agent 模式这些工具，已经可以拿着一句模糊的需求跑上十几分钟，改十几个文件，然后告诉你「done」。
爽是真的爽。翻车也是真的翻车。
社区给这种开发方式起了个名字叫 vibe coding——氛围编程。你说个大概，AI 凭感觉写。问题在于 AI 的「感觉」来自训练数据里的平均水平，而平均水平意味着：
- 需求不澄清就开写。你说「加个导出功能」，它不问导出什么格式、多大数据量、要不要异步，直接给你怼一个同步导 CSV 的接口，十万行数据一导服务卡死。
- 没有测试先行的纪律。让它写测试，它会在实现写完之后补一堆「必然通过」的测试——测试跟着实现走，而不是实现跟着测试走，TDD 的灵魂完全颠倒。
- debug 靠猜。报错了就开始改，改一版不行再改一版，像个在黑暗里挥拳的新手，从不先建立假设再验证。
- 越帮越乱。修一个 bug 顺手「优化」了三个不相关的文件，diff 大到没法 review。
Matt Pocock 在 AI Engineer 大会上的演讲标题就是对这个现象的回应：Software Fundamentals Matter More Than Ever（软件工程基础从未如此重要）。他的观点很直接：AI 不会淘汰程序员，只会淘汰不懂工程基础的人。因为 AI 放大的是你的方法论——方法论是零，放大一万倍还是零。
而 skills 仓库，就是他把「方法论」变成「可执行资产」的答案。
核心概念：Skill 是方法论的代码化
Skill 到底是什么
物理形态上，一个 Skill 就是一个文件夹，里面核心是一个 SKILL.md。这个 Markdown 文件描述了一个特定工程场景下 Agent 应该如何工作：任务目标、执行步骤、禁止事项、输出格式。
装进 Claude Code / Cursor / Codex 之后，它变成一个斜杠命令。你敲 /tdd，AI 就切换到「测试驱动开发模式」；你敲 /grill-me，AI 就变成一个不把需求问清楚绝不动手的严格架构师。
安装只要一行：
npx skills@latest add mattpocock/skills
交互式选择你要的技能和目标工具（Claude Code / Cursor / Codex），工具会把对应的 SKILL.md 复制到 .claude/ 或等价目录。也可以只装单个：
npx skills@latest add mattpocock/skills/grill-me
和 rules 文件的本质区别
有人第一反应是：这不就是 .cursorrules / AGENTS.md 换了个马甲？
不是。区别在作用域和触发方式：
| 维度 | Rules 文件 | Skill |
|---|---|---|
| 生效范围 | 全局常驻，每次对话都注入 | 按需触发，用时才加载 |
| 内容性质 | 约束（不要做什么） | 流程（怎么一步步做） |
| Token 成本 | 每轮都花 | 只在调用时花 |
| 可组合性 | 一个大文件，改一处影响全局 | 独立模块，随意增删组合 |
| 可移植性 | 工具绑定 | 遵循 Agent Skills 开放标准，跨工具 |
Rules 是宪法，Skill 是 SOP（标准作业程序）。宪法告诉你底线，SOP 告诉你今天这个手术怎么开刀。一个团队真正值钱的不是「代码要写注释」这种宪法条款，而是「线上事故怎么定位、需求怎么拆、重构怎么做」这些 SOP——这正是 Skill 承载的东西。
SKILL.md 解剖
一个典型的 SKILL.md 长这样（结构示意）：
---
name: tdd
description: Red-green-refactor loop for implementing features with tests first.
---
# TDD
## Goal
Implement the requested feature using strict test-driven development.
## Process
1. Write ONE failing test that describes the smallest next behavior.
2. Run the test. Confirm it fails for the RIGHT reason.
3. Write the minimal code to make it pass. No more.
4. Run all tests. Confirm green.
5. Refactor if needed. Tests must stay green.
6. Repeat until the feature is complete.
## Rules
- NEVER write implementation before the test exists and fails.
- NEVER write more than one failing test at a time.
- NEVER "fix" a failing test by weakening the assertion.
## Output format
After each cycle, report: test name, red/green status, diff summary.
注意三个设计细节，这是很多人自己写 prompt 时缺的：
- frontmatter 里的
description是给 Agent 的路由信号。Agent 决定要不要主动加载这个技能，靠的就是这句话。写得越精准，误触发越少。 - Rules 段全是否定式约束。「NEVER write implementation before the test」这种禁令，比正面描述「请先写测试」对 LLM 的约束力强得多——因为模型违规的路径被显式封死了。
- Output format 强制结构化汇报。这让人类 review 每个循环的产出成为可能，而不是等 AI 跑完十分钟给你一坨 diff。
这就是「方法论的代码化」：Kent Beck 的红绿重构循环，被编译成了 LLM 能严格执行的指令序列。
架构分析：一条完整的工程流水线
仓库里有 28 个技能（截至 7 月下旬版本），分工程类和生产力类。真正的精髓不在单个技能，而在它们串起来是一条完整的软件工程流水线：
需求澄清 产品定义 任务拆分 实现 治理
/grill-me → /to-prd → /to-issues → /tdd → /improve-codebase-architecture
/grill-with-docs /prototype /diagnose
/triage
逐个拆核心环节。
/grill-me：先审讯我，再干活
Matt 本人说这是最受欢迎的技能。grill 在英文里是「烤问、审讯」的意思——这个技能把 AI 从「顺从的实习生」变成「刁钻的资深架构师」。
你说「我要加个用户导出功能」，普通 AI 直接开写。挂了 /grill-me 的 AI 会连环追问：
- 导出的数据规模预期是多少？1 千行和 1 千万行是两个完全不同的方案。
- 同步下载还是异步生成后通知？
- 权限模型是什么？普通用户能导出别人的数据吗？
- 格式要 CSV 还是 Excel？编码要处理 BOM 吗？（Windows 下 Excel 打开 UTF-8 无 BOM 的 CSV 会乱码，这种坑就是在这一步被挖出来的）
- 失败重试和幂等怎么处理？
问到你答不上来为止——答不上来的那些问题，就是原本会在上线后变成事故的模糊点。它把「需求评审会」压缩成了一次对话。
变体 /grill-with-docs 更进一步：先读你项目里的领域文档和 ADR（架构决策记录），用你团队自己的术语来审讯你，避免鸡同鸭讲。
/to-prd 和 /to-issues：从对话到可追溯文档
审讯完之后，/to-prd 把整段对话固化成一份正式的 PRD——这一步的价值是可追溯性：三个月后有人问「为什么导出是异步的」，答案在文档里，不在某次已经被 compact 掉的聊天记录里。
/to-issues 再把 PRD 拆成垂直切片的任务。注意是垂直切片（vertical slice）而不是水平分层：不是「先做完所有 model 再做所有 API」，而是「每个 issue 独立交付一条端到端的功能路径」。这个拆法是为多 Agent 并行准备的——每个切片上下文自洽，可以扔给不同的 Agent 同时跑，互相不踩脚。
/diagnose：把 debug 从玄学变成流程
这是我个人认为含金量最高的一个。它强制 AI 走一个严格的多步诊断流程：
1. 复现 —— 先拿到稳定的复现路径，复现不了就先加日志
2. 假设 —— 列出所有可能原因，按概率排序
3. 验证 —— 设计最小实验逐一排除，每次只验证一个假设
4. 定位 —— 确认根因，解释完整因果链
5. 修复 —— 最小 diff 修复，不顺手改无关代码
6. 回归 —— 验证修复且确认没有引入新问题
对比一下裸奔的 AI debug：看到报错 → 猜一个原因 → 改代码 → 还报错 → 再猜 → 再改……每一轮都在污染代码现场，改到最后连原始状态都回不去了。/diagnose 的「先假设后验证、一次只验证一个变量」就是科学方法本身，也是每个老工程师排障时的肌肉记忆——现在这份肌肉记忆可以被 20 行 Markdown 移植给 AI。
/caveman：Token 经济学
生产力类技能里最有意思的是 /caveman（穴居人模式）：强制 AI 用电报式的极简语言回复，砍掉所有「Certainly! Here's a comprehensive overview...」式的废话。
别小看这个。Agent 长会话的成本大头在上下文累积，AI 每轮多说 200 个 token 的客套话，五十轮下来就是 1 万 token 的纯浪费，还会挤占有效上下文导致更早触发 compact、丢失关键信息。/caveman 本质上是一个上下文预算管理工具——用最糙的方式解决最实际的问题，非常程序员。
/write-a-skill：元技能
最后是自举的一环：/write-a-skill 教 AI 帮你写新的 Skill。你描述一个团队的工作惯例，它产出符合规范的 SKILL.md。技能库因此可以自我繁殖——这是整个体系从「Matt 的个人配置」进化成「团队工程资产」的关键钩子。
为什么「小而可组合」赢了
skills 走红之前，社区里流行的是另一个方向：GSD、BMAD 这类全流程框架——一键接管从需求到部署的整个生命周期，内置十几个角色（PM Agent、Architect Agent、QA Agent……）互相开会。
Matt 的设计哲学与之针锋相对，README 里的态度很明确：不要用大而全的超级流程接管项目，而是把开发过程拆成小的、可组合的、模型无关的技能，需要哪个用哪个。
这场路线之争，本质是软件工程史的重演：
- 全流程框架 ≈ 重型瀑布工具链：理论完备，但黑盒、难调试、跟你团队的实际流程对不上时只能硬掰。
- Skills ≈ Unix 哲学：每个工具只做一件事并做好，用管道组合。
grill-me | to-prd | to-issues | tdd就是一条管道。
三个具体的工程优势：
1. 可调试性。 全流程框架跑挂了，你不知道是哪个环节的 prompt 出了问题。Skill 出了问题，就改那一个 SKILL.md，改完 git diff 一目了然。Prompt 终于变成了可版本控制、可 code review、可回滚的工程资产。
2. 渐进式采纳。 团队不需要 all-in。今天先引入 /diagnose 规范排障，下周再上 /tdd，每一步的价值独立可验证。而框架是二元的：要么整个换，要么不用。
3. 模型无关。 遵循 Agent Skills 开放标准的 SKILL.md，在 Claude Code、Cursor、Codex、Windsurf 之间可以平移。模型层竞争再激烈，你沉淀的方法论资产不作废。这层解耦在 2026 年这个模型半年一换代的环境下，价值怎么强调都不过分。
实战：给自己团队造一套私有技能库
理解了原理，落地其实很快。以一个真实场景为例：把团队的「线上事故复盘规范」做成 Skill。
第一步：目录结构
team-skills/
├── incident-review/
│ └── SKILL.md
├── api-design/
│ └── SKILL.md
└── db-migration/
└── SKILL.md
第二步：写 SKILL.md
---
name: incident-review
description: Structured post-incident review following our team's 5-whys + timeline format.
---
# Incident Review
## Goal
Produce a blameless post-incident review document.
## Process
1. Ask for: incident start/end time, detection method, customer impact.
2. Build a timeline: every action taken, with timestamps, in order.
3. Run 5-whys on the root cause. Stop only at a systemic cause,
never at "human error".
4. List contributing factors (monitoring gaps, missing runbooks, etc).
5. Generate action items: each must have an owner and a deadline.
## Rules
- NEVER attribute root cause to an individual. Blameless means blameless.
- NEVER accept "we'll be more careful" as an action item.
- Every action item MUST be verifiable (a PR, an alert rule, a runbook).
## Output format
Markdown document with sections: Summary / Impact / Timeline /
Root Cause / Contributing Factors / Action Items (table).
注意 NEVER accept "we'll be more careful" as an action item 这一条——这是把团队复盘文化里最容易水掉的环节直接焊死在流程里。好的 Skill 都在编码这种「血泪教训」，这是它比通用 prompt 值钱的地方。
第三步：分发
# 推到内部 Git 仓库后，团队成员一行安装
npx skills@latest add your-org/team-skills
# 或者干脆软链到共享目录，改动即时生效
ln -s ~/work/team-skills/incident-review ~/.claude/skills/incident-review
从此新人入职第一天，敲一个 /incident-review 就能产出符合团队规范的复盘文档。以前这需要三个月的耳濡目染，现在被压缩成一次命令调用。
第四步：像维护代码一样维护它
- SKILL.md 进 Git，改动走 PR，让资深工程师 review「我们的方法论被正确编码了吗」。
- 每次 AI 执行技能后翻车的 case，回头修订对应的 Rules 段——技能库就这样随着团队踩坑持续进化。
- 定期用
/write-a-skill把新沉淀的口头惯例转成正式技能。
冷静一点：三个真实的坑
吹了这么多，说三个实际使用中要注意的问题。
坑一：技能不是护身符，模型会「假装遵守」。 挂了 /tdd 不代表 AI 百分百不先写实现。长会话中上下文被压缩后，技能约束的「权重」会衰减。对策：关键流程（比如测试先行）额外用工具层硬约束兜底——比如 pre-commit hook 检查测试文件的提交时间戳，用确定性的机制补 LLM 概率性遵守的漏。
坑二：技能装太多会互相打架。 28 个全装不是最佳实践。description 相近的技能会让 Agent 路由混乱，常驻加载的技能越多、每轮 token 开销越大。对策：按项目类型精选 5-8 个，宁缺毋滥。
坑三：直接抄不如消化重写。 Matt 的技能编码的是 Matt 的工作流——TypeScript 生态、独立开发节奏。你的团队如果是 Java 微服务加两周迭代，/to-issues 的拆分粒度可能完全不适配。正确姿势是把它当参考实现读懂，然后用 /write-a-skill 长出自己的版本。
总结与展望
mattpocock/skills 值 18 万 Star 吗？如果只看代码量——几十个 Markdown 文件——不值。但它标记了一个转折点：
AI 编程的竞争焦点，正在从「模型多强」转向「方法论多硬」。
模型能力是租来的，OpenAI、Anthropic 说涨价就涨价，说换代就换代。但编码成 Skill 的工程方法论是你自己的资产：可版本控制、可移植、可组合、可传承。2026 年一个团队的 .claude/skills 目录，会像 2016 年的 CI 流水线配置一样，成为工程成熟度的直接体现。
再往前看一步：当技能遵循开放标准、可以被 Agent 自主发现和加载时，「技能市场」几乎是必然出现的形态——就像 npm 之于 JS 包、Docker Hub 之于镜像。到那时，把领域专家的排障直觉、架构品味封装成 Skill 出售，可能会成为资深工程师的新变现方式。
最后回到 Matt 那句演讲标题：Software Fundamentals Matter More Than Ever。AI 时代淘汰的从来不是程序员，是不懂工程方法只会「感觉编程」的人。区别在于，以前你的方法论只能通过你自己的双手生效，现在它可以通过一个 Markdown 文件，指挥一支 AI 军团。
方法论第一次可以被 git push。这就是这堆 Markdown 真正的分量。