2026 年 10 月 17 日——Anthropic 于 9 月 23 日至 10 月 15 日接连发布三份工程博客，并在 Claude Code 更新日志与产品公告中给出配套动作，首次完整披露其内部智能体开发链路：Claude 编写 Claude Code 自身约九成代码，自研版本控制系统 Scion 用 5 个月接替 Git 承载单体仓库，代码审查的大部分阅读工作交给机器、人工审批按风险分级；2026 年 6 月至 9 月，Claude Code 代码库合并的变更请求（Pull Request，下称 PR）数量翻倍以上，被回退的 PR 份额下降超过 40%。
三份材料分别覆盖链路的不同环节：9 月 23 日《How we made claude.ai 3x faster in two weeks》披露两周性能冲刺；10 月 13 日《Redesigning source control at Anthropic》披露自研源码控制系统 Scion；10 月 15 日《How the Claude Code team does code review》（作者 Addy Osmani、Morgan Westlee Lunt、Qing Wang）披露七层审查流程。10 月中旬的 Claude Code v2.1.300 更新日志确认大请求启用 gzip 压缩，Code Review 功能同步在 Team 与 Enterprise 套餐正式可用。
2026-10-17 · Claude Code · AI编程 · 工程效能
1. 概览：三份官方材料拼出一条完整链路
三份工程博客的时间与核心数据如下表所示。
| 日期 | 材料 | 核心披露 |
|---|---|---|
| 2026-09-23 | How we made claude.ai 3x faster in two weeks | 两周性能冲刺，13 项用户旅程测量平均提速 3.1 倍（几何均值，p75 口径） |
| 2026-10-13 | Redesigning source control at Anthropic | 自研版本控制系统 Scion，单体仓库日合并量从 5 月约 2500 次增至 9 月超 3 万次 |
| 2026-10-15 | How the Claude Code team does code review | 七层审查流程；Claude Code 仓库 6→9 月合并 PR 翻倍以上，回退份额下降超 40% |
| 2026-10-16 前后 | Claude Code v2.1.300 更新日志与产品公告 | 发往 api.anthropic.com 的大请求启用 gzip 压缩；Code Review 在 Team/Enterprise 套餐正式可用 |
三份材料之间存在明确的因果链：智能体写入的代码量上升，源码控制与持续集成（CI）基础设施率先承压，Anthropic 以自研 Scion 解决存储与检出瓶颈；写入量进一步放大后，逐行人读的审查模式失效，团队把审查改为七层机器优先流程，人工只按风险介入；最后在客户端到服务端的每个等待环节上做测量与优化，把链路总耗时压下来。官方在 10 月 13 日博客中的表述是：「编码已不再是构建系统或开展研究的瓶颈，现在的瓶颈是为人类规模构建的开发者基础设施：源码控制、构建与 CI。」
整条链路的结构如下图所示。
2. 写作侧：九成代码由 Claude 编写
10 月 15 日博客开头复述了官方此前披露的口径：Claude 编写 Claude Code 自身约 90% 的代码。需要区分两个统计对象：单体仓库（monorepo）承载 Anthropic 内部多个产品线，每日落地的变更数从 5 月约 2500 次增至 9 月超 3 万次；Claude Code 存放在独立仓库中，2026 年 6 月至 9 月合并的 PR 数量翻倍以上，同期需要回退的 PR 份额下降超过 40%。
官方对人工审查在高速交付下的处境表述直接：在这种交付速度下，逐行人工审查代码极其困难。审查承担两项职责——在变更上线前发现并修复问题，以及在团队内建立对代码库的共同理解；文章主要讨论第一项，第二项在团队内的处理方式见 4.4 节。
写作侧的智能体参与深度在 10 月 13 日 Scion 博客中已有先例：早期以人工为主编写的 Git 到 Scion 摄取流水线原型，交由 Claude Mythos Preview 内部早期版本重写后，未追加指令的情况下内存占用降至原来的 1/20、速度提升 4 倍，并保留了摄取顺序与数据结构的全部隐含约束。参与项目的工程师自评 Claude 的写代码能力已强于自己，人工审查的职责转向审核变更意图；官方举例称工程师的职责很多时候是对 Claude 说「不」，阻止智能体为满足局部模式而违反系统级约束。
3. 存储侧：Scion 把 Git 换成集中式服务
3.1 单体仓库的规模压力
据 10 月 13 日官方博客披露，Anthropic 的 monorepo 主分支历史体积已近 100 GB，压缩后的工作副本超过 25 GB；仅为 CI 每天就要执行约 2500 万次代码检出，这还未计入开发者环境、Agent 沙箱与研究任务，若按常规方式完整拉取，每天将产生超 600 PB 的 Git 流量。高峰期该公司曾运行数百个内部 Git 镜像并配合快照种子缓解压力，但镜像运维成本与历史类操作（diff、blame）的兼容难度随合并量同步上升。官方观察认为，团队实际把 Git 当作「一份权威副本」的集中式系统使用，绝大多数客户端是在线运行的智能体与作业。
3.2 Scion 的设计与实现
Scion 借鉴 Google Piper 与 Meta Sapling 等大型单体仓库方案的经验，核心设计原则包括：客户端始终在线、按需向服务器取数；提交、变基、合并、历史与 blame 查询全部在服务器端完成，客户端只维护有界本地缓存；版本控制查询全部经 API 暴露，作业无需本地仓库即可提问；全组件水平扩展，没有 packfile、无需仓库维护；提交廉价且无锁，成本随变更规模而非仓库整体规模增长；工作副本可选且稀疏。
实现上，Scion 以「变更集」（changeset）为工作单元：变更集写入预写日志，只记录相对第一父提交有改动的文件列表，并以内容寻址指针指向 blob 存储，创建后在服务端即时全局可用。客户端 scn 经 scion-daemon（节点级）、scion-cache（区域级）、scion-server（权威级）三级结构读取对象，三级响应同一套 RPC，官方称各级缓存命中率均超 99%。
3.3 迁移后的官方实测数据
官方博客与配图给出的关键数据如下。
| 项目 | 数据 |
|---|---|
| 日均合并量 | 2026 年 5 月约 2500 次，9 月超 3 万次 |
| Scion 基础设施 CPU/内存占用 | 原 Git 镜像方案的约 1/200 |
| CI 与研究任务代码检出耗时 | 由分钟级缩短至秒级 |
| 仅 CI 释放的 CPU 容量 | 25% |
| Agent 环境新建工作树 | 7.1 分钟降至 5.1 秒（84 倍） |
| 每次变更请求源码控制总耗时 | 34 分钟降至 3.7 分钟，官方折算每天节省约 1.1 万个智能体小时 |
| CI 作业检出 | 31 秒降至 3.5 秒，官方折算每天节省约 19.5 万机器小时 |
开发者环境中原生 Scion 仓库的命令中位耗时对比（Git 对 scn 客户端）：
| 命令 | Git | scn | 提速 |
|---|---|---|---|
| Status | 3.9 秒 | 19 毫秒 | 约 207 倍 |
| Pull latest | 87 秒 | 3.5 秒 | 25 倍 |
| Checkout | 15 秒 | 1.1 秒 | 14 倍 |
| Diff | 407 毫秒 | 67 毫秒 | 6.1 倍 |
| Rebase | 13 秒 | 2.7 秒 | 4.8 倍 |
「约 207 倍」与「约 1/200」均出自官方材料，属于两个维度的指标：前者为官方图表中开发者环境 Status 命令的中位耗时对比（3.9 秒对 19 毫秒），后者为 Scion 与原 Git 镜像基础设施在 CPU、内存占用上的整体对比，两者不构成矛盾。
3.4 官方定位：只适用于超大单体仓库
官方明确表示，Scion 的设计理念只适用于真正巨大的单体仓库，即拥有数万名工程师、或由成群智能体高频产出代码的组织；由于 Scion 与 Git 分歧显著，需要代码审查、代码搜索、CI 全套随迁，Anthropic 内部实现高度定制，难以对外提供通用版本。官方预判这类问题将在未来 6 到 12 个月内变得更普遍，并已公开设计思路供其他团队借鉴，表示愿与 GitHub、GitLab 及开源社区合作。项目由一个 7 人团队在 5 个月内完成构建与整体迁移，同期还交付了代码审查工具 Antique、代码搜索与源码控制 IAM 系统等约六个配套系统。
4. 审查侧：机器读代码，人工按风险介入
4.1 审查哲学的转变
官方在 10 月 15 日博客中给出的判断是：「是否有人读过这段代码」对于「这个变更可能出什么问题、由哪一层检查（自动化或人工）负责接住」来说是一个不精确的代理指标。审查的时点随之改变：过去的审查是路线尽头的闸门，写完代码、开 PR、等同事；现在的审查持续运行，类似写作时的拼写检查，多数变更在被要求人工查看之前，已经由 Claude 审查并修复过至少一轮。
官方为该流程设定的目标是：Claude Code 各仓库（CLI、桌面与网页应用、移动应用）中大多数 PR 在至多一名人类参与的情况下合并，参与者可以是作者本人，同时回退率与事故率不上升。团队追踪的指标包括每 PR 的人工审批数（中位数与 95 分位）、人工评论数、PR 等待人处理的时间；回退率与事故率作为护栏指标，官方表述为「如果这两项上升，说明人类时间只是被挪了地方，并没有省下来」。
4.2 七层防线
一个典型变更从工程师笔记本（或 Slack 里的 Claude 会话）到用户手中，经过七层检查，各层各自接住一部分问题，漏网部分由回滚兜底。
各层要点如下表。
| 层级 | 机制 | 关键细节 |
|---|---|---|
| 变更前自验证 | Claude 跑测试、构建与 linter，第二个 agent 以全新上下文审查 diff | Claude Code 创建者 Boris Cherny 称让 Claude 能验证自己的工作「可能是最重要的事」，估计能让最终结果好两到三倍 |
| 必需 CI | 多平台 lint、类型检查、测试、构建与打包，红即阻断 | 一个典型 CLI PR 在任何人查看前要跑数十项检查 |
| AI 代码审查 | 多个 agent 并行找 bug，另一组 verifier 对每条发现投票，达到共识才发布，按严重程度排序 | 研究预览上线时，获得实质性审查意见的内部 PR 份额从 16% 升至 54%；超 1000 行的 PR 多有发现，小 PR 多数通过；仓库可配置 Quick/Standard/Deep 三档深度 |
| 独立安全审查 | 单独一轮自动化安全审查，存在未关闭发现时阻断合并 | 可用 /security-review 命令或开源 GitHub Action 复现 |
| 风险分级人工审批 | 分类器读取变更内容定级，决定需要零名、一名或两名人工审批 | 见 4.3 节规则 |
| 合并队列与灰度发布 | 队列在最新 main 上重跑全部检查；新功能先挂 flag 供 Anthropic 员工内部使用，再走 latest 渠道，stable 渠道跟进 | 内部重度使用常在用户之前暴露回归 |
| 快速发现与回滚 | flag 无需部署即可关闭；每周 on-call 轮值；事故复盘追问哪一层应当接住 | 官方承认尚未有随指标收紧审批的「熔断」机制，内部工程师希望在更多变更走向零人审批之前先有熔断 |
AI 审查的产出规则包括：发现按 Important、Nit、Pre-existing 三类标签区分，PR 未引入的旧问题不会算到作者头上；风格、诊断、清理类意见在过滤器中被丢弃（过滤器先在官方自己的 PR 上做了 A/B 测试）；每条发现必须被回应——修复，或给出理由关闭线程；常见情形是 agent 在夜间接手修复，作者回来时 PR 已又过了一轮。
4.3 风险分级与审批规则
人工审批按风险分档，分级由变更内容决定，与作者身份无关。
| 风险档 | 覆盖范围 | 人工审批要求 |
|---|---|---|
| 低 | 文档、文案、仅内部使用的功能、flag 后的增量变更 | 自动化审查与安全检查全绿后可零人审批 |
| 中 | 常规产品变更，以及缓存、自动更新器、系统提示词等敏感区域 | 一名人工审批 |
| 高 | 最高风险代码，外加一小部分永远需要两人的路径 | 两名人工审批 |
官方披露的配套规则有五条：第二分类器会复核「这条例外变更是否即便定级不需要也应加一名人」；代码所有者列为敏感的路径与任何 CI 工作流文件永远需要人；只有仓库可信名单上的作者（以团队自身为主）可走轻量审批路径；agent 的审批在任何情况下都不计入人工名额；在 agent 写的 PR 上，指挥 agent 的人视同一名必需审查者，与其亲手写代码同等担责。此外，一次审批只覆盖一个具体提交，若有系统无法背书的新提交进入（如 agent 的推送、人工解决的合并），审批必须重新给出。
4.4 收敛、评估闭环与人的位置
机器互审带来一个新问题：收敛。agent 作者与 agent 审查者可以让对方无限忙碌——官方记录了一个 CLI PR 过夜经历五十多轮审查与修复后才被作者叫停的案例。用 git blame 回查审查者反复标记的内容，约 59% 在第一轮审查时就已存在，审查者极少发现新 bug，每轮只是多找出一些旧问题。团队据此调整了重审策略：三轮后上限触发，要求作者退一步重新考虑方案；前几轮之后只重审新增 diff；要求按 bug 类别标记以便作者一次修复所有实例；已发布过的发现不再重复。收敛改造后的内部数据为：一轮审查加一轮修复即通过的 PR 从 65% 升至 78%，需要五轮以上的 PR 从 8.9% 降至 1.5%，通过所需平均审查轮数从 2.08 降至 1.32。
审查器本身以评估闭环持续改进：团队把引发事故的历史 PR 连同修复与回退收集起来，由熟悉对应代码的工程师逐条确认 bug 与位置，构成每日运行的评估集；审查器的提示词、工具或模型每次改动都要在全集上重新评分，分数上升才保留。噪音治理同样量化：每条审查意见按作者的实际反应归类（修复、指出错误、说明属有意行为、判定无关），并在已知干净的 PR 上运行审查器统计误报。
人的位置收敛到五类机器不擅长的决策：要不要做这件事（方向、品味与范围）；高风险代码（计费、自动更新器、CI 工作流）；会被他人效仿的架构决策；阅读证据（测试输出、命令返回、截图与审查发现）；以及为每个上线变更承担结果。官方明确表示，产品形态的 Code Review 只发布发现、不代作批准，批准 PR 仍是人的决定；内部仓库走得更远，允许所有者决定哪些低风险变更仅凭自动化检查合并，官方称这条线在持续移动。
团队协作层面，「谁落地、谁负责」（You land it, you own it）是成文规范：中小型变更出问题通常由落地者修复，支撑条件是变更足够小、一切可逆（flag、回退、分阶段发布可在几分钟内撤销大部分错误）、爆炸半径决定检查强度、回归经遥测与内部使用快速浮出；事故复盘只看系统、不做追责。对于审查的第二项职责——建立共同理解——官方的答案是团队中无人保留 Claude Code 的完整心智模型，需要理解某段代码时让 Claude 现写一份对应切片的讲解材料，用时几分钟且反映代码现状。
5. 体验侧：把等待时间当指标经营
5.1 claude.ai 两周三倍：一次完整的性能冲刺
9 月 23 日博客披露，2026 年 8 月的一次为期两周的冲刺把 claude.ai 与桌面端核心体验提速约 3 倍。Claude 通过 Datadog MCP 分析用量数据，圈定占用户活动 95% 的四条旅程（启动应用、发起对话、加载会话、发送消息），在网页与桌面之间拆出 13 项测量；原计划约 20 个项目，第三天就完成了 13 项目标中的 12 项。整个冲刺在单一 Slack 频道中运行，同时并存的线程超过 150 个，两周合并超过 3000 项变更，未发生一起面向用户的事故或回滚；期间引入近 200 个 feature flag，过半在冲刺结束前清理完毕。
部分 p75 实测数据如下。
| 用户旅程（p75） | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| claude.ai 网页全新加载 | 3085 毫秒 | 550 毫秒 | 5.6 倍 |
| 桌面端冷启动 | 6310 毫秒 | 3328 毫秒 | 1.9 倍 |
| 发起新对话（Claude Code 桌面端） | 837 毫秒 | 347 毫秒 | 2.4 倍 |
| 加载会话（Claude Cowork 桌面云端） | 2566 毫秒 | 728 毫秒 | 3.5 倍 |
| 发送消息（Claude Cowork 桌面云端） | 928 毫秒 | 48 毫秒 | 19 倍 |
| 发送消息（Claude Code 桌面端） | 250 毫秒 | 52 毫秒 | 4.8 倍 |
方法论上，官方把「可测量」放在首位：墙钟时间噪声大，毫秒级波动不足以做 CI 门槛，团队改用确定性指标——Valgrind 配合 node --predictable 统计 JS 指令数、React 提交次数、样式重算次数、DOM 变更数——每项新基准都要先证明与真实延迟相关，否则废弃。一个典型案例：消息树组装例程中每个消息 ID 被解析三次，指令数削减 48% 后墙钟时间下降 78%；另一案例中，回复的 markdown 含 em dash 等非 Latin-1 字符会让 V8 把整串按 UTF-16 存储并拖慢全部语法高亮正则，修复后页面首个代码块的高亮耗时从 1.0 秒降至 0.35 秒。冲刺还把流式渲染推到 120Hz 帧预算（每帧 8.33 毫秒），单个线程落地近 60 个 PR，长回复对主线程的总阻塞从约 750 毫秒降至约 200 毫秒；官方账号同步宣布长答案流式平滑度提升约 4 倍、慢速笔记本上的卡顿减少 9 倍、最长单次冻结缩短 4.5 倍。
5.2 Claude Code 等待时间与传输优化
2026 年 10 月中旬，官方公布了 Claude 产品 8 月至 10 月的等待时间对比（口径为首个 token 出现前、扣除模型推理耗时的等待，p90 分位，重点覆盖较慢请求）：Claude Code 本地从 4.07 秒降至 1.33 秒，云端会话从 16.99 秒降至 6 秒，Claude 聊天与 Cowork 从 3.36 秒降至 2.17 秒。此组数据经中文科技媒体报道转述，截至发稿官方英文原始出处未能直接核验，引用时请注意口径。
上述三项对比数据来自媒体转述的官方口径。官方一手可核验的是 Claude Code v2.1.300 更新日志条目：发往 api.anthropic.com 的大请求在遥测关闭时也启用 gzip 压缩，可用环境变量 CLAUDE_CODE_GZIP_REQUEST_BODIES=0 关闭；压缩让每轮对话数据更小、更快到达模型。云端会话侧的配套优化是在用户开始输入时提前启动会话准备，无需等待按下发送。
6. 关键数据汇总
| 维度 | 指标 | 数值 |
|---|---|---|
| 写作 | Claude 编写 Claude Code 代码占比 | 约 90% |
| 写作 | Claude Code 仓库合并 PR（6→9 月） | 翻倍以上 |
| 写作 | 需回退 PR 份额（6→9 月） | 下降超 40% |
| 写作 | monorepo 日变更量（5→9 月） | 约 2500 次增至超 3 万次 |
| 存储 | monorepo 主分支历史体积 | 近 100 GB |
| 存储 | 每日 CI 代码检出次数 | 约 2500 万次 |
| 存储 | Status 命令中位耗时 | 3.9 秒（Git）对 19 毫秒（scn） |
| 存储 | Scion 基础设施 CPU/内存占用 | 原 Git 镜像方案的约 1/200 |
| 审查 | 获实质性审查意见的内部 PR 份额 | 16% 升至 54% |
| 审查 | 一轮通过的内部 PR 份额 | 65% 升至 78% |
| 审查 | 通过所需平均审查轮数 | 2.08 降至 1.32 |
| 审查 | 低/中/高风险档人工审批 | 零名/一名/两名 |
| 提速 | claude.ai 等 13 项旅程平均提升 | 3.1 倍（几何均值，p75） |
| 提速 | 性能冲刺两周合并变更 | 超 3000 项，零用户可见事故 |
| 提速 | Claude Code 本地等待（8→10 月，p90） | 4.07 秒降至 1.33 秒（媒体转述口径） |
| 提速 | Claude Code 云端等待（8→10 月，p90） | 16.99 秒降至 6 秒（媒体转述口径） |
7. 行业观察
- 开发者基础设施成为智能体规模化的第一瓶颈。三份材料共同指向一个顺序：当写入量放大 10 倍以上，先崩溃的是源码控制与 CI，然后才是人的审查带宽。Anthropic 选择为「客户端始终在线」的智能体重建集中式源码控制，并公开预判同类压力将在 6 到 12 个月内扩散到更多组织，这一时间表可供计划智能体流水线的团队对照。
- 审查质量有了可守门的量化指标。官方流程中，回退率与事故率是护栏，人工时间是被优化目标，两者绑定设计避免了「省下审查时间、赔进排障时间」的空转。审查哲学的落点是：逐层指派责任（每层接住一部分问题），漏网交给分钟级回滚，而非要求单点完美。
- 责任模型为智能体协作提供了可参考的成文规则。指挥 agent 的人视同审查者、审批绑定具体提交、机器人审批永不顶替人工名额、敏感路径永远需要人——这四条规则把「AI 写的代码算谁的」从讨论题变成了流程条款，可供引入 agent PR 的团队直接借鉴。
- 收敛问题是机器互审特有的新工程问题。过夜五十轮审查、59% 重复旧发现的数据说明，agent 作者与 agent 审查者的组合需要轮次上限、diff-only 重审与发现去重这类机制约束，这类改造与具体模型无关，可移植性强。
- 性能优化的方法论增量在于「先造尺子」。官方把确定性指标（指令数、提交数、重算数）做成 CI 棘轮，让 agent 在实验室里自我验证、墙钟数据只做事后确认，两周 3000 项变更零事故的成绩建立在此之上。对普通团队的门槛在于：这套玩法要求指标基建先行，官方也在 10 月 15 日博客末尾给出了从 CLAUDE.md、REVIEW.md 到合并队列的分阶段落地清单。
- 官方自评口径需要保留的空间。本文引用的数字全部来自 Anthropic 官方博客与更新日志，属一手但属自我报告；零人审批的边界仍在移动，官方自己的工程师也提出应先有熔断机制再扩大零人审批范围。此外，5.2 节 p90 对比数据暂以媒体转述口径为准。
举手提问