Anthropic换掉Git,软件开始为AI重新设计了吗

10月13日，Anthropic发布了一篇工程复盘。他们用五个月做了一个叫Scion的系统，把内部大型代码仓库从Git迁了过去。

原因很直接，AI写代码带来的变更增长，让原来的基础设施越来越难承受。团队开始按大量AI任务的工作方式，重新设计代码管理。工程复盘

Git是程序员保存修改历史、协作开发时经常使用的工具。你不写代码，也可以把这件事理解成，一个工厂的生产速度突然变快，仓库、运输和交接得跟着调整。

多装几台机器，未必就够了。

这件事让我更想讨论另一个问题。如果软件的主要使用者开始变成AI，我们还会照着今天的样子造软件吗？

过去谈AI与软件，我们常讨论它能不能替人写代码，能不能做出一个更便宜的替代品。Scion提供了另一个入口，产出的速度变了，接收产出的那套系统也可能要变。

软件会怎样组织数据，怎样接受操作，怎样让人知道发生了什么，这些问题都值得重新想一遍。

先把这件事放回它的具体场景。

Git常规的完整克隆方式，让使用者在本地拥有代码和历史，许多查询与修改可以离线进行。它也支持浅克隆、部分克隆和稀疏检出，让人按需要缩小下载或工作区范围。Git并没有一条「每次必须下载全部文件」的死规定。

这类安排照顾了一个很重要的需求，使用者可以在自己的机器上掌握工作，不必每个动作都等待远端回应。

如果使用者变成持续在线、频繁创建和结束的AI任务，取舍就可能不同了。

Scion把提交、合并和历史查询等工作更多放在服务端，客户端按需取数据，有些任务甚至不必准备本地工作副本。这是它在特定规模下选择的工作方式。

同样是管理代码，一个设计让使用者在本地拥有较完整的能力，另一个设计让大量在线任务轻装接入服务。

谁使用它、怎样使用它，会改变哪些成本值得付。

图1，根据官方说明绘制的简化示意。上半部分仅代表Git的完整克隆工作方式，Git也支持部分克隆等机制；下半部分描述Scion的特定设计，不表示一般团队应该迁移。

不过，这里有一段历史不能跳过。

Google在2016年的论文里，就讨论了自建大型代码仓库的规模、工作流程和取舍。Meta在2022年开放Sapling客户端时，也介绍了它此前长期投入的规模化改造，以及对开发者使用体验的改进。

所以，不能看到一家AI公司重做代码管理，就把所有大仓库的问题都算到AI头上。

更值得观察的是，AI可能让一些原本只有极少数大公司遇到的压力，以不同的方式出现。

一个人工作时，会阅读、犹豫、讨论，也会结束一天的工作。设计者可以把这些停顿当成自然存在的缓冲。AI任务的运行节奏不一定如此。如果很多任务同时开始，同时提出修改，同时查询同一批数据，平均一天能处理多少次操作，可能已经不足以描述系统要面对的压力。

还得问，它们是否集中在同一时刻？失败后会不会一起重试？每次操作之前，要重复搬多少东西？

这些问题看起来很工程，背后却有一个容易理解的变化。

软件原先默认的工作节奏，可能正在改变。

如果沿着这个变化往外推，会发现界面也可能发生变化。

人使用软件，通常需要先看见信息，再找到操作入口。按钮、菜单、颜色、布局，都在帮助我们理解眼前的状况。

假设让一个AI整理一批文件，它可以照着屏幕点击，也可以通过接口直接调用「列出文件」「移动文件」这些动作。后一种方式不必经过给人看的菜单，但需要把输入、结果和错误说清楚。

MCP的工具规范已经提供了这样的入口，让模型发现并调用外部系统的功能。规范同时保留对人可见、可拒绝调用的交互建议，具体呈现方式交给应用决定。

这给软件设计提出了一个有意思的问题。同一个操作，为人和为AI提供的入口，是否还应该长得一样？

人需要看懂。AI需要能够调用。两者有共同的目标，但不必共享每一个操作步骤。

以后一个软件可能需要认真服务两种使用者。

AI负责执行时，希望任务能连续进行，状态能明确返回，失败能定位。人回来看结果时，希望知道哪些内容改过、为什么改、接下来还能怎么处理。

把几层菜单接成一句提示词，只解决了从哪里开始的问题。后面的工作仍然存在。

这一点，对想做软件的人尤其重要。界面上少了几个按钮，不等于用户少了几种需要。

