Matt Pocock技能库实战：Grill与TDD提效经验

背景

随着大语言模型（LLM）在软件开发领域的渗透，开发者不再仅仅将其视为代码补全工具，而是开始探索基于特定技能（Skills）或提示词工程（Prompt Engineering）的工作流。Matt Pocock 提出的技能库是这一趋势的代表性实践，旨在通过结构化的指令引导 AI 完成从需求澄清到测试驱动开发的全流程。

然而，直接套用官方技能库往往存在“水土不服”的情况。作者基于自身在 Windows 平台透明代理项目（WinTProxy）重构中的实际经验，对 Matt Pocock 的技能库进行了深度定制与魔改。本文旨在分享这一实战经验，探讨如何根据具体场景筛选、裁剪甚至重构 AI 技能，以平衡开发效率、Token 成本与代码质量，并揭示在 AI 辅助编程时代，人机协作的最佳实践模式。

核心内容

作者详细拆解了其对 Matt Pocock 技能库的使用策略，分为“推荐技能”、“弃用技能”、“工作流组合”及“实战案例”四个部分。

推荐使用的核心技能

1. grill-with-docs（共识达成器）

   • 核心价值：该技能的核心在于“达成共识”。当用户需求宽泛时，它会通过一系列追问迫使开发者明确细节，避免后续开发方向偏差。
   • 注意事项：该技能会生成文档记录共识。作者指出，任务完成后必须删除这些文档，否则它们可能成为后续需求的干扰项。
   • 反面案例：在重构 WinTProxy 时，作者保留了关于使用 ndisapi 替代 WinDivert 的架构决策记录（ADR）。当实际切换至二层网络捕获时，原有的三层处理文档导致 AI 错误地重复捕获数据包，引发严重冲突。

2. to-issues（垂直切片拆解）

   • 核心思想：强调“垂直切片”（Vertical Slicing），即任务划分应从端到端（End-to-End），涵盖从后端到前端的全部实现，而非按技术层级（如仅后端、仅前端）划分。
   • 价值：这种划分方式能提供更有效的反馈闭环，显著提升 Agent 的开发效率。

3. diagnose（调试诊断）

   • 应用场景：适用于日志过多、难以定位问题的场景。
   • 定制化改造：原版技能流程繁琐，包含修改和测试环节。作者将其精简，仅保留“报告原因”的功能，将具体的代码修改和测试工作交由 to-issues 和 tdd 处理，实现了职责分离。

4. tdd（测试驱动开发）

   • 核心评价：作者认为 TDD 思想是“王者”，尤其在配合 Rust 等强类型语言时效果显著。
   • 运作机制：利用 AI 的自我鞭策能力（RED/GREEN 循环），让 AI 自动完成“写测试-失败-写代码-通过”的迭代，开发者只需监督结果，实现“写完即结项”。

弃用或弱化的技能

1. 前置配置的 Issue Tracker
   • 原因：作者偏好本地文档管理，认为比维护 GitHub Issue 更便捷。虽然原版设计针对 GitHub 项目并无不妥，但本地化更符合作者习惯。
2. triage（分诊）
   • 原因：该技能依赖 Issue Tracker。在本地文档工作流中，无需先写文档描述 Issue 再排序，因此该技能显得多余。
3. zoom-out（宏观视角）
   • 原因：原版仅是一句简单的提示词，缺乏复杂的工作流逻辑。作者认为其价值有限，除非魔改用于生成数据流图等可视化内容，否则直接写提示词即可。

定制化的工作流组合

作者根据自身需求，剔除了 engineering 中的 triage，魔改了 zoom-out 等技能，并新增 handoff（会话交接）技能，形成了以下主要工作流：

• 新功能开发：grill-with-docs → prototype (可选，需新开 Session 并通过 handoff 交接) → to-prd → to-issues → tdd
• 架构优化：improve-codebase-architecture → prototype (可选) → to-prd → to-issues → tdd
• Bug 修复：diagnose → tdd

关键洞察：

• Prototype 的隔离：原型开发通常需要在新的 Session 中进行，并通过 handoff 技能将上下文交接给后续的开发 Session，以保持上下文纯净。
• To-PRD 与 To-Issues 的分离：虽然两者常连续使用，但作者发现并非所有需求都需要写 PRD（产品需求文档）。明确的需求可直接拆分任务。保留两者的分离是为了应对不同粒度的需求场景。

实战案例：TinyTrans 托盘菜单优化

作者以优化一个小工具 TinyTrans 的右键菜单为例，展示了魔改后的技能链（clarify → spec → slice → tdd）：

1. Clarify (原 grill-with-docs)：输入模糊需求（“菜单太丑，优化一下”）。AI 发起追问，作者全程接受建议，达成“共识”。
2. Spec (原 to-prd)：将共识转化为文档。作者虽建议审查，但出于信任和效率考虑，直接采纳 AI 生成的 Spec。
3. Slice (原 to-issues)：将 Spec 拆分为垂直切片任务。作者需人工确认切片是否合理（是否端到端）。
4. Tdd：AI 自动执行 TDD 流程，自行迭代直至通过。最终生成的 UI 虽符合功能要求，但审美由作者调侃为“一言难尽”。

选型逻辑：为何选择 Matt Pocock 技能库？

相较于 Superpowers、Trellis 等其他 AI 编程框架，Matt Pocock 的技能库流程控制相对较轻，Token 消耗更低。对于注重成本的开发者而言，这种“轻量级”但具备结构化引导的工作流更具吸引力。

关键要点

• 共识文档的生命周期管理：grill-with-docs 生成的文档是双刃剑，必须在任务结束后及时清理，避免与后续架构变更产生冲突。
• 垂直切片优于水平切片：to-issues 的核心价值在于推动端到端的任务划分，确保每个任务都能提供完整的反馈闭环。
• 技能解耦与重组：不要盲目照搬官方技能库。应根据自身习惯（如本地文档 vs GitHub Issue）裁剪技能（如移除 triage），并组合专用技能（如精简版 diagnose + tdd）。
• TDD 是 AI 编程的最佳拍档：在 AI 辅助开发中，TDD 不仅是代码质量保障，更是利用 AI 自我纠错能力的最佳机制，尤其适合 Rust 等严谨语言。
• 会话隔离与交接：复杂任务应拆分为多个 Session，利用 handoff 技能进行上下文传递，避免上下文污染和 Token 溢出。
• 人机协作的边界：AI 擅长执行和总结，但在架构决策和审美上仍有局限。开发者需保留对关键节点（如需求澄清、任务拆分）的审核权，但可适度放权（如不审查 Spec）。
• 过渡期思维：当前的工作流构建和提示词工程是 LLM 能力进化过程中的过渡产品。随着模型能力提升，繁琐的流程控制将逐渐简化，开发者应关注核心逻辑而非工具本身。

意义与影响

这篇文章不仅是一份工具使用指南，更反映了 AI 辅助编程从“粗放式提示”向“精细化工作流”演进的必然趋势。

1. 从“工具使用”到“工程化思维”：作者展示了如何将 AI 技能视为软件工程的组件，通过组合、裁剪和定制，构建适合特定项目特性的开发流水线。这标志着 AI 编程正在从个人技巧上升为可复用的工程实践。
2. 对“黑盒”AI 的透明化控制：通过 `