用 AI 解决 Git 合并冲突：三类冲突的判断顺序与合并后验证清单

AI 解决 Git 合并冲突的正确姿势不是让它帮你删冲突标记，而是让它先判断冲突属于哪一类——文本冲突、语义冲突还是生成物冲突——再按类给出不同的处理方式。文本冲突可以交给模型合并，语义冲突必须人读两侧意图，生成物冲突（锁文件、构建产物）根本不该手改，应该重新生成。

先分清三类冲突，再决定谁能动手

绝大多数人把冲突当成「同一行被两个人改了」，于是习惯性地打开编辑器挑一边留下。实际上冲突至少分三层，处理成本差一个数量级：

• 文本冲突：两侧改的是同一段代码，但意图不冲突，比如一侧改了变量命名、一侧加了判空。合并结果是两边都要，模型很擅长。
• 语义冲突：Git 认为没冲突（甚至自动合并成功），但逻辑上错了。典型是两个分支各自给同一个 Kubernetes 清单加了端口，自动合并后出现重复端口或不匹配的标签。这类冲突不会报 CONFLICT，只会在线上炸。
• 生成物冲突：依赖锁文件、构建产物、格式化后的大段代码。手改毫无意义，正确做法是取一侧的版本然后重新跑生成命令。

判断顺序应该是：先看冲突文件路径——落在 package-lock.json、composer.lock、dist/ 这类路径上的，直接放弃手改；再看两侧改动是否在同一函数内；最后才看具体行。

用 AI 合并文本冲突：给它完整上下文，别只贴冲突块

只把 <<<<<<< 到 >>>>>>> 之间的片段丢给模型，是最常见的失败原因。模型看不到两侧完整的函数体和调用方，就只能靠猜，猜出来的代码语法正确、语义错误。

最小可用的输入应该包含四样东西：

1. 冲突文件在两侧的完整内容（不是片段）；
2. 两个分支各自的改动意图（从 commit message 或 PR 描述里取一句话）；
3. 冲突涉及的函数的调用方列表；
4. 项目的类型检查/测试命令，让模型知道验证手段。

提示词可以这样组织（此处为演示写法，方括号仅为占位）：「下面是同一文件在 main 与 feature 分支的两个版本，以及两次提交各自的意图。请给出合并后的完整文件内容，保留两侧的改动意图，不要丢弃任何一侧的功能，并说明你做了哪些取舍。」

变基冲突和合并冲突不是一回事

合并（merge）是一次性解决一个冲突点，变基（rebase）是逐个提交重放，同一个文件可能在不同提交上反复冲突。 GitHub 官方文档给出的三选一依然是基准：git rebase --abort 整体回退、git rebase --skip 跳过该提交（极少用）、修复后 git rebase --continue。

变基场景下用 AI 要额外注意一点：每一次 –continue 之后冲突上下文都变了，别把上一轮的合并结果直接复用到下一轮。正确做法是每个冲突点重新喂一次当前文件状态。

合并之后的验证清单

冲突解决完不等于正确。我习惯按这个顺序跑一遍，顺序不能颠倒：

• 类型检查优先：先跑 tsc、phpstan 之类，把语法层面的问题一次性暴露；
• 跑相关测试，而不是全量测试——合并冲突的影响面通常是局部的，全量跑会拖慢反馈；
• 对生成物重新生成：锁文件冲突解决后必须重跑安装命令，让工具自己算依赖树；
• diff 复核：用 git diff 看最终改动，确认没有把一侧的功能整段吃掉。

如果项目里已经有 CI，把这套验证固化进流水线比每次手工跑更稳，可以参考用 AI 搭 CI 流水线里的做法。合并审查阶段也可以顺手用代码评审清单过一遍，避免「冲突解决了但逻辑串味」的情况。

真正省时间的做法：让冲突不发生

AI 在冲突发生前比发生后更有价值。三个习惯能砍掉大部分冲突：

• 分支生命周期控制在两天以内，长分支必然累积冲突；
• 重构类改动单独提 PR，不和功能改动混在一个分支里——依赖升级这类改动尤其容易大面积撞车，处理方式见AI 辅助依赖升级；
• 对多人高频编辑的配置文件（路由表、国际化词条、清单文件）约定追加顺序或分区，把「同一行竞争」改成「不同区域写入」。

大型仓库里冲突往往来自上下文不透明——改的人不知道别人也在改。这种情况下先解决信息同步，比事后用模型拼代码有效得多，具体做法可参考Monorepo 上下文管理。

结论很简单：AI 适合做文本冲突的体力活和验证清单的执行者，不适合做语义冲突的决策者。把判断顺序固定下来，冲突处理就从「凭感觉挑一边」变成了可复现的流程。