Linux.do论坛一位开发者分享了同时使用GPT、Claude、Gemini三大模型进行编程协作的实践经验。作者认为早期CCS等多模型协作项目过于笨重、方案死板，实际工作中更应根据各模型特点灵活分工。根据其使用体验：GPT系列模型是“细节狂魔”，写出的代码基本一轮通过、bug率低，排查问题能力显著强于其他两家，但存在过度工程化、防御性编程过多、生成速度慢、表达机械、前端质量差等短板，适合负责后端架构维护及审查其他模型的方案漏洞。Claude Opus系列被评价为均衡型模型，几乎没有明显短板，表达自然，可放心承担主要开发工作，但编码中可能遗漏细节，需配合Codex审查方案后一轮通过验收。Gemini系列则被认为最具灵性、人机交互体验最佳，前端能力尚可，但执行时容易丢三落四，直接干活的能力约相当于DeepSeek。作者计划将Gemini设为主模型，由其调度Claude Code和Codex完成具体施工，以规避Antigravity在harness能力上的缺陷。作者目前效率最高的工作流是以Claude Code为主力，施工前让Codex审核方案，并由Claude Code直接调用codex-cli/">Codex CLI完成审核，同时向社区征求更多多模型协作经验。
事件分析
这则讨论反映出AI编程工作流正从早期重量级编排框架向轻量灵活的“主模型调度+子模型施工”模式演进，模型编排能力成为关键变量。文中提及的Antigravity等agent化开发环境虽代表方向，但其harness（工具调用框架）不成熟，仍需借助外部CLI工具补足，说明编排层尚未形成稳定范式。从产业视角看，OpenAI系模型偏细节与调试、Anthropic系均衡可靠、谷歌系交互体验突出但执行力不足，各家能力分化催生了“模型混用”的真实需求，这将推动统一编排协议（如MCP）与模型路由服务的发展。若主模型稳定调度其他模型的模式跑通，AI编程的竞争焦点将从单模型能力转向组合协同，harness与编排基础设施的成熟度或成下一个决胜点。
核心观点：AI编程正从单模型能力比拼转向多模型编排竞争，谁能做好“包工头”式调度层，谁就掌握下一代开发入口。
原文链接：Linux.do
评论前必须登录！
立即登录 注册