别再让 AI “自由发挥”了：我拆了一套真正给工程团队用的 Agent Skills

最近发现一套挺有意思的 skill：mattpocock-skills。

它不是那种“帮我写代码”“帮我优化一下”式的万能提示词包。它更像一套给 AI Coding Agent 用的工程工作流：先把需求问清楚，再沉淀领域语言，再写规格、拆工单、TDD 实现、最后按规格和代码标准做 review。

一句话概括：它不是教 Agent 更会“猜”，而是逼 Agent 少猜。

这个 skill 到底是干什么的？

从仓库结构看，这不是单个 skill，而是一组面向真实工程开发的 agent skills。它可以通过 skills.sh 安装到 Codex 等兼容 Agent Skills 标准的工具里，也可以作为 Claude Code plugin 安装。

核心思路很工程化：不要把 Agent 当成一个随叫随到的代码生成器，而是把它放进一条可控流程里。

这套流程大概是这样：

1. 用 /grill-with-docs 先追问需求，把模糊点问出来。
2. 如果有些问题靠文字说不清，就用 /prototype 做一次性原型。
3. 用 /to-spec 把讨论收束成规格。
4. 用 /to-tickets 拆成可以独立推进的小工单。
5. 用 /implement 开始实现，实现过程中尽量走 /tdd。
6. 最后用 /code-review 从“代码标准”和“规格符合度”两个角度 review。

这个套路听起来不花哨，但非常像一个靠谱 senior engineer 带着 junior engineer 干活：先问清楚，再写计划，小步实现，跑测试，最后复盘。

它解决的不是“AI 不够聪明”，而是“工程反馈太弱”

很多人用 AI 写代码翻车，其实不是模型完全不行，而是流程太散。

最常见的场景是这样：

你说：“帮我加个权限控制。”

Agent 很快写了一堆代码，看上去还挺像那么回事。结果一跑，发现它没理解权限边界；再一看 diff，还顺手改了几个无关模块；等你让它修，它又开始在错误方向上补丁套补丁。

问题在哪？

不是它不会写代码，而是它从一开始就没有被要求把问题讲清楚，也没有被放进测试、规格、评审这些反馈环里。

mattpocock-skills 的价值就在这里。它把 Agent 的工作拆成几个明确阶段，每个阶段都有不同目标：

• 需求阶段：别急着写，先问。
• 设计阶段：术语要统一，边界要讲清。
• 计划阶段：规格和工单要能被执行。
• 实现阶段：用测试驱动，不要一口吃成胖子。
• 评审阶段：既看代码有没有味道，也看有没有偏离需求。

几个值得重点看的 skill

/ask-matt：不知道用哪个，就先问它

这个 skill 是整个集合的路由器。

你不用记住所有命令。你只要说当前卡在哪里，它会告诉你应该走 /grill-with-docs、/to-spec、/diagnosing-bugs、/wayfinder，还是直接 /implement。

对团队来说，这一点很重要。因为真正推广一个流程时，最难的不是工具能不能用，而是大家记不住什么时候该用什么。

/grill-with-docs：先把需求拷问清楚

这个 skill 的做法很直接：让 Agent 不断追问你，直到需求分支基本闭合。

它厉害的地方不只是“会问问题”，而是会顺手构建项目文档，比如 CONTEXT.md 和 ADR。也就是说，今天问清楚的领域词、业务规则、设计决定，不会只留在聊天记录里，而是能沉淀到仓库。

这对长期项目非常实用。Agent 下次进来，不用重新猜“账户”“订单”“素材化”“发布态”这些词到底是什么意思。

/to-spec 和 /to-tickets：把聊天变成交付物

很多 AI Coding 的失败点在这里：前面聊得很热闹，真正开始写代码时，只有一坨上下文。

/to-spec 负责把当前讨论整理成规格。/to-tickets 再把规格拆成工单，而且会标清阻塞关系。

这就很像把“口头需求”变成“可执行任务队列”。多人协作时尤其有用，因为每个 Agent 或每个开发者都可以拿一个边界清楚的小任务推进。

/tdd：让 Agent 按红灯、绿灯的节奏走

这个 skill 不是简单说一句“请使用 TDD”。它明确要求先确认测试边界，再按红灯、绿灯、小步实现来推进。

这里有一个观点值得注意：测试应该验证公开行为，不要绑死内部实现。

这对 Agent 很关键。因为 Agent 很容易写出“看起来覆盖率很高，但全是测实现细节”的测试。这样的测试短期能过，长期会拖慢重构。

/code-review：把 review 拆成两条线

这个设计也挺聪明。

它把 review 分成两条线：

• Standards：代码是否符合项目标准，有没有明显代码味道。
• Spec：实现是否符合原始需求，有没有漏做或做多。

