Kimi K2.6 与 Qwen3.7 Max：跨文件修复评测与成本核算方法（2026）

上周三，我准备让 Kimi K2.6 和 Qwen3.7 Max 处理一个维护了 6 年的 Java 项目：修改接口签名、补充测试，并修复 17 个编译错误。评测表格已经建好，核对价格时却遇到了问题：现有证据包里没有可独立核验的官方定价、模型卡、渠道响应快照和同环境评测记录。

TL;DR：截至 2026 年 10 月 27 日，本文掌握的材料不足以严谨判断 Kimi K2.6 和 Qwen3.7 Max 谁的成功成本更低。本文可核验的官方输入价格、输出价格、上下文长度和跨文件修复成功率均为空。真正应该比较的是"全部请求费用 ÷ 成功补丁数"，而不是单独比较每百万 Token 标价。

先看怎么选，别急着站队。

你的场景	当前建议	原因
正在做技术预研	两款模型运行同一任务集	现有资料不足以支持能力排名
需要马上报预算	暂缓给出固定金额	输入、输出单价均为 `[待验证]`
维护 Java、Python、TypeScript 旧项目	同时记录编译、测试和重试	单次生成成功不等于补丁可以合并
团队做模型选型	先锁定渠道，再比较模型	429、500 等错误可能来自接入层
只比较百万 Token 价格	不建议直接下结论	输出膨胀和重试可能反转结果

1. 型号与目录核验：真值表标签不等于各渠道通用 ID

本文统一比较以下两个型号：

Kimi K2.6：kimi-k2.6
Qwen3.7 Max：qwen3.7-max

这两个字符串来自本文输入材料附带的"可用 model ID 真值表"。相关核验记录如下：

核验项	记录
目录来源	本文输入材料附带的可用 model ID 真值表
核对日期	2026-10-27
相关响应快照	`kimi-k2.6, qwen3.7-max`
外部公开目录 URL	未随材料提供
厂商 API 响应	未随材料提供
带时间戳的第三方存档	未随材料提供
可独立验证程度	只能验证本文所用标签，不能证明任意渠道当前均可调用

这里必须区分三个概念：

本文的标准化模型标签 ：用于数据表、日志和评测报告，例如 qwen3.7-max。
渠道实际接受的 model 参数：由 OpenRouter、Together AI、ofox.io 或厂商 API 分别定义。
厂商内部版本号：可能与第三方渠道的名称、别名或发布时间不同。

模型 ID 是渠道命名空间中的标识，不存在天然跨渠道通用的"完整模型 ID"。因此，不能把某个渠道使用的 vendor/model 字符串直接复制到另一个渠道，也不能仅凭本文真值表断言某个渠道已经上架该型号。

正式评测前，应查询目标渠道的模型目录并保存原始响应。例如：

bash 复制代码

# ofox.io：是否开放该目录端点及鉴权方式，应以渠道文档为准
curl -sS https://api.ofox.io/v1/models \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  > "ofox-models-2026-10-27T120000Z.json"

# OpenRouter
curl -sS https://openrouter.ai/api/v1/models \
  > "openrouter-models-2026-10-27T120000Z.json"

# Together AI
curl -sS https://api.together.xyz/v1/models \
  -H "Authorization: Bearer $TOGETHER_API_KEY" \
  > "together-models-2026-10-27T120000Z.json"

每份快照至少应保存：

请求 URL；
UTC 查询时间；
HTTP 状态码；
响应头；
完整响应体；
响应文件的 SHA-256；
实际使用的渠道模型 ID。

如果渠道返回的 ID 与本文标签不同，应建立显式映射，而不是把渠道 ID 称为全平台通用的"完整模型 ID"。

公开资料同样有限。Doriandarko/kimi-2-6-code 是一个以 Kimi K2.6 为核心的终端编程 Agent，但仓库热度不能替代模型能力评测。其他持续更新的大模型评测仓库即使收录了大量模型，也只有在提供目标型号、固定版本、运行配置和原始结果时，才能作为可复现证据。

调用链路最好拆开分析：

flowchart LR A[同一批旧项目任务] --> B[固定提示词与工具] B --> C[已锁定的 API 渠道] C --> D1[Kimi K2.6] C --> D2[Qwen3.7 Max] D1 --> E[编译与测试容器] D2 --> E E --> F[Token、重试、费用和渠道错误记录] F --> G[每个成功补丁成本]

