Claude Code 又笨又懒！被 AMD AI 负责人抛弃。。。

AMD AI 团队负责人公开炮轰 Claude Code：复杂工程任务“已无法信任”，Anthropic 再陷产品与透明度争议。

Anthropic 旗下编程工具 Claude Code，正在遭遇一场来自高阶开发者群体的公开信任危机。

2026 年 4 月 2 日，GitHub 上出现一条题为“Claude Code 无法胜任复杂工程任务”的问题单，发帖者称，在长期、高复杂度的软件工程环境中，Claude Code 自 2 月以来出现明显退化，已经下降到“不再能被信任处理复杂工程技术任务”的程度。

该问题单随后在开发者社区持续发酵。

该用户的 GitHub 个人资料和相关的 LinkedIn 帖子显示该发帖人是 AMD 的 AI 团队主管 Stella Laurenzo。

“Claude Code 根本无法胜任复杂的工程技术任务，” Laurenzo 写道，并指出其团队通过查阅数月来收集的日志得出了这一结论，这些日志来自他们使用 Claude Code 的“高度稳定且高度复杂的工作环境”。Laurenzo 补充道：“我团队中的每位高级工程师都反映过类似的经历/遭遇。”

这份指控并非停留在“体感变差”的层面，而是附带了一整套基于历史日志的量化分析。

GitHub 原帖给出的数据称，团队分析了 6,852 个 Claude Code 会话文件、234,760 次工具调用，以及 17,871 个 thinking blocks。

结论是，从 2 月中旬到 3 月，Claude Code 在复杂、长时程工程工作流中的表现出现了可测量的下滑。

按照问题单中的说法，这种退化最直观的表现，是模型越来越少做“先研究、再下手”的工作。

日志分析显示，Claude 在修改代码前读取文件的频率大幅下降。

每次编辑前的平均读取次数，从 1 月底到 2 月上旬的 6.6 次，下降到 3 月中下旬的 2.0 次，降幅约 70%。

与此同时，模型更频繁地直接改写整个文件，而不是做局部、精确的编辑。这意味着它在复杂工程任务中更像是在“抢答”，而不是在充分理解上下文后再动手。

原帖还给出了另一组更刺眼的数据。

团队自建了一个用于捕捉“偷懒式停止”“推卸责任”“过度请求许可”等行为的 stop hook。

结果显示，3 月 8 日之前，这类违规在历史中是 0 次；3 月 8 日之后，17 天内触发了 173 次，折算下来平均接近每天 10 次。

与之同步上升的，还有用户提示词中的“挫败感指标”，以及模型出现 reasoning loops 的会话数量。

Laurenzo据此认为，Claude Code 在复杂工作流中的“思考深度”明显下降，以至于模型开始系统性地选择成本最低、但并不正确的动作：不先读代码就改、任务未完成就停、遇到问题先甩锅、优先给出最省事的修复方案。 

被鞭子抽打的 Claude Code：

这份分析把矛头对准了一个时间点，Claude Code 的 thinking 内容脱敏或隐藏策略变化。

Laurenzo 表示，所有这一切表明 Claude Code 的思考不够深入，并且这一情况与3月初 Claude Code 2.1.69 版本部署思考内容脱敏功能同时出现。思考内容脱敏功能以标头的形式出现，默认情况下会从 Claude Code API 响应中移除思考内容，这意味着用户无法了解 Claude Code 在思考请求时实际执行的操作。

thinking blocks 的可见性在 3 月上旬快速下降，3 月 12 日之后几乎变成 100% redacted；而质量下滑的时间窗口，与这轮 rollout 高度重合。

Laurenzo 据此提出质疑，Anthropic 是否在后台减少了 thinking token 的分配，或者对复杂工程场景的推理深度进行了限制，只是用户因为 thinking 内容被隐藏，已经很难直接观察到。

