九成代码自己写、大部分自己审：质量只看几个结果型信号
一、把关的对象换了，指标就得换
据公开报道，某厂商披露其编程智能体约九成代码由自身生成、大部分审核由 AI 完成，数月内合并的改动请求量翻倍、回滚率下降四成余，团队把回滚率与事故率当核心指标，并搭了多层代码检查体系。这里的”九成””翻倍””四成余”只作背景引用，本文的一切判断都不建立在它们之上；我们关心的是这句话里被换掉的东西：把关的依据从”有人逐行看过”换成了”能不能回滚、有没有出事故”。
这个替换带来三个结构性变化，每一个都会改变指标的含义。
第一，作者与审校者同源。同一个模型写、同一个模型审，两者的错误分布是相关的，审校通过的置信度不再等价于独立复核。第二，变更粒度变小、数量变多，单条改动值得投入的注意力被摊薄，评审从”读实现”被迫转向”读标准与证据”。第三，人对代码的责任形式从”我读过”变成”我验收过”，于是验收标准本身成了质量的瓶颈。
结论很朴素：过程型把关退到抽检位置之后，能承担把关责任的只剩结果型信号。问题是每一个结果型信号都有被做漂亮的空间，所以它们必须成对使用，不能单独看任何一个。
二、信号、定义、失真方式与配对指标
下表是我们在评审里反复用的那张表，也是本文的核心交付物。四列缺一不可：只有定义没有失真方式，指标会在半年内悄悄变形；只有失真方式没有配对指标，发现变形之后无从判断。
| 信号 | 定义口径 | 被做漂亮的方式 | 必须配对的指标 |
|---|---|---|---|
| 回滚率 | 触发回滚的发布次数除以总发布次数，按发布而不是按提交计 | 把一次改动拆成多条互不依赖的小提交、或者用向前修复代替回滚，回滚次数就人为变少 | 缺陷逃逸数与平均修复时长；只看回滚率会把”敢回滚”当成问题 |
| 缺陷逃逸 | 按发现渠道分开统计：内部测试、灰度阶段、线上工单、外部报告，各算各的 | 把线上问题在工单系统里改分类成”需求理解偏差”，或者把灰度期问题合并回测试期 | 变更影响面（涉及模块数与是否有数据迁移）；不分开渠道的逃逸数无法归因 |
| 事故率与变更前置时间 | 单位时间内由变更触发的线上事故数；从改动提交到进入生产的时长分布 | 提高发布频率会把前置时间压短，同时把每次变更影响面切小，两个数都变好看但风险转移到了链路复杂度上 | 事故里由”多个小变更叠加”引起的占比；这一项才是频率提高的真实代价 |
| 一次通过率 | 首次进入待发布状态即通过全部门禁且无需返工的改动占比 | 把返工藏在同一条分支上继续提交，不重开状态；或者放宽门禁规则本身 | 返工轮次分布与门禁失败原因分布 |
| 门禁拦截数 | 各层门禁拦下的问题数量 | 门禁调松之后拦截数下降会被解读成”代码质量变好” | 逃逸数与门禁规则的改动记录；两条曲线要放在同一时间轴上看 |
| 告警噪声 | 触发后被判定为无需处置的告警占比 | 直接调高阈值或关掉一类告警，噪声立刻消失，同时把真问题也关掉 | 事故发现渠道中”由告警先发现”的占比 |
有两条使用纪律。一是所有比率都要给出分母的原始计数，只看百分数就无法发现”拆提交”这类操作；二是指标的定义变更必须留变更记录，任何一次口径调整都要能在曲线上看到锚点，否则日后没人能解释那条下降的线是质量变好还是统计变严。
三、分层门禁各自拦什么
多层检查的价值不在层数多，而在每层只拦它擅长的那一类问题，避免所有层都在拦同一件事、所有层都漏掉同一件事。
- 语法与构建：拦不可编译、格式不合规、依赖解析失败。它的判据必须是二元且零容忍。
- 单元测试与契约测试：拦模块内部的逻辑错误和接口约定的破坏。契约测试单独一层，因为跨服务的字段与错误码变化最容易被漏。
- 静态分析与危险模式：拦资源未释放、并发访问、注入拼接、异常吞噬这一类模式问题。
- 类型与接口一致性：拦签名漂移、可选字段变成必填、序列化两端不匹配。
- 安全扫描与依赖检查：拦已知漏洞版本、密钥与凭据落库、越权调用面。这一层的失败要能阻断合并，不接受”记入基线下次再改”。
- 数据迁移与兼容：拦迁移脚本不可回退、新旧版本双读双写窗口被破坏。它是所有层里唯一一旦失手就只能靠恢复流程救的。
- 性能基线抽检：拦明显的复杂度回退与容量假设被打破。抽检即可，每次都跑全量会让门禁时间成为新的瓶颈。
- 人工介入：只出现在高风险面上——不可逆操作、涉及资金的链路、对外承诺的接口、以及迁移与数据兼容这一层的评审。
这张分层里最容易失守的不是某一层没配，而是层级之间的责任重叠：静态分析和安全扫描同时报同一类问题，两套豁免清单互相不认识，最后同一个规则在一层被关掉、在另一层还开着，谁也不知道合不合。豁免状态要以规则为单位统一存放，而不是每层各存一份。
四、改动请求量上升之后真正变的是哪几件事
改动数量上升不是”评审压力大”这么简单，它改变的是约束的位置。
评审粒度换了对象。逐行读实现变得不可持续，评审者读的是三样东西：验收标准是否可执行、证据是否覆盖了标准、以及这条改动如果出错能不能单独撤回。标准写得含糊，评审就会退化成”看起来没问题”。
需求描述成为瓶颈。当实现环节不再是慢的那一环，模糊需求带来的返工会成比例放大：同一份含糊描述会被解释成多个不同实现，每个都能通过全部门禁，但没有一个符合提出者的意思。这类返工在指标上表现为一次通过率下降，而不是缺陷逃逸上升，所以要把”返工原因”作为必填项统计出来。
可回滚性从运维话题变成设计约束。能不能单独撤回、有没有开关、数据改动是否可逆，要在方案阶段就被问，因为它决定了回滚率这个指标是否可被接受。与之配套的还有第二个约束：错误必须能被解释，评审者需要看到证据链而不是结论。
发布频率与灰度粒度必须一起动。改动数量上升而灰度批次不变，等于把同一批风险集中放大了；批次上升而观测窗口不变，则会出现多个变更同时生效、事故无法归因。这两件事的顺序是：先定观测窗口，再定批次上限。
五、”自审”这件事要怎么做才可信
如果审校环节由模型承担，那它的可信度本身要当成一个被测对象来设计，有四条底线。
审校者不能与被审者共用同一份上下文。同一段提示、同一份中间推理被两边共享时，审校只是重复了一次生成，而不是独立检查。做法上至少要把输入换成经过改写的形式：只给差异、给约束清单和验收标准，不给生成时的推理过程。
抽检比例与错误率要回填。人工按固定比例抽审，抽出来的错误率要回灌成审校环节的指标，并且按改动类型分开统计。全局错误率会把”迁移类改动审得很差、格式化改动审得很好”这两种情况抹平。
审校结论要留下可核对的差异行。只报”通过”或”有问题”没法复核；必须能指出具体位置与判断依据，人工抽检时才有一致性可比。这一条也是把审校从一句话变成一份记录的成本最低的做法。
审校的判定规则要版本化并有变更通知。审校规则一改，一次通过率与缺陷逃逸会出现台阶，没有版本记录就会被误读成质量突变。
至于人的位置，本文不作价值判断：人工评审没有被取消，它的位置从”每处必经”移到了”抽检与高风险面”。移动之后要求更高，因为人只看少数样本，样本选错就意味着整块区域无人看守。抽检样本要按风险面配额分配，而不是随机抽取。
六、从两条基线开始，而不是从层数开始
洹拓科技接手这类改造时的顺序是固定的：先建两条基线，再谈门禁层数与工具选型。
第一条是回滚基线。把过去若干次发布的回滚事件按原因分类存下来，标出哪些是”能回滚所以回滚”、哪些是”回滚不了只能向前修”。第二类的存在会让回滚率指标系统性偏乐观，不先量化它，后面所有改善都可能是统计噪声。
第二条是缺陷逃逸基线，按发现渠道分开。这条基线的价值在于它不依赖改动量：无论提交数怎么变，线上工单与外部报告的数量与严重度都在同一个位置计量。
有了这两条，才去补门禁分层与配对指标。反过来先上一堆门禁层，指标一片绿灯，实际效果无法验证，半年后既不敢撤层也不敢加层。
最后一句立场：这套指标体系的目标不是证明自动生成的代码质量如何，而是让”质量下降”这件事能在被线上感知之前先在表上看见。能不能看见，取决于定义有没有写死、配对指标有没有一起画在同一张时间轴上。剩下的，才是工具与层数的问题。