模型负责生成内容，渠道负责传输和计费，补丁能不能使用则交给编译器与测试框架验证。三者不能混在一起归因。

2. 核心参数对比：缺少证据的字段不猜

下面只记录本文证据包能够确认的内容。没有模型卡、定价页或渠道响应支持的字段，一律标记为待验证。

参数	Kimi K2.6	Qwen3.7 Max	核验状态
本文标准化标签	`kimi-k2.6`	`qwen3.7-max`	已由输入真值表确认
渠道实际 `model` 值	`[按渠道查询]`	`[按渠道查询]`	不可跨渠道推断
输入价格/百万 Token	`[待验证]`	`[待验证]`	未附官方定价页
输出价格/百万 Token	`[待验证]`	`[待验证]`	未附官方定价页
上下文窗口	`[待验证]`	`[待验证]`	未附官方模型卡
最大输出 Token	`[待验证]`	`[待验证]`	未附正式 API 文档
缓存输入计费	`[待验证]`	`[待验证]`	未附计费规则
思考 Token 计费	`[待验证]`	`[待验证]`	未附计费规则
工具调用支持	`[待验证]`	`[待验证]`	需按模型和渠道分别测试
多模态输入	`[待验证]`	`[待验证]`	缺少可核验说明
结构化输出	`[待验证]`	`[待验证]`	缺少可核验说明

这些参数不一定不存在，只是本文拿到的材料无法证明。

上下文窗口尤其容易被误传。第三方 README 可能互相引用，最终找不到原始模型卡；渠道还可能自行限制最大输入或输出。因此，应同时记录厂商上限、渠道上限和单次请求的实际限制。

3. Benchmark 解析：排行榜替代不了旧项目验收

现有材料没有提供两款模型在相同环境下的 SWE-Bench、GPQA、MMLU-Pro 或 HumanEval 成绩。后续即使找到厂商公布的数据，也应标注"厂商自报"或"是否独立复现"，不能直接把公开 Benchmark 分数当成你的仓库成功率。

Benchmark / 指标	Kimi K2.6	Qwen3.7 Max	能否据此排名
SWE-Bench	`[待验证]`	`[待验证]`	否
LiveCodeBench	`[待验证]`	`[待验证]`	否
HumanEval	`[待验证]`	`[待验证]`	否
GPQA	`[待验证]`	`[待验证]`	否
MMLU-Pro	`[待验证]`	`[待验证]`	否
中文综合评测	`[待验证]`	`[待验证]`	否
首个正文 Token 延迟 P50/P95	`[待验证]`	`[待验证]`	否
跨文件补丁一次成功率	`[待验证]`	`[待验证]`	否

更实用的办法是做仓库级验证。例如准备 24 个任务，Java、Python、TypeScript 各 8 个。每个任务最多允许 3 次修复，两款模型看到的文件、错误日志、系统提示词和测试命令必须相同。

记录项	计算方式	为什么要记
补丁应用率	可无冲突应用的补丁数 ÷ 任务数	排除格式错误或上下文错位
编译通过率	编译成功任务数 ÷ 任务数	排除语法和类型错误
测试通过率	全量测试成功任务数 ÷ 任务数	防止只修表面报错
一次成功率	首轮成功任务数 ÷ 任务数	衡量返工概率
平均重试次数	总重试次数 ÷ 最终成功任务数	重试会增加时间与 Token
平均输入量	总输入 Token ÷ 已计费请求数	观察上下文膨胀
平均输出量	总输出 Token ÷ 已计费请求数	观察输出膨胀
成功补丁成本	全部实际费用 ÷ 成功任务数	最终成本指标

这里的 24 是建议的实验规模，不是已经完成的结果，也不一定具有足够统计功效。正式评测前最好根据预期差异做样本量估算，并按语言、改动文件数、依赖复杂度和缺陷类型分层。

4. 定价分析与真实场景成本测算

本文材料无法核验两款模型的官方输入、输出价格，所以不能写"每百万 Token 多少钱"，也不能据此计算一个看似精确的人民币金额。

基础计算公式是：

text 复制代码

请求成本 =
  输入 Token ÷ 1,000,000 × 输入单价
+ 输出 Token ÷ 1,000,000 × 输出单价
+ 缓存、思考、工具或其他附加费用

对于仓库修复，应进一步计算：

text 复制代码

