分享一套我一直在使用的 AICoding 组合拳，小而美的典范。

本文介绍一套AI编程工作流，来自GitHub上一个名为mattpocock/skills的仓库，目前已经积累了176k星，算得上是经过市场验证的明星产品了。

这个仓库出自一位叫mattpocock的开发者之手，看照片就透着一股浓厚的强者气息。

他在YouTube上有自己的视频频道，围绕这个仓库录制了不少内容，很多视频也被搬运到了B站。7月16日，他专门上传了一期视频，标题是“mattpocock/skills: A complete AI Coding workflow, end-to-end”，对这套工作流进行了完整介绍。当时skills.sh上的下载量是750万次。

等到了7月18日，下载量已经逼近960万次。说不定等你读到这篇文章的时候，已经突破1000万了。

安装

关于如何获取和安装这个skills仓库，GitHub上已经说得很清楚了，这里不再赘述。主要提醒几个视频里提到但GitHub上没写的事情。

比如，通过npx命令安装时，会遇到一个情况：除了主要的Mattpocock Skills技能外，还会看到一个“other”分组。

这个“other”分组是作者正在尝试的一些技能，将来可能会被删除，所以可以先不关注这一组。

安装完成后，这一套skills在context里只占用了660个tokens，和其他skills比起来，算是超级小的体量了。

最后一步，别忘了执行/setup-matt-pocock-skills。这一步可以做一些与开发相关的设置，比如以什么形式进行问题跟踪、哪些关键词能触发相关技能等。需要在具体的项目目录里执行。比如在一个空目录下执行，它会生成这些文件。

组合拳

这个仓库里有很多skill，其中用户主动触发的是这些。每个skill都能单独使用，但当它们形成一套组合拳，威力就大不一样了。

作者给出的组合拳套路是这样的：

这一套组合拳已经是v1.1版本了。v1.0版本长这样：

从v1.0阶段开始使用时，就已经觉得很好用了。v1.1版本是7月初发布的，使用了两周后，发现这个版本确实更厉害，用起来也更顺手。接下来介绍一下这套组合拳里每个skill的功能。

grill-with-docs

使用这个技能，就是和AI进行多轮对话，AI通过“拷问”的方式，把需求聊得明明白白。同时，在这个过程中可以进一步明确各种术语的含义，并会及时更新到CONTEXT.md。如果过程中有涉及架构决策的讨论，也会被记录下来，这就是所谓的Architecture Decision Record（ADR）。

如果想要工程性地使用AI编程，ADR是非常重要的一部分，因为AI在写代码之前，还需要掌握历史决策、设计原因、不能随便改变的约束，以及一些不能从代码中推导出来的业务背景。

grill-with-docs的“前身”叫做grill-me。当第一次接触到grill-me，看到它的完整内容时，相信很多人都会为之一振。现在的版本，这个skill的全部内容一共才八句话。

而两三个月前，这个技能总共只有三句话。在当时一众特别“臃肿”的skills中，它算是一股清流。极简的同时，还挺好用，它真的可以通过一步步追问，帮你把问题或需求梳理清楚。这就是所谓的大道至简。

来看一下实际使用场景。用之前写openSpec时的音乐节案例来演示。首先，直接把之前的问题搬过来：

grill-with-docs或grill-me的核心工作准则之一，就是一次只会问一个问题。每问出一个问题，它还会给出自己的推荐答案以及推荐理由。

比如它问出的第一个问题是这样的：

本意是想要选择“一次展示多个乐队”，但又想起也看过一些乐队的专场，所以选择了“两种都支持”。

接着第二个问题询问用户范围，是单用户还是多用户。它推荐选择单用户，并给出了三个理由。于是选择了单用户。

第三个问题是关于海报怎么“生成”。按照它的建议，选择了方案C。

然后，它会提示出现了一个冲突，需要决策来帮助解决。这里选择了“模板为主+AI可选（自带key）”的方式。

接着第四个问题，确认海报上展示的字段。

后续的问题就不一一展示了，只展示一些觉得值得体现的问题。比如第八个问题，它要把“AI主视觉”这个模糊的词聊透，要让它明白AI到底要承担海报里的哪些部分。

第15个问题，问的是关于“日期格式+时间精度”的问题。

在问要给这个产品取什么名字时，写了“歪歪和Max的音乐记忆”。它敏锐地察觉到这是两个人，与最开始的单用户出现了冲突，于是再次让进行冲突解决。

最后，经过20个问题的“拷问”后，完成了需求的确认。

这就是/grill-with-docs的功能演示。所有问题问完之后，再去看项目中的文件，会发现有了一些变化。比如，CONTEXT.md文件中多了“术语”解释，ADR目录下也多了几个“架构决策”。

/to-spec

接下来是组合拳的第二招“to-spec”。直接调用/to-spec技能，它就会基于前面讨论的需求，自动整理成一份结构化的Spec文档。

