Claude Code 有一个功能叫 /advisor，思路是这样的：你用一个便宜的模型（比如 Sonnet 或 Haiku）当主力干活，遇到拿不准的时候，它自己决定去请教一个更强的模型（比如 Opus 或者 Fable 5）。Opus 看完整个对话上下文，给一个方案或建议，然后主力模型继续干。

听起来挺聪明的对吧？用便宜模型跑大部分流程，只在关键节点花钱请教贵的模型，省钱又不牺牲质量。

但我觉得这个设计有问题。

关键在于：什么时候该去问，是由弱模型自己决定的。这就引出几种很现实的可能：

第一种，它的方案本身就设计得很糟糕，问出来的问题也问不到点子上。就像一个能力不够的新人去请教专家，他连问题都描述不清楚，专家再厉害也没法给出有针对性的建议。垃圾进，垃圾出。

第二种，它很自负。它觉得自己的方案没问题，明明应该去请教更强的模型，但它判断不出自己需要帮助，于是一路闷头做下去。最后交出一个有隐患的结果，顾问从头到尾没被叫过一次。

第三种，它又太不自信了。稍微遇到一点不确定就跑去问，每走两步就请教一次 Opus。那你省什么钱了？还不如直接用 Opus 干。

这三种情况其实指向同一个问题：让一个能力不足的模型来决定什么时候该求助，本身就是一个超出它能力范围的判断。

所以我一直觉得，更合理的方式应该反过来：让聪明的模型去做设计和规划，让便宜的模型去执行具体的操作，最后再让聪明的模型来验收。设计靠高手，执行靠苦力，质检靠高手。这才是性价比最高的组合方式。

我日常都是用 Fable 5 去设计，Opus 或者 GPT 执行，最后 Fable 5 再验收，相对效果还可以。