使用 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.就结束了。其实还应该继续检查合并前后到底少了什么。重点看条件判断有没有丢新增参数有没有退回旧版本异常分支有没有消失配置读取有没有被覆盖新增日志、校验、权限有没有保留。这比只看“文件有没有冲突”更重要。六、配置文件冲突尤其容易被低估业务代码冲突通常比较显眼。但像这些文件YAMLJSONENV模板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 fixedtests passed。还不能马上结束。最好再确认一句两个分支原本想保留的业务行为现在是不是都还在持续更新 ChatGPT、Codex、AI Agent 与大模型开发工作流实战内容更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。