oh-my-pi conflict:// 实战：一行 @theirs 搞定所有 Git 合并冲突
【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi
oh-my-pi（omp）是一个内置 IDE 能力的 AI 编程代理。它最实用的功能之一，就是用conflict://协议把每个 Git 合并冲突变成一个 URL——读一次文件拿到冲突编号，写一行@theirs就能干净地解决冲突，批量模式conflict://*甚至能一次清空整份文件里的全部冲突。本文将带你在 5 分钟内掌握这套机制。
一、合并冲突，为什么 AI 也头疼？
传统工作流里，解决合并冲突是体力活：
git merge之后打开文件，满屏的<<<<<<<、=======、>>>>>>>- 人工判断保留哪一边（ours 还是 theirs）
- 手动删标记、剪贴板复制粘贴
- 文件里 20 个冲突块？重复 20 遍
把这件事交给 AI 代理时，还有一个隐藏坑：模型经常重复粘贴冲突块前后的上下文行，或者行号偏移后改错位置。oh-my-pi 的做法是——把冲突从"文本游戏"变成"URL 寻址"。
二、conflict:// 是如何工作的？
核心逻辑在 conflict-detect.ts 中，整个流程分四步：
| 步骤 | 动作 | 说明 |
|---|---|---|
| 1 | read文件 | 照常读取文件，顺手扫描冲突标记（零额外 I/O） |
| 2 | 注册冲突编号 | 每个完整的<<<<<<</=======/>>>>>>>块获得一个会话内稳定的编号，如#1、#2 |
| 3 | read 输出末尾附加摘要 | 显示⚠ N unresolved conflicts detected，列出每个冲突的行范围和双方内容预览 |
| 4 | write到conflict://N | 用选定的内容替换整个标记块（含两侧内容），文件即刻恢复干净 |
几个值得注意的设计：
- 编号稳定：解决冲突 #1 之后，#2 的编号不变，可以连续写入多笔而不必重新读取
- 按内容定位：替换时以"标记块内容"为锚点查找位置，即使你中途手工改过文件前部导致行号漂移也能命中
- 回声修复：模型若把冲突块前后的相邻行重复粘贴进新内容，系统会自动识别并去重（见 conflict-detect.ts 中的
trimBoundaryEcho）
三、实战步骤：从冲突清单到一行解决
1. 读取冲突清单，拿到编号
读文件时加:conflicts选择器：
read path: "src/session.ts:conflicts"输出形如：
⚠ 2 unresolved conflicts in src/session.ts - ours = HEAD - theirs = feature/x #1 L12-18 #2 L87-93 (3-way)这一步会注册编号，后续所有conflict://操作都依赖它。
2. 查看冲突某一方的内容
不想看整个带标记的块？给编号加作用域：
conflict://1 # 完整标记块 conflict://1/theirs # 只看 theirs 一侧 conflict://1/ours # 只看 ours 一侧 conflict://1/base # 只看 diff3 三方合并的 base 侧3. 一行 @theirs 解决单个冲突
write的content支持四个"侧边令牌"，整行恰好是它时才生效（写进真实代码里的@theirs不会被误展开）：
| 令牌 | 展开为 | 适用场景 |
|---|---|---|
@ours | 记录在案的 ours 侧 | 保留自己的改动 |
@theirs | 记录在案的 theirs 侧 | 采用对方分支的改动 |
@base | diff3 的 base 侧 | 回退到合并基线（仅三方合并可用） |
@both | ours + theirs 拼接 | 两侧是互相补充的新增（绝不适用于对同一行的竞争性修改） |
write path: "conflict://1" content: "@theirs"一行，冲突 #1 消失。也可以混写普通文本：
content: "// keep both\n@ours\n@theirs"这行注释会原样写入，随后依次展开 ours、theirs 内容。
4. 批量解决：conflict://* 一次清空
文件里 10 个冲突？通配符模式两种玩法：
统一策略——所有冲突都用同一侧：
write path: "conflict://*" content: "@theirs"按编号分别指定——每行编号: 侧边令牌：
content: "1: @ours 2: @theirs 3: @theirs"一次调用逐个解决，未列出的编号保持注册状态，可稍后重试。批量处理按文件内自底向上应用，同一文件内是原子的；跨文件部分失败会返回错误标志，失败的编号仍保留注册，方便重试。
四、conflict:// 速查表
| 操作 | 用法 |
|---|---|
| 获取冲突清单并注册编号 | read <file>:conflicts |
| 查看完整标记块 | read conflict://N |
| 查看单侧内容 | read conflict://N/theirs（或/ours、/base） |
| 解决单个冲突 | write conflict://N+@theirs等令牌 |
| 批量统一解决 | write conflict://*+ 侧边令牌 |
| 批量按编号分别解决 | write conflict://*+1: @ours形式指令 |
五、常见坑与自救
- 编号过期？文件被外部改动后，旧编号会失效，报错提示重新读取。解决办法：重新
read <file>:conflicts刷新注册。 @base报错：@base仅对 diff3 三方合并（有|||||||标记）有效，普通两方合并没有 base 侧。@both用错地方：它只做"ours 接 theirs"的拼接，适合两边各自新增不同内容的冲突；对同一行的竞争性修改，必须二选一或自己写出合并后的文本。- 误写了带文件前缀的路径：如
src/x.ts:conflict://1也能自动恢复识别，但推荐直接写裸conflict://1。 - CRLF 文件放心用：内部按 LF 记录、写回时自动还原
\r\n，换行风格不会乱。
六、源码与文档入口
想深入了解实现，可以直接读这些文件：
- 冲突扫描 / 编号注册 / 内容拼接：conflict-detect.ts
- write 工具的冲突分支：write.ts
- read 工具文档：docs/tools/read.md
- write 工具文档：docs/tools/write.md
- 集成测试（含真实批量解决用例）：conflict-integration.test.ts
- 主 README 第 18 节 "Conflict resolution, made easy."：README.md
本地体验的话，先克隆仓库：
git clone https://gitcode.com/GitHub_Trending/oh/oh-my-pi小结
oh-my-pi 的conflict://把合并冲突从"删标记、复制粘贴"的体力活，变成了读一次拿编号、写一行解冲突的 URL 寻址游戏。加上@theirs这类侧边令牌和conflict://*批量通配，处理一个 20 冲突的文件也不再是噩梦。下次 merge 之后，直接把文件丢给代理，看它一行@theirs清场吧。
【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
