合并冲突后，不要只说“保留 ours”。先写明是 merge 还是 rebase，再按文件说明保留哪边。rebase 时两边称呼对调。改完检查 diff，不能留冲突标记。
要点
- 官方没有“保留 ours／theirs”按钮。Codex 能在本地仓库里读文件、改文件、跑你机器上已有的命令，包括 git；权限和沙箱仍由你选。合并冲突发生后，要它动手，先把操作类型和每边的取舍写成提示里的目标、上下文、约束和完成定义。（Codex CLI；Best practices）
- Git 官方文档写明：rebase 是把当前工作分支上的提交，一枚一枚重放到另一条线上。因此冲突出现时，ours 是已经变基上去的那一侧（从上游开始），theirs 是正在被重放的工作分支；换句话说，两边对调了。只对 Agent 说“保留 ours”，在 rebase 里很容易把你自己的改动丢掉。（git-rebase）
git checkout --ours或--theirs是按路径整份取出某一侧，不是按块精细合并。只在你确定整个文件都应采用某一侧时才用。多数业务文件要把两边意图合在一起，不要整文件覆盖。（git-checkout）- 提示里至少写清四件事：当前是 merge 还是 rebase，以及进到哪条分支；每个冲突文件是整份保留哪一侧，还是合并两边；禁止留下
<<<<<<<、=======、>>>>>>>；完成时要跑你指定的检查，并让你先看 diff。不要顺手改未冲突的文件。 - 贴失败 CI 日志时怎么限制改动范围，以及什么时候该先 Plan 再改代码，站内已有专文。本篇只谈冲突发生之后，怎么把“保留哪边”说清楚。（Codex：把失败的 CI 日志贴进去时，怎么限制改动范围、Codex：Plan／先方案后改代码什么时候该强制打开）
正文
场景
功能分支正在 rebase 到最新的主分支，冲突停在 src/pricing.ts。你对 Codex 说：“把冲突解决掉，保留 ours。”
如果它按字面执行 git checkout --ours，在 rebase 里 ours 常常是上游，不是你的功能分支。等你再看文件，折扣逻辑没了，主分支的改动留了下来。
这是时机判断的示意，不是某次逐字实测。官方没有“保留哪边”的模式。要它帮你收冲突，就得把操作类型和取舍写清楚。
可跟做步骤／可抄工作流
下面是用法建议。先自己看一眼 git status，确认这是 merge 还是 rebase，以及冲突文件有哪些。然后再开 Agent。
1. 先写操作类型，再解释 ours／theirs
提示第一行就写当前操作。不要默认 Agent 能从工作区自己猜对。
- 正在把
origin/mainmerge 进当前分支：ours 是当前分支，theirs 是进来的那一侧。 - 正在把当前分支 rebase 到
origin/main：按 Git 文档，ours 是已经变基上去的上游一侧，theirs 是正在被重放的工作分支，两边对调。
与其只写 ours／theirs，不如同时写人话：例如“保留功能分支上的折扣计算”“整份采用主分支的 lockfile”。两条一起写，对调时也不容易接错。
2. 按文件下指令，不要一句“全部保留我们的”
官方最佳实践把提示拆成目标、上下文、约束和完成定义。冲突处理正好适用：目标是解决哪些文件，上下文是 merge 还是 rebase，约束是每边怎么取，完成定义是检查什么。
可抄提示，按你的仓库改括号：
【目标】解决当前工作区里的合并冲突，不要改未冲突的文件。
【上下文】
- 当前操作：rebase（不是 merge）
- 当前分支：feat/checkout
- 上游：origin/main
- 因此：ours 是已经变基上去的 origin/main 一侧，theirs 是正在被重放的 feat/checkout。不要按 merge 的语义理解这两个词。
【按文件的取舍】
- src/pricing.ts：不要整文件 checkout。保留功能分支（本次 theirs）里的折扣计算，同时并入 main 里新增的税码字段。
- package-lock.json：整文件采用 origin/main 一侧。
- README.md：两边新增的段落都保留，删掉冲突标记后手工接顺。
【约束】
- 禁止留下 <<<<<<<、=======、>>>>>>>
- 禁止为了消掉冲突而删除仍需要的逻辑
- 禁止改未出现在 git status 冲突列表里的文件
- 不要把这次冲突扩写成一次重构
【完成定义】
- 先列出每个冲突文件你打算怎么处理，等我确认后再改；如果我已经在这条提示里写清取舍，可以直接改，但仍要先给处理说明
- git status 不再显示未解决冲突
- 跑 git diff --check，确认没有冲突标记
- 跑 npm test
- 最后用 git diff 或 --stat 汇总改动，让我审只在你确定整个文件都应采用某一侧时，才允许它使用 git checkout --ours 或 --theirs。业务代码通常要按块合并。lockfile、生成文件可以整份采用某一侧，或在源文件解决后再重新生成。
3. 权限保持在仓库范围内，交付看 diff
解决冲突需要在工作区里改文件，并运行 git 和测试。用你平时的工作区写入权限即可，例如官方文档里的 workspace-write，加上需要时再批准的命令。不要为了“把 rebase 做完”直接开 Full access，或把沙箱改成无限制。
界面上的审批和沙箱名称，以你当前客户端为准。ChatGPT 桌面应用和 IDE 扩展里，常见的是 Ask for approval、Approve for me、Full access；CLI 里可以用 /permissions 查看。需要跑 git 或测试时，按提示批准这一次或本次会话，不要把整个机器打开。
改完后你至少看三件事：冲突标记是否还在，未冲突文件有没有被顺手改掉，以及取舍是否按你写的执行。测试通过也不等于取舍正确。一边的逻辑被整份覆盖，测试仍可能是绿的。
常驻规则可以写进仓库根目录的 AGENTS.md，例如：遇到冲突先停，先报告文件列表，没有明确取舍不要擅自选边。这是把同一条纪律留下来，不是官方自带的冲突策略。
冲突面很大、策略还说不清时，可以另开一轮先列文件再决定。那是把范围说清楚，不必仅仅因为出现冲突就去开 Plan mode。Plan 的时机见站内旧文。
真实用户诀窍／反例
- 诀窍：人话和术语一起写。 “保留功能分支的折扣计算”比单独一个 ours 更不容易接错。
- 诀窍：lockfile 与业务文件分开下指令。 两类文件的正确取舍通常不一样。
- 诀窍：先看
git status，再发言。 连 merge 还是 rebase 都没确认，就不要让它开始改。 - 反例：只说“保留 ours”。 在 rebase 里，这个词常常不是功能分支那一侧。
- 反例：让它“看着办，选更合理的一边”。 产品取舍不在代码里时，它只能猜。
- 反例：整份 checkout 完事。 某一侧的新字段或修复会被盖掉。
- 反例：留下冲突标记，或把标记里的两边注释掉就算解决。 完成定义里应要求
git diff --check。
适用边界
- 本篇只谈：本地已经出现合并冲突之后，怎么向 Codex 或 Cursor 里的 Codex 说明保留哪边。不覆盖贴 CI 日志时如何限制改动范围，也不覆盖何时强制先 Plan。
- 官方没有自动选边的功能，也没有保证 Agent 一定按你的取舍执行。提示可以写清，终审仍是你的 diff。
- ours／theirs 的含义以当前这次 Git 操作为准，并以 Git 文档为准。cherry-pick 或其他操作如有不同，先自己确认，再写进提示。
- 沙箱、审批和按钮文案随客户端变化，以现页为准。不要为了结束一次 rebase 就解开全部权限。