Anthropic 十月中旬在工程博客上发了一篇挺少见的文章：他们把整个公司的主仓库从 Git 迁到了自研的版本控制系统 Scion，五个月完成迁移。起因不是 Git 有什么致命缺陷，而是 Claude 写代码的速度太快，把按人类节奏设计的开发基础设施压垮了。这故事听起来离站长很远，但里面有几个关于版本管理的判断，值得做站的人琢磨。
图片由 AI 生成
先看数字：瓶颈是怎么被撑破的
Anthropic 公布的几个数字很说明问题。2026 年 5 月，他们日均合并约 2500 个代码改动，到 9 月已经超过 3 万个。主分支的历史接近 100GB，压缩后的完整工作副本超过 25GB，每天为 CI 和各种任务执行约 2500 万次代码检出。峰值时期他们跑着几百个 Git 镜像来分担流量，最后连镜像的磁盘和内存都装不下了。
Scion 的解法是放弃 Git 的分布式假设：既然几乎所有客户端都是永远在线的 AI Agent 和 CI 任务，那干脆让提交、合并、变基全部在服务端完成，客户端只维护一个有界缓存和按需拉取的工作副本，检出默认是稀疏或虚拟化的。效果是版本控制基础设施的 CPU 和内存占用降到原来的约两百分之一，CI 检出从分钟级缩到秒级。七个人、五个月，连同代码评审和代码搜索一起重做。
要注意的是，Anthropic 明确说 Scion 不打算开源，也不适合作为 Git 的通用替代——它只对超大单体仓库成立，配套的评审、搜索、CI 都得自己来。普通人用 Git 依然是正确答案，这一点他们自己说得很清楚。
图片由 AI 生成
启发一：版本管理不是 Git 命令，是习惯
多数站长的「版本管理」其实只有 FTP 覆盖上传。改模板、改插件前先拷一份带日期的副本，出问题再覆盖回去，这就是最朴素的版本管理，问题是它只有一档：最新一次备份。Git 的价值不在于命令有多高级，而在于每次改动都有独立记录、能回滚到任何一步、能看清楚「什么时候改的什么」。
落地方案不用复杂：把主题目录、自定义插件、配置文件放进一个 Git 仓库，每完成一个改动提交一次，提交信息写清楚做了什么。远程端可以用私有仓库托管，或者干脆定期推到服务器上的裸仓库。这套东西半天就能搭好，之后每次改版的底气完全不同。
启发二：提交要小，回滚才有意义
Anthropic 那篇文章里有个细节值得注意：他们放弃了合并队列上的全局锁，转而投资合并后和部署前的自动化测试——因为单笔改动足够小，出问题可以被快速发现和修复。这个思路搬到站长这边同样成立：一次提交只做一件事，改一处模板、加一个函数、调一段样式，别攒一个星期的大改动一次性提交。
提交越碎，出问题时定位越准。回滚不是恢复整站备份那种伤筋动骨的操作，而是撤掉某一次改动就能解决。很多站长害怕改代码，根源就在于没有这种「改错了一步就能退回来」的安全感，而 Git 恰好提供的就是这个。
启发三：自动化的价值在瓶颈之后才显现
Anthropic 的处境是产量先涨上去，基础设施跟着崩，然后才不得不重建。站长这边的路径是反过来的：先建好基础设施，等产量（不管是内容更新频率还是代码改动频率）上来时就不会手忙脚乱。具体可以从三件事做起：
- 版本控制：主题和自研代码进 Git，小步提交，远程留备份。
- 自动备份：数据库和文件定时备份，异地存一份，定期演练恢复。
- 改动留痕：每次改版记录改了什么文件、为什么改，和提交记录互相印证。
这三件事单看都不起眼，加在一起就是一套小型团队级的工程习惯。规模上去之前把习惯养好，比规模上去之后被迫补课要轻松得多——毕竟大多数站长的瓶颈不是日合并三万次，而是三个月后想不起来上次改的那行代码在哪。
