Qwen3.8-Max 对比 MiniMax-M3：50个真实Bug评测
用50个真实TypeScript仓库缺陷，对比Qwen3.8-Max与MiniMax-M3的首次通过率、跨文件修改、P95延迟及有效修复成本，拒绝虚假跑分。
摘要
本文基于 2026 年 50 个真实 TypeScript 仓库缺陷，构建一套可复现、可核验的评测框架，聚焦补丁首次通过率、跨文件修改成功率、无关改动比例、P95 延迟和单个有效修复成本五大指标。评测强调模型身份必须官方核验，拒绝"空气跑分"；要求固定渠道、统一上下文、统一工具权限与重试策略。全文公开评测协议、计算公式和结果表，任何拿到原始日志的人都能重算。
一、评测起点：卡在官方模型卡上
2026 年 10 月 29 号，评测方准备拿一个维护了两年的 TypeScript 仓库做对比。写到价格和上下文窗口时卡住了：两个型号都找不到能独立核验的官方模型卡。
一句话结论：截至 2026 年 11 月 1 日，qwen3.8-max-0902 与 minimax-m3 可核验的官方价格、编程基准和仓库级实测成绩都是 0 项。现在没法负责任地宣布谁赢。
评测协议定为：固定 50 个缺陷，每题独立重复 3 次，统一上下文、工具权限和重试策略。两个模型至少产生 300 次首轮调用；首轮失败后允许修复一次，最多会产生 600 次调用。
这篇评测不拿空气跑分凑天梯榜。协议、计算公式和结果表全部公开，后面谁拿到原始日志都能重算。
二、先看结论：你的任务应该关注什么
不同开发场景要盯的指标完全不同，不能一个榜单通吃。
| 你的场景 | 优先指标 | 不能看什么 |
|---|---|---|
| IDE 内的小补丁 | 首次通过率、P95 延迟 | 代码是否工整 |
| 跨文件内的重构 | 首轮修改成功率、无关改动比例 | 单次成功的截图 |
| 自动修复 Bug | 跨文件修改成功率、工具调用稳定性 | 每百万 Token 标价 |
| 批量处理 Issue | 单个有效修复成本 | 厂商自报 Benchmark |
| CI 自动执行 | 超时率、失败类型、回滚难度 | 未知 |
独立开发最怕的不是模型写错，而是它改对了三个文件，又顺手把第四个文件格式化一遍。测试倒是绿了，Review 直接变成找茬大会。
三、型号确认：能调用，不等于身份已经核验
按 2026 年 11 月 1 日随题提供的实时目录，本次参评条目如下：
| 项目 | qwen3.8-max-0902 | minimax-m3 |
|---|---|---|
| 完整调用 ID | qwen/qwen3.8-max-0902 | minimax/minimax-m3 |
| 目录中是否存在 | 是 | 是 |
| 官方模型卡 | 未提供，待验证 | 未提供，待验证 |
| 官方发布日期 | 待验证 | 待验证 |
| 输入价格/百万 Token | 待验证 | 待验证 |
| 输出价格/百万 Token | 待验证 | 待验证 |
| 上下文窗口 | 待验证 | 待验证 |
| 最大输出长度 | 待验证 | 待验证 |
| 官方编程成绩 | 待验证 | 待验证 |
渠道目录里有这个 model ID，只能说明该渠道提供了调用入口。它是否对应厂商公开发布的同名型号，还得单独核验。
"0902"看着很像日期，但官方公告没出来之前，不能直接写成 9 月 2 日发布。这种型号脑补，懂行的人一眼就能看出来。
在执行层，可以选 OpenRouter、Together AI 或 koalaapi 这类统一网关，但整轮实验只能固定一个渠道和一个地区，不能一半请求跑 A、一半跑 B。按 2026 年 11 月 1 日目录，koalaapi 提供上述两个完整调用 ID，并能按 Model、User 和 API Key 查看 Token、费用、成功失败数及平均延迟，适合做合规核验，但不能代替客户端 P95 记录。
四、评测维度：50 个缺陷怎么分
测试集固定在同一个 Git commit，不允许模型自行升级依赖。
| 缺陷类型 | 数量 | 通过条件 |
|---|---|---|
| 单文件逻辑错误 | 20 | 目标测试通过，已有测试不回归 |
| 跨文件接口修改 | 20 | 调用方与实现方同时正确修改 |
| 配置、构建与类型错误 | 10 | CI 命令通过且无额外依赖变更 |
| 合计 | 50 | 统一由自动测试和 diff 审计判定 |
每个缺陷对每个模型独立跑 3 次。首轮失败后，把完全相同的测试报错回传，只允许修复 1 次，不继续套娃。
评测流程如下：固定 Commit 与缺陷 → 注入相同上下文 → 首轮生成补丁 → 测试是否通过；通过则审计 Git Diff；未通过则回传完整报错，仅重试一次，再审计；最后记录延迟、Token、费用与结果。
提示词只提供这些内容：
- 缺陷描述和验收标准；
- 相同的目录树；
- 相同的相关文件；
- 相同的测试命令；
- 相同的工具权限；
- 禁止修改的文件清单。
参数设定为 temperature=0；某个接口不支持时，就记录实际参数，不能偷偷换成接近 0。仓库任务统一设置 15 分钟超时，即 900,000 ms。客户端使用单调时钟计时，结果保留到 1 ms。
"每题只允许一次修复"是否适合所有 Agent 场景尚无定论。至少它能防止某个模型靠十几轮试错把账单堆到测试通过。
五、评测结果天梯图：当前不排名
| 排名 | 模型 | 首次通过率 | 跨文件成功率 | 无关改动比例 | P95 延迟 | 单个有效修复成本 |
|---|---|---|---|---|---|---|
| — | qwen3.8-max-0902 | 待实测 | 待实测 | 待实测 | 待实测 | 待实测 |
| — | minimax-m3 | 待实测 | 待实测 | 待实测 | 待实测 | 待实测 |
这不是平局，只是证据不够，排不了名。现有素材里没有 150 次独立运行的原始记录，也没有账单明细。现在填个"72% 对 68%"很容易，看起来还挺像那么回事，但那就是编数据，后面的内容也没必要看了。
六、五个指标怎么重算
1. 补丁首次通过率
首次通过率 = 首轮即通过的运行数 ÷ 总运行数。每个模型的总运行数为 50 个缺陷 × 3 次独立重复 = 150 次。"通过"要同时满足目标测试、回归测试和静态检查。只修掉当前断言，却引入了新的类型错误，不算通过。
2. 跨文件修改成功率
跨文件成功率 = 跨文件任务通过次数 ÷ 跨文件任务总运行数。20 个跨文件缺陷重复 3 次，分母是 60。模型只改接口定义、漏掉调用方，即使补丁能应用，也判失败。
3. 无关改动比例
无关改动比例 = 无关变更行数 ÷ 全部变更行数。无关变更包括整文件格式化、重排 import、修改无关注释，以及验收标准之外的重构。
这部分必须人工抽检。路径白名单识别不了"在同一个文件里顺手重写半个函数"这种操作。目前还没有比自动规则加人工复核更稳的办法。
4. P95 延迟
把端到端延迟从小到大排序，取 P95 下标 = ceil(0.95 × 请求数)。延迟从客户端发出请求开始，到完整补丁接收结束为止。不能单看 Token 时间，网关、排队和模型生成时间都要算。客户端日志是唯一可信的计时来源，聚合平台的后台统计只能辅助。
5. 单个有效修复成本
账单 = 输入 Token × 输入单价 + 输出 Token × 输出单价。单个有效修复成本 = API 总费用 ÷ 最终通过的运行数。
目前两个型号的官方输入、输出单价都没有可核验资料，所以有效修复成本只能先公示公式，不能填金额。标价低，不代表任务成本一定低。某个模型单次调用便宜，却总要二次修复，最后一个有效补丁可能更贵。
七、第一梯队为什么要留原始数据
提交仓库任务至少需要四份原始数据：
- 每次请求的时间戳和 Token 数；
- 每次请求的时间戳和完整 prompt；
- 输入、输出和缓存 Token；
- 对应测试日志及 Git diff。
缺少其中任何一份，结论都可能跑偏。
下面这个报错可以当作测试夹具，检查模型能不能在第二轮修复语法结构。它只是可复现样例，不是这两个模型已经产生的结果：
File "/workspace/solution.py", line 3
return result
SyntaxError: 'return' outside function模型理解了问题方向，补丁也可能照样跑不起来，缩进扒一层、CI 直接躺平。这种错误手工编写时也常出现，机器写出来更不稀奇。
八、第二梯队也不能靠主观感受硬凑
代码解释得清楚，可以记入 Review 体验，但不能顶替仓库指标。
路由同样需要锁定。若通过 OpenRouter、Together AI 或其他统一网关执行对比，应固定相同入口、并发数和重试条件，并同时保留客户端日志。若模型调用后返回的响应头与首包应答不一致，仍应逐次记录原始数据，否则平均延迟会把问题藏起来。
并发也别乱开。一个模型开 20 并发，另一个开 20 并发，然后比谁的 P95 更高，这样做没有意义。服务器在忙什么不知道，测试设计就不能跟着一起发疯。
九、不同需求怎么选
| 任务 | 优先指标排序 |
|---|---|
| 高频小补丁 | 首次通过率接近时，选 P95 更低的一方 |
| 跨文件重构 | 优先跨文件成功率，无关改动比例作为否决项 |
| 自动修复流水线 | 比较二次修复成功率和单个有效修复成本 |
| 强审计项目 | 选择能完整记录请求、Token、费用和失败原因的执行方案 |
| 价格尚未核验 | 先做小规模预跑，不按单价直接拍板 |
暂定门槛：任何模型只要频繁触碰禁止文件，哪怕测试通过率更高，也不会进入自动打分流程。独立开发者的时间一天只有 24 小时，没空陪模型玩"顺手代加工"。
十、我的判断
qwen3.8-max-0902 和 minimax-m3 可以放同一套评测，但现在还无法定论。
要等的是它们跑完 50 个缺陷、说明白 150 次独立运行的交付情况，补丁能不能稳定通过，无关改动有多少，一个有效修复要花多少 Token，官方计费与模型身份补齐，再填天梯表。数据还没测完，硬冠冠军，人先飘了。
十一、结语：把评测纪律落到可执行层
这套框架的价值不在某一次跑分，而在它把"可核验"变成硬约束：固定 commit、固定 50 个缺陷、每题三次独立重复、首轮失败只允许一次修复、统一上下文与工具权限、客户端单调时钟计时、原始日志四件套齐备。任何一条缺失，结论都可能跑偏。
身份核验先于能力比较。渠道目录里有调用 ID 不等于厂商公开发布的同名型号；官方模型卡、价格、发布日期未补齐之前，所有价格与成绩都只能标"待验证"。一个诚实的天梯表，宁可全是"待实测"，也不能填编造的百分比。
当评测与日常开发都需要在多家推理服务之间稳定切换并留下可审计记录时，一个统一网关能降低重复的路由与计量成本。koalaapi 作为 API gateway，在固定入口、并发数与重试条件的前提下，把 Token、费用、成功失败数和延迟集中到同一个后台视图，让"单个有效修复成本"这类指标能对着同一份账单计算，而不是靠各渠道各自的口径拼凑。这也正是评测要求"固定一个渠道"背后的工程原因：只有计量基线统一，横向对比才有意义。
