Explainfuture · Explainfuture · May 13, 2026
diff --git a/docs/基于 skill 思想的个人开发提效实践.md b/docs/基于 skill 思想的个人开发提效实践.md
@@ -0,0 +1,256 @@
+---
+title: 从 Matt Pocock 的 skills 仓库看 AI 协作开发：把 Agent 变成工程流程执行器
+date: 2026-05-13 10:00:00
+tags:
+  - AI协作
+  - Claude Code
+  - 工程化
+categories:
+  - 前端
+---
+
+最近看到 Matt Pocock 开源的 `mattpocock/skills` 仓库，我突然意识到：AI 编程真正值得学习的，不是“怎么写一个更神的 prompt”，而是如何把成熟工程师的工作流沉淀成可复用的 skill。
+
+这个仓库里的 skill 不是单纯让 Claude Code 更会写代码，而是试图解决 AI Agent 在真实开发中最常见的几个失败模式：
+
+- 做出来的东西和需求不一致
+- 对业务术语理解不稳定
+- 代码越写越散，架构持续劣化
+- 缺少测试反馈，改完不敢合并
+- 调试时靠猜，而不是靠可复现证据
+- 任务拆分太横向，多个 Agent 很难并行推进
+
+所以我对这个仓库的理解是：**它不是 prompt 合集，而是一套 AI 时代的工程协作协议。**
+
+## 1. `/grill-me`：不是让 AI 直接开写，而是先拷问需求
+
+传统使用 AI 的方式是：
+
+> 帮我实现一个 xxx 功能。
+
+但 Matt 的思路不是这样。他的 `/grill-me` 更像是让 Agent 扮演一个严格的技术负责人，在写代码前先追问你：
+
+- 这个功能到底服务谁？
+- 成功标准是什么？
+- 哪些边界明确不做？
+- 和现有系统有没有冲突？
+- 有没有更简单的方案？
+- 当前方案背后的假设是什么？
+
+这解决的是 AI 协作里最致命的问题：**misalignment，需求错位。**
+
+很多时候不是 AI 写代码能力不行，而是它太早开始写了。需求还没被压实，边界还没被定义，验收标准还没明确，它就已经开始生成文件了。
+
+所以我现在个人开发时，也会先让 Agent 进入“grill”模式：
+
+> 先不要写代码，请你连续追问我，直到你能明确功能目标、边界、验收标准、数据流和潜在风险。
+
+这一步看起来慢，但它能显著减少后面的返工。
+
+## 2. `/grill-with-docs`：让 Agent 基于项目上下文提问
+
+`/grill-me` 更偏通用需求对齐，而 `/grill-with-docs` 更像真实项目里的技术评审。
+
+它不是凭空问问题，而是结合项目里的上下文文档，例如 `CONTEXT.md`、ADR、现有代码结构，再来判断你的需求是否合理。
+
+这对个人项目也很有价值。因为 AI 最大的问题之一是“每次都像新同事入职”，它不知道你之前怎么设计的，也不知道某个词在你的项目里是什么意思。
+
+所以我会维护一份轻量的 `CONTEXT.md`，里面记录：
+
+- 核心业务实体
+- 路由结构
+- 状态管理方式
+- 重要事件流
+- 关键模块边界
+- 项目里的专有术语
+- 已经做过的架构决策
+
+比如在一个 Agent 工作流 UI 里，我会明确：
+
+```text
+tooluse_start：后端通知某个工具开始执行
+tooluse_end：后端通知某个工具执行结束
+tool_call_id：一次工具调用的唯一标识
+agent_message：Agent 对用户可见的解释性消息
+workflow_event：驱动 UI 状态变化的后端事件
+```
+
+这样以后无论是写 PRD、拆 issue，还是让 AI 改 UI，它都会沿用同一套语言，不会每轮重新发明概念。
+
+## 3. `/prototype`：不确定的东西先做可抛弃原型
+
+Matt 的 skill 里很重要的一点是：prototype 不是正式代码，而是用来回答一个问题的临时实验。
+
+这点对前端尤其重要。很多 UI、交互、状态机问题，靠文字描述很难想清楚。比如：
+
+- Agent 对话流应该怎么展示？
+- 工具调用卡片是插在消息流里，还是单独放在侧栏？
+- loading 状态是按 message 维度，还是按 tool_call 维度？
+- 多个 tool 并发执行时，UI 如何排序？
+
+这类问题不应该一上来就写进正式代码。更好的方式是让 AI 做一个 throwaway prototype：
+
+- 只验证一个问题
+- 一条命令能跑起来
+- 不接真实接口
+- 不做复杂抽象
+- 验证完删除，或者只迁移有价值的部分
+
+我现在会把它当成“低成本设计实验”。不是为了产出代码，而是为了把模糊想法变成可观察结果。
+
+## 4. `/to-prd`：把对话沉淀成可执行需求文档
+
+很多人和 AI 聊完需求后，直接让它开始写代码。但 Matt 的流程里有一个关键中间层：`/to-prd`。
+
+这个 skill 的价值在于：把前面讨论过的目标、边界、取舍、验收标准，整理成一个稳定的 PRD。这一步其实是在防止上下文丢失。
+
+因为 Agent 的对话上下文是流动的，前面聊过的内容可能被后面的实现细节冲淡。如果没有 PRD，Agent 很容易在执行中偏航。
+
+我现在会要求 PRD 至少包含：
+
+- 背景问题
+- 用户目标
+- 非目标范围
+- 功能范围
+- 交互流程
+- 数据流
+- 验收标准
+- 风险点
+- 测试策略
+
+这样后续拆 issue、写代码、写测试，都有一个稳定锚点。
+
+## 5. `/to-issues`：按垂直切片拆任务，而不是横向拆任务
+
+我觉得这个仓库最值得前端学习的一点，是它强调 vertical slice。
+
+很多开发者拆任务时会这样拆：先建数据结构，再写接口，再写页面，再补测试。这叫横向拆分，问题是每一步单独完成后都不能演示，也不能独立验证。
+
+Matt 的 `/to-issues` 更强调按用户价值拆垂直切片。一个 issue 应该尽量打通完整链路：
+
+- 最小 UI
+- 最小数据结构
+- 最小状态流
+- 最小接口或 mock
+- 最小测试
+- 可以独立验收
+
+比如做 Agent 工具调用 UI，不应该拆成：
+
+- issue 1：定义类型
+- issue 2：写 WebSocket
+- issue 3：写工具卡片
+- issue 4：写样式
+
+更好的拆法是：
+
+- issue 1：展示单个 `tooluse_start` 到 `tooluse_end` 的完整生命周期
+- issue 2：支持多个 tool call 并发展示和去重
+- issue 3：支持失败状态、重试状态和用户可见解释
+- issue 4：补充回放测试和边界测试
+
+这样每个 issue 都是一个能跑通的小闭环，而不是一堆半成品。
+
+## 6. `/tdd`：给 Agent 一个明确的红绿反馈循环
+
+AI 写代码最大的问题不是“不会写”，而是“写完以后看起来像对的”。
+
+所以 `/tdd` 的价值不是形式主义地补测试，而是给 Agent 一个清晰的反馈循环：
+
+1. 先写一个失败测试
+2. 最小实现让测试通过
+3. 再重构
+4. 再补下一个行为
+
+这比“先写完整功能，最后补测试”稳定很多。
+
+对 Agent 来说，测试就是外部世界给它的信号。如果没有测试，它只能靠语言概率判断自己写得对不对；有了测试，它至少有一个可运行的客观反馈。
+
+我在个人项目里会特别强调：
+
+- 一次只写一个行为测试
+- 测 public interface，不测内部实现细节
+- 不为了测试强行拆一堆浅模块
+- 每次通过测试后再考虑重构
+
+这能明显减少 AI 一次性生成大坨代码的问题。
+
+## 7. `/diagnose`：调试不是猜，而是建立反馈循环
+
+`/diagnose` 这个 skill 对我的启发也很大。它的核心不是“让 AI 找 bug”，而是让 AI 按工程师方式排障：
+
+**复现 → 最小化 → 假设 → 打点验证 → 修复 → 回归**
+
+这和很多人用 AI 修 bug 的方式完全不同。
+
+低质量方式是：
+
+> 这个报错怎么修？你直接帮我改。
+
+高质量方式是：
+
+> 先不要改代码。请你帮我确认如何稳定复现，然后最小化问题范围，再列出可能假设，并告诉我应该加什么日志或测试来验证。
+
+尤其是前端问题，比如 WebSocket 乱序、状态重复渲染、瀑布流抖动、虚拟列表高度异常，如果不能稳定复现，直接改代码很容易越修越乱。
+
+所以我现在会要求 Agent 先建立 feedback loop。没有复现，不动代码。
+
+## 8. `/improve-codebase-architecture`：AI 提速也会加速熵增
+
+这个 skill 我觉得是整个仓库里最“工程化”的部分。
+
+很多人只看到 AI 能提高开发速度，但忽略了另一个事实：AI 也会更快地产生技术债。没有架构约束时，Agent 很容易：
+
+- 到处复制逻辑
+- 新增一堆浅模块
+- 把组件拆得很碎但没有抽象价值
+- 为了修一个 bug 改很多地方
+- 让代码越来越难被下一个 Agent 理解
+
+Matt 的思路是定期检查代码库里有没有 shallow module，并寻找 deep module 的机会。
+
+我对它的理解是：
+
+- 浅模块：接口和实现一样复杂，用不用它都差不多
+- 深模块：对外接口很小，但内部封装了有价值的复杂度
+
+前端里常见的浅模块是：
+
+- `useXxxState` 只是转发 `useState`
+- `XxxService` 只是包了一层 `fetch`
+- `XxxContainer` 只是把 props 原样传下去
+- `utils` 里堆满没有领域含义的小函数
+
+真正有价值的深模块应该是：
+
+- `useAgentToolLifecycle`：封装 `tooluse_start / tooluse_end / error / retry / dedupe / ordering`
+- `createWaterfallScheduler`：封装并发限制、节流、取消、视口卸载、请求优先级
+- `useCollaborativeCanvasSync`：封装 Yjs 文档同步、本地状态映射、远端事件合并
+
+AI 越参与开发，越需要这种架构保洁。否则项目会进入一种状态：短期功能都能做，但长期每次修改都很痛苦。
+
+## 我最终提炼出的个人工作流
+
+结合 Matt Pocock 的 skills，我现在更倾向于把 AI 协作拆成七步：
+
+1. `/grill-me`：先挑战需求，不急着写代码
+2. `/grill-with-docs`：结合 `CONTEXT.md` 和现有代码做需求校准
+3. `/prototype`：对不确定交互或状态机做可抛弃验证
+4. `/to-prd`：把讨论沉淀成稳定 PRD
+5. `/to-issues`：按垂直切片拆成可独立验收的 issue
+6. `/tdd`：用红绿重构执行每个切片
+7. `/diagnose + /improve-codebase-architecture`：出问题时先建立反馈循环，开发后定期做架构保洁
+
+这套流程本质上不是“让 AI 更听话”，而是让 AI 进入一个成熟工程师熟悉的开发节奏：先对齐、再设计、再切分、再验证、再实现、再治理。
+
+## 结语
+
+以前我使用 AI，更像是在问：你能不能帮我写代码？
+
+现在我更愿意问：你能不能按一个优秀工程师的流程，帮我把这次迭代稳定推进？
+
+Matt Pocock 的 skills 仓库给我的最大启发是：AI 编程的上限，不只取决于模型能力，也取决于你有没有把自己的工程判断流程化。
+
+真正的提效，不是今天多生成了多少代码，而是让每一次开发都更可控、更可复现、更可维护。
+
+也就是说，skill 的价值不是“替我写”，而是把“偶尔做对”变成“稳定做对”。