# AI 写代码快了，先堵住的却是搬代码的路

> Anthropic 把超大单仓迁到 Scion。值得拆开的不是‘Git 要被淘汰’，而是 Agent 批量开工后，取代码、查历史与准备工作区的成本怎样变成主角。

- 作者：芝士AI吃鱼
- 发布日期：2026-10-14
- 栏目：[AI锐评](https://ai-knowledgepoints.cn/commentary)（观点与分析）
- 主题：AI锐评、AI编程、Git、开发基础设施
- HTML 正文：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-14-scion-code-transport](https://ai-knowledgepoints.cn/blog/commentary-2026-10-14-scion-code-transport)
- Markdown 永久链接：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-14-scion-code-transport/index.html.md](https://ai-knowledgepoints.cn/blog/commentary-2026-10-14-scion-code-transport/index.html.md)
- 原始来源：[Anthropic Scion 工程文章与 Git 官方文档](https://www.anthropic.com/engineering/redesigning-source-control)

引用本文时，请注明作者与 HTML 正文链接。Markdown 版本用于机器阅读，与 HTML 正文共享同一内容来源。

## 正文

想象一家仓库招来一批手脚飞快的装配工。零件刚到，他们就装好了，动作利索得让人舍不得眨眼。

老板兴冲冲地加人，结果门口堵了。每个工人开工前，都要先领一车材料；有的人只是查一下货号，也得跟着排队。车越派越多，工位反而在等。

这时再买一批更快的电动螺丝刀，多少有点安慰自己的意思。

这是个假想场景。读到 Anthropic **2026 年 10 月 13 日发布的 [Scion 工程文章](https://www.anthropic.com/engineering/redesigning-source-control)**，很容易想到这条搬运通道。按其自报，单仓每天合并的改动从 5 月约 2,500 次涨到 9 月超过 30,000 次，公司用五个月把这个 monorepo 从 Git 迁到了自研 Scion。这里数的是合并改动，不是完成的产品功能，也不是程序员人数。

最容易传播的标题，大概是“AI 把 Git 干废了”。

可这会错过真正有意思的地方：当写代码的人变成一群频繁启动的 Agent，原先摊在长时间开发过程里的准备成本，可能突然变成每次开工都要交的费用。

**模型写得快，不会让下载、展开文件和查询历史自动免费。**

## 搬一车，还是取一件

Scion 官方给出的取舍很明确：客户端按服务器持续可达来设计，历史、合并等工作更多放在服务端；查询可以走 API，需要落盘的工作副本则按需、稀疏地准备。它也明确表示，这套方案不适合作为 Git 的通用替代品。[来源：同一篇官方工程说明](https://www.anthropic.com/engineering/redesigning-source-control)

这个方向值得看，倒不是因为“集中式”三个字自带先进光环。

回到仓库，如果一个任务只想知道“这件零件上次是谁改的”，合理的服务可以直接回答；如果另一个任务真要组装，就把它需要的材料送到工位。前者是查询，后者是取货。把两种需求都包装成“先准备一套完整开发环境”，方便的是流程编写者，账单却落在每次任务启动上。

这只是帮助理解的意象：代码对象可以复制、缓存和复用，不像实物搬走就少一件。真正该算的，是传输了哪些字节、准备了多少文件，以及这些操作有没有沿用上一次的结果。

![原创机制示意：只查历史的任务可请求服务端返回答案，需要执行代码的任务仍须取得依赖文件。Git partial clone 控制对象下载，sparse checkout 控制工作树文件，两者不等价；图中不包含性能数值。](https://ai-knowledgepoints.cn/images/articles/scion-commentary/ask-or-fetch.svg)

AI 辅助制作的原创分析图，区分任务需求与数据准备层次；不是 Scion 架构复刻、产品截图或性能测试。

[查看竖版大图](https://ai-knowledgepoints.cn/images/articles/scion-commentary/ask-or-fetch-mobile.svg)

这里也有一个不太讨喜、却必须带上的条件：按需取货，意味着没取到的东西仍在别处。网络中断、权限不够、远端服务繁忙，都会影响后续任务。

完整本地副本的冗余，有时候恰好是离线工作的底气。不能先把这种能力从需求表里删掉，再宣布新方案全面胜出。仓库门口不排队了，工位能不能独立干活，还得重新问一遍。

## Git 也不是只会整车发货

如果读完新闻，脑子里留下“Git 必须把所有东西全下载下来”，那就被一个过分整齐的故事带偏了。

[Git 的 partial clone 文档](https://git-scm.com/docs/partial-clone)说得很清楚：可以先省略不需要的对象，之后按需补取。补取缺失对象需要远端可达；预先取齐所需部分，才可能在相应范围内离线工作。它也把 partial clone 与限制提交历史范围的 shallow clone 区分开来。

另一个容易混淆的是 [sparse checkout](https://git-scm.com/docs/git-sparse-checkout)：它控制工作树里出现哪些受跟踪文件，不等于单靠它就减少了此前下载的全部对象。省传输、少落盘、少取历史，是不同层次的事情，不能看见目录变小，就认为网络流量也按同样比例降了。

所以，Scion 的新闻不该让普通团队连夜把 Git 换掉。更有用的刺激是：看看自己的自动化任务，到底需要一张查询结果、一小块代码，还是确实需要完整的构建输入。

举个合成场景。一个 Agent 只负责判断改动涉及哪个目录，另一个要运行跨包集成测试。前者可能仅靠变更清单就够，后者如果少拿了共享配置或依赖包，节省下来的下载时间就会换成错误结果。这个例子没有对应某家公司的实测数据，目的是说明：不能给所有任务发同一张领料单，也不能凭“看起来只改了这个目录”就认定依赖到此为止。

最让人心疼的浪费，是任务根本没用到那些材料，却在一次又一次为准备它们付钱。

最危险的节省，是材料没发齐，检测却给了一个绿灯。

## 别急着修新仓库，先看看车都运了什么

如果要把这条新闻变成自己的工程判断，我会先拿一条现有流水线，拆开看它的等待：排队、取代码、装依赖、构建、运行测试，各占了多少；冷启动与已经有缓存的运行分开看。这里提出的是诊断办法，本文没有跑过 Scion，也没有测得本站在这些阶段的耗时。

假如瓶颈一直在测试执行，换取代码的方式未必改变总等待。假如准备工作区才是大头，先检查重复下载和不必要的文件展开，可能比继续加 Agent 更值得做。没有这张分账单，“我们也需要一套新版本控制系统”就是把别人的规模当成自己的需求。

还有个很朴素的验收条件：优化后，要继续能说清楚测试对应哪个精确版本、用了什么输入。取回来的文件少了，证据不能跟着少。否则搬运效率看上去提升了，出问题时却连当时装配的是哪一批零件都说不清。

这也解释了为什么我不愿把“每天合并多少次”直接当作生产力。拆小改动可能更易检查，大量无效改动也可能让数字很好看；最终仍要看交付的行为、故障和维护负担。吞吐量描述了通道有多忙，无法独自回答运出去的东西有多值钱。

Scion 让我在意的，是 AI 编程把一个长期躲在背景里的问题推到了前台：我们给机器安排了多少工作，又让它为开工重复准备了多少东西。

装配工跑起来了，值得高兴。下一眼，先看看门口那些车里，装的是这次真要用的零件，还是没人拆过的旧货。

资料核对：2026 年 10 月 14 日。Scion 事件与部署描述来自 Anthropic 10 月 13 日官方文章，属于厂商自报；本文没有独立验证其规模或性能，也未将官方内部方案视为公开可直接安装的产品。Git 机制依据核对当日官方文档，具体效果取决于客户端、服务端支持与工作负载。仓库意象、任务示例与诊断建议为原创分析，不构成对本站实施迁移或削弱发布检查的建议。

想继续讨论 AI 工程如何落地，可以看 [AI 实践路线](https://ai-knowledgepoints.cn/planet)；公众号入口在[关于页](https://ai-knowledgepoints.cn/about#wechat)。

本文文字与图解由 AI 辅助制作，来源已在正文列明。