Claude Code 报告已修好，问题却还在

让 Claude Code 修一个 bug：刷新登录页，会话就丢了。它读了十几个文件，改了两处代码，回复“已修好”。你一刷新，问题还在。

这时候很容易把需求再说一遍，或者干脆换个模型重来，结果往往是又一轮读文件、改代码、说“已修好”。

“已修好”只是一句汇报，背后有没有证据才是关键。Claude Code 干活是一个循环：收集信息，采取行动，验证结果，三个环节都该留下证据。

证据缺在哪一环，修复就在哪一环悬空：可能是没读到真正相关的文件，可能是查错了地方，也可能压根没验证原来的问题。分不清缺在哪，每次追问都只能靠猜。

更有效的入口，是沿着它的工作记录倒着查。一份修复记录拆成已有证据、当前判断和最小的下一步三行，缺口就看得见；再从上下文、工具、验证这些角度逐项核对，哪一环没站稳也就清楚了。

最后一步，是把“帮我修一下登录问题”这样的含糊请求，改写成它能照着做、你也能验收的任务说明。

01 “已修好”只是一句汇报

读取和修改说明它采取了行动，行动是否有效，还要有证据。工程 Agent 围绕目标收集信息、调用工具，并依据结果调整下一步。在 Claude Code 中，模型负责解释信息、推理和选择动作，工具负责读取文件、运行命令和修改代码，工具结果为下一次判断提供依据。Anthropic 的官方文档把这个过程称为 agentic loop（Agent 循环）。

用户说明任务与完成标准
  ↓
收集上下文：取得相关代码、配置、错误信息
  ↓
采取行动：根据当前判断读取、修改或运行命令
  ↓
验证结果：比较实际结果与完成标准
  ├─ 有差距 → 用新证据修正判断，继续读取或修改
  └─ 达到标准 → 汇报结果与尚未验证的部分

三个阶段可能交错：运行失败测试既是在采取行动，也是在收集错误证据；测试结果可能让原先的修改方案失去依据，需要重新读代码。

读到了相关代码，才有条件判断改哪里；执行了针对原问题的检查，才有依据说明改动是否有效。“已修好”需要相应的证据支撑。Anthropic 的最佳实践页也把“给它一个可以运行的检查”和“告诉它看不到的信息”并列为两条主线。

02 从一份修复记录定位缺口

下面是一份构造的修复记录，路径和测试名称仅用于演示判断过程。

用户报告：
  登录页刷新后丢失会话。

失败测试：
  refresh-session.test.ts
  预期：刷新后保持原会话
  实际：刷新后创建了新会话
  测试调用：src/auth/restore-session.ts

本次工具记录：
  读取 src/legacy/login.ts
  修改 src/legacy/login.ts
  运行 legacy-login.test.ts，结果通过

最终回复：
  登录问题已修复。

先对照用户要求与实际检查的行为。用户要求刷新后保留会话，记录却只显示旧登录测试通过。现有记录证明某项测试通过，尚未证明刷新问题已修复。这是可以直接确认的验证缺口。

再看调查对象。失败测试调用的是 restore-session.ts，工具记录中读写的是 legacy/login.ts。这让人怀疑，修改可能落在失败行为的调用路径之外，还需要继续核实。路径不同时，两个模块仍可能有关，恢复入口说不定就调用旧模块。下一步应读取失败测试和恢复入口，核对它们与修改文件的调用关系。

如果进一步确认恢复流程不经过旧模块，而且刷新测试仍失败，才有依据判断本次改动偏离了目标行为，应沿恢复入口继续定位。此时确认的是修复过程偏离目标，代码层面的根因仍待调查，两种判断需要分开。可以把这次分析整理成三行：

最小检查应直接减少当前的不确定性，而不以命令长短衡量。疑问是两个文件是否有关联，就先核对调用关系；收集无关日志回答不了这个问题。

03 项目代码怎样成为判断依据

上面的记录还留下一个问题：恢复入口明明在项目里，为什么它没有成为判断依据？

上下文窗口是模型生成当前回答时能够参考的信息范围。其中可以包含任务说明、会话历史、已读取文件、命令结果，以及加载的项目规则和工具说明。文件内容被读取后，才成为当前判断的依据；只躺在磁盘上的文件，还没有参与判断。搜索入口选错或关键文件未读，后续推理就可能缺少必要前提。

