开发者按使用场景分类推荐大语言模型方案

好了！随着这一周疯狂发布模型的尘埃落定，我已经敲定了一套新的模型组合，在这里分享出来供大家参考。

这次我的分类方式更有条理一些。我把各种大语言模型分到了几个类别里：

1. 交互调度器
这些模型是我用的大副（以及二副），因为它们速度快、效率高、对话体验好，足够聪明能理解我的意图，判断力也足够好，能帮我调度其他“船员”干活。
这一类目前是 Opus 5.5 和 Grok 4.7。
如果我的订阅额度用完了，也有可用的平价替代方案：Muse Spark 1.3、DeepSeek V4 Flash。

2. 高阶智能模型
这些模型我只用来处理高度模糊或者需要创意的任务，只有这类任务真正需要额外的算力，也配得上它们的成本。
我也用这类模型处理升级问题——当其他“船员”互相卡bug了，当审查循环失控了，当一个简单修改最后莫名其妙变成了一个巨型PR，我就会调用这些模型帮我理清混乱。
目前这类是 GPT 6 Astra 和 Fable 5.1（如果 Fable 额度不够就用 Opus 5.5）。

3. 规划器
这类模型是我默认信任的，用来规划新功能、排查复杂bug。它们会生成规格说明，然后交给更便宜的模型去实现。
目前我几乎只用 Opus 5.5 来做这个，因为它的投资回报率惊人，只要我不需要用到高阶智能就选它。

4. 执行者
这些是高效的干苦力活的模型，只要给它们一份定义清晰的规格说明，就能产出可靠的实现。
我目前用 Opus 5.5、GPT 6 Sol 和 Grok 4.7 来做这个，同样也有平价选项：Muse Spark 1.3 和 DeepSeek V4 Flash。（我相信还有很多其他可用的替代方案，只是我没时间去试它们）
在这些模型里，我目前发现 Sol 是最好的对抗性代码审查员（我还没用 Astra 做这个，因为这么大工作量用它太贵了）。

5. 小修小补模型
这些模型我用来处理极其简单的修改，比如一行代码修复或者配置修改。它们真的不需要多高的智能，因为要改什么往往已经定义好了。
这类我用 GPT 6 Luna，额度不够的时候同样用平价选项。

我实际使用这套分类的方式是，我把这些路由偏好告诉了“大副”，它就能帮我把正确的任务分配给正确的模型（现在因为 Jev 已经变得非常高效）。
最后我要指出一点，你能看到 Opus 5.5 在我的组合里有多全能——它几乎什么都能做！这是第一个覆盖了我几乎所有分类的模型，这个优势非常大，意味着如果我只能选一个订阅，目前我一定会选 Anthropic。