Matt Pocock Skills 使用指南：需求澄清、TDD 与模块设计
2026年10月20日 · 2859 字 · 6 分钟 · AI编程 Agent Skills Matt Pocock 开源项目 软件工程
Matt Pocock Skills 是一套面向 AI 编程助手的开源工程技能，涵盖需求澄清、领域术语、任务拆分、测试与模块设计。它把重复使用的工程实践写成可调用的技能，帮助使用者在动手前明确需求，并在实现后验证结果。
截至 2026 年 10 月 20 日，mattpocock/skills 已获得 297,946 个 GitHub Star（约 29.8 万）。Matt Pocock 把自己日常使用的工程实践整理成了一组 Agent Skills，覆盖需求讨论、设计、实现与检查。
图片来源：GitHub 官方项目预览图，获取于 2026 年 10 月 20 日；图中 Star 数为平台取整显示。
它想解决的问题，很多用 AI 写过代码的人都遇到过。
让 AI 加一个导出按钮，几分钟就写好了。
点一下，文件也能下载。再一看：导出了全部数据，没带上筛选条件，普通账号还能拿到不该看到的订单。
接下来，聊天框里就剩下了熟悉的循环：
“这里不对，再改一下。”
写代码省下来的时间，又花在了补需求、查问题和返工上。
它最值得借鉴的地方，是让一些本来靠人反复提醒的工程习惯，有了可以重复调用的入口。
Matt Pocock Skills 是什么？
在这个仓库里，技能通常以 SKILL.md 组织：说明适用场景、执行步骤，以及需要参考哪些文件。有的负责组织一次完整讨论，有的提供测试或设计时使用的规则。
你可以把它理解成给编程助手准备的一份工作手册。
比如，你平时总要提醒 AI：“先弄清需求”“测试别只测内部函数”“别为了抽象又套一层”。这些重复沟通的内容，可以整理进技能，遇到对应问题时再调用。
仓库强调技能应当小、可调整、能组合。对使用者来说，这意味着可以先挑最需要的一项，逐步放进自己的开发习惯里。
下面这个订单导出的例子，是为了说明方法而设计的演示场景。
需求澄清：grilling 与 grill-with-docs
“加个订单导出功能”，看起来很清楚。
真要动手时，至少有几个问题：
- 导出当前页，还是全部筛选结果？
- 谁能导出，能看到哪些字段？
- 没有数据时给什么提示？
- 数据量很大时，是等待下载，还是后台生成？
其中任何一项理解不同，都会写出另一套功能。
仓库的 grilling 会围绕决策的依赖关系分轮提问：先解决当前能确定的选择，再往下讨论依赖它的细节。grill-with-docs 则把需求访谈与领域建模组合起来。
放到这个例子里，先确定“谁能导出什么”，再讨论“大文件怎么处理”，会比一开始就争论按钮放哪里更有用。
越是会改变权限、数据范围和验收结果的问题，越应该在代码出现之前讲清楚。
图片由 AI 生成，仅作示意。
领域建模：用 GLOSSARY.md 统一术语
还有一种返工，很隐蔽：同一句话里，大家对一个词有不同理解。
你说“客户”，可能指下单的人；AI 看代码里的 Account，却把它理解成一个企业账号。
后面的筛选、权限、导出字段，就可能一路跟着偏。
仓库里的 domain-modeling 会追问模糊术语，把确定下来的含义写进 GLOSSARY.md。对于有实际权衡、以后难改、又容易让后来者困惑的决定，才考虑记录 ADR，也就是架构决策记录。
例如，我们可以在演示项目里约定：
“导出范围”始终指当前用户权限内、符合当前筛选条件的订单集合，与列表分页无关。
这句话一旦确定，产品讨论、代码命名和测试用例就有了共同参照。
换一次会话，也有地方查。
任务拆分：to-tickets 与纵向切片
有了需求，接下来通常是拆任务。
一种很常见的拆法：先数据库，再接口，最后页面。
每项都能写成“已完成”，用户却还没办法体验一次完整导出。直到页面接上接口，前面理解错的地方才暴露。
to-tickets 强调把需求拆成能独立演示或验证的小任务，并明确哪些任务会阻塞后续工作。它把这种从各层穿过去、完成一小段完整行为的方式叫做纵向切片。
如果由我来安排这个演示需求，我会先做：
让有权限的用户，成功导出少量符合筛选条件的订单，并验证越权请求会被拒绝。
这一步走通，页面、权限、查询与文件生成之间的连接就得到了实际检查。随后再增加大数据量处理、任务进度和下载过期等能力。
完成一个小闭环，比同时开工五个半成品，更容易看出方向有没有错。
TDD：通过公开接口验证行为
有时 AI 会很认真地补上一堆测试，然后郑重宣布：“全部通过。”
但如果预期结果也是照着实现推出来的，测试就像拿自己的答案给自己判卷。
仓库的 tdd 特别提醒，要通过公开接口检查行为，避免测试紧贴内部实现，也避免把实现逻辑重算一遍当成预期值。它要求先约定测试位置，再按“一条失败测试、一份最小实现”的节奏推进。
在订单导出场景中，一个有价值的检查可以是：
用户只能查看 A 店铺，发起导出后，文件里不能出现 B 店铺的订单。
这个预期来自权限规则。即使内部换了查询函数，它依然有意义。
测试先暴露差距，代码再补齐行为。每次只推进一小步，就更容易知道问题从哪里开始。
图片由 AI 生成，仅作示意。
这里还有个容易看漏的细节：**仓库当前版本把重构放在审查阶段处理，并不把它塞进每轮红绿实现循环。**读技能时，要看具体规则，不能只凭名字套用印象中的流程。
模块设计：codebase-design 与深模块
一个功能能跑，还只是开始。
假如每个调用方都要自己处理权限、拼查询、做格式转换，下一次改规则时，就要到处找地方改。
codebase-design 提倡“深模块”：调用方只需要理解较小的接口，就能使用背后较多的能力。它关心的是接口给调用方省了多少事，以及修改能否集中在合适的位置。
以这个演示功能为例，我会检查：导出入口能否统一接收当前用户和筛选条件，再把权限过滤、字段选择与文件生成妥善组织起来？
要不要新增一层抽象，取决于它能否真正收拢复杂度。
如果只是换个文件名，把同样的参数继续往下传，维护的人未必轻松多少。
如何安装并开始使用 Matt Pocock Skills
如果你常用支持 Skills 的编程助手，可以参考项目 README 给出的安装方式：
npx skills@latest add mattpocock/skills
按提示选择自己的工具和技能。当前 README 提醒，选择时应包含 setup-matt-pocock-skills；安装后，在项目中运行一次：
/setup-matt-pocock-skills
它会帮助确定任务记录在哪里、使用哪些分流标签，以及术语和决策文档放在哪里。这里展示的是项目文档中的用法，本文没有执行安装，也没有做工具兼容性实测。
第一次使用，可以按下面的顺序推进：
- 在一个支持 Skills 的编程助手中完成安装，选择
setup-matt-pocock-skills。 - 在目标项目运行一次
/setup-matt-pocock-skills，确定任务记录、分流标签与文档位置。 - 选一个范围小、结果容易判断的真实需求，用
/grill-with-docs澄清权限、数据范围和验收结果。 - 需要拆分时使用
/to-tickets；实现时参考tdd的公开接口测试规则，检查结果是否满足先前约定。
上面的顺序是本文建议的入门路径，可按项目现状调整。
先用需求访谈补齐关键选择，再看测试是否覆盖了自己最在意的行为。跑完一轮，观察两件事：后半程有没有反复补需求？改完代码后，有没有证据说明行为符合预期？
这比一口气装满技能列表，更容易判断它是否适合自己。
AI 把代码产出提速之后，需求表达和结果验收，会更直接地影响你究竟省了多少时间。
这个仓库提供了一批可以拿来修改、组合的做法。对已经在用 AI 做真实项目的人，值得挑一个最常踩坑的环节试试。
项目地址：Matt Pocock Skills 官方仓库。
本文基于 2026 年 10 月 20 日可见的项目文档整理。Star 数与技能规则会随项目更新变化；文中的订单导出为演示场景，未执行安装或工具兼容性实测。