大家好，这里是最佳拍档，我是大飞。我们先来看一组数字：今年5月，Anthropic平均每天往主仓库合并2500次代码变更；到了9月，变成了每天超过3万次。4个月涨了10倍以上，而且他们明确说这个增速短期内不会放缓。因为想合并代码的需求几乎没有上限，每打通一个瓶颈，产出的代码量就会再涨一截。

10月13日，Anthropic在官方工程博客发了一篇文章，讲他们怎么用5个月时间、靠一个7人的团队，从零做了一套内部版本控制系统叫Scion，把整个单体仓库从Git迁了过去。同期还上线了代码审查工具Antique、代码搜索和一套源码权限管理系统等配套工具。

这事在开发者圈子里很快传开，甚至有人喊出了“RIP Git”。Git统治程序员的开发流程将近20年，现在一家AI公司用自己模型写出来的系统把它换掉了。难道Git真的不行了吗？普通开发者要不要慌呢？今天我们就来聊聊这件事，答案自然会清楚。

我们先来说背景。在Anthropic，写代码本身早不是瓶颈了。Claude可以自主迭代研究闭环、微调复杂程序、从零搭起新服务，瓶颈挪到了别处。比如版本控制、构建系统、CI流水线这些全是按人类开发规模设计的基础设施，他们的负载特殊已经到了什么程度呢？

仅主分支的历史数据就接近100GB，压缩后的工作副本超过25GB。光CI系统每天就要做大约2500万次代码检出，这还没算开发环境、Agent沙箱和研究任务。如果每次都直接从Git拉数据，一天的传输量会超过600PB。

这种量级的流量靠原来的Git架构硬扛显然是扛不住的。Git其实给过一些局部的处理手段，比如浅克隆、稀疏检出、Promisor Remote。业界对付大单体仓库也有一套常规打法，比如搭内部镜像、把仓库快照存进对象存储等等。

这些Anthropic全用过，负载最高的时候同时跑着几百台Git镜像服务器。办法确实续了命，但是越来越难维护：两次快照刷新之间，快照和主分支最新版的差距越拉越大；部分克隆的仓库要想正常跑diff、blame这种依赖历史的操作，也得花越来越多精力去伺候。

到了这一步，他们开始回头审视自己的用法，发现了一个关键的错位：和大多数公司一样，Anthropic实际一直把Git当集中式系统来用，所有工作围着一份权威仓库转。但Git的底色是去中心化，它假设每个客户端都可能离线干活，所以每次克隆都带一份完整仓库。

问题在于Anthropic的客户端几乎全是Agent和自动化任务，永远在线。Git为分布式离线场景准备的那些优点，仓库一大全变成了扩展的障碍。于是他们问自己：如果从一开始就按Agent始终在线这个前提来设计版本控制，它该长什么样？这就是Scion的起点。

超大单体仓库的版本控制有先例，Google的Piper和Meta的Sapling都踩过很多坑。Scion的设计也参考了这些经验，文章里给了几条设计原则：首先，客户端始终在线。需要什么数据就从服务器现取；客户端和服务端职责不对称。

查历史、查blame、建提交、合并、变基这些全都要在服务端完成；客户端只维护一个有上限的本地对象缓存，把文件摆上磁盘、盯住文件系统的变化，同时给人一套顺手的操作入口。它自己几乎做不了什么计算，换来的是本地数据量会小得多。

其次，版本控制服务要完整才能托起新的应用。Git时代CI任务想查这行代码最后是谁改的，要么自己养一份本地仓库，要么指望托管平台的API刚好能回答。Scion把客户端用到的查询能力全开放成了API，很多任务根本不需要本地仓库。

他们内部的自动化二分定位和回滚流水线就是靠这个跑的，没有这种便宜和可编程的访问这些工具在现在的规模下根本立不住。第三、所有组件必须能够横向扩展：说回那几百台Git镜像，仓库一大过单机磁盘或内存就扩不动了。

于是Scion把数据进行分布式存储，每个组件独立扩展，整个系统里没有任何一份完整实体化的仓库（服务端也没有）。既然Git那种packfile压缩打包的机制不存在了，仓库维护这桩差事也就没了。

第四，提交必须够轻、增量、无锁：Git是本地提交再push，而Scion的提交、变基、合并全发生在服务端，没有push这一步。这样的前提是每个操作都得快：创建提交的开销要跟这次变更的大小成正比，不能跟整个仓库的规模成正比。

不然服务器早晚会跟不上；而分支、标签这类指向提交的引用能少用就少用，因为如果要所有服务器一致维护全局状态扩展迟早是瓶颈。最后，工作副本是可选的、默认稀疏：仓库这么大CI每天检出几千万次能不走检出就不走。