成功补丁成本 =
  评测期间全部实际请求费用
  ÷ 通过补丁应用、编译和全量测试的任务数

如果成功任务数为 0，就不应把结果写成 0 元，而应记为"无法计算"或正无穷。

当前价格表只能写成：

计费项	Kimi K2.6	Qwen3.7 Max	数据日期
输入单价	`[待验证]`	`[待验证]`	2026-10-27
输出单价	`[待验证]`	`[待验证]`	2026-10-27
缓存读取单价	`[待验证]`	`[待验证]`	2026-10-27
思考 Token	`[待验证]`	`[待验证]`	2026-10-27
失败请求是否计费	`[待验证]`	`[待验证]`	2026-10-27
工具调用附加费用	`[待验证]`	`[待验证]`	2026-10-27
结算币种与税费	`[待验证]`	`[待验证]`	2026-10-27

三个开发场景的测算模板如下。人民币金额应按账单结算规则和指定汇率换算，不能自行编造汇率。

场景	请求输入	请求输出	成功数	人民币成本
单个跨文件 Bug	账单导出值	账单导出值	编译且测试通过数	`¥[待填]`
24 个旧项目任务	两款分别汇总	两款分别汇总	各自成功任务数	`¥[待填]`
每月 300 个修复任务	月度总量	月度总量	月度成功补丁数	`¥[待填]`

假设 A 模型单次账面费用更低，但平均需要重试 2 次；B 模型单次费用更高，却能一次通过，那么 A 的成功成本完全可能更高。最终差多少，要看原始请求日志和账单，而不是宣传页。

OpenRouter、Together AI、ofox.io 和厂商 API 可以作为候选接入路径，但目标型号是否上架、使用什么 ID、如何计费，都应分别查询。评测时必须记录渠道、渠道模型 ID、失败率和账单字段，不能把不同渠道的结果直接合并。

5. API 调用：基础、流式与完整工具调用闭环

下面用 OpenAI Python SDK 演示兼容接口。示例 base_url 为 https://api.ofox.io/v1。

需要注意：代码中的 kimi-k2.6 和 qwen3.7-max 来自本文真值表；运行前仍应通过目标渠道目录确认它们是否就是该渠道实际接受的 model 值。

python 复制代码

from openai import OpenAI

c = OpenAI(
    api_key="YOUR_KEY",
    base_url="https://api.ofox.io/v1",
)

5.1 基础调用

python 复制代码

messages = [
    {
        "role": "user",
        "content": "修复仓库中的跨文件类型错误，并输出 unified diff。",
    }
]

r = c.chat.completions.create(
    model="kimi-k2.6",
    messages=messages,
)

print(r.choices[0].message.content)

if r.usage:
    print(
        "prompt_tokens =", r.usage.prompt_tokens,
        "completion_tokens =", r.usage.completion_tokens,
    )

5.2 切换到 Qwen3.7 Max

切换模型后必须重新发起请求，不能继续读取上一次 Kimi 响应的 usage：

python 复制代码

MODEL = "qwen3.7-max"

qwen_r = c.chat.completions.create(
    model=MODEL,
    messages=messages,
)

print(qwen_r.choices[0].message.content)

if qwen_r.usage:
    print(
        "prompt_tokens =", qwen_r.usage.prompt_tokens,
        "completion_tokens =", qwen_r.usage.completion_tokens,
    )

这样读到的 qwen_r.usage 才属于新的 Qwen3.7 Max 请求。

5.3 流式输出

流式输出适合测量首个事件时间和首个正文 Token 时间，但二者不能混为一谈。首个事件可能只包含角色、空增量或元数据。

python 复制代码

stream = c.chat.completions.create(
    model=MODEL,
    stream=True,
    messages=[
        {
            "role": "user",
            "content": "修复给定错误并输出 unified diff。",
        }
    ],
)

for event in stream:
    delta = event.choices[0].delta
    if delta.content:
        print(delta.content, end="", flush=True)

如果渠道支持在流式响应中返回 usage，还应按照其文档启用相关参数；否则应从账单或请求日志中补齐 Token 数据。

5.4 Function Calling 完整闭环

OpenAI 风格的 Function Calling 不会替客户端执行本地工具。模型只会生成 tool_calls 和参数。客户端必须完成以下步骤：

读取模型返回的 tool_calls；
校验并解析参数；
在本地执行工具；
以 role="tool" 回传执行结果；
再次请求模型，让它基于工具结果生成最终回答。

