mattpocock/skills 到底能提升多少 AI 编程效率？我翻完公开实测、 Token 数据和真实用户反馈
mattpocock/skills 是 Matt Pocock 公开的一组 AI 编程技能。它不是一个单独的代码优化器，而是一组可以组合使用的工作流，包括需求澄清、代码审查、测试驱动开发、问题诊断、架构分析和上下文交接等。
项目的核心思路不是让 Agent 全自动接管开发，而是把一些工程习惯写成小型技能，让 Claude Code、Codex 等 Agent 在特定阶段按照固定流程工作。官方将其定位为“小、容易修改、可组合”的工程技能。
截至 2026 年 9 月 2 日，我没有在公开资料中找到一组完整的：
- 同一批真实代码任务
- 同一个模型
- 不使用 mattpocock/skills 的对照组
- 使用 mattpocock/skills 的实验组
- 对比成功率、缺陷率、开发时间、 Token 和成本
- 多次重复并提供统计显著性
因此，现阶段能整理到的证据主要来自多模型实际运行、GitHub Issue 中的长期使用反馈、 Token 估算、社区实测，以及项目后续针对实际问题所做的修改。
官方项目说明：目标是约束工作流，没有公布整仓效果基准
测试来源名称：mattpocock/skills 官方仓库
官方说明，这些技能主要用来处理 Coding Agent 中几类常见问题，包括需求理解偏差、输出过于冗长、代码无法正常工作，以及代码库复杂度持续增加。
例如 /grill-me 和 /grill-with-docs 会在编码前进行需求访谈；/tdd 要求模型按照测试驱动方式工作；代码审查技能则把审查拆成代码规范和需求符合度两个方向。
官方还提出，共享领域语言可以减少 Agent 的冗长表达，并称 Agent 因为能够使用更简洁的项目语言，也会减少用于思考的 Token 。
但官方 README 没有给出这部分效果的量化基准，例如没有公开：
| 指标 | 官方整仓数据 |
|---|---|
| 编码任务成功率提升 | 未提供 |
| 缺陷率下降 | 未提供 |
| 开发时间缩短 | 未提供 |
| 输入 Token 变化 | 未提供 |
| 输出 Token 变化 | 未提供 |
| API 成本变化 | 未提供 |
| 有技能 / 无技能对照实验 | 未提供 |
因此，官方公开资料主要说明设计目标和工作方式，不能直接换算成“安装后成功率提升多少”或者“能节省多少 Token ”。
第三方多模型实测：一个月记录 1,027 次请求，重型 Agent 工作流单日花费达到 30～35 美元
测试来源名称：Reddit — StrataBlock 多模型实际运行测试
网页地址：www.reddit.com/r/WebAfterA…
测试者将 mattpocock/skills 接入 VS Code，通过 StrataBlock 的 OpenAI 兼容接口切换多个模型。
帖子列出的模型包括 Opus 4.8、Sonnet 5、Gemma 4、GPT-5.6 等。实际运行的技能包括 /grill-with-docs、/tdd 和 /improve-codebase-architecture。
一个月测试窗口中的公开数据为：
| 指标 | 数据 |
|---|---|
| 请求总量 | 1,027 次 |
| 重型测试日单日成本峰值 | 30～35 美元 |
| 空闲日成本 | 接近 0 美元 |
| 记录指标 | 输入 Token 、输出 Token 、缓存 Token 、延迟、状态码、单请求成本 |
测试者特别提到，进行测试驱动循环或者大型代码库扫描时， Token 使用量会上升得很快。
模型表现也存在差异。帖子称 Opus 4.8、Sonnet 5、GPT-5.6 等前沿模型能够完成复杂技能、结构化输出和递归式 Agent 工作流；Gemma 4、Kimi K2.5、Grok 4.3 等模型的结果差异更大，部分模型需要额外修改提示词才能遵循技能步骤。
需要区分的是，这 1,027 次请求和 30～35 美元单日峰值来自作者整个多模型测试环境，不是“mattpocock/skills 单独产生的成本”。
该测试也没有设置“无 skills”对照组，所以原作者没有得出“技能让编码成功率提高多少”或“使用技能能节省多少 Token ”的结论。
GitHub 跨模型实测：弱模型会把完整访谈压缩成一个问题
测试来源名称：GitHub Issue #729 — grill-me 跨模型长期使用反馈
一名开源 Agent 编排器维护者把 grill-me 改造成规划器中的提示模块。该规划器可以连接 Claude Code、Codex、OpenCode，以及约 25 个 API 提供商，因此积累了一批跨模型运行数据。
他报告了一个重复出现的结果：在能力较弱的模型上，原本要求“持续访谈直到双方形成共同理解”的提示，会退化成只问一个问题，然后直接进入方案整理。
测试者第一次采用的修复方式，是强制至少询问三个问题。随后为了重新接近原版 grill-me 的设计，他删除了这个硬性限制，原来的失败行为随即再次出现。
最后有效的修改不是继续增加计数器，而是加入两条提示约束：
- 仍有重要设计分支没有探索时，不允许进入方案阶段；
- 从访谈切换到方案阶段时，必须用一句话说明为什么可以结束访谈。
测试者报告，这种纯提示词修改能够解决自己观察到的问题。
该 Issue 没有公开具体任务数量、成功率或统计显著性，因此它属于长期跨模型现场反馈，不是标准化基准测试。
GitHub Token 估算：部分工程技能正文合计约 11,594 个 Token
测试来源名称：GitHub Issue #808 — Token usage estimates
2026 年 8 月，一名用户提出给每个技能增加 Token 使用量预估，并使用 o200k_base 对技能文件进行了估算。
他明确指出，实际 Token 量会受到模型影响，这些数字只是统一编码方式下的近似值。
公开的工程类技能数据如下：
| 技能 | 元数据 Token | 正文 Token | 可选内容 Token |
|---|---|---|---|
| ask-matt | 21 | 2,691 | 950 |
| grill-with-docs | 29 | 18 | 0 |
| triage | 32 | 1,510 | 2,850 |
| improve-codebase-architecture | 31 | 1,290 | 1,595 |
| setup-matt-pocock-skills | 43 | 1,644 | 3,216 |
| to-spec | 29 | 584 | 0 |
| to-tickets | 53 | 1,170 | 0 |
| implement | 15 | 67 | 0 |
| wayfinder | 45 | 2,620 | 0 |
| 合计 | 298 | 11,594 | 8,611 |
这些数字测量的是技能文件自身的文本量，不是一次开发任务一定会额外消耗的 Token 。
例如某些技能只会在需要时加载部分内容，技能执行过程中又可能调用代码库、子 Agent 或其他工具。因此不能把 11,594 或 8,611 直接当作“一次使用的额外 Token 成本”。
原 Issue 的目的也是增加调用前的成本预估，而不是证明这些技能能够节省 Token 。
Reddit 长期用户反馈：技能从约 30 个减少到 5～6 个后，使用体验更轻
测试来源名称：Reddit — I deleted most of my Claude skills last week
网页地址：www.reddit.com/r/ClaudeAI/…
这名用户长期给 Claude 安装大量 Skills、MCP 和自定义工作流。
他称，当技能数量增加到大约 30 个时，每次交互都会变慢。Claude 在执行一个简单任务前可能先检查十余项内容，一个简单问题也可能先产生约 400 个 Token 的流程化前言。
之后他开始删除技能，并在这个过程中接触 mattpocock/skills。他认为这套仓库与大型技能包不同，每个技能范围较小，使用的工程词汇也较集中。
最终他的活跃技能数量下降到约 5～6 个，并报告 Claude 和自己的使用体验都变得更快，也更容易知道当前到底加载了哪些规则。
需要注意，这不是“安装 mattpocock/skills 前后”的严格对照。他同时删除了大量其他技能，因此无法把性能变化单独归因于 mattpocock/skills。
这份反馈支持的是“小而少的技能集合”这种使用方式，而不是某个具体技能的编码质量提升比例。
GitHub 用户实测：grill-me 与架构分析组合后，访谈可能膨胀到数十甚至数百个问题
测试来源名称：GitHub Issue #274 — improve-codebase-architecture 实际使用反馈
一名用户原本长期使用 improve-codebase-architecture，但在该技能加入 grill-me 风格的访谈流程之后停止使用。
他的实际反馈是，一个类似“如何减少两个模块之间的摩擦”这样的架构问题，在完成代码探索后，Agent 会很快选择一个方案，并围绕该方案继续询问大量问题。
用户给出的量级是：
| 指标 | 用户反馈 |
|---|---|
| 单次访谈问题数量 | 数十到数百个 |
| 极端情况下的访谈时间 | 约 2 小时 |
| 最终处理方式 | 停止使用该组合流程 |
这里的“数十到数百个问题”和“2 小时”是用户描述的实际体验，没有附日志统计或独立复现。
原作者没有在该 Issue 页面公布成功率、质量评分或 Token 对照数据。
GitHub 用户实测：GPT-5.5 多次跳过确认，直接开始实现
测试来源名称：GitHub Issue #240 — GPT-5.5 与 grill-me
另一名用户报告，在 GPT-5.5 上已经多次遇到同一种情况：当模型认为没有更多问题可以询问时，会直接开始实现代码，而不是停止访谈等待用户决定下一步。
他的处理方式是在 grill-me 末尾增加一条明确约束：没有更多问题后，不得未经允许进入实现阶段，而应询问用户下一步操作。
用户称修改后有改善。
该测试没有给出出现次数、修改前后成功率或者任务样本量，因此只能作为模型遵循技能指令时的实际失败案例。
第三方结构复核：本质是小型单用途提示文件，不是复杂 Agent 框架
测试来源名称：Hacker News — 热门 Skills 仓库结构分析
网页地址：news.ycombinator.com/item?id=483…
一篇 Hacker News 讨论对当时 GitHub 热门的多个 Skills 仓库进行了结构比较。
分析者统计，当时的 mattpocock/skills 大约由十个小型、单用途的 SKILL.md 文件组成，与包含上百个技能、Agent 定义、Hooks 和 MCP 配置的大型技能框架属于不同类型。
分析者认为，这类技能的核心仍然是带有调用约定的提示文本。其价值主要来自工作流和工程经验的封装，而不是新的模型能力。
这篇分析没有运行编码任务，也没有提供成功率或 Token 对照，因此属于结构复核，而不是性能基准测试。
Hacker News 上也存在实际用户的正面反馈。一名开发者称自己会用 grill-me 配合 Codex 和 Linear，在编码前通过多轮交流生成更详细的需求说明，并认为需求说明比大型代码改动更容易检查，后续实现也更符合自己的意图。该反馈同样没有给出时间、成功率或成本数据。
官方后续修正：增加确认门槛，并重新划分“事实”和“决策”
测试来源名称：mattpocock/skills 官方 CHANGELOG
项目后续确实修改了 grilling 工作流。
官方更新记录增加了一个明确的确认门槛：在用户确认双方已经形成共同理解之前，Agent 不允许开始执行方案。
同时，项目把问题划分为两种：
- 事实：Agent 应该自己通过代码库或环境查询；
- 决策：必须交给用户回答。
官方解释，旧提示中“能够通过代码库回答的问题就自己探索”的表述，在其他技能调用 grilling 时可能被模型理解成可以自行回答用户本应决定的问题，因此后来进行了拆分。
这与 GitHub 中出现的“Agent 自己向前推进”“没有等待用户确认”等反馈属于同一类行为问题。
官方后续改版：13 个问题从约 13 轮改成约 3 轮，但问题本身没有消失
测试来源名称：mattpocock/skills 官方 CHANGELOG — grilling 轮次改版
后续版本又改变了 grilling 的交互方式。
旧版强调一次只询问一个问题。新版先构建“决策树”，然后在同一轮中询问所有前置条件已经确定、彼此不会相互影响的问题。用户回答后，再计算下一轮问题。
官方给出的具体例子是：
| 方式 | 13 个问题需要的交互轮次 |
|---|---|
| 旧版逐个询问 | 约 13 轮 |
| 新版按决策树分组 | 约 3 轮 |
这里减少的是交互轮次，不是问题总数量。
官方还允许把环境事实交给后台子 Agent 查询，让与这些事实无关的问题继续进行。更新目标是减少串行等待，而不是减少所有推理、工具调用或者总 Token 量。
总结
目前 mattpocock/skills 最缺的仍然是一组标准化的独立 A/B 基准测试。
没有公开数据能够证明，面对同一批真实代码任务，在模型、上下文和任务完全一致的情况下，安装这套 Skills 可以让成功率提高多少、缺陷率下降多少、开发时间缩短多少。
现有公开数据更多证明了另一件事：这些技能确实会改变 Agent 的工作方式。
第三方一个月多模型测试记录了 1,027 次请求，前沿模型能够执行复杂技能，但能力较弱的模型更容易偏离技能指令；GitHub 的跨模型反馈也记录了 grill-me 在弱模型上退化成“问一个问题就进入方案”的情况。
成本方面，也没有证据表明整套 Skills 是一个省 Token 工具。第三方测试明确提到，测试驱动循环和大型代码库扫描会快速增加 Token 使用；社区对部分工程技能文件的静态估算已经达到 11,594 个正文 Token 和 8,611 个可选内容 Token，虽然这些内容并不会在每次任务中全部加载。
实际使用效果也取决于组合方式。有人把技能数量从约 30 个减少到 5～6 个后获得了更轻的工作流；也有人在架构分析中加入 grilling 后遇到数十甚至数百个问题，单次访谈持续约 2 小时。
项目后续持续修改 grilling，增加确认门槛、拆分事实和决策，并把 13 个问题从约 13 轮交互压缩到约 3 轮。这些更新表明项目确实在根据真实使用中的失败模式调整工作流。
因此，根据目前能够找到的公开资料，mattpocock/skills 更适合被看成一套工程流程约束工具，而不是已经通过公开基准测试证明能够系统性提升 AI 编程性能的优化器。
它公开展示出的价值主要集中在需求澄清、流程纪律、代码审查和工程习惯复用。至于“成功率提升多少”“能省多少 Token ”“开发速度提高多少”，现阶段都缺少足够的独立对照数据。
