简介说明
很多人第一次使用 AI 编程工具时，都会经历一个阶段：刚开始觉得效率非常高，描述一句需求，代码很快就生成出来了。但项目一旦变大，问题也会逐渐出现。
需求没有问清楚，代码结构越来越乱；功能看起来完成了，却没有测试；一个 Bug 反复修改，最后连原本能运行的部分也被改坏了。AI 写代码本身并不难，难的是让它按照一个可靠的工程流程持续工作。
mattpocock/skills 解决的正是这个问题。
它不是一个完整的自动开发框架，也不是强迫你遵守固定步骤的项目管理系统，而是一套可以自由组合的 AI 编程技能。你可以根据当前任务，选择需求访谈、TDD、原型设计、代码审查或 Bug 诊断等能力，把它们插入自己的开发流程。
这也是它最实用的地方：AI 负责提高执行效率，开发者仍然掌握节奏和决策权。
一套可组合的工程技能
项目的官方定位是：
Skills For Real Engineers
仓库中的 Skills 主要分为 Engineering 和 Productivity 两大类。
Engineering 类技能更偏向软件开发，包括：
setup-matt-pocock-skills：初始化项目工程配置grill-with-docs：通过持续提问澄清需求，并整理上下文文档to-spec：将当前讨论整理为技术规格或项目方案to-tickets：把计划拆分成可以执行的任务implement：根据规格或任务开始实施tdd：使用测试驱动开发推进功能prototype：先制作原型，验证交互和设计方向code-review：从代码规范和需求实现两个角度审查改动diagnosing-bugs：按照步骤定位复杂 Bug 和性能问题improve-codebase-architecture：扫描代码库，寻找架构改进机会domain-modeling：建立项目中的领域模型和统一术语resolving-merge-conflicts：辅助处理 Git 合并或变基冲突
Productivity 类技能则适合更广泛的工作场景，例如：
grill-me：针对计划、方案或想法进行深入追问handoff：整理当前工作，生成交接文档teach：围绕一个主题生成分阶段、可互动的学习内容to-questionnaire：把暂时无法决定的问题整理成问卷wait-what：当需求没有被正确理解时，重新解释和对齐
这些技能之间并不是互相绑定的。你可以只安装 tdd，也可以把需求访谈、规格设计、任务拆解和测试开发串成一条完整链路。
安装方式
对于 Claude Code，可以直接安装官方插件：
claude plugins install mattpocock-skills
也可以在 Claude Code 会话中执行：
/plugin install mattpocock-skills
如果使用 Codex、OpenCode 或其他支持 Skills 的 AI 编程工具，可以通过 skills 安装器：
npx skills@latest add mattpocock/skills
安装过程中可以选择需要的技能以及目标 AI 编程工具。项目文档建议把 setup-matt-pocock-skills 一并安装，因为其他工程技能需要依赖它完成项目初始化。
安装完成后，在项目目录中执行：
/setup-matt-pocock-skills
初始化时，工具会询问几个关键问题，例如：
- 项目使用 GitHub、Linear 还是本地文件管理任务
- Issue 使用哪些标签
- 生成的文档保存在哪里
这一步只需要针对每个项目执行一次。完成之后，AI 就能按照项目约定使用后续技能。
一条比较实用的开发流程
以“开发一个秒杀系统”为例，比较合理的使用方式并不是直接让 AI 开始写代码，而是先把问题拆开。
1. 先用 grill-me 把需求问清楚
可以先执行：
/grill-me
它不会急着生成代码，而是围绕业务目标、用户角色、核心流程、异常情况和边界条件持续提问。
例如秒杀系统至少需要明确：
- 商品库存是在数据库中扣减，还是使用缓存预扣
- 用户重复提交时如何处理
- 秒杀开始前是否允许进入页面
- 库存扣减失败后如何回滚
- 是否需要限制每个用户的购买数量
- 高并发下订单和库存的最终一致性如何保证
这些问题如果一开始没有说清楚，后面生成的代码很可能只是“看起来能用”。
如果项目涉及较多业务术语和架构决策，可以使用：
/grill-with-docs
它除了提问，还会将讨论结果整理为项目上下文、术语说明和架构决策记录。对于长期维护的项目来说，这类文档比一次性的聊天记录更有价值。
2. 用 to-spec 生成技术规格
需求讨论完成后，可以执行：
/to-spec
它会根据当前上下文整理出一份规格文档，内容通常包括：
- 用户故事
- 功能范围
- 技术约束
- 数据结构
- API 设计
- 模块边界
- 异常流程
- 不做什么
需要注意的是，当前仓库使用的是 to-spec，它并不是传统意义上只生成一份 PRD，而是更偏向可直接指导开发的技术规格。
3. 用 to-tickets 拆解任务
当规格已经比较明确后，可以执行：
/to-tickets
它会把较大的需求拆成多个可以独立推进的任务，并尽量标明任务之间的依赖关系。
例如秒杀系统可以拆成：
- 商品和库存模型
- 秒杀活动配置
- 库存预扣接口
- 幂等校验
- 下单流程
- 限流策略
- 压测脚本
- 监控和日志
这样的拆分比“帮我完成秒杀系统”更适合 AI 执行，也更容易在中途检查进度。
4. 用 prototype 先验证界面
如果任务包含后台管理页面或用户端页面，可以先运行：
/prototype
它适合在正式开发前验证页面结构和交互方式。对于设计方向不明确的页面，可以让 AI 先提供几种不同方案，再选择其中一种继续实现。
这一步尤其适合：
- 管理后台
- 数据看板
- 表单流程
- 复杂交互页面
- 移动端界面
先确认页面怎么用，再开始完善组件和业务逻辑，通常比写完一大堆代码后再返工更省时间。
5. 用 tdd 逐步实现
开始编码时，可以执行：
/tdd
它强调 Red-Green-Refactor，也就是：
1. 先写一个会失败的测试
2. 编写刚好让测试通过的实现
3. 再整理代码结构
4. 继续推进下一个垂直切片
对于 AI 编程来说，测试不仅是质量保障，也是非常重要的反馈渠道。没有测试时，AI 只能根据代码表面推测结果；有了测试，它可以通过明确的失败信息不断修正实现。
对于秒杀系统这类容易出现边界问题的功能，测试可以重点覆盖：
- 库存为零时不能继续下单
- 同一用户重复请求只能成功一次
- 并发请求下库存不能扣成负数
- 订单创建失败时库存处理符合预期
- 秒杀未开始或已结束时正确拒绝请求
代码写出来之后，还要继续管理
AI 编程最容易被忽视的一点，是“代码生成”并不等于“工程完成”。
code-review：分别检查规范和需求
可以使用：
/code-review
这个 Skill 会从两个方向审查代码：
- 是否符合项目规范，是否存在明显的代码异味
- 是否真正实现了原始需求和规格
这种双重检查很有必要。只看代码风格，可能忽略业务逻辑错误；只看功能是否完成，又容易放过耦合、重复代码和难以维护的结构。
diagnosing-bugs：处理那些改不好的 Bug
遇到复杂问题时，可以使用：
/diagnosing-bugs
它强调先建立反馈，再进行定位，而不是让 AI 不断尝试“可能的修复”。
一般会经历类似的过程：
- 复现问题
- 缩小范围
- 提出假设
- 添加日志或诊断信息
- 验证假设
- 修复问题
- 增加回归测试
这套流程看起来朴素，但正好可以避免 AI 在没有证据的情况下反复修改代码。
improve-codebase-architecture：定期给代码库做体检
项目变快以后，代码腐化也会变快。可以定期执行：
/improve-codebase-architecture
它会扫描代码库，寻找适合“加深模块”的位置，例如：
- 一个模块暴露了太多内部细节
- 多处代码重复实现同一逻辑
- 某个组件承担了过多职责
- 上层代码依赖了底层实现
- 测试只能通过复杂方式完成
这个 Skill 更像一份架构体检报告，而不是自动替你重构整个项目。最终改不改、先改哪一处，仍然需要开发者判断。
handoff：让工作可以交给下一个智能体
当一个 AI 会话快要结束，或者需要切换到其他工具时，可以使用：
/handoff
它会整理当前任务的背景、已经完成的内容、未解决的问题、关键决策和下一步建议。
这对于长任务尤其有用。否则每次切换 AI 工具，都需要重新解释项目背景，既浪费时间，也容易遗漏重要上下文。
teach 不只是写文档
这个项目还有一个比较特别的技能：
/teach
它可以根据项目代码、文档或指定资料，生成更具互动性的学习内容，而不是简单输出一篇说明文。
适合用来：
- 学习一个陌生开源项目
- 理解团队内部代码
- 熟悉新的技术概念
- 为新人制作上手材料
- 生成带练习和问答的课程
它的价值在于，学习过程不再是“AI 给你一篇长文”，而是可以围绕章节、问题、练习和反馈逐步推进。
项目的优点
1. 不强迫用户采用固定流程
它不像某些工作流框架那样，从需求到交付全部打包成一条不可调整的流水线。你可以只使用其中一个 Skill，也可以根据项目情况自由组合。
2. 更重视需求对齐
grill-me 和 grill-with-docs 解决的是 AI 编程里最常见的根本问题：双方以为已经理解了需求，实际上理解的不是同一件事。
3. 把工程经验变成可重复的流程
测试驱动、代码审查、调试、领域建模和架构设计，这些并不是 AI 时代才出现的概念。项目的价值在于把它们整理成 AI 可以执行的具体工作方式。
4. 技能文件透明、容易修改
通过 npx skills 安装时，技能会以普通文件的形式写入项目。开发者可以直接阅读、调整甚至创建自己的版本，不需要依赖黑盒逻辑。
5. 不绑定某一个模型
仓库设计目标是让这些 Skills 能够适配不同 AI 编程工具和模型。它关注的是工作方法，而不是某个模型的专属能力。
6. MIT 协议，使用限制少
项目采用 MIT License，适合个人项目、团队内部工具和商业开发场景使用。具体使用时仍应遵守所使用模型和第三方服务的许可条款。
项目的不足
1. 它不能替代开发者做技术决策
Skills 可以帮助提问、整理和检查，但无法保证最终方案一定正确。架构取舍、业务规则和安全边界仍然需要人来确认。
2. 前期沟通会变多
使用 grill-me 或 grill-with-docs 后，AI 通常不会马上写代码，而是先提出一系列问题。对于非常简单的小改动，这可能显得有些繁琐。
比较实际的做法是：小修复直接处理，涉及数据、权限、并发或模块边界的任务再使用完整流程。
3. 输出质量依赖项目上下文
如果项目缺少测试、缺少文档、目录结构混乱，AI 的判断也会受到影响。improve-codebase-architecture 能帮助发现问题，但不会自动消除所有历史负担。
4. 不同 AI 工具的支持程度可能不同
Claude Code 目前有官方插件安装方式。Codex 和其他工具主要通过 skills 安装器使用，而原生 Codex 插件仍在项目规划中。实际使用前，需要确认目标工具对 Skills、命令和项目级文件的支持方式。
5. 不是所有技能都适合一次性使用
如果把需求访谈、规格、任务拆解、TDD、审查和架构分析全部套在一个很小的任务上，反而会增加流程成本。它更适合按问题选择工具，而不是把技能数量当成效率指标。
推荐的使用方式
如果刚开始接触，可以采用这条轻量流程：
/setup-matt-pocock-skills /grill-me /to-spec /tdd /code-review
如果是长期维护的正式项目，可以增加：
/grill-with-docs /to-tickets /implement /diagnosing-bugs /improve-codebase-architecture
需要切换 AI 工具或交给其他开发者时，再补充：
/handoff
最重要的是，不要把这些命令当成必须全部执行的仪式。它们更像一组工程工具：需求模糊时使用提问，设计不确定时做原型，代码不稳定时加强测试，Bug 难以复现时进入诊断流程。
适合哪些人
mattpocock/skills 比较适合：
- 使用 Claude Code、Codex 或 OpenCode 开发项目的人 - 希望让 AI 遵循工程流程，而不是只生成代码的人 - 正在维护中大型代码库的开发者 - 想系统使用 TDD、代码审查和架构设计的人 - 希望把自己的开发方法沉淀成 AI 工作流的人 如果只是偶尔让 AI 修改一行配置、写一个简单脚本，完整安装这套技能可能没有必要。
最后
mattpocock/skills 的核心价值，不是让 AI 生成更多代码，而是让它在生成代码之前多问几个关键问题，在生成代码之后多做几轮验证。
它把需求澄清、统一术语、技术设计、测试、审查、调试和交接这些原本依赖个人经验的环节，整理成了可以反复调用的 Skills。开发者不需要放弃自己的工作习惯，也不必接受一套封闭的自动化流程，只需要在合适的时机调用合适的工具。
对于已经在使用 AI 编程助手的人来说，这个项目值得尝试的地方并不是“能不能帮你写出一个页面”，而是它能不能让你的项目在快速开发之后，依然保持清晰、可测和可维护。
下载地址
https://github.com/mattpocock/skills
https://pan.baidu.com/s/11isEjAZN09z39CW-SgZBjg?pwd=ugup 提取码: ugup
https://pan.quark.cn/s/472559f3d319
评论抢沙发