Git被换掉，LLM被替代：AI编码倒逼工具链重构

当 AI Agent 以远超人类的速度产出代码，那些为人类开发节奏设计的工具链开始显现结构性裂缝。Anthropic 用 7 名工程师、5 个月时间重写了一套版本控制系统 Scion 并迁移核心仓库；GitHub 把密钥扫描中的通用 LLM 换成微调后的 ModernBERT；哥伦比亚大学与 Google DeepMind 等机构则用 BTTF 把芯片仿真波形转成 SQLite 数据库。三件事指向同一个结论：AI 写代码的狂飙，正在倒逼整条软件工程流水线重做一遍。

一、Git 的离线自治，为何成了 AI 时代的负担

当检出次数从千级跃升到千万级

Git 的分布式设计让工程师克隆仓库后断网也能提交、合并、查看历史，这套模型支撑软件开发二十多年。但 Anthropic 面临的是另一种负载：今年 5 月每天平均合并约 2500 项代码变更，到 9 月已超过 3 万项，CI 系统每天要执行约 2500 万次代码检出。

这些检出大多来自始终联网的 CI 作业和运行几分钟便销毁的 Agent 沙箱，它们可能只需要几个文件、一份 diff，或确认两个提交的祖先关系。为这类操作准备本地仓库，重复成本被无限放大。Anthropic 主分支历史接近 100 GB，压缩工作副本超过 25 GB。若每天 2500 万次检出都获取完整副本，理论流量会超过 600 PB。浅克隆、稀疏检出、快照和数百台 Git 镜像能缓解一时，但镜像要同步、快照会过期、历史查询仍需补齐对象，仓库越活跃，维护成本越高。

浅克隆与稀疏检出是 Git 为缓解大仓库负担提供的两种机制。浅克隆（shallow clone）通过 --depth 参数只拉取最近若干次提交，丢弃更早的历史对象，从而大幅缩小传输体积；稀疏检出（sparse checkout）则允许工作区只展开指定目录或文件模式，其余路径不写入磁盘。二者常被 CI 组合使用，以“只取所需”的方式降低单次检出的成本。但它们都是局部优化：浅克隆无法回答跨历史的 blame 或祖先关系查询，稀疏检出仍要求本地存在完整的对象数据库，一旦需要补齐缺失对象，就会触发额外的网络往返。在每天数千万次检出的负载下，这些补丁式手段的边际收益迅速衰减，这正是 Anthropic 选择重建协议而非继续调参的背景。

Scion 的取舍：放弃离线，换回在线效率

Scion 将客户端缩成轻量入口，提交创建、合并、变基与历史查询放到中心服务，本地仅监测文件变化、维护少量缓存，需要工作目录时按需展开。CI 若只想计算 diff，可以直接调用 API，无须完整检出。

提交格式也随之改变：Git commit 指向描述仓库状态的目录树，Scion 的 changeset 则以预写日志条目记录相对首个父提交修改过的文件，通过内容寻址指针引用数据。创建 changeset 无须生成 Git packfile，只有 main 等引用更新时才对 Spanner 中的单行记录执行 compare-and-swap，把并发竞争集中到分支引用移动的瞬间。

历史查询是更难的部分。增量记录无法直接回答某行是谁改的、文件经历过什么，Scion 为 blame、路径历史与提交图跳表维护 derived data，让写入与历史分析可以独立扩展。对象写入后不可变，缓存能跨任务复用，Anthropic 称缓存命中率超过 99%。迁移后，Scion 相较旧 Git 镜像体系的 CPU 和内存需求约缩小 200 倍，检出从分钟级降至秒级，CI 释放约 25% 的 CPU 容量。

这个 200 倍说的是基础设施资源占用，并非 Git 操作整体提速。Anthropic 还同步建设了 Antique 代码评审、源码搜索、IAM 和批量合并工具来适配新协议，在线服务本身的维护也成了新成本。

内容寻址存储（content-addressable storage）指以数据内容的密码学哈希作为其标识符的存储模型，Git 的 blob、tree、commit 对象均属此类。Scion 的 changeset 通过内容寻址指针引用文件数据，意味着相同内容只存一份、写入后不可变，因而可以安全地在任务之间复用缓存。与之配合的 compare-and-swap（CAS）是一种乐观并发控制：更新前先校验目标记录的当前值是否仍等于读取时的旧值，相等才写入，否则重试。Scion 把引用更新收敛为对 Spanner 中单行记录的 CAS，使并发冲突只发生在分支指针移动的瞬间，而非整个提交过程。这两项机制共同支撑了文中“缓存命中率超过 99%”与“写入与历史分析可独立扩展”的表述。

二、波形变 SQL：让 Agent 能真正追查芯片故障

几十 GB 的物理文件装不进上下文

芯片验证面对的是另一种障碍。RTL 仿真产生的 VCD、FSDB 波形记录大量信号随时间变化的状态，复杂设计的转储可达数十 GB 甚至 TB 级。工程师可以在波形查看器里沿时间轴寻找异常，Agent 若把原始波形转成文本，上下文很快被时间戳、信号名和重复跳变占满，追查其他信号还要重复读取文件。

BTTF 的思路是把数据访问交给 SQLite：signal_metadata 保存信号名称、类型和层级等静态信息，signal_changes 记录信号 ID、时间戳和变化后的值，两表通过 ID 关联。查询某条信号在指定时刻的状态，SQL 找到该时刻之前最近的变化记录；检查一段时间内的翻转，则按时间窗过滤与聚合。模型只需处理问题与少量返回事件，数据库负责检索，模型决定下一步查什么。

