码农早餐 · 2026-10-14

Anthropic 的 monorepo 主分支历史快 100 GB，压缩后工作副本还超 25 GB，每天 2500 万次 checkout 供 CI 用，最后干脆不用 git、换成自研的 Scion，迁移花了五个月。我的第一反应是：这坑迟早会轮到我们，先别急着夸它快，看看自己仓库离这个量级还有多远。

.gitignore 里那套规则，Anthropic 已经不用 git 了

上次我们聊过 Anthropic 的日合并量涨到 3 万次，今天这篇是他们自己披露的后续：为了扛住这个量，他们把整个 monorepo 从 git 迁走了，换成了自研的 Scion，迁移只花了五个月。时间线是 2026 年 5 月日均约 2500 次合并，到 9 月超过 3 万次，涨了十倍以上，而瓶颈从写代码变成了源码管理、构建和 CI 这些「为人手规模设计」的基础设施。你如果在自己机器上敲过 git clone 一个稍大的仓库，就知道这个方向上的压力长什么样。

代价先摆出来。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB，每天大约 2500 万次 checkout 供 CI 使用，天真地拉取会产生超过 600 PB 的 git 流量。他们试过 shallow clone、sparse checkout、promisor remote、内部镜像和快照种子，峰值时跑着几百个 git mirror，但随着合并率上升，种子离 main 越来越远，依赖历史的 diff 和 blame 越来越难维护。Scion 的核心改动是三条：客户端永远在线，数据按需向服务端取；客户端只保留有限的对象缓存，commit、merge、rebase 全在服务端做；仓库数据分布式存储，任何地方都没有一份完整物化副本，也没有 packfile 这种需要定期维护的东西。git 为离线分布式做的那些优化，在客户端全是常驻在线的 agent 时，反而成了拖累。 配套的还有代码评审界面 Antique、代码搜索和一套源码管理 IAM，都在同期上线。

值得注意的对照是，超大 monorepo 的源码管理早有先例，Google 的 Piper、Meta 的 Sapling 都趟过这条路，Scion 是带着这些经验做的。另一个细节是 ref 被有意弱化，除 main 和发布分支外不建议用分支和 tag，因为需要所有服务端达成一致的全局状态本身就是扩展性问题。对大多数团队来说，这套东西现在还用不上，原文也承认近期不会有太多组织遇到同样的问题，但他们判断用 AI 编码工具的人迟早会撞上同样的压力点。真正该记住的不是「该换版本控制系统了」，而是当你的客户端从人变成 agent，很多为人的使用习惯做的默认假设都会开始漏风。

💡 主厨说：Scion 现在不值得你抄，但那句「瓶颈从写代码变成源码管理」值得你记着——先看看自己团队的 CI 和 review 流程，哪一步是为人手速度设计的。

来源：

• Redesigning source control at Anthropic

Janas：32 GB 笔记本跑 48 GB 的 MoE，读 prompt 62 tok/s

一个叫 Janas 的推理引擎开源了，纯 C 写的，CPU 或 GPU 都能跑。它做的事很直接：MoE 模型的专家权重不常驻内存，从 NVMe SSD 流式读进来，于是 32 GB 内存的笔记本能跑 48.4 GB 的 Qwen3-Next-80B。作者给的数字是写 37 tok/s、读 prompt 62 tok/s，同样的机器上 llama.cpp 是 2.8 和 16。仓库里还列了 13 个 Q4_K_M 量化模型的对比，说每一个都比 llama.cpp 快。

这类「比 llama.cpp 快 N 倍」的说法，我第一反应是先看它在什么条件下测的——单机、单模型、Q4_K_M、带投机解码的 37 和去掉 draft 的 24 差了不少，换台机器换种量化，倍数未必守得住。但方向本身有意思：内存不够时，与其降参数，不如把 SSD 当第二层显存用，代价是首次读专家的延迟和 SSD 寿命。想在自己机器上跑大 MoE 的，值得拉下来对一遍。

来源：

• Janas - GitHub

一小时音频 13 秒转完，代价是 5% 错字率

有人把 Google 的 EmbeddingGemma 2 改成了语音转文字：音频编码器原封不动，只训练一个把音频切片搬进文本空间的小 reader，从约 22.9 万个英文词里挑最近的，再加个小模型补标点和大小写。在 8 GB 的 M3 MacBook Air 上，1 小时音频 12.6 秒转完，全程跑在 Neural Engine 上，音频不出本机。代价写在明面上：词错率约 5%，主流语音模型是 2–3%。速度是真快，但错字率翻倍意味着转完还得自己过一遍。

来源：

• hackernews · amrrs

Anthropic 自建源码系统：日合并量 2500 到 3 万

Anthropic 在工程博客里说，他们自建了一套源码管理系统。5 月每天合并约 2500 个代码变更，到 9 月这个数字涨到 3 万以上，翻了十倍还多。他们的说法是，原来的开发者基础设施是按人的规模建的，现在被撑爆了，成了瓶颈。

值得琢磨的是这个量级本身。一天 3 万次合并，靠人写是写不出来的，背后必然是大量 agent 在提交。也就是说，代码托管、CI、review 这一整条链路，正在从「给人用」变成「给 agent 用」。你手上的 pipeline 如果还是按人天节奏设计的，迟早也会撞上同一堵墙。先别急着羡慕这个数字，想想你的 review 流程还能不能看懂这些提交。

来源：

• @AnthropicAI

HN 上首页后，网站被 AI 爬虫拖垮

发帖上了 HN，拿到一百来个 upvote，本该是高兴的事。但作者发现网站几天后反而越来越慢，日志里真正登录的活跃用户只有一小撮，服务器负载却高得离谱。加上按 URL 路径统计的日志才看清：大部分请求连新闻正文都不去取，纯粹在扫接口。流量来源不是读者，是爬虫。这事跟你的关系很直接：只要你的站点能被公开访问，被 AI 爬虫盯上只是时间问题，早点想清楚哪些路径该限流、哪些该直接挡掉，比事后救火便宜得多。

来源：

• hackernews · sammy0910

---

本期从过去 24h 的 X / Hacker News / GitHub Trending 共 59 条信息中挑出 5 条（全天逐小时采写、经事实校对后于晨间选编）。内容由 LLM 辅助生成，每条均附原始来源链接，重要决策请交叉验证。