这能避免一个常见问题：代码写得很漂亮，但需求实现错了；或者需求做对了，但代码质量明显在透支未来维护成本。

两条线分开看，结论会更清楚。

怎么用？给你一条最稳的落地路径

如果你是第一次在项目里用这套 skills，建议不要一上来就全量铺开。先用下面这条主线：

 复制代码npx skills@latest add mattpocock/skills

安装时选择你需要的 agent，并确保选上：

 复制代码/setup-matt-pocock-skills

然后在项目里先跑：

 复制代码/setup-matt-pocock-skills

它会配置三件事：

• issue tracker 放在哪里，比如 GitHub、GitLab 或本地 Markdown。
• triage 标签怎么映射，比如 needs-triage、ready-for-agent。
• 领域文档放在哪里，比如 CONTEXT.md 和 docs/adr/。

配置完以后，一个常规需求可以这么跑：

 复制代码/grill-with-docs
/to-spec
/to-tickets
/implement

如果只是一个很小的改动，可以跳过规格和拆票，直接在当前会话里 /implement。但只要需求开始变大，建议还是老老实实走 spec 和 tickets。

别嫌麻烦。Agent 越强，越要给它轨道。不然它跑得越快，偏得也越快。

用完之后，收益在哪里？

收益可以拆成四类。

第一，需求对齐成本下降。

/grill-with-docs 会强制把模糊点提前暴露。很多问题在动手前问出来，成本非常低；等代码写完再发现理解错了，成本就高很多。

第二，项目语言会越来越稳定。

CONTEXT.md 和 ADR 这类文档不是为了好看，而是为了让 Agent 和人都说同一套话。一个项目最怕同一个概念有三种叫法，Agent 更怕。术语稳定以后，命名、测试描述、提交说明都会更一致。

第三，代码质量有反馈环。

TDD、类型检查、单测、全量测试、code review，这些东西本来就是工程基本功。这个 skill 的价值是把这些基本功写进 Agent 的工作协议里，让它每次都按这个节奏走。

第四，大需求更容易拆。

/to-tickets 和 /wayfinder 对复杂任务很有帮助。前者适合把明确规格拆成小工单，后者适合那种连路线都不清楚的大项目。它们的目标不是一次性生成完美计划，而是让不确定性被逐步压低。

如何给团队做培训？

如果要把这套 skills 推给一个研发团队，不建议开一场“命令大全”式培训。大家听完会觉得懂了，第二天还是照旧乱用。

更好的方式是拿真实项目练。

安排成两周五篇文章：

第一课，安装和初始化。

每个人在自己的项目里跑 /setup-matt-pocock-skills，把 issue tracker、triage 标签、领域文档位置定下来。目标不是装成功，而是让团队知道这些配置后面会被哪些 skill 读取。

第二课，需求追问。

选一个真实需求，用 /grill-with-docs 让 Agent 追问。培训重点是看问题质量：它有没有问到边界条件？有没有发现术语不清？有没有把重要决定写进文档？

第三课，规格和工单。

把第二课的讨论转成 /to-spec，再用 /to-tickets 拆工单。这里要重点训练“工单能不能独立交付”，而不是追求拆得多细。

第四课，TDD 实现。

每个人拿一个小工单，用 /implement 驱动 /tdd。重点看三件事：测试是不是先失败，测试是不是测公开行为，实现是不是小步推进。

第五课，评审复盘。

用 /code-review 对本次 diff 做 Standards + Spec 双轴评审。最后团队一起整理一份自己的使用约定：哪些场景必须先 grill，哪些场景必须拆 tickets，哪些测试边界必须提前确认。

从这学到的不是“某几个神奇命令”，而是一套和 Agent 协作的工程习惯。

适合谁？不适合谁？

它很适合已经有代码库、有 issue 流程、愿意写测试、愿意沉淀文档的团队。

如果你的项目还处在 demo 阶段，只想快速试一个想法，也可以用里面的 /prototype 或 /grill-me，但不一定要把完整流程都搬进来。

它不太适合一种情况：你只想让 AI 快速堆代码，不想被追问，也不想写规格和测试。

这种情况下，这套 skill 反而会显得“烦”。但从工程角度看，这个“烦”正是它的价值。它把那些平时容易省掉、但后面一定会还债的动作，提前放到了流程里。

最后

看完这套 skill，最大的感受不是“提示词写得多高级”，而是它很清楚软件工程到底难在哪里。

难点不是让 AI 多写几行代码。真正难的是：需求怎么对齐，边界怎么切，反馈怎么变快，代码怎么在几轮迭代后还站得住。

mattpocock-skills 给出的答案很朴素：别让 Agent 自由发挥，把它放进工程纪律里。

这可能也是 AI Coding 接下来真正要补的一课。