当您给 Claude Code 一个在您的代码库中完成的任务时，Claude 通常会以简洁的方式汇报结果。在 Claude 所做更改的描述下方，可能会列出各种被修改的文件（从微小改动到重大改动不等）。通常，编写代码更改本身（并对其进行解释）的那个会话，并不是评判这些更改质量的最佳裁判。在保留某项更改之前，最好自己先查看一遍，然后让 Claude 在一个干净的上下文中（不带这次会话的历史记录）再次审查它。
审查实际的更改
diff（差异）是一项更改的前后对比：逐个文件地列出被删除的行和被添加的行。/diff 命令会以这种形式打开一个交互式查看器，展示您尚未提交的更改，它也可以显示 Claude 每一轮对话所做的更改。使用上下箭头在文件之间移动，按 Enter 打开某个文件。
/diff每次都值得再看一眼的最重要的事项是：
- 您没有要求的更改。 例如，在 Claude 处理某个文件时被顺带修改的配置值，或者您没有提到过的被重写的辅助方法。
- 被削弱的测试。 如果您所在的项目包含测试，请找出任何被跳过、删除或放宽条件直到通过的测试。
- 新增的包和硬编码的值。 仅为一个函数而添加的依赖项，或直接写入代码中的 URL 或密钥。
如果整个更改都是错的，运行 /rewind（或在空提示上按两次 Esc），选择产生该更改的那条提示，然后选择恢复代码和对话。有一点值得了解的限制：由 Claude 运行的 shell 命令（例如安装某个包）所改变的文件，不会被回滚。
下面的练习使用了一个小型的注册表单任务：上方是 Claude 的总结，下方是 Claude 修改过的八个文件。
寻求第二意见
"探索 → 规划 → 编码 → 提交"课程中提到，在提交更改之前应该让第二位审查者来审查它。一次长会话会携带它读取和决定过的一切内容。那正是您在上一课中学会管理的上下文，而这恰恰是您不希望审查者带有的历史记录。/code-review 就是那位第二审查者：它在一个干净的上下文中审查更改，不带有您这次会话的任何历史记录，并报告它的发现。除非您要求，否则它不会修改任何内容。
/code-review审查在后台运行，耗时从几秒到几分钟不等，并且会像其他任务一样计入您的用量，因此请把它留给那些值得再看一眼的更改。审查完成后，发现的问题会出现在您的对话中。您也可以用普通语言提出请求，Claude 可以根据该请求启动同样的审查。如果 Claude 直接内联回答而不是启动审查，请您自己运行该命令。
对于这个注册表单的更改，审查返回了四项发现：
决定如何处理每一项发现
将每一项发现归入以下三类之一：
- 立即修复。 这是一个真实存在的问题，它很重要，必须修复。
- 询问原因。 这一类用于那些您无法完全确认或看起来不对劲的发现。审查者在冷读代码更改时，也有可能遗漏一些东西。
- 暂不处理。 这是一个真实存在的问题，但规模小或影响不大。这些通常可以归并到一组修复中，留到未来的某次会话中一并处理。
要询问原因，请把该发现原样引用给 Claude，并让 Claude 再检查一遍。对于上面的第二项发现，您可以这样输入：
每当您要求修复时，最好同时要求提供证据：
如果一项修复最终演变成了一个规模不小的独立更改，请再次运行审查。
什么时候更仔细地审查才值得
一个简单的单行更改，通常只需要快速看一眼 diff，不需要别的。当一项更改大到您无法在脑海中完全把握时，当它涉及敏感内容或具有破坏性操作时，以及在把工作交给队友之前，您都应该同时使用人工审查和 Claude 审查。
动手试试：对四项发现进行分类
回顾
- 在仅凭总结就信任更改之前，先阅读实际的 diff。运行
/diff，留意您没有要求的更改、被削弱的测试，以及新增的包或硬编码的值。 - 用
/code-review从一个干净的上下文中获取第二意见（或者用普通语言提出请求，让 Claude 启动它）。审查者负责报告，除非您要求，否则 Claude 不会进行修改。 - 将每一项发现归类为立即修复、询问原因或暂不处理，并在每次要求修复时都要求提供证据。
当审查者多次标记出同一个问题时，为 Claude 写一条规则，让它在每次会话开始时阅读，可能是个好主意。那个文件就是 CLAUDE.md，也是接下来要讲的内容。