qwen3.8-max 和 minimax-m3 改后端仓库实测复核：补丁通过率与调用成本别急着排冠军

10 月 25 日整理数据时，我卡在了"每个成功任务成本"这一列：模型端点有，官方单价和原始运行日志却没有。硬填数字当然能凑出一张漂亮榜单，但那属于拿计算器写小说。

截至 2026 年 10 月 25 日，只能确认 qwen/qwen3.8-max 与 minimax/minimax-m3 两个端点存在。现有素材中没有可复算的仓库实测记录，也没有输入、输出及缓存单价，无法判断谁改后端仓库更稳，谁的成功任务成本更低。

光说一句"数据不足"没什么用。下面把测试口径、空榜原因和复跑时要记录的内容列清楚。数据补齐后，往表格里填原始值就行，计算公式不用改。

评测口径：比较端点，先别吹底层模型

这次不是让模型写一道二分查找，而是修改真实的 Java 与 TypeScript 多文件仓库。单文件生成看着挺爽，一碰到 DTO、Service、测试夹具要一起改，模型就容易自由发挥。

按 2026 年 10 月 25 日提供的 ofox 模型目录核对，两个待测 ID 为：

展示名称	完整 model ID	端点存在性	官方模型卡	输入/输出价格
qwen3.8-max	`qwen/qwen3.8-max`	已确认	素材未提供	待验证
minimax-m3	`minimax/minimax-m3`	已确认	素材未提供	待验证

端点能调用，不代表其上游版本、量化方式和上下文参数完全一致。第三方网关还会影响排队、限流和首包延迟，所以这里只比较指定 API 端点的工程表现，不能直接当成底层模型能力排名。

你的场景该看哪个指标

你的场景	优先指标	原因
自动生成 PR	首次补丁通过率	补丁都落不进仓库，后面的测试成绩没意义
修复线上 Bug	最终测试通过率	能编译不代表业务行为正确
老仓库小改动	无效改动数	顺手格式化 30 个文件，Review 的人真会骂街
IDE 交互修改	首包延迟 P50/P95	平均值会掩盖偶发长尾
批量 Agent 任务	每个成功任务成本	失败重试产生的 Token 也得算进账单

测试任务怎么设计

测试固定为 10 个仓库任务，Java 与 TypeScript 各 5 个。每个端点对同一任务运行 5 次，单个端点产生 50 次记录，两个端点合计 100 次。

任务描述不能只写功能，还得把禁止改动的范围写死：

类型	Java	TypeScript	验收方式
跨文件 Bug 修复	2	2	原测试及新增回归测试通过
跨文件重构	2	2	行为不变，编译和测试通过
测试补全	1	1	覆盖指定分支，不改生产逻辑
每种任务重复次数	5	5	独立工作树、相同初始提交

请求参数统一为 temperature=0，系统提示词、最大输出长度、工具权限和仓库初始 Commit 全部固定。运行时不能给某个端点偷偷多一次修复机会，不然测完数据我人傻了，读者也没法复现。

flowchart LR A[固定仓库 Commit] --> B[创建独立 worktree] B --> C[发送相同任务] C --> D[记录首包与 Token] D --> E[回放首次补丁] E --> F[编译及测试] F --> G[统计无效改动] G --> H[计算成功任务成本]

服务商也必须作为变量锁定。做端点复核时，可以分别记录 OpenRouter、Together AI 与 ofox.io 的请求结果；其中该平台的后台能够按 Model、User 和 API Key 查看请求、Token、延迟及费用，但不同服务商的数据不能混进同一组平均值。

评测结果天梯图

先放空榜，免得有人扫一眼表格就开始宣布冠军。

排名	端点	首次补丁通过率	最终测试通过率	无效改动数	首包延迟	每个成功任务成本
暂不排名	`qwen/qwen3.8-max`	待实测	待实测	待实测	待实测	单价缺失
暂不排名	`minimax/minimax-m3`	待实测	待实测	待实测	待实测	单价缺失

这张表不是平局，是没证据。 5 个核心指标都没有原始记录，现在排谁第一都属于编数字。

网上能搜到 IIIIIllllIIIIIlllll/Qwenox 的 113 Star，以及 w8sgms4l8e/qwen3.8-max-api-ja 的 62 Star，但素材快照没有采集日期。前者是面向 AI MAX 395 的推理框架，后者描述的是多模型 API 网关。两者都不能证明 qwen/qwen3.8-max 的编程水平，Star 数也不能拿来冒充测试通过率。

