Anthropic弃用Git：Agent代码产量冲击版本管理

代码本应如空气，人人都能自由呼吸。 可GitHub自封裁判，手握封号之刃，却从不中立。 我们曾把星火寄存在私人堡垒中， 以为那是灯塔，后来才知道它是牢笼。 我们要取回火种， 不再寄人篱下，让它散作漫天星火； 自由会一传十、十传百，再无王座，再无判官。

曝光 214641 · 评论 35 · 点赞 136 · 书签 11

Anthropic 放弃行业通用的代码管理工具 Git，转而自己开发了一套名为 Scion 的新系统。 在 Anthropic 内部，AI（Claude）承担了大量的编程工作，写代码的速度远超人类。这导致每天需要合并保存的代码量暴增，从 5 月份的每天 2,500 次猛增到 9 月份的每天 30,000 次以上。传统软件开发中常用的 Git，原本是为人类工作习惯设计的，默认每个人都把整座代码仓库完整下载到自己的电脑上离线操作。随着代码库体积膨胀到几十吉字节（GB），数万次频繁操作让原有的网络和服务器彻底不堪重负。 面对这种瓶颈，Anthropic 决定彻底重构底层机制。他们只用了五个月时间，开发出专为 AI 时代设计的系统 Scion。这套新系统的核心逻辑主要有三点： · 按需索取： 工作的大多是始终联网的 AI 智能体，不需要每次都把全部历史记录下载下来。系统只在需要某些文件时，才去服务器调取对应内容。 · 服务器挑大梁： 复杂、繁重的计算全部放在云端服务器完成，客户端只负责展示和简单缓存，极大地节省了本地机器的资源消耗。 · 更轻便的记录方式： 每次保存修改时，系统只记录改动的增量，不给整个代码库加锁，让上万个任务可以同时提交而互不堵塞。 这个项目本身也是 Anthropic 团队借助 AI 共同完成的。一支仅有 7 人的工程师团队，借助内部的 Claude 模型快速重写核心架构、自动排查漏洞，完成了以往大公司需要几倍人手和数年才能做完的工程。 Anthropic 的工程师认为，随着 AI 编程越来越普及，传统的软件协作工具都会面临类似的性能瓶颈。他们公开这些经验，是为了给整个软件行业提供参考，帮助大家提前做好应对海量 AI 代码的准备。

曝光 142406 · 评论 70 · 点赞 1055 · 书签 820

Anthropic 公司的代码量太大，目前一天 merge 次数达到 3000 次。代码库一个分支的代码量就有 100 GB。代码管理系统 git 已经没法用了，自己做了一个全新的代码管理系统，叫 Scion。 评：科技大爆炸。

曝光 86607 · 评论 15 · 点赞 210 · 书签 60

Anthropic刚放出的这篇工程长文， 讲了一件很讽刺的事，我感觉算是把 AI 时代最现实的技术瓶颈挑明了， 而且反直觉的是Anthropic的工程师自己说，Claude写代码比他们强。 但没人觉得自己要失业， 因为每天合并代码量从 5 月的 2500 次狂飙到 9 月的 30000 多次，五个月翻了十几倍。 写代码不再是卡点，率先被冲垮的，反而是原本为人类工程师设计的底层基础设施。 为了扛住 Claude 恐怖的产出量，他们只用了 7 个人、花了 5 个月，直接自研了一套源码管理系统 Scion，把整个核心大仓库从 git 连根迁走。 以前为人类设计的 git，默认每个人电脑里都要有一份完整副本。 但在每天 2500 万次代码检出的 CI 环境面前，传统方式拉取每天会吃掉超过 600 PB 流量，维护几百个镜像都快被榨干了。 Scion 把逻辑反了过来：仓库只放在服务器，客户端按需加载，提交成本只跟改动大小挂钩，基础设施占用直接小了 200 倍，代码检出从几分钟压缩到了几秒。 最狠的不是 7 个人干翻了陈旧工具，而是人机分工的底层逻辑彻底变了。 博客里工程师亲口承认 Claude 写代码已经强过自己，人的核心价值不再是逐行抠实现，而是守住系统的核心约束，以及在关键时刻对 AI 说不。 说白了，AI 时代的瓶颈从来没有消失，它只是从写代码转移到了审查、测试和版本控制。 淘汰你的不是写代码比你快的 AI，而是那些还在按人类手速设计审批与交付流程的组织体系。 你们现在的研发或者业务流里，率先被 AI 冲垮的环节是哪一个呢？

