使用 ChatGPT、Codex Agent 做合并、Rebase 或处理多人协作代码时，经常会遇到一种非常隐蔽的问题：
Git冲突看起来已经解决了，测试也全部通过，但上线以后才发现，一段原本应该保留的业务逻辑没了。
常见表现包括：
- Agent处理冲突后，Git不再报错；
merge或rebase顺利完成；- 单元测试、Build都正常；
- 但某个新加的判断条件被覆盖；
- 另一个分支刚加的异常处理消失；
- 接口参数退回旧版本；
- 页面还能跑，业务行为却已经变了。
这类问题最危险的地方就在于：
Git认为冲突已经解决，不代表业务冲突真的解决了。
一、Git冲突本质上只是“文本冲突”
假设两个分支同时修改了同一个函数。
分支A增加：
VIP用户走新的折扣逻辑。
分支B增加：
库存不足时禁止继续下单。
Git看到两边都改了相同区域，于是产生冲突。
但Git不知道：
这两个逻辑其实都应该保留。
它只知道：
同一段文本被不同分支修改了。
所以真正需要解决的不是：
选A还是选B。
而是：
合并以后最终业务逻辑应该是什么。
二、最危险的是机械选择ours或theirs
处理冲突时，经常会看到：
ours
和：
theirs
如果 Codex Agent 为了快速完成任务，直接选择其中一边，冲突确实马上消失。
但另一边的修改可能也一起被丢掉。
例如：
A分支：
增加权限判断。
B分支：
增加缓存失效逻辑。
如果直接保留A版本，就可能把B的缓存逻辑覆盖。
Git会告诉你：
Conflict resolved.
但真实结果可能是：
一段刚开发好的功能没了。
三、为什么测试还能通过？
这是很多人最容易困惑的地方。
因为测试覆盖的并不一定是：
两个分支合并后的全部业务语义。
比如现有测试只检查：
- 接口能返回；
- 正常用户能下单；
- Build没有报错。
但刚刚被冲掉的逻辑可能是：
- 特殊权限；
- 异常状态；
- 边界条件；
- 某种配置开关；
- 某个新业务分支。
只要测试没覆盖到，整个测试集依然可能全部绿色。
所以：
测试通过，只能证明被测试到的行为正常。
不能证明：
冲突两边的意图都完整保留了。
四、解决冲突前先看“两边分别想做什么”
这是 Codex Agent 处理冲突时最应该做的一步。
不要直接盯着冲突标记：
<<<<<<<
=======
>>>>>>>
而应该先分别看：
当前分支为什么改这里？
另一分支又为什么改这里？
例如：
当前分支是在修：
订单重复提交。
另一个分支是在加：
新的优惠计算。
那最终代码就应该同时满足：
防重复提交 + 新优惠规则。
这才是真正的冲突解决。
五、冲突解决后要看“语义Diff”
很多人解决冲突以后只做：
git status
看到：
All conflicts fixed.
就结束了。
其实还应该继续检查：
合并前后到底少了什么。
重点看：
- 条件判断有没有丢；
- 新增参数有没有退回旧版本；
- 异常分支有没有消失；
- 配置读取有没有被覆盖；
- 新增日志、校验、权限有没有保留。
这比只看“文件有没有冲突”更重要。
六、配置文件冲突尤其容易被低估
业务代码冲突通常比较显眼。
但像这些文件：
- YAML；
- JSON；
- ENV模板；
- CI配置；
- 路由配置；
- Feature Flag；
如果 Agent 直接选一边，问题可能更隐蔽。
例如一个分支新增：
新服务地址。
另一个分支修改：
超时时间。
最终如果只保留其中一份配置，看起来文件完全合法，但另一项配置已经被覆盖。
所以配置冲突不能只检查：
语法对不对。
还要检查：
两边新增的配置项是不是都保留了。
七、函数签名变化也特别危险
比如一个分支把函数改成：
createOrder(userId, couponId)
另一个分支仍然使用：
createOrder(userId)
冲突解决时，如果 Agent 恢复成旧签名，部分调用可能仍然能跑。
但新业务参数已经被丢掉。
类似的问题还包括：
- DTO字段变化；
- API参数；
- 返回结构；
- 枚举值；
- Feature参数。
这些都不是普通文本变化。
而是：
接口契约变化。
八、最好补一个“冲突专项验证”
处理完Git冲突以后，不要只重新跑原来的测试。
还应该问：
这次冲突的两边，各自想实现什么？
然后针对两边分别验证。
例如冲突涉及：
权限判断 + 新订单状态。
那至少应该验证：
- 权限规则仍然有效；
- 新状态仍然可以正常流转；
- 两者组合场景也没问题。
这类测试才真正针对：
冲突解决是否正确。
九、Agent处理冲突时应该设置停止条件
如果遇到这种情况：
- 两边都改了核心业务判断；
- 两边都修改了同一个接口协议；
- 无法判断哪个行为是最新需求；
- 冲突涉及数据库Migration；
- 涉及权限、计费、状态流转等关键逻辑；
Codex Agent就不应该直接“猜一个”。
更稳的做法是：
停止自动合并，说明两边差异，再让开发者确认业务意图。
Agent最危险的不是不会合并。
而是：
不知道的时候仍然继续做决定。
十、可以直接这样约束ChatGPT、Codex Agent
以后让 ChatGPT、Codex Agent 自动解决Git冲突，可以直接要求：
遇到Git冲突时，不要机械使用ours或theirs。先分别说明两个分支在冲突区域各自修改了什么业务逻辑，再给出需要同时保留的行为。解决后检查最终Diff，确认两边新增的判断、参数、配置和异常处理是否仍然存在。如果无法确定业务优先级，停止自动处理并明确列出冲突点。完成后针对冲突双方的原始需求分别做验证，不要只以Build或现有测试通过作为完成标准。
这个约束能明显减少：
“Git冲突没了，但业务逻辑也没了。”
最后
Codex Agent自动解决Git冲突以后，测试能过，业务逻辑却丢了，真正的问题通常不是：
Git合并失败。
恰恰相反。
Git层面可能已经完全成功。
真正失败的是：
Agent只解决了文本冲突，却没有解决业务语义冲突。
更稳定的流程应该是：
理解两边意图 → 合并业务逻辑 → 检查最终Diff → 分别验证两边需求 → 无法判断时停止。
所以以后看到：
All conflicts fixed，tests passed。
还不能马上结束。
最好再确认一句：
两个分支原本想保留的业务行为，现在是不是都还在？
持续更新 ChatGPT、Codex、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。
