版本控制

十月十五日腾讯研究院 AI 速递提到一个很硬核的工程故事：Anthropic 日均合并代码变更从五月的约 2500 次涨到九月的超 3 万次，单体仓库每天检出约 2500 万次——如果继续用 Git，全公司一年的仓库流量要超 600PB。于是一个七人团队用五个月自研了版本控制系统 Scion，把计算放服务端、客户端按需取数，各层缓存命中率超 99%，检出时间从几分钟缩到几秒。Claude Mythos 预览版还顺手重写了迁移管道，内存降到二十分之一、提速 4 倍。Anthropic 明确表示无意开源。 3 万次合并一天是什么量级？ 传统大厂 monorepo 一天几百次合并已经算高节奏。3 万次意味着每秒半次合并，而且这些合并绝大多数是 AI 起草、人审批。Git 的设计假设是「人写代码、人提交」，索引、对象存储、delta 链都是为低频写入优化的。当写入频率涨十倍、读取（检出）频率涨百倍，Git 的每一层都成了瓶颈——服务端要为每个客户端算 delta，网络要传全量对象，客户端要重建工作区。 Scion 的服务端化思路是什么？ Scion 把版本库的状态机放在服务端，客户端不再拉全量对象，而是按需取「我这次检出需要的那几个文件版本」。这本质上是把版本控制从「分布式文件系统」改造成「带历史的数据库」：服务端知道你的缓存里有什么，只发增量；客户端缓存 99% 命中，网络只传那 1% 的差异。这跟 Cloudflare 或 CDN 缓存静态资源是同一个思路——版本控制被重新设计成内容分发系统。 为什么不开源？ Anthropic 不开源的理由很现实：这是它自家 AI 工作流的定制件，跟内部 Claude 模型、审批流程、缓存协议深度耦合，开源出来别的公司也用不了。但信号很清楚：当企业代码仓库被 AI 推到 PB 级，版本控制、CI、代码审查这些「老基建」都要重做一遍。下一波创业机会就在这——给非 Anthropic 的公司做 PB 级 monorepo 版本控制。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月十五日，据腾讯研究院 AI 速递披露：Anthropic 内部日均合并代码变更从五月的约 2500 次，涨到九月的超过 3 万次，单体仓库每天检出约 2500 万次——如果还用传统 Git，传输量要超过 600PB。于是一支七人小队花了五个月，自研了一套服务端化的源码控制系统 Scion，把计算放在服务端、客户端按需取数，各层缓存命中率超过 99%，检出时间从几分钟压缩到几秒。Anthropic 同时表示无意开源。这是「用 AI 写代码写到连 Git 都崩了」的活案例。 3 万次日合并是什么概念？ 传统软件公司一天合并几百次代码就已经算高强度了。Anthropic 三个月内从 2500 次冲到 3 万次，涨了十几倍——这不是人写出来的速度，而是 AI 智能体在疯狂提交。当几十个 Claude 实例同时改代码、同时跑测试、同时提合并请求，传统版本控制系统的设计假设就崩了：Git 是为「人每天提交几次」设计的，它假设客户端要拉全量仓库、要在本地做大量计算。现在提交频率高三个数量级，这个模型根本撑不住。 Scion 到底改了什么？ 核心思路是把 Git 的「客户端胖、服务端瘦」整个反过来。传统 Git 每次检出要把整个仓库历史传到本地；Scion 把计算和存储都放在服务端，客户端只按需取自己需要的那一小段，靠多层缓存把命中率做到 99% 以上。Anthropic 还让 Claude Mythos 预览版重写了迁移管道，内存占用降到原来的二十分之一、速度提升 4 倍。这不只是换个工具，而是把版本控制从「文件同步协议」重写成了「为 AI 智能体高频并发优化的数据服务」。 为什么不干脆开源？ Git 之所以能统治二十年，靠的就是开源生态。Anthropic 不打算开源 Scion，理由很现实：这套系统是为它自己那种「AI 主导的超大规模仓库」定制的，通用企业还没到这个规模，开源出去也没人能用。但它透出的信号更值得注意：当 AI 把代码产出量推到 PB 级，版本控制、CI、代码评审这些被认为「早就成熟」的老基建，全都得重做一遍。接下来两年，所有重度用 AI 写代码的大公司，都会面临同样的问题——是继续给 Git 打补丁，还是自己造一套为 Agent 时代设计的研发基础设施。Anthropic 选了后者。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论。 ...

引言 Prompt是大语言模型应用的核心资产，但在很多团队中，Prompt的管理方式仍然停留在复制粘贴和聊天记录中。随着Prompt复杂度增长和团队协作需求增加，缺乏版本管理的Prompt会导致：无法追溯变更历史、无法回滚有问题的修改、无法复现线上效果、团队成员各自维护不同版本。本文分享将Prompt纳入专业版本管理的实践方案。 为什么Prompt需要版本管理 Prompt是代码 Prompt与代码有相似的特性：需要迭代调试、存在依赖关系（系统Prompt→Few-Shot示例→用户输入模板）、需要测试验证、可能引入回归问题。因此，Prompt应享受与代码同等的版本管理待遇。 Prompt变更的影响 一个看似微小的Prompt修改可能导致模型行为的显著变化：将"请分析"改为"请详细分析"可能使输出长度翻倍；调整示例顺序可能影响Few-Shot效果；修改约束条件的措辞可能改变模型的遵守程度。没有版本管理，这些变更的影响无法被追踪和评估。 Git工作流设计 仓库结构 prompts/ ├── system/ │ ├── assistant.md # 通用助手系统Prompt │ ├── code-reviewer.md # 代码审查专家 │ └── data-analyst.md # 数据分析师 ├── templates/ │ ├── classification/ # 分类任务模板 │ ├── extraction/ # 信息提取模板 │ └── generation/ # 内容生成模板 ├── few-shot/ │ ├── sentiment/ # 情感分析示例 │ └── ner/ # 命名实体识别示例 ├── tests/ │ ├── test_cases/ # 测试用例 │ ├── expected_outputs/ # 期望输出 │ └── runners/ # 测试运行器 ├── configs/ │ ├── models.yaml # 模型配置 │ └── environments.yaml # 环境配置 └── README.md Prompt文件格式 每个Prompt文件采用统一的格式： ...