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