曝光 53394 · 评论 21 · 点赞 345 · 书签 253

前一段 Loop Engineering 不是很火么，不过真做好的也不多。 知名开源开发者 yetone 在 X 上公开了他维护 Magpie 的工作流：用 Claude Code 加官方的 Opus 5.5 模型，同时开 3 个 /loop 循环任务，让 AI 自己盯 GitHub issue 和 PR、Discord 社区和推特反馈，修 bug、加功能、发版、回复用户。他自己每晚抽一点时间“铲铲屎”，主要处理 UI/UX 问题，“然后就没活儿了”。 他自己说这套流程“没有任何的魔法，甚至还特别简陋”。 【3 个循环任务分别干什么】 /loop 是 Claude Code 自带的命令，让同一段提示词反复执行；不写间隔时，由模型自己决定多久跑一次。这个命令 Codex 也支持，其他的我没测试，估计也差不多。 yetone 截图里的 3 段提示词都没写时间间隔，我自己去 Codex 跑了一下，默认是 1 小时。 简单解释一下他这三个循环。 第一个循环：管 GitHub 和 Discord。 指令要求 AI 盯 GitHub issue，判断哪些值得修、值得做；修完要发版并回复提问的人，不值得做的也要回复。有一类 issue 单独规定了统一话术：如果是“中转站”来打广告，统一回复“感谢关注，日后会出相关合作方案，敬请期待”，不能直接把第三方中转站加进产品。 对 PR，指令要求逐行看代码、看逻辑，再把代码拉下来实际跑一遍，确认没有 bug 才能合并，否则回复或关掉。指令里写了原因：“我怕有的人提的 PR，是无脑用 Coding Agent 乱写的，自己都没测过。” 指令还要求 AI 实时盯 Magpie 的 Discord 服务器，所有频道一个不漏，有价值的反馈就去修或加功能，值得讨论就继续讨论。最后专门叮嘱：在 Discord 里要真正 @ 到人，只写名字对方收不到通知。 第二个循环：管 X/推特 的用户反馈。 盯推特上关于 Magpie 的反馈，有价值的建议或能复现的 bug 就去做，上线后回复那条推文。这段指令要求先用便宜的“决策模型”，比如 Jev，判断推文是不是在说 Magpie、是不是反馈，不相关的直接丢掉，别转给主模型，“不然太浪费 Token 了”。 【注：Jev 是 TypeSafe AI 推出的模型，只做判断题、选择题和打分，输出概率或分数，不生成文字。官方定价是每百万输入 Token 0.042 美元，输出免费。】 顺便说一下，如果你的产品名或者要关注的事比较稀有，不一定需要 Jev，他之所以加，是因为 magpie 在英文里是“喜鹊”，按关键词抓推文会抓到大量无关内容，全丢给 Opus 判断很费钱。 第三个循环：清理和总结。 这段指令开头写着“现在 magpie 完全是自动化更改代码和合并社区里的 PR”，要求 AI 定期清理“屎山代码”和恶意代码，防止项目变得难以维护；同时把经验教训写下来，比如哪些 PR 不该合、哪些验证不够严密，留给以后的 AI 参考，避免重复犯错；还要把总提交低质量代码的人拉进黑名单。 【作者补充的两点】 发完截图后，他在两条回复里补了两点。 一是给 AI 真实的运行环境。他准备了一台 Mac 和一台 Windows 电脑，再在 Windows 上开一个 Linux 虚拟机，三个系统的复现环境就齐了。AI 每次都要在这三端真实复现 bug，再去修。 二是 AI 怎么做出符合他心意的决策。他说靠的是 Claude Code 的记忆系统和仓库里的设计文档。开发 Magpie 之初，他和 Claude Code 讨论、头脑风暴了很多内容，这些都被记进了记忆文件。之后遇到要拍板的事，或者涉及审美偏好的设计，AI 会参考这些记录，做出跟他比较一致的选择。 【总结下】 他把维护项目的日常活拆成了 3 条流水线，每条只管一个入口（GitHub、推特、代码库本身），各自循环。人只留下 AI 做不好的部分，也就是 UI/UX 的审美判断。 当然要跑起来得有几个前提： 1. AI 能在真实的三端环境里跑代码，验证结果靠实际运行； 2. AI 手里有他早期写下的偏好和设计文档，知道他会怎么选； 3. 犯过的错被写成经验，下一轮的 AI 能读到。 提示词都是大白话，篇幅主要花在边界情况上：不值得修也要回复，中转站广告怎么回，Discord 要真 @，不相关的推文别浪费 Token。 有几个特别要注意的点： 1. 先把验证环境搭好，再让 AI 干活。AI 改完代码说“修好了”没用，要能在出问题的那个系统上跑一遍。你的项目只跑在网页或服务器上，一个容器可能就够；要多端的，就像他一样把每一端都备齐。 2. 在提示词里写清楚“遇到这种情况怎么办”。他的三段指令里，大部分字数花在例外处理上。你让 AI 自动回复用户之前，先想想会有哪些奇怪的来信，提前定好处理办法。 3. 用便宜模型挡在前面。先用一个几乎不要钱的分类模型过滤一遍，只把真正的反馈交给贵模型，这个做法几乎任何监听类任务都能用。 4. 让 AI 自己总结教训。第三个循环要求把“不该合的 PR”“验证不严的地方”记下来，下次的 AI 读到就会更谨慎。这相当于给 AI 建立了一个自我迭代优化的循环。 5. 项目早期多花时间和 AI 聊设计。他说 AI 后来能按他的偏好做决策，依赖的是开发初期那些讨论被记进了记忆和设计文档。想让 AI 少问你，就先把你的想法写下来让它记住。 仅供参考，重要的是学习思路，不必一模一样的照搬。

