DeepSeek V4 vs GLM-5.1 vs GPT 5.5 编程实测：真实项目开发谁更强？

最近AI圈又热闹了，DeepSeek V4和GPT 5.5几乎前后脚发布，跑分数据都特别亮眼。但今天我想聊一个更实在的问题——跑分高，真的等于写代码好用吗？"}, {"speaker": "guest", "text": "这个问题太好了，其实做过真实项目开发的人都有体感，跑分和实际干活完全是两码事。你看HumanEval、MBPP这些基准测试，考的基本是独立的算法函数题，就像考试做选择题一样，环境很干净。但真实项目呢？你得理解业务上下文，得跨文件协调修改，还不能把已有功能搞崩。这中间的差距其实非常大。"}, {"speaker": "host", "text": "对，所以今天我们要聊的就是一个特别有意思的实测。B站有个UP主叫阿超，他用自己维护了快一年、有7000多用户的浏览器插件SAR-BASE做测试项目，让GLM-5.1、DeepSeek V4 Pro和GPT 5.5来做同一个真实开发任务。这个测试设计我觉得挺硬核的。"}, {"speaker": "guest", "text": "嗯，确实硬核。先说下这个插件的背景，SAR-BASE是一款批量下载视频字幕的浏览器插件，用户反馈了一个痛点——视频明明有多种语言字幕，但插件只能导出中文的。所以这次的核心任务就是让AI来实现多语言字幕导出功能。"}, {"speaker": "host", "text": "听起来好像不算特别复杂？"}, {"speaker": "guest", "text": "你看，表面上是加个功能，但浏览器插件的架构其实挺特殊的。它有Manifest配置文件、Content Script、Background Service Worker、还有Popup页面，这些组件之间通过Chrome的消息API通信。你改一个功能，可能要同时动好几个文件，而且还得遵守浏览器的安全沙箱限制。所以对AI来说，难点不是写一段代码，而是理解这种分层架构，改的时候不能把已有的消息通信链路搞断。"}, {"speaker": "host", "text": "明白了，这就是为什么用真实项目测试比跑分有意义得多。那具体任务是什么？"}, {"speaker": "guest", "text": "四个核心点：在表格里新增字幕语言列、接入字幕语言获取接口、实现多语言字幕的选择和导出，最关键的一条——新功能不能破坏已有功能。三个模型用完全相同的提示词，GLM-5.1和DeepSeek V4 Pro都用VS Code里的Cloud Code插件，GPT 5.5用的是OpenAI自家的Codex插件。"}, {"speaker": "host", "text": "好，那我们直接看结果。先说GLM-5.1？"}, {"speaker": "guest", "text": "GLM-5.1的表现，说实话可以用"教科书级别"来形容。它上来先给了一个非常清晰的To-Do列表，把整个任务拆成了多个步骤，然后一步步执行。开发者能清楚看到它每一步在干什么，整个思考链路特别透明。"}, {"speaker": "host", "text": "这个To-Do列表其实挺重要的，对吧？它不只是给人看的。"}, {"speaker": "guest", "text": "对，这其实是两个作用。第一，它让开发者能校验AI是不是正确理解了需求，相当于一个人工确认的窗口；第二，它给AI自己建立了一个结构化的执行路线图，降低遗漏功能点的概率。你可以把它理解成思维链推理在工程场景中的应用。最终结果呢，字幕语言列正常显示，中英文及其他语言选项都完整，多语言全选导出没问题，已有功能也没被破坏。一次性通过，零修复。"}, {"speaker": "host", "text": "这在真实项目里确实难得。那DeepSeek V4 Pro呢？"}, {"speaker": "guest", "text": "DeepSeek V4 Pro有一个很明显的差异——它没有给出To-Do列表，开发者不太清楚它具体计划怎么做。不过基础功能是完全OK的，字幕获取成功，导出内容也没问题。但有一个UI上的瑕疵，下拉框样式有问题，五种语言只能看到三种，而且没法滑动查看。"}, {"speaker": "host", "text": "功能逻辑对了，但用户体验打了折扣。"}, {"speaker": "guest", "text": "是的，对于一个有7000用户的正式产品来说，这种样式问题虽然不影响核心逻辑，但用户是会直接感知到的。"}, {"speaker": "host", "text": "GPT 5.5呢？我记得它还有个速度问题？"}, {"speaker": "guest", "text": "对，GPT 5.5通过Codex插件测试，它的思考链路其实还算清晰，功能点罗列也挺完整。但最大的问题是慢——花了大概15分钟才完成代码修改。这跟Codex的架构有关，它是异步任务模式，提交需求后在云端沙箱里独立完成，再把结果以Pull Request的形式返回。有点像你委托一个远程开发者干活，效率上天然就慢一些。功能结果呢，和DeepSeek类似，基础逻辑没问题，但下拉框也有样式问题，被其他元素遮挡了。"}, {"speaker": "host", "text": "有意思，两个模型都栽在了CSS样式上。这是巧合吗？"}, {"speaker": "guest", "text": "其实不是巧合，这是AI编程助手的一个普遍短板。大模型训练时主要学的是代码的逻辑结构和语义关系，但CSS的视觉表现高度依赖上下文——同一段CSS在不同的DOM结构、不同的父元素overflow设置、不同的z-index层叠上下文里，渲染出来可能完全不一样。模型很难光看代码文本就推断出最终的视觉效果。所以你会发现，逻辑功能往往能一次过，样式细节却经常需要二次调整。"}, {"speaker": "host", "text": "除了真实项目，这次测试还有一个3D页面生成的环节，用同一个提示词生成3D智慧城市监控大屏。结果怎么样？"}, {"speaker": "guest", "text": "GLM-5.1拿了9.8分，房屋建模和汽车动态效果都很出色，拖拽交互特别丝滑，完成度最高。GPT 5.5得了9.5分，整体完成度也不错，但运行时电脑明显卡顿，性能开销比较大，很可能是没有做几何体合并优化。DeepSeek V4得了9.0分，3D场景基本完整，但车辆移动速度太快不自然，而且左下角的实时事件区域文字重叠了。"}, {"speaker": "host", "text": "GPT 5.5那个卡顿问题挺有代表性的，能写出功能正确的代码，但不一定能写出高效的代码。"}, {"speaker": "guest", "text": "没错，这就是当前大模型普遍缺乏性能意识的体现。它知道怎么实现功能，但不太会主动去优化Draw Call数量、控制几何体面数这些影响渲染性能的关键因素。"}, {"speaker": "host", "text": "那综合来看，这次测试给我们的最大启示是什么？"}, {"speaker": "guest", "text": "我觉得最核心的一点是"一次通过率"的价值被严重低估了。每次代码需要修复，开发者都要重新阅读AI生成的代码、定位问题、描述修复需求、再验证结果。有研究说程序员被打断后平均要15到25分钟才能恢复专注状态。所以一个一次通过率90%的模型，实际生产力可能远超一个通过率70%但跑分更高的模型。"}, {"speaker": "host", "text": "嗯，这个视角确实很实际。当然也要说一句，这只是一个特定场景下的测试，不同项目类型可能会有不同结论。但至少在真实复杂项目迭代这个最贴近开发者日常的场景里，稳定性和一次通过率，可能真的比跑分榜上那个数字更值得你关注。"}, {"speaker": "guest", "text": "对，选AI编程助手，别光看考试成绩，得看它到了工地上能不能真正干活。"} ],