从想法到交付：Matt Pocock 的 AI Skills 工作流

从想法到交付：Matt Pocock 的 AI Skills 工作流

你让 AI 编程助手实现一个功能，它很快写出了一大堆代码。但仔细一看，需求理解错了，边界条件没处理，测试也不能说明功能是否真的可用。

这类问题不一定能靠一条更长的提示词解决。Matt Pocock 的思路是：把开发过程拆成一系列可以重复、可以检查的工作方式，让 AI 在合适的阶段做合适的事。

本文根据 Matt 的 AI Skills 七节邮件课程和 AI Hero 官方文档整理。邮件课程强调一条从模糊想法到持续改进的闭环；官网文档则提供了每个技能的使用细节。文中的项目和提示词均为说明用示例。

Skill 到底是什么？

可以把 Skill 理解成给 AI 助手的一份可复用工作说明书：遇到某一类任务时，应该先了解什么、按什么步骤推进，以及交付什么结果。它通常是可以阅读的 Markdown 指令，有时还会带参考资料或脚本。

例如，一句普通提示词可能是：“帮我设计评论功能。”而一个需求澄清 Skill 会引导助手检查项目已有代码和术语，提出关键问题，并帮助你逐步做出决定。

Skill 不是一个新模型，也不能保证结果正确。它的作用是让工作方式更稳定、更容易复查；实际执行范围仍取决于你使用的助手、权限和具体版本。

整体流程：先想清楚，再让 AI 动手

七节邮件可以归纳成下面这条路径：

模糊想法
   ↓
grill-with-docs：澄清目标和决策
   ↓
prototype + handoff：遇到无法靠讨论解决的问题时，做小实验
   ↓
to-spec：记录已经达成的方案
   ↓
to-tickets：拆成可实现、可验证的小任务
   ↓
实现：按任务逐个构建；需要时使用隔离环境
   ↓
code-review：对照需求和项目规范检查改动
   ↓
复盘：改善说明、验证方式或代码结构，进入下一轮

这不是要求每个任务都走完全部步骤。修复一个明确的小问题，可能直接实现并验证就够了；功能越大、决策越不确定，前面的澄清和拆分就越有价值。

安装和开始使用

邮件中给 Codex、Cursor、OpenCode 等工具的安装方式是：

npx skills add mattpocock/skills

安装过程会让你选择技能和目标工具。安装单个技能也可以参考各技能的官网页面，例如：

npx skills@latest add mattpocock/skills --skill=prototype

安装后，可以在支持的编码助手中尝试输入 /prototype，并说明要验证的问题。不同工具的技能发现和调用方式可能不同，以工具实际界面为准。

首次在一个项目里使用这套工程技能时，/setup-matt-pocock-skills 可以帮助配置任务跟踪器、标签及领域文档位置。它会先提出方案并等待确认，然后写入项目配置。任务既可以放在 GitHub、GitLab，也可以选择本地 Markdown 等方式。另一个入口是 /ask-matt：不确定应该用哪个技能时，可以描述当前处境让它推荐。

版本提示：网上旧文章可能使用 /to-prd、/to-issues 等名字。官方 v1.1 将主要流程中的 /to-prd 改名为 /to-spec，并将 /to-issues 改名为 /to-tickets。升级后应检查是否残留旧技能，具体以当前安装版本和官方更新说明为准。

1. /grill-with-docs：把模糊想法问清楚

假设你说：“我想给博客加一个评论系统。”这句话看起来很明确，但马上会出现一串问题：

• 谁可以评论？访客是否需要登录？
• 评论是否支持回复？删除后回复如何处理？
• 垃圾评论如何处理？管理员有哪些权限？
• 项目里是否已有用户、通知或审核机制？

/grill-with-docs 的作用，就是围绕计划或设计持续提问，结合现有代码和领域文档，帮助人和助手建立共同理解。能从代码库查明的问题，助手应先查代码；需要产品判断的地方，仍然需要人做决定。

它还会把已经澄清的领域术语写入 GLOSSARY.md，并在符合条件时记录重要架构决策（ADR）。因此它可能修改项目文档，使用时要留意助手提出的变更。

示例：

/grill-with-docs
我想给博客增加评论功能。请先检查项目已有的用户和评论相关实现，
再帮我厘清功能范围、权限、边界条件和需要做的决策。

这里的重点不是让 AI 不停提问，而是把真正影响设计的选择提前暴露出来。

2. /prototype 和 /handoff：用小实验回答不确定的问题

有些问题光靠讨论很难判断。例如：评论回复展开后会不会太拥挤？一个状态切换是否容易理解？这时可以用 /prototype 做一个小原型。

原型的第一步是写清楚要回答的问题，而不是把整个功能实现一遍。比如：

/prototype
只验证一个问题：手机屏幕上，二级评论默认折叠是否容易发现？
用模拟数据做一个可点击的简易页面，不接入真实服务。

原型代码是为了学习而写的，不应默认直接当成生产代码。官方文档提到，可以把原型留在主线之外的分支作为证据，再将得到的结论带回正式设计。

当讨论已经很长，或者需要把问题交给另一个会话、工具或同事时，/handoff 可以把目标、已有决定和待解决的问题整理成临时交接文档。做完实验后，把结论和证据带回原来的规划过程，而不是只说“原型做好了”。

3. /to-spec：把讨论结果变成明确的说明

讨论结束后，信息散落在聊天记录里。换一个会话或者过几天再看，很容易忘记当初为什么这样决定。

