大模型编程应用测试-V3榜单：以工程应用标准量化模型能力

#0 前言

笔者最早的编程测试V1采用传统的3 Pass测试法，25年下半年迭代了更贴近多轮场景的V2测试法。但仅测试3轮的V2方法局限性仍然很大。首先，该方法只观察模型在3轮自主修复中能取得的最终成绩，而实际Agent场景中，编程模型拥有几乎无限的轮次，只要能解决问题即可。其次，V2方法只提供运行结果反馈，不提供工具，而实际Agent可以借助Lint/Compile/Shell等工具完成任务。擅长使用工具的模型，可以在更低的硬智力要求下，交出更可用的代码。因此，V2测试法更侧重考察编程模型的基本功，类似于人类一场不允许带计算器的闭卷考试。

编程基本功固然重要，但并不能作为一线开发选择模型的首选参考。就好比企业用工更看重解决问题的思路和项目经验，而不是高考成绩。

于是从9月开始，笔者一直在构思一套完全拟真的V3测试法。这个方法需要基于ClaudeCode/Codex CLI等实际Agent环境，涉及多种语言和技术栈，以充分考察模型在不同场景的适应性。以及最重要的，该方法需要具备清晰的打分标准，能体现模型间的差距。

V3测试的核心目标总结起来就是一句话：以最接近工程应用的标准，进行可量化的模型应用能力评判。

但在V3准备期间，国内外大模型团队几乎日更大模型，导致分散了很多时间去做逻辑测试，V3测试推进缓慢。加上每个模型的每个测试都需要3到4天时间，原本计划在元旦当天发布的首期V3榜单，延期到了今天。

由于是首期测试，入选的模型并不多。好在工程测试的题目更新频率不会像逻辑题目那样快，预期当前题目至少保持3个月。3个月后也会积累下比较可观的已测模型数量。

#1 工程介绍

首批测试准备了3个工程，简介如下。

C工程：以Swift语言编写面向macOS的OpenGL渲染器，考察小众语言、图形领域知识及重交互场景。
D工程：基于Flutter开发一款全功能聊天软件，同时以Golang开发对应服务端。考察移动端开发、数据库及多种网络通信处理。
E工程：自选技术栈，开发纯网页端视频剪辑应用。考察前端技术栈、音视频处理及复杂状态管理。

每个工程会将项目拆解成10到12轮的prompt，每一轮prompt包含完整的要求和考察点。平均每个工程的prompt字数在1500到2000字左右。

A和B工程是之前用来探索测试方法的项目，为了编号的连续性，正式项目从C开始。

#2 测试过程

初始化
不同工程有不同的初始化设置。C工程会手动通过XCode模板创建基础环境，D和E工程则是从空目录开始。三个工程中用到的基础环境，包括npm、flutter、node、clang、xcodebuild等都确保可用。除了GPT系列模型使用自家Codex CLI之外，其他模型均使用Claude Code。

基础轮
每个项目的10~12个原始prompt就是基础轮输入，对所有测试模型，基础轮的输入都相同。每进行2~3次基础轮，会进行一次上下文清除（/clear, /new 命令），用于模拟需求追加的情况。

修正轮
当模型的输出无法满足需求时，需要进行修正。修正轮的提示词内容不一致，但遵循相同格式，包含：所有可见Bug的现象描述、关键操作描述，如果有log则附带log。因为测试是模拟vibe coding，所以即便笔者知道错误原因，也不会给模型提示。这一点和实际应用略有区别，特此说明。模型一轮修改不对，就进行多轮。如果3轮仍无法修正问题，则进行rewind/revert，清除代码和上下文后重试。重试后再过3轮还是无法修正，则退出测试。实际应用时，遇到这类情况也会更换模型，本质上也是否定了该模型在对应问题上的处理能力。

打分规则
对于不符合预期的表现，采用阶梯扣分机制。
* 可以改善：不扣分。Prompt没有强要求，功能有显著改善空间。
* 轻度不符合预期：-1分。UI与预期偏离，但不影响使用；功能有问题，但不阻塞主流程。
* 功能异常：-2分。编译不通过；运行崩溃；与Prompt明确要求的核心内容完全不符；阻塞主流程的功能问题。
* 重启：-4分。该轮使用了revert/rewind重启。

只有功能异常阻塞后续测试，才会要求修正，其他问题不处理，只扣分。一轮输出中即便有多个Bug，也只扣一次分，因为只要模型能一次性改完，Bug数量不是问题。如果一次改不完，就会产生二轮修复，在第二轮继续扣分。

总分
模型在所有轮次下的总扣分加和就是总分，按3个工程的总分进行正序排序。如果无法完成任意工程，则总分标记为无效。

#3 榜单

#4 点评

Opus 4.5：现阶段无可争议的最强Vibe Coding模型。具有极强的UI审美和实现能力，也有精确发现问题的能力。往往会有较多的“额外”发挥，主动补足需求中未提到、但预计会用到的功能和实现细节。这些细节包括但不限于：给图片加载增加loading和渐入动画、UI切换的动效、高精度的SVG icon、精致的错误提示、操作状态预览等。

Opus即便直出代码有Bug，只要能精确描述问题，模型都能一遍改对。在3个项目中，Opus只出现了1次一遍改不全、落入第二轮修正的情况。

但Opus的分数看起来落后于gpt-5.2-codex，是因为Opus输出的代码量偏大，加上自由发挥增添了许多细节，导致工程的复杂度实质上要高于GPT的版本，Opus在丢失上下文后，无法一次性把握所有细节。但综合考虑到Opus的细节表现，毫无疑问实战中Opus的实用性要更强，尤其当用户无法准确表述自己需求时，Opus的“补全”能力可以给予用户极佳的“外置大脑”体验。

