让 Codex 修改项目后，开发者需要回答三个问题：原有工作是否保留，AI 实际改了哪些文件，合并后的行为是否符合需求。只看“任务完成”的回复，无法回答这些问题。
本文由 AIXiamo（AI夏末）整理，AI 辅助起草，命令与行为依据 Git 和 OpenAI 官方文档核对。下文是开发流程示例，不代表已验证的客户项目。
一、先确定改动属于谁
先暂停正在写入同一目录的任务，保存编辑器中尚未落盘的文件，再查看：
git rev-parse --show-toplevel
git status --short --branch
git worktree list
git diff
git diff --cached
第一条确认项目根目录；status 查看分支、修改与未跟踪文件；两个 diff 分别展示未暂存和已暂存差异。
需要记录的是“任务开始前已有的改动”。例如你已修改配置文件，Codex 又修改了同一文件，最后的差异可能包含双方工作。普通 git diff 也不会展示未跟踪新文件的完整内容，需按 status 列出的路径另行检查。Git diff 官方说明
可提交的原有工作，可以放到临时分支，按明确文件路径暂存、核对暂存差异并提交。不能提交的本地配置与忽略文件，要按项目规则单独保留。新建分支名称本身只建立引用，不会自动保存未提交内容。
二、让新任务拥有独立目录
假设已经确认本地 main 是本次任务需要的起点，在同一终端记录基线并创建目录：
review_base=$(git rev-parse main)
git worktree add -b codex/config-review \
../config-review "$review_base"
把 review_base 对应的提交号写入任务说明，并将新目录的绝对路径交给 Codex。main 是示例名称，应替换成实际基线；本地分支也不必然等于远端最新版本。
Git worktree 共享仓库的提交与分支信息，但各自拥有工作文件、HEAD 和索引。普通 git worktree add 从指定提交检出内容，原目录中尚未提交的修改不会因此自动复制过去。若新任务需要这些改动，应先保存成明确提交，再选择该提交作为起点。
Codex App 的托管 worktree 是另一个流程：官方文档说明，选择包含本地改动的起点时，应用可以将未提交改动带入。使用时应确认界面所选起点，避免把两种流程混为一谈。OpenAI worktree 文档
目录分开以后，进程仍可能访问共享端口、数据库或其他目录，因此还要明确允许修改的文件和服务范围。
三、审查文件和行为，再提交任务
在任务 worktree 内查看：
git status --short
git diff
git diff --cached
git diff --check
git diff --cached --check
核对改动文件是否属于需求范围，再阅读关键函数的完整上下文。diff --check 能发现部分空白错误与冲突标记，不能证明功能正确。
可以使用 Codex 的代码审查功能检查未提交改动或对照基线分支，同时要求指出具体文件、触发条件和证据。人工仍需核对审查结论，并执行项目已有的验收步骤；没有验证的部分应明确记录。OpenAI 代码审查说明
任务提交后，再比较基线到任务分支的差异：
git diff "$review_base"...codex/config-review
这一步审查的是已提交结果，所以前面的未提交文件检查不能省略。
四、在干净目录保留合并检查点
回到原项目根目录，在保留 review_base 的同一终端中，从相同基线创建验收分支：
git worktree add -b review/config \
../config-integration "$review_base"
cd ../config-integration
git status --short
git merge --no-ff --no-commit codex/config-review
确认验收目录没有待处理改动后再合并。这里同时使用 --no-ff 与 --no-commit，目的是在创建合并提交之前停下；单独使用 --no-commit 不能阻止快进合并更新分支。
出现冲突时先停止，查看未合并文件：
git diff --name-only --diff-filter=U
逐处判断双方需求，不能机械保留全部“当前”或“传入”内容。即便没有文本冲突，也要审查暂存差异并核验组合行为。审核通过后才提交，再按团队流程将验收分支并入目标分支。Git merge 官方说明
五、回退与清理也需要证据
若决定放弃尚未提交的合并，可以在合并前目录干净、原有工作已保存的前提下使用 git merge --abort。它尝试恢复合并前状态；若合并前带有未提交修改，或解决冲突时又产生需要保留的新工作，不能把它当成通用备份。
已提交结果需要撤销时，应另行核对目标提交和历史，使用产生反向提交的回退流程；合并提交还涉及父节点选择，不能照抄普通提交的处理方式。
清理 worktree 前，检查修改、未跟踪文件和忽略文件，保存需要的产物后再正常移除，保留 Git 对脏目录的保护。
AIXiamo 第一方维护的 AI 并行修改与 worktree 教程 提供共同基线、逐个合并和冲突停止的离线示例，可作为补充阅读。
一个可交接的 AI 改动，应留下基线提交、文件差异、任务提交、验收结果和未验证事项。这样，下一位开发者才能知道发生了什么，以及从哪里继续。