用 Yenpo 审查 Claude Code 的改动

Claude Code 跑完了，摘要说功能已经实现，你却还没看懂行为到底变在哪里。在 Yenpo 中打开它实际修改的本地项目，从 diff 开始，把摘要里没讲清的调用和分支补上，再决定下一步。

你需要一个本地 Git 仓库和 macOS 版 Yenpo。浏览代码和 diff 不需要连接模型；想让 AI Reader 帮忙时，再配置模型即可。

1. 先确定哪些改动属于这一轮

开始一轮任务前，在 Claude Code 将要修改的目录中运行以下只读命令：

git rev-parse --show-toplevel
git rev-parse HEAD
git status --short

记下起始提交 ID，以及已有的修改和未跟踪文件。起始工作区干净时，后续 diff 更容易归属。已有工作需要保留，并用平时的审查工具记录起始内容；只记文件名，无法区分同一文件先后发生的两次修改。

Claude Code 完成并停止写文件后，再运行一次这些命令。除了分支，还要核对目录：如果使用了独立 worktree，Yenpo 应打开那个目录。

这一轮结束后的状态	应该看什么
没有新提交，开始前工作区干净	相对起始提交的本地改动
产生了新提交	起始提交 → 最终提交，再看剩余本地改动
开始前就有改动	对照记录的起始内容，再判断哪些是 Claude Code 新改的

Yenpo 读取的是 Git 状态，不会自动还原 Claude Code 对话中每一轮的范围。如果开始前有改动又没有记录，就把审查范围称为“当前改动”，不要认定它们全部属于这一轮。

打开项目文件夹，点击侧栏带加减号的“改动文件”按钮。“本地改动”标题下的统计以 HEAD 为基准。选择一个文件，阅读它的行内 diff。

先看实现需求的文件，再看调用者和测试。别漏掉新文件：新增测试或配置往往比大段生成内容更能说明行为。Yenpo 的统计可能包含编辑器里尚未保存的内容；与命令行 Git 对照或运行测试前，先保存打算保留的修改。

如果 Claude Code 已经提交，打开“版本比较…”，在“提交”模式逐个查看相关提交相对第一父提交的差异，再回到“改动文件”检查未提交部分。要看整轮的净 diff，将下方占位符替换成记录的起始和最终提交 ID，运行这条只读命令。Yenpo 的“比较”模式选择的是分支，具体见版本选择说明。

git diff START_COMMIT END_COMMIT --

假设你让 Claude Code 修复“切换搜索词后，旧结果仍然显示”的问题。读完改动函数，继续找到它的调用者和更新界面结果的位置。

逐一回答：

可以使用文件搜索；配置了语言服务器时，也可以跳转定义和查找引用。跟读时核对标签页的版本，当前文件可能已经不同于提交比较里的内容。

连接模型后，点击本地改动标题处的“让 AI 审查所有改动”，它会准备当前工作区改动的提问草稿。审查已提交版本时，改用“让 AI 审查这次比较”，并保留比较附件。

发送前把问题改成：

解释搜索结果处理的这次改动，从调用者追踪到界面更新。检查旧请求最后完成的情况。每个判断都引用相关代码，区分原有行为和新增行为，并指出哪些测试真正覆盖了这个完成顺序。只审查，不修改文件。

保持编辑授权关闭。点击回答里的引用核对源码，涉及调用者或前置条件时打开完整文件。逐条核对引用的教程有具体例子。

有效的反馈应写清触发条件和预期结果：

查询 A 早于 B 发起、晚于 B 完成时，A 仍可能覆盖 B 的结果。请检查结果赋值路径，并补一个先完成 B、再完成 A 的测试。保留单次成功请求的现有行为。

先在自己的代码中确认问题，再使用这段反馈。把笼统的“更安全一点”换成实际需要的行为。

修复完成后重新阅读相关 diff，运行项目对应的测试，并记下实际执行的命令和结果。

记下起始和最终提交 ID、已读文件、行为变化的一句话说明，以及还没解决的问题。注明是否包含未提交文件、实际跑了哪些检查，下一轮就有了清楚的起点。

如果工作已经整理到分支，可以接着看与 main 比较分支的教程；其中的 Git 步骤也适用于 Claude Code 创建的分支。