/to-spec 会整理已有讨论、代码和领域文档，形成一份规格说明。它适合在关键决策已经完成之后使用：它负责归纳，不负责替你重新决定需求。官方实现会将规格发布到配置的任务跟踪位置，因此使用前应确认目标位置和写入权限。

以评论功能为例，规格说明可以回答：

• 要解决什么问题，哪些内容暂时不做；
• 用户和管理员分别可以做什么；
• 对关键边界条件已经做了哪些决定；
• 功能需要满足哪些可观察的验收条件；
• 哪些模块或接口需要变化。

一份好规格的价值，是让另一个没有参加讨论的人也能理解方向、发现遗漏，并判断结果是否符合约定。

4. /to-tickets：把大功能切成可以验收的小任务

即使方向已经确定，“实现完整评论系统”对一个 AI 会话来说仍可能太大。/to-tickets 会将规格拆成较小的任务，并标明任务之间的依赖。

这里一个关键概念是垂直切片：一个任务尽量贯穿必要的层次，完成后能独立验证。例如：

评论系统可以逐步拆为“查看和发表基础评论”“回复已有评论”“管理员处理评论”等任务。实际切法取决于项目依赖，重点是每个任务都应有清晰范围和验收方式。

5. /implement 与 TDD：按约定逐个实现

AI Hero 官网主流程还列出了 /implement：将已经确定的任务、规格或计划转化为代码。官方说明中，它会使用测试驱动开发、运行检查、进行代码评审并提交到当前分支。因此，调用前要确认工作目录、分支和任务边界。

其中，/tdd 提供的是测试驱动开发的工作规则：先明确需要测试的公开行为，再写一个会失败的测试，用足够少的实现让它通过，最后整理代码。循环可以概括为：

写一个失败的测试 → 写实现让测试通过 → 重构 → 下一个行为

例如，针对“用户提交空评论”的行为，可以先明确预期：服务拒绝空内容，且不产生评论记录。然后围绕这个行为编写测试，而不是为了覆盖率给每个内部函数写一遍测试。

TDD 适用于需要稳定验证的行为；它也不能取代必要的人工体验检查和对真实运行环境的验证。

6. /code-review：检查是否做对，以及是否做了正确的事

/code-review 对照一个指定基准检查代码差异，官方文档将评审分为两个维度：

1. 项目规范：代码是否遵守仓库已有的约定？
2. 规格要求：改动是否完成原始任务或规格要求？

例如，评论提交接口可能通过了测试、代码风格也一致，但如果规格要求限制未登录用户提交，而实现完全没有权限检查，它仍然没有完成任务。

示例：

/code-review
请以 main 为基准，检查本分支是否符合评论功能规格和项目规范，
重点指出会影响用户行为或数据正确性的问题。

人工仍然需要阅读发现、判断优先级并验证修复。AI 评审是额外的一双眼睛，不是最终质量保证。

7. 从一次错误中改进下一次工作

邮件课程的最后一个重点是：代码修好了，还要回头看错误为什么容易发生。

比如，助手反复漏掉权限检查，可能是任务没有写清角色；频繁找到错误的文件，可能是项目缺少入口说明；一个功能总要跨很多文件修改，可能说明模块边界不够清晰。

这里有两个互补的工具：

• /retro：回看一次会话中的摩擦，提出对项目说明、检查或工作环境的改进建议。官方文档说明它先提出候选项，由人选择后再处理。
• /improve-codebase-architecture：检查哪些模块值得重构，例如调用方需要了解过多内部细节的地方，并生成报告供人选择进一步讨论。

不是每次出错都要重构。先区分问题来自需求、验证、说明还是结构，再选择最小且有效的改进。

一个完整的实践示例

假设要给博客增加评论功能，可以这样走一遍：

1. 澄清：用 /grill-with-docs 查看现有项目，确定登录、回复、审核和删除规则。
2. 实验：如果移动端回复层级不好判断，用 /prototype 做一个只验证交互的页面；必要时用 /handoff 把问题转到新会话，再带回结论。
3. 记录：用 /to-spec 整理目标、范围、规则与验收条件，检查后保存到团队约定的位置。
4. 拆分：用 /to-tickets 切成基础评论、回复、审核等可验证任务，并明确依赖。
5. 实现：从基础评论开始，用 /implement 或项目已有流程实现，针对关键行为运行测试；需要后台运行时，可考虑隔离环境。
6. 评审：用 /code-review 对照任务和项目规范检查差异，自己复核关键行为。
7. 改进：如果反复出现同类问题，用 /retro 找工作流问题；如果模块边界反复造成摩擦，再考虑架构分析。

每一步都应留下下一步真正需要的信息：明确的决定、原型结论、可验收的任务、测试结果和审查发现。这些材料让工作可以继续，也让人能够判断 AI 到底完成了什么。

常用技能速查

第一次实践时，可以选一个真实但不大的功能。从需求澄清开始，做出一个可验收的切片，检查结果，再记录一次过程中最值得改进的地方。整个流程的价值，就在这些可观察的反馈里。

参考资料

• Matt Pocock，AI Skills 七节邮件课程，1/7—7/7。课程内容通过邮件发送；本文为归纳解读，未公开个人邮件链接。
• AI Hero：AI Skills 官方文档
• Matt Pocock Skills 源码仓库
• Sandcastle 源码仓库
• Skills v1.1 更新说明