AI Coding 要不要先规划?AI 大神给出了开发范式

我现在的需求开发，基本都在走自己搭的 E2E 工作流。从分析需求、出技术方案，到拉分支、写代码、测试，再到 CI/CD，AI 基本能一杆子通到底。

这套流程确实省掉了很多重复性的工作。但用下来，有个痛点越来越明显：它对小需求不够友好。一个小需求走完整的 E2E 流程，还要跑上几个小时，属实是低效。

最近看 Matt Pocock 分享的 AI Coding 工作流，让我重新思考了这个问题：

什么时候应该直接让 Agent 写代码，什么时候应该先做需求澄清和规划？

针对不同大小的需求，选择不同的工作流，这个思路我觉得值得借鉴。下面就结合他的几个 Skill，聊聊怎么选择。

1. Matt Pocock 是谁？

我关注 Matt Pocock 挺久了，之前分享过的很火的/grill-me，就是他的作品。

Matt Pocock 是 TypeScript 领域知名的技术教育者，创办了 Total TypeScript，也在持续分享 AI Coding 的实践。

他还维护了一个开源的 Agent Skills GitHub 仓库，把需求澄清、方案设计、任务拆解和代码实现整理成不同的 Skill。热度也很高，目前 Star 也有 284 K。

后面要聊的 /grill-with-docs 和 /wayfinder 就在这个仓库里。

这 2 个都不是直接帮你写代码的 Skill，而是解决开始写代码之前，还有哪些事情没想清楚。

2. 小改动、需求明确：直接 Vibe Coding

比如订单列表中的一个字段展示有误，正确的取值规则已经确定，只需要修改对应逻辑并验证。这时候，可以直接让 Agent 定位问题、修改代码、运行相关测试。

这类需求再走一遍澄清和方案设计，很可能只是在重复已经确定的事情。直接动手，省下这部分时间，改完照常检查和验证。

3. 范围可控，规则没定：用 /grill-with-docs

比如，我们有个这样的需求：

订单取消后，自动退还用户使用的优惠券。

直接让 Claude Code 实现，Agent 很可能开始搜索 OrderService、CouponService，找到取消订单的逻辑，然后修改代码。

但这句话还没说清楚：优惠券已经过期怎么办？退券是在取消申请时触发，还是等取消成功后触发？订单重复取消会不会重复退券？恢复后是否保留原有效期？

这些不是代码实现细节，而是业务规则。Agent 即使把代码写得很漂亮，也可能因为理解错了规则而实现错误。

这时候就适合用 /grill-with-docs。它会结合代码库分轮追问，把规则和术语讨论清楚，并记录符合条件的关键决策。

当前版本会把明确的领域术语写进 GLOSSARY.md。对于难以撤销、需要解释背景且存在实际取舍的决策，会记录为 ADR（Architecture Decision Record，架构决策记录）。

这里要注意：术语表和 ADR 不会自动保存全部业务规则。其他讨论结果可能仍留在聊天中。如果要换 Session 继续开发，最好先在当前会话用 /to-spec 整理成规格，再核对有没有遗漏刚才确定的规则。

4. 项目很大，决策相互依赖：用 /wayfinder

如果需求变成：

重构整个订单、支付和优惠券系统，支持新的退款流程。

这次要考虑的可能有订单状态机、支付回调、跨服务事务、历史数据迁移、灰度兼容，以及多个团队之间的接口约定。

这些问题之间还有依赖关系。例如，退款状态模型没有确定，后面的接口设计就很难定下来。

全放进一个长对话里，问题很容易越问越多。状态模型还没定，就开始讨论接口和补偿，后面又得回头重来。

如果一次对话已经装不下这些问题，就可以用 /wayfinder 来组织后续讨论。

它不是马上把需求拆成开发任务，而是先建立一张决策地图。

第一次对话建立并保存决策地图后就结束，不马上讨论具体规则。下一次对话读取已有地图，选择一个尚未解决、也没有被其他问题阻塞的决策，再展开讨论。

图里的“异常补偿”要等“退券规则”确定后再讨论。实际 Skill 会用关联的决策 Ticket 保存问题、处理状态和讨论结论，地图则索引这些记录。后续对话按需读取，不必重新翻一遍全部聊天。

两者的区别也就清楚了：

/grill-with-docs 适合把一个需求集中讨论清楚；/wayfinder 适合一次讨论不完的复杂需求，先整理待解决的问题及其依赖，再分多次对话逐个讨论，并记录每次的结论。

两者可以配合使用：地图中的某个问题，仍然可以通过一轮需求澄清来解决。

如果需求在一轮会话里就能澄清，直接上决策地图，反而会增加没有必要的流程成本。它不应该成为每个需求的默认起点。

5. 需求明确以后，怎么进入 Coding？

规则和设计取舍确定后，可以继续用 Matt 的另外几个 Skill，把讨论转成开发工作：

例如一个大型需求，可以按下面的方式推进：

但这不是要求每个需求都走完整流程。

已有明确方案，就从 Spec 或 Coding 开始；需要分批实施，再拆成 Ticket。

Skill 是用来解决问题的，不应该为了使用 Skill 而增加步骤。

6. 怎么安装和使用？

Matt 的 Skills 已经开源，可以通过 skills CLI 安装到支持的 Coding Agent。

项目地址：https://github.com/mattpocock/skills

只想试用 /grill-with-docs，要连同它依赖的两个 Skill 一起安装：

bashnpx skills@latest add mattpocock/skills --skill grill-with-docs grilling domain-modeling

如果想使用 /wayfinder 和后续整套工作流，可以安装全部 Skills：

bashnpx skills@latest add mattpocock/skills --skill '*'

安装时按提示选择对应的 Agent 和安装范围。使用 /wayfinder 等涉及决策 Ticket 的流程前，在目标仓库运行一次 /setup-matt-pocock-skills，配置问题跟踪工具和文档位置；也可以选择本地 Markdown 来管理决策。

随后在支持斜杠调用的环境中，可以尝试：

markdown/grill-with-docs我们要在订单取消后退还优惠券，请先帮我澄清业务规则和设计决策。

或者：

markdown/wayfinder我们准备重构订单退款系统，涉及订单、支付和优惠券多个模块。先梳理需要解决的关键设计问题。

第一次使用建议先选一个真实但规模可控的需求，看看 Skill 最终留下的文档和决策是否足以支持下一阶段的开发。

7. 最后

结合 Matt 这套工作流，我觉得可以按需求是否明确、能否在一轮会话里讨论清楚，选择三种入口：

以前我们很容易把“先规划”当成一条通用的 AI Coding 建议。但一个小 Bug 和一次大型系统重构，显然不需要相同的流程。

规划本身不是目的，减少错误决策和后续返工才是。

8. 参考资料

• Matt Pocock / Total TypeScript：https://www.totaltypescript.com/

• Agent Skills 开源仓库：https://github.com/mattpocock/skills

• /grill-with-docs ：https://www.aihero.dev/skills-grill-with-docs

• /wayfinder ：https://www.aihero.dev/skills-wayfinder

• /setup-matt-pocock-skills ：https://www.aihero.dev/skills-setup-matt-pocock-skills