Skills 是什么，以及为什么你需要它们
每次你和 AI 重复解释同一件事，你都在浪费时间——Skills 让 AI 永久记住怎么配合你工作。
想象一个刚入职的实习生
你刚雇了一个超级聪明的 AI 实习生。 问题是：每天早上他们来上班，对你们公司的一切毫无记忆。你必须每次都重新解释：
我们用 TDD 写代码
先写测试，再写实现，这是我们的铁律。
调试遵循诊断循环
复现 → 缩小范围 → 假设 → 验证 → 修复。
需求先做 Grilling
开始写代码之前，必须回答所有不确定的设计问题。
Skills 就是你写给这个"忘性大的实习生"的操作手册。当你说 /tdd，AI 立刻知道你的整套测试哲学和流程，不需要再解释一遍。
Skills vs. 普通提示词：有什么不同？
你可能已经在用提示词了。Skills 和普通提示词的区别，就像厨师的私人食谱 vs. 口头描述一道菜的做法：
每次对话都要重新粘贴。AI 理解了，但下次它仍然不记得。每次都从零开始。
写一次，永久生效。在任何项目里输入 /tdd，AI 立刻进入你的测试流程。就像在 AI 大脑里安装了一个子程序。
Skills 可以互相叠加。先 /grill-with-docs 对齐需求，再 /tdd 测试驱动开发，再 /diagnose 调试——像搭积木一样。
Matt Pocock 的四大工程问题
这套 Skills 体系解决的是 AI 编程时最常见的四个失败模式。每次你遇到这些问题，都有对应的 Skill：
AI 没做你想要的 → /grill-me
AI 说话太啰嗦 → /caveman
代码跑不通 → /tdd
代码结构越来越乱 → /improve-codebase-architecture
GSD 和 BMAD 等框架试图接管整个开发流程，但这让 AI 的 bug 变得难以排查。Matt Pocock 的 Skills 更小、更精准、可组合——你保持控制权，AI 在每个环节提供专项帮助。
测验：判断 Skills 的使用场景
你每次开始新功能开发，都要告诉 Claude：「先写测试，用红绿重构循环，测试要覆盖公共接口而不是实现细节」。你应该？
你的应用有一个偶发性 bug，只在生产环境出现，本地无法复现。你应该先用哪个 Skill？
一个 Skill 文件的完整解剖
Skills 只是普通的 Markdown 文件——但它的每个部分都有精确的用途。
Skills 的目录结构
每个 Skill 就是一个文件夹，里面放着指令和参考资料。就像一个员工手册：主文件是核心规程，其他文件是详细参考。
SKILL.md 只包含核心规程（保持简短）。详细说明放在单独文件里，只有需要时才读。这样 AI 不会被淹没在上千行指令里。
SKILL.md 的 Frontmatter：触发器
每个 SKILL.md 文件的顶部都有一个Frontmatter，它告诉 AI 两件事：这个 Skill 的名字，以及什么时候应该自动触发它。
---
name: tdd
description: Test-driven development
with red-green-refactor loop.
Use when user wants to build
features or fix bugs using TDD,
mentions "red-green-refactor",
wants integration tests.
---开始 Frontmatter 元数据块
这个 Skill 的命令名字是 "tdd"，输入 /tdd 就能调用它
描述这个 Skill 做什么——这是 AI 判断"我现在应该用哪个 Skill"的依据
触发条件：用户提到红绿重构、TDD、集成测试……
当这些关键词出现时，AI 会自动加载并执行这个 Skill
结束 Frontmatter 块
Skills 之间如何「对话」
某些 Skills 依赖其他 Skills 设置的共享资源。就像公司的 HR 手册依赖之前建立的组织架构——它们共享同一套语言和文档体系。
Skill 文件内容：指令的密度
Skills 的内容不是泛泛的提示词，而是精确的工程规程。来看 TDD Skill 里最关键的那段——它明确禁止了最常见的错误：
## Anti-Pattern: Horizontal Slices
DO NOT write all tests first,
then all implementation.
## Correct approach
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3反模式：不要用「水平切片」
不要先写完所有测试，再写所有实现
（这样写出来的测试是想象中的行为，不是真实行为）
正确做法：垂直切片，一次一个功能
写一个测试，立刻让它通过，再写下一个
每次循环都在真实代码的反馈下前进
AI 有默认行为——不加约束，它倾向于先写完所有测试。Skill 里的明确禁令，覆盖了这些默认行为，让 AI 按照你的工程理念工作，而不是它自己的。
测验：Skill 结构判断
一个 Skill 的 Frontmatter 里，哪个字段决定了「什么时候 AI 应该自动触发这个 Skill」？
为什么 TDD Skill 把测试示例放在单独的 tests.md 里，而不是直接放在 SKILL.md 里？
实战 Skills 精读：TDD、Diagnose、Review
三个最核心的工程 Skills，逐行读懂它们如何工作——以及你可以怎么改造它们。
/tdd：测试驱动的六步循环
TDD Skill 的核心是一个严格的六步循环。每一步都有Checklist，AI 不能跳过任何一步：
确认公共接口、要测试的行为、深模块机会。得到用户认可后再开始。
只写第一个测试，让它失败（RED），再写最少的代码让它通过（GREEN）。
每次 RED→GREEN 一个行为，不要同时写多个。
GREEN 之后清理代码——但必须在测试全通过的状态下。
列出错误路径、边界条件，用同样的循环覆盖它们。
写一段简洁的工作摘要，说明做了什么改变、为什么。
/diagnose：调试的反馈循环哲学
Diagnose Skill 的核心洞见是：调试的关键不是猜测，而是建立一个可重复的失败信号。有了信号，bug 就有 90% 被解决了。
## Phase 1 — Build a feedback loop
This is the skill. Everything else
is mechanical. If you have a fast,
deterministic, agent-runnable
pass/fail signal for the bug,
you will find the cause.
Spend disproportionate effort here.
Be aggressive. Be creative.
Refuse to give up.阶段 1：建立反馈循环（这才是调试的精髓）
其他一切都是机械步骤——关键在这一步
你需要一个快速、确定性的、AI 可以自动运行的通过/失败信号
有了这个信号，你就一定能找到 bug 的根因
在这一步花大量时间是值得的
要有创造力，不要轻易放弃构建反馈循环
从「写一个失败的测试」到「差异循环（新版本 vs 旧版本对比输出）」，再到「属性/模糊测试（跑 1000 个随机输入找失败模式）」——每种方法对应不同类型的 bug。这是几十年调试经验的提炼。
/zoom-out：当 AI 迷失在代码细节里
Zoom-out Skill 解决一个特殊问题：AI 在深入某段代码后，有时会忘记整个系统的大图——就像一个工匠在修一块砖的时候，忘记了这是一面墙的一部分。
测验：选择正确的 Skill
你的 API 有时响应 500 错误，但复现率只有 5%，日志里看不出规律。你的第一步是？
AI 花了 40 条消息帮你优化一个数据库查询，现在提出的解决方案感觉「在局部上是对的，但和整体架构可能冲突」。你应该？
打造你自己的 Skill
从「重复说同一件事」到「一个命令搞定」——这是 Skills 真正的魔力所在。
识别你的「重复解释」
你有没有在开始新功能时，重复告诉 AI 同一件事？这些「重复解释」就是你最好的 Skill 候选材料。想想你常说的话：
项目规范类
「我们用 NestJS + TypeORM，测试用 Jest，所有 DTO 都要有 class-validator 装饰器。」
流程规范类
「每次 PR 提交前，先跑 lint，再跑测试，最后更新 CHANGELOG。」
代码风格类
「函数命名用动词开头，组件用 PascalCase，工具函数放 utils/，不要用 any。」
用 /write-a-skill 可以帮你把这些整理成规范的 Skill 文件——它会问你几个关键问题，然后生成完整的 Skill 结构。
一个 Skill 的最小可行结构
你不需要写出 TDD Skill 那么完整的文档就能开始。一个最小可行的 Skill 只需要三个部分：
---
name: api-endpoint
description: Create NestJS API endpoints
with our conventions. Use when
adding new routes, controllers,
or services.
---
# API Endpoint Conventions
Always use class-validator DTOs.
Always return standard response.
Never put business logic in controller.命令名：/api-endpoint
触发条件：用户提到 NestJS、新路由、控制器……
正文：你的项目规范，用简洁的命令式写法
用 Always/Never 明确表达强制规则
避免模糊的「应该」「最好」，要明确
Drag & Drop：Skill 的三种类型
根据内容不同，Skills 可以分为三大类。把下面的 Skill 名称拖到它对应的类型：
⚙️ 流程 Skill — 定义一套步骤循环，AI 按固定流程操作
📚 知识/配置 Skill — 建立共享语言或配置基础
🎨 风格 Skill — 改变 AI 的输出格式和表达方式
测验：Skill 设计决策
你想给 Skill 加入 20 个代码示例和反例。最好的做法是？
团队 Skills 工作流
当整个团队共享同一套 Skills，AI 就成了团队智慧的放大器——而不是每个人各自重新教的「不同学生」。
Skills 的分层：个人 vs. 团队 vs. 项目
Skills 可以在三个层级存在，就像公司的规章制度：有全公司适用的（全局），有部门内部的（团队），有项目专属的（本地）：
安装在你个人机器上，适用于所有项目。例如 /tdd、/diagnose 这种通用工程规范。
存在 Git 仓库里，团队所有成员共享。包含这个项目的独特规范、领域语言、架构决策。
个人工作习惯，不提交。例如你个人的代码风格偏好、自定义的调试步骤。
CONTEXT.md：团队共享语言的基础
在 Matt Pocock 的 Skills 体系里，CONTEXT.md 是比任何单个 Skill 都更基础的文件。它是团队和 AI 之间的「共同语言词典」：
## Language
Issue tracker:
The tool that hosts a repo's issues
— GitHub Issues, Linear, etc.
Avoid: backlog manager, backlog host
Triage role:
A canonical state-machine label
applied to an Issue during triage.语言词典部分——定义项目专用词汇
Issue Tracker：存放项目 issues 的工具
可能是 GitHub Issues、Linear 或本地文件
禁止用「backlog manager」等模糊说法
Triage Role：issue 在分类流程中的状态标签
用精确术语，AI 输出也会精确，少废话
一次完整的团队 Skills 对话
这是一个真实的团队使用 Skills 的工作流——从需求澄清到功能上线：
测验：团队 Skills 决策
你的团队刚确定了新的 API 命名规范——所有端点用 REST 风格，DTO 必须有验证装饰器，测试覆盖率 80%+。这个规范应该存在哪里？
CONTEXT.md 里的领域语言词典，除了让团队沟通更顺畅，还有什么工程上的实际好处？
从理解 Skills 是什么、解剖 Skill 文件结构、精读三个实战 Skills，到动手创建自己的 Skill，再到在团队中共享——这就是 Real Engineers 用 AI 的方式：用工程化的方法，管理工程化的工具。