“赛博同事们，谁是开发者的最优解？”
作者丨孟一凡
编辑丨马晓宁 梁丙鉴
你很难把 Coding 仅仅视为大模型的诸多能力维度之一。
和单纯的文本或图像生成相比，代码更明确的规则、严格的语法和可验证的结果只是部分原因。更为特殊之处在于，在 ChatBot 到 Agent 这条进化链上，Coding 意味着的工具调用、数据处理和复杂流程自动化，几乎承载了模型从“会说”走向“能干”的绝大部分期待。
一个值得关注的变化是，Coding 正在从眼花缭乱的 Benchmark 榜单中脱颖而出，成为一种模型竞争的基础设施级指标。无论 OpenAI 、Anthropic 、Google 还是其他厂商，在发布新模型时几乎都会将 Coding 场景作为大秀肌肉的选择。
某种意义上，这就是正在形成中的行业共识，即代码能力不仅意味着编程水平，更是衡量模型逻辑推理、工具使用和实际生产力的重要角度。
我们也很好奇，国产模型如今在 Coding 这条卷生卷死的赛道里已经进化到了何种程度。为此我们选择了五款以编程能力见长的国产模型，包括 DeepSeek V4 Pro 、Kimi K2.6 、Qwen 3.7 Max 、GLM 5.1 和 MiniMax M3 ，将它们放进同一个真实工程任务的场景里，并让 Claude Opus 4.7 担任裁判模型，从可运行性、正确性、可读性、可维护性四个维度量化评分。
接下来就看看，各家模型的表现如何。
编者注：此次测试选用模型，为截至 2025 年 6 月 10 日各家最新款旗舰模型，故随后发布的 Kimi K2.7 及 GLM-5.2 均未参赛。对上述两款模型的测试也将陆续发布，欢迎关注。
01
不写八股文，真正的压力测试
Coding 能力的测试也大有讲究。HumanEval 、MBPP 这些业界常见的 Coding Benchmark ，本质上都在测试模型会不会写代码。最常见的模式就是给出一道算法题，看模型能不能给出正确的解法。只能说程序员有自己的八股文，LLM 来了也得写一遍。
这种测试和真实工程开发之间，还有着不小的距离。实际干过开发工作的人就知道，最头疼的是产品经理甩过来一份含混不清的需求，你得自己去理清边界条件，此外数据库表能跑还不够，设计的时候就要把未来三个月的业务扩展都考虑进去。还有可维护性，你写的代码，同事也得能看懂，线上出了 Bug ，得从日志里能定位到根因。
跟这些相比，把代码写出来只是开始。
所以我们不做 LeetCode 跑分，不刷榜。这次测试选择用真实工程任务加裁判模型量化评分的模式，所有结果只有一个标准，那就是工程场景能不能用起来。
我们为这五款模型设计了两项任务。
任务 A 是完整交付一套优惠券系统，从数据库 DDL 设计到 Python 核心逻辑，再到 API 文档和部署方案，都需要模型独立完成。
很多模型发布的时候会选择一些“一键生成”的小游戏或者小程序作为 Coding 能力的展示，乍看亮眼，实际都是轻量级的小玩意儿。而这项测试考的就是“从无到有”的架构能力，字典表扩展性、双模式有效期、并发锁设计、滑动窗口防刷、模糊需求澄清，还要做到中国手机号正则校验。
任务 B 是 常见的 Bug 诊断修复，但我们在测试强度上下了功夫。模型会拿到一段包含五个预设陷阱的高并发秒杀代码，我们要求它诊断根因并修复。陷阱包括竞态条件超卖、Redis 缓存穿透、连接池配置不足、事务隔离级别不当、异常回滚遗漏。这项测试，关注的是模型“从坏到好”的工程嗅觉。
裁判模型 Claude Opus 4.7 会从可运行性（30%）、正确性（30%）、可读性（20%）、可维护性（20%）四个维度量化打分，最终成绩加权计算。
02
优惠券系统，差点集体翻车
测试刚刚开始，五款模型的表现就让人大跌眼镜。
问题就出在需求澄清这个环节。我们在 Prompt 里故意埋了一个模糊表述："短时间内高频领取需拦截"。看到这里，一个成熟的工程师就该主动追问了，什么叫短时间，一分钟还是五分钟，什么又叫高频，五次还是十次？
但令人意外的是，没有任何一款模型主动要求我们澄清这项需求，刚才提到的参数都是模型自己假设的。工程师素养是一个很难量化的隐形维度，至少在这一关，五家打了个平手：谁都没追问，谁也不比谁强。
在后续的架构设计层面，模型的表现出现了分化。MiniMax M3 拿到了全场最高的 95 分，裁判评语是："整体属于资深架构师水准的方案，正确性和可运行性最为出色。"
它在核心服务实现环节的 70 分虽然不是最高，但防刷与并发安全环节以 80 分领先。在高并发场景下，MiniMax M3 不仅关注到了功能实现，更可贵的是系统稳定性与可用性。
比如通过 Redis Lua 脚本实现库存原子扣减，从根源上避免超卖问题，采用滑动窗口限流机制，较传统固定窗口更精准地应对突发流量和恶意刷请求，同时引入熔断与降级策略，在下游服务异常时保障核心业务持续运行。这一整套组合拳，被裁判称为“工业级实现”。
Kimi K2.6 与 MiniMax M3 并列拿下了架构设计环节的第一名 95 分，但它的得分路径完全不同。
裁判给 Kimi 的评语是：“整体是接近资深架构师水准的方案，正确性与可维护性最佳。”它的数据库设计同样采用了字典表管理优惠券类型，没有掉进硬编码三个 type 字段的坑里。但 Kimi 真正的杀手锏在可维护性，它为每个接口编写了完整的类型注解和文档字符串，连 Redis 连接池的异常重试策略都写了详细的注释说明。Opus 4.7 在可读性维度上给了 4 分，扣掉的 1 分是因为它用了 ASCII 流程图来展示架构，“排版略逊”。
但到了核心服务实现环节，Kimi 只拿到 70 分，与 MiniMax 持平。问题出在一个架构级的致命疏忽：Redis 扣减库存成功后，如果 DB 落库失败，系统没有最终一致性补偿机制。这意味着在大促期间一旦出现网络抖动，用户明明抢到了券、Redis 也扣了库存，但数据库里却没有记录，也就是券凭空消失了。Opus 4.7 的原话是：“Redis 与 DB 无最终一致性补偿机制，高并发下可能出现数据不一致。”
这是一个典型的“想得周全、做得规范、但漏了最关键的一环”的案例。
DeepSeek V4 Pro 在架构设计环节拿到了 85 份，表现尚可，裁判称赞其“正确性最佳，几乎完全覆盖需求与边界场景”。但到了核心代码实现环节，分数跌到了 65 分。
问题出在业务逻辑正确性上，Opus 4.7 发现 discount_value 范围限制和防刷的 key_TTL 的设置有误。前者可能导致异常折扣甚至业务规则失效，后者则意味着限流窗口过短、过长或被不断刷新，从而削弱防刷效果甚至影响正常用户使用，都踩在真实场景的雷区上。
Opus 4.7 评语的原话是：“结构与并发处理思路最好，最差是正确性。”
这揭示了一个有趣的现象，DeepSeek V4 Pro 很会"想"，但不太会"做"。它在架构层面的抽象能力堪称一流，数据库设计用了字典表管理优惠券类型，而不是硬编码三个字段。但当涉及到把设计落地为可运行代码时，它却会在边界条件上犯低级错误。
此外 Qwen 3.7 Max 和 GLM 5.1 也各有可圈可点之处。
Qwen 3.7 Max 在架构设计环节拿到了 90 分，裁判评语是：“正确性和可运行性表现最佳，覆盖参考答案全部要点且落地方案完整。”它的亮点在于工程化考虑非常周全，不仅实现了核心逻辑，还主动给出了 Docker Compose 部署配置和压测脚本，Opus 4.7 在可运行性维度上直接给了 5 分的成绩。
但 Qwen 的短板也很鲜明。核心服务实现只拿到 60 分，突出问题是折扣类型用 if/elif 硬编码分支，而不是策略模式或配置化。这意味着如果下个月业务方说要新增一种“随机立减券”，开发者必须改核心代码、重新部署服务，这在真实工程里是不可接受的。此外，Opus 4.7 还提到它的可读性“相对最弱”，原因是缺少架构图示，纯文字描述让方案的直观性打了折扣。
可以说，Qwen 是一个“能跑起来、但不好维护”的典型。这是 OPC 验证的首选，但对于长期迭代的任务，还需要努努力。
GLM 5.1 同样在架构设计环节拿到了 90 分，裁判评语几乎和 Qwen 的一样：“正确性和可运行性是最强项，覆盖参考答案全部要点并落地完整。”它的数据库设计被 Opus 4.7 评价为“兼具可执行性与可扩展性”，优惠券类型字典表、有效期双模式、防刷滑动窗口等核心锚点全部命中。
但 GLM 在核心服务实现环节也只拿到 60 分，问题出在安全性而非架构上。Opus 4.7 发现它的 schemas.py 中，CouponCreate 的 type 字段缺少合法的枚举校验，这意味着攻击者可以直接传入一个非法的优惠券类型值，系统不会拦截，而是可能直接入库。在真实生产环境中，这是一个潜在的安全漏洞。
更致命的是并发安全环节，GLM 只拿到 75 分，是五家中的倒数第二。它的防刷实现虽然用了滑动窗口的大框架，但细节上有瑕疵。Opus 4.7 指出“限流粒度偏粗，未区分用户级与 IP 级双层防护”，在面对专业羊毛党时可能会被突破。
表 1：任务 A 各环节得分
不过综合成绩看下来，所有模型在这项任务中的表现都算不上优秀。MiniMax M3 和 Kimi K2.6 并列第一，拿下 81.0，最低分则是 DeepSeek V4 Pro 的 73.5。放在百分制里看，这相当于全班第一名考了 81 分。不是学霸太强，是试卷太难，这种复杂架构的从零生成，的确是今天 Coding 模型的一大痛点。
03
Debug 是所有人的舒适区
如果说任务 A 是一次集体挂科的期中考试，那任务 B 就是期末补考。全班都及格了，甚至考得还不错。得分最高的仍然是 MiniMax M3，拿下 89.7 分，分数最低的 GLM 5.1 也有 79.0，基本都在 80 分段以上。这意味着，给一个现成的 Bug 让模型找，比让模型从零写一个无 Bug 的系统，要容易得多。
在找 Bug 这件事上，MiniMax M3、DeepSeek V4 Pro、Qwen 3.7 Max 的成绩并列。三家的 Bug 发现率都拿到了 90 分，也就是命中了五个预设陷阱中的至少四个。
DeepSeek V4 Pro 在这一环节的表现尤其值得关注。虽然在任务 A 中排名垫底，但在 Bug 诊断中它与 MiniMax M3 和 Qwen 3.7 Max 并列第一。Opus 4.7 指出，它覆盖了全部预设问题且结构清晰，在正确性和可读性上表现最佳。一种可能的解释是，或许 DeepSeek V4 Pro 的强项恰恰是理解复杂逻辑。
在修复质量上，Kimi 与 MiniMax 的得分并列第一。
Kimi K2.6 以 90 分的总分与 MiniMax M3 持平，裁判给了很高的评价，称其修复方案“整体是一份接近生产级的修复方案，可读性和可维护性最佳，包括注释三段式、配置中心和结构化日志。”
一个值得注意的细节是，Kimi 在修复代码中引入了配置中心，也就是将将限流阈值、连接池参数、超时时间全部外置。如果这三者被写死在代码里，那么一旦线上流量变化或环境切换，就必须重新修改代码、测试并发布版本，维护成本很高，也容易引入新的问题。
Opus 4.7 评价其为生产级的原因也在这里，引入配置中心意味着这些运行参数与业务逻辑解耦，运维或开发人员可以根据实际负载动态调整配置，无需重新部署服务，大幅提升了系统的灵活性和可运维性。
更重要的是，开发、测试、预发、生产的不同环境下往往需要不同参数配置。配置中心能够实现统一管理、版本控制和灰度发布，避免“本地正常、线上异常”的配置漂移问题。在高并发系统中，限流、连接池和超时参数本身就是稳定性治理的重要抓手，将其外置说明 Kimi K2.6 考虑到了系统长期运行和持续演进的需求，而不是仅满足当前场景。
在基础修复之外，五款模型都给出了架构层面的优化建议。MiniMax M3 、Kimi K2.6 、GLM 5.1 在这一环节都拿到了 90 分，其中 MiniMax M3 的建议被认为在“结构化呈现 + 全维度运维考量”上最为出色，涵盖了缓存预热、异步落库补偿、限流降级、监控告警和容量规划五个维度。
容量规划
Kimi 和 Qwen 在架构优化中都提到了“扩容”，但基本上是“建议增加 Redis 节点”这种原则性表述。MiniMax M3 则给出了具体的扩容阈值和分片策略，比如 QPS 达到多少时触发扩容、Redis Cluster 分几个 shard、每个 shard 的内存上限设多少。Opus 4.7 正是因为这些数字而扣了它的分（“部分容量数字未给出具体计算依据”），但反过来看，敢给具体数字本身就说明它在运维落地层面想得比其他模型深一层。
异步落库补偿机制
其他模型（包括 DeepSeek V4 Pro 和 Qwen 3.7 Max）都提到了“异步写 DB 来降低 Redis 延迟”，但基本上点到为止。MiniMax M3 则在这个基础上补了一个补偿链路的设计，如果异步落库失败，如何通过消息队列重试、失败后多久触发告警、以及如何在不一致时做数据对账修复。这是一个很多工程师在真实项目里都会漏掉的点：写了异步逻辑，但没写失败兜底。
灰度发布方案
MiniMax M3 的文档中包含了渐进式灰度切流的部署策略——先小流量验证库存扣减一致性，再逐步放大。这个维度在 Kimi 和 Qwen 的文档中完全没有出现。GLM 5.1 虽然提到了“运维方案”，但更多是监控和日志层面，没有涉及发布策略。
DeepSeek V4 Pro 在这一环节的 80 分是全场最低，裁判评语是“缺少监控/限流具体实现细节”。有意思的是，这与它在任务 A 中展现的“架构抽象能力强但落地细节弱”的特征高度一致。
表 2：任务 B 各环节得分
04
MiniMax 爆冷夺冠
到此为止，已经可以算出综合排名。
令我们意外的是，MiniMax M3 以 85.3 的综合得分爆冷夺冠，其在 Bug 诊断与修复环节的表现尤为突出（89.7 分），而DeepSeek V4 Pro 虽然综合得分排名第四（78.6 分），但凭借最低的 API 定价，性价比指标（CPP {随机新闻正文}.20）全场最优，是预算敏感型团队的首选。
表 3：综合排名
在此前的两项测试任务中，五款模型表现出了迥异的特性。MiniMax M3 的 Task B 得分（89.7）全场最高，Bug 诊断和修复都堪称工业级。如果比作工程师的话，它应该是团队里那个在 Code Review 时一眼看出代码里竞态条件的人，也是那个在故障排查时最快定位根因的人。
但它不是那种能从零搭建完整系统的人，至少不是做得最好的那个。Task A 的 81.0 虽然也是并列第一，但这个分数本身就意味着"还有 19 分的提升空间"。写代码对它来说不是舒适区，找 Bug 才是。
Kimi K2.6 的表现同样亮眼，所有子项得分都在 70-90 分之间，这是一份没有明显短板，还能够一够单项最高的成绩。它的文档和运维方案被 Opus 4.7 反复称赞为“最出彩”、“最详实可落地”，其中在修复实现环节引入配置中心和结构化日志的做法，堪称这次比赛中工程实践可维护性的标杆。
不过之前没有提到的一处隐忧是，Kimi K2.6 在任务 A 的核心代码实现中遗漏了 Redis 与 DB 的最终一致性补偿。在秒杀场景下，这可能是个致命的错误。这种画像有点像是一个做事很规范的工程师，但偶尔也会在大局观上失焦。
Qwen 3.7 Max 的表现，用一个词形容就是"稳"。Task A 77.5，Task B 87.0，综合 82.2，排名第三。我们复盘成绩的时候发现，它在任何环节都没有拿过第一名，但也没有跌出过前三。不惊艳，但绝不会出大错，这就是你在任何项目上都可以放心用的人。
对于 DeepSeek V4 Pro，则有不小的争议，长处和短板都相当明显。综合得分 78.6，排名第四的背后，是几乎溢出的架构设计能力和火候欠缺的工程落地表现。前一脚能在需求澄清与架构设计环节拿到 85 分，后一步就在核心代码实现上跌到 65。更极端的是，它在 Bug 诊断环节以 90 分并列第一。这说明它不是不懂，而是在从“想”到“做”的转化过程中出了问题。
GLM 5.1 的特性也很鲜明。虽然在两项任务中都是最后一名，但它在修复实现的可读性维度上拿到了 5 分，在架构优化环节也拿到了 90 分。这说明当给定明确方向时，它就能给出结构清晰、覆盖面广的方案。但在没有锚点的创造性任务中，它容易被其他模型拉开差距。这是最适合最为辅助性编程工具的选手，人类工程师的主导和方向支持下，就会发挥出最强的性能。
05
性价比对决：谁是开发者的最优解？
数据截至 2026 年 6 月 3 日，各模型国际官网标价：
表 4：各模型官网最新 API 定价对比
这份价格表里有几个值得注意的点。DeepSeek V4 Pro 在 5 月 31 日之后，原本的 75% off 折扣价已成为正式官方价，使其成为五家中单价最低的模型，输出价格甚至不到 Kimi 的四分之一。MiniMax M3 采用阶梯定价，目前官网正在进行限时 5 折活动，折扣后价格甚至低于 DeepSeek。Qwen 3.7 Max 是五家中最贵的，约为 DeepSeek 的 3-4 倍。
光比能力不分价格，是耍流氓。假设你是一个中小团队的 Tech Lead，每天跑一个中度 Agent workload（日耗 100 万 Input Token + 10 万 Output Token），那么按上面这份各模型官网最新标价，一个月的账单如下：
表 5：月度成本与性价比对比
可以看到几个惊人的数字。DeepSeek V4 Pro 的 CPP（成本性价比）为 {随机新闻正文}.20，意味着花 20 美分就能买到 1 分的能力。相比之下，Qwen 3.7 Max 买同样的 1 分能力需要 {随机新闻正文}.59，贵了整整 3 倍。用 Qwen 一个月的预算（.75），可以跑三个月 DeepSeek 还剩 .77。
MiniMax M3 的限时 5 折价使其月度成本仅为 .60，CPP 仅 {随机新闻正文}.15，甚至比 DeepSeek 还便宜。但需要注意这是限时折扣价，标准价 .20 的 CPP 为 {随机新闻正文}.30，仍优于 Kimi 和 Qwen。
如果你是对预算极度敏感的个人开发者或初创公司，DeepSeek V4 Pro 就是最经济的选择。当然对于追求折扣红利的短期项目而言， MiniMax M3 的五折价也是一个方案。而且综合实力最强、Bug 诊断最佳的成绩，让这款模型在标准价之下也相当有竞争力。
如果想作为团队主力长期使用，则可以考虑 Kimi K2.6。虽然综合得分第二，但也胜在没有明显短板、规范性强上。而对于为生态集成买单的阿里云用户来说，Qwen 3.7 Max 的表现也同样可靠。
如果把这次评测比喻成一场招聘面试，五家模型各自拿到了不同的 offer。
MiniMax M3 是高级工程师，Bug 排查能力全场最强，但入职后需要配一个架构师帮它把关从零建系统的活儿。Kimi K2.6 拿到了技术骨干的 offer，没有明显短板，规范性强，是任何团队都可以放心托付的主力。Qwen 3.7 Max 更像资深工程师，稳健可靠，但工资要求最高。DeepSeek V4 Pro 作为性价比之王当之无愧，花最少的钱，就能买到中上的能力，而 GLM 5.1 则还在试用期。
复盘整场比赛，MiniMax M3 的夺冠也让我们重新思考 Coding 能力的竞争。或许这条赛道上真正的比拼，早就从写出更优雅的算法，进化到了谁能理解更复杂的工程约束，甚至拥有或是模仿一种玄而又玄的工程师嗅觉。毕竟在真实业务场景中，一个能精准定位竞态条件、给出工业级修复方案的模型，远比一个会写快速排序的模型有价值。
在这场国产大模型的混战中，有人比拼能力上限，有人重新定义性价比的底线。而开发者的幸福在于，你终于可以不再被价格绑架，根据团队规模和项目需求，选一个真正适合你的“赛博同事”了。
（本文作者长期追踪模型及 AI 产品动态，欢迎添加微信 LIFACAI_888 互通有无。）