🔧 Matt Pocock Skills For Real EngineersMatt Pocock Skills For Real Engineers

📖 一、项目概述：为什么需要这些Skills

Matt Pocock的skills项目是一个面向AI编程助手（Claude Code、Codex等）的技能框架，核心理念是解决Agent编码的四大失败模式。

1.1 与GSD/BMAD/Spec-Kit的区别

"Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve."

Matt的Skills设计哲学：

• 小 (Small) - 每个Skill专注单一职责
• 易适配 (Easy to adapt) - 灵活可修改
• 可组合 (Composable) - Skills可以自由组合
• 模型无关 (Model-agnostic) - 适用于任何模型

❌ 二、四大失败模式深度解析

2.1 失败模式#1：Agent没做对的事

问题本质：沟通不对齐。你以为Agent理解了你的需求，但实际上它完全理解错了。

解决方案：Grilling Session（严苛追问环节）

Matt设计了两种 grilling skill：

1. /grill-me - 通用版本
2. /grill-with-docs - 增强版本，增加了挑战领域模型、精化术语、实时更新CONTEXT.md等功能

"Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one."

2.2 失败模式#2：Agent太啰嗦

问题本质：Agent和人类使用不同的术语体系，导致沟通冗长且低效。

解决方案：Shared Language（共享语言）

Matt借鉴了Eric Evans在《领域驱动设计》中的"Ubiquitous Language"概念：

BEFORE: "There's a problem when a lesson inside a section of a course 
        is made 'real' (i.e. given a spot in the file system)"
AFTER:  "There's a problem with the materialization cascade"

共享语言的好处：

• 变量、函数、文件命名一致 - 使用共享语言
• 代码库更易导航 - Agent理解术语
• Token消耗更低 - Agent无需反复解释概念

2.3 失败模式#3：代码不工作

问题本质：没有快速的反馈循环。Agent写完代码后，不知道它是否能运行。

"Without feedback on how the code it produces actually runs, the agent will be flying blind."

解决方案：完整的反馈循环体系

• 静态类型 - TypeScript类型检查
• 浏览器访问 - 实时验证UI
• 自动化测试 - TDD红绿重构循环
• 调试技能 - /diagnose skill

2.4 失败模式#4：我们建了一个泥球

问题本质：Agent加速了开发，但同时也加速了软件熵增。代码库以前所未有的速度变得更加复杂。

"Invest in the design of the code every day."

解决方案：日常架构改进

• 每隔几天运行一次 /improve-codebase-architecture
• 使用 /zoom-out 保持全局视角
• 在 /to-prd 中提前考虑模块设计

⚙️ 三、核心Skill深度分析

3.1 /grill-me 和 /grill-with-docs

触发条件：

• 用户说"grill me"
• 用户想要压力测试计划
• 用户想要被追问设计细节

执行流程：

1. Agent逐个提出问题
2. 等待用户反馈后再继续下一个问题
3. 如果问题可以通过探索代码库回答，则探索代码库

3.2 /tdd 红绿重构循环

"Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't."

好测试 vs 坏测试：

// ✅ GOOD: 测试行为
test("user can checkout with valid cart", async () => {
  const cart = createCart();
  cart.add(product);
  const result = await checkout(cart, paymentMethod);
  expect(result.status).toBe("confirmed");
});

// ❌ BAD: 测试实现细节
test("checkout calls paymentService.process", async () => {
  const mockPayment = jest.mock(paymentService);
  await checkout(cart, payment);
  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
});

垂直切片 vs 水平切片：

