北京
一个智能体提出修正，另一个补上测试，第三个调整 API 调用。代码来得很快，但总得有人确认这些改动放在一起能不能跑、能不能交付。
这组数字能说明量级。GitHub 在 Octoverse 2025 报告中给出的数据是：平均每月 4320 万个合并的拉取请求，同比增长 23%。平台上的开发者数量也在增加。这些数字反映的是活跃度上升，并没有单独拆出与 AI 相关的部分。
Anthropic 的尺度是另一种量级：这家公司表示，从 2026 年 5 月到 9 月，每天整合的变更从约 2500 次增加到 3 万次以上。其在 2026 年 10 月发布的关于 Scion 的复盘，描述了它如何重新设计版本管理来消化这个体量。
这个内部案例不代表所有团队的日常，但它指向一个问题：当代码提案到达的速度超过团队处理的速度，会发生什么？
版本管理不是从 Git 开始的
源码控制（source control）用来追踪文件改动、找回历史版本、合并多方贡献。它比 Git 早得多：SCCS、RCS、CVS、Subversion 都属于这条脉络，协作模式也一路演化。
Git 由 Linus Torvalds 在 2005 年创建，设计目标是让开发者以分布式方式工作。每个本地仓库都能保存完整历史，很多操作不需要连服务器。
这套模型支持多人并行：各自准备改动，再合到一起。智能体用的也是这些能力。但智能体一多，某些成本就变得显眼——准备环境、评审提案、调和两处改动，每一样都要花时间。
四个摩擦点
提案在排队。智能体一上午提出二十个修正，评审者和持续集成（CI）流水线只能处理其中几个，剩下的就等着。评审和测试决定了整合的节奏。改动产出变多了，交付的改动却不一定变多。要看懂这个落差，得把等评审、等测试结果的时间也算进去，而不只是写代码的时间。
改动会互相撞车。一个智能体给 API 加参数，另一个同时在重构同一个 API。两份提案单独跑都没问题，合到一起就可能不兼容。有些冲突在合并文件时暴露，另一些涉及程序行为，在这一步根本看不出来。文本上没有冲突的合并，不等于不用测试合并后的结果。分开跑通的测试，也不足以验证整体。
环境准备很费时间。十个临时智能体各自克隆一个 monorepo（把多个项目或服务放在一起的仓库），而每个智能体只需要改某个服务里的几行。下载和准备文件的成本，可能比修正本身还高。少拉一些文件是条路子，前提是编译和测试所需的依赖还得留着。启动快，但第一次构建又要下载一堆缺的东西，那就没意义了。
还得能找回“验证过的是什么”。一个排序算法经过多轮自动修正后，评审者要重新确认预期行为，还要核对测试对应的是不是最新提案。追踪一次修正的身份，有助于理解它的来路。要决定是否整合，还得知道究竟哪个版本被测试过。一次新的修订或一次 rebase，都可能改掉此前验证所针对的代码。验证必须和它实际测试的那个版本绑定在一起。
和 AI 之前一样，代码产出更快，并不保证交付更快——前提是开发链路没有跟着变。
三类回应
“Git 替代品”这个说法，把并不解决同一个问题的工具装进了一个筐。这些路子可以互补：一个让 rebase 更顺手的工具，不一定能缩短仓库下载时间；一个虚拟工作副本可以加快文件准备，但它不会去验证两个 API 改动是否兼容。
含大量贴图、3D 模型或音频文件的项目还有另一重约束：有些文件很难合并。Perforce P4 和 Unity Version Control 这类工具提供了适配这类资源的工作流。
当智能体产出更多代码，评审、测试和整合就可能成为最慢的环节。第一步是先测出到底哪一环在拖团队的后腿。这个问题问清楚之后，工具才更容易比较。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
