如何检测 Claude 性能下降（附真实数据）

本视频涵盖的内容

• Claude 在发布后会变笨：理论与零日计时相遇
• livenerf：对 Opus 5.5 从发布周开始的 30 天计时
• 如何捕捉性能下降：78 个有时正确的 问题
• 它能看到什么：7.5 分，且 token 计数率先变化
• 盲点：Opus 5 交换和 8 个错误答案键

翻译的文字记录

译自英文原版旁白。可用音频和字幕由 YouTube 控制。

Claude 在发布后会变笨：理论与零日计时相遇

0:00 众所周知，Claude 在发布几周后会变笨。 所以一位开发者从发布周开始对 Opus 5.5 进行计时， 计时结果显示，没有人能够提前知道。 在这个视频中，有三个问题。 你如何捕捉性能下降？ 这个测量器能看到什么？ Anthropic 又说了什么？ 仓库致谢中的一句话让我忍俊不禁。

0:20 我会在最后提到它。 今天是 9 月 30 日星期三，这里是 The Daily Diff。 今天有三个故事，其中最重要的是一个名为 live nerf 的 GitHub 仓库。

livenerf：对 Opus 5.5 从发布周开始的 30 天计时

0:30 数月来，人们一直说 Anthropic 在发布后悄悄地降低了其模型的性能。 常见的理论是模型被压缩，或者在同一名称下使用较小的模型， 或者干脆是思考能力降低了。 该仓库将迄今为止的每次争论都称为“感觉之争”。 Opus 5.5 于 9 月 22 日发布， 一周前我告诉过你，它在独立排行榜上名列前茅，同时生成了比中位模型 多三倍的词语。 两天半后，一位名为 ninja hawk 的开发者启动了计时，

0:59 每天一次，持续三十天，日志不可编辑。 Hacker News 帖子获得了近八百个赞，并像团队 聊天一样分裂。一位评论者说，在绝大多数报告的案例中，模型性能下降并不是真的。 另一位评论者说，人们只是习惯了新的智能水平。 而一位 Claude Code 高级用户现在每次都会忽略“评价本次会话”的 弹出窗口，因为评价 Claude 似乎让它变得更糟了。 同行评审。那么，问题一，你如何捕捉性能下降？

如何捕捉性能下降：78 个有时正确的 问题

1:27 你从大约两千三百道难题开始， Opus 第一次尝试就答对了百分之九十三， 这对于检测器来说是无用的，因为它总是答对的问题不会 下降。百分之九十七的问题总是对或总是错的， 而那七十八道它有时才能答对的问题成为了测试面板。 相同的提示，没有工具，并且采用严格匹配的评分，没有 AI 裁判， 因为裁判也会漂移。 它通过无头 Claude Code 在 Max 订阅上运行，

1:55 因为 API 版本的定价约为每月一千六百美元。 Claude Code 版本是固定的，因为用仓库的话说， 更改的测试框架看起来和更改的模型一模一样。 这些统计数据来自 Anthropic 的 Evan Miller 撰写的一篇名为 《给评估添加误差棒》的论文。 所以 Anthropic 自己的数学现在正在审计 Anthropic，这相当于学术版的 向客户支持引用服务条款。

它能看到什么：7.5 分，且 token 计数率先变化

2:19 问题二，它能看到什么？ 每十天窗口，大约下降七点五分。 为了证明这个装置有效，作者故意降低了 Claude 的工作量。 中等工作量使输出减少了大约四分之一，分数只减少了四 分。低工作量使输出减少了近三分之二， 分数减少了八分。 这才是值得借鉴的部分。 思考减少首先体现在 token 计数上，然后才体现在答案中。

2:43 所以固定你的模型版本，记录每个任务的输出 token 数量， 并保留一些你自己的固定问题。 如果你的代理突然写得更短了，在查看 Reddit 之前先检查你的日志。 这就是诚实的部分。

盲点：Opus 5 交换和 8 个错误答案键

2:54 悄悄地换回旧的 Opus 5，对这个装置来说变化太小了，无法 识别，readme 文件也提前说明了这一点。 审计还发现了八个看起来有误的答案键， 所以性能下降检测器在找到性能下降之前，先在基准测试中发现了错误。

Anthropic：我们从不降低模型质量

3:08 问题三，Anthropic 怎么说？ 去年，在一波投诉之后，Anthropic 发布了一份事后分析报告。 它写道，引用：“我们绝不会因为需求、 时间或服务器负载而降低模型质量。” 同一篇文章承认有三个 bug 降低了 Claude 的性能，并且近三分之一的 Claude Code 用户至少有一次遇到了错误的服务器。 所以投诉是真实的，原因是 bug， 这就是为什么仓库警告说发布周可能是最糟糕的一周。

3:35 三十天中已经过去了六天。 第一个可能的发现大约在 10 月 24 日左右公布， 所以诚实的答案是，包括那些确信的人在内，没有人知道。 说到没有人公布的数字。

数据中心对其数字保密；Backblaze 公开

3:46 Lighthouse Reports 和荷兰报纸 Trouw 发现，绝大多数 欧洲数据中心对其电力和水的使用量保密， 尽管欧盟法规已要求报告三年了。 在荷兰，不到四分之一的数据中心公开了这些信息。 仅微软的一个数据中心就使用了荷兰约百分之一的电力。 与此同时，Backblaze 又做了那件无聊的事情。 它的季度硬盘统计数据涵盖了大约三十五万块硬盘， 故障率上升到百分之一点七三，

4:16 是近期最高水平。 三个希捷型号的故障率为零。 这就是一个公开的基准线，一季度又一季度， 持续了十三年。

致谢：Claude 帮助构建了测量器

4:25 现在，那行致谢词。 readme 文件承认仓库的许多内容是在 Claude 的帮助下编写的， 而 Claude 正是被测量的模型。 所以 Claude 帮助构建了测量器，用于检查 Claude 是否变笨了。 这就是为什么评分器是简单的函数。 用作者的话说，你不应该信任作者， 无论是人还是其他。 如果你宁愿阅读而不是听我说，diff 每天早上都会免费发送到你的收件箱，

4:46 地址是 thedailydiff.dev，链接在下方。 所以，今天对 live nerf 的结论是。

结论：SHIP IT，在 10 月 24 日前请勿引用

4:51 SHIP IT。我会发布它，因为这是我见过的第一个有时间戳、 公开规则和明确盲点的性能下降论据。 只是在 10 月 24 日之前不要引用它。 这就是今天的 diff。 我是 Axrisi 的 Niko。 负责任地合并。

来源

1. livenerfgithub.com
2. Validationgithub.com
3. Hacker Newsnews.ycombinator.com
4. Anthropic postmortem (Sep 2025)www.anthropic.com
5. Adding Error Bars to Evals (Evan Miller)arxiv.org
6. Inspect (UK AI Security Institute)inspect.aisi.org.uk
7. NL Timesnltimes.nl
8. Hacker Newsnews.ycombinator.com
9. Backblaze Drive Stats Q2 2026www.backblaze.com
10. Hacker Newsnews.ycombinator.com