❌ WRONG (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

✅ RIGHT (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3

3.3 /diagnose 系统化调试

调试六阶段：

Phase	名称Name	关键行动Key Actions
1	构建反馈循环	这是技能本身
2	复现	运行循环观察bug
3	假设	生成3-5个排名假设
4	验证	一次改一个变量
5	修复	写回归测试后再修复
6	清理	删除调试代码，总结

"If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause — bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you."

3.4 /improve-codebase-architecture 架构改进

核心概念：深度模块（Deep Modules）

"The best modules are deep. They allow a lot of functionality to be accessed through a simple interface."

删除测试：

"Imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep."

3.5 /to-prd 和 /to-issues 需求拆解

PRD模板结构：

1. Problem Statement - 用户视角的问题
2. Solution - 用户视角的解决方案
3. User Stories - 详细的用户故事列表
4. Implementation Decisions - 实现决策
5. Testing Decisions - 测试决策
6. Out of Scope - 范围外
7. Further Notes - 其他备注

3.6 其他Skills概览

Skill	用途Purpose	触发条件Triggers
/zoom-out	全局视角	需要理解代码如何融入更大系统
/prototype	原型验证	需要验证设计决策
/triage	问题分流	管理issue工作流
/caveman	极致压缩通信	需要减少Token消耗
/write-a-skill	技能创作	需要创建新Skill

🧠 四、方法论提炼

4.1 Skill可组合性设计

Matt Skills的可组合性体现在：

• 松耦合 - Skills通过共享配置协作，而非硬编码依赖
• 共享配置层 - CONTEXT.md、ADR提供跨Skill上下文
• 渐进式披露 - 基础功能在SKILL.md，细节在引用文件
• 硬依赖 vs 软依赖：
  • 硬依赖：必须先运行 /setup-matt-pocock-skills
  • 软依赖：优雅降级，无配置也能工作

4.2 ADR决策记录的用法

创建时机（三条件同时满足）：

1. 难以逆转 - 后期改变成本高
2. 缺乏上下文会令人困惑 - 未来读者会疑惑"为什么这样做"
3. 真实权衡的结果 - 有明确的替代方案并选择了一个

4.3 垂直切片思想

核心原则：

• 每个切片是可独立部署的最小功能单元
• 切片穿过所有层（schema/API/UI/tests）
• 完成的切片可演示或验证

4.4 与GSD/BMAD/Spec-Kit的对比

维度Dimension	GSD/BMAD/Spec-Kit	Matt Skills
控制权Control	流程拥有者，用户失去控制	用户保持完全控制
灵活性Flexibility	刚性强	每个Skill小而独立
学习曲线Learning Curve	高	低，可选择性使用
适用场景Use Case	标准化大型团队	个人开发者、灵活团队

💡 五、对看宝AI的启发

5.1 Skill系统的借鉴

• 小而专注 - 每个Skill只做一件事
• 共享配置层 - Agent通过共享的"上下文文档"协作
• 触发描述 - 每个Skill的description明确何时触发
• 渐进式文档 - SKILL.md是入口，引用文件提供深度

5.2 Grill机制在学习任务中的应用

当前问题：用户请求学习时，可能没有想清楚具体需求。

Grilling应用示例：

用户: "帮我学习TypeScript"
Agent: "在开始之前，让我确认一下：
1. 你目前的TypeScript水平是？
2. 学习TypeScript的主要目的是？
3. 你计划投入多少时间？
..."

5.3 共享语言对记忆系统的启发

Shared Language应用：

• 在记忆中维护项目的"术语表"
• 学习笔记使用一致的术语
• 新概念自动添加到术语表

5.4 垂直切片对任务拆解的启发

垂直切片应用：

任务：构建一个博客系统
↓
垂直切片：
Slice 1: 文章列表页 + 后端API + 数据库 + 基础测试
Slice 2: 文章详情页 + 评论功能
Slice 3: 文章编辑功能 + 富文本编辑器
...

🔗 相关链接

官方资源Official Resources

• GitHub仓库
• Matt Pocock Newsletter
• skills.sh安装器

引用书籍Referenced Books

• 《The Pragmatic Programmer》- David Thomas & Andrew Hunt
• 《Domain-Driven Design》- Eric Evans
• 《Extreme Programming Explained》- Kent Beck
• 《A Philosophy Of Software Design》- John Ousterhout

相关笔记Related Notes

• skVM - Skills虚拟机深度研究 - 上交大IPADS的Skills系统研究
• Skill Graphs 2.0 - 技能图谱化设计
• nuwa-skill造人术 - 思维蒸馏

💭 思考与实践

思考Reflections

1. Grilling vs 直接执行：Grilling机制是否会降低效率？如何在速度和深度之间取得平衡？

   我的看法：对于小型任务，直接执行可能更快。但对于复杂系统，Grilling可以避免返工。实际上，Grilling节省的时间往往超过它花费的时间。

2. Shared Language的维护成本：CONTEXT.md需要持续维护，如何确保它不会过时？

   建议：每次Grilling会话后自动更新、新概念出现时实时添加、定期回顾清理。

3. 垂直切片的粒度：如何确定"薄"切片的边界？

   Matt的建议：可演示或可验证，这给了我们一个客观标准。

实践计划Action Plan

1. 为看宝AI创建Grilling Skill
   • 收集用户学习需求的追问列表
   • 设计多轮对话流程
   • 集成到现有的学习路径生成器
2. 建立知识库的Shared Language
   • 从本文开始，建立AI领域的术语表
   • 新笔记必须使用统一术语
   • 定期更新术语表
3. 实践垂直切片
   • 在处理复杂任务时，先规划垂直切片
   • 每个切片完成后验证
   • 记录切片边界决策