实测主流大模型协作编程效能：Opus 规划下，谁才是最佳执行模型？

一项针对大模型协作编程能力的实测引发关注。该测试模拟了真实的开发场景，利用 Claude Opus 担任整体规划与架构分析角色，而将具体的代码实施工作分配给不同的模型执行。测试选取了包括 Composer-2.5、Grok-4.6-medium、Gemini-3.7-flash-high、GPT-5.6-Luna-max、Opus-5-max 以及 GPT-5.6-Sol-max 在内的多个模型，基于线上真实仓库的 Issue 进行修复，并以 Code Review 结果作为验收标准。

在速度表现方面，Composer-2.5 耗时最短（约 455 秒），且性价比最高。Grok 和 Gemini 表现中规中矩，而 GPT-5.6-Luna-max 虽然输出 Token 数量最少，但耗时较长。GPT-5.6-Sol-max 则出现了严重的“发散”现象，耗时超过 2700 秒仍未完成，甚至耗尽了测试额度，显示出其在长上下文任务中的不稳定性。

在代码质量方面，测试重点关注了状态机死锁、阈值判断、鉴权等结构性陷阱。结果显示，所有模型生成的代码均存在不同程度的缺陷。其中，Luna-max 在实现质量上表现最佳，优于 Opus 自身的实现；Composer 虽然速度快，但存在状态机死锁等问题；Sol 虽然引入的新机制较多，Review 出的问题最少，但因无限发散导致无法交付。

结论指出，在追求效率时应选择 Composer-2.5，追求质量则首选 GPT-5.6-Luna-max。该测试强调，即便是最先进的模型也无法一次性完美解决复杂工程问题，缺乏人工干预的“Vibe Coding”会导致项目维护难度增加，AI 时代“软件工程”的严谨性依然不可或缺。

事件分析

核心观点：大模型分工协作已成趋势，但纯粹依赖生成的“Vibe Coding”不可取，严谨的工程审查仍是代码质量兜底的唯一防线。