Anthropic 官方文档显示，在 Claude 4 系列的 API 中，extended thinking 默认返回的是“总结版 thinking”，而非完整原始 thinking；文档同时明确表示，用户仍然会按完整 thinking tokens 计费，且 summary 行为本身也可能继续调整。另一份官方更新记录还显示，Claude Code 后续版本已将 interactive sessions 中的 thinking summaries 改为默认不再显示，用户需要手动开启 showThinkingSummaries: true 才能恢复。也就是说，官方确实在近期对 thinking 的展示方式做了调整，但“展示减少”是否等于“实际思考变浅”，官方并未承认。

这正是此次争议的核心所在。

对于大量普通用户来说，thinking 被隐藏，更多只是可解释性变弱；但对于依赖 Claude Code 承担复杂软件工程任务的团队来说，问题不只是“看不见过程”，而是无法确认模型是否真的拿到了足够的推理预算。

更微妙的是，这场产品口碑风波，发生在 Anthropic 一连串负面事件之后。

3 月 31 日，Anthropic 因一次发布打包失误，意外将 Claude Code 大规模内部源码暴露到公共软件仓库。

这次事件涉及近 2,000 个文件、约 500,000 行代码；外界从泄露代码中看到了更多未发布功能、内部指令和“常驻后台代理”等设计线索。

Anthropic 事后回应称，这属于“人为错误导致的发布打包问题”，并非外部安全入侵，也没有客户数据或凭证泄露，但这起事件依然引发了对其工程流程和运营成熟度的质疑。

与此同时，Claude Code 的配额与 token 消耗问题也在同步发酵。

Anthropic 已承认“用户触及 Claude Code 使用上限的速度比预期快得多”，并表示团队正在调查。

在短短一周左右的时间里，Anthropic 一边要处理源码泄露带来的工程与品牌压力，一边又要回应开发者对配额异常、复杂任务能力下滑、thinking 不透明的连续质疑。

过去半年，Claude 在开发者圈中一度建立起很强的口碑，尤其是在长链路执行、多文件修改、系统工程类任务中的表现，被不少工程师视为头部水准。

Laurenzo 希望 Anthropic 能够公开透明地说明其是否减少或限制了思考 token 的数量，从而导致 Claude Code 输出垃圾结果。至少，她希望 Claude Code 能公开每次请求使用的思考 token 数量，以便用户“监测他们的请求是否获得了所需的推理深度”。

Laurenzo 还要求 Anthropic 为运行复杂工作流程的工程师增设一个最高思考级别的选项。这位 AMD AI 主管解释：“目前的订阅模式无法区分每次响应需要 200 个思考 token 的用户和需要 20000 个思考 token 的用户。运行复杂工程技术工作流程的用户愿意为有保障的深度思考支付更高的费用。”

“我们已换成了另一家供应商，他们提供的服务质量更优，不过 Claude 一直对我们不错，我们离开是希望 Anthropic 能够改进其产品，”Laurenzo 解释道，同时以保密协议为由，拒绝透露其团队所使用的新工具的具体细节。尽管如此，Laurenzo 还是警告 Anthropic，AI 编程领域仍处于早期阶段；如果 Anthropic 一意孤行、不思改进，很可能会失去领先地位。

“我只想补充一点，6 个月前，Claude 在推理质量和执行方面独占鳌头，”Laurenzo 在问题单讨论帖中回复道。“但也需要密切关注和仔细评估其他 AI 开发商。在 Claude Opus 之前占据的能力层级上，Anthropic 绝非独此一家。

对 Anthropic 来说，这才是最危险的信号。

当最懂产品上限的重度用户开始迁移，失去的可能不只是口碑，而是整个 AI 编程赛道最核心的一批标杆客户。 

在 AI 编程工具进入工程化竞争阶段之后，开发者最在意的，不只是模型能不能写代码，而是它在复杂任务里是否稳定、是否透明、是否可预期。只要这三个问题回答不好，再强的模型，也很难长期保住“可被信任”的位置。

原帖：

参考链接：https://github.com/anthropics/claude-code/issues/42796

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。