CI任务想看某次提交和合并基点之间的差异直接问服务端要，不少写入任务也可以完全走API。真要落盘就用稀疏检出和虚拟化检出：读到哪个文件才拉哪个。好了，原则讲完了现在来看看它怎么落地。

Scion的基本工作单元叫变更集（Changeset），是预写日志里的一条记录。它保存了Git提交里的大部分信息，但是组织方式不同：Git提交存的是指向整棵目录树的指针；变更集存的是相对第一个父提交发生变化的文件清单，加上指向对象存储里压缩文件内容的内容寻址指针。

变更集在服务端创建，创建完全局立即可见。这个结构让接收变更的吞吐量非常高：没有packfile要收、没有锁、没有跨服务器协调，也没有引用要挪。Scion技术上还支持引用，但创建和获取提交都不碰它；挪一个引用只是在Spanner数据库单行数据上做一次Compare-and-Swap操作而已，跟创建变更集是分开的两码事。

由于变更集只记录变化本身所以光靠它是没法快速回答“这行最后谁改的”、“这个文件经历过哪些提交这类问题的”。所以Scion基于变更集再建了一批数据结构：有专门查blame和路径历史的，有给提交图查询加速的跳表。

他们把不直接属于变更集的数据统称为派生数据（Derived Data），全部走一套通用机制来算。每种派生数据都是递归定义，从父变更集的对应数据推出来：想让某个操作更快加一种新的派生数据就行；每种数据可以选择提前算还是用到再算，不生成没人用的东西。

客户端也看不到内部结构服务端随便优化客户端不用动；系统长大过程中他们加过很多次新类型，比如做文件复制检测、按路径搜索文件的新索引。架构上：一小队Scion服务器对外提供全部版本控制API，所有数据内容寻址、写完不变。

任何服务器都能放心缓存不用互相确认；服务端本质就是一群大缓存，顺便按需算派生数据、写回Spanner。扩展起来也很容易协调成本很低：文件获取的协议跟Git差别很大，Scion的客户端叫scn。

拉数据时不告诉服务端自己已有什么而是从根目录树开始查本地缺哪些目录树对象，递归请求；再按照同样的方式拉文件内容。每个请求都指向一个明确的、永远不变的对象，任何一层缓存都能直接答；没有好几个G的packfile大响应。

效率高还能断点续传，稀疏检出和虚拟化检出也用不着特殊支持：客户端不请求不需要的目录树就行。部署分为三层：客户端通过Socket跟本机的scion-daemon通信，daemon代替了整台计算节点来管理对象。

同一节点上的任务大量复用相同的对象统一管理最为划算；daemon启动时会加载一份定期刷新的快照，之后只跟本区域的缓存服务器scion-cache说话。scion-cache直接从内存按daemon要落盘的格式流式发对象，不现场算差量也不做压缩。

缓存缺了对象才轮到权威的scion-server，由它从Spanner或云存储读取。三层用同一套RPC接口客户端不需要知道缓存拓扑，理论上哪层都能互相通；但是他们严格限定了层级访问关系为的是隔离故障。

免得某个区域的缓存挂了请求直接冲垮上游把全系统拖下水：效果数据可以记一下，每层缓存命中率超过99%，不需要长期状态想扩就扩。跟之前的Git镜像基础设施相比Scion在CPU和内存上的占用缩小了200倍。

CI和研究任务的检出速度提了大约2个数量级，从几分钟缩到几秒钟；整个集群空出大量算力光CI就省出25%的CPU容量。说完技术，再说开发过程这部分可能更有意思：他们动工做Scion的时候正赶上Claude Mythos Preview和Claude Tag在内部开放。

这两个模型一边放大了对于Scion的需求，一边显著加快开发速度：文章里有个很有代表性的例子。今年早些时候团队基本手写了第一版Git到Scion的数据导入流水线原型，当时觉得已经挺好了。

后来拿到Claude Mythos Preview的早期内部版本他们让模型重写整个程序，没给任何额外的指示。而Claude交回来的版本内存消耗降低了20倍、运行速度快了4倍；原程序里关于导入顺序和数据结构的所有隐含约束一条没丢。

整个项目7个人、5个月做完了Scion和Antique，外加代码搜索等6个相关系统还完成了全面迁移。这一切都发生在每日合并量涨10倍的期间，搁以前开发部署这样一套的版本控制系统要更多的工程师花好几年时间迭代迁移。

所以他们的判断是：小团队快速开发大型系统以后会越来越常见，工程师的角色变化值得拿出来单独说一下。参与项目的工程师现在都承认单论写代码Claude已经超过自己，但是工程师没有变廉价只是换了位置。

