一套长期使用的AICoding组合拳：小而美典范
来源：互联网 2026-07-31 16:35:04GitHub上mattpocock/skills仓库（176k星）提供一套AI编程工作流，包含多个极简skill，仅占660个tokens。组合使用时，/grill-with-docs通过多轮对话明确需求并生成ADR，/to-spec转化为结构化文档，/to-tickets拆分为任务，/implement自动编码并评审。该工作流还可用于非技术场景，如制定跑步
本文介绍一套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，也可以一次性将所有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来帮你梳理思路。可以是技术上的思路，但也不止于技术上的思路。它解决的其实不是“答案在哪里”，而是“我应该如何一步步找到答案”。希望这个案例也能打开你的思路。如果感兴趣的话，不妨找一个小需求，打一遍这套组合拳。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
同类更新
更多
热游推荐
更多-
- DreamStudio
- Android/ | AI绘图
- 2026-06-30
-
-
- Playground AI
- Android/ | AI绘图
- 2026-06-30
-
- Adobe Firefly
- Android/ | AI绘图
- 2026-06-30
-
-
-
- Leonardo AI
- Android/ | AI绘图
- 2026-06-30
-
- Stable Diffusion
- Android/ | AI绘图
- 2026-06-30
