Codex 完成任务后，决定能否合并需要看两部分：分支里已经提交的代码，以及工作目录里尚未提交的改动。Yenpo 可以保留提交比较，同时让你查看当前文件。
你需要 Yenpo 和包含任务结果的本地仓库。下文用 codex/search-fix 作为示例分支，请将它和 main 替换为实际名称。
1. 打开 Codex 真正修改的目录
Codex 可能在独立 worktree 中工作，而且可能处于 detached HEAD 状态，没有分支名。要看它的未提交文件，应在 Yenpo 中打开那个 worktree 的目录。OpenAI 的 worktree 文档说明了这种工作方式。
在任务的工作目录中运行：
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git status --short分支名输出为空，可能表示 detached HEAD。记下提交 ID；不建分支也可以在 Yenpo 的“提交”模式查看单个提交，并阅读本地改动。若要执行下方的分支比较，先在 Codex 中使用“Create branch here”建立分支，再重新打开 Yenpo 比较选择器。远程任务的结果应先通过平时的 Git 流程带到本地。
2. 将分支与 main 比较
- 点击侧栏“版本比较…”，切换到“比较”。
- 在“旧版本”一栏选择“本地分支”里的
main。 - 在“新版本”一栏选择“本地分支”里的
codex/search-fix（或刚在 Codex 中创建的分支）。 - 使用“分叉以来”，查看目标版本从共同祖先之后带来的改动。
- 核对方向和短提交 ID，点击“查看改动”。
想以 origin/main 为基准，就在“旧版本”中选择“远程分支”。这里读取的是本地保存的远程跟踪引用；需要更新基线时，先用平时的 Git 客户端 fetch，再重新打开选择器。
| 想回答的问题 | 比较方式 |
|---|---|
| 分支从 main 分叉后增加了什么？ | 分叉以来 |
| 两个最新提交目前有哪些差别？ | 直接比较 |
| 单个提交相对第一父提交改了什么？ | 提交 |
main 在分叉后继续前进时，直接比较会包含两侧发展的差异。“分叉以来”只显示目标版本的改动。两种方式的区别见版本选择说明。
3. 阅读并追问已提交的 diff
从变更文件树中打开文件。每个行为变化都沿着调用者、修改的分支和对应测试读一遍。悬停在版本行上可以查看完整提交 ID。比较会固定在这些提交上；Codex 增加提交后，需要重新打开比较。
连接模型后，点击“让 AI 审查这次比较”，检查比较附件，再修改草稿：
审查这次比较中的取消、错误处理和调用方假设是否退化。每个问题都给出触发输入或状态、改动位置、预期与实际行为，以及支持判断的源码引用。区分原有问题和本次引入的问题，说明没有覆盖到的范围。
发送后逐一核对引用是否来自选定版本，并确认每个问题的触发条件确实可能出现。Git 比较对话始终只读。
4. 单独审查尚未提交的内容
返回侧栏带加减号的“改动文件”。“本地改动”将当前内容与 HEAD 比较，也可能包含 Yenpo 中尚未保存的文本。新增、修改和删除的文件都要看；使用 Git 命令或测试磁盘文件前，先保存打算保留的编辑。
需要区分暂存区与工作区时，运行以下只读命令：
git diff --stat HEAD --
git diff --cached --
git diff --
git ls-files --others --exclude-standard第一条汇总已跟踪文件相对 HEAD 的净变化；后两条分别展示已暂存和未暂存的差异。最后一条列出未跟踪且未被忽略的文件，需要打开文件阅读内容。已暂存修改和未暂存修改可能互相抵消，决定下一次提交具体包含什么时，不能只看净 diff。
“让 AI 审查所有改动”会为当前内容相对 HEAD 的改动另起草稿。这些文件不属于刚才的提交比较。如果 Codex 没有产生提交，它的工作可能全在这里。
5. 写清楚合并判断
记录比较的提交 ID、是否检查了未提交文件、确认的问题，以及实际运行过的测试命令。在准备合并的工作目录和版本中执行检查；本地文件上的测试可能覆盖了固定比较里尚不存在的代码。
要求 Codex 再修一轮后，重新查看相关提交比较和本地改动。单个函数仍看不懂时，可以用自己的模型解释并核对引用。想按一轮 AI 任务来组织审查，可以参考 Claude Code 工作流。