怎么做一次信得过的模型对比

2026 年 8 月，我们在同一轮模型测试里三次写下「实测通过」。每一次，同样的请求重跑都失败了。这三次「通过」，每一次都只跑了一遍。

这些测试是我们自己做的：2026 年 8 月 18 日到 31 日之间，在一个设计产品的提示词上手工跑了三轮，连同原始的 token 数和我们犯过的错，一起记在一份台账里。LLMCompare 就是把这套做法做成了产品。下面十条规则，是这份台账教给我们的、在自己的任务上做模型对比的方法，无论你是用 LLMCompare 对比 AI 模型，还是自己写脚本。

手工对比模型，会在哪里出错？

第一轮测试的日期是 2026 年 8 月 18 日至 19 日，在三份设计需求上对比了 Claude Sonnet 5、Gemini 3.7 Flash 和 GPT-5.6 Terra。台账记下了我们在得出这一轮结论的过程中犯的四个错误，并注明四个都可以复现。

1. 拿一次侥幸的结果当结论。这个错误犯了三次。
2. 实验做到一半改了判据。「有内容」起初指标题非空，后来改成标题和文案方案都非空。改动前后的结果无法放在一起比。
3. 一次动了两个变量。我们把设计方向的数量从 3 改成 1，同时又在测另一个变量的影响，然后宣布找到了根因。把数量调回 3，这个结论立刻被推翻。
4. 拿生产环境从不发送的请求做验证。那三次「通过」都是不带系统提示词的手写 HTTP 调用，而它们和生产环境的唯一差别，正是那份 72 KB 的系统提示词。

四个错误没有一个和模型有关。四个都出在流程上，而流程可以由工具来强制执行。

每条用例应该跑几次？

不止一次。同样的请求，模型每次的输出都有差别，所以单次成功不算证据。

第二轮测试在 2026 年 8 月 30 日，让 GPT-5.6 Terra 在 reasoning_effort 的五个档位上各跑两次。输入完全相同：十次调用上报的输入 token 都是 1,261。在 xhigh 档，第一次用了 458 个思考 token，第二次用了 813 个。如果每档只跑一次，这两个数里的某一个就会被当成 xhigh 的成本写进结论。

规则 1：每一格跑多次，并展示波动。每多跑一次，就多一次调用。LLMCompare 在运行开始前显示预估积分，定价页说明了积分怎么计价。

规则 2：每个结论旁边都写上样本量。第一轮里每个模型在每份需求上只跑了一次，总共九个数据点，台账把这一轮的每一条质量判断都标为观察，还需要在真实流量里继续验证。样本小的报告，应当写明「仅供参考」。

哪些数字是测量，哪些是看法？

token 数、响应时间、成本是测量。质量评分是打分的一方做出的观察。第二轮的质量对比，是一个人读了五份输出，没有盲评，也没有打分，台账里就是这么写的。

规则 3：测量和评判分开报告，不合成一个总分。合成的总分会让人分不清哪一部分是测出来的，哪一部分是判出来的。

各个模型是在相同条件下运行的吗？

第一轮里，三个模型不是。每个模型用的结构化输出机制都不一样。Claude Sonnet 5 以纯文本输出 JSON，schema 写在用户消息里。Gemini 3.7 Flash 用 responseSchema。GPT-5.6 Terra 用 response_format 加 JSON schema，strict 设为 false。如果三个模型统一用一种机制，其中两个出不了结果。

因为三个模型走的是三种机制，台账把第一轮要回答的问题重新表述了一遍。问题不是哪个模型更强，而是「模型加上它当前可用的最佳机制」这个组合，哪个更强。

规则 4：条件不同，就在结果里写明。第二轮是反过来的例子：两次运行之间只改了一行配置，十次调用的输入 token 数完全相同，说明输入没有变。

各家的 token 数为什么不能直接比？

各家数 token 的口径不一样。第一轮里，Claude Sonnet 5 每次调用上报约 4,000 个输入 token，Gemini 3.7 Flash 和 GPT-5.6 Terra 上报约 20,000 个。三个模型收到的是同一份系统提示词，大小 72,705 字节。Anthropic 的 input_tokens 字段不含提示词里被缓存的部分，另外两家的 prompt_tokens 字段含被缓存的部分。

