Anthropic 一天合三万条，你一天几条
Hello，我是飞飞。
先问你件事：你自己那个仓库，现在平均一天提交几条？我猜个位数，不少人可能连一条都不到。这个数今天变得重要了，因为有人刚给一条线刻上了刻度。
今天中文圈到处在传，说 Anthropic 不用 git 了，版本控制整个换成了自己造的。我把官方原文逐字读了一遍，假的。他们迁的是自己那一个仓库，原文还专门留了一整段劝别人别学。而真事比传闻有意思：他们第一次给「什么量级才配动这个底座」这条线，配上了真实数字。
我把那条线拿来量了一遍自己。差着四个数量级。
到处在传的那句话
传的版本是这样：Anthropic 不用 git 了，自研了一套版本控制，把 git 整个换掉。
我去读了那篇原文。原话是 fully migrated our monorepo from git in five months，翻过来是：五个月里，把我们那个 monorepo 完整迁出了 git。
monorepo 说人话，就是全公司的代码装在同一个仓库里。多数团队一个项目一个仓库、一个人手上几个仓库。monorepo 反过来，全公司共用那一个。所以他们动的只是自己那一个仓库。
更硬的反证在他们自己的收尾段，原文写了一句：Scion is by no means a suitable replacement for git for general use. 意思是，Scion 绝不适合拿去当 git 的通用替代品。这是 Anthropic 自己写的。
那这条错为什么传得开？因为「大厂弃用 git」这个标题太顺了，顺到没人去核后半句。
他们到底迁了什么
Scion 是从存储层重写的完整版本控制系统。它有自己的数据单元、自己的客户端、自己的服务端和协议。
他们自己特意提了一嘴，Scion 里没有 git 那种 packfile。说人话：git 每攒一批改动就压成一个包存起来，包一多就得定期拆开重装，仓库越大这道工序越贵。Scion 干脆取消了打包，所以它压根没有「仓库维护」这一说。底下那层是被整个换掉的，它没挂在 git 上。
为什么要动？他们没写某一步崩了，写的是一整套已经撑不住的日常。
他们的 main 分支，光历史就快 100 GB。CI 每天要跑大约 2,500 万次 checkout，平均每秒接近三百次，每一次都可能拖走整个仓库的一份拷贝。全量拉的话，一天要搬 600 PB 出去。
峰值的时候他们跑着几百个内部 git 镜像。先到顶的是镜像的磁盘和内存。
真正的病根在他们一句话里：nearly all of our clients were agents and jobs that are online by definition. 他们一直拿 git 当一个集中式系统用，留一份权威副本。可这个系统里的「客户端」，几乎全是永远在线的 agent 和任务。让 git 在分布式、离线场景里称王的那些设计，在这个用法下全变成了负担。
那篇里有句话我印象很深：Very often, we found that the role of the engineers was to tell Claude 'no.' 很多时候，工程师的活变成了去对 Claude 说不。
这条路也有人走过。Google 的 Piper、Meta 的 Sapling 都是自研的版本控制，Anthropic 在那篇里也点了名。之前的那些，基本只留下一个名字。
名字这事，10 月 14 号还闹过一场。Meta 那套 Mononoke 的建造者发文说 Scion 大量借鉴，用的词是「接近于剽窃」，可 Anthropic 那篇只列了 Sapling，一个字没提 Mononoke。第二天，Anthropic 把 Mononoke 补进了脚注。那位建造者后来补的一句，我觉得比指控本身更值得记：问题在署名，不在照抄。
官方自己劝你别换
最值钱的是这两句。门槛那句是：The concepts we've outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code.
翻过来：这套东西只对真正巨大的 monorepo 才成立，前提是你要么有几万个工程师，要么有一大群 agent 在那拼命写代码。
另一句更直白：Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend. 我们内部花 token 的能力，远超任何一家公司现实中愿意花的那个数。
Anthropic 等于亲手给「什么时候才该动这个底座」画了一条线，还顺手报出了线上的刻度。
一个七人团队，五个月搬完，同期还做了半打相关系统。做完之后他们花了不小篇幅劝你别学，还给了替代方案。把 Scion 里那几招搬回 git 就行。用他们的话说，git 的服务端没必要跟客户端一个玩法。
我 6 月那句还成立吗
6 月 23 号，我写过一篇，主角是一个开源项目叫 Oak，它想给 agent 换掉 git。
同一篇里我说了句挺满的话：不换，至少现在不会。理由两条。一条是迁移成本。我这条写作流水线挂着十几个 skill，配图的、查重的、发布的，每一个都是顺着 git 那套规矩磨出来的。另一条是 Oak 当时还是 v0.99.0 的公测版。我的真实仓库不拿去给一个 0.99 的版本控制系统当小白鼠。
我还留过一个伏笔，原话是：等它过了 1.0、等有人拿真仓库跑出独立的实测数据，我大概会先拿它当草稿层试一试。
今天来的，是后半句。真仓库的实测数据来了。Anthropic 把自己那个真仓库亮了出来，带着花了多久、几个人、迁移前后的数。一份完整的账。没来的那一半是前半句：Scion 不对外，我装不上，Oak 也还是没到 1.0。
所以准确说，伏笔兑现了一半：真仓库的数据来了，能给我用的那个选项没来。
那两句理由今天还成立吗？成立。我的十几个 skill 还长在 git 上，Oak 也还是那个版本号。
但理由底下还压着一条，我当年没写出来。因为我当时不知道它画在哪。Anthropic 这篇，正好把它补上了。
我离那条线还差多远
要跟它比，我得先把自己那个数重新数一遍。
今天跑了一趟 git log，窗口卡在 6 月 24 号到现在。这个仓库 2022 年 8 月建的，到今天一共 636 条提交。
光是 6 月 24 号之后的 114 天里，就有 307 条。除下来，一天 2.7 条。
上周三我数的时候是 607 条。九天才多了 29 条，日均那个数几乎没动。
再把 Anthropic 那边摆过来。5 月，他们那个仓库平均每天合并大约 2,500 条改动；到 9 月，一天超过 30,000 条。
9 月 9 号那天是个峰值，30,401 条。这个精确数出自第三方重绘的那张图。官方自己用的措辞是「涨了十倍以上」。
这里有个坑我得说清。Simon Willison 重绘官方那张图的时候发现，每根柱子其实是两层叠的。蓝色是常规的合入请求，橙色那一种叫 antique change request，说白了是另一种改动单位。名字不用记，要紧的是它跟蓝色不是一回事。
橙色 5 月底才冒出来，7 月中基本把 PR 全替掉了。所以 5 月的 2,500 和 9 月的 30,000 还不是同一种单位。中间隔着一次计量方式的更换。
我的 2.7，对上它的 2,500，大约九百倍。对上 30,000，一万一千倍上下，差不多四个数量级。
这个数我也得把丑话说完：我这边量的单位，是「提交到我自己那个单作者仓库」；它那边量的单位，是「合并进整个公司 monorepo 的改动」。这是两种东西，不能相减，也写不出「我差了 X 倍」这种精确话。但四个数量级这个量级判断，换成什么口径都站得住。
换个好懂的算法。9 月 9 号那一天他们合并进去的量，差不多是我这个仓库从 2022 年建仓到今天全部提交的 48 倍。反过来说，我四年多攒下的这些，按它那天的速度，大约半个小时就能合并完。
只有当写代码的量到了那个份上，连「读」都得整个重做一遍。Claude 开发者博客那篇开头就问了一句 Does anyone read code anymore?，还有人读代码吗。他们的回答是：团队里没人再在脑子里存着一份完整的代码地图，想知道哪一块，就让 Claude 现写一份讲解。这跟我上周问过的是同一个问题，官方比我干脆得多。
这就是我当年漏掉的那一条。6 月的我，手上只有一杆「贵不贵」的秤；今天多了一把带刻度的尺子。
该不该动这个底座，不在你觉得它多疼，在你手上有多少量。而我离那条线，大约差四个数量级。
我 6 月留的那个伏笔，前半句还没到。Oak 还没过 1.0，Scion 也不对外。刻度有了，可线的那一边现在还站不上人。
回到最开头那个问题：你自己那个仓库，一天几条？数完你要是愿意，来对个数。我挺想知道这条门槛在别人那儿长什么样。