测试一下哪个模型适合当主力模型的协作模型

在我日常使用Claude的过程中，我发现Opus等模型在细节实施的过程中表现经常不太好，但是整体的规划能力还是比较出色的。

于是我尝试了让Claude在一个任务需要具体编码的时候，利用各种harness cli的非交互模式来负责具体的实施。

也就是Opus 5/Fable 5做整体的分析、规划，一些更快、更小的模型来负责具体的编码、测试等，既节省了成本，又让整体的质量得到了保证。

但是，各个模型在和Claude模型配合的时候，质量、速度表现差距是比较大的，于是我用我们线上仓库创建了多个worktree，选用线上一个真实存在的issue和Opus的分析作为输入，由各个模型自己分析实现方案，再用review的结果作为验收标准，与此同时，会有opus-5和gpt-5.6-sol-max两个模型的实现作为对照。

目前仅列出我实际尝试过的几个模型

一、速度表现

值得注意的是，耗时最长的luna的输出token反而是四个里最少的（21269），这也和用下来的实际感受接近，luna会花费大量的时间在生成以外的工作上，如果各位佬用上下文不够长的编程问题测试luna，会发现luna的表现很不错，属于是又快又好，但是在实际工作过程中使用luna，就会体验到什么叫又香又臭。

Sol，这位更是重量级，从一个issue描述开始无限发散，一个任务跑了2700s+还在继续发散，直接给我15$的cursor三方模型额度跑光了，只能说还好我的cursor只花了2$订阅了一个月，否则我还不得心疼死，显然，Sol是不适合作为一个协作模型的。

二、质量表现

质量来说这四个模型的实现都是有问题的，整体来看luna的表现最好，甚至我认为实现质量是高于Opus 5自己实现的。我最看好的哈基米此处给到拉完了，我好久没有看到能给我编几个接口的模型了，Sol确实牛逼，即便是中断了，新引入了一大堆的机制后，review出来的问题都是最少的，但是这个无限发散的修改在项目里实际上是不OK的。

总的来说，要效率选composer-2.5，要质量选gpt-5.6-luna-max，顺便这个结果也告诉了各位佬友，目前的模型，即便是Opus 5，5.6 Sol，输出的代码也并不能一次性解决线上的问题，甚至如果没有人主动干预的话，问题还会变得越来越糟糕，仅依赖vibe coding，会导致整个项目越来越难以维护，也许coding已经死了，但是engineering还活着。