两周多前我测完 Kimi K3，结论是国产模型摸进了第一梯队。这周 Qwen 3.8 Max 发布，说实话，我的第一反应是没兴趣。
我已经很久没正眼看过 Qwen 了。印象里它的编程能力不太行，这个印象停留了挺久，久到看到发布消息也没什么波澜。
但 Qoder 正好在送 800 次免费调用。
我想了个省事又公平的办法，把 K3 那次测过的三个场景，原样拿给 Qwen 3.8 Max 再做一遍。
太强了，Kimi K3：我愿意称之为Kable
先把答案放这。三个场景打平，有一个地方它做得比 K3 还好。
Qwen 3.8 Max 是什么
先说硬信息。
2.4 万亿参数、950 亿激活的 MoE，100 万 token 上下文，API 价格是每百万 token 输入 2 美元、输出 6 美元，输出价大概是 Claude Fable 5 的八分之一。
官方还说下周开源权重，这是 Qwen Max 级别的模型第一次开放权重，同批还有一个 27B 的小模型也开源。
官方给自己的定位是“仅次于 Fable 5”。
这里提醒一句。它对比表里的 Anthropic 模型是 Opus 4.8 和 Fable 5，7 月 24 日发布的 Opus 5 不在里面。
所以这张表看看就好，我不逐条念了，直接看实测。
我现在更关心的是落到 Qoder 里怎么用。
模型选择器里 Qwen 3.8 Max 是 0.5x Credit，错峰时段（晚 10 点到早 8 点）再打 5 折，上下文 200K / 400K / 1M 三档可选。
调用次数方面，新用户注册能领 800 次，登录后还有赠送的 300 次，一共 1100 次；订阅之后还能再领 2000 次。
想复现我这篇的测试，成本是零。
这次怎么测的
三个场景和 K3 那次完全一样，从零做一个视频工作台、一个实时选座票务系统、一个物理驾驶小游戏。
有几个口径要先说清楚，不然后面的结论没法看。
第一，这次每个场景我只给了一轮需求，一次实现到位。提示词不是 K3 那次的原话。K3 当时是来回加了好几轮需求，会员、候补这些功能都是后来补的，这次我把那些多轮需求整理成了一份完整版提示词，验收标准写得更细。这一点对 Qwen 有利，它拿到的考卷更清楚，打平的结论要打这个折扣。
第二，这是 Qwen 加 Qoder 对 K3 加 Kimi Code 的对比，两边都是模型配自家框架的工作流，不是裸模型横评。我现在本来就更关心这个口径，裸模型分数离真实使用太远了。
第三，这次没有真实项目案例。K3 那篇里有私有仓库 MR 审查、老系统架构审查和一条线上告警，这次都没有。800 次调用刚好用完，手头也暂时没有合适的需求。能不能进真实工作流，这篇只能说一半。
耗时上，视频工作台大概 30 分钟，订票系统 50 分钟左右，游戏 30 分钟左右。
Qoder 开的 YOLO 模式，过程中我没帮它装依赖、改代码、处理环境。项目交付后，所有功能我都亲自上手操作了一遍。
场景一：视频工作台
需求是做一个对标剪映工作方式的纯前端剪辑工具，素材库、节目预览、多轨时间轴、片段检查器、撤销重做、本地持久化。
功能层面和 K3 版打平，该有的都有。界面比 K3 版克制，深色编辑器配色，信息层级清楚，AI 生成的味道明显更轻。还多出一些专业功能，轨道锁定和静音、片段边缘修剪、左右方向键逐帧定位、窄屏只读审片模式。
有一个设计差异值得说。
调整片段速度时，K3 版是轨道上的片段长度跟着速度变；Qwen 版是片长固定，按源素材长度夹取速度上限。两种语义都讲得通，但第一次用 Qwen 版会困惑一下。
工程上它交了 28 个单元测试，全部通过，TypeScript 类型检查零错误。
场景二：实时选座票务系统
这个需求最重。
消费者端选座购票，运营后台管理场馆和演出，中间是锁座、支付、出票、退款、候补、核销的完整状态流转。
先说架构，它是真后端。
PostgreSQL 存业务数据，Redis 传实时事件，座位状态用 SSE 推到前端，外加一个 Worker 处理锁座过期和候补派位，Docker Compose 一键拉起。
我支付、退款之后刷新页面、开全新浏览器会话重新登录，数据全部一致。
K3 版的功能基线它一项不少，工程细节甚至更讲究。
锁座是原子操作，任一座位不可售就整批失败；支付接口带幂等键，重复点击不会产生重复订单；重复核销返回 409；候补排队有 24 小时防饿死机制，普通用户等满一天就升级优先层，不再被后来的会员插队。
后台九个模块我全部点了一遍，创建场馆、创建演出、授予会员、核销门票都实际做了，订单、候补、审计日志、通知记录的数据都对得上。整个过程浏览器控制台零报错。
场景三：物理驾驶小游戏
需求是照 Drive Mad 的玩法做原创游戏，只用前进和后退控制车辆越障，五个主题关卡，一批即死机制。
K3 那次的弱点我很清楚。五关彼此太像，难度偏低，而且我到现在都不确定它底层是不是用了成熟物理引擎。
Qwen 版把这两个弱点都补上了。它明确用了 planck.js（Box2D 系的物理引擎），而且不是装装样子，悬挂弹簧、碰撞冲量判定、低重力和冰面摩擦的逐关调参都是真的。五个关卡主题和 K3 版相同，但每关的机制密度明显更高。工地有关卡内推箱垫路，冰原有相位旋转杆，火山有落石区加连续断桥。
即死机制我逐个试了一遍。托底、被旋转杆扫中、被落石砸中、掉出关卡边界、碰到熔岩危险面，全部真实触发。难度也比 K3 版高，冰原和火山要卡时机，我自己玩都死了好几次。
它同样带了一套测试，23 个全部通过，其中还包括五个关卡的无头仿真通关，用脚本模拟输入，自动把车开到终点。
不过 K3 也不是全输。K3 版的画面色彩明显更丰富，结算卡做得更俏皮。Qwen 版的美术偏朴素，赢在手感和机制，不赢在卖相。
最让我意外的一点
三个场景做下来，耗时都比 K3 长一点。我一开始以为是模型慢，看了过程记录才发现不是。
它每写完一个场景，会自己打开浏览器做验收，而且做得相当较真。
做视频工作台时，它发现预览在后台标签页里会因为 rAF 节流卡住，主动把播放循环改成了 rAF 加 setInterval 双驱动；发现 Delete 键删除片段没生效，自己派发键盘事件排查掉了。
做订票系统时，它先自己检查环境，发现 Docker 没启动就自己拉起来，跑完 25 个测试又自己进浏览器走完整流程。
换句话说，它慢的那部分时间，花在了自己给自己验收上。
这个东西跑分表里完全看不到，但它恰恰是后端工程师判断敢不敢把活交给它的依据。
三个项目全部自带测试、控制台零报错、幂等和审计这些细节都想到了。能做到这一步，已经不只是能跑通 Demo，它知道交付物长什么样。
最后
我对 Qwen 的偏见这次算是被打掉了。三个和 K3 完全相同的场景，功能打平，工程严谨度上还略强一点。
当然，边界再说一次。它拿到的提示词更完整，占了便宜；这次也没有真实项目对照，复杂遗留系统里它什么样，我还不知道。
但即便打完这些折扣，有些话我也想直接说。
在这之前，Qwen 在我心里的位置就是“编程不行，不用看”。
这个印象放了很久，久到我自己都忘了它是哪一次形成的。
这次三个场景跑完，我不得不承认一件事，我对它的判断一直停留在老黄历上，而它已经悄悄换了位置。
写这个公众号以来，类似的经历今年已经是第三次了，GLM 5.2 一次，K3 一次，这次是 Qwen。
一次是意外，三次就不是了。国产模型这一次，是真的追上来了。
这两天我也刷到一些完全相反的评价，有人说它是“PPT 模型”，有人就扔下一句“拉完了”。
我不知道他们是不是真的实测过，也不排除是我这三个场景恰好对它友好。反正我自己的初步感受，还行。
如果你也好奇它到底什么水平，我的建议很简单，别信跑分，别全信我这篇，也别信一句没头没尾的评语。
去下载一个 Qoder，新用户能领 1100 次免费调用，拿你手头一个真实场景丢给它跑一次。你自己的任务，比任何评测都更能替你下判断。
如果这篇对你有帮助，欢迎关注「子昕AI编程」，也顺手点个赞、在看，或者转发给同样在折腾 AI 编程工具的朋友。
