AI技能(mattpocock-skills)使用
本文最后更新于 2026年7月24日 凌晨
这套技能适合想摆脱盲目 Vibe Coding、又不想每次都手写一大段流程提示词的人。
如果你本身习惯先写文档、设计测试再推进，它更多是帮你固化流程、少打一些字；如果你平时用 AI 编程全靠聊天，脑子里有想法却不太会主动约束 AI 的输出，也值得试试。它把需求澄清、规格、任务拆分和实施验证等工程习惯写成了一组可组合的提示词。不过它不是质量保证：实际效果仍取决于模型能力、项目的测试与工具链，以及你对需求和关键决策的审查。
安装
我使用的是 Cursor：
1 | |
如果其他平台则执行原本的安装命令，其中自己去选择就好
1 | |
通常不需要重启；如果当前会话没有显示新命令，新开一个会话后再输入/查看即可。
使用
仓库里有不少技能，并非每个都适合直接触发。下面介绍几个常用的工程技能；也可以通过 ask-matt 问问当前场景适合使用什么技能。它们是可组合的，不必每次严格走完全部流程。
1. setup-matt-pocock-skills
首次在尚未配置的仓库使用这些工程技能时，建议执行一次。它会配置本仓库的 Issue 跟踪器、分诊标签和领域文档布局。默认生成英文文本，也可以要求使用中文。
生成或更新哪些文件取决于仓库现状和已安装技能：
CLAUDE.md或AGENTS.md：在已有文件中加入文档导航；两者都不存在时会询问创建哪个- docs/agents/domain.md：文档规范
- docs/agents/issue-tracker.md：问题跟踪器
- docs/agents/triage-labels.md：分诊标签，仅在安装了
triage技能时生成
2. grill-with-docs
有什么需求，都可以通过这个命令提出，例如：
1 | |
接下来的对话会明显不同于直接向 AI 提需求：它会持续追问，通过反复沟通逐步澄清需求。即使最新模型也会主动提问，但这种技能会把追问的深度和频率提升到另一个层级——多到可能让人觉得烦。它牺牲了一些“随便聊聊就生成代码”的轻松感，却更有利于产出真正符合预期的实现。
在追问的过程中，技能还会把已经确认的领域术语写入 CONTEXT.md，把难以回退、需要记录取舍的关键决策写成 ADR 文档。CONTEXT.md 应只保存术语表，而不是需求或实现细节；ADR 也只适合记录确实存在权衡、且未来读者需要理解原因的决策。这样即使之后换了一个对话，AI 也能通过这些文档理解项目背景，而不是又从头猜一遍。
不过，到这一步还没有开始写代码，也不会直接生成任务。接下来可以按需要使用另外几个技能，把已经聊清楚的需求逐步变成可执行的代码。
3. to-spec
根据刚才的历史对话整理出一份正式的需求规格，并发布到已配置的 Issue 跟踪器。因为前面已经把关键细节问清楚了，这个过程通常不会再进行完整的拷问；但它会确认测试边界（seam），仍应检查生成的规格是否符合预期。
4. to-tickets
把规格拆分成多个可以独立验证的子任务，并标注它们之间的依赖关系。它会尽量把任务拆成贯穿数据库、接口、页面和测试的「纵向切片」，而不是只拆成「先写接口、再写页面」这种无法单独验收的横向步骤。正式创建任务前，它会先展示拆分结果并要求确认。
如果初始化工程时选择了本地文件作为 Issue 跟踪器，任务会保存在 .scratch/<功能名>/issues 中，文件名通常从 01-xxx.md 开始，按「先完成阻塞项」的顺序编号。没有依赖关系的任务可以并行，但每个 AI 会话应使用独立的分支或 Git worktree，避免在同一工作目录同时修改文件。
5. implement
到了这一步才是真正开始写代码。它会按照规格或任务实施功能，尽可能使用测试驱动开发，并定期进行类型检查、单测和最终的完整测试。也就是说，前面几个技能负责把模糊的想法变成清晰、可执行的工作项，implement 负责把这些工作项落到代码里。
1 | |
这其实和很多人以前使用 AI 编程的习惯相反：给 AI 一句「把这些需求都实现掉」，然后尽量少干预，等它一次性输出完整结果。这样的体验很爽，但需求一大就容易失控——AI 需要在同一个上下文里同时理解需求、设计架构、修改多处代码、处理任务依赖和排查测试失败；其中任何一步跑偏，后面的修改都会建立在错误的前提上。最后往往得到一大坨难以验收的改动，人只能重新通读代码，甚至让 AI 推倒重来。
implement 的思路是把人从「盯着 AI 写每一行代码」中解放出来，但并不把整个项目不加约束地交出去。它一次只处理一个已经定义好边界的任务：先明确目标和验收标准，再写代码、跑测试、检查结果。人需要做的干预变少了，却集中在需求确认、任务拆分和关键决策这些真正需要人判断的地方；AI 则负责完成边界清楚、可以验证的实施工作。
所以，当 to-tickets 生成了多个任务后，不建议为了省事把所有任务一次性丢给 /implement。优先从没有依赖的任务开始，完成并验证后再推进后续任务；对于互不依赖的任务，可以在独立的分支或 Git worktree 中交给多个 AI 会话并行执行。这样即使某个任务出问题，影响范围也被限制在一个小切片内，定位和回滚都会轻松得多。
每执行完一个任务后，它会自行运行相应的检查并给出结论；当前版本的技能还要求进行代码审查并提交当前分支。确认改动确实通过后，再推进下一个「依赖已满足」的 issue。