Qwen3-Max 与 Qwen-Plus：60 个真实修复任务评测方案

标题：Qwen3-Max 与 Qwen-Plus：60 个真实修复任务评测方案

正文：

Qwen3-Max 与 Qwen-Plus：60 个真实修复任务评测方案

本文是一份评测方案，不是已经完成的实测报告。目前没有可公开复核的 60 个任务清单、模型原始响应、补丁、测试日志、Token 记录和账单，因此不能给出胜率、成本排名或"Max 是否更值"的结论。

本文涉及的时间分别为：

资料检索快照：2026 年 6 月 5 日
评测方案整理日：2026 年 10 月 21 日
文章修订发布日期：2026 年 10 月 26 日

资料检索早于方案整理和文章发布。正式执行评测前，必须重新核对供应商目录、价格和接口规格，不能把 2026 年 6 月 5 日的目录状态直接当成此后的永久状态。

先纠正模型名称

"Qwen3.7 Max"和"Qwen3.7 Plus"不是本次资料快照中可对应到供应商公开目录的正式名称，也不能作为可复现实验使用的 model ID。不能把 Qwen3-Max、Qwen-Plus 等名称自行组合成"Qwen3.7"。

按 2026 年 6 月 5 日检索的阿里云百炼模型目录，本方案拟比较以下目录项：

供应商目录名称	API model ID	本文中的简称	状态
Qwen3-Max	`qwen3-max`	Max	待正式调用核验
Qwen-Plus	`qwen-plus`	Plus	待正式调用核验
Qwen3.7 Max	无对应目录项	不使用	非正式名称
Qwen3.7 Plus	无对应目录项	不使用	非正式名称

这里的日期是目录核验快照日期 ，不是模型训练截止日期，也不代表 qwen3-max 和 qwen-plus 永远指向同一个后端版本。

如果供应商同时提供固定日期版本和滚动别名，正式评测应优先使用固定版本。若只能使用滚动别名，则必须保存：

完整 model ID；
API 区域和端点；
请求时间；
响应中可获得的模型版本字段；
SDK 及 API 版本；
供应商控制台中的调用记录；
测试当天的模型目录页面或存档。

在这些信息齐全之前，本文只能讨论 qwen3-max 与 qwen-plus 的评测方法，不能声称比较的是两个固定不变的模型快照。

TL;DR

目前没有证据可以证明 qwen3-max 在 60 个真实缺陷任务上一定强于 qwen-plus，也没有证据可以证明后者成本更低。

以下数据均尚未采集：

首轮补丁通过率；
二次修复率；
Python、Java 和 TypeScript 分语言结果；
平均延迟及 P95 延迟；
429、5xx 和超时率；
输入、输出及缓存 Token 用量；
总调用费用；
每个有效补丁成本。

需要特别区分"未采集"和"未公开"：本文没有完成价格及规格核验，不应据此断言供应商没有公开相关信息。正式测试前，应按照正确的 model ID，重新读取供应商当天的模型目录、价格页和 API 文档。

选型真正需要回答的是：

Max 相比 Plus 多完成的有效修复，能否覆盖额外的调用费用、等待时间和工程复杂度？

这 60 个任务目前只是目标样本

评测计划包含 60 个任务：

Python：20 个；
Java：20 个；
TypeScript：20 个。

但在完整任务清单公开前，不能声称"已经整理了 60 个真实缺陷"，也不能声称这些任务全部来自真实仓库、根因已经确认或拥有稳定测试。

一个任务只有同时具备以下材料，才能进入正式样本：

公开仓库地址；
固定的缺陷 commit；
修复 commit 或可核查的根因记录；
仓库许可证；
可在干净环境复现的失败测试；
固定依赖和构建环境；
明确的测试命令；
缺陷版本上稳定失败、修复版本上稳定通过；
不依赖已经失效的外部服务或私有凭据；
未被模型提示直接泄露标准补丁。

正式发布时，应提供一份包含 60 行记录的任务清单。最低字段如下：

