合并冲突
Merge Conflict也常被叫作：冲突conflict合并报冲突
「两条线都改了同一个地方，Git 不知道该听谁的，停下来问你。」
合并冲突 Merge Conflict
两条分支改了同一处，Git 停下来等你决定听谁的。
合并冲突（merge conflict）发生在两条线改了同一个地方：分支 A 把文案改成了「你好」，分支 B 把同一行改成了「欢迎回来」，Git 不知道该听谁的，就停下来，把问题交给你。
冲突不是错误，是 Git 在尽职——它把两边的版本都留在文件里，用 <<<<<<< 和 >>>>>>> 标出来，等一个人做决定。真正出问题的是处理方式：很多人（和很多 AI）图省事「选最新的」或「选我这边」，结果另一边的活就丢了。
正确的流程是：先让 AI 把两边分别改了什么讲清楚，由你决定保留哪边（或都要、或写成新的），再动手。解决完一定要检查整个项目里没有残留的冲突标记——那是程序直接报错的头号原因。
长什么样 真实可交互，不是截图
<<<<<<< 分支A
你好，欢迎
=======
欢迎回来，老朋友
>>>>>>> 分支B冲突标记把两边的版本都留在文件里等你决策。注意：留哪边是人的取舍，跟「哪个版本新」没有关系——AI 擅自选一边，另一边就没了。
拆开看，里面有这几块
-
1
冲突标记 Conflict markers
<<<<<<< 、======= 、>>>>>>> 三段，把两边的版本框出来，等你填答案。
-
2
双方内容 Both sides
标记中间夹着的内容，分别来自哪条分支。这是你决策的全部依据。
-
3
冲突文件清单 Conflicted files
git status 里标着 both modified 的文件，就是这次合并要处理的全部。
-
4
决策 Decision
由人决定：留 A / 留 B / 都要 / 写新内容。这是冲突的本质。
常见的有哪几种
两边的改动二选一，另一边的改动放弃。
用在：两边的改动本来就互为替代
把两边的改动按顺序都留下。
用在：两边的改动是互补的
两边都不满意，用一句话把两边意图合成新的写法。
用在：两边都对但合起来不对
容易搞混？这样区分
冲突不是代码写错了，是 Git 的正常询问：两边的改动都要保留，需要人做决定。报错是程序没法运行，冲突是版本控制需要决策。判断方法：冲突文件里能看到 <<<<<<< 标记和两边的完整内容。
覆盖是把一边的内容整体替换掉，另一边的改动直接消失；正确处理冲突是逐处取舍：每处看清两边，决定留谁。判断方法：解决后两边的改动都还在吗？
什么时候用得上
按「先讲清两边 → 人决定 → 清标记」走。每一步都可观察，AI 糊弄不了。
必须让它先展示两边分别改了什么，再由你决定。它直接改，就是在替你拍板。
全项目搜 <<<<<<< 确认零残留，再跑一遍两边的功能场景确认改动都在。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
【任务】解决 [项目目录] 合并 [分支A] 和 [分支B] 时出现的冲突 【范围】只处理冲突文件和这次合并，不改动无关代码 【边界】 - 先用 git status 列出所有冲突文件，逐个告诉我**每个文件里两边各改了什么**，任何一边都不许跳过 - 保留哪边由我决定：把两边内容都展示出来，让我选「留 A / 留 B / 两边都要 / 写成新内容」，你按我的选择改 - 解决完一个文件就 git add 一个，全部解决后再 git commit - 禁止为「看起来干净」重写整个文件或删掉另一边改动；禁止在冲突标记没清干净的情况下声称完成 【交付】 1. 冲突文件清单 + 每个文件里两边改动的内容（用大白话讲） 2. 我每次决策后，你改了什么、为什么这么改 3. 全部解决后：搜索整个项目确认没有残留的 <<<<<<< / ======= / >>>>>>> 标记，并贴出 git status 确认干净
冲突解决最大的坑是 AI 擅自选边。这段强制它「先展示两边内容、由你决定」，并要求解决后搜残留标记——两条都指向可观察的证据，糊弄不了。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「主路径」这层：真实用户的正常操作能走通，不靠特殊参数。
要亲眼看到这些，才算数
- 跑 git status，能明确看到冲突文件（标着 both modified），不是一句「有点冲突」带过。
- 打开冲突文件，能看到 <<<<<<< / ======= / >>>>>>> 标记，并确认标记两边的内容能对应到两条分支。
- 让 AI 先解释两边各改了什么——它不解释就直接改，就是在替你拍板，要求它停下重来。
- 解决后在整个项目里搜索 <<<<<<<，一个都不剩；git status 干净。
- 跑一遍两边的功能场景：分支 A 的功能在、分支 B 的功能也在——这才是冲突解决真的完成了。
它常这么糊弄你
- 「我保留了最新的版本」——留哪边是人的取舍，不是版本新旧。AI 擅自选一边，另一边的活就丢了。
- 「冲突解决了」——文件里还残留 <<<<<<< 标记，程序直接报错。搜一下就知道。
- 「两边差不多，我合并了」——没给你看两边分别是什么就自己拼，等于替你做了决定。
- 把冲突文件整个重写，说「干净了」——另一边的改动全没了，这比冲突本身更糟。
冲突解决能验到「主路径」层：命令级的事实（无残留标记、git status 干净）只是基础，还必须跑真实场景确认两边的功能都在——那是文件内容层面的验证，光看命令输出不够。
考考你 选一个你觉得对的
合并出现冲突，AI 说「我帮你选了一边，保留最新的」。你该怎么回应？
冲突的本质是两边的决定都要看，留哪边是人的取舍，跟版本新旧无关。AI 擅自选一边，另一边的改动就丢了。删掉重写等于丢掉信息，整体回退是回避问题不是解决问题。