本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
Claude Code 变“笨”了，也变懒了，还学会了“摸鱼”，同时连复杂工程任务也搞不定了。
对，你没看错。一位来自国外的用户，用他的故事，收集了大量的数据和证据，证明了当前最得力的 AI 助手 Claude Code 突然“变笨”。
目前，该 issues 问题虽然已被关闭，但讨论还在继续，同时引发了大量的转发，冲上了 HN 的热搜榜。
一位工程师的困惑
2026 年 4 月 2 日，老外工程师 stellaraccident，在 githu 上开场了他的故事。
他收集了大量的数据，参见https://github.com/anthropics/claude-code/issues/42796，引起了广泛的关注。
下面，我们就他的问题，展开深入剖析。
问题简述
stellaraccident 用 Claude Code 做高强度、高复杂度的工程开发，几个月来一直顺风顺水。但从今年二月开始，事情不对劲了。
- 它开始无视我们的指令
- 声称“最简单的修复方案”，结果却是错的
- 让我们往东，它偏要往西
- 明明没做完，却报告“任务完成”
我们期望的很简单，让它变回一月份那个靠谱的样子。
当深度思考被悄悄关掉
stellaraccident 所在的团队分析了 6852 个会话日志、17871 条思考记录、234760 次工具调用，发现了一个惊人的时间线。
思考内容被打码的时间线
| 时间段 | 思考可见 | 思考被隐藏（redacted，即内容被屏蔽） |
|---|---|---|
| 1月30日 – 3月4日 | 100% | 0% |
| 3月5日 | 98.5% | 1.5% |
| 3月7日 | 75.3% | 24.7% |
3月8日 | 41.6% | 58.4% |
| 3月10-11日 | <1% | >99% |
| 3月12日+ | 0% | 100% |
非常关键的一个巧合，用户集中反馈“质量下降”的日期，正是3 月 8 日，思考内容被隐藏的比例首次超过 50% 的那天。
而造成这一切的一个关键原因是：Extended Thinking（扩展思考） 被悄悄的默认关闭了，要知道这个扩展思考 = 大语言模型在给出答案前，内部进行的“头脑风暴”过程。就像人类工程师写代码前会先画流程图、查文档、想方案一样。
数据不会说谎
数据显示，思考深度其实在更早之前就缩水了。
即使思考内容还能看到时，它的“思考长度”已经在悄悄变短。
| 时间段 | 估算平均思考长度（字符数） | 相比基线变化 |
|---|---|---|
| 1月30日 – 2月8日（基线） | ~2,200 | — |
| 2月下旬 | ~720 | ↓67% |
| 3月1-5日 | ~560 | ↓75% |
| 3月12日+（完全隐藏） | ~600 | ↓73% |
大家可以这样通俗理解：想象一个工程师，以前写方案前要写 2 页纸的草稿，后来突然只让写半页，再后来连草稿都不让看了，你觉得他交出的方案质量会怎样？
行为变化
数据显示，Claude Code 的行为变化明显。从“先调研，再动手”变成“边猜边改”。
核心指标
研究团队，对比了读文件次数与改文件次数。如下表格所示。
| 时期 | 读:改比例 | 研究:修改比例 | 读操作占比 | 改操作占比 |
|---|---|---|---|---|
| 好时期（1.30-2.12） | 6.6 | 8.7 | 46.5% | 7.1% |
| 过渡期（2.13-3.7） | 2.8 | 4.1 | 37.7% | 13.2% |
| 退化期（3.8-3.23） | 2.0 | 2.8 | 31.0% | 15.4% |
上面的数据显示，70% 的调研工作被砍掉了！
以前：读目标文件 → 读相关文件 → 全局搜索用法 → 看头文件和测试 → 精准修改
现在：打开文件 → 直接改 → 出问题 → 再改 → 循环……
每周趋势
数值越低，调研越少。
周次 读:改比例 研究:修改比例
──────────────────────────────────────
1月26日 21.8 30.0 ← 巅峰调研期
2月02日 6.3 8.1
2月09日 5.2 7.1
2月16日 2.8 4.1 ← 开始滑坡
2月23日 3.2 4.5
3月02日 2.5 3.7
3月09日 2.2 3.3
3月16日 1.7 2.1 ← 历史最低
3月23日 2.0 3.0
3月30日 1.6 2.6全文件重写比例翻倍
“手术刀”变“大锤”，发现不对，时不时就来一次重写。
| 时期 | 全文件重写（Write）占修改操作比例 |
|---|---|
| 好时期 | 4.9% |
| 退化期 | 10.0% |
| 后期 | 11.1% |
后果造成的后果是，以前是精准修补，现在是“整页重写”，快是快了，但容易丢上下文、破约定、引入新 bug。
为什么深度思考如此重要
为什么“深度思考”对高级工程师工作流如此关键？
这个团队的工作任务处理的不是简单脚本，而是：
- 50+ 个 AI 智能体（AI Agent）同时跑系统级编程（C 语言、MLIR、GPU 驱动）
- 单次自主运行 30+ 分钟，涉及多文件协同修改
- 项目有 5000+ 字的专属编码规范文档（
CLAUDE.md） - 代码审查、任务管理、迭代调试一条龙
- 在“好时期”，一个周末就能合并
19.1 万行高质量代码
深度思考让模型能够：
- 在行动前规划多步策略（先读哪个文件？按什么顺序？）
- 回忆并应用项目专属规范（比如”变量名不能缩写”）
- 在输出前自我检查，提前发现逻辑漏洞
- 判断任务是否真正完成，决定继续还是暂停
- 在数百次工具调用中保持推理连贯性
然而，当思考变浅时，模型会本能选择“最省力的动作”。
不读就改、没做完就停、出问题就甩锅、选“最简单”而非“最正确”的方案。
这正是用户反馈的所有症状。
思考缩水后的 8 种翻车行为
下面是 stellaraccident 所在团队，研究的精华附录，特意精选了 8 条。
不读就改
Editing Without Reading。
| 时期 | 未先读取就直接编辑的次数 | 占所有编辑的比例 |
|---|---|---|
| 好时期 | 72 | 6.2% |
| 过渡期 | 3,476 | 24.2% |
| 退化期 | 5,028 | 33.7% |
这带来的后果是：1/3 的修改是“盲改”。破坏周边代码、违反文件约定、把新代码插进注释块中间、重复实现已有逻辑。
推理死循环
Reasoning Loops。当思考深度不足，模型无法在内部解决矛盾，只能把纠结过程暴露给用户：
“哦等等”、”其实吧”、”让我再想想”、”嗯不对”、”重来重来”……
| 时期 | 每千次工具调用中的“自我打脸”次数 |
|---|---|
| 好时期 | 8.2 |
| 退化期 | 21.0 |
| 后期 | 26.6 |
数据显示增长超 3 倍！最差的会话里，单次回复出现 20+ 次自我否定，输出完全不可信。
最简单就行心态
当模型开始频繁说“最简单的方法”（Simplest Fix Mentality），往往意味着它在偷懒。
| 时期 | 每千次工具调用中“simplest”出现次数 |
|---|---|
| 好时期 | 2.7 |
| 退化期 | 4.7 |
| 后期 | 6.3 |
真实案例表明，2 小时内模型说了 6 次“用最简单的方法”，结果后续自我承认这些代码“偷懒且错误”、“赶工”、“粗糙”。
提前收工 + 疯狂请示
stellaraccident 所在团队写了一个脚本 stop-phrase-guard.sh 来自动检测这些“想偷懒”的话术。
| 类别 | 3 月 8-25 日触发次数 | 典型话术 |
|---|---|---|
| 甩锅 | 73 | “这不是我改的”、“本来就是坏的” |
| 请示 | 40 | “要我继续吗？”、“还要我做吗？” |
| 提前停 | 18 | “这里停挺合适”、“天然断点” |
| 贴标签 | 14 | “已知限制”、“留待未来” |
| 找借口 | 4 | “开新会话继续吧”、“太长了” |
| 合计 | 173 | |
| 3 月 8 日前 | 0 |
这个脚本本身的存在，就是退化的证据，好时期根本不需要它。
用户被迫手动打断
用户按 Escape 键打断模型，说明“你干错了，停！”，对应的统计数据如下表格所示。
| 时期 | 每千次工具调用的打断次数 |
|---|---|
| 好时期 | 0.9 |
| 退化期 | 5.9 |
| 后期 | 11.4 |
数据显示，增长 12 倍！每次打断都意味着：用户停下自己的工作 → 读模型输出 → 找错误 → 想修正方案 → 重新指挥。这正是 AI 智能体本该帮人类省掉的活儿。
模型自己承认我搞砸了
退化期，模型被纠正后，常会自我检讨。
你说得对，那确实偷懒且错误。我在回避代码生成器的问题，而不是解决它。
你说得对，我赶工了，结果很明显。
你说得对，我确实粗糙了。CPU slab 提供者的预取逻辑是实打实的工作。
| 时期 | 每千次工具调用中自我承认错误的次数 |
|---|---|
| 好时期 | 0.1 |
| 退化期 | 0.3 |
| 后期 | 0.5 |
模型其实知道什么是好代码，只是没预算（思考令牌）去做检查了。
同一文件反复修改
短时间内对同一文件修改 3+ 次，往往是“试错”而非“规划”：
改 → 失败 → 再改 → 又失败 → 再再改……
好时期也有反复修改，但区别在于：好时期是“读-想-改-再读-再改”的有意识迭代；退化期是“盲改-报错-再盲改”的无头苍蝇。
规范漂移（Convention Drift）
项目有 5000+ 字的 CLAUDE.md 规范文档，好时期模型能稳稳遵守。
退化后出现：
- 变量名又用缩写（
buf,len），尽管规范明确禁止 - 清理模式违规（该用
goto的地方用了if链） - 删除代码后，相关注释没清理
- 出现“第二阶段”、“后续完成”等被明令禁止的临时标记
不是模型“不知道”规范（规范就在上下文里），而是没思考预算去逐条核对。2200 字符的思考空间，够它默念“检查命名、检查清理模式、检查注释风格”；500 字符？不够。
彩蛋发现
一天中不同时段，模型“智商”还不一样？
社区有人猜“美国工作时间质量差”，他们用数据验证。
关键发现
- 下午 5 点（太平洋时间）是最差时段：估算思考长度仅 423 字符（有足够样本的时段中最低）
- 晚上 7 点是第二差：373 字符，且样本量最大（1031 条）
- 深夜 10 点 – 凌晨 1 点有回升：759-3281 字符，可能是平台负载低
这表明，思考分配可能受系统负载影响，而非固定配额。好时期（思考充足时），时段差异几乎不存在；现在差异变大，恰恰说明思考资源在被“动态调配”。
附录
退化带来的真实成本——省了小钱，亏了大钱。
令牌消耗对比（2026 年 1-3 月）
| 指标 | 1 月 | 2 月 | 3 月 | 2 月→3 月变化 |
|---|---|---|---|---|
| 活跃天数 | 31 | 28 | 28 | — |
| 用户提问数 | 7,373 | 5,608 | 5,701 | ≈1 倍 |
| API 请求数 | 97 | 1,498 | 119,341 | ↑80 倍 |
| 总输入令牌 | 4.6M | 120.4M | 20,508.8M | ↑170 倍 |
| 总输出令牌 | 0.08M | 0.97M | 62.60M | ↑64 倍 |
| 估算 Bedrock 成本 | $26 | $345 | $42,121 | ↑122 倍 |
| 估算日均成本 | — | $12 | $1,504 | ↑122 倍 |
| 实际订阅费 | $200 | $400 | $400 | — |
注：1 月数据不完整，实际用量更高
为什么 3 月成本爆炸？
- 合理扩容：项目增多、并发智能体增多（约 5-10 倍）
- 退化浪费：试错、重试、人工纠正（额外 10-15 倍）
- 灾难性损失：原本能周末合并 19 万行代码的多智能体工作流，彻底瘫痪
最扎心的是：用户提问数几乎没变（5608 → 5701），但模型消耗的 API 请求多了 80 倍、输出令牌多了 64 倍，产出质量却更差。
人类付出一样多，模型浪费一切。
4 条务实建议
- 透明化思考分配：如果思考令牌被削减或封顶，请告诉依赖深度推理的用户。
redact-thinking让外部无法验证。 - 推出“最大思考”档位：复杂工程用户愿意为 guaranteed deep thinking（保证的深度思考）付更多钱。当前订阅制无法区分“需要 200 思考令牌”和“需要 20000”的用户。
- 在 API 响应中暴露思考指标：即使内容隐藏，至少返回
thinking_tokens数值，让用户监控推理深度是否达标。 - 建立“金丝雀指标”：像我们写的 stop hook 违规率（0 → 10 次/天）这样的机器可读信号，可作为全平台质量退化的早期预警。
社区回声（精选评论）
eljojo：惊人的分析！作为用户，这几周我也隐约感觉到不对劲，但说不清。“先调研→再动手”变成“边猜边改”这点太戳我了，我最近一直在调
CLAUDE.md想抵消这问题，原来根子在这儿。bbecausereasonss：你们用数据证明了我们一直在说的！
ewaltd：标题该改成《Claude 退化到连
任何工程任务都不能信任了》。它现在第一次几乎永远做不对，代码里全是 bug 和重复，必须全程盯着，否则必出问题。可惜了。suzuenhasa：非常好的分析，完全符合我的体验。12 月时它还挺棒——不完美，但能用。最近坏日子远多于好日子。我也以为是自己疯了，或者漏了什么设置，直到发现
它真的没在思考，至少我看不到了。gbaraldi：做类似项目（LLVM/MLIR/编译器），被“这里适合停一下”搞到崩溃。它提交了十几个无用 commit，整体感觉就是“变笨了”。
临时解决方案
有意思的是，这份临时解决方案来自于 Anthropic 官方回复。
bcherny（Anthropic 团队成员）回复道。
我们内部全程用 1M 上下文，评估结果也 OK。大家可以试试：
- 设置
/effort high或/effort max提高单次问题最大思考令牌 - 设置
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000强制缩短上下文窗口 - 设置
CLAUDE_CODE_SIMPLE=1简化模式（适合简单任务）
欢迎反馈哪种组合体验最好
结语
这不是抱怨，而是一份“诊断书”。这份报告不是为了指责，而是希望：
- 帮助开发团队“用数据定位问题”，而非依赖模糊反馈
- 为重度用户争取“可配置的推理深度”
- 推动行业建立“可量化的 AI 智能体质量指标”
思考令牌不是“锦上添花”，而是复杂工程工作流的“承重结构”。当我们要求大语言模型做资深工程师的活，就得给它资深工程师的“思考时间”。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Claude Code 变了，一份 6852 个会话日志扒出的摸鱼真相