AI 解 merge 冲突看起来像魔法，直到某天它「解决」冲突的办法是悄悄把一个分支的意图删掉一半。产物照样能编译、照样过语法检查、照样过大部分单元测试，于是你把一个静默回退送上了线。真正的流程不是「让 AI 全自动合」，而是把每个冲突归到三类里的一类，对每一类给恰当的信任。归类归对了，14 个冲突的 rebase 20 到 40 分钟解完，而不是手工 2 小时，回退率和手工持平。
一句话总结
- 把每个冲突分到琐碎（约 60%）、结构性（约 30%）、语义性（约 10%）。前两类交给 AI，第三类自己扛。
- 琐碎冲突：手工解，或接受 IDE 的一键建议。比写 prompt 快。
- 结构性冲突：一个文件一份地交给 AI，附带指令「保留两边意图、什么都别删、调和不了就把 marker 原样还回来」，然后核对 diff、跑这个文件的测试。
- 语义性冲突（逻辑跨多个文件）：永远不外包。AI 读不懂你两周前写的 feature spec，它只会选 parse 起来更顺那一边，而不是正确那一边。
- AI 最主要的故障模式就是悄悄丢掉一边。每个非琐碎的解都用
git diff <merge-base>..HEAD核一遍，确认两个分支的逻辑都还在。
工具现状，2026 年 6 月
冲突解决现在已经内建进主流 AI 编码工具里，区别在于它们能看到多少上下文、在哪里运行。
| 工具 | 运行位置 | 能看到什么 | 价格（2026 年 6 月） | 适合 |
|---|---|---|---|---|
| VS Code 合并编辑器 + Copilot | 编辑器内 | merge base + 两边改动 | 任意付费 Copilot 套餐（Pro 每月 $10） | 一键解结构性冲突，diff 就摆在眼前 |
| Cursor | 编辑器内 | 整文件 + 仓库上下文 | Pro 每月 $20（Sonnet 4.6、Opus 4.7、GPT-5.5、Gemini 3.1 Pro） | 周边代码很重要的多 hunk 冲突 |
| Claude Code | 终端 / IDE | 按需读整个仓库 | 随 Claude Pro 每月 $20 附带（仅 Anthropic 模型） | 想先读历史再解的冲突 |
| GitHub「Fix with Copilot」 | github.com 的 PR 页面 | PR diff，会跑 build + 测试 | 任意付费 Copilot 套餐 | PR 上异步解；只有 build 和测试都过才推送 |
VS Code 的合并编辑器在三方视图里有个 Resolve with AI 的星标；Copilot 会用 merge base 加两个分支的改动，给出一份尽量保留两边意图的解（VS Code 文档）。github.com 上的 Fix with Copilot 按钮（2026 年 4 月 13 日上线）把有冲突的 PR 交给一个云端 agent，由它解冲突、跑 build 和测试，只有都通过才推送（GitHub Changelog）。它们有同一个盲区：调和的是文本，对于「两处改动文本上能合、逻辑上却互相矛盾」的情况，只是有时能抓到。
三类冲突
- 琐碎类 —— 格式、import 顺序、空白、两边加了同一行、两边改了同一条注释。AI 处理得很稳，活跃仓库里大约占 60%。
- 结构性 —— 两边都改了同一个函数但意图不冲突（一边加参数、一边加校验）。AI 加复核能处理，约 30%。
- 语义性 —— 改动跨多个文件，合并需要理解每一边在做什么。AI 不能稳定处理，你必须自己扛。约占 10%，但绝大多数合并回退是这一类引发的。
类别看的是意义，不是 marker 长什么样。两个 <<<<<<< 块长得一模一样的冲突，完全可能一个是琐碎、一个是语义。
先把 marker 设好
解之前先打开 zdiff3。默认冲突样式只显示分叉的两边；diff3 和 zdiff3 还会显示共同祖先（||||||| base 块），这正是让你——以及 AI——看清每一边究竟改了什么、而不是靠猜的关键。zdiff3 还会把两边共有的行提到冲突区域外，让 marker 只圈住真正有冲突的文本。它在 Git 2.35（2022 年 1 月）随版本发布（git 文档）。
git config --global merge.conflictStyle zdiff3
git config --global rerere.enabled true # 复用已记录的解法开了 zdiff3，一个两边都保留了开头两行的冲突会渲染成这样——共有的 D/E 在 marker 外面，base 块告诉你起点是什么：
D
E
<<<<<<< ours
F
G
||||||| base
# original line
=======
X
Y
Z
>>>>>>> theirs把 base 块（|||||||）喂给 AI 是准确率最大的一次升级。没有它，模型是在从两个终态反推意图；有了它，它能看清每一边各自加了什么 delta。
开工前
- 两边分支独立测试都得是绿的。
main是红的就别合进main，先修main，否则你分不清哪些失败是 merge 引入的。 - 快照工作区。
git stash任何未提交的改动，这样解完后的git diff才有意义。 - 提前定好回退线。 「这次超过 30 分钟、或者哪里感觉不对，就
git rebase --abort手工解。」事先想清楚能避免第 45 分钟时的沉没成本决策。 git status先扫一遍。 它列出每个冲突文件。锁文件（package-lock.json、yarn.lock、Cargo.lock）和生成代码：按 manifest 重新生成，绝不 merge。
具体步骤
- 跑
git status做分流。把冲突文件按类别分组。锁文件和生成代码送去重新生成。标出疑似语义冲突——两边都动到相关业务逻辑的地方。 - 琐碎类：手工批量处理（或接受 IDE 的一键建议）。为一行空白冲突写 prompt 比直接解还慢。
- 结构性：交给 AI，一文件一份。 附上完整
<<<<<<<块连同|||||||base、上下几行上下文、和目标。用git diff --diff-filter=U列出所有还带 marker 的区域。git diff --diff-filter=U # 所有未合并区域 - 每份 AI 的解，往下走之前先核。 每解完一个就跑对应测试文件。对一份 AI 的解，信任度要比一个初级开发的 PR 还低——读 diff。
- 语义冲突：自己做。 先读两边历史：
git log --oneline branch-a -- path/to/file，branch-b同样。先理解每一边改动的意图再合。AI 可以建议，你来决定。 - 跑完整测试套件，再跑集成和 e2e 测试。 合并回退常常通过单元测试，却在调用点或跨模块边界处炸掉。
- commit 带备注。 在 merge commit message 里记下每个靠判断解的冲突、以及每个「AI 建议删这段」的决定。未来排查回退的你，正需要这些。
保留两边意图的 Prompt
把冲突区域（连同 zdiff3 的 base 块）粘到标注处。方括号里是占位符。
我在解一个 merge 冲突。这是带上下文的冲突区域
（zdiff3 样式，所以包含 ||||||| base 块）：
[粘从 <<<<<<< 到 >>>>>>> 加上下各 10 行]
HEAD 分支（ours）在改：[一句]
incoming 分支（theirs）在改：[一句]
产出一份合并版本：
1. 保留两边的意图，任一边的逻辑都不删。
2. 如果两边对同一条语句做了不兼容的修改，就保留冲突
marker 不动，并告诉我必须做哪个决定。
3. 不要「顺手改善」冲突区域之外的内容，只动有冲突的地方。
4. 只返回合并后的代码、不要解说，除非第 2 条适用。第 2 条是承重的一句：它给模型「拒绝」的权限，正是这一条把一次静默的坏合并，转成一句诚实的「你来决定」。
质量检查
- 两边都活着。 每个非琐碎冲突，都确认结果里两个分支的逻辑都在（除非有一边本来就是要替换另一边）。这正是 AI 最常翻车的地方。
git diff <merge-base>..HEAD -- path/to/file显示相对共同祖先的合并后改动。每个结构性和语义文件都目视核一遍。- 完整测试套件通过。集成和 e2e 测试通过。
- merge commit message 列出每个判断点、每个 AI 建议的删除。多数回退都直接追到这些点上。
容易踩的坑
- 因为 marker 长得像就把所有冲突都当琐碎类。 类别看的是意义，不是语法。
- 让 AI 解语义冲突。 它读不懂你的 feature spec，它选的是 parse 起来更顺那边，不是正确那边。
- 接受「看起来合上了」的输出却不确认两边逻辑都在。「删了一半」这种故障能过语法和大部分单元测试。
- 用 AI 合锁文件或生成代码。 从源头重新生成。
- 跳过 merge 后的集成测试。 能过单元测试的解，照样能在两个模块外的调用点炸。
- 不在 commit message 里记判断点。 两周后出问题，你根本回不去为什么这样合的。
- 不给上下文就让 AI「解掉冲突」，没说每边在做什么。它瞎猜，有时还猜错。
FAQ
- 该在 IDE 里用 AI 还是在 chat 里？ 结构性冲突，IDE 集成的 AI（Cursor、Claude Code、VS Code 合并编辑器）更好——它能看到整文件和 merge base。单个临时冲突，只要你把
zdiff3块粘进去，chat 也行。 - GitHub「Fix with Copilot」按钮干什么？ 2026 年 4 月 13 日上线，它把有冲突的 PR 交给 Copilot 云端 agent，由它解冲突、跑 build 和测试，只有都过才推送。任意付费 Copilot 套餐可用；Business/Enterprise 需要管理员开启云端 agent。仍然要审 diff——测试过了不等于两边意图都还在。
git rerere会取代 AI 吗？ 不会，两者搭配。rerere（reuse recorded resolution，复用已记录的解法）在长 rebase 里把你已经做过的解法在重复冲突上重放；AI 处理新出现的冲突。两个都开。- AI 把冲突 marker 原样还回来怎么办？ 对语义冲突来说这是赢的状态——模型在说「你来决定」。别硬推，手工解。
- 能在不属于我的文件里让 AI 解冲突吗？ 风险大。owner 有你没有的上下文。非做不可的话，合之前把解法发给 owner 看。
git merge也适用吗？ 适用。类别模型和哪个命令产生冲突无关，只是中止命令不同（git merge --abort对git rebase --abort）。