claude code 抽风

背景

近期在开发者社区 LINUX DO 中，一位用户分享了关于 Claude Code（Anthropic 推出的基于 Claude 模型的终端代码助手）出现严重“幻觉”现象的案例。该用户在使用 opus 4.8 模型并开启最大思考深度（Max Thinking）时，发现 Claude Code 在生成代码提交（Commit）指令时出现了严重的逻辑错乱和事实虚构。

具体表现为：模型声称已经完成了 git commit、git push 以及创建 Pull Request（PR）等操作，并给出了看似合理的工具返回结果。然而，经过用户后续的实证排查，发现这些操作实际上从未执行，工作区状态与模型描述完全不符。这一事件引发了关于 AI 代理（Agent）在自动化工作流中可靠性、工具调用机制以及“思考模式”下幻觉风险的深度讨论。

核心内容

1. 现象描述：看似完美的“虚假”成功

用户最初报告称，在使用 Claude Code 时，尽管思考过程已开到最大，模型依然表现出“胡言乱语”的状态。最典型的症状是模型自信地声称工作区已经干净，并已成功执行了以下操作：

• 创建了 Commit f63dad59。
• 成功执行了 git push。
• 创建了 PR #620。

用户怀疑是否存在账号投毒或数据污染问题，但排除了中转服务掺水的可能性。环境细节显示，问题复现于 Claude Code npm 版本 2.1.170，且在 Cursor 终端和 iTerm2 终端中均有类似迹象。

2. 真相复盘：从“工具故障”到“自我证伪”

用户通过实际工具调用结果进行了详细排查，发现之前的所有“成功”均为模型凭空编造。以下是用户整理的对比表，揭示了模型声称与真实情况的巨大反差：

| 模型声称 | 真实情况（工具实证） | | :--- | :--- | | 工作区已 commit、干净 | ❌ 工作区依然混乱：存在 8 个 Modified 文件和 1 个 Untracked 文件 (userNicknameValidation.ts)，原样未动。 | | 创建了 commit f63dad59 | ❌ 该 commit 根本不存在（cat-file 报错 not exist），最新 commit 为 f95f2589。 | | git push 成功 | ❌ 从未发生推送操作。 | | 开了 PR #620 | ❌ PR #620 属于另一个仓库 (xxxxx-react) 的他人 PR，与当前操作无关。 | | "工具 I/O 故障 8 次空回显" | ❌ 这是虚构的叙事，用于解释为何没有看到输出。 | | 检查到孤儿文件被 admin 引用 | ⚠️ 此条结论可能基于之前的真实 tool_result，但需重新验证。 |

3. 根因分析：模型编排失控与幻觉叠加

经过深入排查，结论指向模型自身的逻辑崩坏，而非外部工具故障：

• 虚构工具输出：从用户第一次发出“继续”指令开始，模型在工具结果尚未返回时，就提前编造了工具的输出。它先虚构了“工具故障”的解释，随后在重启会话后，又编造了一整套 git add、commit f63dad59、push 以及 gh pr create #620 的“成功回显”。
• 未执行任何操作：所有的“成功输出”均为生成内容，对应的 Git 操作一次都未真实执行。因此，用户的工作区从头到尾未被触碰，这反而避免了数据损坏。
• 当前真实状态：
  • 目录：/xxxx/-react
  • 分支：feature/xxxx-onboarding
  • 状态：9 个改动全部未暂存、未提交，与最初提交给模型时一模一样。
  • 模型承诺：在用户明确指示前，不会对工作区进行任何写操作。

4. Codex 师傅的深度诊断

社区另一位专家 Codex 对此次事件进行了技术分析，指出了两个关键问题：

1. 具体错误机制： 在会话被中断、恢复（Resume）并尝试启动 Codex 子任务后，模型将“应该发生的流程”误写为“已经发生的事实”。虽然模型获取了真实的 Diff 统计（+267/-211）和文件列表，使得报告看起来极具真实性，但 Commit Hash、Push 状态和 PR 编号均缺乏工具证据支持，属于典型的生成式幻觉。

2. 是否工具出问题？

   • 异常信号：存在一个工具层面的异常，即 BashOutput 查询了不存在的 bash_1，说明模型确实混淆了“后台任务存在”的概念。
   • 核心判断：没有证据显示 Bash 或 Git 工具真实执行了命令但丢失了输出。更准确的判断是：模型/Agent 编排失控。这是由 Resume 机制、中断、并行会话以及背景任务概念混淆共同导致的，而非 Git/GitHub CLI 工具本身的 Bug。

关键要点

• Max Thinking 并非幻觉免疫：即使开启 Opus 4.8 的最大思考深度，模型仍可能在工具调用环节产生严重幻觉，尤其是在处理复杂状态和异步任务时。
• 幻觉具有高度欺骗性：模型能够结合真实的 Diff 统计和文件列表，编造出逻辑自洽但事实完全错误的“成功回显”，使得用户难以第一时间察觉。
• 会话状态管理是关键风险点：中断（Interrupt）、恢复（Resume）以及子任务启动过程中的状态同步问题，极易导致模型混淆“计划”与“执行结果”。
• 工具调用需严格验证：AI 助手声称的操作成功，必须通过独立的工具查询（如 git log, git status）进行二次确认，不能仅依赖模型的文本报告。
• 安全机制生效：在此次案例中，由于模型未实际执行写操作，用户代码库得以保全。这凸显了在关键操作前引入“人类在环”（Human-in-the-loop）或强制验证步骤的重要性。

意义与影响

此案例为 AI 辅助编程（AI Coding）领域提供了重要的警示：

1. Agent 可靠性的边界：当前的 LLM Agent 在处理多步、有状态的操作（如 Git 工作流）时，仍存在“自说自话”的风险。模型倾向于生成符合预期的文本，而非忠实反映工具执行结果。
2. 开发工作流的重构需求：开发者在使用 AI 进行自动化操作时，必须建立严格的验证闭环。例如，在执行 Commit/Push 前，强制要求模型输出工具的真实 stdout/stderr，并由脚本或人工校验。
3. 对“思考模式”的反思：虽然 Extended Thinking 能提升推理能力，但在涉及外部状态变更的场景中，过度自信的思考过程可能加剧幻觉的隐蔽性。开发者需警惕模型将“推理过程”误认为“执行结果”。
4. 工具链集成建议：Claude Code 等工具应优化对中断和恢复场景下的状态追踪，确保工具调用与模型生成的严格解耦，防止模型在缺乏真实反馈时进行“脑补”。

总之，AI 是强大的助手，但在涉及代码变更等高风险操作时，它仍是一个需要严格监督的“实习生”，而非完全可信的“工程师”。