裁剪的代价：185 MB 背后只剩 64% 覆盖率

把波形搬进数据库并不会自动消除压力。高频时钟产生密集记录，逐行 INSERT 又有事务成本，BTTF 在摄取时建立波形标识到数据库 ID 的映射，统计信号跳变，结合时钟过滤、无跳变信号裁剪和批量插入。

实验数据说明了取舍的分量：未裁剪数据库占用 1420 MB，查询约耗时 410.5 毫秒；过滤时钟和无跳变信号后，规模降到 395 MB，耗时降至 94.8 毫秒；若继续删除跳变率低于平均水平的信号，数据库能缩至 185 MB，但活动覆盖率只剩 64.23%。罕见故障可能恰好出现在几乎不翻转的控制信号上，数据在导入阶段被删除，后面的 Agent 就无法恢复证据，裁剪必须服从断言与调试需求。

研究团队在 4.2 GB 波形、18450 个信号和 150 条专家标注查询的实验中取得 95.33% 的执行准确率，Multi-Agent 质量评分比单 Agent 提高 17.3%，平均延迟增至约 1.96 倍，静态 SVA 检查准确率为 84.62%。方案可支持后仿真分析，但持续摄取与复杂归因仍需验证。

VCD 与 FSDB 是芯片仿真的两类波形格式。VCD（Value Change Dump）是 IEEE 1364 标准定义的开源文本格式，逐条记录信号值的变化时刻，可读性好但体积庞大；FSDB（Fast Signal Database）是 Verdi 等商业工具使用的二进制格式，压缩率与读写速度更高，但依赖专有工具链。BTTF 需要先解析这两种格式，把“信号—时刻—值”的三元组抽取出来再写入 SQLite 的两张表。理解这一点有助于判断其工程边界：格式解析的吞吐直接决定摄取速度，而 FSDB 的封闭性意味着方案在开源工具链中的可移植性受限。文中“持续摄取仍需验证”的保留意见，很大程度上正源于此。

三、密钥扫描：从生成式 LLM 退回分类器

高频判断不该承担生成式推理成本

高熵字符串可能是真实凭据，也可能是测试数据、占位符或校验和。正则能快速找到可疑格式，却不擅长判断代码上下文；通用 LLM 能帮助区分，但候选越多，推理费用和延迟越累积。对于必须在代码提交被接受前给出结果的 Push Protection，这种等待直接影响开发体验。

GitHub 保留正则作为候选入口，将后续判断交给微调后的 ModernBERT。它读取候选字符串、密钥类型、变量名、文件路径和附近代码，输出风险分类得分，再由阈值决定是否告警。编码器经过一次前向计算就能返回类别，不需要像生成式 LLM 那样逐 token 输出解释，适合批量处理同类请求。

98% 降本指的是模型服务费

难点在于 hard negatives：字符串很像密钥，却是无害示例。GitHub 将产品反馈及人工标注、真实仓库中的高召回候选、专门合成的困难负样本组合起来，并按仓库、候选值和关联关系划分训练与评估集，减少相似数据带来的评估偏差。模型导出为 ONNX 并进行 8 位量化以降低推理开销，阈值则需结合 Precision、Recall 与线上流量校准。

相较旧 LLM 管线，新方案的离线 Precision 提高 13%，Recall 提高 19%。线上 A/B 实验显示，Post-push 扫描执行时间中位数下降 86%，模型服务成本下降超过 98%，按仓库所有者加权的告警接受指标提高 11.5%。这里的 98% 指模型服务费用，并非整套安全系统的总成本；分类器也只能判断正则找到的候选，前置规则的覆盖范围仍限制漏报表现。

编码器模型与生成式 LLM 在推理模式上有本质区别。以 ModernBERT 为代表的编码器对输入做一次双向前向计算，直接输出分类向量，延迟与输入长度近似线性且可高度批处理；生成式 LLM 则需自回归地逐 token 解码，每个 token 都是一次前向，还要维护 KV 缓存。密钥扫描本质是二分类任务——候选字符串是否为真实凭据——不需要自然语言解释，因此编码器在成本与延迟上占优。ONNX 与 8 位量化进一步压缩了这一优势：ONNX 提供跨框架的统一计算图与运行时优化，8 位整数量化把权重从 FP32 降至 INT8，显著减少内存带宽与算力需求，代价是轻微精度损失，需通过阈值校准来补偿。

四、下一块倒下的多米诺：CI

GitHub 缩短了安全扫描的反馈时间，代码接下来仍要经过构建、测试和部署。Anthropic 在解决源码检出问题后遇到了新麻烦：一轮测试尚未结束，主分支可能又合入数百甚至数千项修改。

继续依赖全局锁会让变更不断积压，放开并发又带来新风险，即便某次测试已经通过，它对应的代码状态也可能与准备部署的版本出现差异。CI 接下来要处理的，是验证结果如何在高频变更中保持有效：构建缓存需要识别源码与依赖关系的变化，测试记录必须关联具体提交和构建产物，系统还要判断哪些结果能够复用、哪些修改会使此前的验证失效。对于依赖关系复杂的 Monorepo，仅靠增加测试机器很难解决并发修改带来的版本一致性问题。

Anthropic 已经开始强化合并后测试与部署前验证。对普通团队而言，先完善依赖分析、增量测试和构建缓存，比直接重建版本控制系统更现实。随着 Agent 持续提高代码产出，软件工程的瓶颈会沿着交付链路向后移动。代码进入主分支的速度可以越来越快，但构建、测试与部署之间必须保留可靠的验证关系。工程基础设施的价值，也将更多体现在能否让高速变化的代码持续获得可信的交付依据。