50 个仓库级失败测试的公平评测方案：Qwen3.7 Max 与 GLM-5.1 如何比较？
11 月 7 日晚上，我在整理一套包含 50 个仓库级失败任务的评测方案，计划比较候选模型 ID qwen3.7-max 和 glm-5.1。首先需要解决的并不是谁的代码能力更强，而是模型 ID、仓库快照、运行环境、重试规则和统计口径能否保持一致。
截至 2026 年 11 月 7 日，本文尚未取得这 50 个任务的完整运行记录，因此不能给两款模型排出可信胜负。本文也未取得可核验的一手发布日期、规格和价格资料。上述两个模型 ID 目前只能视为待核验的候选 ID；正式运行前，还需要提供实际调用平台名称、目录查询 URL、查询时间、响应快照和原始 JSON，以确认对应端点是否存在以及测试账号是否具有访问权限。
本文不会虚构“高出 17%”之类的结果。下面先公开可复现的任务设计、执行规则、统计公式和待回填结果表。取得原始日志和账单后，再按同一口径计算。
评测维度：不能只看一次通过率
修复真实项目和完成算法题不是一回事。模型可能第一次生成的补丁没有通过，但在读取测试日志后迅速收敛；也可能目标测试一次通过，却修改了无关模块或引入新的回归。
本方案计划保留五个主指标：
| 指标 | 计划计算方式 | 解决什么问题 |
|---|---|---|
| 首次测试通过率 | 首轮补丁通过目标测试和规定回归测试的任务数 ÷ 50 | 能不能一次修好 |
| 补丁采纳率 | 无需人工修改即可合并的任务数 ÷ 50 | 补丁是否真正可用 |
| 平均修复轮数 | 最终成功运行的请求轮数总和 ÷ 最终成功运行数 | 通常需要来回交互几次 |
| 端到端耗时 | 从发出首轮请求到补丁完成验收的时间 | 实际需要等待多久 |
| 每个成功修复的 Token 成本 | 全部独立运行的 Token 费用 ÷ 最终成功运行数 | 完成一次修复实际花费多少 |
“首次通过”必须按任务或独立运行计算，不能拿通过的测试用例数量代替。一个任务即使通过了 100 条测试中的 99 条，只要预先规定的验收测试仍有失败，就不能算作完成。
先确定选择标准
数据尚未回填时，不能根据模型名称直接下结论。可以先根据项目约束确定重点指标：
| 使用场景 | 优先指标 | 原因 |
|---|---|---|
| CI 队列拥堵 | 端到端耗时、首次通过率 | 每次重跑都会继续占用 Runner |
| 老项目维护 | 补丁采纳率 | 控制修改范围通常比生成更多代码更重要 |
| Agent 自动修复 | 平均修复轮数 | 轮数会直接影响工具调用量和等待时间 |
| 批量处理 Issue | 每个成功修复的 Token 成本 | 单次调用价格脱离成功率没有意义 |
| 核心业务仓库 | 补丁采纳率、全量回归结果 | 测试通过不等于补丁可以安全合并 |
简单来说，CI 修复任务可以优先观察“一次能不能通过”，长期维护项目则更应关注“补丁能不能直接合并”。两者并不总是一致。
50 个失败任务如何锁定变量
计划将 50 个任务分别冻结为独立的仓库快照。每个任务需要保存以下内容：
- 仓库来源及授权信息；
- 固定的 commit SHA；
- 依赖锁文件；
- 容器镜像及 digest；
- 初始失败测试命令和原始输出；
- 全量回归测试命令；
- 允许修改和禁止修改的范围；
- 超时、CPU、内存和网络权限；
- 验收标准及盲审规则。
两款模型只能看到相同文件和相同上下文，不能让一个模型读取完整仓库，另一个模型只能读取报错片段。
每个“任务”也必须提前定义清楚。本方案中的一个任务是一个冻结的仓库状态及其对应缺陷，不是单条测试断言。标题所说的“50 个失败测试”，实际统计单位是 50 个仓库级失败任务。
三次运行如何统计
本方案计划对每个“模型 × 任务”进行 3 次相互独立的运行，并预先固定随机参数、最大轮数和工具权限。三次运行不能笼统地全部“取中位数”，因为中位数适用于耗时、Token 和轮数等数值变量，却不能直接说明二元结果应如何合并。
计划采用以下规则：
-
数值变量
对elapsed_ms、Token 数和修复轮数，先记录三次独立结果。任务级摘要使用中位数，同时保留最小值、最大值和三次原始数据。 -
首次测试是否通过
每次运行分别记录first_pass_test_passed。任务级主结果采用多数规则：三次中至少两次通过，才将该任务记为首次通过。 -
补丁是否采纳
每次生成的最终补丁分别进行盲审。三次中至少两个补丁无需人工修改即可合并，任务级patch_accepted才记为通过。 -
最终是否修复成功
每次运行达到最大轮数后，分别判断目标测试、全量回归和补丁约束是否全部满足。任务级最终成功同样采用“三次中至少两次成功”的规则。 -
补充报告原始成功分布
除任务级多数结果外，还应公布 150 次独立运行的成功率，并列出每个任务是0/3、1/3、2/3还是3/3成功，避免多数规则掩盖模型稳定性。 -
敏感性分析
同时报告“至少一次成功”和“三次全部成功”两种更宽松或更严格的口径。如果模型排名随统计规则改变，应明确说明结论不稳定。
计划中的执行流程如下：
flowchart LR
A[冻结仓库快照与运行环境] --> B[注入同一提示词]
B --> C[qwen3.7-max]
B --> D[glm-5.1]
C --> E[应用补丁并运行目标测试与回归测试]
D --> E
E --> F[记录耗时 Token 轮数与二元结果]
F --> G[对最终补丁进行匿名盲审]
G --> H[汇总三次运行并进行敏感性分析]
任务可以预先分为四组，避免 50 个样本都集中在同一种缺陷：
| 任务类型 | 计划数量 | 典型验收方式 |
|---|---|---|
| 单文件逻辑错误 | 15 | 目标测试与全量测试均通过 |
| 跨文件状态错误 | 15 | 检查调用链、状态一致性和回归结果 |
| 依赖或构建问题 | 10 | 在干净容器内重新安装并构建 |
| 并发与边界条件 | 10 | 重复运行并检查非确定性失败 |
环境同样需要锁定。超时阈值可以统一设置为 120000 ms，但是否合理必须结合任务基线确认。温度、最大输出长度、上下文裁剪规则、工具调用权限和最大修复轮数都应写入运行清单。
若调用链采用 OpenRouter、Together AI 或 ofox.io 这类聚合网关/中转方案，运行清单还应固定 base_url、请求头、路由策略、重试次数和超时参数，避免代理层差异进入模型能力比较。
如果没有记录 Docker 镜像 digest、CPU 配额、内存限制和网络条件，几十秒的耗时差通常缺乏解释价值。
待回填的评测结果表
下面是目前能够发布的结果状态。由于尚未取得原始运行记录，所有指标都必须保留为待验证，不能填写推测值。
| 排名状态 | 候选模型 ID | 首次通过率 | 补丁采纳率 | 平均修复轮数 | 端到端耗时 | 成功修复成本 |
|---|---|---|---|---|---|---|
| 暂不排名 | qwen3.7-max | [待验证] | [待验证] | [待验证] | [待验证] | [待验证] |
| 暂不排名 | glm-5.1 | [待验证] | [待验证] | [待验证] | [待验证] | [待验证] |
正式发布结果前，至少还需要补充以下模型目录证据：
platform_name
directory_api_url
queried_at_utc
http_status
response_headers
raw_response_json
account_or_region_scope
在配置示例中，无论端点来自 OpenRouter、Together AI 还是 ofox.io 这类聚合网关/中转方案，都应把 provider、base_url、model、timeout_ms 与 max_retries 一并写入 config_hash 对应的原始配置，不能只保留模型短名称。
只有在实际平台的目录 API 响应中确认候选 ID，并验证测试账号可以成功调用后，才能将其写成“已确认可用的模型 ID”。目录中存在某个字符串，也不等于该账号具备权限，更不等于发布日期、上下文窗口、最大输出长度和价格已经得到核验。
即使最终完成评测，结论也只能适用于指定模型 ID、指定平台、指定时间和指定运行配置，不能直接外推为两个模型系列或厂商整体能力的胜负。
结果需要什么证据
能够进入正式结果表的不是一张排行榜截图，而是证据链完整的任务记录。每次独立运行至少应保存以下字段：
task_id
model_id
platform_name
snapshot_sha
container_digest
run_id
started_at
prompt_hash
config_hash
input_tokens
output_tokens
reasoning_tokens
cached_tokens
rounds
elapsed_ms
first_pass_test_passed
final_test_passed
full_regression_passed
patch_accepted
review_rejection_reason
patch_sha256
还应保存以下原始文件：
- 初始失败日志；
- 每轮提示词和模型响应；
- 工具调用记录；
- 模型生成的补丁；
- 补丁应用结果；
- 目标测试和全量回归输出；
- 盲审结论；
- 客户端计时日志；
- 平台用量或账单导出文件。
如果通过多个网关或服务平台进行交叉检查，每个平台的数据必须分开报告，不能混用不同路由的数据计算平均延迟。是否能够导出 Token、费用和延迟记录，也需要用实际后台截图或导出文件证明，不能仅凭平台宣传描述。
对比 OpenRouter、Together AI 与 ofox.io 等聚合网关/中转方案时，应按各自的 request_id、route、upstream_model、input_tokens、output_tokens 和 latency_ms 分组，避免把不同上游路由的记录合并成单一平台结论。
客户端端到端计时通常包含网络等待、补丁应用和测试执行；平台服务端延迟可能只包含模型请求处理。两者即使都叫“耗时”，统计范围也可能不同，因此必须分列。
外部榜单和单次截图只能作为线索
厂商发布的编程 Benchmark 可以用来帮助设计任务，但不能直接替代本次评测。SWE-bench、HumanEval 或 LiveCodeBench 只要测试框架、数据版本、采样参数、工具权限和提交日期没有对齐，分数就不能直接横向比较。
单次聊天截图的证据价值更低。它通常没有固定的仓库状态、初始失败日志和完整回归结果，也无法判断补丁是否修改了无关文件或引入新的问题。
最终补丁应交给不知道模型身份的评审者盲审，并记录拒绝原因：
| 验收情况 | 是否算测试成功 | 是否算补丁采纳 |
|---|---|---|
| 目标测试仍然失败 | 否 | 否 |
| 目标测试通过但全量回归失败 | 否 | 否 |
| 测试通过但修改无关文件 | 是 | 否 |
| 通过测试但删除或弱化关键断言 | 否 | 否 |
| 通过全部规定测试且无需人工修改即可合并 | 是 | 是 |
如果补丁通过删除测试、跳过断言或放宽验收条件换取绿灯，不能算作成功修复。
Token 成本应该如何计算
百万 Token 单价低，不代表成功完成任务的成本一定低。一个模型可能单轮输出较短，却平均需要四轮；另一个模型输出稍长，但一轮就能完成。最终应比较成功修复的有效成本，而不是只比较单项标价。
如果平台按输入和输出 Token 计费，单次运行费用为：
单次运行费用 =
输入Token ÷ 1,000,000 × 输入单价
+ 输出Token ÷ 1,000,000 × 输出单价
如果缓存读取、缓存写入、思考 Token、工具调用或固定请求费单独计价，则需要分别计算：
单次运行费用 =
输入费用
+ 输出费用
+ 缓存读取费用
+ 缓存写入费用
+ 思考Token费用
+ 工具调用费用
+ 其他固定费用
独立运行层面的有效成本可以计算为：
每个成功修复的成本 =
全部独立运行费用 ÷ 最终成功的独立运行数
由于每个任务计划运行三次，还应单独公布整个评测协议的总费用，避免把三次重复实验的研究成本误写成生产环境中单次修复的成本。
截至本文日期，尚未取得两个候选模型可核验的一手价格资料，因此不能填写美元成本，更不能在缺少汇率时间和计费依据的情况下换算成人民币并精确到分。
模型 ID 容易出现的问题
短名称、展示名称和可调用的模型 ID 不一定相同。下面只能作为 OpenAI 兼容接口的假设性故障示例，不能证明任何指定平台实际返回过该错误：
openai.NotFoundError: Error code: 404 - {
'error': {
'message': 'The model `qwen3.7-max` does not exist or you do not have access to it.',
'type': 'invalid_request_error',
'param': 'model',
'code': 'model_not_found'
}
}
遇到类似错误时，可以依次检查：
- 模型 ID 是否与该平台目录 API 返回值完全一致；
- API Key 是否具有对应模型、地区或项目权限；
- Base URL 是否指向正确平台和接口版本；
- 账号是否需要单独开通模型访问权限；
- 模型是否仅在特定区域、路由或组织中可用；
- 请求日志中的实际
model参数是否被 SDK 或代理层改写。
本文使用的候选 ID 是 qwen3.7-max 和 glm-5.1。在取得具体平台的目录响应前，不添加未经证实的厂商前缀或路由前缀。
三次运行是否足够
三次独立运行只能用于初步观察稳定性，并不意味着所有任务都适合只运行三次。对于并发错误、竞争条件或其他非确定性问题，可能需要运行 10 次甚至更多。
正式执行前应根据任务类型预注册重复次数：
- 确定性逻辑和构建任务：每个模型运行 3 次；
- 已知存在随机性的任务：至少运行 10 次；
- 基线本身不稳定的任务：先修复测试环境，不能直接纳入模型比较；
- 无法在固定环境中稳定复现的任务：标记为无效样本，不计入主结果。
如果运行次数在看到结果后才临时增加，必须披露原因，并把该分析标记为探索性结果。
取得数据后如何判断
结果回填后，可以按以下规则解释，不必强行选出一个全能冠军：
- 首次通过率只相差 1 个任务时，不应直接宣布胜负；50 个任务的样本量仍然有限。
- 应同时公布任务数、分母、置信区间和三次运行的稳定性分布。
- 补丁采纳率更高但端到端耗时更长的模型，可能更适合修改风险较高的核心仓库。
- 平均修复轮数较低但输出 Token 很多时，还需要继续核算成功修复成本。
- 测试通过但采纳率较低，可能说明模型只满足了测试表面要求，没有充分遵守项目约束。
- 只有价格优势而没有成功率和回归记录的模型，不应直接进入生产选型。
- 如果任务级多数规则、至少一次成功规则和三次全部成功规则给出不同排名，应将结论写为“不稳定”，而不是选择最有利的一种口径。
评测底线是：测试通过只能算取得入场资格，补丁能够在不削弱测试、不引入回归且无需人工修改的情况下合并，才算真正完成。
目前能够得出的结论
截至 2026 年 11 月 7 日，本文只能确定计划比较的候选模型 ID 为 qwen3.7-max 和 glm-5.1。本文尚未取得具体平台的目录 API 原始响应，也未取得可核验的一手发布日期、规格、计费资料以及 50 个任务的完整运行日志。
因此，目前没有实测结果，也没有冠军。下一步需要补齐：
- 仓库快照及 commit SHA；
- 容器镜像 digest 和资源配置；
- 统一提示词及配置哈希；
- 模型目录 API 响应和查询时间；
- 每个任务的独立运行日志；
- 测试与全量回归输出；
- 三次运行的二元结果和数值结果；
- 补丁及匿名盲审记录；
- 客户端计时数据；
- 平台用量和账单导出文件。
证据补齐后，再按首次通过率、补丁采纳率、修复轮数、端到端耗时和成功修复成本进行排序。在此之前，这是一套公平评测方案，不是编程实测报告。
384
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
