Matt Pocock 分享了「AI Coding Agent 该用多重流程」的决策框架，按改动规模匹配流程重量，小改动直接写，中大型改动先澄清需求，规划失控时才升级到重型规划

无元无份

Matt Pocock 分享了「AI Coding Agent 该用多重流程」的决策框架，按改动规模匹配流程重量，小改动直接写，中大型改动先澄清需求，规划失控时才升级到重型规划

Matt Pocock 是 281K ⭐️「Skills For Real Engineers」开源 Skills 项目作者：
https://github.com/mattpocock/skills

这次他分享的是工作流中两个 / 命令的使用时机：
· /grill-with-docs  轻量澄清流程：agent 在动手前“拷问”你（grill），结合文档把需求问清楚，目的是避免“agent 把东西建错了”。
· /wayfinder  重型规划流程：先给代码库画“地图”（map）、拆工单（tickets），再按图施工。

1. 改动很小 → 不要 grill，直接 one-shot。
背后的推理是一个成本模型：前置澄清流程的价值 = 避免返工的损失。如果 diff 本身很小，“建错东西”的代价趋近于零，那么为它付出的流程成本就是纯浪费。流程的重量应该与错误成本成正比，而不是无脑套用。

2. 永远不要从 /wayfinder 开始。
他描述的典型失败模式是：一上来就跑重型规划，结果发现方案其实很简单，但此时 map 和 tickets 已经生成了，沉没成本之下反而被一套不必要的规划绑架。

正确姿势是渐进升级：预期中大型改动时，先从 /grill-with-docs 这种轻流程开始；只有当对话中发现规划明显失控、问题确实复杂时，再说一句 "let's turn this into a map" 切换到 /wayfinder。