「新模型发布两周后好像变笨了」大概是 AI 社区最经久不衰的阴谋论。每一次大版本发布后，总会有人贴出聊天截图说质量下滑，厂商则回应什么都没改。双方都没有证据：用户没有发布当天的基线，厂商没有公开路由细节。9 月 29 日登上 Hacker News 首页的开源项目 livenerf，就是冲着这个死局来的——它在 Claude Opus 5.5 发布当天开始记录基线，用一套预注册的统计流程，回答一个曾被认为无法回答的问题：模型发布之后，到底有没有被悄悄换掉或者削弱？
问题为什么难：你永远回不到发布那天
检测模型降级（社区黑话叫 nerf）在方法学上有个根本障碍：要判断「变差」，你需要一个「发布时」的参照点。等社区意识到异常时，模型可能已经运行了几周，当时的快照再也无法复现——厂商可能已经换了量化方案、换了路由策略，甚至换了同名不同权的模型。livenerf 的核心洞察是：与其事后争论，不如在发布当天就把钟表锁死。
项目作者选中的时机非常精准。Claude Opus 5.5 于 9 月 22 日发布，livenerf 在 9 月 24 日 22 点 10 分 UTC 跑了第一轮基线，距发布约两天半。它给这个项目贴的标签很能说明气质：append-only（只增不删）、deterministic-as-possible（尽可能确定性）、boring（无聊）。评测框架用的是英国 AI 安全研究所的 Inspect AI，统计方法直接照搬 Anthropic 自己的论文《Adding Error Bars to Evals》，保证没有自造的统计口径可以抬杠。
第一步：从 2336 道题里筛出 78 道「边界题」
整套方法的第一块基石是面板（panel）设计。检测漂移不需要海量题库，需要的是对模型变化敏感的题目。livenerf 的做法分三层筛选：
先取 GPQA Diamond、MMLU-Pro、竞赛数学和 AIME 2025 到 2026 的题共 2336 道，每道题用 Opus 5.5 采样 4 次。结果非常符合预期：首试通过率约 93%，而且 97% 的题目要么四次全对、要么四次全错。恒对的题检测不出退化——模型再差也能做对；恒错的题同样没用。真正携带信号的是那 78 道「sometimes right」的题：模型有时做对、有时做错，通过率的任何系统性移动都会体现在这批题上。
第二层修正更见功力。按「有时对」标准筛题会引入选择偏差：这批题看起来接近五五开，实际难度并非如此。livenerf 用新鲜样本复测，发现这批题的真实通过率是 62.0% 而非筛选时的 54.7%，于是功效计算全部改用新鲜率，而不是被筛选过程污染的表面值。
第三层是题目质量审计。报告发现 78 道题里有 8 道答案键疑似错误、30 道表述歧义。这在大模型只有「有时能做对」的题目里是正常比例——恰恰是强模型勉强够得着的题最容易出争议。livenerf 的处理方式不是偷偷删题，而是预注册一个敏感性分析：正式结论同时报告含争议题与剔除争议题两个版本。
第二步：把不可控的推理服务冻进可控的 harness
第二块基石是 harness 冻结。通过订阅服务调用模型，采样温度、思考预算这些参数都不暴露给用户，服务端随时可能变化。livenerf 的策略是：既然无法控制模型本身，就把其他一切控制到死。
具体做法是每天用 headless 模式的 Claude Code（claude -p 命令行）跑完整面板，90 个样本一轮，命令行版本钉死在 2.1.280，整套 harness 的哈希值固定为 461391b6fce64167，每一天的运行都验证哈希一致才计入。原始日志永久保留，评测脚本只增不改。到 9 月 30 日，项目已完成 7 天采集，无一漏跑，其中第 5 天有一次预算守卫被覆盖，也被如实记入偏差日志而不是掩盖。
这里有个容易被忽略的脏细节：订阅入口的安全分类器有时会拦截生物类或部分数学类请求，有时甚至改用 Opus 5 回答。livenerf 的处理是把被分类器碰过的样本直接剔除并计数，保证面板只测量目标模型本身。这种对数据洁净度的偏执，正是家用级评测和专业评测的分水岭。
用 Inspect AI 组织任务的方式大致如下：
from inspect_ai import task, eval
from inspect_ai.dataset import json_dataset
from inspect_ai.scorer import choice
from inspect_ai.model import get_model
@task
def livenerf_panel():
return json_dataset("panel/frozen_78.jsonl"), choice()
# 每天 22:10 UTC 定时执行，harness hash 必须与基线一致
# eval(livenerf_panel, model="claude-code/opus-5-5", limit=90)第三步：校准——先用已知的降级验证仪器灵不灵
一块温度计在测量未知之前，得先在冰水里试过。livenerf 做了预注册的阳性对照实验：人为把 effort 从 high 降到 medium 和 low，看仪器能不能检出这个已知降级。结果给出了整篇项目里最有工程价值的结论：
effort 降到 low 时，输出 token 减少 62%，准确率下降 8.3 加减 4.5 个百分点；降到 medium 时，token 减少 26%，准确率只降 4.2 加减 3.9 个百分点。两组实验里 token 的相对变化都远比准确率显著。换句话说，厂商如果通过压缩思考预算来悄悄降级，输出 token 量是最先报警的仪表，准确率反而是迟钝的。这也是为什么 livenerf 同时追踪两条曲线——单看准确率，很可能在噪声里错过真实变化。
校准同时揭示了仪器的检测下限：每天跑一轮全面板，一个 10 天窗口能检出约 7.5 个百分点的准确率变化。这个灵敏度够用吗？项目自己的负面对照给出了残酷答案：把 Opus 5 塞进 Opus 5.5 的位置，测得差异为负 3.8 加减 6.3 个百分点，在 99% 置信水平下无法区分。也就是说，如果厂商只是做了同家族内的小幅模型替换，这套仪器会漏报。作者把这个局限原原本本写进了 README，而不是藏在脚注里——这种诚实在评测项目里比高灵敏度更稀缺。
你可以怎么搭一个自己的 livenerf
这套方法完全可复用，给任何关心某个订阅模型稳定性的团队或个人。核心流程五步：
第一，发布当天（越早越好）冻结题面板。不必是 2336 道题的规模，300 到 500 道题、每题采样 4 次，筛出时对时错的边界题，50 到 100 道就够支撑初步功效计算。题源用 GPQA、MMLU-Pro 这类公开且不易被训练数据污染的基准。
第二，写一份预注册文档。把面板构成、统计口径、判定阈值、敏感性分析方案全部在开始采集之前锁定。预注册的意义在于防止事后挪动球门——这也是 livenerf 与一般「我测了三天觉得变笨了」帖子的本质区别。
第三，固定 harness。命令行版本、评测框架版本、运行时刻全部钉死，每天运行前校验配置哈希。日志只增不改，任何人为干预都要写进偏差记录。
第四，同时记录准确率和输出 token 两条曲线。token 曲线是更早报警的那一个，尤其对思考型模型。
第五，攒够窗口再下结论。10 天基线起步，之后按窗口对比，报告置信区间而不是单日涨跌。单日波动毫无意义，这一点对 90 样本的小面板尤其成立。
结语：把玄学变成仪表盘
livenerf 目前的进度是 30 天计划跑完 7 天，第一行正式结果要到第 20 天之后，首次可下结论的日期在 10 月 24 日前后。无论最终结论是「Opus 5.5 稳如磐石」还是「确实出现了可检出的漂移」，这个项目的方法论价值都已经兑现：它证明了个人开发者也能用一套冻结面板、一条订阅通道和一份预注册文档，把模型稳定性的争论从 vibes 拉回到统计检验的地面。当模型厂商的发布节奏快到两周一个版本，这种「发布日基线」的基础设施，或许会成为每个严肃 AI 团队的标配。