第一轮里，输出的口径同样不一致。OpenAI 的输出数已经包含思考 token，Anthropic 和 Gemini 则把输出和思考分成两个数上报。三家都把思考 token 按输出计费。

规则 5：先把用量换算到同一个口径再比，并保留原始数字可查。

规则 6：思考 token 单独列一行。思考 token 不出现在可见输出里，却经常是成本差异的主因。第二轮里，把 GPT-5.6 Terra 的 reasoning_effort 从 none 调到 xhigh，思考 token 从 0 涨到最多 813，而十次调用的可见输出一直在 252 到 288 个 token 之间。按台账的计算，xhigh 的输出账单是 none 的 3.8 倍。档位也不是单调的刻度：在第二次运行里，high 档用了 159 个思考 token，medium 档用了 317 个。

什么算失败？

超时、被拒绝、输出为空，都是结果，计入产生它的那个模型的表现。厂商限流或平台故障是另一回事：调用没有完成，说明不了模型的任何问题。

规则 7：每一次失败都要记录，并把模型的失败和没有完成的调用分开。第二轮里，我们自己的工具就违反了这一条。等待结果的脚本只认成功这一种情况。一次调用以 HTTP 400 失败后，用量日志只在成功时才写，所以一直是空的，脚本就一直等下去。

价格和参数从哪里来？

规则 8：每个价格都要有来源和日期。第一轮用的价格，是 2026 年 8 月 19 日对照三家厂商的定价页核实的。那一天，Gemini 3.7 Flash 的输入价是每百万 token $0.75，输出价是每百万 token $3.75，都是导入价，2026 年 12 月 31 日之后将涨到 $1.50 和 $7.50。一份成本对比如果不写明用的是哪个价格，价格变了之后就无法核对。LLMCompare 在模型与价格列表里标出每个价格最后一次核实的日期。

规则 9：把运行那一刻的条件固化下来。模型版本、实际生效的参数值、提示词、价格表，都按运行开始时的状态存下来。文档不等于实际生效的记录：文档里 reasoning_effort 列了七个取值，GPT-5.6 Terra 对 minimal 这个值返回了 HTTP 400，并在报错里列出它支持的五个值：none、low、medium、high 和 xhigh。

规则 10：写明速度是在哪里测的。响应时间取决于发出请求的机器所在的地区，也取决于当时的网络。LLMCompare 从自己的服务器测量响应时间，并在每份报告里写明测量位置。

评判的人应该知道哪份输出出自哪个模型吗？

不应该。第三轮测试在 2026 年 8 月 31 日，是针对 GPT-5.6 Terra 上一处提示词改动的盲评 A/B 测试：在提示词里的字体目录每一行末尾加一个「best for」字段。四份需求在改动前后各跑一遍。两组结果并排摆给评判的人，不告诉哪组是哪个，评判的人选了带字段的那一组。这处改动测得的代价，是每次调用多 6,725 个输入 token，从 20,975 增加到 27,700，增幅 32%。

台账给第三轮的结论划了边界：四份需求，两组，各跑一次，一个人评判，只评一遍。这个样本够支撑「这个字段开还是关」的决定，不够支撑任何「质量提升了多少」的说法。

LLMCompare 的人工评判默认是盲评：模型名被隐藏，每条用例里各输出的顺序随机。

十条规则的清单

1. 每一格跑多次，并展示波动。
2. 每个结论旁边都写上样本量。
3. 测量和评判分开报告，不合成一个总分。
4. 各模型的运行条件不同时，在结果里写明。
5. 把 token 用量换算到同一个口径，并保留原始数字。
6. 思考 token 单独列一行。
7. 每一次失败都要记录，并和没有完成的调用分开。
8. 每个价格都写明来源和日期。
9. 把运行那一刻的模型版本、参数、提示词和价格固化下来。
10. 写明响应时间是在哪里测的。

这篇文章说明不了什么

台账只有三轮测试，用的是同一个产品的提示词，每格跑了一到两次。这些记录支撑不了这三个模型的排名，本文也不给排名。文中引用的每个数字说的都是 2026 年 8 月的情况，模型版本和价格都会变。

我们的模型对比文章里，每篇实测文章都链到一份公开报告，用例、输出和数字都可以在报告里核对。想在自己的任务上用这十条规则，可以用自己的用例新建一次评测。