Opus 5.5 疑似上线后降级？开发者用同一提示词复现对比

一位开发者在 Reddit 上贴出了一组颇具争议的证据：他用完全相同的提示词和参考图片，在 Claude Opus 5.5 发布当天与约十天后分别生成同一个 Godot 游戏项目，结果后者的质量明显劣化。这篇帖子重新点燃了社区关于「大模型上线后被悄悄降级（nerf/gimp）」的长期争论。

一次有「收据」的复现实验

这位开发者的测试对象颇有情怀——他想用 Opus 5.5 忠实复刻 David Braben 的经典游戏《Lander》，这是他童年在英国学校里玩到的第一款游戏，运行在搭载早期 ARM 芯片的 Acorn Archimedes 上。

他的实验设计值得注意：发布当天（9 月 23 日）生成的 Godot 仓库（macOS、Metal 渲染、C#）被单独保存在磁盘上，并未作为后续参考。到了 10 月 2 日，他在一个全新的、从零开始的工作区中，喂入完全相同的提示词和两张原始参考图。两次测试都将 Opus 的努力程度设为 Extra High。

换句话说，他刻意控制了变量，试图把「非确定性」这个常见的反驳理由排除在外。

作者列出的具体退化点

按照帖子的描述，后期版本相比发布日版本出现了多项可观察的退化：

• 渲染故障：相机移动时，场景道具会相对世界空间「卡顿、抽搐」，这是发布日版本没有的问题。
• 缺失物理效果：原版实现了飞船解体（break-apart）物理，这其实并未在提示词中明确要求，属于模型主动加的「彩蛋」；新版本则没有。
• 交互体验下降：没有了介绍性的控制菜单，只剩一行永久覆盖在画面上的小字提示。
• 视觉细节劣化：发射台炮塔的外观更差。
• 射击逻辑错误：飞船移动时子弹渲染不准确，且从飞船尾部生成并「穿模」（no-clip）而过。
• 缺少相机切换功能。

技术层面的根因分析

这篇帖子比一般的「感觉变差了」的抱怨更有说服力，因为作者真的去读了生成的代码。

他发现，退化版本的 Godot 项目全局开启了物理插值（physics interpolation），而 Props.cs 在每一帧的每个 tile step 都从头重建道具列表（树木等），重新编号每个对象所占的槽位，并在每帧重置对象计数。

作者直言，只要对 Godot 文档有基本了解就能避免这个问题。这意味着问题不只是「表现变差」，而是生成代码的工程质量本身出现了问题——他担心随着项目规模扩大，这类底层混乱会不断累积、复合成更严重的 bug。

物理插值（physics interpolation）是游戏引擎中用于平滑渲染帧与物理更新帧之间差异的技术。Godot 的物理系统以固定频率（默认 60Hz）运行，而渲染帧率可能更高，插值会在两次物理帧之间估算对象位置，使运动看起来更流畅。然而，若全局开启物理插值后未正确处理对象的生命周期——比如 Props.cs 每帧销毁并重建道具列表——引擎会在已被标记为「新生成」的对象上执行插值，因为它没有前一帧的位置参考，就会从原点或错误位置「弹出」到当前位置，造成视觉上的卡顿与抽搐。这正是作者描述的「相机移动时道具在世界空间中抖动」现象的底层机制。正确做法是：要么在场景初始化时一次性构建道具列表并仅按需更新，要么为动态生成的对象显式调用 reset_physics_interpolation() 以告知引擎跳过首帧插值。生成的代码同时犯了「不必要的全局启用」与「错误的对象管理」两个错误，二者叠加才导致了难以追踪的帧级 bug。

「非确定性」能解释这一切吗？

大模型输出本身具有非确定性，这是任何此类对比必然面对的质疑。作者对此有明确回应：相同提示词和参考图下的差异通常很小，而这次得到的是一个明显更差的结果，他认为这不能用随机性来解释。

这是整个讨论的核心分歧点。支持者会认为可观察、可复现的代码级退化构成有力证据；而怀疑者则会指出，单次对比样本量太小，温度采样、上下文微小差异、甚至运气，都可能导致一次性生成（one-shot）结果的巨大落差。严格来说，要证明「模型被降级」，需要多次重复实验并做统计，而非单一样本。

大语言模型的「温度（temperature）」参数控制输出的随机程度：温度为 0 时模型趋向确定性最高的输出，温度越高则越有创造性但也越不稳定。代码生成任务通常会设置较低的温度，但即便如此，「one-shot」（单次无对话历史）生成仍会因采样随机性产生不同结果。更关键的是，模型在推理阶段可能经历服务端的 A/B 路由——同一 API 端点可能在不同时间调用不同的权重版本或系统提示版本，用户无从感知。这使得「是随机性还是模型本身变了」成为一个在用户侧原则上无法区分的问题。要在统计意义上排除随机性，需要在相同时间窗口内对同一模型版本进行大量重复采样，并与另一时间窗口的采样结果做分布比较，而非依赖两个时间点各一次的单样本对比。

「悄悄换模型」的指控与透明度诉求

作者走得更远，提出了一个颇具阴谋论色彩的猜测：也许发布的头三天用户用到的其实是某个更强的模型（他称之为 Mythos），之后被悄悄替换。他还提到，相比 4.5/4.6，Max effort 模式会「过度测试」并从用户手里拿走太多控制权。

无论真相如何，他的核心诉求是透明度——用户有权知道自己调用的到底是什么模型、是否发生了变更。

需要强调的是，「发布后被降级」在 AI 社区是反复出现的集体感受，但至今缺乏严格的第三方验证。厂商通常会以路由策略、安全调整、负载均衡等理由解释性能波动，而用户的主观体验很难与客观退化划清界限。作者承诺会把两个版本的源码上传到个人开发博客并在评论区附上 GitHub 链接，这为社区进一步独立验证留下了空间。

怎么看待这类「降级」证据

这个案例的价值，不在于它「证明」了 Opus 5.5 被降级——单一样本显然不够——而在于它示范了一种更负责任的质疑方式：控制变量、保留原始产物、深入代码找根因，而不是停留在「感觉不如以前」的情绪化吐槽。

对依赖 AI 编程工具的开发者来说，几点务实的启示：重要项目的生成结果值得存档备份；不要把一次性生成的代码当成可以直接信任的黑盒，底层工程质量需要人工审查；对厂商宣称的能力保持合理的、可验证的怀疑。在厂商给出明确说明之前，这类帖子仍属于待验证的单源指控，读者宜保持审慎。