贵模型只出方案与验收：省Token闭环

有人把省 Token 的模型分工做成了闭环工作流，动机写得很直白："Token 太贵，都是被逼的"：Fable 写设计方案 → 循环里 Opus 执行、Advisor（Fable）验收 → 直到通过为止。 三步拆开是这样的：第一步，/advisor fable 把顾问设成 Fable——之后用 Opus、Sonnet 时遇事不决会自动请教它，多出来的 Fable 消耗"可以接受也值得"，等于请了个高级工程师当顾问；第二步，复杂问题先让 Fable 出方案——高级工程师写技术方案，普通工程师照着执行；第三步，Opus 执行时带上一句提示词："完成后让 advisor 验收，按反馈修复，修完再验，直到通过"，还能配合 /goal 一起用。 关键收益是闭环自转：以前他得手动把文档带回 Fable 的会话里去验收（或者新开一个会话发过去），现在 Opus 实施完自己找 Advisor 验收、拿反馈、改到通过——人不用再当那个传话的快递。 被引用的那条 8 月旧帖补了两个省钱细节：方案先落成文档（方便批注修改、其他 agent 也容易接手）；文档确认后趁 Prompt Caching 还热先 /compact 一次——这时候压缩上下文最便宜，等缓存过期再压就贵了。省 Token 的功夫，一半发生在缓存过期之前。 我的看法：这套的精髓是把贵模型的使用压缩到两个决策点——出方案与验收，执行与返工都交给便宜的一侧；自动验收接上之后，人的角色从"质检"退回"抽审"。它也正好回应了另一条省钱路线（用机制拦住昂贵的读取）：省钱没有银弹，要么改路径，要么改分工——两套都成立，选哪套看你卡在哪一段。