为应对 AI 生成代码变更的激增， 对 Code 团队的代码审查流程进行了重构。据官方披露，今年 6 月至 9 月，合并至 Code 代码库的拉取请求（PR）数量翻倍，而需要回滚的比例下降超过 40%。

这种压力波及整个 单仓库（）。其每日代码提交量从 5 月的约 2,500 次飙升至 9 月的 多次。尽管 Code 拥有独立代码库，但同样面临巨大挑战。在如此高速迭代下，人工逐行审查变得 " 极其困难，甚至不可能 "。团队在建立高覆盖率审查机制后，转而优化人类审查时间，旨在最小化回滚或事故风险。

AI 预审与分级审批

目前，每个 PR 在由人类查看前，均先经过 模型审查。该模型将代码差异与整个代码库及 PR 既定意图比对，检查更改是否解决问题、符合规范或破坏其他功能，并对错误修复追溯根本原因。

"Code for Code" 公开版已在 Team 和 计划中全面开放，本地可通过 /code- 命令运行简化版。在研究预览阶段，内部 PR 获得实质性审查意见的比例从 16% 跃升至 54%。

人类审批介入程度依风险等级而定：文档、文案及带开关标志的增量更改，在通过自动化审查和安全检查后无需人工批准；普通产品更改需一人审批；最高风险代码需两人审批。风险分级基于更改内容而非作者身份，代理程序的批准不计入人工审批。若错误审查或独立自动化安全审查中发现的问题未解决，PR 将无法合并。

自研工具链与历史回溯

为处理庞大代码量， 还重构了源代码控制系统。公司自研了版本控制系统 Scion 及代码审查工具 。一个七人小组在五个月内完成了从 Git 到单仓库的全面迁移，并构建了这两个系统及另外六个相关系统。如今，该团队虽仍负责审查 Scion 的每个变更请求，但重点已从阅读每一行代码转向审视变更意图。

此前曾漏放 Bug。在 4 月 23 日关于 Code 质量投诉的事后分析中，公司将问题归因于三项独立变更，这些变更均在 v2.1.116 版本（4 月 20 日发布）中得到修复。其中一项缓存错误导致系统清除了非活跃会话的早期推理结果，该错误曾通过多轮人工和自动化审查。回溯测试显示，在获取完整上下文所需的代码仓库后，Opus 4.7 发现了该 Bug，而 Opus 4.6 未能发现。 表示，正为代码审查增加对更多仓库的支持，以提供更丰富的上下文信息。

【星途科讯 图文丨小林 首发于 ZAKER 科技，转载请注明出处】