例如，恢复入口已经迁移，已加载的 CLAUDE.md 却仍写着“登录逻辑位于 legacy 目录”，就可能把调查引向旧模块。先前排查旧流程留下的限制，也可能影响当前任务。这些都是待核查的可能原因，需要回到加载和工具记录确认。会话越拉越长之后怎样清理这类干扰，可以接着看越聊越乱，该清空、压缩还是交接。

用户的纠偏应当补入能改变判断的事实。例如：

这次失败发生在刷新后的会话恢复。失败测试调用 `restore-session.ts`，
你刚才修改的是 `legacy/login.ts`。请先核对两者的调用关系，
再判断现有改动是否影响这个失败。

这段话指出了症状、记录差异和待核实的问题，同时保留了调查空间。只说“再认真一点”，Claude Code 得到的项目信息和之前一样多。

04 用六个视角检查工作过程

Agent 循环帮助我们看清“做了什么、结果怎么影响下一步”；分析原因时，还需要问“哪些条件出了问题”。可以从模型、上下文、工具、控制、隔离和验证六个视角检查。

这些视角可以同时描述一次失败。登录案例中，“未取得恢复入口的信息”是上下文缺口，“只运行旧模块测试”是验证缺口。如果进一步发现搜索参数指向了错误目录，还需要检查工具使用。这些缺口可能相互影响，先根据记录逐一核对，比急着归结为一个原因更有帮助。

隔离也有两种不同对象：分开上下文，可以减少不同任务的信息混杂；分开工作目录，可以减少文件改动相互覆盖。两项工作分开讨论，照样可能写到同一个文件。

任务边界则为所有视角提供判断标准。例如，用户只说“优化登录”，可能指速度、界面，也可能指刷新后的行为。目标尚未确定时，先澄清要改变什么；目标清楚了，才谈得上确认工作是否完成。

先调整证据所指向的环节：缺文件就补读，权限拒绝就核对操作和授权。若上下文缺少关键前提，就补上这条信息，比换模型或加泛泛要求有效。必要信息充分时，再检查推理是否成立，避免同时修改多个层面的配置。

05 同样是测试没过，证据不同

仍然围绕登录修复，比较下面几种记录。它们都可能被称为“测试没过”，但每种情况能提供的证据不同。

测试通过的证据范围取决于实际断言。只检查输入凭据后能否登录，覆盖的是登录这一件事；刷新后会话是否保留，要另行检查。

权限拒绝表示命令未执行，没有产生测试结果。先核对具体操作、拒绝原因和已授权范围；暂时无法执行时，报告阻塞及未验证内容，权限维持原范围。

验证方式也应符合任务。解释函数时，可对照分支逻辑检查说明；修复会话恢复行为，则需要覆盖该行为的运行证据。完成标准决定应取得什么证据。收到新证据后要调整判断：原来怀疑权限阻断，后来命令执行成功且断言失败，就应继续分析被测行为，换掉已经失去依据的解释。

06 把含糊请求写成可验收的任务

用户在循环开始时提供边界，在过程中用新事实纠偏，最后验收结果。回看最初的请求：

帮我修一下登录问题。

它还缺三样信息：什么操作触发问题、实际发生什么、预期是什么。补充说明应从已经观察到的事实开始，代码原因留待调查确认。

开发者已经确认：匿名会话首次建立正常，刷新后创建了新会话；目前还不知道负责恢复的文件在哪。本次只处理恢复问题，同时要保留主动退出的行为。逐项补充：

整理后的请求可以是：

匿名会话首次建立正常，但刷新登录页后会创建新会话。
请修复刷新后的会话恢复，使它保留原会话。

我还不确定相关文件，请先从复现步骤、失败测试和会话恢复调用链定位入口。
本次聚焦这个问题，不重做登录界面；主动退出后清除会话的行为应保留。

修复后验证刷新前后会话是否一致，并检查主动退出是否仍然有效。
请说明实际运行了哪些检查；如果缺少环境或无法覆盖某项行为，
写清阻塞和未验证部分。

请求先限定行为和调查范围，待核对调用链后再补路径。约束应来自真实需要，例如明确必须保留的行为。日常怎样提问、怎样先计划再实现，可以参考Claude Code 快速入门路线。

复杂任务可以先做只读调查并核对计划，再进入修改；新证据出现后仍需调整方案。自然语言提供协作边界，必须强制限制的操作还需相应权限控制。

判断一次任务的进展时，记下三件事，方便之后回查：看到什么证据、目前支持什么判断、下一步怎么减少不确定性。用户据此说明边界、纠正方向并验收结果，Claude Code 才能在同一个目标下持续推进。