本篇是一篇入门技术教程。里面会碰到一些技术名词，老金也不是技术出身，知道刚开始读这些东西，难免觉得有点远。

可接触得多了，慢慢弄懂一个名词是什么意思、能解决什么问题，再用AI时，就更容易把需求说具体。有时候，多知道一种办法，就会想到原来这件事也能让AI帮忙，用起来也会更顺手。

所以，希望你能耐心看完，不用一遍记住所有东西。今天就从Git这个词开始，看看我们让AI反复改代码时，它能帮上什么忙。

Git是干什么的，为什么写代码要用它

假设你和同事一起改一个网站，同一份文件里，你改了页面标题，他改了登录按钮。两个人都保存了一份，最后该用谁的？如果直接用一份覆盖另一份，另一人的修改就可能丢掉。

Git就是用来管理这类改动的工具。你可以把一批改动交给Git，保存成一个能回查的版本，这叫提交。Git会记录这次提交改了哪里，比较两个版本的差别，也能帮助你把两个人的改动合在一起。如果双方改到了同一处，没法自动合并，就把冲突标出来，留给人处理。发现这次改坏了，还可以查以前的版本，撤销相应改动。

这些工作合起来叫版本控制，装着项目文件和修改历史的地方，叫代码仓库。它不负责判断登录按钮好不好用，那要靠另外的检查和测试。

Git和GitHub也不是同一个东西。Git是版本控制工具，GitHub则是可以存放Git仓库、让团队协作的网站。不用GitHub，也能用Git。

对一个项目来说，每个人、每个AI都写出自己的那份代码以后，还得把合适的改动汇总进团队共同使用的版本，这一步叫合并。

AI写快了，后面却越来越忙

做Claude的Anthropic，每天就在处理大量这样的合并。只是AI写代码越来越快，保存、分发和检查代码的工作，开始跟不上了。

代码写出来，只是做成一个软件的开始。他们最近花了5个月，让7个人重做了一套内部工具，把管理内部代码的Git换掉了，解决的就是代码写完以后，大家还在等什么。

今年5月，Anthropic每天要把约2500次代码改动合进仓库，到了9月，已经超过3万。这里说的是代码变更的次数，不是代码行数，一次改动可能涉及不止一个文件。

官方统计图里，两种颜色对应他们先后使用的两套改动审查流程，黑线是7日平均。到9月9日，单日已经合并了30,401次。

但写完代码，不等于网站和软件马上就能用。自动化任务得先拿到要检查的那份代码，再把它构建成能运行的程序，接着跑测试，看看有没有把原来的功能弄坏。这套自动构建和测试的流程，通常叫CI。

Claude越来越能写，等代码下载、等构建、等测试的时间却没有跟着消失。测试也开始跟不上了，一轮还没跑完，几百甚至几千个新改动可能已经合进仓库。即使测试通过，也只能说明这次测试的那个版本通过了检查，不能替后来加进来的代码作保证。

写得更快以后，原来不太起眼的等待，也开始变贵了。

Anthropic把许多项目放在一个大仓库里统一管理，这种做法叫单体仓库。这个仓库主分支，也就是团队汇总改动的那条主线，历史接近100GB，一份供任务使用的代码副本，压缩后还超过25GB。

仓库大，取一次代码就费事，更麻烦的是反复取。他们的自动构建和测试流程，每天大约要准备代码2500万次，还没算开发者、AI任务和研究任务使用的那些副本。

一个任务多等几分钟似乎没什么，同样的动作一天重复上千万次，就会占掉大量机器资源，而且这些资源还没有用来测试代码或做研究，只是在准备开工。

他们没有上来就推倒Git，而是先想办法少下载一点，比如只取最近的历史、只下载需要的目录，再多放一些供大家取用的仓库副本，这些副本叫镜像。他们还提前保存仓库某一时刻的状态，也就是快照，让新任务不用每次都从头准备。

下面的旧架构图里，一条路径负责让镜像跟上最新改动，另一条路径负责生成快照，交给后面的任务使用。高峰时，Anthropic运行过数百个Git镜像。

这些办法确实争取了时间，但改动合并得越来越快，刚做好的快照很快又落后了，镜像也得不断同步。少下载一些数据，又会让查历史、查某一行是谁改的这些操作更难维护。

于是他们开始考虑，能不能换一种分工，让每个任务少做一些重复的准备？

换成Scion，具体少做了什么

Anthropic做出了Scion，一套专门服务内部大代码库的版本控制系统。它接替Git，管理谁改了什么、改动怎样合并，以及以后怎么查回这些记录。他们还做了配套的Antique，让工程师查看和审查改动，再加上代码搜索、权限管理等系统，7个人用5个月完成了开发和迁移。

Git有个很重要的优点：拿到相应数据以后，开发者即使断网，也可以在自己的电脑上查历史、比较版本、保存改动。Anthropic的大部分使用者却是一直在线的AI和自动化任务，工作时本来就离不开服务器，改完也要汇总到团队共同使用的版本里。

Scion便把更多工作放到服务器上，比如查历史、保存新版本和合并代码，任务所在的机器只保留要用的数据，需要哪个目录，就取哪个目录，需要哪个文件，再取那个文件。

有些任务甚至不用下载文件。比如，一个自动检查任务只想知道两个版本改了哪里，直接向服务器询问就够了，不必为了回答这个问题，先在本地准备一份仓库。

Scion保存一次改动时，也会把改了哪些文件和文件的具体内容分开管理。这样，创建这份变更记录的开销，主要取决于这次改了多少，而不是整个仓库有多大。

这份记录叫变更集，里面记着谁改了什么，并指向单独保存的文件内容。目录结构则由服务器另外推导，不必把所有细节都塞进同一份记录里。