下面的示例只允许模型在预先批准的测试命令中选择，避免直接执行模型生成的任意 Shell 命令：

python 复制代码

import json
import subprocess

MODEL = "qwen3.7-max"

TEST_COMMANDS = {
    "unit": ["pytest", "-q", "tests/unit"],
    "all": ["pytest", "-q"],
}

def run_tests(target: str) -> dict:
    if target not in TEST_COMMANDS:
        return {
            "ok": False,
            "error": f"unsupported target: {target}",
        }

    completed = subprocess.run(
        TEST_COMMANDS[target],
        cwd="/path/to/repository",
        capture_output=True,
        text=True,
        timeout=300,
        check=False,
    )

    return {
        "ok": completed.returncode == 0,
        "returncode": completed.returncode,
        "stdout": completed.stdout[-12000:],
        "stderr": completed.stderr[-12000:],
    }

tools = [
    {
        "type": "function",
        "function": {
            "name": "run_tests",
            "description": "运行仓库中预先批准的测试命令",
            "parameters": {
                "type": "object",
                "properties": {
                    "target": {
                        "type": "string",
                        "enum": ["unit", "all"],
                    }
                },
                "required": ["target"],
                "additionalProperties": False,
            },
        },
    }
]

messages = [
    {
        "role": "user",
        "content": "请选择合适的测试范围并调用 run_tests，然后总结结果。",
    }
]

# 第一次请求：检查模型是否正确生成工具调用名称及参数
first = c.chat.completions.create(
    model=MODEL,
    messages=messages,
    tools=tools,
    tool_choice="auto",
)

assistant_message = first.choices[0].message

if not assistant_message.tool_calls:
    raise RuntimeError("模型没有生成 tool_calls，不能证明工具调用流程有效")

messages.append(assistant_message.model_dump(exclude_none=True))

# 客户端本地执行每一个工具调用
for tool_call in assistant_message.tool_calls:
    if tool_call.function.name != "run_tests":
        tool_result = {
            "ok": False,
            "error": f"unknown tool: {tool_call.function.name}",
        }
    else:
        try:
            arguments = json.loads(tool_call.function.arguments)
            tool_result = run_tests(**arguments)
        except Exception as exc:
            tool_result = {
                "ok": False,
                "error": str(exc),
            }

    # 将本地执行结果回传给模型
    messages.append(
        {
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(tool_result, ensure_ascii=False),
        }
    )

# 第二次请求：模型基于真实工具结果生成最终回答
final = c.chat.completions.create(
    model=MODEL,
    messages=messages,
    tools=tools,
)

print(final.choices[0].message.content)

这个实验验证的是：

模型是否生成了正确的工具名称；
参数是否符合 JSON Schema；
客户端能否成功执行本地工具；
渠道能否正确传递 tool_calls 和 role="tool" 消息；
模型能否根据工具结果继续回答。

不能把上述过程写成"模型执行了测试"。真正执行测试的是客户端进程。

不同渠道应分别建立实验标签。兼容接口接受 tools 参数，不代表底层模型一定会生成有效的 tool_calls；返回 HTTP 200，也不代表整个工具调用闭环已经完成。

错误日志同样需要原样保存。例如：

text 复制代码

Sorry, your request failed. Please try again.

这类错误如果没有模型名、请求 ID、渠道响应和底层错误码，就不能归因于 Kimi K2.6 或 Qwen3.7 Max。HTTP 500 也只能先说明调用链路发生故障，不能直接判定为模型能力失败。

6. 五类典型应用场景

两款模型都可以在以下任务上做 A/B 测试，但在完成同环境实验前不能提前宣布胜负。

场景	输入内容	验收命令	核心指标
接口签名迁移	定义、调用点、测试	编译 + 全量测试	漏改文件数
依赖版本升级	配置文件、报错栈	构建 + 冒烟测试	重试次数
数据库字段重构	Schema、DAO、服务层	迁移测试	回归失败数
前后端类型对齐	DTO、接口、页面类型	类型检查	编译通过率
并发 Bug 修复	日志、线程模型、测试	重复压力测试	修复后失败率

任务提示词里不建议直接塞入整个仓库。可以先提供：

目录树；
错误日志；
相关接口定义；
直接关联的源文件；
编译与测试命令。

然后让模型提出后续读取清单，再按需补充上下文。这样既能减少无关输入，也便于比较两款模型请求了哪些文件。

