GitHub Trending 上有一个项目最近悄悄起飞——mattpocock/skills，不是靠"一天涨多少星"爆火，而是靠一个非常朴素的命题：AI Agent 能不能先把需求问清楚，再动手写代码？作者 Matt Pocock 是 TypeScript 圈知名的布道师，目前他的 newsletter 订阅者已经接近 6 万人。
相比那些喊着"全自动接管开发流"的 AI 工具，mattpocock/skills 的姿态反而更克制：不做端到端 Agent，只给你一套"工程技能模块"，让你现有的 Agent 学会先对齐、再动手。如果你最近被 AI 写出来的代码"看着对、跑起来全错"反复折磨，这个项目值得你花 10 分钟了解一下。
什么是 mattpocock/skills
mattpocock/skills 是一个面向真实工程师的 AI Agent 技能库，作者 Matt Pocock 在 Slogan 里写得很直白："Skills for Real Engineers. Straight from my .agents directory."——所有技能都是从他自己日常 .agents 目录里抽出来的。
它的设计哲学可以用三组关键词概括：
- 小而精：每个技能只解决一个具体问题，不打包复杂流程
- 易适配：不绑定特定模型或框架，Claude Code、Codex、Cursor Agent 都能用
- 可组合：技能之间可以叠加，按需取用
之所以这么设计，Matt Pocock 给出了一个直接的理由：当前 GSD、BMAD、Spec-Kit 等方法论都在试图"接管整个开发流程"，过程中却剥夺了工程师的控制权，一旦 Agent 写出 bug，定位问题往往比从头写还难。他的解法是让 Agent 学会"停下来问问题"——比起一气呵成的代码，一段被充分对齐的需求反而更省时间。
为什么工程师都在关注它
mattpocock/skills 的核心不是工具，而是它体现的两种工程实践：Grilling 对齐法 和 共享语言（Ubiquitous Language）。
Grilling 对齐法：让 Agent 先把需求问透
"Grilling" 直译是"烤问"，在这里指对模糊需求进行连续追问，直到对齐。mattpocock/skills 提供了两个最常用的 Grilling 技能：
| 技能 | 路径 | 作用 |
|---|---|---|
| /grill-me | skills/productivity/grill-me/ | 非代码场景的深度提问对齐 |
| /grill-with-docs | skills/engineering/grill-with-docs/ | 带文档增强的深度提问 + 建立共享语言 + 写 ADR |
举一个真实场景：你让 Agent"做一个课程平台"，它的第一反应多半是直接搭脚手架。但 /grill-me 会先抛出一连串问题——课程怎么组织？章节和课时是什么关系？"发布"是什么意思？学生购买之后立刻能看，还是定时解锁？这些问题的答案，往往比代码本身更重要。
共享语言：让 Agent 和团队说同一种话
/grill-with-docs 内置了一套"术语对齐"机制。它会引导你和 Agent 建立一份通用术语表（Glossary），确保所有人讨论同一个名词时指向同一个意思。
一个例子来自 Matt Pocock 的实战：某个课程平台里"lesson inside a section is made 'real'"——这句话看似清晰，但每个工程师对 "made real" 的理解都不一样。最终他们把它精炼为 materialization cascade（物化级联），团队沟通、代码命名、Agent prompt 全部统一用这个词。
这个理念其实来自 Eric Evans 的 DDD（领域驱动设计）：通用语言（Ubiquitous Language）让沟通和代码表达都源自同一领域模型，减少"鸡同鸭讲"的返工。
核心技能一览
除了 Grilling 系列，mattpocock/skills 还包含若干工程实践技能：
- /triage：自动给 issue 打标签、按优先级筛选，省掉手工分拣
- setup-matt-pocok-skills：初始化向导，帮你选 issue tracker（GitHub Issues / Linear / 本地文件）、设置标签体系、决定文档保存位置
Issue Tracker 集成支持三选一：
- GitHub Issues：开源项目首选
- Linear：喜欢现代看板的团队
- 本地文件：纯本地工作流，不想绑云服务
两种安装方式，按需选择
mattpocock/skills 提供两种安装方式，覆盖从"只想用"到"想魔改"的不同人群。
方式一：Claude Code 官方插件市场（推荐）
如果你主要用 Claude Code，最省事的方式是：
/plugin install mattpocock-skills特点：
- 托管式只读捆绑包
- 作者更新后自动推送
- 订阅式使用，无需 fork
方式二：npx 安装到任意 Agent
如果你用 Codex、Cursor Agent 或其他工具，或者想自己改技能：
npx skills@latest add mattpocock/skills特点：
- 交互式选择要安装哪些技能
- 复制为可编辑文件到你的仓库
- 自主控制版本（需要手动 pull 获取最新）
- 适合喜欢魔改的工程师（tinkerers）
⚠️ 一个容易踩的坑：两种方式不要混装，否则会出现技能重复，Claude 里同时识别到两份 grill-me。
和同类项目有什么不同
mattpocock/skills 并不是唯一做"AI Agent 技能"的库，但定位有明显区别：
| 项目 | 定位 | 规模 | 特点 |
|---|---|---|---|
| mattpocock/skills | 实用技能集 | ~60K 用户 | 小而精、可组合、工程师导向 |
| anthropics/skills | Claude Code 官方技能 | 官方维护 | 通用场景 |
| opencode | 全栈编码 Agent | 171K⭐ | 端到端自主完成 |
| caveman | Token 压缩技能 | 66K⭐ | 极端简洁语言风格 |
| ponytail | Agent 懒思维框架 | 1,679⭐/day | 让 Agent 学会偷懒 |
最核心的差异：mattpocock/skills 不做端到端 Agent，它提供的是"工程技能模块"，让你现有的 Agent 更好地工作。而 opencode 这类项目是想替代你完成整个开发闭环。
谁适合用它，谁用不上
适合：
- 团队里有多人协作，需求经常要在群里反复对齐
- 用 AI Agent 写代码时反复遇到"输出看着对、跑起来错"
- 想给现有 Agent 加一套工程化的工作流，不愿意换框架
用不上：
- 你是独立开发者，自己提需求自己写代码
- 你已经深度用 GSD / Spec-Kit 这类端到端方法论
- 你的项目极小，根本不需要术语对齐
你能从 mattpocock/skills 学到什么
哪怕你不打算直接用这个项目，它背后的几个工程理念也值得借鉴。
Grilling 对齐法
在执行复杂任务前，先用连续提问把模糊需求逼到清晰。代价是多花 5-10 分钟，回报是省下几小时返工。这个习惯不需要任何工具，你下次给 Agent 提需求时，可以先自己写 3-5 个澄清问题。
Ubiquitous Language（通用语言）
跨系统集成项目（电商 ERP、订单系统、CRM、客服工单）最容易出问题的地方就是术语——"订单状态"在运营、财务、客服、技术四个部门叫法都不一样。建一份全员认同的术语表，能砍掉一半的沟通成本。
ADR（Architecture Decision Records）
重大技术选型后，把决策过程记录下来：当时面临哪些选项？最终选了什么？为什么？半年后回看能省掉无数次"为什么当初这么设计"的考古。
技能原子化设计
mattpocock 的技能是"小模块"，每个只解决一个问题。这其实也是好的内部工具/插件系统的设计原则：宁可多个小工具各司其职，不要一个大平台什么都做。
💡 落地案例：把"先对齐再动手"刻进工作流
一家跨境电商团队把 mattpocock/skills 的理念搬到了自己的内部 AI 助手上，做了三个落地动作：
- 需求澄清 SOP：在 AI 助手开工前自动问 3-5 个澄清问题，没回答清楚就不进入实现阶段——结果新需求首次通过率从 40% 提升到 78%
- 术语表沉淀：把 ERP、Shopify、物流系统里"订单状态""发货节点""退款类型"统一成 24 个标准术语，所有 prompt 和文档都用同一套词
- 重大决策 ADR：每次接入新 SaaS、调整数据流架构后，强制写一份 ADR 文档存进知识库，半年后新人入职可以直接顺着 ADR 摸清系统脉络
你也可以用类似方式把自己的工作流对齐一遍——关键不是装哪个工具，而是养成"先问对问题再动手"的肌肉记忆。
安装链接与资源
- GitHub 仓库：https://github.com/mattpocock/skills
- Matt Pocock 官网与 newsletter：https://www.mattpocock.com
- Claude Code 插件市场：/plugin install mattpocock-skills
- 通用安装：npx skills@latest add mattpocock/skills