AI 解 merge 冲突看起来像魔法——直到某一天它”解决”冲突的方式是把一个分支的意图删掉一半。真正的流程不是”让 AI 全自动合”，而是看清你面对的是三类冲突中的哪一类，对每一类给恰当的信任。看错类，悄悄回退就上了线；看对了，14 个冲突的 rebase 20 分钟解完，对比手工 2 小时。
这篇主要解决什么问题
一个三类冲突模型（琐碎、结构性、语义性）、每一类对应的 AI 工作流、以及防止”AI 删一边”这种故障的护栏。把冲突区域贴进 Claude Code、Cursor、通用 chat 后能拿回”两边意图都保留”的合并的实操命令。
这篇适合谁看
在大团队里频繁 rebase 的人、维护长寿命 feature 分支的维护者、清理几个月没合的旧分支的工程师、要为一个小组管 merge 纪律的技术负责人。
什么时候适合用
3 个以上冲突的 rebase 或 merge，否则就要坐下来手工解。落后 main 几周的长寿命 feature 分支。要保留两个并行功能实现各自一半的 squash-merge。
什么时候不建议用
安全关键代码（鉴权、权限、加密）的冲突——每一行自己读。一边本来就该回退另一边的冲突——AI 读不出意图。锁文件（package-lock.json、yarn.lock）的冲突——按 manifest 重新生成，不要”merge”。生成代码的冲突——重新生成，不要手 merge。
开工前
- 开始前确保两边分支独立测试都过。main 红的，别合进 main；先修 main。
- 暂存工作区。
git stash任何未提交的修改；rebase / merge 从干净状态开始，解完后的git diff才有意义。 - 提前定回退线。“这次解超过 30 分钟或者哪里感觉不对，就
git rebase --abort手工解。“事先承诺回退线能避免沉没成本陷阱。 - 读冲突清单。
git status列出每个冲突文件。先扫一遍。看到锁文件或生成代码，先按”重生成”处理掉。
三类冲突
- 琐碎类 —— 格式、import、空白、两边加了同一行、两边改了同一条注释。AI 处理得稳。活跃仓库里大约 60%。
- 结构性 —— 两边都改了同一个函数但意图不冲突（一边加参数，一边加校验）。AI 加复核能处理。约 30%。
- 语义性 —— 改动跨多个文件，合并需要理解每边在做什么。AI 不能稳定处理，你必须自己做。约 10%，但 90% 的合并回退由这一类引发。
具体步骤
- 跑
git status分流。把冲突文件按类别分组。锁文件和生成代码：重新生成，不 merge。标出疑似语义冲突（两边都动到了相关业务逻辑的地方）。 - 琐碎类批量处理。打开每个文件，看 marker，接受显而易见的解法。比让 AI 一个一行冲突挨个 prompt 更快。
- 结构性冲突，把冲突区域贴进 AI。包括完整的
<<<<<<<块、上下几行上下文、目标：保留两边意图。不要删任一边的逻辑。无法调和就保留 marker 并说明。git diff --diff-filter=U # 列出所有冲突区域 - AI 给的每一份合并按文件应用，一次一份。每完成一个就跑对应测试。对 AI 的信任比对初级开发还要低——每个 diff 都核。
- 语义冲突自己做。读两边历史（
git log --oneline branch-a -- path/to/file，branch-b 同样）。先理解每边在做什么再合。AI 可建议，你决定。 - 全部冲突解完后跑完整测试。再跑集成 / e2e 测试。合并回退常常通过单元测试。
- 该 squash 就 squash，commit、push。merge commit message 里把所有靠判断解的地方记上——未来的你会感谢现在的你。
保留两边意图的 Prompt
我在解一个 merge 冲突。这是带上下文的冲突区域：
\{粘从 <<<<<<< 到 >>>>>>> 加上下各 10 行\}
HEAD 分支（当前）在做：\{一句\}
incoming 分支（另一边）在做：\{一句\}
产出一份合并版本：
1. 保留两边的意图。任一边的逻辑都不删。
2. 两边对同一语句做了不兼容的修改时，保留冲突 marker 并说明
我需要做哪个决定。
3. 不要"顺便改善"冲突区域之外的内容。只动有冲突的地方。
4. 只返回合并后的代码，不要解说，除非第 2 条适用。质量检查
- 每个冲突区域：合并版本里两边的逻辑都在（除非有一边明确就是要替换另一边）。AI 最常见的故障就是默默丢一边。
git diff <merge-base>..HEAD -- path/to/file显示两边的变更。每个非琐碎冲突都目视确认一次。- 全部单元测试通过。集成测试通过。
- merge commit message 列出所有靠判断的冲突。未来 debug 需要这条。
- 任何”AI 建议删这段”的决定都在 commit message 里标记。多数回退都追到这里。
怎么把这流程沉淀下来
- 把三类分流当 checklist 每次 merge 都跑。
- 把”保留两边意图”的 prompt 存成片段。这是这套流程里最值得复用的产物。
- 记录 AI 哪些类型解得干净、哪些需要重做。规律会浮现——你代码库的特定区域 AI 总搞不定。
- 痛苦的 merge 之后在团队频道留一句话：“
src/billing/*的冲突别让 AI 解——上次它把两套定价模型搞混了。“低成本沉淀部落知识。
建议的操作流程
git status 分流 → 琐碎类手工批处理 → AI 一文件一份地解结构性冲突并核 → 语义冲突人来做 → 测试通过 → 集成测试通过 → commit 带判断点备注。14 个冲突的 rebase 通常 20-40 分钟，对比手工 2 小时，回退率相当（只要尊重类别）。
容易踩的坑
- 因为 marker 长得像就把所有冲突都当琐碎类。类别看的是意义不是语法。
- 让 AI 解语义冲突。AI 读不懂你两周前写的 feature spec。它会选 parse 起来更顺那边，不是正确那边。
- 接受”看起来合上了”的 AI 输出但不确认两边逻辑都在。“AI 删了一半”这种故障能通过语法检查。
- 用 AI 合锁文件或生成代码。重生成。
- 跳过 merge 后的集成测试。能通过单元测试的解，照样可能在调用点炸。
- merge commit message 不记判断点。两周后出问题，根本回不去为什么这样合的。
- 不给上下文就让 AI “解掉冲突”，没说每边在做什么。AI 瞎猜，有时对，有时不对。
FAQ
git rerere怎么样？: 值得开。它会记下解法并在后续 rebase 自动重放。配合 AI：rerere 处理重复冲突，AI 处理新冲突。- 应该在 IDE 里用 AI 还是 chat 里？: 结构性冲突，IDE 集成的 AI（Cursor、Claude Code）更好——它能看全文件。一次性的临时冲突，chat 就够。
- AI 把冲突 marker 返回回来怎么办？: 好事。AI 在说”这是语义冲突，你来决定”。别硬推；手工解。
- 能在不属于我的文件里让 AI 解冲突吗？: 风险大。owner 有你没有的上下文。如果非做不可，合之前把解法发给 owner 看。
git merge也适用吗？: 适用。类别模型和哪个命令产生冲突无关。