一句话定义：修复缺口（Remediation Gap）指的是安全工具发现问题的速度，与组织实际修复、验证并发布补丁的速度之间的系统性落差；积压下来的未修漏洞，就是常说的补丁债（patch debt）。
打个比方：仓库装了一百个摄像头，却只有两个维修工。摄像头秒级报警，谁都能看到哪扇窗没关、哪盏灯不亮；维修工得爬梯子、订货、等审批、挑不影响发货的时间动手。一天过去，报警单堆了一摞，仓库并没有更安全——只是更清楚自己有多不安全。AI 审查与漏洞扫描扮演的正是那批不知疲倦的摄像头。
关键在于两边性质不同。发现问题是并行、可自动化、边际成本极低的：代码仓库多挂一个扫描器，报告就多一摞。修复却是串行的，要人改代码、跑测试、过变更评审、灰度发布，还要判断“这条告警在业务里到底算不算事”。于是缺口大致等于“发现速率 × 时间 − 修复吞吐”，前者被 AI 拉高一个数量级，后者几乎原地踏步。
这个缺口还会被三件事放大。一是误报与低价值告警混在真实风险里，模糊了排序，让人先累、后麻木。二是上下文缺失：工具能标出“某依赖有已知漏洞”，却不知道这段代码根本不走那条路径。三是可见性本身带来的压力：报告一旦生成，未修项就成了“已知问题”，审计和合规看得见，责任也就落下了。
| 相邻概念 | 关注点 | 与修复缺口的关系 |
|---|---|---|
| 技术债（technical debt） | 代码与设计的长期维护成本 | 更宽泛，补丁债是它在安全维度的分支 |
| 漏洞管理（vulnerability management） | 发现、分诊、修复、验证的闭环 | 修复缺口就是闭环里“修复”环节的产能不足 |
| 平均修复时长（MTTR） | 单条问题的处理速度 | 缺口看整体积压规模与积压项的中位年龄，不只看平均值 |
| 告警疲劳（alert fatigue） | 人的注意力被消耗 | 是缺口的心理表征，根因仍是修复产能 |
对从业者，实际意义有三点：一是别把“扫出多少条”当成绩，改看“每周关闭多少条”“积压最久的那批有多老”；二是降低修复成本比提高发现精度更划算，例如自动生成修复补丁、依赖自动升级、默认安全配置，把人工判断留给真正需要判断的少数；三是把安全修复并进日常发布节奏，而不是攒到季度“大扫除”，因为冻结窗口后的集中修复最容易出错。对普通职场人，你只会收到越来越多的“请升级、请修复”通知，按“是否可被利用、影响范围多大”分诊，别被数量淹没；采购工具时也不妨多问一句：修复侧它能帮上多少忙？
AI 让发现变得便宜，只有当修复也变便宜，缺口才会真正收窄。