AI Code Review 误报治理实战

AI Code Review Workflow 搭建指南讲了怎么把评审流程跑起来，但真正决定这套流程能不能长期用下去的，是跑起来之后的误报治理。团队接入 AI Review 的典型曲线是：第一周惊艳（抓到好几个真 bug），第二周开始有人抱怨”又在瞎说”，第三周有人开始无脑点 resolve 不看内容。本文只讲误报治理这一件事：怎么量化、怎么分类、怎么建立能持续改进的闭环。

一、先量化，再治理

“感觉误报有点多”是没法优化的，必须先有一个可追踪的指标。最简单的量化方式是让评审者在 resolve 评论时打一个标签：

# PR 评论的 resolve 动作绑定一个反馈标签
RESOLVE_REASONS = {
    "fixed": "确实是问题，已修复",
    "acknowledged": "是真问题，但本次不改（记录了技术债）",
    "false_positive": "AI 理解错了，不是问题",
    "not_applicable": "规则不适用当前场景",
}

把这些标签写入一张统计表（哪怕只是一个 CSV 或者飞书多维表格），按周跟踪：

周	评论总数	fixed	acknowledged	false_positive	not_applicable	误报率
W1	42	28	6	5	3	11.9%
W2	38	19	4	12	3	31.6%
W3	35	21	5	6	3	17.1%

误报率的定义是 false_positive / 评论总数。这个指标本身不需要追求 0——AI review 的价值是”覆盖面广、成本低”，完全消灭误报意味着评审规则过于保守，会漏掉真问题。实践中把误报率控制在 15-20% 以内，团队通常能接受；超过 30%，评审意见会被系统性忽略，治理就失效了。

二、误报的四种典型模式

从多个团队的实践看，AI Code Review 的误报集中在四类模式，每类的成因和修复方式都不同：

模式一：缺乏项目上下文的”正确但无关”建议

AI 指出的问题在通用意义上成立，但项目里有意为之（比如某个”未处理的 edge case”其实是上游已经保证不会发生）。

修复方式：维护一份”已知设计决策”清单喂给 prompt，明确告诉模型”这些模式是有意为之，不要重复提出”：

项目已知设计决策（评审时不要对以下模式提出异议）：
- src/legacy/ 目录下的代码遵循旧规范，不评审风格问题
- 所有 API handler 的输入已经在网关层做过 schema 校验，handler 内部不需要重复校验
- 数据库连接池由框架统一管理，不需要在业务代码里评审连接释放

模式二：跨文件上下文缺失导致的误判

AI 只看到 diff 里改动的文件，看不到调用方或者被调用的其他文件，容易对”看起来有问题但结合上下文是对的”代码提出异议。

修复方式：评审 prompt 里加一步”如果需要更多上下文才能判断，先列出需要看哪些文件，而不是直接下结论”，配合工具调用能力让模型主动去读取相关文件再给结论，而不是仅凭 diff 片段猜测。

模式三：过时规则集导致的重复误报

团队规范变了（比如放宽了某个 lint 规则），但评审 prompt 里的规则集没同步更新，AI 持续按旧规则挑刺。

修复方式：把评审规则和项目的 lint 配置文件绑定读取，而不是把规则硬编码在 prompt 里——这样规则源头只有一份，不会出现”实际规范已改，AI 还在用旧规范”的滞后。

模式四：过度泛化的”最佳实践”建议

模型倾向于套用通用最佳实践（比如”建议加日志”、“建议加类型注解”），但这类建议和当前 PR 的实际风险无关，纯粹是模型的默认倾向。

修复方式：prompt 里明确限定评审范围为”本次 diff 引入的新问题”，并要求每条评论必须能回答”如果不改这里，会导致什么具体的错误或维护成本”，答不出具体后果的建议一律不输出。

三、抑制清单机制

除了改进 prompt，还需要一个运行时的抑制清单机制，处理”已经反复出现且明确是误报”的情况，不用每次都指望 prompt 调整生效：

class SuppressionRule:
    def __init__(self, pattern: str, file_glob: str, reason: str):
        self.pattern = pattern      # 匹配评论内容的关键词或正则
        self.file_glob = file_glob  # 适用的文件范围
        self.reason = reason        # 记录为什么抑制，便于日后审计

SUPPRESSION_LIST = [
    SuppressionRule(
        pattern=r"建议添加输入校验",
        file_glob="src/handlers/**",
        reason="handler 层输入已在网关校验，2026-07-15 团队决议不重复评审"
    ),
    SuppressionRule(
        pattern=r"connection.*not closed",
        file_glob="src/db/**",
        reason="连接池框架托管，2026-06-20 确认"
    ),
]

def should_suppress(comment: str, file_path: str) -> bool:
    import re, fnmatch
    for rule in SUPPRESSION_LIST:
        if fnmatch.fnmatch(file_path, rule.file_glob) and re.search(rule.pattern, comment):
            return True
    return False

抑制清单必须定期复审（建议每季度），因为抑制规则本身可能过时——比如”连接池框架托管”这条，如果半年后框架升级不再自动管理连接，这条抑制规则就会变成隐患，遮蔽真实问题。每条抑制规则都记录了决策日期和理由，复审时直接按日期排查。

四、反馈闭环：让治理可持续

误报治理不是一次性的 prompt 调优，而是需要一个持续运转的闭环：

每周评审数据回顾
    ↓
识别当周误报率最高的 3 类模式
    ↓
按模式类型决定修复路径：
  - 上下文缺失 → 补充"已知设计决策"清单
  - 规则过时 → 检查规则源是否和 lint 配置同步
  - 重复出现 → 加入抑制清单
    ↓
下周验证误报率是否下降
    ↓
（若下降）固化改动；（若未下降）重新归类问题模式

建议把这个回顾流程和评审成本控制的月度账单回顾放在一起做——误报率高往往伴随着评审调用量虚高（AI 对同一段代码反复评论同样的误报），两个问题经常同源，一起复盘效率更高。

五、什么时候该承认”这类代码不适合 AI 评审”

治理到一定程度会遇到收益递减——某些代码类型（比如高度依赖业务领域知识的规则引擎、需要理解外部系统契约的集成代码）无论怎么调 prompt，误报率都压不下去。这种情况下，更现实的做法是把这类路径直接排除出 AI 评审范围，只保留人工评审，而不是无止境地投入治理成本追求一个不现实的误报率目标。