Vibe Coding 合并冲突：AI 辅助对账而不丢双方语义

冲突文件里保留了两边都编辑的几行，AI 很容易在几秒内输出一份没有 <<<<<<< 的版本。但“能解析”不等于“已合并”：一边可能增加租户授权，另一边改变缓存键；两段文本可以顺利拼在一起，却让授权检查发生在缓存命中之后。真正的合并对象是双方行为，不是冲突标记。

Git 高级工作流提供 merge、rebase 等命令的综合背景；本文只处理 Vibe Coding 场景的语义对账。它也不同于Git Bisect 隔离回归：Bisect 寻找最早坏提交，冲突解决是在尚未形成结果提交前证明两边承诺仍成立。

先冻结操作现场，不急着选边

冲突出现后先记录当前操作类型、起始对象、目标对象、git status 和未合并路径。不要把 merge、rebase、cherry-pick 的 ours 与 theirs 当作永远等于“我的分支”和“同事分支”；标签含义取决于正在执行的操作。使用明确提交 ID、分支角色和任务 claim 描述来源，比口头说“保留 ours”可靠。

Git 在典型三方冲突的 index 中保存 base、ours、theirs 阶段。可以检查未合并项，并分别读取 :1:path、:2:path、:3:path；二进制、rename/delete、submodule 或缺少共同 base 的情况需要专门处理，不能假设三份文本总存在。先把完整三方版本交给 Agent，再附双方 PR/任务的验收声明、相关测试与仓库规则。只给冲突片段，会丢失调用方和不变量。

任何自动修改前都保留开工基线与恢复检查点。操作来源不明、工作树还有第三方改动或 Agent 无法解释 base 时，应停下；根据当前操作选择官方支持的 abort 路径也需要确认它不会覆盖操作开始前的未提交工作。

建一张语义账本再生成候选

对每个冲突区域写四列：

AI 的第一步不是写最终代码，而是指出冲突类型：同一语法位置的文本冲突、不同位置却共享不变量的语义冲突、接口版本冲突、删除与修改冲突、生成源与产物冲突。后两类即使 Git 没标记，也要进入对账。例如一边新增枚举值，另一边把 default 写成成功分支，自动合并仍会吞掉未知状态。

然后让 AI 提出至少两个候选及各自舍弃项，禁止“以较新文件为准”“测试多的一边为准”这类替代判断。人类 owner 决定产品语义、兼容承诺和风险接受；AI 可以定位调用链、生成最小补丁和补充测试，但不能因为某边更容易编译就批准丢弃另一边。

验收组合语义，而不是分别跑旧测试

先运行 A 与 B 原有的针对性测试，确认没有直接回归；再增加只有组合后才有意义的交叉反例，例如授权与缓存、重试与幂等、删除与后台任务、可选字段与旧客户端。两边各自绿色只能证明孤立行为，不证明次序、锁、错误映射或生命周期能共存。

对公共 API、数据库迁移和权限变化，重新检查数据模型与业务不变量、API 合同示例与非功能门。若组合需要改变已批准规格，进入规格变更，而不是把冲突解决提交当作隐式批准。

解决后逐文件检查没有残留标记，再用选择性暂存与 Diff 自审只加入本次对账内容。git diff --check 或编译通过只能支持格式和结构声明；最终收据还应列出双方 claim、采用方案、被拒方案、组合测试、人工决策人和当前结果对象。

给不确定性保留退出通道

如果任一方的意图只能从聊天猜测，安全结果是 NEEDS_OWNER_DECISION。可以保留冲突现场、输出最小问题并停止，不要先提交一个“看起来合理”的版本再等线上验证。若冲突处理越改越大，放弃当前操作、回到检查点重新切片，通常比继续修补更可审阅。

合并完成后发现语义丢失，按Revert 与 Reflog 恢复流程区分共享影响与本地对象找回；不要重写已被他人基于的历史来掩盖错误。一次可靠的 AI 辅助合并，结果不是更快删掉标记，而是双方原本要保护的行为都能被新证据逐条指出，任何取舍也由有责任的人明确留下。