目前更可靠的验收方式仍是：在隔离容器内自动应用 diff，再运行固定命令。人工评价可以补充代码质量、可维护性和安全性判断，但不能替代编译器和测试框架。

7. 开发者接入与数据记录方案

接入渠道和模型能力必须拆开评价。同一模型经不同渠道调用时，限流、重试、路由、Token 统计和参数透传都可能不同。

方案	优点	风险	适合场景
厂商官方 API	归因链路较短	支付、配额和模型需分别维护	单模型深度使用
OpenRouter	模型目录集中	需复核上架状态、费用和路由	多模型快速验证
Together AI	提供统一推理接口	目标型号可用性需实时确认	推理服务评估
ofox.io	可作为兼容 API 候选	型号、后台字段和计费均需实测	团队接入验证
自建兼容网关	策略和日志完全可控	运维与故障归因成本较高	大团队平台化

每次请求至少记录以下字段：

text 复制代码

experiment_id
task_id
request_id
provider
base_url
canonical_model_label
provider_model_id
model_directory_snapshot_sha256
started_at
finished_at
http_status
attempt_number
prompt_tokens
completion_tokens
cached_tokens
tool_call_count
billed_amount
currency
patch_applied
compile_passed
tests_passed
error_category

其中：

canonical_model_label 使用本文统一标签，如 qwen3.7-max；
provider_model_id 保存渠道实际接受的 ID；
attempt_number=1 表示第一次请求，不算重试；
渠道自动重试和客户端业务重试应分开记录；
账单金额应以渠道最终账单为准，而不是只按本地 Token 估算。

别只保存模型回复文本。出现 429 或 500 时，如果没有请求 ID、时间戳和渠道信息，后续几乎无法准确归因。

8. 竞品候选池

如果目标是编程修复，候选池没有必要只放两款模型。以下型号来自本文输入材料提供的真值表，但它们在具体渠道上的可用性、实际 model 参数、价格和能力仍需分别查询。

模型	本文标准化标签	渠道可用性	本文可核验价格	建议用途
Kimi K2.6	`kimi-k2.6`	`[待验证]`	`[待验证]`	本轮基线
Qwen3.7 Max	`qwen3.7-max`	`[待验证]`	`[待验证]`	本轮基线
Kimi K2.7 Code	`kimi-k2.7-code`	`[待验证]`	`[待验证]`	编程专项对照
GPT-5.3 Codex	`gpt-5.3-codex`	`[待验证]`	`[待验证]`	代码修复对照
DeepSeek V4.1 Flash	`deepseek-v4.1-flash`	`[待验证]`	`[待验证]`	高频任务对照
Doubao Seed 2.0 Code	`doubao-seed-2.0-code`	`[待验证]`	`[待验证]`	编程模型对照
GLM-5.3	`glm-5.3`	`[待验证]`	`[待验证]`	通用推理对照
MiniMax M3	`minimax-m3`	`[待验证]`	`[待验证]`	通用任务对照

这些字符串不应自动加上厂商命名空间。只有渠道目录明确返回了带命名空间的 ID，才能把它记录为该渠道的 provider_model_id。

横向评测最好限制在 4 款以内。24 个任务乘以每个任务最多 3 次请求，再乘以多个模型和渠道，实验规模会迅速膨胀。

9. FAQ

Q1：Kimi K2.6 和 Qwen3.7 Max 哪个更便宜？

目前无法核验。本文证据包没有两款模型可独立验证的输入、输出单价。即使拿到单价，也应把失败请求、重试和附加费用计入成功补丁成本。

Q2：为什么不能直接比较百万 Token 单价？

真实账单还可能受到输出长度、思考 Token、缓存、工具调用、失败请求和重试影响。每百万 Token 单价更低，不代表完成同一任务的总费用更低。

Q3：跨文件修复成功应该如何定义？

至少同时满足以下条件：

补丁可以无冲突应用；
项目可以编译或通过类型检查；
目标测试通过；
全量测试没有新增失败；
没有引入明显的安全或兼容性问题。

只生成一份看起来合理的 diff，不算成功。

Q4：为什么要分开记录编译通过率和测试通过率？

编译通过只能说明语法和类型基本成立。业务逻辑、边界条件和回归问题通常要到测试阶段才会暴露。

Q5：429 或 HTTP 500 算模型失败吗？

不能直接算作模型能力失败。应先区分：