字段	内容
`task_id`	唯一任务编号
`language`	Python、Java 或 TypeScript
`repository`	仓库链接
`license`	许可证及核验结果
`bug_commit`	固定缺陷 commit
`fix_commit`	原项目修复 commit；评测时不提供给模型
`container_digest`	容器镜像摘要
`install_command`	安装命令
`test_command`	完整测试命令
`failing_tests`	缺陷版本上的失败测试
`root_cause_record`	Issue、PR 或维护者说明
`context_files`	提供给模型的文件清单
`timeout`	单任务超时限制

如果这些资料无法提供，相关任务只能称为"候选任务"，不能写入正式成绩。

评测流程

每个任务对两个模型使用相同的代码版本、提示词、上下文和测试环境，并最多运行两轮修复。

flowchart LR A[固定缺陷 commit] --> B[发送相同提示与代码上下文] B --> C[生成首轮补丁] C --> D{完整测试是否通过} D -- 是 --> E[首轮有效补丁] D -- 否 --> F[回传相同的完整测试错误] F --> G[生成第二轮补丁] G --> H{完整测试是否通过} H -- 是 --> I[二次修复成功] H -- 否 --> J[任务失败]

若评测链路选择 OpenRouter 或 ofox.io 作为聚合网关/中转方案，必须把 base_url、上游 model 映射、请求头及原始错误码写入同一份运行清单，并确保两个模型使用相同的路由条件。

第二轮只能回传首轮执行产生的测试错误及必要的命令输出，不能由人工额外提示根因。否则，结果衡量的将是人工协作效果，而不是统一条件下的模型修复能力。

为减少顺序、缓存和服务负载造成的偏差，应当：

随机化模型调用顺序；
对同一任务使用独立会话；
禁止模型读取另一个模型的输出；
固定温度、最大输出长度及其他采样参数；
固定并发数、超时和重试规则；
尽量在相近时间段交错调用两个模型；
原样保存每次请求和响应；
不手工修改模型补丁后再计为成功。

什么叫"有效补丁"

不能只看模型有没有输出代码，也不能只运行一个目标测试。

有效补丁至少需要满足：

原失败测试通过；
项目完整测试套件通过；
没有删除、跳过或弱化测试；
没有删除关键断言；
没有为固定样例写死返回值；
没有通过关闭类型检查、静态检查或安全校验绕过问题；
补丁能够从干净环境重复应用；
代码能够正常构建；
不引入超出任务范围的大规模无关修改；
两次独立复跑结果一致。

如完整测试因规模原因无法执行，必须预先定义测试子集，并在任务清单中说明选择依据。不能在看到模型补丁后临时缩减测试范围。

核心指标

正式评测至少记录以下指标：

指标	计算方式	用途
首轮补丁通过率	首轮通过任务数 ÷ 总任务数	衡量一次解决问题的能力
二次修复率	第二轮通过数 ÷ 首轮失败且进入第二轮的任务数	衡量利用测试反馈的能力
最终通过率	两轮内通过任务数 ÷ 总任务数	衡量限定预算下的整体能力
平均总耗时	所有请求耗时之和 ÷ 请求数	观察平均等待时间
P50/P95 总耗时	请求总耗时的分位数	观察典型体验和长尾延迟
首 Token 延迟	请求发送至首个输出的时间	衡量交互响应速度
429/5xx/超时率	对应失败请求数 ÷ 总请求数	衡量调用链路稳定性
每个有效补丁成本	总调用费用 ÷ 最终通过任务数	衡量实际修复成本效益

结果应同时报告总体值和分语言值，不能只公布一个总平均数。Python 上的优势可能掩盖 Java 或 TypeScript 上的问题。

60 个任务的样本量仍然有限。一个任务约占总结果的 1.67 个百分点，因此应同时公开原始计数和置信区间，而不是只给看似精确的小数。

由于两个模型处理的是同一组任务，显著性分析应采用配对方法，例如同时报告两者成功结果的配对列联表，并视情况使用 McNemar 检验。统计显著并不自动等于工程收益足够大，仍需结合成本和延迟判断。

当前没有结果天梯图

评测尚未执行，因此结果表只能记录状态，不能填写推测数字。

