Claude Code越更越废？！大厂AI主管公开怒喷思考深度暴跌，官方回应更被怼爆 ：菜成AI“玩具”

整理 | 华卫

“Claude Code 在 2 月份更新后无法用于复杂的工程任务。”近日，一条这样的帖子在热门开发者论坛上引发热议，甚至让 Anthropic 的 Claude Code 负责人 Boris Cherny 亲自“出现”来做回应。

溯源之后我们发现，这一言论最早是在一位开发者在 Claude Code 的 Github 主页上提交的 issue，且附上的分析报告基于挖掘了三个月的 Claude 会话日志数据得出，包含的角度及内容都十分详尽。

而根据这位开发者在 Github 主页上的名字 Stella Laurenzo 及相关的 Linedln 帖子，该开发者还是 AMD 的 AI 团队主管。

思考深度下降 67%，

算力消耗增加几个数量级

先来看看 Laurenzo 发布的分析报告。该报告由 Claude Opus 4.6 基于其 2026 年 1 月 30 日至 4 月 1 日的会话日志数据生成，对 6852 份 Claude Code 会话文件中的 17871 个思考模块与 234760 次工具调用进行量化了分析后给出结论：redact-thinking-2026-02-12 的上线，与复杂、长会话工程工作流中可观测到的质量下降呈现精准关联。

并且，数据表明，扩展思考 token 并非 “锦上添花” 的功能，而是模型完成多步骤研究、遵循规范、审慎修改代码所必需的结构性要素。当思考深度被削减时，模型的工具使用模式会出现可测量的转变，从 “优先研究” 转向 “优先编辑”，进而引发用户反馈的各类质量问题。

在展开分析前，报告中表示，“分析通过数据帮助 Anthropic 明确受影响最显著的工作流及其成因，旨在为高权限用户的思考 token 分配决策提供依据。”

一是思考内容屏蔽时间线与质量下降高度吻合，这基于会话 JSONL 文件中的思考模块分析。此次质量下降问题于 3 月 8 日被独立上报，而这一天恰好是 redacted thinking 占比突破 50% 的日期，其上线节奏（一周内从 1.5% 逐步升至 25%→58%→100%）与分阶段灰度发布的特征完全吻合。

二是思考深度在 redacted thinking 前已呈下降趋势，思考模块中的特征字段与思考内容长度的皮尔逊相关系数达 0.971（基于 7146 组同时包含二者的配对样本测算）。即便在 redacted thinking 后，仍可据此估算思考深度。截至 2 月下旬，在 redacted thinking 启动之前，思考深度就已下降约 67%。3 月初上线的 redacted thinking 处理，让这一变化对用户变得不可见。

三是行为影响，这些可量化的质量指标均在开展思考分析之前，基于 18000+ 条用户提示词独立计算得出。其专门编写了拦截脚本（stop-phrase-guard.sh），用于自动检测模型回避责任、过早终止任务、反复请求授权确认等行为。该脚本在 3 月 8 日之后的 17 天内触发了 173 次，而在此之前触发次数为零。

四是工具使用模式转变：优先查阅 → 优先编辑，对 234760 次工具调用的分析显示，模型不再先阅读代码再进行修改。模型从每次编辑对应 6.6 次查阅降至 2.0 次，修改前的调研行为减少了 70%。在表现良好的阶段，模型工作流为：读取目标文件 → 查阅相关文件 → 在代码库中检索调用关系 → 阅读头文件与测试代码 → 再进行精准修改。而在性能退化阶段，模型仅读取当前文件便直接编辑，常常不检查上下文环境。

报告称，研究力度的下滑始于 2 月中旬，与估算思考深度下降 67% 的时间段完全吻合。同时，整文件写入的使用量翻倍，模型越来越倾向于重写整个文件，而非进行精准的局部修改；这种方式速度更快，但会丧失精确性与上下文感知能力。

并且，“减少思考次数看似能节省每次请求的算力。但一旦思考不足导致输出质量下降时，模型就会崩溃：生成错误结果、被中断、不断重试，并在后续修正中消耗大量 token。而这些修正原本在第一次就正确思考的情况下是不需要的，最终结果却是，整体算力消耗增加了几个数量级。”

据悉，受影响的工作流包含多个场景：50 余个并发智能体会话，从事系统编程（C、MLIR、GPU 驱动）；30 分钟以上自主运行，执行复杂的多文件修改；大量项目专属规范（长达 5000 余词的 CLAUDE.md）；代码评审、需求 / 工单管理与迭代调试；表现良好阶段，曾在一个周末内通过两个合并请求合入 19.1 万行代码。

