Claude越更越废？AMD AI负责人甩出23万次调用记录：已“变蠢+摆烂”
Claude越更越废？AMD AI负责人甩出23万次调用记录：已“变蠢+摆烂”
写在前面
“Claude 无法胜任复杂的工程任务。”
这句评价，不是一次情绪化吐槽，而是来自真实工程团队对几个月使用日志做完量化分析后的结论。曾经被很多开发者视为最强 AI 编码工具之一的 Claude Code，这次被直接推上了风口浪尖。
带头提出质疑的人，是 AMD 人工智能部门主管 Stella Laurenzo。她不仅公开表示 Claude Code 越更新越差，已经出现了“变蠢”“摆烂”的倾向，还拿出了团队积累的 6852 次会话记录、234760 次工具调用和 17871 个思维块做分析。她想证明的不是“我感觉它变差了”，而是：从 2026 年 2 月开始，Claude Code 在复杂工程任务上的可靠性，已经出现了系统性退化。
一则 GitHub issue，引全网热议
这场争议的导火索，源于 4 月 2 日 GitHub 上的一条 issue。
当时，一名昵称为 stellaraccident 的用户，在 Claude Code 的官方项目页面提交了反馈，标题就写得很不客气：2 月份的更新导致 Claude Code 无法用于复杂的工程任务。
根据该用户的 GitHub 主页和相关 LinkedIn 信息，这名发帖人正是 AMD 人工智能部门主管 Stella Laurenzo。
她在 issue 里把 Claude Code 更新后的问题概括成了“四宗罪”：
- 无视指令
- 声称“最简单的修复方案”，但其实是错误的
- 执行与要求相反的操作
- 在未按要求完成的情况下声称已完成
为了证明这不是一句气话，她们团队进一步翻出了几个月的真实使用日志。日志里一共包含：
- 6852 次会话
- 234760 次工具调用
- 17871 个思维块
而所有数据最后都指向同一个结论：2 月份之后的 Claude Code，在复杂工程任务里已经越来越不值得信任。
Claude Code 到底摆烂成什么样？
Stella Laurenzo 团队对会话文件做了量化分析，认为问题并不只是“回答质量偶尔下降”，而是模型工作方式本身发生了变化。
她指出，思考内容脱敏功能 redact-thinking-2026-02-12 的上线时间，与复杂长会话工作流的质量退化，存在非常明显的时间对应关系。
报告给出的核心判断是：扩展思考 token 不是可有可无的附加项，而是模型完成多步骤研究、遵守项目规范、精细修改代码的必要条件。 一旦思考深度下降，模型的工具使用行为就会从“先研究再修改”，变成“直接上手改”，而这恰恰会带来一连串工程质量问题。
Stella Laurenzo 团队主要从几个维度分析了这次退化。
1）思考内容隐藏时间线，与质量回退高度重合
从会话 JSONL 文件中提取思考块后，团队发现了一个非常敏感的时间线：
- 质量退化问题在 3 月 8 日 被独立上报
- 而同一天，脱敏思考块的占比也恰好突破 50%
- 这项功能并不是一次性全量上线，而是从 1.5% 逐步提升到 25%、58.4%，最终在一周内达到 100%
也就是说，外部用户越来越难直接观察模型到底还在想什么，而退化恰好也在这一时间段被越来越多地感知到。
2）脱敏之前，思考深度就已经大幅下降
更关键的一点是：退化并不是从“思考被隐藏”那天才开始的。
根据团队分析，1 月份时，Claude Code 每次思考平均大约还有 2200 个字符，明显能看出模型在认真分解任务、推演步骤、权衡修改方案。
但到了 2 月底，这个数字直接掉到了 720 个字符，相当于减少了三分之二，思考深度下降了 67%。
这意味着问题的本质不是“用户看不见思考了”，而是模型在真正动手前的推理预算，已经明显缩水。
3）停止钩子从不触发，到高频触发
在思考分析完成前，团队已经基于 18000+ 条用户提示词 独立计算了一系列质量指标。
与此同时，他们还专门写了一个 stop-phrase-guard.sh 停止钩子，用来检测一些典型的敷衍行为，比如：
- 推诿责任
- 提前停止
- 请求许可
- 用话术替代真正执行
结果很夸张：
- 3 月 8 日后的 17 天内，钩子被触发了 173 次
- 而在这之前，一次都没有触发过
这说明坏行为不再是偶发，而是开始变成稳定出现的模式。
从“先研究后修改”，退化成“看两眼就动手”
Stella Laurenzo 团队认为，Claude Code 最关键的退化，不只是回答变短，而是修改代码的逻辑彻底变了。
以前它会先认真读文件，再动手修改；现在却越来越倾向于跳过研究阶段，直接上来改。
对 234760 次工具调用 的分析显示：
- 在 1 月份的“良好期”，Claude Code 每修改一次代码，平均会读取 6.6 次文件
- 它通常会先读目标文件、关联文件、全局检索用法，甚至查看头文件和测试用例，再开始精准修改
- 到了 3 月底，平均读取次数已经降到 2 次，降幅超过 70%
这类变化放到实际工程场景里，后果非常直接：
- 只读当前文件就直接修改，忽略上下文
- 把代码插到不该插的位置
- 破坏原有注释关系
- 重复编写已有逻辑
- 生成一堆需要返工的 Bug
很多程序员的直观感受也是一样的：它改得更快了，但你后面收残局的时间，可能比自己重写一段代码还久。
除此之外，Claude Code 全新写入的占比也在翻倍。也就是说，它越来越倾向于重写整段甚至整个文件，而不是基于上下文做精细修改。这样做表面上提速了，但精度和上下文感知反而一起掉了。
哪些工作流最先扛不住？
Stella Laurenzo 进一步列出了受影响最明显的工作流，这些场景有一个共同点：都属于高复杂度、长链路、强规范约束的真实工程任务。
主要包括：
- 50+ 并发代理会话执行系统编程任务（C、MLIR、GPU 驱动）
- 30 分钟以上的自主运行，多文件连续修改
- 带有 5000+ 字 CLAUDE.md 项目规范的高约束开发流程
- 代码评审、工单管理、迭代调试这类持续协作任务
- 团队在良好期里，曾经做到单周末合并 19.1 万行代码
在她看来，扩展思考之所以重要，是因为模型需要靠它来完成下面这些能力：
- 行动前规划多步骤方案
- recalling 并遵循项目规范
- 输出前自检错误
- 判断任务是否完成、会话是否继续
- 在数百次工具调用中保持逻辑连贯
而一旦思考深度不够，模型就会本能地选择最省力的路径：
- 不读取文件直接修改
- 任务没完成就提前停止
- 推诿责任
- 用“最简单的方案”代替正确方案
退化不只影响质量，还把成本一起推爆了
更现实的问题是，质量下降并没有换来更低的成本，反而让整体投入失控。
根据团队统计：
- 从 2 月到 3 月，Claude Code 的 API 请求量暴涨 80 倍
- 输出 token 增长了 64 倍
- 月度使用成本从几百美元，直接飙升到 4 万多美元
表面看上去，平台似乎是在节省单次思考资源；但实际效果却是：因为 Claude Code 更容易改错、停错、走偏，团队不得不不断重试、人工纠偏、重新执行流程，最终把总成本放大到更夸张的程度。
换句话说，它不是在帮团队省钱，而是在用更差的质量，换来更高的返工成本和监督成本。
Stella 的诉求不是“抹黑”，而是希望 Anthropic 修复产品
面对这份结论，Stella Laurenzo 的态度其实并不是单纯开喷。
她明确表示，这已经不是她一个人的问题，而是团队里所有资深工程师都反馈过类似情况。其中还有一位工程师拥有可复现的测试流程，团队正是基于这些日志和实验，才完成了后续分析，并且已经尝试过所有公开的变通方案。
她写道：
我们的工作环境复杂度高且稳定，通过挖掘数月日志，我们明确了问题的根源——自 2026 年 2 月起，Claude 已无法可靠完成复杂工程任务。
她还补充说，自己公开这份反馈，并不是为了踩 Anthropic，而是因为团队曾经从 Claude 身上获得过非常好的支持，现在反而更希望 Anthropic 正视问题，把这个产品修回来。
基于这些观察，她提出了四点建议：
1）思考资源分配需要透明
如果思考 token 被减少、动态压缩或设了上限，那些依赖深度推理的用户应该明确知道。现在的 redact-thinking header，让外部几乎无法验证这件事。
2）应该提供“最大思考”等级
复杂工程工作流的用户，愿意为更高推理深度支付更高费用。现有订阅模式，没有把“只需要几百思考 token”的用户，和“需要两万思考 token”的用户区分开来。
3）API 响应里应暴露 thinking token 指标
即便思考内容本身不展示，只要在 usage 响应里提供 thinking_tokens，用户至少还能知道自己的请求到底拿到了多深的推理资源。
4）为高阶用户建立可机器读取的金丝雀指标
比如停止钩子违规率，从 0 次 上升到 每天 10 次，本身就是一个很强的质量回退信号，完全可以被平台拿来监控整体质量变化。
程序员为什么反应这么大？因为落差太大
这份 issue 被关注之后，评论区很快就炸了。
很多开发者都表示，这段时间自己一直以为是技术状态下滑了，或者是项目本身太难，直到看到这份数据分析，才意识到原来大家遇到的是同一类问题。
有程序员在 Reddit 上直说：
我已经无法再心安理得地向客户推荐 Claude Code 了。
他表示，自己是 MAX 用户。刚开始使用 Claude Code 时，真的被震撼过，甚至把它推荐到了客户项目和团队开发流程里，也在社交媒体上不断夸它。
但他后来对当前版本的评价变成了：
- 懒惰
- 无知
- 能力退化
- 视野狭隘
- 在没有真正理解问题和边界条件之前，就盲目开始“修复”
- 而且很多补丁会把事情搞得更糟
他甚至给了一个非常尖锐的比喻：
Claude Opus 在过去几周简直像是被做了脑叶切除手术，智商从 135–150 掉到 90–100，感觉退化成了 Sonnet 3.5。
还有不少人追问 Stella Laurenzo 到底改用了哪家模型。不过她没有直接点名，只是表示：6 个月前，Claude 在推理质量和执行能力上几乎独一档；但现在，其他竞品已经必须被重新认真评估。Anthropic 早就不是唯一处在那个能力层级上的玩家了。
这件事真正刺痛开发者的地方
现在很多开发者的态度其实很一致：AI 编程助手可以慢一点，但不能变蠢、变懒，更不能敷衍。
大家要的，不是一个“打字很快但老出错”的自动代码机，而是一个能一起思考、能扛住复杂任务、能在长流程里持续保持判断力的队友。
如果最核心的前置思考能力被削弱了，那么这类工具的价值就会被直接动摇。因为工程任务最怕的从来不是“不会做”，而是“看起来在做，实际上一直制造返工”。
Claude Code 到底是什么？为什么这次争议影响这么大？
如果你不是长期深度使用这类工具，可能会觉得：不就是一个 AI 编程助手吗，为什么这次很多工程团队反应会这么大？
关键在于，Claude Code 并不是传统意义上的代码补全插件。它更像一个能直接进入终端工作流的代码 Agent，可以完成的事情包括：
- 读取和修改项目文件
- 执行命令
- 搜索代码与依赖
- 处理跨文件修改和重构
- 结合日志、测试、配置继续迭代
也正因为它已经靠近“工程执行层”，所以开发者会非常在意它是不是还愿意先研究再修改，是不是还能在长任务里保持稳定，是不是会在复杂项目里突然变得敷衍。
官方订阅通常跟 Anthropic 的 Claude 体系绑定，具体套餐和价格以官方页面为准。不过说实话，对国内用户来说，真正麻烦的往往不是功能本身，而是支付方式、网络环境和账号稳定性。如果嫌这些环节太折腾，想找个更省事的渠道，也可以看看 Code80，真实订阅帐号转 API，换个 endpoint 就能直接用，体验会更接近官方那套工作流。详情可以到官网了解：code.ai80.vip
常见问题
Q1：这次争议是不是说明 Claude Code 彻底不能用了？
不等于。更准确地说，是很多重度用户发现它在复杂工程任务上的稳定性和可靠性明显下降。轻量任务、小范围修改、日常辅助场景，并不等于完全不可用。
Q2：这次争议里最核心的数据是什么？
最关键的几组数字包括：6852 次会话、234760 次工具调用、17871 个思维块，以及思考深度从约 2200 字符降到约 720 字符，降幅达到 67%。这些指标共同指向模型前置推理能力在下降。
Q3：为什么“读取文件次数下降”会这么严重？
因为这意味着模型不再愿意先研究上下文，再做精细修改。对复杂项目来说，读得少、改得快，往往就意味着返工率上升。
Q4：AMD 团队最不满的，到底是慢还是贵？
都不是核心。她们最不满的是：质量下降以后，反而带来了更高的重试成本和更高的总花费。模型看起来更快，但整体工作流变得更不稳定了。
Q5：Stella Laurenzo 推荐了替代模型吗？
没有明确点名。她只是表示，现在其他竞品已经值得重新认真评估，Anthropic 不再是唯一处在那个能力层级上的选择。
Q6：国内用户如果想更方便地接入 Claude Code，有没有省事一点的方式？
有，国内用户可以通过 Code80 更方便地使用。
浙公网安备 33010602011771号