我原本计划了10个LLM评估实验，但只跑了1个——而这1个就够了。
我本来没打算写什么基准评测论文。
我只想回答一个更实际、更接地气的问题：
“在我日常工作中，到底什么时候真需要用前沿模型……什么时候只是白白烧钱？”
于是我做了工程师认真思考时都会做的事：
- 设计了10个实验
- 覆盖真实的Agent使用场景
- 搭配可复用的评估框架
- 设定预算上限，免得事后后悔
然后我只跑了其中一个实验。
结果发现，这一个就够了。
分裂的现实：工作预算 vs 个人预算
在公司，LLM的Token费用是别人买单。
- 前沿模型一个Jira工单就能搞定
- 我们负担得起用真实数据跑20次实验
- “先上线再学习”是合理默认选项
在家就不一样了：
- 我无法本地运行Sonnet或V4
- 我的GPU吞不下前沿质量的4K上下文窗口
- 每次生成都刷我自己的信用卡
但我仍然想了解这些模型在真实工作负载下的表现，而不是用玩具提示词。不过在自己项目中，我必须精打细算每一分钱花在哪里。
正是这种张力催生了前沿实验计划。
我设计了10个实验来覆盖整个空间
理论上，这个计划很完美。
每个实验都是一个大问题的一个切片：
“对于一队做运维开发工作的Agent，应该用哪个模型处理哪个任务、投入多少努力、花多少钱？”
我围绕这个设计了10个实验：
- 自适应预算调节器 – 能保证质量的最便宜推理预算是多少？
- 前沿轻量现场测试 – 在我的实际工作负载上，便宜模型能否替代昂贵模型？
- 上下文衰减检测器 – 在真实文档中，长上下文回忆能力到底在何处崩溃？
- 工具漂移 – 同时暴露50–200个工具时，工具调用准确率会下降吗？
- 代码审查断点 – 在多大的PR规模和多复杂的语言下，AI代码审查不再有用？
- 本地vs云端基准 – 量化后的本地模型能否接近其云端对应版本？
- 缓存命中最大化 – 在多轮Agent场景中，提示缓存究竟能省多少钱？
- 开源权重一对一 – 开源权重模型之间对比，而非厂商之间对比
- 主权Agent实验室 – 在单一狭窄任务上，微调后的开源模型能否匹配前沿模型？
- 顶点阈值检测器 – 哪些任务真正需要最贵的模型？
除此之外，我还构建了一个可复用的评估框架：model-compass
- 9个真实Agent任务（CI诊断、事件分类、代码审查、PR草稿、架构分析等）
- 每个任务配有评分标准（二元/精确匹配/测试运行器/LLM评判）
- 统一的适配器层，支持Anthropic、OpenAI、DeepSeek、OpenRouter、Together、Kimi
- 自动计算每个任务的成本（美元估算）
- 路由表生成：“对于这个任务，使用能通过测试的最便宜模型”
计划很周密。
然后我跑了1个实验就停了。
为什么我选择CI诊断作为那个实验
我本可以从更“炫酷”的任务开始，比如架构推理或多Agent协调。
但我选了CI诊断。
为什么？
因为这才更接近我整天实际做的事情。
我的团队在多个仓库中交付TypeScript、Swift、Kotlin、C++、Java、Go和BrightScript代码。我们的CI管道整合了大量第一方和第三方工具。一旦出现红色告警，日志动辄数兆字节而不是千字节。大多数失败发生在繁重的集成测试中，有些日子某些区域仅因工具和测试不稳定性就有5–20%的失败率。
作为领导，我不是那个每一条失败日志都读的人。我的团队才是。我亲自投入去理解他们的痛苦，并开始构建真正能帮忙的Claude技能。丑陋的现实是：“CI变红 → 我知道根本原因和下一步”过去常常需要花一小时甚至更多时间下载日志、寻找模式。端到端地，从发现问题到让修复上线，往往是一整天。
有了合适的自动化和AI介入，我们把这个时间压缩到了大约15分钟理解情况，许多情况下不到2小时就能让修复合并且重新投入生产。
本实验中的大多数运行都以同样的方式开始：我眯着眼睛看一份5000行的GitHub Actions日志，心想：“这正是我希望模型替我做这件事的原因。”
如果能搞清楚：
“对于CI诊断，我到底该为哪个模型付费？”
这就能立刻转化为工作中更好的决策。
于是实验01（作为更大计划的前奏）在纸面上很简单：
- 任务：从真实日志中诊断CI构建失败
- 模型：Haiku vs Sonnet
- 数据：来自开源仓库（Django、Rails、Node、Pytest等）的真实GitHub Actions日志
- 评分：模型是否识别出正确的失败领域，并给出有用且正确的步骤？
我通过model-compass框架运行，设定了硬预算上限。
总花费：13.53美元。
13美元看起来很少，但每个实验有几个子变体，如果样本量足够，整个计划每个实验大约要花费300美元以上。在开始第一个实验的第一个变体后，我果断缩减规模，设定20美元的硬预算来完成整个实验。这意味着削减样本量、放弃子变体、在运行中不断缩小范围。
这个实验是什么（以及不是什么）
在继续之前，有必要明确范围。
这个实验是什么
- 一个专注的个人现场测试。一个类似我真实工作的DevOps风格任务（CI诊断）。两个模型，真实的GitHub CI日志，足够多的运行次数来观察质量、延迟和成本方面的模式。
- 校准我个人直觉的一种方式。我想回答这些问题：“我是否真的需要为CI使用昂贵模型？”以及“何时可以安全地默认使用便宜模型？”
- 对我框架的现实检验。运行这个实验迫使我看到框架中哪些20–25%的部分是真正可复用的，以及哪些实验特定脚本（数据下载、配置、变体、摘要）实际上承担了主要工作。
- 在真实约束下工作。个人预算、没有强大的GPU集群、且前沿模型无法本地运行。目标不是“覆盖一切”，而是“从一个精心挑选的切片中学到尽可能多”。
这个实验不是什么
- 不是正式的LLM基准测试。我没有在标准化公共基准上对数个模型进行统计严谨的对比。我没有那些团队所拥有的基础设施、预算或全职评估背景。
- 不是排行榜结论。在单一CI任务上比较两个前沿模型，并不意味着“模型A总体上优于模型B”。它只是说：“对于CI诊断，根据我的提示词和数据，对我来说这样是合理的。”
- 不是最终的框架。最初的
model-compass设计假设了一个非常通用、可复用的核心。但在实践中，每个DevOps实验都需要自己的数据管道和脚本。这个实验正在为更好的框架提供输入，它本身不是那个最终框架。 - 不能替代专业的评估工作。拥有专门评估团队和大预算的机构才是进行广泛、正式模型对比的合适人选。我在这里做的事情要狭窄得多：为自己实际工作所用的模型做出一两个更好的决策。
核心结论：便宜模型赢了
结果如下：
- Haiku 4.5 vs Sonnet 5（通过OpenRouter）
- 相同的提示词、相同的日志、相同的评分标准
- 涵盖不同失败类型（数据库连接、测试失败、构建错误、依赖问题）的约50次运行
Haiku：
- 便宜10倍
- 快67%
- 在准确率上统计持平
Sonnet：
- 使用了更多Token
- 花费更高
- 速度更慢
- 在唯一要紧的指标上并未明显胜出：“你能帮我修复这个构建吗？”
对于“我该为CI诊断付费使用Sonnet吗？”这个问题，答案是：
“默认情况下，不值得。”
如果你只读了这些，你可能会想：
- “哇，真让人意外！”
- “关于省钱的好故事！”
但对我来说，感受并非如此。
而这一部分很重要：
你不应该把这个结果理解为“Haiku 在所有事情上都比 Sonnet 好。”
对我具体的这份工作而言：
- CI 日志分析
- 一部分 DevOps 风格的诊断
- 我们团队实际遇到的那些场景
Haiku 是目前对我来说最有意义的模型：
- 它比 Sonnet 便宜
- 实际使用中更快
- 而且，基于公开数据和本次实验，对于这些特定任务它“足够好”甚至更好
在工作中，我仍然大量使用 Sonnet 或 Opus——特别是对于更难的推理、架构决策或更模糊的问题。
这个实验只是把我工作中的一块（CI/DevOps 诊断）挪到了“默认用 Haiku，需要时再用 Sonnet/Opus”的思维框架里。
这里有细微差别。在有些运行中，Sonnet 的回答更清晰、更连贯。Haiku 倾向于更冗长。对于 CI 诊断来说，这种冗长是特性而非缺陷。Haiku 将原始日志中大概 1/1000 的内容总结成工程师或下游 agent 可以处理的信息。当有人类参与循环并获得更多上下文进行推理时，我可以接受小幅度的质量差距。
我对成本并不感到意外。那不是教训。
我原本就预期前沿模型会很贵。
我并不震惊于：
- 用 Sonnet 做 CI 诊断对于这个任务来说“不值得”
- Haiku 看起来是这种忙活任务的正确默认选择
同样，我也不震惊于：
- 一个简单的小实验就烧掉了 13.53 美元
- 一个完整的 10 个实验的计划会消耗数百美元
每个实验包含几个子变种，如果有合适的样本量，每个实验大约要 300 美元以上。在开始第一个实验的第一个变种后，我大幅缩减规模，并设定 20 美元的硬目标来完成整件事——当场削减样本量、放弃子变种、缩小范围。
这正是为什么我把个人实验控制在有限范围内，而工作实验则更开放：
- 工作时：预算更大，探索自由度更高
- 在家时：我想从前沿模型中学到东西，但我不希望一个副项目悄悄变成一张 300 美元的账单
真正的教训是别的：
我其实不需要运行全部 10 个实验就能学到我想学的。
宽广的设计，狭窄的执行
设计 10 个实验仍然是值得的。
那个过程迫使我清晰地思考：
- 对于不同的任务，“足够好”到底是什么样子
- 上下文长度、工具数量、缓存实际上在哪些地方重要
- 什么时候微调可能比“直接用 fancy 模型”更好
但在执行层面，我意识到：
- 我日常的大部分收益来自于一些针对性强的洞察，而非完整的实验室工作
- 我并不需要一张完美绘制的模型行为前沿图来在明天做出更好的决策
- 把 CI 诊断作为“典型的 DevOps 场景”运行一次，足以校准我的直觉
那一个实验：
- 验证了
model-compass的测试装备 - 为我真正关心的一个任务生成了一个具体的路由决策
- 让我看到评分体系哪里坏了（二元关键词检查 vs 实际行为质量）
- 以一种现在选择模型时仍能牢记的方式，揭示了“Haiku 与 Sonnet”的权衡
另外 9 个实验的设计仍然保留在那里，以备将来需要。
但就目前而言，设计工作加上一次聚焦的执行已经足够了。
混乱的部分：我让一个 LLM 搭建了测试装备
还有另一层，我认为比实验结果更重要。
我请一个 LLM 帮我搭建评估装备本身。
它……成功了。
某种程度上。
LLM 做得好的地方
- 快速写出了完整的比较脚本
- 用标准化的接口连接了多个 provider
- 帮我重构出一个更干净的 CLI
- 提出了我还没整合的评分钩子（精确匹配、LLM 评判、测试运行器）
失败的地方
- 它总是写“一次性”脚本，而不是可复用的代码
- 路径处理 bug、缩进错误、JSON/CSV 输出中字段缺失
- 六个不同的脚本最终被归档在一个 trial/ 文件夹里，名字像
compare_models_v3_final_real_final.py - 由于小错误导致大量 API 重新调用，每次悄悄多花几美元
当我第三次修复一个路径 bug 并重新运行同一批调用时，我能感觉到实验在后台烧钱。
元教训既残酷又简单：
人类必须写出完整的规格说明。每个字段。每个输出。每个边界情况。
一旦我写清楚：
- CSV 中需要哪些列
- 路由表 YAML 应该是什么样子
- 评分如何与评分维度挂钩
LLM 终于有用了。
在此之前，它只是在猜。
我的测试装备设计比我想象的更加不成熟
这次运行中还有另一个令人不安的发现。
我最初的测试装备设计远比实验实际需要的更通用。
在纸面上，model-compass 看起来像是一个干净、可复用的引擎：
- 通用任务定义
- 共享的工具接口
- 一套统治所有场景的评分系统
但实际上，DevOps 风格的实验（CI 诊断、PR 审查、发布说明生成）都需要自己的流水线：
来自公共 GitHub 仓库的大规模数据输入
因为这是一个私人项目，我无法把测试装备指向内部仓库。我不得不：
- 跨多种语言抓取公共仓库
- 遵守 GitHub 的速率限制
- 在本地存储日志、PR 和变更列表
实验特定的“自动化配置文件”
每个实验需要自己定义的“配置文件”：
- 仓库/语言/框架
- 测试哪种失败或变更类型
- 针对该部分使用什么提示模板和工具
每个实验的多阶段脚本
实际的流程更像这样：
- 下载并规范化数据的脚本（速率限制友好）
- 生成自动化配置文件的脚本
- 按配置文件逐个运行一个模型并捕获成本与输出的脚本
- 按配置文件比较两个模型输出的脚本
- 跨变种和子变种汇总这些比较结果的脚本
测试装备的第一个版本中，没有任何一点被干净地编码。
当尘埃落定时，我意识到我们可能只用了最初设计的不到 25%。真正的工作大多存在于实验特定的脚本中。
而这……没问题。
这里没有任何东西是真正可丢弃的：
- 测试装备中不成熟的部分告诉了我哪些还不应该集中化
- 实验脚本是核心应该长什么样的具体证明
- 正确的下一步是在实验结束后把好的脚本回收到测试装备中
这虽然不耀眼但很有用：
先设计通用的东西，发现它是错的，让特定脚本告诉你通用层实际上应该是什么。
另一个重大转变是抵制“一个大脚本”的本能。DeepSeek V4 Pro 的第一次尝试是一个单一的脚本，它会下载日志、运行两个模型、然后一次性输出最终比较结果。看起来聪明，但让迭代变得昂贵。把它拆分成更小的脚本——“下载一次并缓存不可变的日志”、“按配置文件运行单个模型”、“汇总保存的输出”——意味着我可以在一个阶段修复 bug，而不用在其他阶段浪费 API 调用。当汇总器出问题时，我不需要重新运行模型；只需重新处理保存的输出。当下载器出问题时，我修复它而不触及任何 LLM。这种分离是让这个实验在财务和技术上保持理智的关键。
我们标准化了什么，以及 TierForge 如何使用它
即使只有两个模型，我也需要让输出对齐，这样比较才不会基于“感觉”。对于每次CI运行，我将模型输出强制统一为固定结构：故障领域（简短的标签，如 db-connection 或 test-assertion）、一两三句话的根因摘要、证据指向（日志片段或行范围）、粗略置信度桶（低/中/高）、三到五条具体的修复步骤，以及一个简单的判断——这看起来是真实问题还是偶发/基础设施问题。
在此基础上，每次运行还会捕获输入/输出token数、缓存与非缓存token、以美元计的总成本以及延迟。评分和比较脚本随后回答那些非常枯燥但非常重要的问题：故障领域是否与标注的真实情况匹配、根因方向是否正确、步骤是否可操作且安全、某个模型是否持续过度自信且错误、以及这额外花费了多少成本。
接着，我将数据汇总成三层摘要：按模型变体（例如，“在DB连接故障上，Haiku通过了X/Y项，Sonnet通过了A/B项，以下是成本和延迟差异”）、按所有变体跨任务（整体准确率、获得一个“足够好”的CI诊断答案所需的成本，按模型计）、以及一份人类可读的决策摘要。
这就是TierForge的用武之地。TierForge是一个开源路由工具，它能把证据转化为YAML路由规则。它需要基于真实数据的路由规则：针对像 ci-diagnostics 这样的特定用例，什么是主模型、什么是升级模型、以及在什么条件下切换。这个实验恰好提供了这些：一条具体的“默认用Haiku，满足这些条件时切换Sonnet”规则，以及实际每任务成本数字，而不是凭“感觉”。
我实际学到的东西（并保留了下来）
回顾一下，以下是我保留并持续使用的东西。
- 测试平台比论文更重要
我不需要发布“决定性的基准测试结果”来获得价值。
我需要的是：
- 一种针对不同模型运行我的任务的方法
- 根据我的质量标准自动对输出进行评分
- 以美元（而非感觉）查看每任务成本
- 生成一个可以放入配置文件的路由表
model-compass最终变成的样子。 - 一个精心选择的实验胜过十个泛泛的实验
CI诊断：
- 看起来像我实际的工作负载
- 使用真实日志，而非合成提示词
- 锻炼了错误处理、日志解析、解释质量和可操作性
- 我的个人预算塑造了我的学习策略
因为我无法为个人实验承受数百美元的开销：
- 我设计得广泛（10个实验）
- 我执行得集中（1个当下重要的实验）
- 对于超出我专业范围的内容，我严重依赖公开基准
- “廉价模型 vs 昂贵模型”不仅仅是成本问题 CI实验回答了一个成本问题。 难点在于行为问题： 我是否会真的默认在CI工作中使用Haiku？还是仍然会点击那个“好”模型，因为它感觉更安全？ 即使手头有数据，我有时还是会发现自己默认使用那个“很好”的模型。
我仍在摸索的问题
我在这里没有明确的答案。只有几个我一直在思考的开放问题：
- 当你自掏腰包时，如何决定“足够”的实验量？
- 如何平衡从前沿模型学习与不让你的副项目变成无偿的基准实验室？
- 如果你真的做过成本/质量比较，它们是否改变了你的默认模型选择……还是你仍然会伸手去拿那个更光鲜的模型？
- 如果你让LLM构建使用LLM的工具，你设置了什么机制来防止它悄悄烧掉你的预算？
如果你曾在这种张力中周旋——工作预算 vs 个人预算，好奇心 vs 成本——我很想听听你是如何处理的。
是的，账单很重要。但在与我交流的团队中，“这个太贵了”往往隐藏着其他担忧：我们还不确定是否信任这些输出，我们觉得对工作流程没有完全掌控，或者我们害怕在领导面前显得鲁莽。我试图反其道而行之：通过更了解工作负载、更依赖证据来收紧成本，而不是因为恐惧而收紧成本。
当你考虑在团队中控制AI成本时，真正的驱动力是什么？仅仅是云账单，还是更深层的东西——信任、形象、掌控感，或者觉得在让模型触碰一切之前应该先搞清楚状况？