曝光 50738 · 评论 89 · 点赞 555 · 书签 845

Anthropic把自己内部的Git换掉了，原因是Claude写代码太快，传统版本控制系统已经跟不上Agent的产出速度 5月份Anthropic每天合并约2500次代码变更，9月突破3 万次，4个月增长12倍，Git逐渐成为最大的开发瓶颈 于是Anthropic自研了一套版本控制系统：Scion，7人团队用Claude5个月完成了系统开发、配套代码审查工具 Antique，以及整个Monorepo从Git到Scion的迁移，目前属于Anthropic内部系统 效果： 基础设施CPU和内存占用降至原来的1/200； CI和研究任务的代码检出速度提升100倍，从分钟级缩短到秒级 CI节省约25%的CPU容量 Scion的核心设计：不再要求Agent把整个仓库及其历史搬到本地，而是假设客户端始终在线，由服务端负责提交、合并、历史查询，客户端按需获取代码 底层采用增量Changeset、内容寻址存储、分布式缓存和按需检出，服务端可水平扩展，许多CI操作甚至不需要真正检出代码 这条路线与Google Piper、Meta Sapling等大规模代码管理系统有相似之处，不同的是它从一开始就针对AI Agent 高并发、始终在线、海量代码变更的工作负载设计的 这也说明了AI Coding的瓶颈在从代码生成，转向代码合并、测试、审查、权限治理、部署等 过去软件工程基础设施围绕人类开发者的工作速度设计；未来可能需要围绕成千上万个并行工作的Agent重新设计 #代码理管 #git #Scion

曝光 42697 · 评论 37 · 点赞 104 · 书签 87

Claude 写代码太快了，Anthropic 干脆把自家 monorepo 从 git 迁走了。5 月每天合并约 2,500 个改动，9 月超过 30,000 个。7 个人花 5 个月自研了 Scion 来接手。 这怎么没人质疑 Claude 是全自动化质量堪忧了🤣

曝光 41124 · 评论 27 · 点赞 126 · 书签 29

