两周多前实测 Kimi K3 时，结论是国产模型已经摸进了第一梯队。

本周 Qwen 3.8 Max 发布，我的第一反应是没兴趣——印象里它的编程能力不太行。

但 Qoder 正好在送 800 次免费调用，于是我用 K3 那次测过的三个场景原样再跑了一遍，结果出乎意料。

三个场景打平，有一个地方 Qwen 3.8 Max 还做得更好。

Qwen 3.8 Max 是什么

2.4 万亿参数、950 亿激活的 MoE 架构，100 万 token 上下文。API 价格每百万 token 输入 2 美元、输出 6 美元，输出价约为 Claude Fable 5 的八分之一。官方定位"仅次于 Fable 5"，下周开源权重——这是 Qwen Max 级别模型首次开放权重。

在 Qoder 中，Qwen 3.8 Max 是 0.5x Credit，错峰时段（晚 10 点到早 8 点）再打 5 折，上下文 200K / 400K / 1M 三档可选。新用户注册可领 1100 次免费调用。

测试方案

三个场景和 K3 那次完全相同：从零做一个视频工作台、一个实时选座票务系统、一个物理驾驶小游戏。提示词整理为完整版一次性给出，验收标准更细。两边都是"模型 + 自家框架"的工作流对比（Qwen + Qoder vs K3 + Kimi Code），不是裸模型横评。全程 YOLO 模式，未人工干预。

场景一：视频工作台

对标剪映的纯前端剪辑工具，需要素材库、节目预览、多轨时间轴、片段检查器、撤销重做、本地持久化。功能层面和 K3 版打平，但界面更克制——深色编辑器配色，AI 生成味道更轻。还多出轨道锁定和静音、片段边缘修剪、左右方向键逐帧定位、窄屏只读审片模式等专业功能。

工程上提交了 28 个单元测试全部通过，TypeScript 类型检查零错误。

场景二：实时选座票务系统

这是最重的需求：消费者端选座购票，运营后台管理场馆和演出，中间是锁座、支付、出票、退款、候补、核销的完整状态流转。架构是真后端——PostgreSQL 存数据，Redis 传实时事件，SSE 推座位状态，Worker 处理锁座过期和候补派位，Docker Compose 一键拉起。

功能基线一项不少，工程细节更讲究：锁座原子操作、支付接口带幂等键、重复核销返回 409、候补排队有 24 小时防饿死机制。后台九个模块全部实测通过，浏览器控制台零报错。

场景三：物理驾驶小游戏

对照 Drive Mad 玩法做原创游戏，前进/后退控制车辆越障，五个主题关卡。Qwen 版明确使用了 planck.js（Box2D 系物理引擎），悬挂弹簧、碰撞冲量、低重力和冰面摩擦的逐关调参都是真的。五关机制密度明显更高：工地有关卡内推箱垫路，冰原有相位旋转杆，火山有落石区加连续断桥。

即死机制逐个验证全部真实触发。难度比 K3 版高，冰原和火山要卡时机。项目自带 23 个测试全部通过，包含五个关卡的无头仿真通关。

最让我意外的一点

三个场景耗时都比 K3 长一点，但不是模型慢——而是它每写完一个场景会自己打开浏览器做验收。做视频工作台时发现预览在后台标签页里 rAF 节流卡住，主动改成 rAF + setInterval 双驱动；做订票系统时先检查环境、拉 Docker、跑 25 个测试再进浏览器走流程。

慢的那部分时间，花在了自己给自己验收上。这个东西跑分表里看不到，但它恰恰是工程师判断敢不敢把活交给它的依据。

最后

对 Qwen 的偏见这次算是被打掉了。三个相同场景，功能打平，工程严谨度上还略强。当然它拿到的提示词更完整、没有真实项目对照，结论需要打折扣。但即便打完折扣，Qwen 已经悄悄换了位置——国产模型这一次，是真的追上来了。

如果你也好奇它到底什么水平，建议去下载 Qoder，新用户可领 1100 次免费调用，拿你手头一个真实场景丢给它跑一次。你自己的任务，比任何评测都更能替你下判断。