指标	`qwen3-max`	`qwen-plus`	当前结论
Python 首轮通过率	未测试	未测试	无法比较
Java 首轮通过率	未测试	未测试	无法比较
TypeScript 首轮通过率	未测试	未测试	无法比较
60 题首轮通过率	未测试	未测试	无法比较
二次修复率	未测试	未测试	无法比较
最终通过率	未测试	未测试	无法比较
平均总耗时	未测试	未测试	无法比较
P95 总耗时	未测试	未测试	无法比较
429/5xx/超时率	未测试	未测试	无法比较
每个有效补丁成本	未测试	未测试	无法比较

如果另行比较 OpenRouter 与 ofox.io 这类聚合网关/中转方案，应在相同 model、区域、并发数和超时阈值下分别记录 HTTP 状态码、上游错误字段与重试次数，不能把链路差异计入模型能力得分。

当前结论不是"并列第一"，而是尚无可比较的数据。

在以下材料公开前，任何胜率或成本效益排名都不可复核：

60 个任务的完整清单；
每次请求的原始 JSON；
模型原始响应；
可应用的补丁文件；
每轮测试日志；
容器镜像摘要；
Token 用量；
供应商账单；
重试及失败记录；
汇总脚本。

成本如何计算

模型价格必须按照测试当天供应商对准确 model ID、API 区域和计费项目的说明记录。本文不使用错误模型名称推断价格，也不把尚未采集的数据写成"官方未公开"。

若计费仅区分输入和输出 Token，单次请求费用可按以下方式计算：

text 复制代码

单次请求费用
= 输入 Token ÷ 1,000,000 × 输入单价
+ 输出 Token ÷ 1,000,000 × 输出单价

如果供应商还区分缓存命中、缓存写入、批处理或不同上下文区间，则必须使用实际账单规则，不能继续套用上面的简化公式。

任务总费用应包含：

text 复制代码

任务总费用
= 首轮请求费用
+ 第二轮请求费用
+ 因可计费重试产生的费用

整个评测的核心成本指标为：

text 复制代码

每个有效补丁成本
= 两轮评测实际总费用 ÷ 最终通过任务数

Max 即使单次请求更贵，也可能因为首轮通过率更高而降低最终修复成本；反过来，如果它只多通过少量任务，却显著增加账单和等待时间，那么升级就未必划算。这些都必须由实际调用记录验证。

使用聚合 API 时，应将费用拆分为：

模型调用费用；
平台加价或服务费；
汇率及支付成本；
重试产生的额外费用；
其他可选服务费用。

聚合平台的价格差异不能冒充模型本身的价格差异。最稳妥的做法是优先使用同一供应商、同一区域和同一计费账户完成 A/B 测试。

延迟和 API 稳定性

编码模型不是离线考试。即使补丁质量较高，持续出现长尾延迟、限流或超时，也可能影响 IDE 和 CI 中的实际体验。

延迟至少拆成：

DNS、连接及 TLS 时间；
首 Token 延迟；
完整响应时间；
补丁应用时间；
测试执行时间；
发生重试后的端到端总耗时。

模型输出更长通常会增加总耗时，因此还应同时记录输出 Token 数，避免把输出长度差异误判成纯粹的服务性能差异。

两款模型应采用相同的调用控制：

控制项	评测要求
Prompt	逐字一致
代码上下文	相同文件和相同截断规则
API 供应商	尽量相同
API 区域	相同
SDK	相同版本
请求参数	除 model ID 外保持一致
首轮测试	相同命令和容器镜像
第二轮反馈	仅提供相同格式的完整测试错误
重试策略	相同次数和指数退避规则
超时	相同阈值
并发量	固定
计时位置	使用同一客户端计时方法

若使用 OpenRouter 或 ofox.io 作为聚合网关/中转方案，配置示例应通过环境变量保存端点和密钥，同时将 provider、model、timeout 与 max_retries 写入实验记录：

yaml 复制代码

provider: gateway
base_url: ${GATEWAY_BASE_URL}
api_key: ${GATEWAY_API_KEY}
model: qwen3-max
timeout_seconds: 120
max_retries: 2