规范文档放在这个路径下：.scratch/music-poster/spec.md。整个文档好几百行，分为这几个章节：

• Problem Statement
  ：描述要解决的问题，以及为什么需要这个功能。

• Solution
  ：描述整体解决方案和功能流程。

• User Stories
  ：使用用户故事的形式明确具体需求，让AI理解“谁、要做什么、为什么做”。

• Implementation Decisions
  ：记录技术实现方案，包括架构设计、技术选型、数据模型以及关键设计约束。

• Testing Decisions
  ：明确测试范围、测试策略以及核心测试边界。

• Out of Scope
  ：明确当前版本不做什么，避免AI自行扩展需求。

• Further Notes
  ：补充优先级、风险以及未来演进方向。

简单来说，/to-spec做的事情就是把已经讨论明确的需求，转换成一份结构化、可执行的软件开发规范。后续就可以基于这份Spec完成代码实现。

现在有了明确的计划，接下来上场的就是/to-tickets，把计划拆分为详细的任务。

/to-tickets

直接调用/to-tickets就可以把spec.md拆分为一个个具体的任务。

一共拆成了12个小任务，每个任务里面还有多个子任务。

/to-tickets还会贴心地告诉你这些任务之间的依赖关系，哪些任务可以并行启动。

把任务拆分好之后，接下来就到了代码实现环节，也就是该/implement上场表演了。

/implement

在执行/implement之前，还有一个小技巧，也是在视频里学到的。

当有了详细的任务之后，在进入编码实现之前，可以先做一次/clear操作，把当前的上下文清空，给后续的编码实现环节留下足够的上下文。

执行完/clear操作之后，可以使用/implement去逐个实现每个issues，也可以一把都给到/implement让它逐个实现。剩下的就是让它慢慢跑着。

从GitHub上看，/implement其实是一个组合技能，里面使用了/tdd做代码实现和/code-review做代码评审。也就是说，在/implement搞完之后，不需要再主动调用/code-review做代码评审了。

它闷着头搞了一个多小时后，最后成品的核心功能就长这样。如果后续要修改，比如想要在输入表演者的地方支持批量输入，以逗号进行分割，再次从/grill-with-docs开始使用即可。

在这个过程中，如果有值得记录下来的技术决策，它也会主动提醒落下来。最终又会在.scratch目录下新生成一个目录，里面新生成一套spec和issues。

/wayfinder

如果说/grill-with-docs是/grill-me的升级版，那么/wayfinder就是再次升级的版本。作者本人对这个命令也颇为偏爱，甚至专门为它录制了一期视频。

那么/wayfinder和/grill-with-docs之间的区别是什么呢？根据作者表达的意思，/wayfinder是帮你找到正确路线，是一个探索和规划的动作；/grill-with-docs是审问你已经有的方案，确保方案和已有项目知识一致，属于验证和沉淀。

而且作者在视频里提到的一个点很值得注意：他会在一些非技术的场景下使用这个命令去探索实施路径。基于这个提示，也计划用它来探索一个和技术无关的事情——跑步。

首先，它进行了一些基础询问，比如目前的跑量和跑步经验，让它知道是小白还是老手，还询问了每周能跑几天，方便制定具体的计划。

另外，在输出内容里可以看到“grill”关键词。收集到这些基础信息之后，它给出了一个“整体路径”的路线图。

先看看它现在给出的输出。这是map.md的内容，里面有一个章节是“not yet specified”，即尚未明确的内容。生成的这7个子任务，就是围绕这些尚未明确的内容展开。

从前面的路线图可以知道，01和04是整个任务的起点。所以可以分别看一下这两个子任务。01是对用户的一些基础信息的进一步询问，04是依据什么模型推导出配速区间。

从跑步经验来看，01和04之间确实没有直接的关联关系。接着从01开始继续/wayfinder，它会继续追问一系列问题，甚至细到了跑鞋服役公里数的维度。

01询问完成后，它也会主动去更新对应的md。基于前面跑鞋的问题，选择的是“大于600km”，于是它追加了一个换鞋的任务。在用/wayfinder执行“换鞋”任务时，它基于选择推荐了几双跑鞋，还建议不要买碳板竞速鞋。

最后，经过了一轮又一轮的对话，不断深入地掌握了当前情况和对最终目标的明确，在31个问题之后，它给出了这三个月一共12周的完整训练计划，以及对应的恢复计划与营养安排。此外，还有很多其他关键输出，比如配速区间、进度观察等，由于篇幅原因就不再一一截图了。

此时，再去看map.md，之前所有的待定点都完成了。

而上面产生的所有文档，都是从这个模糊的问题开始的：

所以，思路不妨打开一些。遇事不决，就用/wayfinder来帮你梳理思路。可以是技术上的思路，但也不止于技术上的思路。它解决的其实不是“答案在哪里”，而是“我应该如何一步步找到答案”。希望这个案例也能打开你的思路。如果感兴趣的话，不妨找一个小需求，打一遍这套组合拳。