Laurenzo 强调，“扩展思考是高级工程师工作流程的支柱”。她表示，扩展思考是模型实现以下能力的核心机制：行动前规划多步方案（读取哪些文件、按什么顺序）、从 CLAUDE.md 中调取并应用项目规范、在输出前自行发现错误、判断继续执行还是终止（会话管理）、在数百次工具调用中保持连贯推理。

“当思考深度不足时，模型会倾向于选择成本最低的行为：不阅读就编辑、未完成就终止、为失败推诿责任、采用最简单而非正确的修复方案。这些正是实际观测到的问题表现。”这是该开发者最终给出的判断。

为此，她提出以下四点改进建议。

• 思考资源分配透明化：若思考 token 被削减或设限，依赖深度推理的用户应知情。当前的思考内容脱敏头部导致外部无法验证。

• “最大思考量” 付费档位：运行复杂工程工作流的用户愿意支付更高费用，以获得稳定的深度思考能力。现有订阅模式未区分单次需 200 思考 token 与需 20,000 思考 token 的用户。

• 在 API 响应中返回思考 token 指标：即便思考内容被脱敏，在用量响应中暴露 thinking_tokens 字段，可让用户监控请求是否获得所需推理深度。

• 来自重度用户的预警指标：拦截脚本触发率（从 0 升至日均 10 次）可作为机器可读信号，在全用户群中监测，作为质量下降的先行指标。

开发者骂疯了：

退化为一个 AI“玩具”

对于这份分析报告，不少开发者表示了强烈的认同。“分析得太棒了。作为用户，我过去几周也遇到了这个问题，但一直找不到原因。”“完全证实了我们一直以来所说的！”“这与我使用 Claude 的经历非常吻合，尤其是在过去的几个月里。”“原来不止我一个人这样。”

甚至有几位个人开发者认为，Claude Code 的水平已经下降到一年以前。“过去一个月我对 Claude Code 越来越失望，它经常胡说八道，还信誓旦旦地解释一些我知道是错的原理。感觉就像在用去年的 Claude Code 一样。”“我使用 Claude Code 已经 8 个月了，但现在模型质量的下降程度让我非常惊讶。不仅 token 使用量激增，而且最新 Opus 和 Sonnet 模型生成的代码质量也远低于我去年 12 月的水平。”

还有开发者称，“不止复杂工程任务，Claude 已经退化到无法信任其执行任何工程任务的地步了。它从来不会第一次就把事情做对，代码中充满了错误和重复代码，必须时刻监视它，否则它就会搞砸一切。Claude 已经沦为又一个人工智能‘玩具’了，真可惜。”

值得关注的是，某位采用 Claude 的企业技术团队负责人，就此给出了更为尖锐的评价。

我对此并无异议，而且我其实还有更复杂的内部分析。但我也在尽量谨慎发言，只谈论我本人能够证实的事情。我曾多次告诉我的团队，“挫折在所难免，供应商发布糟糕版本也不是第一次了”。然而，这次的退步非常严重，我想我们都在观察 Anthropic 会如何处理。归根结底，我需要一个值得信赖的工程工具合作伙伴，这一点对智能体本身和智能体的开发者同样适用。如果他们能从现在的状况中把产品拉回正轨，我会密切关注，并在看到他们的实际行动之前保留意见。

我受多项保密协议约束，只能透露我能说的有限信息。我只想再补充一点：六个月前，Claude 在推理质量和执行能力上还是独一档的存在但其他竞品现在也需要被密切关注和仔细评估。在 Opus 此前所处的能力梯队中，Anthropic 早已不再是唯一的玩家。

Claude Code 负责人回应被驳，

反给 Codex“送人”？

事态不断发酵，加入这场讨论的开发者越来越多，Claude Code 负责人 Boris Cherny 也注意到了，并于几个小时前亲自在 Github 和论坛都发帖回应了情况。

您好，感谢这份详尽的分析。在继续沟通之前，我想先表达对其中展现的深度思考与严谨态度的认可。这份报告内容丰富，我将尝试逐一拆解说明。核心问题主要集中在两点：

关于 redact-thinking-2026-02-12

该测试版头部配置仅在界面中隐藏思考过程，因为绝大多数用户并不会查看这部分内容。它不会影响模型实际的思考行为，也不会改变思考配额或底层扩展推理机制，属于纯界面层面的改动。

在底层实现中，启用该头部可以省去生成思考摘要的步骤，从而降低延迟。你可以在 settings.json 中设置 showThinkingSummaries: true 退出该模式（详见文档）。

如果你分析的是本地存储的会话记录，在该头部启用的情况下将不会保存原始思考内容，这很可能对分析结果产生了影响。Claude 在本次分析中观察到会话记录缺少思考内容，可能并未意识到思考过程实际仍在进行，只是未对用户展示而已。

关于 “截至 2 月下旬思考深度已下降约 67%”

