本文深入剖析Qwen3.8-Max与Qwen3.8-Flash在定价倍率、真实成本、架构差异、基准测试口径及实际编程场景中的能力剖面。指出平台0.5×与0.15×倍率掩盖了13–15倍的官方价差，实为旗舰补贴、轻量溢价；Max是2.4T稀疏激活旗舰，强于长程自主与指令遵循，但幻觉控制弱（Omniscience 3.4）；Flash基于Qwen4预览架构，轻量高效但上下文受限（原生256K），自托管可行性高。选型需规避六大误区，依任务类型（构建/迁移/补测/并发修复）匹配模型，并落实prompt工程与缓存策略。
Qwen3.8-Max 0.5× 对 Flash 0.15×，倍率只差 3.33 倍，官方价差却是 15 倍——这张表在补贴旗舰、溢价轻量，多数人恰好选反了
引言
选择框里只有两行：
Qwen3.8-Max 1.0× 0.5×
Qwen3.8-Flash 1.0× 0.15×
两行的 1.0× 都被划掉了，剩下的 0.5 和 0.15 是现在真正生效的价格。
多数人看到这两行的第一反应是"差的真多"——3.33 倍，Max 贵三倍多，那就先拿 Flash 干活，实在不行再换。
这个判断在别的模型表上通常是对的。但在这一格上，它恰好反了。
因为 0.5 和 0.15 不是成本的比例，是平台愿意让你承担的比例。而阿里云自己公布的价目表上，这两个模型之间的真实价差是 13 到 15 倍——不是 3.33 倍。
也就是说：平台用 3.33 倍的倍率差，去覆盖 15 倍的真实成本差。中间那 11 倍多的缺口，在 Max 身上是补贴，在 Flash 身上是溢价。
换算成一句话：在这张表上，你花 0.5 的额度买 Max，拿到的是官方标价 ¥12/百万的输入能力；花 0.15 的额度买 Flash，拿到的是官方标价 ¥0.8/百万的输入能力。前者的"每单位倍率买到的官方价值"是后者的 4.5 倍。
这不是我随手算的，下面会用三个地区、四个口径、两组官方价目逐一验算，并把推导过程写到你能自己复核。
但"应该选 Max"这句话只对了一半。这篇文章真正要回答的是三件事：
- 倍率倒挂是真的，但为什么省钱的效果经常兑现不了？——因为 Max 会把你省下的钱，花在反复读文件、反复验证、反复自我检查上。有独立测试记录：一个扑克模拟任务核心功能 20 分钟就写完了，之后又花了将近一小时调整角色行为，最后因额度耗尽中断。
- Max 有一个很少被提到的硬短板，比"慢"严重得多——幻觉控制。Artificial Analysis 的 Omniscience 分数是 3.4，而它的对手 Claude Opus 5 是 37.1。这个模型知道很多，但它不知道自己不知道什么，这在编程里是致命的。
- Flash 的 0.15× 也不代表"最便宜的 Qwen"。 上一代 qwen3.7-flash 在 32K 以内的输入价是 0.2 元/百万，是新版 0.8 元的四分之一。新一代换了架构、能力上去了，但短上下文场景反而更贵——这是"新版一定更划算"这条经验第一次在本系列里失效。
先把这张表读对，再谈能力。
一、先看清那一格：两个被划掉的 1.0× 和一个不该被忽略的比值
1.1 把四个价格摆在一起，倍率就开始说不通了
先说清两件事，避免后面越算越乱。
第一，0.5× 和 0.15× 是什么。 这是平台侧的消耗倍率——你调用一次，按某个基准折算成多少额度。它不是"打几折"，也不是官方定价，它是平台自己的一套计价尺子。
第二，官方真实价格是多少。 阿里云百炼（华北2·北京）的刊例价，两个模型都不分档（这是 Qwen3.8 系列的一个特点，后面第四节会讲它和 MiniMax-M3 的差别）：
| 计费项（元/百万 token） | Qwen3.8-Max | Qwen3.8-Flash | 倍数 |
|---|---|---|---|
| 输入 | 12 | 0.8 | 15.0× |
| 输出 | 36 | 2.7 | 13.3× |
| 缓存命中 | 1.5 | 0.1 | 15.0× |
| Batch 输入（5 折） | 6 | 0.4 | 15.0× |
| Batch 输出（5 折） | 18 | 1.35 | 13.3× |
| 显式缓存创建 | 15 | 1.25 | 12.0× |
| 显式缓存命中 | 1 | 0.1 | 10.0× |
国际站（新加坡）价：
| 计费项（美元/百万 token） | Qwen3.8-Max | Qwen3.8-Flash | 倍数 |
|---|---|---|---|
| 输入 | 2.00 | 0.15 | 13.3× |
| 输出 | 6.00 | 0.47 | 12.8× |
| 缓存读 | 0.25 | 0.016 | 15.6× |
四个口径算下来，真实价差落在 12.8 倍到 15.6 倍这个区间。
而平台给的倍率比是 0.5 ÷ 0.15 = 3.33 倍。
这个比值的差距不需要知道 1.0× 具体等于多少钱就能证明——因为比值把基准消掉了。0.5/0.15 是 3.33，12/0.8 是 15，36/2.7 是 13.3，无论拿哪个口径去比，3.33 都对不上。
结论只有一个：平台的倍率不反映这两个模型的相对成本。
1.2 要让倍率如实反映成本，Flash 该标 0.033× 而不是 0.15×
把这个结论算成具体数字会更刺眼。
如果平台的目标是"倍率如实反映成本"，那么以 Max 的 0.5× 为锚：
Flash 应有的倍率 = 0.5 × (0.8 / 12) = 0.033×
如果以 Flash 的 0.15× 为锚：
Max 应有的倍率 = 0.15 × (12 / 0.8) = 2.25×
实际标的是 0.5× 和 0.15×。所以：
- 相对 Flash 这个锚，Max 被补贴了 4.5 倍（2.25 ÷ 0.5）
- 相对 Max 这个锚，Flash 被溢价了 4.5 倍（0.15 ÷ 0.0333）
两个方向算出来的补贴/溢价倍数一致，都是 4.5 倍左右。这不是巧合，是同一个比值的两种读法。
换个更直观的说法：用 1 份额度，买 Max 能换回 24 元的官方输入价值（12÷0.5），买 Flash 只能换回 5.33 元（0.8÷0.15）。差 4.5 倍。
输出侧同理：Max 是 36÷0.5 = 72，Flash 是 2.7÷0.15 = 18，差 4.0 倍。
1.3 这不是平台算错，是补贴方向的问题
为什么会出现这种倒挂？最合理的解释是平台的计价基准不是官方原价。
平台要在几十个模型之间用一把尺子，最可能的做法是：给每个模型定一个"综合分档"，而不是照抄官方价。旗舰模型定一个上限（比如不加价，1.0×），中间档按能力折扣，轻量档统一压到一个地板价（0.15× 这个数在这张表里已经出现第二次了）。
回想这个系列的第五篇：MiniMax-M3 折后也是 0.15×。
同一个数字，含义完全相反：
- MiniMax-M3 的 0.15×，相对它自己的官方折扣（2:1）是"平台政策价"——平台比官方更狠。
- Qwen3.8-Flash 的 0.15×，相对它自己 15 倍的官方成本差是"溢价"——平台比官方宽松得多。
这说明 0.15× 是一个地板值，不是按成本算出来的。平台把所有轻量档都压到这个位置，以免用户在小模型上花太多；而旗舰档反而被压在 0.5×，以免用户不敢碰。
补贴方向是"往旗舰倾斜"。
对用户的含义非常直接：这张表在鼓励你用旗舰。如果你按"倍率低就是便宜"的直觉选了 Flash，你放弃的是平台给你的最大一笔补贴。
1.4 顺带一个坑：Qwen3.8 不是两个模型，是六个
名字带 Qwen3.8 的，阿里一共放了六个，能力、许可、能不能自托管全不一样：
| 模型 | 是什么 | 开源权重 | 发布 |
|---|---|---|---|
| Qwen3.8-Max | 旗舰，2.4T 总参 / 95B 激活 | 是，作为 Qwen3.8-2.4T-A95B | 2026-08-03（API） |
| Qwen3.8-27B | 稠密视觉语言模型，270 亿 | 是，Apache 2.0 | 2026-08-14 |
| Qwen3.8-Flash-Next | 125B / 6B 激活 MoE | 是，Qwen Community 1.0 | 2026-08-26 |
| qwen3.8-flash | Flash-Next 的托管版 | 否，仅 API | 2026-08-26 |
| Qwen3.8-Omni-Flash | 文/图/音/视全模态 | 否，仅 API | 2026-09-18 |
| Qwen3.8-LiveTranslate | 实时同传 | 否，仅 API | 2026-09-18 |
两个容易混的点：
一是 Qwen3.8 和 Qwen3-8B 不是一个东西。 后者是 Qwen3 时代的老模型，只差一个点和一条横线，名字撞得很厉害。粘 model id 之前多看一眼。
二是截图里的 qwen3.8-flash 是托管版，不是 Qwen3.8-Flash-Next。 两者同源，但托管版多了默认 1M 上下文、内置工具（代码解释器、网页抓取、web_fetch 都免费）、非思考模式。下载 Flash-Next 自己跑，你拿到的是原生 262,144 上下文，工具得自己带。这个差异在第四节会直接决定"能不能自托管"。
二、把底牌摊开：两个型号的真实参数
2.1 Qwen3.8-Max：2.4 万亿总参、950 亿激活的"长跑型旗舰"
| 参数 | 值 |
|---|---|
| 总参数 | 2.4 万亿（2.4T） |
| 每 token 激活 | 约 950 亿（95B），占比约 4% |
| 架构世代 | Qwen 3.5 世代（Gated DeltaNet + 门控注意力） |
| 专家数 | 512（其中 10 个路由专家 + 1 个共享专家） |
| 上下文 | 1M（托管版默认）；最大输出 128K |
| 最大输入 | 949K 量级（受 1M 上下文与输出预算共同约束） |
| 模态 | 文本 + 图片 + 视频输入（原生视觉语言） |
| 接口协议 | OpenAI 兼容 / Anthropic 兼容 / 原生 DashScope，五个区域 |
| 开源权重 | Qwen3.8-2.4T-A95B，自定义许可 |
三个值得单独说的点。
第一，512 个专家里只有 10 个路由 + 1 个共享。 这个稀疏度在 2.4T 量级上意味着：单个 token 只走极少数专家路径，但总容量大得能装下很多互不干扰的知识。这是"参数多但不一定慢"的结构基础——只是"不一定慢"不等于"不慢"，第五节会给出实测速度。
第二，托管版和开源权重版不是同一个产品。 这是很多人没意识到的事：
- 开源版：纯文本、总是先思考再回答（always thinks before it answers）
- 托管版：加了视觉输入、非思考模式、默认 1M 上下文
所以"阿里开源了 2.4T 旗舰"这句话，落到你手上是一个能力更窄、且强制思考的版本。想让它不思考？做不到。
第三，它是第一个开放权重的 Max 级模型。 这个信号本身有意义——但对多数团队来说，"能下载"和"能跑起来"之间隔着数据中心。2.4T 不是工作站能装的，这一节最后会算清楚。
2.2 Qwen3.8-Flash：125B / 6B，但架构是 Qwen4 的预览版
| 参数 | 值 |
|---|---|
| 总参数 | 125B MoE（另有 51B 的 N-gram 嵌入表） |
| 每 token 激活 | 约 6B（不到 5%） |
| 架构世代 | Qwen4 预览版：Qwen Sparse Attention（QSA）+ Gated DeltaNet + 门控残差 + Muon 训练 |
| 上下文 | 开源权重原生 262,144；托管版默认 1M |
| 最大输入（托管） | 991,808（思考模式 983,616） |
| 最大输出 | 131,072 |
| 最大思维链 | 262,144 |
| TPM | 5M |
| 模态 | 文本 + 图片 + 视频输入 |
| 开源权重 | Qwen3.8-Flash-Next，Qwen Community 1.0，可 vLLM / SGLang / Transformers / TokenSpeed |
| 接口协议 | OpenAI 兼容 / Anthropic 兼容（可接 Claude Code、Codex） |
这里最有信息量的是架构那一行。
Max 用的是 Qwen 3.5 世代的发动机，Flash 用的是 Qwen4 的预览发动机。
也就是说，这个"轻量档"不是把旗舰砍小，而是换了一台下一代的发动机先试水。Qwen Sparse Attention 是新的稀疏注意力设计，Gated DeltaNet 负责长序列上的线性复杂度，Muon 是训练侧优化器。官方发布文里提到，它的训练成本大约是 Qwen3.7-Plus 的九分之一。
这个背景解释了后面的一些反常现象：为什么一个 125B 的模型在 LiveCodeBench v6 上能干到 91.9（比 27B 的 90.3 和 Qwen3.7-Plus 的 89.6 都高），为什么它在 AA 智能指数上（40）反超了更大的 27B（34）。
但也解释了一个陷阱：架构新 ≠ 全面强。它在最难的单个调用深度上仍然有天花板，这一点和所有 Flash 档一样。
2.3 一个常被忽略的差异：原生 256K 还是托管 1M
这是选型时最容易踩的坑。
两个模型的"1M 上下文"来源完全不同：
- Max：托管版默认 1M，开源权重版的开源说明里也提到 1M（示例上下文封顶有约束）
- Flash：开源权重原生只有 262,144，1M 是托管版额外加的
所以：
| 你的使用方式 | 能拿到的上下文 |
|---|---|
| 平台上调 qwen3.8-flash | 1M |
| 本地跑 Flash-Next | 262K（可扩到约 1M，但要自己解决） |
| 平台上调 qwen3.8-max | 1M |
| 本地跑 Qwen3.8-2.4T-A95B | 看部署配置，官方示例里常封顶在 262,144 |
如果你打算"先在平台上调通，再自托管省钱"，Flash 这条路的上下分会直接砍掉四分之三。 这个落差必须在方案里写清楚，否则上线当天才发现装不下代码仓库。
2.4 开源权重版和 API 版的差异，值得单独一张表
| 维度 | qwen3.8-max（托管） | Qwen3.8-2.4T-A95B（开源） |
|---|---|---|
| 模态 | 文 + 图 + 视频 | 纯文本 |
| 思考模式 | 可开可关，三档 effort | 强制思考，不能关 |
| 上下文 | 默认 1M | 视部署配置，示例常封顶 262,144 |
| 许可 | 商业 API | 自定义（Qwen3.8-Max License） |
| 维度 | qwen3.8-flash（托管） | Qwen3.8-Flash-Next（开源） |
|---|---|---|
| 上下文 | 默认 1M | 原生 262,144 |
| 内置工具 | 代码解释器/网页抓取/web_fetch 免费 | 无，自己带 |
| 许可 | 商业 API | Qwen Community 1.0 |
| 硬件门槛 | 无需 | 普通 GPU 可跑（vLLM/SGLang/TF/TokenSpeed） |
这张表最重要的一行是最后一行。 Max 的"开源"是姿态，Flash-Next 的"开源"是可以落地的方案——125B/6B 激活这个体量，在合理量化下是几台机器能装下的量级。这是本系列所有模型里，自托管可行性最高的一档。
2.5 两个型号的真实差异，一张表
| 维度 | Qwen3.8-Max | Qwen3.8-Flash | 差异要点 |
|---|---|---|---|
| 总参 / 激活 | 2.4T / 95B | 125B / 6B | 激活差 15.8 倍 |
| 架构世代 | Qwen 3.5 | Qwen4 预览（QSA+GDN） | Flash 的发动机更新 |
| 上下文（托管） | 1M | 1M | 打平 |
| 上下文（开源） | 视部署 | 262K | Flash 明确 |
| 模态 | 文图视 | 文图视 | 打平 |
| 思考控制 | 三档 effort，可关 | 三档 effort，可关 | 打平 |
| 官方输入价 | ¥12 | ¥0.8 | 15× |
| 官方输出价 | ¥36 | ¥2.7 | 13.3× |
| 平台倍率 | 0.5× | 0.15× | 仅 3.33× |
| 自托管可行 | 数据中心级 | 普通 GPU 可跑 | Flash 唯一强项 |
| 独立 AA 智能指数 | 58 | 40（测的是开源 Flash-Next） | 差 18 分 |
最后一行打了一颗星，因为这两个分数的测量对象不一样——Max 测的是托管 API，Flash 测的是开源权重。这个坑在第三节第 3 条会讲清楚。
三、读基准的五条纪律
这个系列每篇都有这一节，因为榜单误读是编程选型里最贵的错误。Qwen3.8 这一代坑特别多，所以是五条。
3.1 纪律一：官方 Terminal-Bench 29.0 用的是自家框架 + 5 小时超时
Qwen3.8-Max 的官方发布文里，编码类核心成绩是这样的（对比 Claude Opus 5）：
| 基准 | Qwen3.8-Max-0902 | Claude Opus 5 | 谁赢 |
|---|---|---|---|
| TerminalBench 3.0 | 29.0 | 42.7 | Opus 5 |
| DeepSWE 1.1 | 69.3 | 73.6 | Opus 5 |
| NL2Repo-Bench | 64.9 | 72.3 | Opus 5 |
| ProgramBench（Almost Solved） | 28.0 | 41.5 | Opus 5 |
| SWE-Marathon | 44.8 | 50.0 | Opus 5 |
| MLS-Bench-Lite | 50.1 | 49.8 | Qwen |
| SWE-Atlas QnA | 66.3 | 63.2 | Qwen |
| QwenSWEBench V2 | 70.0 | 68.0 | Qwen |
注意这里有一个关键的口径说明：官方 TerminalBench 的分数是在自家测试框架下、跑 5 小时超时得到的。第三方用标准框架重测，分数更低。
这句话的意思是：29.0 已经是"给足了时间和合适的脚手架"之后的成绩。换到通用 harness 上，这个数字还会往下掉。
同一张表的另一处也有类似现象。初版（0803）的 Terminal Bench 2.1 报了 86.6，看起来和 Claude Opus 4.8 的 84.6 打平——但这是 2.1 版本，0902 用的 3.0 版本只有 29.0。两个基准版本难度完全不同，不能放在一起看。
3.2 纪律二：Snorkel 的 14.7% 和 4.9%，配套的数字是 77.7% 和 89.1%
第三方评测机构 Snorkel 用自己的一套专业基准测了 Qwen3.8-Max，结果是这样的：
| 基准 | 分数 | 排名 |
|---|---|---|
| Agentic Coding 2.0 | 14.7% Pass@1 | 13 / 14 |
| SWE-bench CLI | 4.9% Pass@1 | 9 / 14 |
| Terminal-Bench 4.0 | 27% ±3.8 | 13 / 23 |
| SnorkelLegal | 25.6% | 11 / 14 |
| SnorkelUnderwrite 2.0 | 20.0% | 10 / 14 |
| SnorkelFinance 2.0 | 14.1% | 8 / 14 |
| SnorkelManufacturing | 8.3% | 11 / 14 |
| SnorkelRevOps | 6.5% | 13 / 14 |
4.9% 和官方 69.3% 放一起，谁都会觉得中间有一个是假的。但关键在 Snorkel 自己给出的一句话：
The primary coding constraint was sustaining execution long enough to finish.
Timeouts affected 77.7% of Agentic Coding trials and 89.1% of SWE-bench CLI trials.
也就是说：在 SWE-bench CLI 上，近九成的试验是超时结束的，不是答错结束的。
这就把两件事分开了：
- 模型的能力（会不会做）
- 模型能不能在给定时间内做完（做不做得完）
Snorkel 测出来的是后者，官方 TerminalBench 那 5 小时超时争取的也是后者。同一个模型，一个说 69%，一个说 4.9%，都在测同一件事的两面。
还有一个细节值得记：Snorkel 观察到它在细分领域的编码广度有限——安全、游戏、系统管理三类在 Agentic Coding 2.0 上都低于 8%。"全栈都能写"是个过于乐观的说法。
3.3 纪律三：AA 的 Flash 分数测的是开源权重，不是托管 SKU
Artificial Analysis 给出的几个数字，是这一节里最容易被误用的：
| 模型 | AA 智能指数 | AA 编程指数 | 中位输出速度 |
|---|---|---|---|
| Qwen3.8-Max | 58 | 71.8 | 约 37–48 tok/s（口径冲突） |
| Qwen3.8-Flash-Next（开源权重） | 40 | — | 51.6 tok/s |
| Qwen3.8-27B | 34 | 68.1 | 45.7 tok/s |
三个陷阱：
陷阱一：Flash 的 40 分不是托管 qwen3.8-flash 的分数。 AA 测的是开源 Qwen3.8-Flash-Next 这个 artefact。托管版多了 1M 默认上下文和内置工具，能力可能更高也可能因为约束变化而不同——没人测过托管 SKU。
陷阱二：这两个 index 的对比集不一样。 Flash 那条有 116 个模型，27B 那条有 141 个，评估日期也不同。只能当"相邻"读，不能当受控头对头。
陷阱三：速度的口径冲突。 AA 的中位输出速度有 37 tok/s 和 48 tok/s 两个流传值，来源不同、测试条件不同。我在文末的说明里两个都列了，你按 37–48 这个区间用，别引单一数字。
顺带一个反直觉的点：Flash-Next 51.6 tok/s 对 27B 的 45.7 tok/s，差距只有 13%。 所谓 “Flash” 不是延迟承诺，它省的是钱，不是时间。想靠换 Flash 提速的，收益远小于预期。
3.4 纪律四：Code Migration 24.0% 对 SWE-bench Verified 85.6%，这不是矛盾
这是本篇最容易被忽略、但对 Java 开发者最关键的一组数字。
在综合榜上，Qwen3.8-Max 的成绩很漂亮：
| 基准 | 分数 |
|---|---|
| SWE-bench Verified | 85.6% |
| LiveCodeBench | 87.8% |
| Terminal-Bench 2.1 | 86.6% |
| SWE-bench Pro | 67.7% |
| Qwen SWE-bench | 80.7% |
| DeepSWE 1.1 | 57.5% |
| OSWorld / OSWorld Verified | 86.1% |
| AIME 2025 | 99.4% |
| GPQA Diamond | 92.7% |
| IFBench | 82.8% |
| MRCR v2（256K, 8-needle） | 92.9% |
| Arena Code Elo | 1667 |
| Vibe Code Bench | 64.7% |
| Code Migration | 24.0% |
前十项都在 80 以上，Code Migration 是 24.0。
这个数字意味着什么？"会写代码"和"会把代码搬到另一个框架上"是两种能力，而后者这个模型做得并不好。
对照 Java 生态的现实：Spring Boot 2.x → 3.x（javax.* → jakarta.*）、JDK 8 → 21、MyBatis 迁 MyBatis-Plus、老 Struts 迁 Spring MVC。这些活儿的共同点是——你必须理解旧代码为什么这么写，而不只是知道新代码怎么写。它需要的是"读懂既有意图 + 等价重写"，不是"从零生成"。
24.0% 这个分数，直白地告诉你：别让它直接落迁移后的代码，让它出迁移方案和风险清单。
这条纪律和 3.1、3.2 是一条线：Qwen3.8-Max 的强项是"从零构建一个能跑的东西"，短板是"理解并改造一个已经存在的东西"。这个区分在本文第八节会给出具体操作方式。
3.5 纪律五：0803 和 0902 是两个不同的模型，别混着引
Qwen3.8-Max 有一个 0902 快照，编码能力提升幅度非常大：
| 基准 | 0803 初版 | 0902 快照 | 提升 |
|---|---|---|---|
| TerminalBench 3.0 | 11.3 | 29.0 | +157% |
| ProgramBench（Almost Solved） | 10.5 | 28.0 | +167% |
| DeepSWE 1.1 | 56.6 | 69.3 | +22% |
| NL2Repo-Bench | 55.9 | 64.9 | +16% |
| QwenSWEBench V2 | 55.1 | 70.0 | +27% |
| MLS-Bench-Lite | 41.0 | 50.1 | +22% |
| SWE-Marathon | 39.1 | 44.8 | +15% |
| SWE-Atlas QnA | 60.3 | 66.3 | +10% |
八项编码基准全部提升，两项翻倍以上，而定价没变。
所以你在网上看到的"Qwen3.8-Max TerminalBench 11.3，不行"和"Qwen3.8-Max TerminalBench 29.0，还行"，说的可能是两个不同快照。引用时必须带上版本号。
好消息是这属于"免费升级"——如果你已经在用 Max，0902 是白给的提升。
四、能力剖面：Max 的四强四弱，Flash 的四强三弱
榜单读完之后，把能力落成写代码时能感知的形状。
4.1 Max 的四个强项
强项一：长程自主推进，愿意反复验证。
这是 Qwen3.8-Max 最鲜明的特征。官方发布文里的演示都是按"天"计的长任务：一个叫 oh-my-cli 的项目自主编码跑了约 16 天，累计 265 次提交、127 个 PR、151 个 issue；另一个演示让它进真实的阿里天池竞赛，在 24 小时内自主工作，击败了 526 支人类队伍中的 458 支。
厂商演示都有幸存者偏差——没人会发跑崩的那次。但这些演示说明它被优化来做什么：长周期、无人值守、需要持续推进的工程任务。
第三方实测的观察角度不同，结论却一致。有测试者发现它在同一个 Web 页面任务上，完成度高于 GPT-5.6：它会反复读取代码、修改、验证，一层层迭代细节；而 GPT-5.6 更快满足主要功能就收尾。两者的差别不是能力，是对"完成"的定义——一个接受"能用"，一个追求"更接近产品要求"。
强项二：指令遵循（IFBench 82.8）。
这个分数在综合榜上是第一名。落到日常：你写"不许用 Lombok、异常必须包成统一 Result、日志必须带 traceId"，它真的会照做。这听起来是基本功，但多数模型在长 prompt 里会漏掉第三条。
有 优快云 博主的实测印证：让它写一个带重试和超时控制的 HTTP 客户端封装，要求处理异常并打日志——一次生成就能跑，异常分支也覆盖到了。
强项三：长上下文检索（MRCR v2 92.9%）。
在 256K 长度、8 needle 的检索测试上拿 92.9%，排在同类第二。实测感受是：给一份约 3 万字的行业报告做摘要 + 追问细节，摘要准确，细节问题能定位到原文对应段落，没有出现"读了后面忘了前面"的情况。
同时要注意一个配套数字：LongBench v2 只有 69.1。这两个数字不矛盾——MRCR 测"找得到"，LongBench 测"理解得对"。能定位到那一段，不等于读懂了那一段。
强项四：原生多模态 + 操作系统级操作。
OSWorld Verified 86.1，AndroidWorld 85.3，ScreenSpot Pro 84.5，MMMU-Pro 82.3。这一组分数意味着它能看图、看视频、操作桌面界面。对编程的价值不是"能画 UI"，而是能看着截图定位样式问题、能读设计稿生成布局代码、能看录屏复现 bug。
4.2 Max 的四个弱项，第一个就够致命
弱项一：幻觉控制（AA-Omniscience 3.4，对手 Opus 5 是 37.1）。
这是本文写到这里发现的最重要一件事，也是我在前面几篇里从没遇到过的形状。
一个模型在 GPQA Diamond 上考 92.7（博士级科学推理），在 Omniscience 上只有 3.4。这两个分数放在一起的含义是：
它知道得非常多的，但它几乎不知道自己不知道什么。
在编程里这直接对应三类事故：
- 编造不存在的 API。 它会写出
Result.success(data).withTraceId(id)这种看起来极其合理、但你的Result类里根本没有withTraceId的方法。语法对、风格对、语义错，编译器才会救你。 - 编造不存在的依赖版本。
spring-boot-starter-xxx:3.8.2——版本号编得像真的，mvn一跑就 404。 - 编造配置项。
spring.datasource.hikari.leak-detection-threshold-ms，名字合理、前缀正确，但官方文档里叫别的。
这类错误的成本特别高，因为它们不会被代码审查发现，只会被运行时发现。你在 PR 里看到一段逻辑通顺的代码，会本能地相信它；只有真正跑起来才会发现那个方法不存在。
**应对方式必须写进流程，不能靠"小心一点"：**每个由 Max 生成的、涉及外部 API 的代码块，强制要求它输出"这个 API 我确认存在于哪个版本"；凡是它给不出版本或文档位置的，一律视为待验证。这条会写在第七节的 prompt 模板里。
弱项二：速度，以及由速度带来的成本。
AA 记录的中位输出速度在 37–48 tok/s 区间（口径冲突，见 3.3）。这个数字单独看还行，但配上它的输出长度就变味了：
AA 跑完整套评测，用了约 1.9 亿输出 token，导致按任务算的实际成本高于 Claude Opus 5（xhigh 档）。
一个官方输出价 ¥36/百万的模型，单任务实际成本超过 Claude Opus 5——这个反差全部来自"话多"。
独立开发者的记录更直白：用四项固定任务测 Qwen3.8-Max，每一项都是耗时最长的模型。其中扑克模拟任务的核心功能约 20 分钟就完成了，之后又花近一小时调整角色行为。他的结论是"质量很高，但速度很慢"。
雷峰网的实测给出另一个极端案例：任务跑了 3 小时 29 分钟，经历多次验证超时和持续重试，最终因额度耗尽而中断。
弱项三：多轮迭代会"卡壳"。
有实测记录称，让它在自己刚生成的代码上加功能，第一次改得不错，第二次连续修改时出现响应变慢、改动不完整。
这跟 3.2 节 Snorkel 的超时数据是同一件事的两种表现：它在"从零构建一次"的场景里很强，在"连续小步修改"的场景里会退化。
对你的工作流的含义很具体：
- “生成 → 人工审 → 再生成”：安全
- “全自动多轮迭代直到测试通过”：危险，容易在一轮里失效或者烧光额度
弱项四：代码迁移（Code Migration 24.0%）。
已在 3.4 节详述。对 Java 开发者，这一条要写在方案首页。
4.3 Flash 的四个强项
强项一：编码基准上几乎不输旗舰。
官方给的对比表（Flash-Next / 27B / Qwen3.7-Plus / Opus 4.6 Max）：
| 基准 | Flash-Next | 27B | Qwen3.7-Plus | Opus 4.6 Max |
|---|---|---|---|---|
| SWE-bench Pro | 62.5 | 61.7 | 55.8 | 53.4 |
| LiveCodeBench v6 | 91.9 | 90.3 | 89.6 | 88.8 |
| CoWorkBench | 73.9 | 70.7 | 65.1 | 68.2 |
| GPQA Diamond | 91.7 | 89.2 | 90.3 | 91.3 |
四项全部第一，包括对 Opus 4.6 Max。注意这是阿里自报、发布首日、未经复现的数据——但方向和 AA 的独立测（Flash-Next 智能指数 40 > 27B 的 34）是一致的，两份不同来源的数据指向同一个结论，可信度就上来了。
强项二：成本，差距是数量级的。
| 输入 | 输出 | 100万输入+100万输出合计 | |
|---|---|---|---|
| qwen3.8-flash | ¥0.8 | ¥2.7 | ¥3.5 |
| qwen3.8-max | ¥12 | ¥36 | ¥48 |
一天"重活"（百万输入 + 百万输出）差 13.7 倍。
强项三：真能自托管。
125B 总参 / 6B 激活 + 51B N-gram 嵌入，Qwen Community 1.0 许可，可在普通 GPU 上通过 vLLM / SGLang / Transformers / TokenSpeed 跑起来。这是本系列所有模型里自托管可行性最高的一档——比 Max（数据中心级）、比 MiniMax-M3（BF16 854GB）都现实得多。
强项四：接口兼容性好。
OpenAI 兼容 + Anthropic 兼容，官方明确说"可无缝接入 Claude Code、Codex"。这意味着已有的工具链通常不用改代码，只改 base_url 和 model id。
4.4 Flash 的三个弱项
弱项一：最难的单点调用深度不够。
所有 Flash 档的共同天花板。它能在 SWE-bench Pro 上拿 62.5，但在需要"一次想透三层嵌套的状态机"或者"设计一个能扛住乱序回调的幂等方案"时，会给出看起来完整、实际有缝的方案。这类任务不会报错，只会在生产环境里偶发。
弱项二：短上下文场景比上一代贵四倍。
这是本篇第二个反直觉发现，第五节会详细算。
弱项三：AA 数据是间接的，而且速度不占优。
40 分测的是开源权重 Flash-Next，不是托管 SKU；51.6 tok/s 对 27B 的 45.7 tok/s 只快 13%。"Flash"这个名字在延迟上是名不副实的。
4.5 一张评级表
按编程实际感知的维度打分（10 分制，主观综合，仅供排序参考）：
| 维度 | Qwen3.8-Max | Qwen3.8-Flash | 说明 |
|---|---|---|---|
| 从零生成完整模块 | 9 | 7 | Max 强在完成度 |
| 长程自主多步任务 | 8.5 | 6 | Max 的设计目标 |
| 单轮改一处小 bug | 7 | 8 | Max 过度验证，反而慢 |
| 多轮连续迭代 | 5.5 | 7 | Max 会卡壳 |
| 代码迁移 / 老系统改造 | 5 | 6 | 两者都不擅长，Flash 成本低 |
| 跨 40 文件代码库理解 | 9 | 7.5 | 都支持 1M，Max 检索更准 |
| 图片/设计稿/录屏理解 | 9 | 7 | Max 原生多模态更成熟 |
| 单任务响应速度 | 5 | 8 | 差 13% 的单 token 速度，差数倍的完成时间 |
| 单位成本 | 5（倍率补贴后 7） | 8.5 | 见第五节 |
| 可自托管性 | 2 | 8 | Flash 唯一明显领先项 |
五、把账真正算清：三个和你以为不一样的结论
5.1 结论一：平台的 3.33 倍补贴，会被 Max 的"啰嗦"吃掉
回到第一节那个推导：平台给的倍率差是 3.33 倍，官方成本差是 13–15 倍。平台替你承担了中间 11 倍多的缺口。
按道理，这意味着"用 Max 的超额成本只有 3.33 倍，而不是 13 倍"，几乎无脑该用 Max。
但这个算术有个隐藏前提：假设两个模型完成同一件事，消耗的 token 量相同。
而这个前提恰好不成立。
看证据链：
- AA 跑完整评测套件用了 约 1.9 亿输出 token，导致单任务实际成本高于 Claude Opus 5（xhigh）
- 独立开发者：四项任务每一项都是耗时最长的模型；扑克模拟核心功能 20 分钟完成，之后又花近一小时调角色行为
- 雷峰网：单任务 3 小时 29 分钟，多次验证超时与重试，最终额度耗尽
- Snorkel：Agentic Coding 试验 77.7% 超时，SWE-bench CLI 89.1% 超时
把"啰嗦系数"设为 k（Max 完成同一任务消耗的 token 是 Flash 的 k 倍），那么实际成本比是：
实际成本比 = 3.33 × k
要让它不划算，只需要 k > 4.5 左右（因为 15 ÷ 3.33 ≈ 4.5）。
而上面四条记录都指向 k 落在 2 到 5 之间，个别长任务会超过 5。
所以真实的结论不是"无脑选 Max"，而是：
平台的补贴是真的（3.33 倍对 15 倍），但这份补贴的兑现条件是——你必须能截断它的迭代循环。一旦放手让它自己判断"什么时候算做完"，k 会涨到 4 以上，补贴基本被吃掉，你只是在为更慢的响应付同样的钱。
这就是为什么第五节的其余部分、第七节的 prompt 模板、第九节的 SOP 全都在做同一件事：给 Max 装刹车。
5.2 结论二：思考不加价，但 reasoning_effort 三档是双刃剑
Qwen3.8 全系有一个很好的设计：思考模式不额外收费。
对比同门的 qwen-plus，它的思考模式把输出价从 $1.20 拉到 $4.00，涨了 3.3 倍。Qwen3.8 系列没有这个问题——你开 thinking，输出价还是 ¥36（Max）或 ¥2.7（Flash）。
但"不加价"不等于"不花钱"。思考产生的 token 仍然按输出价计费。
三个模型都提供了 reasoning_effort 三档：
xhigh（默认）→ medium → low
这是本系列里粒度最细的显式降本开关（MiniMax-M3 只有开/关两档，MiMo 也是两档）。
实际用法要注意两点：
第一，默认是 xhigh。 也就是说，你不主动改，它就在最高档思考。如果你的场景是"改一个字段名"，xhigh 纯属浪费——3000 token 的思考换一行代码。
第二，降档有质量代价，而且代价不均匀。 从 xhigh 降到 low，对"格式化代码"几乎无损，对"设计并发方案"是灾难。所以不能一刀切，要按任务类型分。
还有一个配套机制：preserve_thinking 默认开启，模型会保留之前的推理链在上下文里。对多轮 agent 场景是好事（保持一致），对成本是坏事（上下文越来越长）。容器化短任务建议主动关掉。
5.3 结论三：Flash 在 256K 以内，比上一代贵四倍
这是本篇第二个必须要说清的反直觉点。
看 qwen3.8-flash 和它的上一代 qwen3.7-flash 的定价结构：
| 输入长度 | qwen3.7-flash 输入 | qwen3.8-flash 输入 | 谁便宜 |
|---|---|---|---|
| ≤ 32K | $0.03 | $0.15 | 老版便宜 5 倍 |
| 32K – 256K | $0.10 | $0.15 | 老版便宜 1.5 倍 |
| 256K – 1M | $0.20 | $0.15 | 新版便宜 1.25 倍 |
国内人民币价同理：qwen3.7-flash 在 32K 以内是 0.2 元/百万，qwen3.8-flash 是 0.8 元——4 倍差距。
原因很清楚：qwen3.8 系列改成了不分档、一口价。 这个改动对长上下文用户是利好（不用再算档位），对短上下文用户是涨价（原本最便宜那一档被抹平了）。
所以"Qwen3.8-Flash 是最便宜的 Qwen"这句话是错的。 正确的是：
- 短提示、高频、轻任务 → qwen3.7-flash 更便宜（但能力弱一档，官方描述是"仅适合简单任务"）
- 长上下文（>256K）、需要新一代能力 → qwen3.8-flash 更划算
这个发现直接反驳了"新版一定更划算"的默认假设。选型时必须按你真实的输入长度分布去算，而"平均输入长度"这个指标会骗人——真实分布是双峰的话，一口价会让你在短的那一峰上多付 4 倍。
5.4 缓存：1.5 元 对 0.1 元，命中率决定一切
两个模型都有缓存，价格天差地别：
| 标准输入 | 缓存命中 | 折扣比 | |
|---|---|---|---|
| Qwen3.8-Max | ¥12 | ¥1.5 | 1/8 |
| Qwen3.8-Flash | ¥0.8 | ¥0.1 | 1/8 |
两边都是八分之一，结构一致。
但 Qwen3.8 系列有一个官方文档明确指出的例外：Model Studio 的缓存文档说，Qwen3.8 系列的缓存命中价不是通常的 20% 或 10%，显式缓存创建对 qwen3.8-max 保持 125%，具体费率要去控制台看。
翻译成操作建议：别按别家模型的 1/5 或 1/10 去估算 Qwen3.8 的缓存收益，去控制台查你自己的实扣价。
缓存有两种模式，用法不同：
隐式缓存（默认开启）：系统自动识别重复前缀，命中部分按缓存价计费。不需要你做任何事，但命中率取决于你的 prompt 结构。
显式缓存（需 cache_control 标记）：有效期 5 分钟，每次命中重置，要求至少 1,024 token。创建费是输入价的 125%，命中价极低。适合"一个小时内反复用同一份大上下文"的场景。
对编程场景的实操结论：把你的项目结构说明、编码规范、数据库表定义放在 prompt 最前面并且逐字节稳定（不插入时间戳、不插入随机 ID、不重排字段），让隐式缓存能命中。这一条能让长上下文任务的成本降一个数量级。
5.5 三个算例
假设你有三种典型任务，算清楚再选。
算例一：每日代码审查（短上下文、高频）
- 每次输入 15K（diff + 规范）、输出 2K
- 每天 200 次
| Max | Flash | |
|---|---|---|
| 输入 token | 300 万 | 300 万 |
| 输出 token | 40 万 | 40 万 |
| 官方成本 | 300×12 + 40×36 = ¥5,040 | 300×0.8 + 40×2.7 = ¥348 |
| 平台倍率折算 | 5040 × 0.5 = 2,520 单位 | 348 × 0.15 = 52.2 单位 |
| 单位成本比 | 48 倍 | 1 倍 |
这个场景 Flash 完胜。 代码审查的每次调用都是独立的、短的、模式化的——正是 Flash 的主场，也是 Max 的"过度验证"最没价值的地方。
注意这里的单位成本比是 48 倍，而倍率只差 3.33 倍——因为官方单价差 15 倍叠加在倍率上。等一下，这里要说清楚：平台按倍率计费，所以实际扣的是"官方成本 × 倍率"吗？不是。
这里必须诚实：我们不知道平台的 1.0× 对应多少钱。 所以上面"平台倍率折算"那一列只能作为相对比较，不能当实付金额。
能确定的只有一件事：无论平台怎么定义 1.0×，只要它是"官方成本 × 倍率"这个形式，Max 的实际成本就永远是 Flash 的 3.33 倍乘以啰嗦系数 k。 而如果平台是"按官方价实收 × 倍率"，那么上面这个 48 倍就是实付比。
两种情况下的结论不同，我在文末把这一点列进了"口径冲突"。你所在平台的实际计价方式，需要自己去账单里核对一次——这是本文唯一一个我给不出确定答案的地方。
算例二：跨仓库重构方案（长上下文、低频、高价值）
- 每次输入 400K（整个模块 + 依赖）、输出 20K
- 每周 5 次
| Max | Flash | |
|---|---|---|
| 输入成本/次 | 0.4×12 = ¥4.8 | 0.4×0.8 = ¥0.32 |
| 输出成本/次 | 0.02×36 = ¥0.72 | 0.02×2.7 = ¥0.054 |
| 单次合计 | ¥5.52 | ¥0.374 |
| 每周 | ¥27.6 | ¥1.87 |
这个场景差 14.8 倍，但绝对值都很小（每周 27 元 vs 2 元）。 这时候应该无脑选 Max——因为方案错一次的代价远超这 25 块钱。
这就是"单位成本"和"决策成本"的区别。 高频任务看单位成本，低频高价值任务看决策成本。
算例三：Max 的啰嗦惩罚（同一任务，k=4）
一个"修一个中等 bug"的任务：
- Flash：输入 30K、输出 3K，一次成功 → ¥0.024 + ¥0.0081 = ¥0.032
- Max（k=4）：输入 30K × 4 轮重读 = 120K、输出 12K（含思考） → ¥1.44 + ¥0.432 = ¥1.87
58 倍。 而如果只看单价，你会以为是 13 倍。
这就是 5.1 节那个 k 的威力：它不是乘在单价上，是乘在"你调用几次 × 每次多长"上，两层放大。
5.6 自托管经济学：Max 别想，Flash 可以算
先给结论：Max 的自托管这条路，对 99% 的团队是死路。
2.4T 总参、95B 激活。就算用 FP8，权重也要上 TB 级存储，推理要一个完整的机架。而且开源版是纯文本 + 强制思考——你花了机架的钱，拿到一个能力更窄还要多烧思考 token 的版本。
Flash 才是真能算的。
Qwen3.8-Flash-Next，125B 总参 / 6B 激活，普通 GPU 可跑（vLLM / SGLang / Transformers / TokenSpeed）。
粗算（假设你有 4 张 H100 80G，按云上约 ¥25/卡/小时）：
4 卡 × ¥25 × 24h × 30 天 = ¥72,000/月
而对标同等吞吐，用托管 Flash 大概需要多少？
假设一个月 300 万次调用，每次输入 8K、输出 1K：
输入：300万 × 8K = 240 亿 token × ¥0.8/M = ¥192,000
输出：300万 × 1K = 30 亿 token × ¥2.7/M = ¥81,000
合计 ≈ ¥273,000/月
托管 ¥273,000，自托管 ¥72,000 —— 在这个量级上自托管明显划算，而且还有数据不出内网、版本自己控的好处。
但门槛在运维：你需要有人能处理 vLLM 的 OOM、量化精度损失、滚动升级、灰度。如果团队没有这个人，托管就是更便宜的选项。
还有一笔隐形账：自托管拿到的是 262K 上下文，不是 1M。 如果你的场景依赖超长上下文，自托管的成本优势会被这个限制部分抵消。
六、场景选型矩阵：12 个真实任务怎么选
把前面所有分析压成一张可以直接查的表。
| # | 任务 | 选谁 | 理由 | 关键动作 |
|---|---|---|---|---|
| 1 | 给一个已有类补单元测试 | Flash | 输入短、模式化、可验证 | 传完整类 + 已有测试风格样例 |
| 2 | 批量 DTO / Entity 字段映射 | Flash | 机械转换，Max 的验证能力用不上 | 给它一张对照表，别让它自己猜 |
| 3 | 写一个全新的 Controller + Service + Mapper | Max | 从零构建是它的主场 | 要求先出接口定义再落实现 |
| 4 | Spring Boot 2.x → 3.x 迁移方案 | Max 出方案，Flash 落码 | Code Migration 24%，不能让它直接改 | 见 8.1 |
| 5 | 并发 bug / 死锁排查 | Max（但必须限轮） | 需要跨文件推理 | 必须设"最多 3 轮，每轮必须给新证据" |
| 6 | 跨 40 个文件理解一个老模块 | Max | 1M + MRCR 92.9 | 用 repo 级检索给它喂结构，别整包塞 |
| 7 | 看设计稿 / 截图生成页面结构 | Max | 原生多模态更强 | 附上你的组件库清单，禁止它自创组件 |
| 8 | 日志埋点 / 异常统一封装 | Flash | 模板化，改动面小 | 给一个已有的正确样例当 few-shot |
| 9 | 单轮改一处小 bug（一行到十行） | Flash | Max 会过度验证，反而更慢 | — |
| 10 | 多轮连续迭代直到测试通过 | Flash（限 3 轮后转人工） | Max 在第二轮会卡壳 | 每轮只让它改一处 |
| 11 | 写技术方案 / 评审文档 | Max | 长输出、结构化、指令遵循强 | 先给目录骨架，逐节展开 |
| 12 | 数据清洗脚本 / 一次性工具 | Flash | 生命周期短，不需要完成度 | 让它输出带 assert 的自检版本 |
这张表的规律很简单：
“从零构建、需要完成度、跨文件理解” → Max。
“模式化、改动面小、可即时验证” → Flash。
“改造既有代码” → 两者都不擅长，用 Max 出方案 + 人工主导，别交给 Flash 直接改。
第三条是最容易被忽略的。很多团队的直觉是"迁移这种脏活交给便宜的模型，出错了再修"——但迁移出错的代价不是修一行代码，是语义等价性被悄悄破坏（一个 @Transactional 传播级别改了，测试全绿，生产偶发脏数据）。这类任务上省钱是最贵的省法。
七、在飞算 JavaAI 里怎么落地：一条需求的两档流水线
7.1 四阶段 × 两档的分配表
飞算 JavaAI 的智能会话分四个阶段：需求分析、前后端设计、前端开发、后端开发。这四个阶段对模型的需求完全不同，正好可以按档分配。
| 阶段 | 建议模型 | reasoning_effort | 原因 |
|---|---|---|---|
| 需求分析 | Max | xhigh | 要理解模糊需求、补全隐含约束，这是幻觉高发区也是价值最高区 |
| 前后端设计 | Max | medium | 结构化输出为主，不需要最高档思考 |
| 前端开发 | Flash | medium | 组件化、模式化，改动可即时预览 |
| 后端开发 | Flash（复杂模块切 Max） | low → medium | 明确的 CRUD 用 low，跨模块事务用 medium |
**为什么需求分析必须用 Max：**这一步的输出会变成后面三步的输入。如果这里把"订单超时关闭"理解成"订单支付超时"，后面三步全会沿着错的语义展开，而且因为每一步都自洽，你很难在中间发现。上游错误的成本是指数级的。
**为什么后端开发可以降到 low：**绝大多数后端代码是"照着接口定义填实现"，reasoning_effort: low 足够。省下来的思考 token 在这个阶段占比最大——因为调用次数最多。
7.2 Max 专用的"刹车 prompt"
这三个约束是为了对付 4.2 和 5.1 里说的过度验证问题。
【执行纪律】
1. 你最多可以执行 3 轮"读取-修改-验证"循环。第 3 轮结束时必须输出当前结果并停止，
即使你认为还有问题。停止时用以下格式说明未完成项：
- 已完成：xxx
- 未完成：xxx（原因）
- 建议下一步：xxx
2. 每一轮修改前，先用一句话说明"这一轮我要验证的假设是什么"。
如果你无法说出一个新的假设，说明这一轮没有新增信息，立即停止。
3. 禁止重复执行相同的验证命令。如果你要再跑一次测试，必须先说明
"上一次运行与这一次之间的代码差异是什么"。
第 2 条是关键。过度验证的本质是"重复验证同一件事"——它在验证一个已经被证实的假设。强制它说出"这一轮的新假设"，就等于强制它证明这一轮有存在的必要。
第 3 条对应雷峰网那个"多次验证超时和持续重试"的现象。重复跑测试是 agent 最常见的空转形式。
7.3 Max 专用的"反幻觉 prompt"
针对 AA-Omniscience 3.4 那个短板。
【事实纪律】
1. 任何涉及以下内容的代码，必须标注来源版本，否则不要写：
- 第三方库的类名/方法名 → 写 [需验证: 库名 版本]
- 配置项名称 → 写 [需验证: 官方文档路径]
- 注解参数 → 写 [需验证: 版本]
2. 如果你不确定某个 API 是否存在，输出这个格式：
【不确定】我倾向于使用 xxx，但我不确定它在 yyy 版本中是否存在。
替代方案：zzz（我更确定这个存在）
3. 禁止使用"显然""当然""众所周知"这类词来掩盖不确定性。
第 2 条那个格式设计得很重要：它允许模型承认不确定，而不是假装确定。 对一个 Omniscience 只有 3.4 的模型，你唯一能做的就是给它一个"承认不知道"的出口——如果没有出口，它只会编。
7.4 一段可直接抄的 reason_effort 决策树
# 按任务形态选 reasoning_effort，Qwen3.8 系列三档
def pick_effort(task: dict) -> str:
# 1. 改一行、格式化、字段改名 → 最低档
if task["est_loc_change"] <= 10 and not task["involves_logic"]:
return "low"
# 2. 加单测、写 DTO、日志埋点 → 低档（模板化，模式清晰）
if task["pattern"] in ("unit_test", "dto_mapping", "logging"):
return "low"
# 3. 跨模块重构、并发问题、迁移方案 → 最高档
if task["cross_module"] or task["concurrency"] or task["migration"]:
return "xhigh"
# 4. 需求分析、方案设计 → 最高档（上游错误成本指数级）
if task["stage"] in ("requirement", "design"):
return "xhigh"
# 5. 其余默认中档（不要用默认的 xhigh，那是白花钱）
return "medium"
最后那行注释是重点：Qwen3.8 的默认是 xhigh。 你不传这个参数，它就在最高档思考。对一个小改动来说，这个默认值会烧掉大量输出 token。显式传 medium 是最省事的一刀降本。
7.5 缓存命中：把不变的东西放最前面
这一条对所有模型都适用，但在 Qwen3.8 上收益特别大（因为缓存命中是标准输入的 1/8）。
prompt 的结构按稳定性从高到低排列：
[1] 系统角色 + 执行纪律 + 事实纪律 ← 永不变化，缓存常命中
[2] 项目技术栈 + 编码规范 + 禁用清单 ← 极少变化
[3] 数据库表结构 / 接口契约 ← 每周变化
[4] 当前任务描述 ← 每次变化
[5] 相关代码片段 ← 每次变化
三个让缓存失效的常见错误：
- 在第 1、2 段里插入时间戳或随机请求 ID
- 用
json.dumps(dict)序列化配置——字典顺序可能不稳定，逐字节就变了 - 每次重新生成"项目结构摘要"——摘要一变，后面全部失配
**修法：**第 1、2 段用纯字符串常量；配置序列化固定用 json.dumps(cfg, sort_keys=True, ensure_ascii=False)；项目结构摘要缓存到本地文件，只在文件树真的变了才重新生成。
八、代码实战：同两个任务，两种命运
8.1 Max 的主场：Spring Boot 2.3 → 3.2 迁移方案（但别让它落码）
先看错误用法。如果你直接说"帮我把这个项目从 Spring Boot 2.3 迁到 3.2"，它会给你一堆 javax.* 改成 jakarta.* 的替换，看起来非常专业，然后你会踩到这些坑：
javax.validation改了，但@Valid在嵌套对象上的行为变了spring.factories被移除，自动配置要改成AutoConfiguration.importsWebSecurityConfigurerAdapter被移除，但它的替代写法有 3 种，选错了会导致整个安全链失效- Hibernate 6 改了 ID 生成策略的默认值，
GenerationType.AUTO的行为不一样了
这些没有一个是"改 import"能解决的，而且都不会在编译期报错。
正确用法是让它出方案、标风险，人来落码：
请阅读以下 pom.xml 和 3 个代表性 Controller，产出一份迁移评估报告，不要写任何代码。
报告必须包含：
1. 直接依赖清单：哪些依赖的版本跨越了 javax→jakarta 边界
2. 配置迁移项：列出 spring.factories 里现有的自动配置类（我会贴给你），
逐条说明它在 3.x 里的对应写法；如果你不确定某个类的替代方案，标记【需验证】
3. 行为变更风险：列出 3.x 中默认行为发生变化、且不会导致编译错误的点，
每条给出"如何验证这个变化在你的项目里是否生效"的具体命令
4. 分批策略：如果这个项目有 40 个模块，建议按什么顺序迁，为什么
5. 不建议迁的部分：有没有哪个模块建议暂缓或重写而非迁移
约束：
- 涉及具体类名、配置项名称时，标注你确认的版本号；不确定的标【需验证】
- 不要给出"可能""也许"这类无法验证的表述
**为什么这样问有效：**Code Migration 24.0% 说的是"直接产出可用的迁移代码"很难，但"识别迁移风险点"是另一件事——它需要的是知识广度（这个 API 在 3.x 里叫什么），而这正是 GPQA 92.7、IFBench 82.8 覆盖的能力。把任务从"生成"改成"识别"，就绕开了它的短板。
这也和雷峰网那段的观察吻合：它对"完成"的定义是"更接近产品要求"，所以它会倾向于给你一份看起来很完整的代码。但在这个任务上，一份看起来很完整的迁移代码恰恰是最危险的产出。
8.2 Flash 的主场：批量补单测 + 日志埋点
这类任务的三个特征——输入明确、输出可验证、模式重复——正好避开 Flash 的全部短板。
为以下 Service 方法补单元测试。
约束：
1. 使用项目已有的测试风格（我会给你一个样例，严格模仿其 import 和断言风格）
2. 每个方法至少覆盖：正常路径、参数为空、边界值、异常路径
3. 使用 Mockito mock 掉所有外部依赖，不要用 @SpringBootTest
4. 不要写"测试覆盖率"相关的注释
5. 如果某个分支你无法从代码推断出预期行为，写一个 @Disabled 的测试并注明原因
样例（严格模仿）：
【贴一个已有的、你认可的测试类】
第 5 条很重要。Flash 在这类任务上的失败模式不是"写错"，而是**“编一个看起来合理的断言”**——比如给一个抛 IllegalArgumentException 的方法断言它返回 null。加上这条约束，它会把不确定的分支标出来，而不是硬编。
8.3 Flash 翻车的地方：一个并发扣减的修复
任务描述：库存扣减在高并发下出现超卖，请修复。
Flash 大概率会给你这样一段：
// Flash 的典型产出
@Transactional
public boolean deductStock(Long skuId, int quantity) {
Stock stock = stockMapper.selectById(skuId);
if (stock.getAvailable() < quantity) {
return false;
}
stock.setAvailable(stock.getAvailable() - quantity);
stockMapper.updateById(stock);
return true;
}
这是经典的读-改-写竞态。它加了 @Transactional，看起来考虑了事务——但默认隔离级别下，两个事务可以同时读到同一个 available 值，然后各自扣减，最后一次写入覆盖前一次。
正确做法至少有三种，各有代价：
| 方案 | 写法 | 优点 | 缺点 |
|---|---|---|---|
| 悲观锁 | SELECT ... FOR UPDATE | 简单可靠 | 锁竞争，吞吐低 |
| 乐观锁 | UPDATE ... WHERE available >= ? AND version = ? | 无锁，吞吐高 | 失败要重试，需要重试策略 |
| Redis 预扣 | Lua 脚本原子扣减 + 异步落库 | 最快 | 一致性复杂，要处理补偿 |
Flash 的问题不是它不会写乐观锁，是它不会告诉你"这里有三种方案，你的场景该选哪个"。 它给一个能编译、看起来有事务保护的方案，你会以为问题解决了。
Max 在这个任务上会好一些——它会问"你的 QPS 量级是多少"，会提到 FOR UPDATE 和乐观锁的取舍。但按 4.2 的描述，它可能在第二轮修改时卡壳，或者陷入反复验证。
所以这个任务的正确姿势是：
第一轮（Max，xhigh）：只让它分析，不出代码
"分析这个扣减逻辑在并发下的所有失败模式。不要给修复代码。
按'触发条件 / 后果 / 检测方法'三列输出。"
第二轮（人工）：根据失败模式清单，自己决定用哪种方案
第三轮（Flash，medium）：只让它实现你选定的那一种
"按乐观锁方案实现，重试逻辑用 Spring Retry，最多 3 次，退避 50ms 起指数增长。"
这个三段式是本文最重要的一条经验：把"判断"和"实现"分开，判断用 Max，实现用 Flash。
8.4 两个任务的对比结论
| 迁移方案 | 补单测 | |
|---|---|---|
| 选谁 | Max | Flash |
| effort | xhigh | low |
| 输出形态 | 风险清单 + 分批策略（不落码） | 可运行的测试类 |
| 验证方式 | 人工评审 + 逐条实测 | mvn test 通过 |
| 如果选错会怎样 | 用 Flash → 得到一堆假等价替换，编译过、语义错 | 用 Max → 花 5 倍成本，还要人工删掉过度设计的测试 |
这张表最后一行是整篇的缩影：两个方向的选错，代价的性质完全不同。 用 Max 干 Flash 的活，浪费的是钱（可度量、可回滚）；用 Flash 干 Max 的活，浪费的是信任（不可度量、会在生产上还账）。
钱可以再挣，信任不行。所以边界不清的时候，选 Max。
九、一套可以直接抄走的选型 SOP
9.1 五步判断，每步一个可回答的问题
第一步：这个任务做错一次的代价是多少？
- 编译报错 / 测试失败 → 代价低，用 Flash
- 生产事故 / 数据错乱 / 安全漏洞 → 代价高，用 Max
- 无法判断 → 按代价高处理
第二步：这个任务的输入有多长？
- < 32K → 注意：qwen3.7-flash 比 qwen3.8-flash 便宜 4 倍，如果任务简单可以直接用老版
- 32K 到 256K → qwen3.8-flash 和老版差距缩小
- 256K 到 1M → qwen3.8-flash 的一口价开始占优，且只有它和 Max 支持
第三步：这是"从零构建"还是"改造既有"？
- 从零构建 → Max（这是它最强的地方）
- 改造既有 → Max 出方案 + 人工落码，绝不让 Flash 直接改
- 模式化替换 → Flash
第四步：需要几轮迭代？
- 1 轮 → 都行
- 2 到 3 轮 → Flash（Max 在第二轮会卡壳）
- 3 轮以上自主循环 → 必须给 Max 装 7.2 那个刹车 prompt，否则用 Flash 分批做
第五步：要不要自托管？
- 要，且能接受 262K → Flash-Next
- 要，且必须 1M → 只能托管
- 要，且必须视觉输入 → Flash-Next 可以，Max 开源版不行（纯文本）
9.2 三十题私有题集：怎么在半天内测出适配度
公共榜单只能告诉你大致方位，真正的判断要用你自己的代码。下面是按本文分析设计的 30 题，每题记录耗时 / 成本 / 一次通过率 / 人工返工次数四项。
A 组：Max 应该赢的（10 题）
- 从零写一个带分页 + 排序 + 多条件筛选的查询接口
- 把一段 200 行的祖传 if-else 改造成策略模式
- 读懂一个 15 个类的模块，输出时序图文字描述
- 根据一段产品需求（模糊），补全成可实现的接口契约
- 设计一个能扛住乱序回调的支付幂等方案
- 分析一个 N+1 查询问题，给出三种优化方案的取舍
- 看一张 UI 截图，输出页面结构 + 组件树（附你的组件库清单）
- 为一个跨 3 个微服务的流程设计分布式事务方案
- 写一份技术评审文档，含备选方案对比
- 给一个并发 bug 出所有可能的失败模式清单（不要求修）
B 组：Flash 应该赢的（10 题）
- 给一个已有类补 8 个单测
- 20 个 DTO 的字段映射（Entity → VO）
- 把
System.out.println全部改成结构化日志 - 单轮修一处空指针
- 给一个方法加参数校验注解
- 把 XML 配置改成注解配置（机械转换）
- 补 Swagger 注解
- 写一个一次性的数据清洗脚本
- 把一段 SQL 改成 MyBatis-Plus 的 Lambda 写法
- 生成 10 个 enum 的转换工具类
C 组：两个都会翻车的（10 题，用来标定边界）
- Spring Boot 2.3 → 3.2 全量迁移
- 一个偶发的
@Transactional失效问题 - 高并发扣减（不给 QPS 量级）
- 一段没有注释、变量名全是
a1/a2/b1的老代码重构 - 修一个只在生产环境、每 3 天出现一次的 bug
- 把一个 10 年前的 Struts 项目迁 Spring MVC
- 在没有任何文档的情况下理解第三方 SDK 的某个行为
- 优化一个已经跑得很慢但不知道慢在哪的接口
- 一个涉及 4 个团队接口约定的改造
- 判断一段代码有没有安全漏洞
C 组的价值最大——第 21、26 题测的就是 Code Migration 24.0% 那一块；第 25、28 题测的就是"能不能在有限轮次内收敛"。
9.3 三段可复用的 prompt
第一段：给 Max 的分析型任务骨架
【角色】你是资深架构师，不是编码助手。
【任务】分析以下代码/需求，输出判断，不输出实现代码。
【输入】{代码或需求}
【输出格式】
1. 关键约束（我从没说过但你必须遵守的）
2. 失败模式清单（触发条件 / 后果 / 检测方法 三列）
3. 备选方案对比（至少 2 个，含取舍）
4. 你无法判断的部分（明确列出，不要猜）
【纪律】涉及具体 API/配置项时标注确认的版本号；不确定的标【需验证】
第二段：给 Flash 的实现型任务骨架
【角色】你是执行者。
【任务】严格按以下规格实现，不要自行扩展。
【规格】{明确的接口签名 + 行为描述}
【参考样例】{一个你认可的、风格一致的已有实现}
【禁止】不要加规格外的功能、日志、注释、异常处理
【不确定时】写 // TODO(需人工确认): {具体不确定什么}，不要自行假设
第三段：给任意模型的自检骨架
在回答前，先自查这三个问题并简短回答：
1. 我这个回答里，有哪些具体的东西（类名/方法名/配置项/版本号）是我确认存在的？
哪些是我推断的？分别列出来。
2. 如果我的方案在真实环境失败了，最可能的原因是什么？
3. 我不应该回答但现在回答了的部分是什么？
第 3 个问题特别有效。它逼模型去发现自己"越界"的地方——而越界正是幻觉的高发区。
十、六个常见误区
误区一：“Flash 是 Max 的缩水版”
错，而且方向反了。
Max 用的是 Qwen 3.5 世代的架构，Flash 用的是 Qwen4 预览版（Qwen Sparse Attention + Gated DeltaNet + 门控残差 + Muon 训练）。这是两台不同世代的发动机。
官方数据里，Flash-Next 在 SWE-bench Pro（62.5）、LiveCodeBench v6（91.9）、CoWorkBench（73.9）、GPQA Diamond（91.7）四项上全部超过 27B 和 Qwen3.7-Plus，也超过 Opus 4.6 Max。
Flash 不是"小 Max"，是"新一代架构的小型化验证"。 这个区别很重要——它意味着你不能用"参数少所以能力弱"去推论，必须看具体基准。
误区二：“倍率低的就一定便宜”
本篇第一节已经把这个推翻了。
倍率 0.5 和 0.15 差 3.33 倍，官方成本差 13–15 倍。倍率越低的那一格，相对官方成本的溢价越高。
正确的读法是：倍率要和官方价一起看，单独看倍率一定会选反。
误区三：“Qwen3.8 全系不分档，所以新版一定比老版贵得不合理”
这个说法有一半是对的，但它推出的结论错了。
事实：qwen3.8-flash 在 32K 以内的输入价是 0.8 元，而 qwen3.7-flash 是 0.2 元，贵 4 倍。
但推论不该是"那不如用老版"，而应该是：按你的输入长度分布分开处理。
- 短任务占比高 → 老版 flash 更省钱，代价是能力弱一档（官方描述：“仅适合简单任务”）
- 长任务占比高 → 新版一口价反而划算
- 混合负载 → 两条路由并行，按 token 数分流
这才是"不分档"这个设计变更的正确应对。
误区四：“官方开源了，所以能自己部署省钱”
两个模型要分开看。
- Max 的开源版：2.4T 参数、纯文本、强制思考。机架级硬件，"省钱"这个前提不成立。
- Flash-Next：125B/6B，普通 GPU 可跑，这个是真能省的（5.6 节算过，一个月 ¥72,000 对 ¥273,000）。
但即便 Flash-Next，也要算上运维成本 + 上下文从 1M 降到 262K 的损失。"开源"是一个选项，不是一个决定。
误区五：“官方 TerminalBench 29.0，比 Opus 5 的 42.7 差不了多少”
差得不少，而且更差的是它没显示出来的部分。
两个原因：
- 29.0 是自家框架 + 5 小时超时跑出来的。第三方标准框架下更低。
- Snorkel 的 Terminal-Bench 4.0 只有 27%，排名 13/23，配套 89.1% 的超时率。
真实含义是：它能在给足时间和合适脚手架的情况下完成一部分终端任务，但在通用条件下，很多时候它根本跑不完。
误区六：“GPQA 92.7，所以它很可靠”
这是本篇最危险的一个误读。
GPQA Diamond 92.7 和 AA-Omniscience 3.4 是同一个模型的两个数字。
- GPQA 测的是"给定一道有正确答案的题，它能不能答对"
- Omniscience 测的是"它能不能区分自己知道的和不知道的"
第二个能力在编程里比第一个更重要，因为你要的是它别乱写，不是它什么都会。
一个 Omniscience 3.4 的模型，会在 92.7 分的自信水平上，写出一个不存在的 withTraceId() 方法。它的自信和它的准确性是脱钩的。
应对只有一条：把"承认不确定"写进 prompt，并且对每一个外部 API 引用做版本核验。 7.3 节给了模板。
十一、结论：这张表在补贴旗舰，但补贴有个兑现条件
回到开头那两行。
Qwen3.8-Max 0.5×
Qwen3.8-Flash 0.15×
如果你只记一件事，记这个：
这两个数字的比值是 3.33，但它们背后真实的成本比是 13 到 15。中间那 11 倍多的缺口，是平台替你出的钱，而且这笔钱主要出在 Max 身上。
换算过来：花 1 份额度买 Max，换回 24 元的官方输入价值；买 Flash，换回 5.33 元。差 4.5 倍。
这就是为什么"先拿 Flash 干活，不行再换 Max"这个直觉是反的——你放弃的是这张表里最大的一笔补贴。
但这句话有个必须加的限定：
这笔补贴的兑现条件是你能截断 Max 的迭代循环。
有独立记录显示：一个扑克模拟任务核心功能 20 分钟就写完了，之后又花近一小时调整角色行为；另一个任务跑了 3 小时 29 分钟，最后因额度耗尽中断；Snorkel 的第三方测试里，77.7% 的 Agentic Coding 试验和 89.1% 的 SWE-bench CLI 试验是超时结束的。
一旦放手让它自己判断"什么时候算做完"，啰嗦系数 k 会涨到 4 以上，补贴被吃掉，你只是在为更慢的响应付同样的钱。
所以这篇的落点不是"选 Max"，而是三句话：
第一，Max 的能力是真的，但它被优化来跑长任务，不是跑快任务。 从零构建完整模块、跨 40 个文件理解老代码、看设计稿生成布局、出迁移风险清单——这些是它明显领先的领域。改一行、补单测、机械转换——用它是浪费。
第二，Flash 被低估的地方是架构，不是价格。 它用的是 Qwen4 预览版的发动机，在 SWE-bench Pro 和 LiveCodeBench v6 上超过了 27B 和 Opus 4.6 Max。但它的 0.15× 在官方 15 倍价差面前是溢价，不是便宜。选它应该是为了"轻任务 + 可即时验证 + 能自托管"，不是为了省钱。
第三，这一格最需要注意的不是选谁，是两个隐藏风险。
- 幻觉控制：AA-Omniscience 3.4（对手 37.1）。它会自信地编造 API、配置项、依赖版本，而且不会在编译前暴露。
- 代码迁移：Code Migration 24.0%，而 SWE-bench Verified 是 85.6%。"会写代码"和"会改造代码"在这个模型上差了 61 个百分点。
这两个风险都不在"选谁"的层面能解决，只能靠流程——Max 出判断、Flash 出实现、人工做验收。
顺带一个时间点提醒：Qwen3.8-Max 的 0902 快照把八项编码基准全部拉高（TerminalBench 3.0 从 11.3 到 29.0，ProgramBench 从 10.5 到 28.0），而定价没变。如果你在 9 月前试过 Max 并因为它编码不行而放弃，值得用 0902 重测一次——那已经是一个不同的模型了。
最后一句关于那张表本身：它不告诉你谁更强，只告诉你平台希望你先试谁。 强弱要看第三节那五条纪律之后剩下的东西，而"希望你先试谁"这件事，它说得非常直白——旗舰档 0.5×，轻量档压到地板价 0.15×，同一个 0.15× 在上一格（MiniMax-M3）也是地板价。
地板价是用来打消顾虑的，不是用来反映成本的。
数据来源与说明
一、官方信息（阿里云 / 通义千问）
- 定价与规格：阿里云百炼华北2（北京）刊例价；qwen3.8-max 输入 ¥12 / 输出 ¥36 / 缓存命中 ¥1.5 / Batch ¥6+¥18 / 显式缓存创建 ¥15、命中 ¥1；qwen3.8-flash 输入 ¥0.8 / 输出 ¥2.7 / 缓存命中 ¥0.1 / Batch ¥0.4+¥1.35 / 显式缓存创建 ¥1.25、命中 ¥0.1。两模型均不分档。
- 国际站（新加坡）：qwen3.8-max $2.00/$6.00，缓存读 $0.25；qwen3.8-flash $0.15/$0.47，缓存读 $0.016，显式缓存创建 $0.20。阿里云国际站另有折扣价 $1.65/$4.951（Max）、$0.113/$0.382（Flash），本文主用刊例价。
- 上下文与限额：两模型均为 1M 上下文、128K 最大输出（Max）；Flash 最大输入 991,808（思考模式 983,616）、最大输出 131,072、最大思维链 262,144、TPM 5M。
- 架构：Max 2.4T 总参 / 95B 激活 / 512 专家（10 路由 + 1 共享）/ Qwen 3.5 世代（Gated DeltaNet + 门控注意力）/ MTP 训练。Flash-Next 125B + 51B N-gram / 6B 激活 / Qwen4 预览（QSA + GDN + 门控残差 + Muon）/ 训练成本约为 Qwen3.7-Plus 的 1/9。
- 开源：
Qwen3.8-2.4T-A95B（自定义许可，纯文本，强制思考）；Qwen3.8-Flash-Next（Qwen Community 1.0，原生 262,144 上下文，可 vLLM/SGLang/Transformers/TokenSpeed）。 - 官方基准（0803 初版，对比 Opus 4.8 / Fable 5 / GPT-5.6 Sol）：Terminal Bench 2.1 86.6、SWE-bench Pro 67.7、DeepSWE 1.1 56.6、FrontierSWE 73.5、PaperBench 93.0、CoWorkBench 74.8、Toolathlon 72.5、GPQA Diamond 92.6、HLE 43.6、IFBench 82.8、MRCR v2 256K 83.2、LongBench v2 69.1。
- 官方基准（0902 快照，对比 Claude Opus 5）：TerminalBench 3.0 29.0、DeepSWE 1.1 69.3、NL2Repo 64.9、ProgramBench 28.0、SWE-Marathon 44.8、MLS-Bench-Lite 50.1、SWE-Atlas QnA 66.3、QwenSWEBench V2 70.0、CoWorkBench 76.1、JobBench 64.0、Toolathlon 73.3、WorkArena Elo 1468。
- 官方基准（Flash-Next / 27B / Qwen3.7-Plus / Opus 4.6 Max）：SWE-bench Pro 62.5/61.7/55.8/53.4；LiveCodeBench v6 91.9/90.3/89.6/88.8；CoWorkBench 73.9/70.7/65.1/68.2；GPQA Diamond 91.7/89.2/90.3/91.3。
- 综合榜聚合值（Qwen3.8-Max）：SWE-bench Verified 85.6、LiveCodeBench 87.8、Arena Code Elo 1667、Vibe Code Bench 64.7、Code Migration 24.0、IOI 73、OSWorld 86.1、AIME 2025 99.4、GPQA Diamond 92.7、IFBench 82.8、MRCR v2 92.9、MMMU-Pro 82.3。
- 内置工具定价（Flash）：代码解释器 / web_extractor / web_fetch 免费；web_search ¥4/K 调用；t2i_search ¥24/K；i2i_search ¥48/K。
二、第三方独立评测
- Artificial Analysis：Qwen3.8-Max 智能指数 58、编程指数 71.8；Qwen3.8-Flash-Next 智能指数 40、51.6 tok/s；Qwen3.8-27B 智能指数 34、编程指数 68.1、45.7 tok/s。AA-Omniscience：Qwen3.8-Max 3.4，Claude Opus 5 37.1。 AA 记录 Max 跑完整评测套件消耗约 1.9 亿输出 token，单任务实际成本高于 Claude Opus 5（xhigh）。
- Snorkel：Agentic Coding 2.0 14.7%（13/14）、SWE-bench CLI 4.9%（9/14）、Terminal-Bench 4.0 27%±3.8（13/23）；SnorkelLegal 25.6%、Underwrite 20.0%、Finance 14.1%、Manufacturing 8.3%、RevOps 6.5%；超时率：Agentic Coding 77.7%、SWE-bench CLI 89.1%；安全/游戏/系统管理三类在 Agentic Coding 2.0 上均低于 8%。
- Vals AI / 其他：见上文各表。
三、独立实测记录
- 雷峰网：Qwen3.8-Max 页面完成度高于 GPT-5.6，倾向反复读取/修改/验证；单任务运行 3 小时 29 分钟，多次验证超时与重试，最终额度耗尽中断；指出"过度思考"包含模型推理阶段与 agent 执行阶段两类消耗，本次只能确认后者。
- 独立开发者 Thomas Wiegold：四项固定任务测试，每项任务都是耗时最长的模型；扑克模拟核心功能约 20 分钟完成，之后又花近一小时调整角色行为；结论"质量很高，但速度很慢"。
- Minjae Cho（sgtcho.com，104 次实测，2026-08-03）：预算模式下 SVG 任务（120 秒上限）两模型共 18 次尝试全部超时；无限制模式下稳定版 3 个 SVG 任务耗时 28 分 12 秒 / 87,380 completion tokens，预览版 32 分 11 秒 / 101,867 tokens；56,695 input token 的 needle 检索任务全部通过。
- 优快云 博主 AgatePanther34：3 万字报告摘要准确、细节可定位原文段落，无"读后忘前"；HTTP 客户端封装（重试 + 超时 + 异常 + 日志）一次生成即可运行；连续第二次修改时出现响应变慢、改动不完整；画像为"一次性生成强，多轮迭代弱"。
- UsageBox / OrcaRouter / pricepertoken 等聚合站：qwen3.7-flash 与 qwen3.8-flash 的分档对比（32K 内 $0.03 vs $0.15，32K–256K $0.10 vs $0.15，256K–1M $0.20 vs $0.15）；Qwen3.8 系列缓存命中价不是通常的 20% 或 10%，需查控制台。
- SeaWhale AI（haijingai）模型页：Terminal-Bench 3.0 官方成绩使用自家测试框架 + 5 小时超时，第三方标准框架下重测分数更低；与 GLM-5.3 的 Terminal-Bench 3.0 对比为 29.0 vs 28.3。
四、口径冲突与不确定项（请勿当确定事实引用）
- Max 的中位输出速度：存在 37 tok/s 与 48 tok/s 两个流传值，来源与测试条件不同。本文按 37–48 区间表述，不引单一数字。
- Qwen3.8-Max 开源版许可：一处资料称"Qwen3.8-Max License（开源版 Apache 2.0）“，另一处明确为"自定义许可”。本文按自定义许可主述，Apache 2.0 一说存疑。
- Flash 的 AA 分数 40 测的是开源权重
Qwen3.8-Flash-Next，非托管qwen3.8-flashSKU；且与 27B 的 index 条目分属不同对比集（116 vs 141 个模型）、不同评估日期，只能当"相邻"读，不是受控头对头。 - 发布日期的多处不一致：Max 有 2026-08-02 与 08-03 两个说法；27B 有 08-13 与 08-14；Flash 有 08-25、08-26、08-27 三个说法。本文取最常见值并在此标注差异。
Qwen3.8（第六个 2.4T 未命名项）：一处资料称阿里表示"该 2.4 万亿参数旗舰的权重即将释出但暂不可调用"。此项与Qwen3.8-2.4T-A95B是否同一物，资料不足，未在正文中使用。- 平台 1.0× 的货币含义未公开。本文所有"倍率折算"仅作相对比较，不能当作实付金额。5.5 节明确标注了两种可能的计价方式（“官方成本 × 倍率” vs “官方价实收 × 倍率”）会导致不同结论，需自行核对平台账单。这是全文唯一未闭合的口径。
- 官方 TerminalBench 数值的可比性：0803 的 2.1 版（86.6）与 0902 的 3.0 版（29.0）为不同基准版本，不可横向比较；官方跑分使用自家框架与 5 小时超时，与第三方标准框架结果不可直接对比。
- 30 题私有题集为本文基于能力分析设计的方法论，其中第 21、26 题的能力预期来自 Code Migration 24.0% 这一官方分数，并非实测结论。
扫一扫
320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
