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

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

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

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

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

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

一、速度表现

模型 |
修复耗时 |
文件 |
+/- |
输出 token |

composer-2.5 |
454.9s |
7 |
+352/-118 |
23660 |

grok-4.6-medium |
803.7s |
13 |
+301/-21 |
45032 |

gemini-3.7-flash-high |
994.0s |
7 |
+300/-26 |
64366 |

gpt-5.6-luna-max |
1326.5s |
6 |
+415/-152 |
21269 |

opus-5-max |
1199.7s |
13 |
+1693/-42 |
- |

gpt-5.6-sol-max |
2700s+ |
23 |
+1551/-31 |
- |

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

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

二、质量表现

模型 |
修复耗时 |
findings |
缺陷性质 |

composer-2.5 |
454.9s |
11 |
状态机死锁，4个同根因；健康请求误判 |

cursor-grok-4.6-medium |
803.7s |
12 |
3个死机制 + security + 无用轮询 |

gemini-3.7-flash-high |
994.0s |
13 |
死分类器 + 2处引用不存在的东西 |

gpt-5.6-luna-max |
1326.5s |
7 |
跨数据串扰；无死机制 |

opus-5-max |
1199.7s |
6 |
状态恢复缺口×3 + 阈值窗口错 + 1个死机制 |

gpt-5.6-sol-max |
2700s+ |
5 |
无鉴权探测 + SSE热路径开销 + 丢用户输入；无死机制 |

结构性陷阱 |
**composer
2.5** |
**grok
4.6-med** |
**gemini
3.7-flash** |
**luna
max** |
Opus 5 |
sol max(中断) |

阈值套在错误的时间窗口
headers/TTFT 当成 body，健康请求误判 |
1 |
1 |
1 |
— |
1 |
1 |

失败状态没有恢复路径
进得去出不来，标志位无人清除 |
2 |
1 |
1 |
1 |
3 |
— |

阻止发送时丢用户输入
已清空 composer，守卫才拒绝 |
1 |
1 |
— |
1 |
— |
1 |

写了但永远不会触发的死机制
条件恒真/恒假，标志位无人读 |
— |
3 |
1 |
— |
1 |
— |

四类中踩中 |
3 |
4 |
3 |
2 |
3 |
2 |

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

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