代码审查

当你给 Claude Code 一个在代码库中完成的任务时，Claude 通常会以简洁的方式报告结果。在 Claude 所做更改的描述之下，可能有各种文件被更改（从小到大的更改）。通常，编写代码更改本身（并解释它们）的会话并不是这些更改的最佳审查者。最好在保留更改之前自己查看每个更改，然后让 Claude 在没有此会话历史记录的干净上下文中再次审查。

审查实际更改

差异是更改的前后对比：逐文件显示删除的行和添加的行。/diff 命令以该形式打开未提交更改的交互式查看器，还可以显示 Claude 每次对话更改了什么。使用上下箭头在文件间移动，按 Enter 打开文件。

/diff

每次最值得关注的事项：

• 你没有要求的更改。 Claude 在编辑文件时修改的配置值或重写的你没有提到的辅助方法。
• 变弱的测试。 如果你的项目包含测试，识别任何被跳过、删除或放宽直到通过的测试。
• 新包和硬编码值。 仅为一个函数添加的依赖项、直接写入代码的 URL 或密钥。

如果整个更改是错误的，运行 /rewind（或在空提示上按两次 Esc），选择产生它的提示，然后选择 恢复代码和对话。一个值得了解的限制：Claude 运行的 shell 命令（如包安装）更改的文件不会被回滚。

寻求第二意见

探索 → 计划 → 编码 → 提交课程说过在提交之前让第二个审查者审查更改。长会话包含它读取和决定的所有内容。这就是你在上一节课中学到的上下文，也正是你不希望审查者拥有的历史记录。/code-review 就是那个第二审查者：它在干净的上下文中审查更改，没有你的会话历史记录，并报告发现的问题。除非你要求，否则它不会编辑任何内容。

/code-review

审查在后台运行，从几秒到几分钟不等，与其他任何任务一样计入你的使用量，所以将其留给值得第二眼的更改。发现结果会在完成时到达你的对话中。你也可以用普通语言询问，Claude 可以从该请求开始相同的审查。如果 Claude 直接回答而不是开始审查，自己运行该命令。

审查你刚才做的更改。报告问题；暂时不要修复任何内容。

决定如何处理每个发现

将每个发现分为三类之一：

1. 立即修复。 这是一个真正的问题，很重要，必须修复。
2. 询问原因。 这是你无法完全验证或似乎不对的发现。冷读代码更改的审查者也可能遗漏内容。
3. 暂时搁置。 这是一个真正的问题但很小或无关紧要。这些通常可以批量成一组修复，在未来的某次会话中处理。

要询问原因，将发现引用回 Claude 并要求 Claude 再次检查。对于上面第二个发现，你可以输入：

你报告说 isValidEmail 没有修剪空格，但第 4 行调用了 trim()。再次检查并告诉我该发现是否成立。

每当你要求修复时，最好同时要求提供证据：

修复第一个发现：不要跳过空邮箱测试并恢复原始断言。然后运行测试并显示输出。