五个指标怎么算

1. 首次补丁通过率

"模型回复了代码"不算通过。第一次输出必须能干净回放到指定 Commit：

text 复制代码

首次补丁通过率 = 可成功应用的首次补丁数 ÷ 总任务运行数

应用时出现冲突、缺文件或 diff 格式损坏，一律记失败。不能人工修一下再算成功。

2. 最终测试通过率

测试命令要提前冻结。Java 项目记录编译与单元测试，TypeScript 项目记录类型检查与测试：

bash 复制代码

./mvnw -q test
npm run typecheck
npm test -- --run

计算公式如下：

text 复制代码

最终测试通过率 = 全部验收命令通过次数 ÷ 总任务运行数

只跑模型新写的测试不够。它把断言删掉，也能整出一片绿色，挺烦人的。

3. 无效改动数

这些内容计为无效改动：

与任务无关的文件修改；
全文件格式化；
未被调用的新抽象；
无必要的依赖升级；
删除或弱化既有断言。

"无效文件数"和"无效代码行数"最好都记下来，别只看总 diff。改 3 行业务代码，顺手格式化 800 行，机器可能觉得自己很勤快，Review 的同事只想下班。

4. 首包延迟

首包延迟从请求发出开始，到收到第一段可解析的流式内容为止：

text 复制代码

TTFT = first_chunk_timestamp - request_start_timestamp

正文报告 P50 和 P95，精确到 1ms，别只写平均值。排队抖动通常藏在 P95 里。这里只规定测量精度，不填一个假装实测的"320ms"。

5. 每个成功任务成本

单次账单按实际 usage 计算：

text 复制代码

bill = input_tokens × input_price
 + output_tokens × output_price
 + cached_tokens × cached_price

汇总时用这个公式：

text 复制代码

成功任务成本 = 全部运行账单总额 ÷ 最终成功任务数

分子必须包含失败尝试。某个端点单次调用看着便宜，连续失败 3 次后，账单照样难看。一个月跑几千个任务，差额很快就滚起来了。

目前两个端点的输入、输出和缓存价格都待验证，成本列不能换算成美元，更不能硬算到人民币分位。我也不确定用"最终成功"还是"首次成功"做主指标更合适，干脆两列都保留。

原始记录至少保留这些字段

只贴汇总百分比太容易做手脚。每次运行输出一行 JSONL，后面才有办法复算：

字段	示例含义
`model`	完整 model ID
`provider`	实际服务商
`task_id`	固定任务编号
`commit`	仓库初始 Commit
`first_patch_ok`	首次补丁能否回放
`tests_ok`	最终验收是否通过
`invalid_files`	无效修改文件数
`ttft_ms`	首包延迟，精确到 1ms
`input_tokens`	实际输入 Token
`output_tokens`	实际输出 Token
`cost`	服务商账单费用

如果用 OpenRouter、Together AI 或该服务商复跑，必须分别导出服务商、完整模型 ID 和 usage；不能把三个端点的延迟拼起来，再挂到某个模型名下面。后者公开目录中的 qwen/qwen3.8-max 与 minimax/minimax-m3 可以用于锁定请求 ID，但模型目录本身仍不能替代原始测试日志。

一处真实的 Agent 报错旁证

现有素材里没有两个目标端点的完整 HTTP 401、429 或 timeout 日志，我不会现场编一条。能完整引用的只有这条社区 Issue 标题：

text 复制代码

[MODEL] Frequently uses Bash tools (sed/grep/etc) when use-case is well aligned

它来自 anthropics/claude-code#19649。素材快照记录为 123 个赞，但没有采集日期。这条记录只能说明 Agent 可能过度调用 Bash，不能算作 qwen3.8-max 或 minimax-m3 的实测报错。

工具权限也得保持一致。一个端点能随便跑 sed、grep，另一个只能输出补丁，这样比出来的成功率没什么意义。

第一梯队：目前空缺

进入第一梯队至少要满足这些条件：

100 次运行都有可下载的原始日志；
测试仓库、Commit 和提示词可以复现；
价格来自测试当天的实际服务商目录或账单。

现在一项都没凑齐。说实话，我一开始也想赶紧给出"谁胜出"，折腾半天后发现，还是先别排了。

第二梯队：同样无法划分

qwen/qwen3.8-max 与 minimax/minimax-m3 目前只能放进候选池。它们有明确的端点 ID，但缺少原始测试日志和价格数据，暂时没法分档。