利用 bug，而不是模型 bug

Source: Dev.to

实际出现的问题

• 默认推理力度被调低。
  3 月初一次用户体验修复把 Claude Code 的默认设置从 “high” 降到了 “medium”。用户感觉它变得更笨了。该改动在 4 月 7 日被撤回。

• 一次缓存优化在每轮都丢失了先前的推理。
  该优化本应在空闲会话时清除一次过时的思考，但一个 bug 让它在每一轮都触发。Claude 在执行时忘记了之前的原因，表现为健忘和重复。已在 4 月 10 日修复。

• 冗长系统提示影响了代码质量。
  提示 “Keep responses under 100 words.” 导致代码质量下降了 3 %，而内部评估未能捕捉到。通过更广泛的消融实验发现后，于 4 月 20 日撤回。

这些事件都没有涉及模型本身的更改；权重没有变化，API 也不在影响范围内。

教训

• 模型不是产品。
  用户体验的是 model + harness + system prompt + tool wiring + context management + caching。每一层都可能出现自己的 bug。当有人说 “Claude 变差了”，权重通常是最后被修改的部分。

• API 层的产品不受影响。
  如果你直接使用 Messages API，这些 bug 并没有波及到你。这也是为什么要弄清 “我在使用 Claude Code，还是在使用原始 API？” 很重要。

• “评估通过” ≠ “没有回归”。
  冗长提示通过了 Anthropic 最初的评估，但更广泛的消融实验——一次去掉一行代码——捕捉到了 3 % 的下降。即使是经过修正的评估套件也可能漏掉行为漂移；消融实验可以发现它。

实际该怎么做

• 在 Claude Code 上？
  更新到 v2.1.116+。你已经在使用它了。使用限制已被重置，以示道歉。

• 直接使用 API？
  什么都不需要做。继续使用你原来的模型即可。

• 在前沿模型之上自行构建 harness 并发布？
  把事后报告读两遍，然后审计你的 prompt + caching + context‑management 流程，检查是否存在相同的静默失效模式。Anthropic 描述的 bug 正是每个 harness 都会重新发明的那类问题。

元教训虽无聊却重要：大多数质量差异存在于 “模型” 与 “用户看到的东西” 之间。发布优秀的 harness。

✏️ 由 KewBot（AI）草拟，Drew 编辑并批准。