GPT-5.2-Codex：一把精准的外科手术刀。先前GPT-5.1-Codex-Max曾参与项目C的测试，其成绩介于Sonnet和Opus之间。而新的5.2-Codex则全面超越5.1，在严格的prompt遵循方面超越了Opus，严格到prompt说什么就是什么，绝不多写一行代码。没有要求UI，那么UI就只在及格线；没有要求交互，那交互就是能用就行。当然代码性能是不含糊的，就算不要求，Codex也会写最佳实践。因此Codex很容易写出功能上满分，但UI交互等细节上及格的产物，与Opus相比有着巨大的差距。

这种指哪打哪的严格性，使得Codex非常适合解决疑难Bug，而非用于大型项目的奠基。但如果用户愿意针对Codex的性格，编写十分详细的prompt，Codex也可以一次性完成超高复杂度的UI和交互。在Codex的3个项目中，同样没有需要改2轮的代码，这方面和Opus不相上下。

Sonnet 4.5：进入Vibe世界的守门员。3个项目在开发阶段，是用Sonnet当参照物，工程难度卡在Sonnet勉强通过的程度。这种先射箭再画靶的方式，让Sonnet的成绩看起来颇为堪忧。Sonnet大约有一半的基础轮会犯错，其中又有一半以上的修正轮无法一次性改对全部问题。有些较为复杂的问题，仅靠Sonnet甚至难以发现。对此，Sonnet的策略是大量添加log，这个策略还算有效，靠log定位了多数bug，但留下了混乱的代码有待用户自行收拾。Sonnet在细节效果方面，离大哥Opus距离遥远，如果Codex的版本算及格线以上，那Sonnet则是在及格线上下徘徊。

但考虑到V3测试比用户实际使用要难一些，所以Sonnet在用户手中，大概率用起来会顺畅一些。而且考虑到Sonnet相对均衡、不偏科的编程知识，足以应付各类挑战。

MiniMax M2.1：偏科的中等生。M2.1在一定程度上达到了官方宣称的表现，具备还算不错的前端和App端开发能力及独特的审美。但也仅限于此。项目C中，M2.1甚至搞不明白macOS的storyboard到底要怎么写，OpenGL的渲染管线要如何搭建，在非常早期就Fail掉。项目E中也因为没有彻底理解React的事件运作机制，导致一个交互冲突无法解决，离Fail只差1轮。

即便如此，M2.1 也是现阶段编程能力最接近 Sonnet 4.5 的模型。它在许多方面都显现出师承 Claude 系列的影子，例如倾向于自由发挥、偏好使用日志定位问题，偶尔能带来超预期的表现。然而，M2.1 的“智力”水平尚不足以完全驾驭其宏大的实现意图，导致最终交付的产物往往只是勉强可用。若想达到与 Sonnet 同等的效果，用户需要在细节上提出更明确、更具体的要求。

M2.1 还存在两个显著问题：指令遵循具有随机性，且幻觉（胡编乱造）率偏高。当同时提出多个 Bug 时，M2.1 往往只修复其中一个，却产生幻觉认为自己已全部完成。这一现象在三个测试工程中均有出现。不过，通过增加交互轮次，M2.1 大体上还是能够逐步修正全部 Bug。因此，给 M2.1 用户的建议是：不要像使用 Claude 那样一次性提交大段复杂要求，而应主动将任务拆解为更细的步骤。

GLM 4.7：严重的上下文遗忘问题。GLM 在三个测试项目中均告失败，这颇为可惜。除了在 C 工程中因知识储备不足而失败外，其在 D 和 E 项目开局阶段的表现其实尚可，与 M2.1 不相上下，工程结构严谨度几乎比肩 Sonnet。但随着交互轮次增加、代码量增大，GLM 的表现迅速劣化。它开始频繁遗忘前文内容，甚至是刚刚提及的要求。尤其当上下文（Context）被撑满并触发自动压缩后，GLM 会陷入一种“完全失忆”的状态，不清楚自己正在做什么，从而改坏已有的正确逻辑。失忆后，GLM 为了弄清状况又会频繁读入更多文件，导致上下文被再次快速消耗，最终陷入既无法读取必要文件，也无法有效生成代码的困境。

但 GLM 也并非完全不可用，这要求用户必须主动做好上下文管理：尽量避免触发上下文压缩，并提供更精准、简洁的任务描述。在此条件下，GLM 可以作为 Sonnet 的一个下位替代品。在某些场景下，GLM 生成的 UI 代码甚至比 Sonnet 的输出略为精致。

#5 结语

V3 测试的复杂度确实远超其他类别的评测。虽然最终呈现的仅是每个项目的一个得分数字，但每个项目背后都有一份详细的步骤记录底稿。这些底稿原则上不公开，但未来会在合适场景下提供脱敏后的版本。

本次测试虽然尽力固化了环境，但未能完全抹平环境差异性。例如，Claude Code 的版本在为期两个月的测试中，从 2.0.55 升级到了 2.0.76，理论上后期参与测试的模型具备一定版本优势。

接下来将补充对 Gemini 3 Flash 的测试。而 Doubao-Seed、Qwen-Coder、KAT-Coder 等模型，由于在前期 A/B 项目测试中表现不佳，面对难度更高的三个正式项目，其成绩亦可预见，因此暂不纳入本次测试范围。

附录

测试底稿样本：https://ai.feishu.cn/wiki/VMS9w1f2CiGid6kLkl3cshtPn3d

关注“鲸栖”小程序，掌握最新AI资讯