反而可能多了一种。

我没有亲手操作时，怎样仍然掌握这件事？

假设一个AI替你调整了几十个日程，屏幕只显示「已完成」，你很难判断它有没有理解错一句话。把所有操作日志展开，又可能让你面对比手动安排更长的一串记录。

这是一个设计上的两难，不是说哪款产品已经出了这个问题。

人需要的可能是一种有层次的交接，先看重要变化，再看相关理由，必要时回到具体操作。哪些安排影响别人，哪些只是改了自己的提醒，应当容易区分。

撤销也不能只停留在一个看起来很友好的按钮上。文件移动回来相对容易，已经发出的通知、已经触发的其他系统，不一定能按原路退回。软件要说明哪些能恢复，哪些需要进一步处理。

AI把执行过程藏起来之后，交接过程就更值得认真设计。

图2，我们对未来产品的设计推演，非产品实测。人可以让AI连续执行，同时保留查看关键变化、限制授权和处理错误的入口。具体确认频率应随任务影响而定。

这里也就出现了商业上的新问题。

如果读者很少打开一个软件，主要由AI替他调用，过去用来吸引注意的首页、推荐位和层层操作入口，还会有多大作用？

这个问题目前没有统一答案。面向消费者的创作、游戏和社交，体验本身仍然可能是人想得到的东西。不能因为部分工作交给AI，就推断所有界面都要消失。

但在一些以完成任务为主的场景里，软件可能要换一种方式证明自己的价值。

它能否提供稳定、清楚的操作入口？能否留下可检查的记录？能否在出错时让用户恢复？如果一个任务要跨过几套系统，它能否把结果准确交给下一步？

这些能力，往往没有漂亮的首页那么显眼，却可能成为用户选择服务的理由。

对已有客户和数据的软件公司，这也未必只是坏消息。

假设一家企业的合同、审批和日常协作已经依赖某套系统，一个新的AI助手替人发出请求，并不会自动搬走那套系统里累积的数据关系、操作权限和工作记录。能把这些能力可靠地交给AI使用，仍然有价值。

更容易被替换的，可能是某些重复点击和搬运的部分；更难迁移的，可能是那些牵动许多人、许多系统的关系。

这是一种值得验证的行业推演，不能据此断言某家巨头一定受益或一定衰落。

小团队也会遇到相应的选择。

做一个新产品，可以继续把人的每一步操作打磨得更顺，也可以找到一个已有产品难以直接交给AI完成的具体任务，把入口、状态和交接做清楚。

哪条路值得走，要看用户真正需要完成什么。

如果一个任务依然需要人反复比较画面、调整细节、体会手感，那么人的操作体验就很重要。若工作主要是跨系统查询、整理和执行，是否容易被调用与检查，可能更重要。

不能只问「AI能不能把它做出来」，还得问「谁会用它，愿意为什么留下来」。

还有一个容易被效率叙事带过去的取舍。

把更多能力放在服务端，客户端可以更轻，统一管理也更方便。同时，使用者对网络、服务提供方和访问权限的依赖，可能加深。

这不只是速度的区别。它牵涉到，一个人或一家组织能够带走多少工作，服务变化时能否继续使用，遇到争议时还能保留什么记录。

那些为了人的离线工作、自主控制而保留下来的能力，可能显得不够方便，但有时恰恰是用户需要的。

为AI重新设计软件，应该包含这些取舍。只按AI执行得顺不顺来评价，容易漏掉最后承担结果的人。

回到Scion。

Anthropic自己明确说，这套设计适合极大的代码仓库和大量AI任务，不是Git的一般替代品；它也有特殊的内部资源条件。原文的适用范围

一个普通团队，完全可能继续使用熟悉的工具，得到更合适的结果。迁移本身也有成本，已经有效的协作方式不必为了显得先进而重做。

我们从这件事里能带走的，是一个观察软件变化的角度。

过去，软件设计者花了很多力气，让人更容易完成操作。以后，一部分软件还要回答，怎样让AI更容易接入工作，怎样让人更容易接回控制。

两件事都得做好。

工厂的生产线可以越跑越快，但仓库往哪里送、货物交给谁、出了问题怎么追回，仍然需要清楚。

代码管理只是一个已经开始变化的地方。更值得继续看的，是其他软件会怎样重新安排这些交接。

AI可能是越来越忙的使用者。

工作最后落到谁的生活里，软件就仍然需要照顾谁。