Claude Code 说修好了，你该怎么验收

假如 Claude Code 告诉你：“用户退出后旧 refresh token 仍然有效的问题，已经修好了。”你准备看什么，才接受这句话？

很多人这时会去看类型检查有没有通过、测试是不是绿的。可类型检查通过，只回答了“类型对不对”；测试全绿，也可能只是没有一条测试覆盖“退出后旧 token 应该失效”。复杂任务的难处在于，如果一开始只说了一句“帮我修好退出功能”，到结束时你手里根本没有判断标准，只能凭感觉接受或拒绝。

更好的顺序是倒过来：开工之前，先想清楚结束时要看哪几类证据。以这个 token 问题为例，可以先定四类：

• 行为证据：用户退出后，旧 refresh token 换不到新 token；
• 兼容证据：正常登录、正常刷新和多设备策略仍符合现有约定；
• 自动化证据：相关测试、类型检查和构建都通过；
• 审查证据：修改范围、残余风险和没覆盖到的环境都说清楚了。

证据定下来，研究就知道要找什么，验证就知道要跑什么，复核也知道要看哪些边界。下面从这四类证据倒推整个任务。

01 一句“帮我修好”缺了什么

复杂工作流要把阶段的输入、产出和进入条件接起来。以“退出后旧 refresh token 仍有效”为例，先查清存储和校验路径，再决定怎样撤销、怎样保留正常刷新与多设备行为。每一步都需要前一步的证据。

只说“帮我修好退出功能”没有给出这些判断依据；增加许多文档和代理，也不自动补齐它们。先确定验收，再安排研究、计划、实现、验证和复核。

Claude Code 最佳实践把这个问题说得很透：Claude 在工作“看起来做完了”的时候就会停下；如果它没有能运行的东西来判断工作是不是真的做完了，“看起来做完了”就是它唯一的依据，结果就是你自己成了测试套件，每个错误都要等你碰巧发现。官方的建议是给 Claude 一个能返回通过或失败的检查，比如测试文件、构建的退出码、linter，或者一个把输出和样例做对比的脚本。

02 从结束时要看的东西往回推

先暂时跳到任务结束时。假如 Claude 说修好了，你准备看什么才接受？把这个问题答清，再往前安排研究、实现和验证，需要的证据就有了方向。

refresh token 修复可以先定义四类证据：

沿“退出后拒绝旧 token”倒推，研究就要找到存储、保留旧 token 的测试夹具，以及 refresh 校验路径。再看“正常刷新仍可用”，就得查已有测试、多设备约定和旧数据处理。这样研究会围绕后面的检查展开。拿到这些答案，就能安排实现；继续调查时聚焦可能改变决定的问题，具体耗时仍看代码和环境。

这一阶段留下的材料，下一阶段要用得上。格式完整的文档本身不能代替这些依据。研究、计划、实现各阶段怎样衔接，见用 Claude Code 开发大功能的分阶段做法。

03 验证：拿出最初的证据要求

验证信号要能重复观察：测试退出码与失败详情、构建和类型结果、API 响应、界面对比、数据状态变化或日志事件。

走到验证，再拿出一开始的证据要求。缺陷能否复现，正常刷新、退出后拒绝、多设备和并发是否符合约定，都要有对应结果。此时即使 pnpm typecheck 已通过，也只回答了类型检查这个问题，认证行为还需要自己的检查。

报告要包含实际命令和可检查摘要。高输出测试可以交给子代理，只返回失败用例、关键错误和日志位置。最佳实践文档在这一点上说得很直接：不管用哪种检查方式，都要向 Claude 要证据，也就是它运行的命令和输出，或者截图；单独一句“所有测试都通过了”说明不了多少，读输出比你自己重跑一遍检查更快。

04 复核：换一个没被锚定的视角

实现者容易沿用原有假设。让新上下文中的只读子代理主动寻找遗漏的调用路径、并发条件、安全边界和测试盲点。子代理文档说明，每个子代理都从全新、隔离的上下文开始，看不到你的对话历史，也看不到 Claude 已经读过的文件，这正是独立复核需要的起点。

独立复核要有新的上下文、审查任务和证据要求。换个模型也还要检查这些条件：

• 审查代理没有被实现过程中的失败尝试锚定。
• 它拿到清楚的修改范围和验收标准。
• 它必须提供文件、行号和触发条件作为证据。
• 主会话复核发现后再采纳结论。

把原验收标准交给审查者。退出 token 已失效，也仍要核对并发和多设备约定；只看风格会漏掉这些边界。

官方文档推荐的做法与此一致：用一个从没看过这段对话的新子代理审查 diff，它不会被产出代码时的推理带偏；想让审查对照计划而不是泛泛找 bug，就自己写审查提示，例如让子代理对照规格文档检查每条需求是否实现、列出的边界情况是否有测试，只报告影响正确性的缺口，跳过风格问题。官方特别提醒别删掉“跳过风格”这一句：一个被要求找问题的审查者总能找到点什么，每条都去修，最后会多出不必要的抽象层和一些永远不会发生的情况的测试。

新的上下文有助于重新检查假设，但不保证审查者没有偏差。复核深度仍按任务风险与规模选择。复核用的子代理怎样定义成只读角色，见Claude Code 自定义只读审查子代理。

回到开头那句“已经修好了”。有了这四类证据，你要看的就不再是一句总结，而是退出后旧 token 被拒绝的实际响应、正常刷新仍通过的测试、跑过的命令和输出，以及一份说明了残余风险的审查。验收标准定在最前面，后面每一步都有了方向。如果修复迟迟通不过检查，什么时候该停下来，见Claude Code 修复循环的五个停止条件。