他们提供的是对系统间整体关系的理解是对设计取舍的判断，知道要解决什么问题、和要撑多大的规模。很多时候工程师的工作就是对Claude说不：为什么要说不呢？因为Agent有时会为了满足某个局部代码模式去违反系统的核心约束。

迁移过程里这种情况特别多：比如有几个系统想查某次变更什么时候合进的主分支，Claude给的办法是线性扫提交日志；而正确做法是直接查代码审查工具。Anthropic还大量使用了对抗性代码审查，这招在很多方面有效但是容易盯死局部问题把系统改得过度复杂。

有一次审查对另一个内部服务过于不放心，Claude就堆了一大堆额外校验。现在团队成员仍然审查每一个变更请求但是主要看修改意图不再逐行读代码了：质量这块，因为Claude写码的速度远超人类于是Scion成了他们碰过的测试最充分、防护最完善的代码库之一。

工期这么紧，他们还是把历史上遇到过的复杂基础设施交互和版本控制操作全做成了可隔离、可重复运行的模拟测试，还上了模糊测试和完善的限流。Claude还能随手挖出重要的优化点：有次它发现一个祖先关系查询算法漏用了一个已有索引。

这种问题如果交给专家分析调优就得好几天甚至几周，而Claude仅花了一天做完第二天接着找下一个问题去了。除此以外安全合规从设计第一天就在考虑：Scion支持丰富的仓库访问控制，权限可以细化到单个目录。

保护最敏感的代码又不丢掉单体仓库的好处；配套的审查工具还能表达复杂的语义化审批约束，比如区分只改注释的简单变更和涉及敏感逻辑的修改让人类审查者把精力集中在影响最大的变更上。

运维上有个很新鲜的做法：团队重度使用了Claude Tag来监控各个组件，还专门建了一批Slack频道每个频道放一个Claude实例死死盯住某一个组件的健康状况。他们管这些Claude叫超级粉丝（Superfans）：有盯scion-daemon的、有盯scion-cache的、有盯Antique合并队列的。

这些实例能访问遥测数据和日志，像一个经验丰富又闲得发慌的工程师一样不停的刷图表找异常。传统告警当然保留着但是超级粉丝能逮到一些很细微、从没出现过的问题，相比之下传统告警就显得有点钝了。

这个项目还逼着他们重新检视了不少按人类规模设计的流程：最典型的是合并队列（Merge Queue）。Agent规模下一次测试还在跑可能已经有几百上千次变更合进仓库，业界标配的全局仓库锁根本没法有效复现。

他们的做法是放弃全局排队把重心挪到合并后和部署前的自动化测试；代价是并发变更会打架但是Claude修冲突的速度比人类发现冲突在哪儿还快。最后我们来说说边界这部分要讲清楚免得大家误解：Anthropic明说了Scion绝不是Git的通用替代品。

这套设计只适用于真正庞大的单体仓库：要么数万工程师共用，要么大量Agent持续编写代码。而且Anthropic有个别人没有的条件他们为内部任务烧Token的能力远超普通公司愿意承担的水平。

这样既满足自身开发需求也是在测试Claude的能力：把Scion做成通用产品也不现实，它和Git差异太大。别人要迁就得迁整个开发生命周期还得配套代码审查、代码搜索和CI；而Anthropic内部的这些系统是高度定制的，外人很难直接用。

他们也担心真做一个讨好所有人的公开版本最后反而没什么用：但他们的判断是未来6到12个月这类问题会越来越普遍。与其让每家用Git的公司都独自撞墙不如把思路公开：他们给的方向是Git服务端不必和客户端用同一种工作方式。

新的服务器架构能带来明显的扩展性提升；托管平台可以像Scion一样提供完整的服务端RPC接口甚至在不同平台之间标准化。现有的数据协商协议不是非保持原样不可，浅克隆、稀疏检出这些功能也有改进空间。

文章结尾Anthropic的态度很克制：Git社区花了近20年把这套平台扩到服务数百万开发者，他们自己的贡献其实很窄只是提前看到了AI编程和这些系统相撞的样子。希望跟GitHub、GitLab和开源社区一起应对：回头看整件事，“Git被取代”更像个噱头。

真正值得记住的是一个更朴素的信号：当AI写代码的速度开始指数级上升，那些围着人类节奏设计的工具链会一个接一个顶到天花板。今天是版本控制明天可能是CI后天是代码审查的每一个默认假设。

Anthropic这次虽然是把自己撞墙的过程完整公开了但是对于其他团队来说这堵墙大概率也会在路上。感谢收看，我们下期再见。