Claude 真的变差了吗？追查 AI 编程工具各环节的退化

用户不断反映 Claude 变差了：它会拒绝任务、写出更差的代码，或者在会话中迷失方向。我以前常对退化的说法持怀疑态度，但最近自己也遇到了问题。这并不能说明究竟哪一层发生了变化，因此我想梳理整个系统。

我曾让 Claude Code 排查无法打开的 Dropbox。它说问题超出了软件工程范围，建议查看我根本无法进入的设置。在我的实际体验中，另一个编程智能体很快解决了问题；单个案例无法证明普遍退化，但它说明了我所说的拒绝任务。

这些故障并不相同：API 可能阻止请求，助手可能拒绝或放弃任务，也可能给出更差的方案，或在长对话中偏离用户意图。它们可能来自不同环节，把一切都归结为模型变弱会掩盖有用的区别。

视频展示的 MarginLab 跟踪数据在我查看的时期里，加权指标从约 57% 降到 55%。它测试的是不断变化的模型和 Claude Code 组合；这条曲线值得调查，但它并非隔离模型权重的受控实验，也不能单独解释下降原因。

一个请求会经过多层：提示词和对话历史、智能体运行框架及其工具、API、服务基础设施和模型。模型依据提供的上下文生成输出；普通推理中，上下文改变的是激活状态和预测，而不是存储的模型权重。

运行框架除了用户消息，还会提供系统指令、工具定义和其他上下文。工具调用将结果返回对话后，智能体通常会再次请求模型。因此，糟糕的指令或别扭的工具既可能影响结果，也会增加得到结果的成本。

我在处理一道密码学谜题时也遇到过拒绝。过滤、路由、硬件和模型行为都是可以调查的环节，但一次拒绝本身不能确定是哪一个组件造成的。频繁使用工具会产生许多请求，配置差异因此有更多机会影响结果。

我们的期望也会变化。随着模型进步，我开始交付更难的任务，并提高对结果的要求。以前不足为奇的失败，如今可能让人感觉像退化，即使任务本身已经不同。这说明应当比较相同条件下的表现，而不是忽视所有抱怨。

自定义技能、MCP 服务和插件也会增加指令与上下文。有用的扩展可以提供帮助，但无关材料可能干扰智能体，或挤占相关信息的空间。用户和产品开发者都会影响实际交给模型的提示内容。

一个 Claude Code 示例试图编辑 package.json，却被告知必须先读取文件。它搜索后再次尝试并失败，最后才调用框架要求的读取工具。我认为这展示了框架交互如何浪费调用，并让历史记录充满失败尝试，即使底层模型理解了任务。

Matt Mower 的功能实现评测比较了相同模型在不同运行框架中的表现。我引用的结果显示，Opus 在 Claude Code 中的得分比在 Cursor 中低约 15 个百分点。结果取决于评测与配置，但它说明仅凭模型名称无法完整描述一个智能体。

在另一次测试中，Claude 提到系统反复提醒它把我的个人网站视为恶意软件，并表示会忽略这些提醒。即使智能体正确拒绝了一条指令，这些内容仍占用上下文。我担心相互混淆的提醒和工具错误不断累积，会让任务更难完成。

视频中的 Terminal-Bench 表格列出 Opus 4.6 在不同框架下的结果：ForgeCode 为 81.8%，Capy 为 75.3%，Claude Code 为 58.0%。这些是特定日期和配置下的提交结果，并非普遍排名。我还引用了另一项 API 幻觉评测，它曾下降后又恢复，提示问题未必只存在于运行框架。

分词是另一层：它把文本转换成模型处理的 token。同一段代码在不同分词器下可能产生不同数量的 token；我的演示显示，新旧分词器对空格和缩进的分组方式可能差别很大。

在我的示例中，GPT-5 分词器处理一段代码约需 225 个 token，而较旧的 GPT-3 分词器需要 400 多个。我见过旧模型大量重复空白字符，浪费 token 和费用。不过，token 数量只是分词器的一个属性，单靠它不能证明某个模型一定表现更差。

