Claude “变笨“之谜揭开：AI 系统的脆弱不在模型，而在 Harness
Claude "变笨"之谜揭开：AI 系统的脆弱不在模型，而在 Harness
引言
过去几周，大量开发者抱怨 Claude 变得"懒惰"、“推理能力下降”、“更容易幻觉”。AMD 的一位高级工程师甚至审计了6,852 个 session 文件、234,000+ tool calls，用硬数据证明 Claude 的推理深度明显下滑。第三方基准测试报告准确率从 83.3% 暴跌到 68.3%，排名从第 2 跌到第 10。
用户把这种现象称为“AI shrinkflation”（AI 缩水）。
4月23日，Anthropic 终于发布官方解释：模型权重没有改变，是 “harness”（外围配置）出了问题。
这个事件揭示了一个被忽视的工程真理：
AI 系统的脆弱性往往不在模型本身，而在部署层的各种"优化"尝试。
什么是 Harness？
在 AI 工程中，“harness” 指的是包裹在模型外部的所有配置和基础设施：
- System prompts（系统提示词）
- Reasoning effort settings（推理强度设置）
- Context caching（上下文缓存）
- Token limits（输出限制）
- Latency optimizations（延迟优化）
- Tool invocation patterns（工具调用模式）
模型本身只是"大脑"，harness 是"神经系统"——它决定了大脑如何接收信号、如何思考、如何输出结果。
一个看起来合理的 harness optimization，可能悄然牺牲了推理质量。
Claude 事件的三个 Bug
Anthropic 的 post-mortem 披露了三个具体问题：
Bug 1：Reasoning Effort 降低
| 项目 | 详情 |
|---|---|
| 时间 | 3月4日 |
| 变更 | 默认 reasoning effort 从high改为medium |
| 原因 | 解决 UI "冻结"问题——用户等待时界面看起来卡住 |
| 影响 | 复杂任务推理明显变弱 |
教训：延迟优化的代价是推理深度。
用户看到界面"卡住"，会抱怨体验差。但降低推理强度来"流畅化"，本质上是在用智能换速度。这不是用户真正想要的——他们要的是"答案正确"，而不是"答案快速但错误"。
Bug 2：Caching Logic Bug
| 项目 | 详情 |
|---|---|
| 时间 | 3月26日 |
| 变更 | 新的 caching optimization |
| 原因 | 清理 idle sessions 的 old thinking，节省 memory |
| Bug | 本应 1 小时后清理，结果每轮都清理 |
| 影响 | 模型丢失"短期记忆"，变得重复、遗忘 |
教训：缓存的边界条件是最容易出错的地方。
代码逻辑：if idle > 1 hour: clear thinking
实际行为：clear thinking on every turn
一个简单的条件判断错误，让 Claude 在每次对话后都"忘记自己在想什么"。这不是模型问题，是 harness bug。
Bug 3：Verbosity Limits
| 项目 | 详情 |
|---|---|
| 时间 | 4月16日 |
| 变更 | System prompt 添加字数限制 |
| 要求 | 工具调用间 ≤ 25 词，最终回复 ≤ 100 词 |
| 原因 | 减少 Opus 4.7 的 verbosity |
| 影响 | 编码质量下降 3% |
教训：prompt 的副作用难以预测。
Anthropic 可能觉得用户抱怨"废话太多"，于是加个限制。但这个限制让模型在复杂任务中无法展开思考——该说的话没说完，就被迫压缩。
一个 25 词的限制，可能让模型跳过了关键推理步骤。
为什么 Harness Bug 比 Model Bug 更隐蔽？
Model Bug：容易发现，容易定位
如果模型权重有问题，表现会在所有场景下滑。基准测试会直接反映出来。修复路径清晰：重新训练或调整权重。
Harness Bug：场景依赖，难以复现
Harness 问题通常只在特定场景触发：
- 长对话 session（caching bug）
- 复杂推理任务（reasoning effort）
- 多工具调用任务（verbosity limits）
单一基准测试可能测不到。用户抱怨时，公司可能说"我们没有改动模型"，因为确实没改动——但改动的是 harness。
信息不对称：公司知道改了什么，用户不知道
Anthropic 改 reasoning effort 时，用户不知道。他们只感觉"Claude 变笨了"。几周后才有人做系统性审计（Stella Laurenzo 的 6,852 sessions 分析），才有了硬证据。
这个时间差就是信任 gap。
Harness 工程的核心原则
Claude 事件给 AI 工程团队上了重要一课。以下是实操原则：
1️⃣ 每个变更必须 Ablation Test
不要：改了一个 system prompt，直接上线。
要：
- 设计对照组（旧 prompt vs 新 prompt）
- 在多个 benchmark 上测试
- 量化副作用（不只是目标指标）
Anthropic 现在的做法：
“We will now run a broader suite of per-model evaluations and ablations for every system prompt change to isolate the impact of specific instructions.”
2️⃣ Latency Optimization 必须声明代价
改 reasoning effort 从high到medium：
- 好处：UI 不冻结，体验流畅
- 代价：复杂任务准确率下降
这个代价必须透明声明，让用户选择：
“需要深度推理时，请手动开启 high reasoning effort”
而不是偷偷改成默认值，让用户不明不白承受代价。
3️⃣ Caching Logic 的边界条件必须测试
缓存逻辑的典型 bug 场景：
- 条件判断错误（每轮清理 vs 闲置后清理）
- 时间单位错误（秒 vs 分钟）
- 并发竞争（多个 session 同时触发）
测试必须覆盖：
- 正常场景（闲置后清理）
- 边界场景（刚好超过阈值）
- 异常场景（频繁切换、并发访问）
4️⃣ Prompt Limits 必须评估 Reasoning 代价
字数限制的隐秘代价：
- 模型可能跳过推理步骤
- 关键信息可能被压缩丢失
- 复杂任务可能无法展开
评估方法：
- 在复杂任务 benchmark 上测试
- 对比无限制 vs 有限制的推理轨迹
- 统计"推理步骤完整性"
5️⃣ Dogfooding 必须用 Public Build
Anthropic 的教训：内部员工可能用的是"特殊版本"，不体验用户真实感受。
新做法：
“A larger share of internal staff will be required to use the exact public builds of Claude Code to ensure they experience the product as users do.”
如果你自己不用公开发布版本，你就不知道用户在抱怨什么。
一个 Harness 变更 Checklist
每次改动 harness 配置时，问这些问题：
[ ] 这个变更的目标是什么？（降低 latency？减少 verbosity？） [ ] 代价是什么？（推理深度？记忆保留？输出完整性？） [ ] 有对照组测试吗？（旧配置 vs 新配置） [ ] 测试覆盖了哪些场景？（简单任务 vs 复杂任务） [ ] 用户会感知到变化吗？（透明告知 vs 隐藏改动） [ ] 有 rollback 计划吗？（发现问题后如何快速恢复） [ ] Dogfooding 测试了吗？（内部员工用过吗）如果任何一个答案是"不清楚"或"没有"，不要上线。
Claude 事件的深层启示
模型是"引擎"，Harness 是"传动系统"
引擎再强，传动系统出问题，车子也跑不好。
Claude Opus 4.6 的模型权重没有变——引擎还是那个引擎。但 harness 的三个 bug 让"传动系统"失灵：
- 油门踩不到底（reasoning effort）
- 变速箱每秒换挡（caching bug）
- 限制排气管流量（verbosity limits）
结果：用户感觉"引擎没力了"，但其实是传动系统卡住了。
"优化"的双刃剑
每个 harness optimization 都有理由：
- 降低 reasoning effort → 解决 UI latency
- 清理 thinking cache → 节省 memory
- 限制输出 verbosity → 减少用户阅读负担
但每个 optimization 都有隐秘代价。问题是：
- 代价是否被量化？
- 代价是否被透明告知？
- 代价是否被充分测试？
Claude 事件的教训：没有量化测试的 optimization，是危险的 optimization。
用户信任比功能指标更重要
Anthropic 的 post-mortem 开头就说：
“We take reports about degradation very seriously.”
为什么？因为用户信任一旦破裂，修复极难。
几周的"变笨"投诉，让用户质疑：
- Anthropic 是否在偷偷 nerfing？
- 是否在用低质量服务骗订阅费？
- benchmark 数据是否可信？
即使最终解释了"是 harness bug 不是 model bug"，信任裂痕已经存在。
预防胜于治疗：透明变更、充分测试、及时沟通。
结语
Claude "变笨"事件表面上是 model quality 问题，实际上是 harness engineering 问题。
核心教训：
- Harness 是 AI 系统的神经系统——它决定了模型如何思考
- 每个 optimization 都有代价——代价必须量化、透明、测试
- Dogfooding 必须用 public build——否则不知道用户真实体验
- 信任比指标更重要——用户感知是最终检验标准
下次你的 AI 产品出现"莫名性能下降"，先问一个问题：
“是不是 harness 出了 bug，而不是模型出了问题？”
如果答案是"可能"，先检查 system prompt、caching logic、reasoning settings——这些"外围配置"往往是最脆弱的环节。
附录：Anthropic 的整改措施
Anthropic 在 post-mortem 中承诺的改进：
| 措施 | 说明 |
|---|---|
| Internal Dogfooding | 更多员工使用 public build |
| Enhanced Evaluations | 每个 prompt 变更都做 ablation test |
| Tighter Controls | prompt 变更更容易审计，模型特定变更严格 gated |
| Subscriber Compensation | 重置所有订阅用户的 usage limits |
这些措施的本质：让 harness 变更更透明、更可控、更可测试。
参考文献
- Anthropic Blog: Technical Post-Mortem on Claude Quality Issues
- VentureBeat Analysis by Carl Franzen (April 23, 2026): Mystery solved: Anthropic reveals changes to Claude’s harnesses and operating instructions
- Stella Laurenzo’s Audit: 6,852 Claude Code sessions, 234,000+ tool calls
- BridgeMind Benchmark Report: Claude Opus 4.6 accuracy drop from 83.3% to 68.3%
关键词：Claude, Anthropic, Harness Engineering, AI Shrinkflation, Reasoning Effort, Caching Bug, Prompt Engineering, AI Quality, Model Deployment