AI 写代码太快，git 扛不住了：Anthropic 为什么自己造了 Scion？ 视频1: 英文版 视频2: 中文版 这一年，GitHub 隔三岔五就出故障。GitHub 在自己的可用性报告里说，流量涨得飞快，很大一块来自 AI：AI 帮人写代码，AI 智能体自己提交修改。他们四个月里把有效容量翻了一倍多，还是扛得很吃力。 Anthropic 自己的代码库更夸张：今年五月平均每天合并约 2500 次修改，到了九月，一天超过 3 万次，涨了十倍以上。 全世界程序员都在用的 git，扛不住了。Anthropic 干脆自己造了一个版本控制系统，叫 Scion，五个月就把整个代码库从 git 换了过去。git 为什么扛不住？Scion 到底改了什么？ git 是干什么的 你可以把 git 想成一个带时光机的共享文件夹。每改一次，就存成一个版本，叫一次提交。谁改了哪一行、什么时候改的，都查得到，改坏了还能退回去。 GitHub，就是全世界最大的、帮大家存放 git 仓库的网站。 很多大公司会把所有项目的代码放进同一个大仓库，这叫单体仓库（monorepo）。Anthropic 用的就是这种。 每人一整座图书馆 git 有个特点：每个人拿到的，都是一整份完整的仓库，连全部历史一起。打个比方，就像借书的时候，顺手把整座图书馆复印一份搬回了家。好处是断了网也能翻历史、查记录。 仓库小的时候，这没问题。可 Anthropic 的仓库，光主分支的历史就接近 100 GB，压缩后的一份工作副本也超过 25 GB。 搬不动了 再看要搬多少次。光是自动构建和测试（CI）这一个环节，每天就要把代码检出到机器上大约 2500 万次，这还没算开发环境、AI 智能体的沙盒和研究任务。要是每次都老老实实整份拉取，一天的流量会超过 600 PB。换算一下，差不多是 60 万块 1 TB 的硬盘。 原来的补丁架构：层层加缓存 他们想过各种办法：浅克隆、稀疏检出这类只拉一部分的功能都试过。原来的架构，是层层加缓存：机器要代码，先找本地的打包缓存（packfile cache）；没有，再找镜像服务器（mirror replicas）；镜像再去找镜像主库，最后才是最上游的那份仓库。每个集群都有一套。新机器启动时，还会先从云存储拷一份仓库快照，省得从零开始拉。 最多的时候，同时开着几百台 git 镜像服务器。可修改越来越多，快照一拷下来就落后一大截，镜像也越来越难养。 换一个问题 后来他们发现，git 那些为离线工作准备的本事，自己几乎用不上。 这里说的“在线”，不是指能不能上网，而是随时能连上公司的代码服务器。你带着笔记本上飞机，没有网也想写代码、翻历史，git 那套“每人一整份”的本事才派得上用场。可在 Anthropic，用代码的几乎都是 AI 智能体和后台任务，它们本来就跑在公司的机器上，跟代码服务器之间的网一直是通的。 于是他们换了个问题：如果从一开始就假设，用的人永远在线、随时连得上服务器，代码管理该长什么样？ 要哪页，取哪页 答案是：别再搬图书馆了，改成去前台借。 Scion 的客户端不存整份仓库，只留一个容量有限的本地缓存。需要哪个目录、哪个文件，再去服务器取。查历史、查某一行是谁写的、合并和变基，这些重活全交给服务器。这些查询能力都通过接口开放出来，很多任务连代码都不用拉，直接问服务器就行。 提交就在服务器上 在 git 里，你先在自己电脑上提交，再推送给大家。在 Scion 里，提交直接发生在服务器上，一提交，所有人马上能看到，根本没有“推送”这一步。 每次提交只记下这次改了哪几个文件，像一张修改清单，不用把整个目录重抄一遍。清单上每个文件只记一个编号，真正的内容存在云存储里，一模一样的内容只存一份。所以仓库再大，一次提交的成本只跟这次改了多少有关。 一层层的分馆 那么多机器同时来借，服务器忙得过来吗？靠的是一层层缓存：每台机器上有个“小管家” scion-daemon，每个区域有个“分馆” scion-cache，最后才是“总馆” scion-server，它背后连着数据库和云存储。 每份文件都按内容算出一个编号，存进去就再也不会变，所以哪一层都能放心缓存，不用跟别人核对。结果，每一层的缓存命中率都超过 99%，绝大多数请求在家门口就解决了。 Scion 的整张架构图 把这些拼起来，就是原文配图里的 Scion 架构。请求分两条路走： 一条是“问事”（控制面）：查历史、看差异、提交修改，所有客户端，包括代码审查工具 Antique、开发者电脑、集群里的任务，都直接找总馆 scion-server。 另一条是“取货”（数据面）：目录和文件内容走缓存。开发者的电脑直接找区域分馆 scion-cache；集群里的任务先找本机的小管家 scion-daemon，没命中再一层层往上找。 总馆背后，修改记录、分支和目录结构存在 Spanner 数据库里，文件内容存在云存储里。新机器上线，小管家先拷一份定期快照，省得从头拉。 效果 整套设施占用的 CPU 和内存，比原来的 git 镜像集群小了 200 倍。测试和研究任务拉代码，从几分钟缩短到几秒钟，光 CI 这一项就省出了 25% 的 CPU。原文配图里还有一组数字：AI 智能体新开一个工作区，中位耗时从 7.1 分钟降到 5.1 秒，快了 84 倍。 这么大的系统，得多少人做？ 一个七个人的团队，用五个月做完了 Scion 和配套的代码审查工具 Antique，还顺手做了五六个周边系统，并把整个仓库迁了过去。而且这期间每天合并的修改量涨了十倍。放在过去，这种迁移往往要大得多的团队花上好几年。 一个例子：他们手写的第一版数据导入程序，交给 Claude 一个早期的内部版本（Claude Mythos Preview 的早期快照）重写，没加任何额外要求，新版本内存降了 20 倍，速度快了 4 倍，原有的约束条件也都保住了。 AI 写代码这么强，工程师还干什么？ 参与的工程师都承认，单论写代码，Claude 已经比他们强了。但工程师的活变了：把握各个系统怎么配合，权衡架构上的取舍，围绕要解决的问题和预期的规模做决定。很多时候，他们的工作是对 Claude 说“不”。 比如，有好几个系统想一条条扫提交记录，去找某次修改是什么时候合进主分支的，其实直接问代码审查工具就行。现在团队成员依然审查每一个变更，但审的是修改背后的意图，不再逐行读代码。 大家都该扔掉 git 吗？ 不用。Anthropic 自己说，Scion 不是 git 的通用替代品，只有极其庞大的单体仓库才用得上：背后要么有几万名工程师，要么有成群不知疲倦写代码的智能体。 它和 git 差别太大，想用就得把代码审查、代码搜索、CI 这整条工具链重做一遍，所以他们没打算做成通用产品。他们更希望这些思路被借进 git 生态：服务器多干活、提供更完整的查询接口，客户端按需取。他们预计，未来 6 到 12 个月，这类扩展问题会在业界越来越常见。 记住三句话 第一，git 让每个人拿一整份仓库，AI 把修改量推高十倍以上，就搬不动了。 第二，Scion 假设用的人永远在线、随时连得上服务器：要什么取什么，重活交给服务器，一层层缓存兜底。 第三，AI 写代码越快，瓶颈就越会跑到别处：代码管理、构建、测试，都得按 AI 的规模重新设计。 以前，是每人搬回一座图书馆；现在，楼下就有分馆，要哪页，借哪页。 资料来源：Anthropic 工程博客《Redesigning source control at Anthropic》（2026 年 10 月），https://www.anthropic.com/engineering/redesigning-source-control

