vibe coding下如何安全合并代码？

取决于你是什么项目

之前我给我的niri fork合入layer动画支持

最后发现这些会爆炸

只合入一部分 剩下的按照原来的逻辑重写^-^

这个问题本质上是一个边界问题。我们既然基于开源社区去派生，那我们在开源的基础上去修改了什么？如果边界很清晰的话，那么这个merge就会很容易。但是如果你是改了开源社区的基础架构，或者整体框架，或者一些核心的协议，那这个merge就会变得很困难。本质上我们要去思考是否和开源社区还是在一条路上。那这个过程也很考验架构。如果你们再去和社区，在社区的代码的基础上去添加新的东西的时候，保持好了边界，模块化，那么后续融合会相对容易。我也在做类似的事情，会添加一个remote，会定期去sync. 但是代码本质上很艺术，所以我们在修改的时候都是基于Adapter或者plug in的这种形式。那么如果它的框架不符合我们要求，那会push到社区来保证后续的持续可合并。因为从本质上我们我们是认可社区的代码结构的。

我们根本分不清哪些改动是我们自己的，哪些是官方的

怎么会，难道没有版本控制系统吗 ^-^

我猜肯定是分得清的

但如果是ai搞的，那确实分不清到底什么代码是需要的

不过也好办交给ai合并就完了

简单来讲，控制好边界，你们自己的东西写好插件、适配器，保留在本地，如果不想提供给社区。如果你认可社区的架构和演进，那么把你们修改的框架型的基础设施型的代码提交到社区，这是最好的方式。否则没有任何解法可以让你很好地把社区的代码融合进来。

讲得很好啊

那会push到社区来保证后续的持续可合并

但是这个是个比较困难的事情

如果没办法合并的话，本质上还是需要好的架构去适应

这种情况应该尽量做成插件，只增不删，尽可能小的侵入，隐藏>删除

这些二次开发几乎全是靠“vibe coding”快速堆出来的，并没有像传统“古法编程”那样逐行 review 过代码

根本分不清哪些改动是我们自己的，哪些是官方的，更不知道应该保留哪一部分、舍弃哪一部分

说明之前的实践有严重问题，那如今的代码就没有保留的必要了，让 AI 帮你分析到底是从哪个版本改过来的、增加了什么，然后重新实现，以后让 AI 教你们怎么修改才能最小侵入、方便跟随上游。AI 时代少拯救，多重构、重写。

有没有什么实用的技巧或工具可以帮我们快速区分双方改动，降低合并风险的

git 就足够了，是你们的流程有问题，我确实见过二开的直接下载源码压缩包，改完之后只剩一个雷霆大 commit 的，而且每个文件还都按照他的本地口味被自动格式化了，神仙难救

所以说这里有一个边界呀，就是社区的架构是否能够承载你本身的业务。这是一个大的边界，如果这个大的边界成立，也就是能承载的话，那你就要去给社区持续的去merge，那你就要去主动的解决这个冲突，最好的方式就把基础框架的东西贡献给社区，否则会渐行渐远。那如果你的业务已经用这个框架无法支持了，那就开启一个你自己的框架，没有更好的解法。那最笨的解法就是你后面让AI去持续学习社区的新代码，并且merge到你的代码仓库里面，那这里面也有成本，AI也会犯错。那合并之后是否会变成四不像？

所以两个边界，一个是大边界，一个是小边界。大边界是要持续地去衡量社区的代码是否可以满足你们的业务需求。它是一个前提，它也决定了你后续在决策上是否要继续跟社区去走同一条路。第二个边界是在第一个边界的基础上，也就是说，你已经决定了要继续跟社区走在一块，那就是要定义模块的边界，怎么在社区的代码的框架基础之上，将你的独有的业务逻辑模块化插到社区代码里面。

让AI合并，说清楚本地的什么功能是需要的就行。或者让AI查一遍，把冲突列出来人工看一看

把所有的需求规划好，让ai再合并的时候是实现就行

古法编程真的有逐行 review ?

vibe coding 也好 古法也好 最终服务的是业务结果

做好测试 大于review