# Opus 5.5 真的变弱了吗？LiveNerf 要等满 30 天才下结论

**Summary:** LiveNerf 将用户对模型上线后衰退的抱怨转化为一项预注册的 30 天测试。我更信任它的克制态度，而非过早的波动，但它狭窄的 Claude Code 路径无法代表所有用户的体验。

- Canonical: https://markhuang.ai/zh/news/livenerf-waits-30-days
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-30
- Section: News
- Tags: LiveNerf, Claude Opus 5.5, AI 评估, Claude Code, 模型监控
- Source: [LiveNerf on GitHub](https://github.com/ninjahawk/livenerf)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个密封的发光模型在实验室样本排中被反复测量，蓝色轨迹中出现一次琥珀色波动](https://cdn.markhuang.ai/news/livenerf-waits-30-days/hero.webp)

*一次异常读数很容易被注意到。LiveNerf 要等变化持续出现，才把它当作证据。*

[LiveNerf](https://github.com/ninjahawk/livenerf) 正在进行一项为期 30 天的测试，检验 Claude Opus 5.5 在发布后是否发生变化。前 10 天用于建立基线，随后是两个 10 天的对比窗口。按照预注册规则，变化必须在两个后续窗口中都达到 99% 置信水平下的显著性、幅度至少 3 个百分点，而且对照组不能出现类似变化，才能算数。最早的结果将在第 30 天得出。

我认为 LiveNerf 的价值恰恰在于它拒绝过早给出答案。一次写代码的体验很差，用户当下就能察觉；但厂商可能在不改界面模型名称的前提下，悄悄调了推理力度、提示词、路由或基础设施。LiveNerf 把一套环境固定住、长期跑，看这些抱怨到底是不是持续存在。如果站得住脚，用户拿到的是一份可复核的证据，而不是又一张翻车截图。

## 粗糙的会话是线索，而非测量结果

这类抱怨很常见：新模型刚上线时又快又准，过了几天就感觉变慢、变笨。但原因往往纠缠在一起——采样本身有随机性，用户的工作负载各不相同，产品更新可能改了模型外围的调度框架，高流量时段也可能恰好撞上表现差的运行，但未必就是原因。

用户反馈值得认真对待，但不代表第一个解释就是对的。2026 年 4 月，[Anthropic 追溯了一次 Claude Code 质量投诉](https://www.anthropic.com/engineering/april-23-postmortem)，发现根源是三个产品层面的变更：默认推理力度降低、一个缓存 bug 导致旧推理反复被丢弃、系统提示词减少了输出的详尽程度从而损害了编码质量。Anthropic 说 API 和推理层本身没受影响。但对用户来说，产品就是变差了。

这个区别很重要。LiveNerf 测的是通过 Max 订阅的无头 Claude Code 跑的 Opus 5.5，不是裸 API 模型，也不是 Claude 聊天界面、工具调用或长时间智能体会话。就算检测到变化，也只能说明这条特定的服务路径变了，但变的是模型权重、路由、分类器、容量还是产品设置，它说不清。

## 基准测试尽可能冻结所有变量

项目文档显示，团队从 GPQA Diamond、MMLU-Pro、竞赛数学及 AIME 2025 和 2026 中筛选了 2,336 道题，最后留下 78 道 Opus 5.5 在校准测试里时对时错的题。这些中等难度的题比模型总能答对或总答错的题更能反映能力变化。

每天的测试把这 78 道题发给 Opus 5.5，同时用一套较小的 GPQA 对照集测试 Opus 5。提示词、推理力度、Claude Code 版本、空工作目录、评分代码全部固定，工具调用、记忆、钩子、仓库指令、LLM 评委全部排除。项目用的是[Inspect](https://inspect.aisi.org.uk/)——英国 AI 安全研究所和 Meridian Labs 开发的开源评估框架——来跑测试并记录结果。

统计设计参考了 Evan Miller 的[2024 年论文《为语言模型评估添加误差线》](https://arxiv.org/abs/2411.00640)。LiveNerf 把每道题和它自己的基线表现对比，按题目聚类不确定性。项目估算，单日一轮测试能检测到每 10 天窗口约 7.5 分的变化，消耗大约 3.6% 的周度 Max 计划额度。

> **Info:**
>
> LiveNerf 能验证某条特定的 Claude Code 路径是否发生了显著变化，但说不清变化的原因，也判断不了所有用户的工作流是变好了还是变差了。

## 仪器无法捕捉的盲区

我喜欢这个项目把不舒服的地方也摆出来。验证发现，低努力模式让输出 token 少了 62%，准确率比高努力模式低 8.3 分。但同样是这个验证，Opus 5 换成 Opus 5.5 的差异在 99% 阈值下根本分不出来。换句话说，这个基准更容易抓住思维量的大幅变化，而不是同系列模型的小幅迭代。

题目集不大，但这是有意为之。团队审计了 80 道入选或后来被剔除的题目，发现 30 道表述模糊，8 道答案本身就有问题。LiveNerf 没有悄悄丢掉这些题，而是全部保留，并计划做一组去掉它们的敏感性分析——这比看到结果再挑题干净得多。不过核心题库主要考的是单轮知识和数学，用户抱怨最多的长时间编码会话基本没覆盖到。

[Reddit 上的早期讨论](https://www.reddit.com/r/ClaudeAI/comments/1wryrwx/is_opus_55_nerfed_new_benchmark_called_livenerf/)提了两个合理的质疑：有人担心公开基准可能被平台识别并区别对待；也有人指出只在固定时间跑一轮，可能错过高峰负载的影响。预注册方案已经承认了第二个问题：结果只反映固定时段的服务表现，不能推广到高峰时段。

项目还注明目前没选定许可证。方法谁都可以看，但在许可证确定之前，团队不应该默认自己有权利复用代码。

## 协议本身才是宝贵启示

LiveNerf 不会告诉我 Opus 5.5 现在做我的活还行不行。我想带走的是它的方法：系统变之前先留一份基线，把测试环境钉死，跑同样的题，保留原始数据，提前定好什么算"变了"。我之前写过[模型对比要看失败率，不是挑最好看的那次](https://markhuang.ai/news/model-build-offs-need-failure-rates)。时间是另一个值得量的变量。

如果是生产环境的智能体，我会跑一个小规模的本地测试，盯着补丁是否通过、输出是否符合 schema、恢复轮次和人工修正的情况。我会把供应商的状态事件和评分放在一起看，把模型行为和框架发布分开。公开基准替代不了这种本地记录，但它能展示诚实的监控应该长什么样。

我不会把 LiveNerf 图表上第一次下探当结论。截至 9 月 29 日的更新，项目才跑了 30 天里的 6 天，基线都还没建完。如果最后没检测到变化，公开记录会如实呈现；如果真的发现持续偏移，固定的协议会让这个结论值得追查。比起拿自己最差的一次体验当基准，我更信这份带时间戳的记录。