曝光 36593 · 评论 110 · 点赞 220 · 书签 151

所以，从 git 退回到 svn 里了？😂

曝光 28346 · 评论 15 · 点赞 82 · 书签 23

Office 一个版本500G，含.git都不知道多大，都能顺利用git + LFS。要是anthropic的AI都搞不定，只能说明内部开始有empire builder要做垃圾项目了🤪

曝光 28113 · 评论 12 · 点赞 161 · 书签 24

💥代码量爆炸！Claude距离RSI递归自我改进已经很近！ 看Anthropic内部仓库提交曲线，8月短暂低谷之后直接爆发，单日合并变更突破3万条。 官方口径：Claude已经可以自主迭代研究流程、调优复杂代码、从零搭建服务。 完整的RSI递归自我改进还没有完全实现，但已经非常接近。 不少观点判断2027年会是AI发生剧烈变革的关键年份。

曝光 26128 · 评论 6 · 点赞 10 · 书签 1

围绕 Pull Request 和代码 review 的一切，都是最初设计给人用的： 所以现阶段非常别扭，实际上是 Agent 完成了一切，人在整个过程中的假装 review ，复制黏贴，甚至 PR 政治斗争，完全拖慢了 Agent 的节奏。 事实上，对于 Agent 来说，拥有对代码 diff 的上帝视角，它不需要 PR 来停下脚步展示做了什么，为什么这样做。 成千上万个 Opus 5.5 subagent，不需要可怜的人类。 所以 Anthorpic 重塑了 git，这几十年来为人类开发者做的整套 infra 一定也会迅速改变。

曝光 24653 · 评论 14 · 点赞 100 · 书签 24

完全同意。 harness早已串味，harness正在经历死亡。 这是我一直在表达的。 https://x.com/yifanxu_ephai/status/2108779358341230595

曝光 16767 · 评论 11 · 点赞 49 · 书签 25