合并冲突时怎样分清两边意图，不让 AI 直接覆盖

冲突标记只显示文本位置，不显示业务意图

先分别理解当前分支和待合并分支为什么改这段、依赖哪些文件和测试，再决定保留、组合或重写。直接选 ours/theirs 很容易丢掉另一边的必要行为。

同一逻辑被两边修改

常见原因：两个变更可能解决不同问题或建立不同不变量。

处理方法：分别读取提交、测试和调用方，列两边必须保留的行为，再写兼容实现。

把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。

一边重命名，一边继续编辑旧文件

常见原因：文件路径变化掩盖了内容修改。

处理方法：追踪历史和符号，先把内容改动迁到新位置，再删除旧文件。

确认“一边重命名，一边继续编辑旧文件”已经有可回查结果，再进入“依赖或锁文件冲突”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

依赖或锁文件冲突

常见原因：手工拼接锁文件可能产生不存在的依赖图。

处理方法：先决定清单文件的正确依赖，再用项目包管理器重新生成并审查差异。

确认“依赖或锁文件冲突”已经有可回查结果，再进入“生成物冲突”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

生成物冲突

常见原因：源数据或生成器已经变化，直接合并产物会过期。

处理方法：确认权威源，解决源文件后运行仓库生成命令，不手改生成结果。

需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“冲突决策记录与回归结果”。

解决后重跑两边关心的测试

冲突决策记录写两边意图、选择、受影响路径和回归。只做到 Git 不再显示冲突，不能证明业务正确。