我们在 2 月份确实落地了两项可能对此产生影响的改动，且均经过审慎评估：

2 月 9 日：Opus 4.6 版本发布 → 默认启用自适应思考机制 Opus 4.6 支持自适应思考，这与此前采用的固定思考配额机制不同。在该模式下，由模型自主决定思考时长，整体效果普遍优于固定配额方案。可通过 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING 退出该机制。

3 月 3 日：Opus 4.6 默认思考强度设为中等（85）我们发现，强度值 85 在智能水平、延迟与成本之间达到了对大多数用户而言的最优平衡点，能够在提升 token 效率的同时降低延迟。我们的产品原则之一是避免擅自更改用户设置，理想情况下本应从一开始就将默认值设为 85。由于我们认为这是一项关键调整，因此采取了以下方案：

1. 上线时伴随弹窗提示，让用户知晓变更并可选择退出

2. 在用户首次打开 Claude Code 时显示当前强度值，避免产生困惑

部分用户希望模型进行更长时间的思考，即便这意味着更高的耗时与 token 消耗。若想进一步提升智能表现，可通过 /effort 指令或在 settings.json 中将强度设为 high。该设置会在会话间保留，也可在团队内共享。你也可以使用 ULTRATHINK 关键字为单轮对话启用高强度思考，或设置 /effort max 让本轮对话后续内容使用更高思考强度。

后续我们将测试为团队版与企业版用户默认启用高思考强度，使其直接受益于扩展思考能力，即便会带来额外 token 消耗与延迟。该默认设置同样可通过 /effort 指令与 settings.json 进行调整。

但大部分开发者似乎并不“买账”他的解释，还纷纷反驳了其论述的几个方面。

首先是 Laurenzo，她对此回复道，“需要明确的是，针对这一问题，我们已经尝试了思考强度与自适应思考的所有参数组合，并通常基于连续数天的日志进行验证。最终我们得出结论：Claude 的质量退化已经严重到无法再作为可靠协作伙伴正常使用。我们拥有足够多思考过程未被屏蔽的日志数据，可以证明：在思考过程被隐藏之前，模型性能就已经出现劣化。无论如何，你们可以按照自己的方式处理问题生命周期，但我们目前没有看到任何证据表明该问题已被修复，或可通过现有参数设置进行有效控制。”

一部分开发者表态称，“关于此事，如果 Anthropic 官方回应称一切运行正常、并无问题，那我们最终大概率将迁移至 Codex。”

也有开发者表示，“直到输出质量急剧下滑，我才意识到默认思考强度已被改为中等。为此我耗费了将近一天时间来修正问题。现在我都会把思考强度设为最高，之后就再没出现过糟糕的会话情况。恳请加入一个‘始终全力思考’的模式可以吗？”

对此，有几位开发者持有不同的看法。一位开发者说道，“我感觉最高思考强度模式反倒有点像是用力过猛，结果变得急功近利、敷衍了事，甚至出现反向效果，反而和低强度模式或劣质提示词的表现差不多了。”还有开发者指出，“问题远不止是默认思考强度被设为中等这么简单，我也认同其他人的说法，即便调至高强度模式，模型急于草草收尾的倾向也明显大幅加剧。”

Cherny 专门回复了这个问题，态度也很诚恳。他表示，“感谢反馈。为方便我们实际定位问题，麻烦您下次遇到此类情况时执行 `/bug` 指令，并在此处提交反馈编号。这样我们就能进行调试，判断是出现了异常问题，还是仍在正常波动范围内。”

就这一情况，Laurenzo 在回复 Cherny 的评论中发表了最新观点及其之后的计划。“这次引发的反响远超我的预期，之后我已删除了部分被断章取义的表述，这些内容偏离了我撰写报告时只想呈现‘客观观测结果’的初衷。正如该讨论主题开头所说，Claude 在过去数月里一直表现出色，我们也希望评估如何继续从它身上获得我们早已习惯的高质量输出。在我们此前的测试中，并未发现调整任何思考强度参数能够改变模型触发拦截规则、倾向走最简路径的问题。”

她表示，“由于这类评估必须基于真实开发场景，我们会在相关工作推进时重新试用这些设置，并提交 `/bug` 反馈记录（我们同时保留了完整会话日志，可私下共享；本次分析仅基于开源代码库上的工作内容）。”

https://news.ycombinator.com/item?id=47660925

https://github.com/anthropics/claude-code/issues/42796#issuecomment-4194703741

声明：本文为 AI 前线整理，不代表平台观点，未经许可禁止转载。

会议推荐

QCon 全球软件开发大会·2026 北京站将于 4 月 16 日 -18 日正式举办。本届大会以“Agentic AI 时代的软件工程重塑”为主题，聚焦 100+ 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。

今日荐文

你也「在看」吗？