7.0
热点
AI SCORE
工具产品2026-04-06 21:50
Claude Code 2月更新后复杂工程任务失效问题
Hacker News · github.com#Claude Code#可用性
Editor brief · 编辑速览
Claude Code 在 2 月更新后在处理复杂工程任务时出现不可用的关键问题，引发大量工程师反馈，反映工具在实际工程场景中的严重可用性缺陷。
加载时出错。请重新加载此页面。
通知：您必须登录才能更改通知设置
我已搜索过现有 Issue，以查找类似的行为报告
此报告不包含敏感信息（API 密钥、密码等）
行为问题类型
其他意外行为
您要求 Claude 执行的操作
Claude 已退化到无法被信任去完成复杂工程任务的程度。
Claude 实际执行的操作
声称采用了“最简单的修复”，但这些修复并不正确
执行了与所要求活动相反的操作
声称已按照指令完成任务
Claude 应该恢复到一月份时的表现。
Accept Edits 已开启（自动接受更改）
您能复现此问题吗？
能，每次使用相同的提示词都可以复现
相关对话
高——大量非预期更改
我们的工作环境始终具有很高的复杂度，并且我们对数月的日志进行了数据挖掘，以了解为什么——从本质上说——自二月份开始，我们注意到 Claude 执行复杂工程任务的能力有所下降。分析基于日志数据，并且所有公开已知的变通方案都已尝试过。Claude 一直以来为我们提供了很大帮助，我们在此提交这份报告，希望 Anthropic 能够解决这些问题。
这份分析由 Claude 通过分析一月至三月的会话日志数据生成。
对 6,852 个 Claude Code 会话文件中的 17,871 个思考块和 234,760 次工具调用进行的定量分析表明，思考内容隐去机制（redact-thinking-2026-02-12）的推出，与复杂、长会话工程工作流中测得的质量退化在时间上精确吻合。
数据表明，扩展思考 token 并非“有了更好”的东西，而是模型执行多步骤研究、遵循约定以及谨慎修改代码时在结构上不可或缺的。当思考深度降低时，模型的工具使用模式会出现可测量的变化：从研究优先转向编辑优先，从而导致用户所报告的质量问题。
本报告提供相关数据，帮助 Anthropic 了解哪些工作流受影响最严重及其原因，目标是为面向高级用户的思考 token 分配决策提供依据。
对会话 JSONL 文件中思考块的分析：
质量退化于 3 月 8 日被独立报告——恰好就是隐去思考块占比超过 50% 的日期。其推出模式（一周内从 1.5% → 25% → 58% → 100%）与分阶段部署相符。
思考块中的 signature 字段与思考内容长度之间存在 0.971 的 Pearson 相关系数（基于二者均存在的 7,146 个配对样本测得）。因此，即使思考内容被隐去，仍可估算思考深度。
截至二月下旬，思考深度已经下降约 67%，当时内容隐去尚未开始。三月初推出的内容隐去机制使用户无法再看到这一变化。
这些指标是在进行思考分析之前，独立根据 18,000 多条用户提示词计算得出的。
我们构建了一个停止钩子（stop-phrase-guard.sh），通过程序捕获推卸责任、过早停止以及寻求许可的行为。在 3 月 8 日之后的 17 天内，它被触发了 173 次；而在此之前一次也没有触发过。
对 234,760 次工具调用的分析表明，模型在修改代码之前不再充分阅读代码。
读取与编辑比率（每次文件编辑对应的文件读取次数）
模型从每次编辑前读取 6.6 次下降到 2.0 次——修改前的研究工作减少了 70%。
在表现良好的时期，模型的工作流是：读取目标文件、读取相关文件、在整个代码库中 grep 搜索用法、读取头文件和测试，然后进行精确编辑。在退化时期，它只读取当前文件便开始编辑，通常不会检查上下文。
Week Read:Edit Research:Mutation
──────────────────────────────────────────
Jan 26 21.8 30.0
Feb 02 6.3 8.1
Feb 09 5.2 7.1
Feb 16 2.8 4.1
Feb 23 3.2 4.5
Mar 02 2.5 3.7
Mar 09 2.2 3.3
Mar 16 1.7 2.1 ← lowest
Mar 23 2.0 3.0
Mar 30 1.6 2.6
研究投入的下降始于二月中旬——正是估算思考深度下降 67% 的同一时期。
写入与编辑对比（精确修改能力）
完整文件 Write 的使用量翻了一倍——模型越来越倾向于重写整个文件，而不是进行精确的局部编辑。这种方式虽然更快，却会损失精确性和上下文感知能力。
受影响的工作流包括：
50 多个并发的 AI 智能体会话，执行系统编程工作（C、MLIR、GPU 驱动程序）
持续 30 分钟以上、涉及复杂多文件更改的自主运行
大量项目特定约定（超过 5,000 字的 CLAUDE.md）
代码审查、bead/工单管理和迭代式调试
在表现良好的时期，一个周末内通过两个 PR 合并了 191,000 行代码
扩展思考是模型实现以下能力的机制：
在行动前规划多步骤方案（需要读取哪些文件、以什么顺序读取）
回忆并应用 CLAUDE.md 中的项目特定约定
在输出前发现自身错误
决定是继续工作还是停止（会话管理）
在数百次工具调用中保持连贯的推理
当思考较浅时，模型会默认选择成本最低的可用操作：不读文件就直接编辑、未完成任务便停止、对失败推卸责任、采用最简单而非正确的修复方案。这些正是观察到的症状。
思考分配透明度：如果思考 token 正在被削减或设置上限，依赖深度推理的用户需要知情。redact-thinking 标头使外部验证变得不可能。
思考分配透明度：如果思考 token 正在被削减或设置上限，依赖深度推理的用户需要知情。redact-thinking 标头使外部验证变得不可能。
“最大思考”套餐：运行复杂工程工作流的用户愿意支付高得多的费用，以获得有保障的深度思考。当前的订阅模式并不区分每次响应需要 200 个思考 token 的用户与需要 20,000 个思考 token 的用户。
“最大思考”套餐：运行复杂工程工作流的用户愿意支付高得多的费用，以获得有保障的深度思考。当前的订阅模式并不区分每次响应需要 200 个思考 token 的用户与需要 20,000 个思考 token 的用户。
API 响应中的思考 token 指标：即使思考内容被隐去，在 usage 响应中公开 thinking_tokens，也能让用户监控其请求是否获得了所需的推理深度。
API 响应中的思考 token 指标：即使思考内容被隐去，在 usage 响应中公开 thinking_tokens，也能让用户监控其请求是否获得了所需的推理深度。
来自高级用户的金丝雀指标：停止钩子的违规率（从 0 次增至每天 10 次）是一种机器可读的信号，可以在整个用户群体中进行监控，作为质量退化的先行指标。
来自高级用户的金丝雀指标：停止钩子的违规率（从 0 次增至每天 10 次）是一种机器可读的信号，可以在整个用户群体中进行监控，作为质量退化的先行指标。
数据源：四个项目（iree-loom、iree-amdgpu、iree-remoting、bureau）中 ~/.claude/projects/ 下的 6,852 个 Claude Code 会话 JSONL 文件
分析的思考块：17,871 个（7,146 个包含内容，10,725 个已隐去）
signature 与思考内容的相关性：基于 7,146 个配对样本计算，Pearson 相关系数（r）为 0.971
分析的工具调用：所有会话中共 234,760 次
行为指标：18,000 多条用户提示词、挫败感指标、纠正频率、会话持续时间
代理验证：流式 SSE 代理确认，当前 API 响应中没有任何 thinking_delta 事件
日期范围：2026 年 1 月 30 日至 4 月 1 日
以下行为模式是在 234,760 次工具调用和 18,000 多条用户提示词中测得的。每种行为都是推理深度降低所产生的可预测后果：由于缺乏足够的思考预算，模型会采取捷径，无法评估替代方案、检查上下文或提前规划。
当模型拥有充足的思考预算时，它会在做出更改前读取相关文件、grep 搜索用法、检查头文件并读取测试。当思考较浅时，它会跳过研究，直接编辑。
在退化时期，每三次编辑中就有一次针对的是模型近期工具历史中未曾读取过的文件。其实际后果包括：编辑破坏周边代码、违反文件级约定、将新代码插入现有注释块中间，或者重复实现文件中其他位置已经存在的逻辑。
拼接错位的注释是一个尤为明显的症状。当模型编辑一个它尚未读取的文件时，它不知道注释块在哪里结束、代码又从哪里开始。它会在文档注释与该注释所描述的函数之间插入新的声明，破坏二者的语义关联。在表现良好的时期，这种情况从未发生，因为模型总是会先读取文件。
当思考足够深入时，模型会在生成输出之前，在内部解决矛盾。当思考较为浅显时，矛盾就会以明显的自我纠正形式出现在输出中，例如：「哦，等等」「其实，」「让我重新考虑一下」「嗯，其实」「不对，等等。」
这种情况的发生率增加到了原来的三倍以上。在最糟糕的会话中，模型在单次响应里出现了 20 多次推理反转——先生成一个方案，随后否定它，再进行修改，又否定修改后的版本，最终产出的内容无法令人信任，因为整个推理过程明显缺乏连贯性。
模型输出中的「最简单」一词，是它正在以最少投入为目标进行优化，而非评估正确方案的信号。在深度思考的情况下，模型会评估多种方案并选择正确的一种。在浅层思考的情况下，它会倾向于选择最不需要推理就能自圆其说的方案。
在一次持续 2 小时的观察窗口中，模型使用了 6 次「最简单」，同时产出的代码在它后续的自我纠正中被描述为「偷懒而且错误」「太仓促」和「草率」。每一次，模型都选择了一个能够回避更困难问题的方案，例如修复代码生成器、实现正确的错误传播、编写真正的预缺页逻辑，转而采用表面的权宜之计。
具备深度思考能力的模型可以评估任务是否已经完成，并自主决定继续工作。在浅层思考的情况下，模型默认会停下来请求许可——这是成本最低的可用操作。
为捕获这些措辞并强制模型继续工作，构建了一个程序化的停止钩子。捕获到的违规行为类别包括：
这个钩子的存在本身就是性能退化的证据。在表现良好的时期，它并无必要，因为模型从未表现出这些行为。钩子中的每个短语，都是针对一次模型试图过早停止工作的具体事件而添加的。
用户中断（Escape 键 / [Request interrupted by user]）表示用户发现模型正在做错事，并将其停止。中断率越高，意味着所需的纠正越多。
从表现良好的时期到后期，中断率增加了 12 倍。每次中断都代表这样一个时刻：用户不得不停下自己的工作，阅读模型的输出，识别其中的错误，组织纠正内容，再重新引导模型——这恰恰是自主 AI 智能体本应消除的监督开销。
在性能退化时期，模型经常在被纠正后承认自己的输出质量很差。这些承认并非用户主动要求——而是在用户指出问题后，模型意识到自己此前敷衍了事：
「你说得对。那样做既偷懒又错误。我试图回避代码生成器的问题，而不是修复它。」
「你说得对——我太仓促了，结果显而易见。」
「你说得对，而且我做得很草率。CPU slab provider 的 prefault 确实需要实实在在地完成。」
在这些案例中，模型自身意识到了输出不符合标准——但这种意识只在外部纠正之后才出现。如果思考深度足够，这些错误本应在推理过程中被模型从内部发现，而不是等到输出之后。模型知道高质量工作是什么样的；它只是没有足够的预算去完成检查。
当模型在短时间内对同一文件编辑 3 次以上时，这表明它正在进行试错，而不是执行预先规划好的修改——先做一次改动，发现失败，再试一次，又以不同的方式失败。这是在工具操作层面体现出的「行动前没有充分思考」。
这种模式在所有时期都存在（在迭代改进过程中，有时确实是合理的），但关键区别在于上下文：在表现良好的时期，重复编辑是有意识的多步骤重构的一部分，而且每次编辑之间都会读取文件。在性能退化时期，则是模型在没有阅读周边代码的情况下，反复折腾同一个函数。
这些项目采用了大量记录在 CLAUDE.md 中的编码约定（超过 5,000 字，涵盖命名、清理模式、结构体布局、注释风格和错误处理）。在表现良好的时期，模型能够可靠地遵循这些约定——读取 CLAUDE.md 是会话初始化的一部分，而深度思考使模型能够在每次编辑时回忆并应用这些约定。
思考深度降低后，对约定的遵守情况出现了可衡量的退化：
尽管规则明确禁止，缩写变量名（buf、len、cnt）仍再次出现
清理模式遭到违反（使用 if 链而非 goto）
已被删除代码的相关注释仍被保留
尽管已被明确禁止，代码中仍出现了时间性表述（「Phase 2」「will be completed later」）
这些违规行为并非因为模型不知道相关约定——这些约定就在它的上下文窗口中。而是因为模型没有足够的思考预算，无法在生成每次编辑之前，逐项对照约定进行检查。拥有 2,200 个字符的思考空间时，它有余地回忆「检查命名、检查清理模式、检查注释风格」。只有 500 个字符时，则没有。
stop-phrase-guard.sh 钩子（包含在数据归档中）会匹配 5 类不良行为中的 30 多个短语。当它被触发时，会阻止模型停止，并注入一条纠正消息，强制模型继续工作。
该钩子的违规日志提供了一个机器可读的质量信号：
Violations by date (IREE projects only):
Mar 08: 8 ████████
Mar 14: 10 ██████████
Mar 15: 8 ████████
Mar 16: 2 ██
Mar 17: 14 ██████████████
Mar 18: 43 ███████████████████████████████████████████████
Mar 19: 10 ██████████
Mar 21: 28 ████████████████████████████████
Mar 22: 10 ██████████
Mar 23: 14 ██████████████
Mar 24: 25 █████████████████████████████
Mar 25: 4 ████
Before March 8: 0 (zero violations in the entire history)
这个钩子之所以存在，是因为模型开始表现出一些在表现良好的时期从未观察到的行为。钩子中的每个短语，都是针对一次具体事件添加的。这个钩子是针对思考深度降低的一种权宜之计——由于模型不再从内部发现问题，它便从外部捕获相应后果。
峰值出现在 3 月 18 日，当天共发生 43 次违规——在活跃会话中，大约每 20 分钟发生一次。那一天，模型曾 43 次尝试停止工作、逃避责任或请求不必要的许可，而且每次都被程序强制继续。
如果在整个用户群体中进行监测，这项指标可以作为模型质量的金丝雀信号。类似停止钩子所捕获的纠正突然增加（或者用户手动输入的同类措辞，例如「不，继续」「你还没做完」「这是你的改动，把它修好」），就能在用户提交错误报告之前，对思考深度退化发出早期预警。
社区报告表明，质量会随一天中的时段而变化，其中美国工作时间的表现最差。通过分析所有会话中按一天内小时数（PST）划分的签名长度，可以检验这一假设。
在思考内容被脱敏之前（1 月 30 日至 3 月 7 日），思考深度在全天各时段相对一致：
非高峰时段仅有约 10% 的小幅优势，这与负载略低的情况相符。
脱敏后（3 月 8 日至 4 月 1 日），时段模式发生逆转，而且变得更加嘈杂：
与假设相反，非高峰时段的总体思考量更低。但逐小时明细揭示了显著差异：
Hour (PST) MedSig ~Think N Notes
─────────────────────────────────────────────────────
12am 1948 736 278
1am 8680 3281 13 ← 4x baseline (very few samples)
6am 4508 1704 50 ← near baseline
7am 1168 441 344
8am 1712 647 586
9am 1584 598 678 work hours start
10am 1424 538 654
11am 1292 488 454 ← lowest work hour
12pm 1736 656 533
1pm 2184 825 559 ← highest work hour
2pm 1528 577 476
3pm 1592 601 686
4pm 1784 674 788
5pm 1120 423 664 ← lowest overall (end of US workday)
6pm 1276 482 615
7pm 988 373 1031 ← second lowest (US prime time)
8pm 1240 468 1013
9pm 1088 411 1199
10pm 2008 759 601 ← evening recovery
11pm 2616 988 532 ← best regular hour
太平洋时间下午 5 点是最糟糕的时段。估算思考量的中位数降至 423 个字符——在所有样本量显著的时段中最低。这时正值美国西海岸下班、东海岸晚间，很可能是负载高峰期。
太平洋时间晚上 7 点是第二糟糕的时段。估算思考量为 373 个字符，且样本数为所有时段之最（1,031 个块）。这是美国的黄金时段。
深夜（太平洋时间晚上 10 点至凌晨 1 点）出现回升。中位数上升至 759～3,281 个字符。此时美国东海岸已经入睡，整个平台的总体负载想必也处于最低水平。
脱敏前的曲线较为平坦；脱敏后则出现明显的峰谷。脱敏前，各时段思考特征中位数的范围为 1,020～2,648（相差 2.6 倍）；脱敏后则为 988～8,680（相差 8.8 倍）。思考深度变得更加不稳定，这与一种对负载敏感的分配系统相符，而不是固定预算机制。
这些数据并不能明确支持“在非高峰时段工作可以获得更好的质量”。相反，它表明在脱敏后的机制下，思考量分配对负载敏感且具有波动性。某些非高峰时段（深夜）表现更好；另一些时段（傍晚）却比工作时间更糟。太平洋时间下午 5 点和晚上 7 点的低谷与美国互联网使用高峰重合，而不是与工作高峰重合，这表明限制可能来自基础设施层面（GPU 可用性），而非策略层面（针对单个用户的限流）。
脱敏前曲线平坦才是更重要的发现：当思考量得到充足分配时，一天中的时段并不重要。如今时段开始产生影响，这一事实本身就是证据，表明思考量正在被配给，而不是以固定水平提供。
减少思考 token 似乎能够节省单次请求的计算资源。但当思考量减少导致质量崩溃时，模型就会陷入无效折腾——生成错误输出、被用户中断、重新尝试，并把 token 浪费在各种纠错上；如果模型第一次就进行了充分思考，这些纠错本来根本不需要发生。最终结果是，总计算资源消耗反而增加了几个数量级。
统计所有 Claude Code 项目的全部使用量。以估算的 Bedrock Opus 定价作为对比（输入 $15/MTok，输出 $75/MTok，缓存读取 $1.50/MTok，缓存写入 $18.75/MTok）。
API 请求量增长 80 倍，并不完全是性能退化导致无效折腾所造成的。它还反映出并发智能体会话数量被有意扩大，而这一扩张恰好在最糟糕的时刻撞上了质量回退。
2 月：1～3 个并发会话，集中处理两个 IREE 子系统。1,498 次 API 请求产出了 191,000 行已合并代码。这套工作流已得到验证，而且卓有成效。
3 月初（回退前）：受到 2 月成功的鼓舞，用户将规模扩大到 5～10 个以上的并发会话，覆盖 10 个项目（IREE loom、amdgpu、remoting、batteries、web、fuzzing，以及 Bureau 的多智能体系统）。这正是预期中的工作流——数十个智能体在大型代码库上协作，每个智能体都能自主运行 30 分钟以上。
3 月按项目划分的 API 请求量（去重后）：
全部请求中有 26% 是子智能体调用——智能体生成其他智能体，以执行研究、代码审查和并行探索。这正是多智能体模式按设计运行的结果，但它会大规模消耗 API 请求。
灾难性的碰撞：质量回退恰好发生在规模扩张期间。用户的体验从“我可以运行 50 个智能体，而且它们都能产出优秀成果”，变成了“现在每一个智能体都成了白痴”。这种故障模式并不是某一个会话出问题，而是 10 个以上的并发会话同时退化，每个会话都需要人工干预，而多智能体工作流原本正是为了消除这种人工干预。
峰值日期：3 月 7 日，共有 11,721 次 API 请求——这是思考内容脱敏比例超过 50% 的前一天，也是最后一次尝试全规模运行的日子。3 月 8 日之后，随着用户彻底放弃并发工作流，会话数量开始下降。
因此，3 月的成本由以下几部分共同构成：
合理的规模扩张：更多项目、更多并发智能体（约 5～10 倍）
性能退化造成的浪费：无效折腾、重试、纠错（约 10～15 倍）
灾难性损失：原本一个周末便能产出 19.1 万行代码的多智能体工作流彻底无法运作，迫使用户退回到有人监督的单会话操作模式
最引人注目的一行数据是用户提示数量：2 月为 5,608 条，3 月为 5,701 条。人类投入了同样的精力，但模型消耗了 80 倍的 API 请求和 64 倍的输出 token，产出的结果却明显更差。
即使考虑到规模扩张（并发会话增加了 5～10 倍），性能退化仍使请求量在仅由扩张所能解释的水平之上额外增加了 8～16 倍。过去能够自主运行 30 分钟的会话，现在每隔 1～2 分钟就会停滞，由此产生的纠错循环使每单位有效工作对应的 API 调用次数成倍增加。
当模型进行深度思考时：
它会在编辑前彻底阅读代码（每次编辑前读取 6.6 次）
它能够在第一次尝试时就正确完成修改
会话可以自主运行 30 分钟以上，无须干预
一次 API 请求就能完成有意义的工作
当模型不进行思考时：
它不经阅读就直接编辑（每次编辑前读取 2.0 次）
修改是错误的，需要进入纠错循环
会话每隔 1～2 分钟就会停滞，需要人工干预
每次干预都会产生多次额外的 API 请求
失败的工具调用（构建、测试）会把 token 浪费在最终被丢弃的输出上
上下文会随着失败尝试不断增长，导致缓存体积增大
在智能体集群规模下，这种情况极具破坏性。一个退化的智能体只会令人沮丧；五十个同时运行的退化智能体则会造成灾难——每个智能体都在错误输出上浪费 token，在同一批文件上反复进行无效操作，并且需要人工关注，而多智能体设计原本正是为了消除这种人工投入。用户被迫