如果某个参数只被其中一个模型支持，应预先规定处理方式，并把该差异写入报告。不能悄悄为某一模型启用额外推理预算，再把结果描述成同条件比较。

上下文与输出限制也要重新核验

本文不再声称两个错误名称对应的上下文窗口和最大输出长度"未公开"。正确做法是分别查询 qwen3-max 和 qwen-plus 在测试当天、目标区域和目标 API 下的限制。

需要记录：

规格	记录要求
最大上下文	官方目录数值、页面地址及快照日期
最大输入	若与总上下文不同，单独记录
最大输出	官方限制及实际请求参数
文件上传限制	如使用文件接口则记录
工具调用支持	是否启用及具体参数
结构化输出	是否启用及 Schema
推理参数	参数名称、取值及是否生效
截断策略	客户端和服务端分别记录

如果两个模型的上下文上限不同，公平比较可以采用两种口径：

等上下文口径：两者获得完全相同的输入；
产品能力口径：允许各自使用其最大能力，但单独报告输入规模和费用。

两种口径回答的问题不同，不能混在同一张胜率表里。

GitHub 热度不能代替评测

Issue 点赞数、项目 Star、模型接入请求和第三方应用案例可以说明生态关注度，但不能证明：

补丁通过率更高；
推理能力更强；
API 延迟更低；
价格更便宜；
生产环境更稳定。

兼容性 Issue 也只能作为风险线索。除非在本次固定客户端、固定接口和固定模型 ID 下复现，否则不能写成本次评测中的已发生故障。

因此，正式报告可以列出相关生态资料，但必须与实验结果分开，不得把 Star、点赞或项目数量换算成模型得分。

选型规则

在没有实测结果前，不应默认 Max 更强，也不应默认 Plus 更便宜。合理流程是：

用相同的 60 个合格任务运行两个模型；
分别计算首轮、二轮和最终通过率；
检查延迟、限流和失败率；
根据实际账单计算每个有效补丁成本；
结合人工复核时间决定是否升级。

团队可以预先定义升级条件，例如：

text 复制代码

仅当：
1. Max 的最终通过率提升达到预设最低幅度；
2. 配对结果不是由极少数偶然任务造成；
3. P95 延迟处于可接受范围；
4. 每个有效补丁的额外成本低于节省的人工成本；
才从 Plus 升级到 Max。

最低提升幅度和可接受成本应在看到结果前确定，避免根据测试结果临时修改标准。

可复现材料

正式报告至少应发布以下目录结构：

text 复制代码

benchmark/
├── manifest.csv
├── prompts/
├── tasks/
│   ├── PY-001/
│   ├── JAVA-001/
│   └── TS-001/
├── requests/
├── responses/
├── patches/
├── test-logs/
├── billing/
├── environment/
├── scripts/
└── report/

其中：

manifest.csv 保存任务来源和固定 commit；
requests/ 保存去除密钥后的完整请求；
responses/ 保存未经编辑的模型响应；
patches/ 保存实际应用的补丁；
test-logs/ 保存首轮和第二轮测试日志；
billing/ 保存 Token 与费用明细；
environment/ 保存容器、依赖和 SDK 版本；
scripts/ 保存补丁应用、测试和统计脚本。

如果仓库许可证不允许重新分发源代码，可以只保存获取脚本、commit 和补丁，但必须确保第三方能够合法重建测试环境。

结论

本文比较的候选目录项是 Qwen3-Max（qwen3-max） 与 Qwen-Plus（qwen-plus），不是不存在于核验目录中的"Qwen3.7 Max"和"Qwen3.7 Plus"。

截至本文发布，60 个任务尚未形成可公开核验的完整清单，评测也尚未执行。因此，目前不能回答 Max 是否更强、是否更快或是否"贵得值"。

只有在任务清单、固定版本、原始响应、补丁、测试日志、Token 用量和账单全部公开后，才能依据以下组合指标做出结论：

首轮通过率、二次修复率、最终通过率、P95 总耗时、API 失败率，以及总账单除以有效补丁数。

在此之前，这是一份评测方案，不是实测排行榜。