夜雨聆风当 AI Agent 开始承担编码工作时，软件工程的经典阶段并没有消失，而是被重新映射为一套可编排的 Skill 指令。本文从软件工程全生命周期视角，系统解析 mattpocock/skills 仓库中的工程化 Skill 体系。
一、Skill 分类总览表
| 环境配置 | setup-matt-pocock-skills | AGENTS.mdCLAUDE.md、docs/agents/ | |
| 需求澄清 | grill-me | ||
| 需求对齐 | grill-with-docs | grill-me 基础上增加领域模型约束：对照 CONTEXT.md 术语表挑战模糊用语，实时更新 ADR | CONTEXT.md、关键 ADR |
| 需求文档化 | to-prd | ||
| 架构设计 | improve-codebase-architecture | CONTEXT.md 和 docs/adr/ 识别架构摩擦，提出"深度模块"重构机会 | |
| 全局理解 | zoom-out | ||
| 原型验证 | prototype | ||
| 开发实现 | tdd | ||
| 代码审查 | review | ||
| 任务拆解 | to-issues | ||
| Issue 管理 | triage | ||
| 缺陷诊断 | diagnose | ||
| 上下文交接 | handoff | handoff-XXXXXX.md |
二、从软件工程视角的深度解析
2.1 需求工程：从模糊意图到可执行文档
传统软件工程中，需求阶段最大的风险是"意图丢失"——用户想的是 A，产品经理理解成 B，开发者做成 C。Matt Pocock 设计了三层递进机制来对抗这种熵增：
grill-me → grill-with-docs → to-prd
grill-me是纯认知层的澄清工具。它不依赖任何项目上下文，只是 relentlessly 地质询用户："你所说的 'account' 是指 Customer 还是 User？" 这种苏格拉底式的追问，本质上是在建立共享心智模型（Shared Mental Model）。grill-with-docs引入领域约束层。它要求代码库中已经存在CONTEXT.md（领域词汇表）和docs/adr/（架构决策记录）。当用户使用的术语与词汇表冲突时，它会立即叫停："你的词汇表将 'cancellation' 定义为 X，但你似乎在表达 Y——到底是哪个？" 更关键的是，它会在对话过程中实时更新文档，确保领域知识不会停留在对话上下文中，而是沉淀为可追溯的上下文文件。to-prd是文档固化层。它将对话中达成的共识转化为结构化的 PRD，并直接发布到 Issue Tracker。其模板设计体现了工程严谨性：Problem Statement（用户视角的问题）→ Solution（用户视角的解决方案）→ 详尽的 User Stories → Implementation Decisions（不含具体文件路径，避免快速过时）→ Testing Decisions → Out of Scope。这种结构直接对应了 IEEE 830 软件需求规格说明的核心要素，但以更轻量、更 AI-native 的方式呈现。
2.2 架构设计：追求"深度模块"而非"浅层抽象"
improve-codebase-architecture 和 zoom-out 共同构成了一个反直觉的架构设计哲学：好的架构不是拆得更细，而是让每个模块更深。
这套 Skill 体系引入了一套严格的词汇表：
Module：任何具有 Interface 和 Implementation 的单元 Depth：接口背后的行为杠杆——小接口、大实现 = Deep；大接口、小实现 = Shallow Seam：接口所在的位置，行为可以在不修改原代码的情况下被替换 Deletion Test：想象删除这个模块，如果复杂度消失了，说明它只是透传；如果复杂度分散到了 N 个调用方，说明它在承担真正的职责
zoom-out 解决的是认知局部性问题。当开发者在陌生代码区域工作时，AI 被要求"上升一层抽象"，用领域词汇（而非文件路径或类名）绘制模块地图。这与传统架构评审中的"走查"（Walkthrough）异曲同工，但由 AI 自动完成。
improve-codebase-architecture 则更进一步，它要求 AI 在提出重构建议时，必须先阅读领域词汇表和 ADR，确保建议不会与已有决策冲突。如果某个重构机会确实与旧 ADR 矛盾，它需要明确标注："这与 ADR-0007 冲突——但由于以下摩擦点，值得重新讨论。" 这种纪律性避免了 AI 在缺乏上下文的情况下提出"天真的重构"。
2.3 原型验证：用可丢弃代码降低设计风险
prototype 的设计体现了"精益创业"思想在软件工程中的映射：在投入正式实现前，用最快速度、最低成本验证关键假设。
它强制要求区分两类问题：
逻辑/状态模型问题 → 构建可交互的终端应用，推动状态机遍历那些"纸面上难以推理"的边界情况 UI/UX 问题 → 生成多个截然不同的视觉变体，通过 URL 参数切换，让用户在真实交互中做选择
原型规则极具工程纪律性：
从第一天起就标记为"可丢弃" 一键运行，无额外认知负担 默认无持久化，状态仅存于内存 跳过所有抛光（无测试、无错误处理、无抽象） 完成后必须删除或吸收，不允许在仓库中腐烂
这与传统软件工程中"Spike"（技术探针）实践完全一致，但 Skill 化后确保了每次原型的执行标准不会因人而异的下降。
2.4 开发实现：垂直切片的 TDD
tdd Skill 的最大贡献不是推广 TDD，而是明确禁止了"水平切片"这一反模式。
传统 TDD 的误用方式是：先写所有测试（RED），再写所有实现（GREEN）。这被称为"水平切片"，它导致测试验证的是"想象中的行为"而非"实际的行为"，测试对真实变化不敏感——行为破坏时测试通过，行为正常时测试失败。
Matt Pocock 的解决方案是Tracer Bullet 垂直切片：
每个切片都是一个完整的端到端行为：写一个测试 → 写最小实现 → 测试通过 → 下一个。测试必须：
描述行为而非实现 仅通过公共接口验证 在内部重构后仍能存活
这种工作方式本质上是在用短反馈循环替代长周期计划，与敏捷软件工程中的"迭代与增量"核心价值观完全一致。
2.5 代码审查：双轴并行审查模型
review Skill 引入了一种极具工程价值的审查范式：将 Standards（规范符合性）和 Spec（需求符合性）作为两个独立正交轴并行审查。
为什么必须分开？因为一个变更可能在一个轴上通过、在另一个轴上失败：
代码完美遵循了所有规范，但实现了错误的东西 → Standards 通过，Spec 失败 代码精确实现了需求，但破坏了项目约定 → Spec 通过，Standards 失败
如果合并审查，一个轴的发现可能掩盖另一个轴的问题。通过并行子代理（parallel sub-agents）分别执行，最终报告并置呈现，确保了审查的完整性。
这种设计与传统软件工程中的 Fagan Inspection（分角色审查：Moderator、Reader、Tester、Developer）有相同的基因——专业化分工提升审查质量，只是在这里分工被映射给了两个独立的 AI 代理。
2.6 任务与缺陷管理：状态机驱动的确定性流程
to-issues、triage 和 diagnose 覆盖了软件工程中最容易被 AI 工具忽略的"流程纪律"环节。
to-issues：Tracer Bullet 的任务拆解
它将 PRD 拆解为"Tracer Bullet Issues"——每个 Issue 是一个薄薄的垂直切片，贯穿所有集成层（schema → API → UI → tests），而不是某一个水平层。这确保了：
每个完成的切片都是可演示/可验证的 偏好 AFK（无人值守）切片而非 HITL（需人工介入）切片 依赖关系明确，按依赖顺序发布
triage：状态机而非自由文本
它将 Issue 管理严格定义为状态机流转：
每个 Issue 必须携带恰好一个 category role（bug / enhancement）和一个 state role。对于 ready-for-agent 状态，系统会附加一个"Agent Brief"——包含足够上下文的执行摘要，确保 AFK Agent 无需额外提问即可开工。这与传统 Scrum 中的"Definition of Ready"完全对应。
diagnose：六阶段纪律
这是整个 Skill 体系中最具临床精确性的流程：
Build a feedback loop — 这是最关键的一步。没有快速、确定性的通过/失败信号，任何调试都是徒劳。Skill 列出了 10 种构建反馈循环的方法，从单元测试到 git bisect run自动化。Reproduce — 确认失败模式与用户描述一致 Hypothesise — 生成 3-5 个可证伪的排序假设，每个必须有预测性陈述："如果 X 是原因，那么 Y 会让 Bug 消失" Instrument — 每次只改变一个变量，优先使用调试器而非日志 Fix + regression test — 先写回归测试（如果存在正确的 seam），再应用修复 Cleanup + post-mortem — 清理所有 [DEBUG-...]标记，追问"什么能预防这个 Bug"
如果修复揭示了架构层面的问题（没有好的测试 seam、调用方纠缠、隐藏耦合），它会明确将信息 handoff 给 improve-codebase-architecture，形成缺陷驱动架构改进的闭环。
2.7 上下文管理：跨越会话的认知连续性
handoff Skill 解决的是 AI Agent 时代一个全新但根本性的问题：会话边界的认知丢失。
当人类开发者下班时，他的大脑不会格式化；但当一个 AI Agent 会话结束时，所有上下文都消失了。下一个 Agent 从零开始，不得不重新阅读代码、重新理解需求、重新建立心智模型。
handoff 要求将当前会话压缩为一份文档，保存到临时路径，并明确建议下一个会话应使用的 Skill。它的核心纪律是：不要重复其他工件（PRD、计划、ADR、Issue、Commit、Diff）中已经捕获的内容，而是引用它们的路径或 URL。
这与传统软件工程中"交接文档"（Handoff Document）或"项目维基"的理念一致，但针对 AI Agent 的认知特点做了优化——它假设读者是另一个 AI，因此强调可执行的引用而非叙述性的总结。
三、底层设计哲学：四个贯穿始终的原则
| 深度优于广度 | |
| 文档即代码 | CONTEXT.md |
| 反馈循环至上 | |
| 人机协作分层 | triage 状态机中的 ready-for-agent vs ready-for-human |
四、总结：一套面向 AI 的软件工程操作系统
Matt Pocock 的 Skills 体系并非简单地将传统软件工程实践"AI 化"，而是重新思考了当执行者变成 AI 时，哪些环节需要被显式化、哪些纪律需要被强制执行。
传统软件工程中，很多最佳实践依赖人的自觉和经验：
需求澄清依赖产品经理的沟通技巧 架构设计依赖架构师的直觉 代码审查依赖审查者的领域知识 Bug 诊断依赖工程师的系统思维
在 AI Agent 时代，这些"软技能"被转化为可编排、可验证、可复现的确定性流程。每个 Skill 都是一个"认知子程序"，有明确的输入、输出、前置条件和后置条件。
这套体系的真正价值在于可组合性：你可以从grill-with-docs开始澄清需求，用to-prd固化文档，通过prototype验证关键假设，用to-issues拆解任务，让triage管理状态，由tdd驱动实现，经review双轴审查，最终用handoff将会话交接给下一个 Agent。整个流程环环相扣，形成一条从意图到代码的确定性管道。
对于正在构建 AI 辅助开发工作流的团队而言，这套 Skill 体系不仅是一套提示词模板，更是一份AI 时代软件工程的方法论宣言。
参考仓库：mattpocock/skills
