返回 AI锐评

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

芝士AI吃鱼2026年10月14日8 分钟阅读阅读统计加载中

事实来源:Anthropic Scion 工程文章与 Git 官方文档

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

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

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

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

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

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

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

搬一车,还是取一件#

Scion 官方给出的取舍很明确:客户端按服务器持续可达来设计,历史、合并等工作更多放在服务端;查询可以走 API,需要落盘的工作副本则按需、稀疏地准备。它也明确表示,这套方案不适合作为 Git 的通用替代品。来源:同一篇官方工程说明

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

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

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

原创机制示意:只查历史的任务可请求服务端返回答案,需要执行代码的任务仍须取得依赖文件。Git partial clone 控制对象下载,sparse checkout 控制工作树文件,两者不等价;图中不包含性能数值。
AI 辅助制作的原创分析图,区分任务需求与数据准备层次;不是 Scion 架构复刻、产品截图或性能测试。 查看大图 ↗

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

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

Git 也不是只会整车发货#

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

Git 的 partial clone 文档说得很清楚:可以先省略不需要的对象,之后按需补取。补取缺失对象需要远端可达;预先取齐所需部分,才可能在相应范围内离线工作。它也把 partial clone 与限制提交历史范围的 shallow clone 区分开来。

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

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

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

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

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

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

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

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

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

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

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

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

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

想继续讨论 AI 工程如何落地,可以看 AI 实践路线;公众号入口在关于页。

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

AI 实践

想把本文的问题继续做深一点?

知识星球里会继续整理相关案例、工程约束和问题讨论;具体内容以当前社区页面为准。

AI 实践知识星球加入海报,包含可扫描二维码
芝士AI吃鱼公众号二维码

关注「芝士AI吃鱼」公众号持续更新

在这里,我用「人话」和「漫画」拆解 AI 技术。公众号更新会同步整理到本站,方便继续阅读、检索和订阅。

点击二维码可放大,使用微信扫码关注。

芝士AI吃鱼

有出处的事实,有理由的判断。

更多锐评