livenerf：用于检测 Claude Opus 5.5 发布后能力退化的确定性基准

TL;DR – livenerf 的作用及其重要性

livenerf 持续对 Claude Opus 5.5（通过 Claude Code Max）运行一个由 78 个 有时正确 的问题组成的冻结面板，并报告其准确率或输出 token 数量相对于发布后前 10 天基准的任何统计显著变化。该项目提供了首个公开、可复现的时间序列数据，可用于证实或反驳 Anthropic 在发布后“削弱”其模型的传闻。

核心贡献：一种确定性、仅追加的漂移检测器

livenerf 消除了除模型自身随机性外的所有非确定性来源。它固定了 Claude Code CLI 版本，冻结系统提示，使用精确匹配评分器，并记录每个请求级别的所有产物（提示、响应、使用情况、延迟、测试框架 SHA 等）。通过每日运行相同面板 30 天，该基准采用成对项目得分差异并结合聚类标准误的方法，遵循 Anthropic 的《为评估添加误差条》（Miller 2024）的统计框架。此设计消除了提示、工具或环境变化带来的漂移，因此任何观测到的变化均可归因于模型或服务堆栈本身。

基准构建方式

1. 校准以识别有信息量的项目

仅保留模型有时正确的项目（约 50%–70% 通过率）。完全正确或完全错误的项目无法提供退化信息。校准阶段对 2,336 个 GPQA-Diamond、MMLU-Pro、竞赛数学和 AIME 2025–26 问题各采样四次，最终得到 78 个面板项目（另有两个后续被排除）。这些项目在纠正选择偏差后，新样本通过率为 62%。

2. 成对每日运行以消除题目难度影响

每天对同一面板进行评估，并将其结果与第 1–10 天的基准分数进行比较。由于比较是按项目进行的，难度被抵消，主要指标变为项目间成对差异的均值。

3. 双臂设计控制平台效应

主臂：通过 Claude Code Max 运行 Opus 5.5。 对照臂：Claude Opus 5（上一代）运行相同的 GPQA 子集。如果两臂同步变动，则变化归因于测试框架或基础设施，而非新模型。

4. 预注册验证证明敏感性

在收集基准数据前，系统运行已知退化（中等 vs. 高等努力）和 A/A 检查。验证结果显示，26% 的 token 使用量减少对应准确率下降 –4.2 ± 3.9 分，而 62% 的减少则导致 –8.3 ± 4.5 分。这表明该工具能够检测到真实的努力相关退化。

实验运行：时间线与当前状态（截至 2026-09-29）

阶段	天数	样本数	状态
基准	1–10（发布 2026-09-24）	90 个样本/天	已收集 6 天，无遗漏
第一个 10 天窗口	11–20	–	待定
第二个 10 天窗口	21–30	–	待定

所有运行均使用固定 CLI 版本 2.1.280（哈希 461391b6fce64167）。第 5 天需一次性的预算保护覆盖，已在偏差文件中记录。

可检测效应量与限制

单次完整面板的每日运行可在 10 天窗口内检测到约 7.5 分的准确率变化（约为每周计划统计功效的 3.6%）。
该工具无法可靠区分 Opus 5 与 Opus 5.5：观测到的差异为 –3.8 ± 6.3 分，在 99% 置信水平下不显著。
token 使用量是更敏感的早期指标；轻微的努力减少会先表现为显著的 token 下降，准确率尚未变化。

如何复现该基准

环境 – Python 3.11+、uv 和已登录的 Claude Code Max 订阅。
固定 CLI – 禁用自动更新，记录 claude --version 到 CLAUDE_CLI_VERSION，并将二进制文件副本放入 ~/.local/share/livenerf。
安装 – git clone https://github.com/ninjahawk/livenerf && cd livenerf && uv sync。
校准与设计 – 运行 python -m livenerf.benchmarks.calibrate … 然后 python -m livenerf.design … 以生成 data/standard_panel.json 并锁定面板。
验证 – 执行 python -m livenerf.validate run … 以确认系统能检测到已知的努力退化。
预飞行检查 – python -m livenerf.preflight --probe 必须输出 READY 才能安排运行。
调度 – 将提供的 scripts/daily.sh 添加到 cron（Linux/macOS）或任务计划程序（Windows）中，每日运行一次，遵守每周使用量保护（若 >75% 周使用率或 >60% 5 小时使用率则跳过）。
分析 – 每个 10 天窗口结束后，运行 python -m livenerf.analysis 以获取成对差异、聚类标准误和自动决策（Δ > 3 分，99% 置信区间不包含零，对照臂稳定）。

所有原始日志以 Inspect .eval 文件形式存储在 logs/ 中（仅追加，永不编辑）。

社区在 Hacker News 上的反应

@jug – “BridgeBench 的 Nerf Bench 检测到 Opus 4.6 的退化，Anthropic 后来在博客中承认了这一点。”

@johnfn – “大多数‘削弱’报告都是感知偏差；一张图解释了‘蜜月效应’——新模型在用户触及复杂性天花板前感觉无限强大。”

@Cider9986 – “我昨晚在 Claude Code 聊天中看到了一次削弱；快速在 Nitter 上搜索，发现同样的说法。”

@zeroonetwothree – “如果该基准无法区分 Opus 5 和 Opus 5.5，那它就没用。”

@nomilk – “好主意；它让服务提供商负责，并且有点尴尬的是，我们竟然需要它。”

这些评论反映出对“削弱”体验的轶事描述与对系统性测量可能性的怀疑之间的分歧。livenerf 直接回应了后一种观点，提供了一个预注册、统计严谨的协议。

局限性与开放问题

模型特异性 – 该基准仅测量通过 Claude Code Max 提供的 Claude Opus 5.5，而非原始 API 模型。在 Azure 或 Bedrock 部署上的结果可能不同。
面板隐私 – 个别问题文本保持私密（仅发布哈希值），以避免泄露专有评估数据。
检测上限 – 同家族模型替换（Opus 5 → 5.5）低于当前统计功效；需要更大样本量或更长窗口才能检测。
外部因素 – 依赖负载的服务变更、安全分类器拒绝或配额限流可能影响 token 使用量，并被记录但未完全分离。

未来方向

将协议扩展至其他前沿模型（如 GPT-6 Astra）及仅 API 部署。
发布一个公开的合成面板供社区复现，同时保留私有的校准项目。
自动化跨提供商比较（Azure、Bedrock），以测试‘削弱’是否为特定提供商独有。
探索更细粒度的 token 使用信号（如每步思考时间）作为早期预警指标。

如何贡献

贡献应仅限于新增纯函数评分器、合成生成器或分析工具。更改冻结面板或提示将创建新版本，必须伴随新的预注册提交。所有 PR 必须披露任何由 LLM 生成的内容，因为该仓库本身部分由 Claude 编写。

引用

@misc{livenerf,
  author = {ninjahawk},
  title = {livenerf: tracking post-launch capability drift in frontier models},
  year = {2026},
  publisher = {GitHub},
  url = {https://github.com/ninjahawk/livenerf}
}