渠道限流；
账户配额；
网络错误；
兼容层错误；
上游模型服务错误；
模型输出不符合要求。

渠道故障可以计入服务可用性，但不能直接计入模型修复能力。

Q6：平均重试次数怎么计算？

一种简单口径是：

text 复制代码

平均业务重试次数 =
  成功任务发生的业务重试总数
  ÷ 成功任务数

第一次请求不算重试。同一任务在获得错误日志后再次请求，算一次业务重试。SDK 自动网络重试应另列统计。

Q7：首字延迟能说明编程能力吗？

不能。它只反映部分交互等待时间。旧项目修复更应该关注总耗时、工具调用轮数、补丁应用结果、编译结果和测试结果。

测量时还应区分：

首个流式事件时间；
首个非空正文 Token 时间；
完整响应时间；
完整任务完成时间。

Q8：能直接在 Claude Code、Cline 或 Codex CLI 中测试吗？

可以，但必须固定：

工具版本；
系统提示词；
上下文选择策略；
文件与命令权限；
最大轮数；
超时时间；
自动重试策略；
实际底层模型及渠道。

否则测出的可能主要是 Agent 策略差异，而不是底层模型差异。

Q9：模型返回 `tool_calls` 是否代表工具调用已经成功？

不是。它只说明模型生成了调用意图和参数。客户端还必须验证参数、执行工具、回传 role="tool" 结果并再次请求。整个闭环完成后，才能评价工具调用是否有效。

Q10：真值表中的模型 ID 能否直接用于所有渠道？

不能。本文真值表只用于统一模型标签。每个渠道实际接受的 model 值都必须通过该渠道目录、文档或成功请求单独确认。

10. 总结与行动建议

截至 2026 年 10 月 27 日，本文掌握的证据不足以判断 Kimi K2.6 和 Qwen3.7 Max 谁更适合旧项目修复，也不足以给出两者的实际成本排名。

本文可以统一使用以下标准化标签：

kimi-k2.6
qwen3.7-max

但渠道实际模型 ID、官方价格、上下文窗口、Benchmark 和跨文件修复数据仍需补充。不能把真值表标签误写成跨 OpenRouter、Together AI、ofox.io 和厂商 API 通用的模型 ID。

可以直接执行的评测方案是：

锁定渠道并保存带时间戳的模型目录响应；
记录标准化标签与渠道模型 ID 的映射；
准备同一批 24 个分层任务；
固定容器、工具版本、提示词和上下文；
每个任务最多修复 3 次；
保存每次请求、错误、Token、账单和工具调用日志；
自动应用补丁并运行编译与全量测试；
分开统计模型能力失败与渠道服务失败；
最后按实际账单计算：

text 复制代码

每个成功补丁成本 =
  评测期间全部请求实际费用
  ÷ 通过补丁应用、编译和全量测试的任务数

等目录快照、定价页、原始请求日志、账单和测试结果齐全后，再填写成功率与金额。没有这些数据时，最严谨的结论就是"待验证"。

Kimi K2.6 与 Qwen3.7 Max：跨文件修复评测与成本核算方法（2026）

1. 型号与目录核验：真值表标签不等于各渠道通用 ID

2. 核心参数对比：缺少证据的字段不猜

3. Benchmark 解析：排行榜替代不了旧项目验收

4. 定价分析与真实场景成本测算

5. API 调用：基础、流式与完整工具调用闭环

5.1 基础调用

5.2 切换到 Qwen3.7 Max

5.3 流式输出

5.4 Function Calling 完整闭环

6. 五类典型应用场景

7. 开发者接入与数据记录方案

8. 竞品候选池

9. FAQ

Q1：Kimi K2.6 和 Qwen3.7 Max 哪个更便宜？

Q2：为什么不能直接比较百万 Token 单价？

Q3：跨文件修复成功应该如何定义？

Q4：为什么要分开记录编译通过率和测试通过率？

Q5：429 或 HTTP 500 算模型失败吗？

Q6：平均重试次数怎么计算？

Q7：首字延迟能说明编程能力吗？

Q8：能直接在 Claude Code、Cline 或 Codex CLI 中测试吗？

Q9：模型返回 tool_calls 是否代表工具调用已经成功？

Q10：真值表中的模型 ID 能否直接用于所有渠道？

10. 总结与行动建议

Q9：模型返回 `tool_calls` 是否代表工具调用已经成功？