项目仓库：mattpocock/skills
Star 数：51,400+ ⭐
排名：GitHub 全球第 466 位
开源协议：MIT License
主要语言：Shell
目录
- 引言：为什么需要真实工程技能？
- 项目概述与核心哲学
- 四大核心问题及解决方案
- 项目架构与目录结构
- 核心技能详解
- 安装与快速开始
- 技能设计模式
- 实战案例：使用 TDD 技能
- 设计理念深度剖析
- 总结与延伸阅读
1. 引言：为什么需要真实工程技能？
1.1 AI 编码时代的挑战
随着 Claude Code、Copilot、Cursor 等 AI 编码工具的普及，软件开发的门槛大幅降低。然而，这种便利也带来了新的问题：
😰 问题现象：
├── "AI 生成的代码根本不是我想要的"
├── "代码能用，但架构一团糟"
├── "调试了三天三夜，问题还是没找到"
└── "每次问 AI 都说需要更多上下文"
🤔 深层原因：
├── 人类与 AI 之间存在沟通鸿沟
├── 缺乏系统化的开发流程和反馈机制
├── 过度依赖 AI，忽视了软件工程基本功
└── 没有建立团队/项目的共享语言
1.2 Matt Pocock 的回答
Matt Pocock 是谁？
- Total TypeScript 创始人
- 前 Vercel 工程师
- TypeScript 教育者和布道者
- 拥有 60,000+ 订阅者的 newsletter
他的答案是：
"真实工程技能"（Skills for Real Engineers）—— 基于数十年工程经验设计的 AI 代理技能集合
这些技能不是替代工程基本功，而是将它们系统化、可重复化，帮助工程师在 AI 时代依然保持高质量产出。
2. 项目概述与核心哲学
2.1 项目定位
┌─────────────────────────────────────────────────────────────┐
│ mattpocock/skills │
├─────────────────────────────────────────────────────────────┤
│ 🎯 使命：让 AI 代理做真实工程，而非"氛围编码" │
│ │
│ 📚 特点： │
│ ├── 小型化：每个技能专注单一职责，易于理解和修改 │
│ ├── 可组合：技能可以单独使用，也可以组合形成工作流 │
│ ├── 模型无关：适用于任何 AI 模型（Claude/GPT/其他） │
│ └── 可定制：鼓励用户修改以适应自己的需求 │
└─────────────────────────────────────────────────────────────┘
2.2 核心哲学
来自项目 README 的原话：
"Developing real applications is hard. 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."
翻译：开发真实应用程序很难。GSD、BMAD、Spec-Kit 等方法试图通过掌控流程来提供帮助，但这样做会剥夺你的控制权，使流程中的错误难以解决。
Matt 的解决思路：
| 传统方法 | Matt 的方法 |
|---|---|
| 流程优先 | 技能优先 |
| 自动化一切 | 保留人的控制权 |
| 固定流程 | 可组合、灵活 |
| 通用模板 | 领域特定 |
2.3 项目数据
| 指标 | 数值 |
|---|---|
| GitHub Stars | 51,400+ |
| GitHub Forks | 4,300+ |
| 排名 | 全球第 466 位 |
| 创建时间 | 2026 年 2 月 |
| 提交次数 | 63 次 |
| 贡献者 | 2 人 |
| 技能总数 | 16 个 |
| Newsletter 订阅 | ~60,000 人 |
3. 四大核心问题及解决方案
3.1 问题总览
┌────────────────────────────────────────────────────────────────────┐
│ AI 编码代理的四大失败模式 │
├──────────────┬─────────────────────────────────────────────────────┤
│ 问题 #1 │ 代理没有按照我的意愿执行 │
│ 问题 #2 │ 代理过于冗长 │
│ 问题 #3 │ 代码无法工作 │
│ 问题 #4 │ 构建了泥球架构 │
└──────────────┴─────────────────────────────────────────────────────┘
3.2 问题 #1：代理没有按照我的意愿执行
引用经典：
"No-one knows exactly what they want."
— David Thomas & Andrew Hunt,《The Pragmatic Programmer》
问题分析：
用户脑海中的想法 ──────→ [沟通鸿沟] ──────→ AI 理解的实现
vs
结果：AI 构建的东西完全不是用户想要的
解决方案：Grilling Session（深度访谈）
| 技能 | 用途 |
|---|---|
/grill-me | 非代码用途的通用访谈 |
/grill-with-docs | 代码用途的高级访谈（带文档更新） |
工作原理：
用户："我想添加一个用户认证功能"
AI 追问：
1. "用户指的是登录用户还是管理员用户？"
→ 用户："登录用户"
2. "使用什么认证方式？OAuth、邮箱密码、还是第三方登录？"
→ 用户："邮箱密码"
3. "密码需要加密存储吗？使用什么加密算法？"
→ 用户："bcrypt"
4. "需要支持忘记密码功能吗？通过邮件重置？"
→ 用户："是的"
...
直到决策树的每个分支都被解决！
3.3 问题 #2：代理过于冗长
问题分析：
😰 AI 生成代码：
"Here is the function that handles the user authentication process
by first checking if the provided credentials match our stored hash..."
✅ 理想情况：
"authenticateUser(credentials)"
根本原因：
- AI 不理解项目中的专业术语
- 缺乏领域模型和共享语言
- 每次都需要重新解释相同的概念
解决方案：CONTEXT.md + 共享语言
示例对比：
| ❌ 之前（模糊描述） | ✅ 之后（共享语言） |
|---|---|
| "There's a problem when a lesson inside a section of a course is made 'real'" | "There's a problem with the materialization cascade" |
共享语言的额外好处：
- ✅ 变量、函数、文件名命名一致
- ✅ 代码库更易于 AI 导航
- ✅ AI "思考" 消耗的 token 更少
3.4 问题 #3：代码无法工作
问题分析：
没有反馈循环的 AI 编码 = 盲目飞行
解决方案：测试驱动开发 + 结构化调试
| 技能 | 用途 |
|---|---|
/tdd | 红-绿-重构循环，测试先行 |
/diagnose | 硬 Bug 的规范化诊断循环 |
/tdd 核心流程：
┌─────────────────────────────────────────────────────────────┐
│ TDD 红-绿-重构循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ RED 阶段 GREEN 阶段 REFACTOR │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 写失败 │ → │ 最简代码 │ → │ 重构代码 │ │
│ │ 的测试 │ │ 使测试 │ │ 提高质量 │ │
│ │ │ │ 通过 │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ 关键词：垂直切片（一次只做一个行为） │
└─────────────────────────────────────────────────────────────┘
/diagnose 核心流程：
复现 → 最小化 → 假设 → 工具化 → 修复 → 回归测试
3.5 问题 #4：构建了泥球架构
引用经典：
"Invest in the design of the system every day."
— Kent Beck,《Extreme Programming Explained》
问题分析：
AI 的超能力 = 加速编码
AI 的副作用 = 加速软件熵增
结果：代码库以前所未有的速度变得复杂难懂
解决方案：关注代码设计
| 技能 | 用途 |
|---|---|
/to-prd | 创建 PRD 前先询问模块设计 |
/zoom-out | 放大视角，理解代码在系统中的位置 |
/improve-codebase-architecture | 拯救泥球代码库 |
4. 项目架构与目录结构
4.1 整体目录结构
mattpocock/skills/
│
├── .claude-plugin/ # Claude 插件配置
│
├── .out-of-scope/ # 范围外内容
│
├── docs/ # 文档
│ └── adr/ # 架构决策记录 (Architecture Decision Records)
│
├── scripts/ # 实用脚本
│
├── skills/ # 核心技能目录
│ │
│ ├── engineering/ # 🏗️ 工程类技能（9个）
│ │ ├── diagnose/ # 调试诊断
│ │ ├── grill-with-docs/ # 深度访谈（带文档）
│ │ ├── triage/ # 问题分类
│ │ ├── improve-codebase-architecture/ # 架构改进
│ │ ├── setup-matt-pocock-skills/ # 初始化配置
│ │ ├── tdd/ # 测试驱动开发
│ │ ├── to-issues/ # 拆解为 Issues
│ │ ├── to-prd/ # 创建 PRD
│ │ └── zoom-out/ # 宏观视角
│ │
│ ├── productivity/ # ⚡ 生产力类技能（3个）
│ │ ├── caveman/ # 极简沟通模式
│ │ ├── grill-me/ # 通用访谈
│ │ └── write-a-skill/ # 创建新技能
│ │
│ └── misc/ # 🔧 杂项工具（4个）
│ ├── git-guardrails-claude-code/
│ ├── migrate-to-shoehorn/
│ ├── scaffold-exercises/
│ └── setup-pre-commit/
│
├── CLAUDE.md # Claude 代理配置
├── CONTEXT.md # 项目共享语言文档
├── LICENSE # MIT 许可证
└── README.md # 项目说明
4.2 技能分类详解
┌─────────────────────────────────────────────────────────────┐
│ 技能分类图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ engineering/ (9个) productivity/ (3个) │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 日常代码工作 │ │ 通用工作流工具 │ │
│ │ │ │ │ │
│ │ • TDD │ │ • caveman │ │
│ │ • diagnose │ │ • grill-me │ │
│ │ • zoom-out │ │ • write-a-skill │ │
│ │ • ... │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ misc/ (4个) │
│ ┌─────────────────┐ │
│ │ 备用工具 │ │
│ │ │ │
│ │ • git-guardrails│ │
│ │ • pre-commit │ │
│ │ • ... │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
4.3 每个技能的文件结构
skill-name/
├── SKILL.md # 📝 主指令文件（必需）
├── REFERENCE.md # 📚 详细参考文档（可选）
├── EXAMPLES.md # 💡 使用示例（可选）
└── scripts/ # 🔧 实用脚本（可选）
└── helper.sh
SKILL.md 标准格式：
---
name: skill-name
description: 技能描述. Use when [触发条件].
---
# Skill Name
## Quick start
[最小可用示例]
## Workflows
[带检查清单的分步流程]
## Advanced features
[链接到其他文件：See REFERENCE.md]
5. 核心技能详解
5.1 Engineering 技能详解
/tdd — 测试驱动开发
文件位置：skills/engineering/tdd/SKILL.md
核心原则：
"测试应通过公共接口验证行为，而非实现细节。代码可以完全改变，但测试不应该。"
好测试 vs 坏测试：
| 好测试 | 坏测试 |
|---|---|
| 集成风格：通过公共 API 测试 | 耦合到实现：模拟内部组件 |
| 描述系统做什么 | 描述系统如何做 |
| 能承受重构 | 重构时测试就失败 |
垂直切片 vs 水平切片：
❌ 水平切片（错误）：
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
✅ 垂直切片（正确）：
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
完整 TDD 流程：
┌─────────────────────────────────────────────────────────────┐
│ TDD 工作流 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 阶段 1: 规划 │
│ ├── [ ] 与用户确认接口变更 │
│ ├── [ ] 识别深度模块机会 │
│ └── [ ] 列出要测试的行为（按优先级） │
│ │
│ 阶段 2: 追踪弹 │
│ ├── RED: 写一个测试 → 测试失败 │
│ └── GREEN: 写最简代码 → 测试通过 │
│ │
│ 阶段 3: 增量循环 │
│ 对每个剩余行为: │
│ ├── RED: 写下一个测试 → 失败 │
│ └── GREEN: 最简代码通过 │
│ │
│ 阶段 4: 重构 │
│ ├── [ ] 提取重复代码 │
│ ├── [ ] 加深模块 │
│ └── [ ] 每次重构后运行测试 ⚠️ 先到 GREEN！ │
│ │
└─────────────────────────────────────────────────────────────┘
/diagnose — 结构化调试
文件位置：skills/engineering/diagnose/SKILL.md
核心洞察：
"如果有一个快速、确定性、可代理运行的 pass/fail 信号来检测 Bug，你会找到原因——二分搜索、假设测试和工具化都只是消耗那个信号。"
诊断循环：
┌─────────────────────────────────────────────────────────────┐
│ 6 阶段诊断循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: 构建反馈循环 │
│ ├── 优先级 1: 失败的测试 │
│ ├── 优先级 2: Curl/HTTP 脚本 │
│ ├── 优先级 3: CLI 调用 │
│ └── ... 直到找到可验证的信号 │
│ │
│ Phase 2: 复现 (Reproduce) │
│ └── 运行循环，观察 Bug 出现 │
│ │
│ Phase 3: 假设 (Hypothesise) │
│ ├── 生成 3-5 个排名假设 │
│ └── 每个假设必须是可证伪的 │
│ │
│ Phase 4: 工具化 (Instrument) │
│ ├── 每个探测映射到特定预测 │
│ ├── 调试器 > 定向日志 > "记录一切" │
│ └── 使用 [DEBUG-xxx] 前缀标记日志 │
│ │
│ Phase 5: 修复 + 回归测试 │
│ ├── 修复前写回归测试 │
│ └── 验证正确边界 │
│ │
│ Phase 6: 清理 + 复盘 │
│ ├── 移除所有 [DEBUG-xxx] │
│ └── 记录 "什么能防止这个 Bug？" │
│ │
└─────────────────────────────────────────────────────────────┘
反馈循环质量金字塔：
优先级 1: 失败的测试
↓
优先级 2: Curl / HTTP 脚本
↓
优先级 3: CLI 调用（带快照对比）
↓
优先级 4: 无头浏览器脚本（Playwright）
↓
...
优先级 9: HITL bash 脚本（最后手段）
/grill-with-docs — 深度访谈与文档同步
文件位置：skills/engineering/grill-with-docs/SKILL.md
核心功能：
- 不断追问计划的每个方面
- 与 CONTEXT.md 中的术语对照
- 实时更新 CONTEXT.md 和 ADR
文档结构规范：
# 标准仓库结构
/
├── CONTEXT.md # 领域术语和共享语言
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
└── ...
# 多上下文仓库结构（monorepo）
/
├── CONTEXT-MAP.md # 指向各上下文位置
├── docs/
│ └── adr/ # 系统级决策
└── src/
├── ordering/
│ ├── CONTEXT.md
│ └── docs/adr/
└── billing/
├── CONTEXT.md
└── docs/adr/
ADR 创建条件（仅当全部满足）：
| 条件 | 说明 |
|---|---|
| 1 | 难以逆转，后期改变成本高 |
| 2 | 缺乏上下文会让人困惑"为什么这么做？" |
| 3 | 存在真正的权衡，选择了其中一个 |
/zoom-out — 宏观视角
文件位置：skills/engineering/zoom-out/SKILL.md
核心指令：
I don't know this area of code well.
Go up a layer of abstraction.
Give me a map of all the relevant modules and callers,
using the project's domain glossary vocabulary.
用途场景：
- 接手不熟悉的代码区域
- 理解某个功能在整体架构中的位置
- 快速建立全局认知
/improve-codebase-architecture — 架构改进
文件位置：skills/engineering/improve-codebase-architecture/SKILL.md
核心概念：
| 术语 | 定义 |
|---|---|
| Module | 任何有接口和实现的东西（函数、类、包、切片） |
| Interface | 调用者必须知道的一切：类型、不变量、错误模式、顺序、配置 |
| Depth | 杠杆效应：大量功能隐藏在简单接口后 |
| Seam | 接口所在位置；可以在不修改原代码的情况下改变行为 |
| Adapter | 在 seam 处满足接口的具体实现 |
Deletion Test：
想象删除这个模块。如果复杂性消失了，它是通道模块。如果复杂性分散到 N 个调用者中，它是在创造价值的模块。
发现深化机会：
寻找以下摩擦点：
├── 理解一个概念需要在多个小模块间跳跃
├── 模块是浅层的（接口几乎和实现一样复杂）
├── 纯函数被提取出来只是为了可测试性
├── 紧耦合模块跨 seam 泄漏
└── 代码库难以测试
5.2 Productivity 技能详解
/grill-me — 通用访谈
文件位置：skills/productivity/grill-me/SKILL.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.
For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase,
explore the codebase instead.
使用场景：
- 用户说 "grill me"
- 想压力测试一个计划
- 想被质询设计方案
/caveman — 极简沟通
核心概念：
通过删除填充词同时保持完整技术准确性，减少约 75% 的 token 使用
示例：
| ❌ 冗长版本 | ✅ Caveman 版本 |
|---|---|
| "I think we should probably consider using..." | "Use X" |
| "It might be a good idea to refactor..." | "Refactor X to use Y" |
| "This could potentially improve performance..." | "X improves perf" |
/write-a-skill — 创建新技能
文件位置：skills/productivity/write-a-skill/SKILL.md
创建流程：
1. 收集需求
├── 技能覆盖什么任务/领域？
├── 需要处理哪些具体用例？
├── 需要可执行脚本还是只需要指令？
└── 有哪些参考资料？
2. 起草技能
├── SKILL.md：简洁指令
├── 参考文件：内容超过 500 行时添加
└── 实用脚本：确定性操作时添加
3. 与用户审核
├── 覆盖所有用例？
├── 有缺失或不清晰？
└── 详细程度合适？
SKILL.md 模板：
---
name: skill-name
description: Brief description. Use when [触发条件].
---
# Skill Name
## Quick start
[最小可用示例]
## Workflows
[带检查清单的分步流程]
## Advanced features
[链接到其他文件]
5.3 Misc 技能详解
| 技能 | 用途 |
|---|---|
git-guardrails-claude-code | 阻止危险的 git 命令（push, reset --hard, clean） |
migrate-to-shoehorn | 将 as 类型断言迁移到 @total-typescript/shoehorn |
scaffold-exercises | 创建带章节、问题、解决方案的练习目录结构 |
setup-pre-commit | 设置 Husky pre-commit hooks（lint-staged, Prettier, 类型检查） |
6. 安装与快速开始
6.1 30 秒快速开始
Step 1：运行安装脚本
npx skills@latest add mattpocock/skills
Step 2：选择技能和编码代理
确保选择 /setup-matt-pocock-skills
Step 3：运行设置命令
在代理中运行：
/setup-matt-pocock-skills
设置命令会询问：
- 使用的问题跟踪器（GitHub / Linear / 本地文件）
- triage 时使用的标签
- 保存文档的位置
Step 4：完成！
6.2 每个仓库的配置流程
对于新仓库，需要运行 /setup-matt-pocock-skills
该技能会创建以下配置：
docs/agents/
├── issue-tracker.md # 问题跟踪器配置
├── triage-labels.md # 标签词汇
└── domain.md # 领域文档布局
标签系统（5 个标准角色）：
| 标签 | 用途 |
|---|---|
needs-triage | 需要维护者评估 |
needs-info | 等待报告者提供信息 |
ready-for-agent | 完全指定，AI 可接手（无人类上下文） |
ready-for-human | 需要人类实现 |
wontfix | 不会处理 |
7. 技能设计模式
7.1 技能命名规范
skill-name/
├── SKILL.md # 主文件
├── REFERENCE.md # 详细参考
├── EXAMPLES.md # 示例
├── tests/ # 测试（如有）
└── scripts/ # 脚本（如有）
7.2 SKILL.md 格式标准
---
name: skill-name
description: 描述. Use when [触发条件].
---
# Skill Name
## Quick Start
[一句话用法]
## Workflows
[详细流程 + 检查清单]
## Advanced
[链接到 REFERENCE.md]
7.3 渐进式披露原则
SKILL.md (简短)
↓
链接
↓
REFERENCE.md (详细)
↓
链接
↓
EXAMPLES.md (示例)
规则：
- SKILL.md < 100 行
- 超过 500 行内容 → 拆分到参考文件
- 只深入一层引用
7.4 触发条件写法
好的示例：
description: Extract text from PDFs, fill forms, merge documents. Use when working with PDF files or when user mentions PDFs, forms, or document extraction.
坏的示例：
description: Helps with documents.
8. 实战案例：使用 TDD 技能
8.1 场景描述
用户想要为一个电商系统添加"购物车"功能。
8.2 步骤 1：规划阶段
AI 提问：
"购物车需要支持哪些操作？"
用户回答：
"添加商品、移除商品、更新数量、清空购物车、计算总价"
AI 继续提问：
"添加商品时，如果商品已经在购物车中怎么办？"
用户回答：
"增加数量，而不是创建新条目"
"用户指的是 Customer 还是 User？它们是不同的概念。"
... 继续直到决策树清晰
8.3 步骤 2：识别模块
AI 提出的模块设计：
shopping-cart/
├── domain/
│ ├── Cart.ts # 核心领域模型
│ ├── CartItem.ts # 购物车条目
│ └── events.ts # 购物车事件
├── services/
│ └── CartService.ts # 购物车服务
└── ports/
└── CartRepository.ts # 仓库接口（用于持久化）
8.4 步骤 3：TDD 循环
RED 阶段 - 写失败的测试：
// cart.test.ts
describe('ShoppingCart', () => {
it('should add an item to the cart', () => {
const cart = new ShoppingCart();
cart.addItem({ productId: 'PROD-001', quantity: 2, price: 29.99 });
expect(cart.items).toHaveLength(1);
expect(cart.items[0].productId).toBe('PROD-001');
});
it('should increase quantity when adding existing item', () => {
const cart = new ShoppingCart();
cart.addItem({ productId: 'PROD-001', quantity: 2, price: 29.99 });
cart.addItem({ productId: 'PROD-001', quantity: 3, price: 29.99 });
expect(cart.items).toHaveLength(1);
expect(cart.items[0].quantity).toBe(5);
});
// ... 更多测试
});
GREEN 阶段 - 最简实现：
// cart.ts
export class ShoppingCart {
items: CartItem[] = [];
addItem(item: CartItemInput): void {
const existing = this.items.find(i => i.productId === item.productId);
if (existing) {
existing.quantity += item.quantity;
} else {
this.items.push({ ...item });
}
}
}
REFACTOR 阶段：
- 提取
CartItem类型 - 添加价格验证
- 保持接口干净
8.5 步骤 4：运行诊断
如果测试失败，使用 /diagnose 技能：
/diagnose
AI: 请描述你观察到的失败。
用户: "添加商品时数量统计错误"
AI: 让我运行反馈循环...
Phase 1: 构建反馈循环
→ 已有失败的测试，跳过
Phase 2: 复现
→ 运行测试，观察失败
Phase 3: 假设
生成 3 个假设：
1. 如果是数组引用问题 → 使用深拷贝
2. 如果是数量计算逻辑 → 检查 += 操作
3. 如果是类型问题 → 检查类型定义
...
9. 设计理念深度剖析
9.1 核心设计原则
原则 1：小型化 (Small)
❌ 一个技能做所有事
✅ 一个技能只做一件事，但做到极致
原因：
- 易于理解和修改
- 可以自由组合
- 更容易测试和调试
原则 2：可组合 (Composable)
skills/
├── grill-me + tdd = 规划良好的 TDD
├── zoom-out + grill-me = 有全局视野的访谈
└── diagnose + tdd = 测试驱动的调试
原则 3：模型无关 (Model-Agnostic)
不依赖特定 AI 模型的能力：
- 通用指令 → 适用于 Claude/GPT/其他
- 不使用特定模型的专有功能
- 鼓励用户修改以适应自己的模型
原则 4：保留人类控制权
❌ 完全自动化，用户失去控制
✅ 技能辅助人类，人类保持最终决策权
9.2 与传统开发方法的对比
| 维度 | GSD/BMAD/Spec-Kit | mattpocock/skills |
|---|---|---|
| 流程 | 固定流程优先 | 技能组合优先 |
| 控制 | 流程自动化 | 人保持控制 |
| 灵活性 | 低 | 高 |
| 适用场景 | 通用项目管理 | 专业工程实践 |
| 学习曲线 | 陡峭 | 平缓 |
| 可定制性 | 低 | 高 |
9.3 共享语言的力量
为什么共享语言如此重要？
没有共享语言：
用户: "When the materialization cascade fires but the lesson hasn't
been made real yet..."
AI: "I don't understand. Could you explain what 'made real' means?"
有共享语言 (CONTEXT.md):
CONTEXT.md:
## materialization cascade
The process of giving a CourseEntity (lesson, section, etc.)
a spot in the file system, making it accessible to students.
用户: "There's a problem with the materialization cascade"
AI: "Got it. What aspect of the cascade isn't working correctly?"
9.4 深度模块 vs 浅层模块
深度模块（理想）：
// 深度模块示例
interface Logger {
debug(msg: string): void;
info(msg: string): void;
warn(msg: string): void;
error(msg: string): void;
}
// 用户只需要知道这 4 个方法
// 内部实现可以很复杂：日志级别、格式化、持久化、轮转...
浅层模块（要避免）：
// 浅层模块示例 - 接口和实现一样复杂
class ComplexLogger {
private level: LogLevel;
private format: Formatter;
private transport: Transport[];
private buffer: Buffer;
private flushInterval: number;
// ... 50 more fields
// 用户必须了解所有内部细节才能使用
}
10. 总结与延伸阅读
10.1 项目亮点总结
┌─────────────────────────────────────────────────────────────┐
│ mattpocock/skills 核心亮点 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🎯 定位：AI 时代的真实工程技能库 │
│ │
│ 📊 数据： │
│ ├── 51,400+ Stars │
│ ├── GitHub 全球排名第 466 │
│ └── 16 个精心设计的技能 │
│ │
│ 🏆 四大核心问题解决方案： │
│ ├── 问题 1 → /grill-me, /grill-with-docs │
│ ├── 问题 2 → CONTEXT.md + 共享语言 │
│ ├── 问题 3 → /tdd, /diagnose │
│ └── 问题 4 → /to-prd, /zoom-out, /improve-codebase-... │
│ │
│ 💡 核心价值： │
│ ├── 小型化、可组合、模型无关 │
│ ├── 保留人类控制权 │
│ ├── 基于数十年工程经验 │
│ └── 真正帮助做真实工程，而非氛围编码 │
│ │
└─────────────────────────────────────────────────────────────┘
10.2 适用人群
| 人群 | 如何使用 |
|---|---|
| 个人开发者 | 使用基础技能提升代码质量 |
| 团队 | 建立共享语言和工程规范 |
| AI 爱好者 | 学习如何与 AI 有效协作 |
| TypeScript 开发者 | 配合 Total TypeScript 学习 |
10.3 快速开始清单
[ ] 运行安装命令：`npx skills@latest add mattpocock/skills`
[ ] 选择 `/setup-matt-pocock-skills` 进行初始化
[ ] 在新项目上运行 `/setup-matt-pocock-skills`
[ ] 下次想构建功能时，尝试 `/grill-me`
[ ] 下次写代码时，尝试 `/tdd`
[ ] 下次遇到 bug 时，尝试 `/diagnose`
[ ] 创建 CONTEXT.md 建立项目共享语言
10.4 相关资源
| 资源 | 链接 |
|---|---|
| GitHub 仓库 | github.com/mattpocock/… |
| Matt Pocock Twitter | @mattpocock |
| Newsletter | www.aihero.dev/s/skills-ne… |
| Total TypeScript | www.totaltypescript.com/ |
10.5 延伸阅读
推荐书籍：
| 书名 | 作者 | 与项目相关章节 |
|---|---|---|
| The Pragmatic Programmer | David Thomas & Andrew Hunt | Grilling philosophy |
| Domain-Driven Design | Eric Evans | 共享语言、ADR |
| Test-Driven Development | Kent Beck | /tdd 技能 |
| A Philosophy of Software Design | John Ousterhout | 深度模块概念 |
| Extreme Programming Explained | Kent Beck | 代码设计理念 |
10.6 最后的思考
"Software engineering fundamentals matter more than ever."
— Matt Pocock
在 AI 时代，工程基本功不是过时了，而是更重要了。技能只是工具，真正重要的是理解为什么这些技能有效，以及如何在你的工作流中灵活运用它们。
Matt 的技能库是一个起点，而不是终点。Hack around with them. Make them your own. Enjoy.
版权声明：
本文为技术分析博客，详细解读了 mattpocock/skills 项目的设计理念和使用方法。项目版权归 Matt Pocock 所有，遵循 MIT 许可证。
参考引用：
- 项目 README: github.com/mattpocock/…
- Matt Pocock Newsletter: www.aihero.dev/s/skills-ne…
