Matt Pocock（281K ⭐ 开源项目 Skills For Real Engineers 作者）分享 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。
Should you /grill-with-docs, /wayfinder, or just one shot the code? 1. If the diff is tiny, DON'T grill /grill-with-docs saves you from situations where the agent built the wrong thing. But if the thing it's building is tiny, that cost drops to nothing. So one-shotting is absolutely fine when you're only making small changes. 2. Never start with /wayfinder A failure mode of /wayfinder is that you start grilling and the solution turns out to be way simpler than you thought. Why is this bad? Because you've created the map and tickets, and you realise you don't need them. So if the expected diff is medium-large, always start with a /grill-with-docs session. Then, if planning starts to get out of hand, just say "/wayfinder let's turn this into a map".在 X 查看被引用的帖子
来源：meng shao · x.com