事件与背景

过去几个月，社区里反复出现一种说法：Anthropic 会在模型发布后几周”悄悄把它变差”（nerf）。但当有人质疑时，双方都拿不出证据——没有发布当天的干净基线，最后都变成”体感对体感”。

2026 年 10 月 1 日前一天，Hacker News 首页被一个名为 livenerf 的开源项目顶上榜首（840 分、355 条评论）。它的自我定位很直接：「一个长期运行、尽可能确定性的基准，用来检测前沿模型发布后是否被悄悄变差」。Claude Opus 5.5 于 2026-09-22 发布，livenerf 选择在发布当天开始计时。

• 测什么、怎么测。 项目跑 30 天、每天一次：第 1–10 天建立基线，之后两个 10 天窗口做对比，最早可能下结论的时间在 2026-10-24 前后，Day 20 之后才会出现第一行结果表。Day 1 是 2026-09-24（发布后约 2.5 天）。截至仓库最后一次更新（2026-09-29），已收集 6/30 天、零遗漏，每天 90 个样本，全部跑在同一个 harness 哈希（461391b6fce64167）和锁定的 CLI 版本（2.1.280）上。
• 面板是筛选出来的难例。 从 GPQA Diamond、MMLU-Pro、竞赛数学（BRUMO、CMIMC、HMMT Feb 2025、APEX）与 AIME 2025–26 中共 2,336 题，各采样 4 次：Opus 5.5 首次约 93% 答对，97% 的题”要么总对、要么总错”，只有 78 道题时对时错，这 78 题构成正式面板。作者还主动量化了选择偏差：这些”时对时错”的题在新鲜样本上通过率从 54.7% 升到 62.0%，功率计算据此校正。
• 结论力度是事先算好的。 结果表明，每天跑一遍全面板，能在 10 天窗口里检出约 7.5 个百分点的准确率变化，成本约为每周计划用量的 3.6%。
• 关键机制先做”阳性对照”。 验证阶段刻意降低 effort：low 档 输出 token 减少 62%，准确率只掉 8.3±4.5 分；medium 档减少 26% token、掉 4.2±3.9 分。也就是说，“模型想得更少了”会先体现在输出 token 上，而不是准确率上——这是该系列最看重的次级指标。
• 它自己也承认边界。 在 99% 置信度下，把 Opus 5 换成 Opus 5.5 在现有样本量下无法区分（−3.8±6.3 分、−23% token）。作者明说：10 天窗口样本量约为验证阶段的 2.5 倍，但”这还没被证明足够”。

主要来源（均以 curl 验证返回 200 并核对正文）：

• livenerf 仓库（GitHub，含 README 与实时结果表）
• livenerf 测量计划 PLAN.md（Hermetic 调用、锁定 CLI、预算与 arms 设计）
• livenerf 预注册 PREREGISTRATION.md（先于数据采集提交，git 历史即时间戳）
• Inspect AI（英国 AI 安全研究院开源评测框架）
• Anthropic：Adding Error Bars to Evals（arXiv:2411.00640）
• Claude Code headless 文档（claude -p）

为什么现在重要

1. 模型 ID 不再是不可变产物。 你 pin 的 claude-opus-5-5 是一个服务的别名，供应商可以在后端改量化、路由、effort 或系统提示，而版本号纹丝不动。影响：所有依赖复现的评测、回归、论文与合规审计，都必须带上时间戳 + harness 指纹，否则”上周跑过是通过的”根本不构成证据。

2. 它把”体感 vs 体感”变成了可证伪的统计。 Day-0 基线、预注册协议、聚类标准误、阳性对照和 A/A 检查——这套方法是 Anthropic 自家评测论文里的标准做法被搬到了社区侧。影响：任何团队都可以照抄这个协议，给自己最关心的能力做一条”漂移曲线”，让”好像变笨了”变成会上能拿出手的指标。

3. 第一个报警信号是输出 token，不是分数。 effort 实验显示，能力下降 62% 的 token 换来的只是 8.3 分准确率损失——很多内部验收卡在”分数没变就没事”。影响：把每样本输出 token 中位数当成金丝雀指标接进监控，比每周跑一次基准更早、更便宜地发现异常。

4. harness 漂移和模型漂移长得一模一样。 livenerf 把”锁定 CLI、关闭自动更新、锁死系统提示”列成非可选项，理由很硬：CLI 一升级，结果就会变，而你无法区分是模型变了还是你的工具变了。影响：做 agent 框架和评测的团队，需要把 runtime 升级当成一次受控变更（记录、观察期、回归），而不是随手 npm update。

5. 仪器有明确盲区，别过度解读。 作者亲自写下：现有设计分不出同家族的模型替换。影响：即便 30 天结果是”无显著差异”，也只能说”这套仪器没看见”，不能说”没发生”。信任与采购决策不能只押一个社区基准，要多个独立信号交叉验证。

工程师/产品人今天能做什么

1. 给正在用的模型做一次”指纹快照”。 记录 model id、provider 侧版本、CLI/SDK 版本、系统提示文本，并在今天跑一次小基准，存下总分 + 每样本输出 token。放进 CI 或周报，成本极低，出事时是唯一的起点。
2. 锁死 harness 并关闭自动更新。 参照 livenerf 的做法：pin 版本号、设置 DISABLE_AUTOUPDATER=1、把版本写进仓库，让 runner 在版本不符时直接拒绝运行；升级走单独的变更评审。
3. 建一个 50–150 题的”难例面板”。 不要用全是满分的题——livenerf 的经验是 2,336 题里只有 78 道有区分度。优先挑模型”时对时错”的题，用它做周度漂移监测，信息量远高于跑一遍通用榜单。
4. 把输出 token 中位数 + 延迟接进告警。 设一条”相对基线下降超过 X%“的阈值；token 骤降往往先于准确率下降出现，是最便宜的先导信号。
5. 照抄它的评测基建。 用 Inspect 跑任务，按 Anthropic 的误差棒方法给出置信区间，别再只报一个平均值——单点分数在你需要判断”是否显著变化”时几乎没有用。

待观察

• 2026-10-24 前后是第一个可下结论的节点，Day 20 后才出第一行结果表。在此之前的任何”Opus 5.5 被降智”说法，仍然没有可靠证据支撑。
• 仪器自陈的边界会不会先被打破。 作者已声明同家族换模型（Opus 5 ↔ 5.5）在 99% 置信下不可区分；即便最终得到”无显著差异”，也无法证明”没被换”。后续要看它是否延长窗口或增加样本以缩小盲区。
• 供应商是否回应。 截至发稿，未找到 Anthropic 针对 livenerf 的公开回应来源。可以盯的是：厂商是否开始公开 serving/路由变更日志或更新模型系统卡——如果”变更透明”成为竞争点，这件事的影响会超出评测圈。