Anthropic 表示 Opus 4.7 更新了分词器，同样输入的 token 数可能因内容而增加到约 1 至 1.35 倍。视频引用的一项独立测量在技术文档上得到约 1.47 倍，在 CLAUDE.md 文件上得到约 1.45 倍。这些是具体样本，并非普遍倍数。

同样材料占用更多 token，可能影响使用限额、成本和上下文窗口容量。我怀疑它也可能影响质量，但把更长的 token 序列类比为更长的文档，并不能证明质量下降的因果关系；模型和分词器是一起变化的。

我没有太多关于不同芯片如何影响这些请求的直接信息，因此涉及硬件的解释只是推测。可以确认的是，Anthropic 的九月事故复盘描述了此前数月中三个间歇性降低 Claude 回答质量的基础设施故障。

事故复盘描述了 Sonnet 4 请求被错误路由到为即将推出的长上下文版本准备的配置。问题最初影响约 1% 的请求，随后负载均衡变更使受影响比例最高达到 16%。Anthropic 还记录了输出损坏和采样相关问题，并表示这些故障已修复。

我把这段历史视为长上下文路由风险的警示，并推测它可能与后来默认的一百万 token 窗口和硬件选择有关。这只是我的假设，事故复盘并未证实：2025 年一次特定的错误路由，不能证明后来所有百万 token 模型都更差，也不能证明请求被有意发送到某种芯片。

Anthropic 后来为 Opus 4.6 和 Sonnet 4.6 正式提供百万 token 上下文窗口，并取消长上下文溢价。长上下文需要资源，我猜测服务成本是否影响了这一决定；但价格和可用性本身无法揭示服务商的路由方式，也无法证明对回答质量的影响。

在我演示的 Claude Code 版本中，模型选择器显示百万 token 选项，同一菜单里没有原先的选择。我展示了一个用于关闭百万 token 上下文的环境设置。使用者应先查看自己所用版本的文档，再决定是否采用这一方法。

AMD AI 负责人 Stella Laurenzo 的团队发布了一份详细的 GitHub 问题报告，分析了 17,871 个思考块、234,760 次工具调用和 6,852 个 Claude Code 会话文件。作者报告称，思考内容可见性的变化与复杂工程工作流质量下降相关。这是一份材料丰富的观察报告，而不是隔离变量的受控实验。

我担心向用户隐藏思考内容，也可能让后续模型请求失去有用的推理历史。关于内部机制的说法只是我的推测：客户端能否看到内容，不足以确定服务商在各轮之间究竟保留或传递了什么。报告中的时间相关性也不能证明隐藏内容导致了退化。

报告描述了三月可见思考内容逐渐被隐藏的过程，并用签名长度作为估算思考深度的代理指标。报告称该指标大幅下降；这个估算依赖其前提，不能当作对每一个内部推理 token 的直接测量。

团队的行为指标包括更多挫败感、疑似循环和提前停止。观察到的读取与编辑调用之比从约 6.6 降到 2：读取占比从 47% 降到 30%，编辑从 7% 升到 15%。我也见过智能体还没调查就开始修改的情况，但这些观察指标本身无法确定原因。

作者还统计了许多助手请求继续许可或宣布暂停的情况。问题并不是询问许可总是错误，而是多余的停顿可能妨碍智能体完成用户已经授权的工作。

报告显示，二月至三月间 API 请求约增至 80 倍，输入 token 约增至 170 倍，而用户提示次数接近不变。作者明确指出，并发智能体会话的增加也是增长原因；不能把这些数字全部归因于行为退化。

Claude Code 的 Boris Cherny 回应时谈到了自适应思考和默认的 medium effort，并建议愿意付出更多时间和 token 的用户把 effort 设为 high。这是可以在相同工作负载上测试的一项配置，并不能证明报告中的所有问题都已解决。

我的结论是，退化可能来自多个相互作用的环节，Anthropic 应提供更可靠的行为和更高的透明度。根据自己的体验和看到的报告，我建议尝试包括 Codex 在内的替代品。但这些个案和选取的图表不能证明其他服务商从不退化，也不能为所有产品在所有任务上排出名次。

用户每天依赖这些工具工作，需要区分期望变化和性能的真实变化。我希望看到更清晰的说明、可复现的评测，以及在出现问题时仍然值得信赖的基础设施。