真需要文件的任务，则尽量从近处拿。用过的文件可以暂存起来，下次直接复用，这叫缓存。Scion先找同一台机器上的缓存，没有再找同一区域的缓存，仍然没有，才向保存权威数据的服务器请求。

下面的官方架构图中，scion-daemon和scion-cache就是这两层缓存，橙色箭头表示请求往哪一层发。许多任务要用同一个文件时，就不必每次都让最上游的服务器重新提供一遍。

他们还限制了各层之间的访问方式，避免某个区域出问题后，所有请求一股脑涌向上游，把其他区域也拖垮。

按Anthropic披露的内部数据，Scion这套基础设施需要的处理器和内存资源，降到了原Git镜像基础设施的约1/200，自动构建和测试系统也因此释放了25%的处理器容量。

这不等于换个工具，电脑就能快200倍。他们省下的是这类巨大仓库、大量重复任务中的基础设施开销。落到AI任务上，一个很直观的变化是，为新任务准备独立代码工作目录，中位耗时从7.1分钟降到了5.1秒。

Claude没有因为换了版本控制系统变聪明，它是终于不用等那么久了。

Claude负责写，工程师还要做什么

Scion本身也是用Claude做的，模型既带来了新的压力，也帮团队解决了问题。

下面统计的是Scion和Antique这两个系统自身的开发，从1月到9月累计合并了12,257次变更。它和开头全仓库一天3万多次的统计范围不同，反映的是这两套工具开发中的改动量。

团队年初手写过一版程序，用来把Git里的数据导入Scion。后来拿到Claude Mythos Preview的早期内部版本，就让它整体重写了一遍。官方给出的结果是，内存消耗降到原来的1/20，速度达到原来的4倍，而且关于导入顺序、数据结构的要求也保住了。

但模型写得好，不代表每次都会选对做法。迁移过程中，有个任务要查某次改动是什么时候合入主分支的，智能体选择从提交日志里一条条往下找。

这么写未必查不出答案，可记录越多，查得越慢。团队已经有代码审查工具，直接问它就行，没必要重新翻一遍历史。工程师得拦住这种做法，不能因为代码跑通了，就接受这条不合适的路线。

还有一次，负责挑错的智能体过度怀疑另一个内部服务不可靠，Claude便加了过量的校验。单独看每一处，都像是在补上保护，放到整个系统里，却增加了不必要的复杂度，以后维护的人还得继续付出时间。

所以，这7个人仍然审查系统的每个变更请求，只是更多在看改动的意图，而不是逐行阅读：这个问题为什么要这么解决，有没有现成的办法，会不会破坏其他功能依赖的条件。

AI能把一种做法实现得很完整，但它未必知道，这种做法从一开始就不该选。

官方给出的耗时对比里，每次变更请求花在版本管理上的总时间，中位数从34分钟降到了3.7分钟。不过各项操作的变化并不一样，有的只快一点，有的能省掉几分钟，优化什么，得看任务实际把时间花在哪里。

仓库快了，测试的问题还在。如果为了等一轮检查完成，就锁住整个仓库，不让新的改动合入，在这样的数量下就很难维持。Anthropic没能有效沿用这种全局锁的办法，因此加大了合并后、上线前的自动化测试投入。

合进来的代码仍可能互相冲突，他们认为Claude能很快处理这些冲突，但这不意味着可以少做测试。什么时候检查、发现问题后怎么阻止上线、怎么退回之前的版本，仍然要安排好。

普通人用AI做项目，要学的是哪一部分

Anthropic自己说得很明确，Scion不适合作为Git的通用替代品。对绝大多数仓库，Git的设计仍然合适。他们遇到的是超大的仓库，加上大量AI持续写代码的特殊情况。

这也不是下载一个工具、换条命令就能完成的事，代码审查、搜索、自动测试都得跟着改。Anthropic分享的是自己的工程经验，没有交付一个普通团队拿来就能直接替换Git的通用产品。

他们在内部使用Claude时，愿意承担的模型用量也远超多数公司，因为同时还在测试模型能力。因此，7个人、5个月，不能直接拿来估算我们做同样事情的成本。

对用AI做网站、小工具的人来说，更有用的是分清两件事：AI已经把代码写出来了，和这个功能已经能放心使用了，中间还有一段工作。

比如让AI给网站加一个登录功能，不能只看页面上多了一个按钮，还得检查正常登录、输错密码、退出后再打开这些情况。这个例子不需要Scion那样的系统，但一样需要保留改动记录，知道这次改了什么，出了问题能退回去。

如果时间主要花在反复解释需求、修测试发现的问题上，就先解决这些问题。如果总是几份代码改来改去、分不清哪份才对，就先把版本管理用起来。仓库并没有让你等太久，就没必要为了追上别人的架构，把整个流程重做一遍。

该改的是拖慢自己工作的那一环，不是别人刚换掉的那个工具。

写在最后

Anthropic这次做成了Scion，可原文里那些被工程师拦下来的方案，同样值得记住。

不管是从提交日志里逐条查找，还是一层层地加校验，Claude都能很快写出来，再补上测试，让不合适的方案也有了成品的样子。

一条路线需要花很多人力时，团队通常得先讨论值不值得做。现在实现变便宜了，这道讨论反而容易被跳过去，可等代码都写好了，又容易觉得已经做了这么多，全部删掉太可惜。

所以，工程师还得能对一份已经写好的代码说不，哪怕它看起来完整，甚至已经跑通了。

当写出代码越来越容易，让一段本来就不该存在的代码消失，也许会成为更难下的决定。

谢谢你读我的文章。

如果觉得不错，随手点个赞、在看、转发三连吧🙂