Codex和OpenCode都支持@codex review自动审PR，prlens/serge走LLM inline comment，AI review和人类review的边界到底怎么划？

目录

一、导语：当"@一下"就能审 PR，边界问题才真正开始

2025 年上半年，GitHub 上出现了一类新的交互习惯：开发者在 Pull Request 评论区敲下 @codex review，几十秒后，一条结构化的评审意见出现在时间线里。OpenCode 等开源实现把同样的触发方式做成了可自托管的服务，prlens、serge 一类工具则更进一步，把模型输出直接映射到具体代码行的 inline comment 上。从交互层面看，AI 评审的门槛已经低到"@ 一下"；但从工程治理层面看，门槛降低恰恰意味着边界问题被放大——当评审意见的供给成本趋近于零，人类评审者的注意力反而成了最稀缺的资源。

笔者在多个团队的代码评审流程中观察到一个反复出现的现象：AI 评审上线初期，团队普遍兴奋于"它能发现我漏掉的问题"；两三个月后，抱怨转向"它说的我都知道"或"它说的不对但我要花时间判断"。这不是模型能力问题，而是分工设计问题。AI 评审的价值不取决于它说了多少，而取决于它说的内容在多大程度上改变了人类的决策。本文试图回答的核心问题是：在现有技术条件下，AI 评审与人类评审的边界应当依据什么原则划分，以及这条边界如何落到可执行的工程参数上。

需要提前说明本文的分析主线：笔者主张用"证据强度 × 可逆性"两个维度来刻画每一条评审意见，而不是用"问题严重程度"这种单一维度。原因在于，严重程度描述的是缺陷本身，而评审分工描述的是"谁来判断这个缺陷"。一个高危但证据确凿的问题（例如硬编码密钥）可以由机器直接拦截；一个低危但证据模糊的问题（例如命名风格争议）反而必须交给人。这条主线将贯穿全文所有章节。

二、背景与问题定义：AI 评审的三代形态与责任真空

2.1 三代形态的演进逻辑

把 AI 代码评审的发展粗略划分为三代，有助于理解当前工具所处的位置。第一代是"静态规则 + 模式匹配"，以 ESLint、SonarQube 的规则引擎为代表，本质是把人类专家的经验编码成确定性规则，优点是零误报可控、可解释，缺点是无法覆盖规则未枚举的语义问题。第二代是"学习型缺陷预测"，以基于代码度量与历史缺陷数据的机器学习模型为代表，典型工作是 2010 年代中期的缺陷预测研究，其局限在于预测粒度粗（文件级或提交级），难以直接转化为行级评论。第三代是"LLM 驱动的语义评审"，即当前 Codex、OpenCode、prlens、serge 所处的形态，它以自然语言生成评审意见，能够覆盖命名、可读性、潜在逻辑错误等前两代难以处理的问题。

本文评述：三代形态并非替代关系，而是叠加关系。当前许多团队的错误做法是用 LLM 评审去替代规则引擎，结果是用高成本、高方差的工具去处理本可由确定性规则零成本解决的问题。合理的架构应当是分层：确定性规则处理可枚举问题，LLM 处理语义与上下文相关问题，人类处理价值判断与责任承担问题。这一分层思想与静态分析领域长期倡导的"多阶段过滤"一致，但在 LLM 时代需要重新校准每一层的职责边界。

2.2 责任真空：工具越自动，责任越模糊

当 AI 评审意见以 inline comment 形式出现在 PR 中，一个微妙的责任转移发生了。传统评审中，每条评论背后都有一个具名的人类评审者，评论被采纳或拒绝都有明确的决策记录。AI 评论则不同：它没有"作者"意义上的责任主体，开发者可以选择忽略而不必解释，也可以盲目采纳而不必验证。笔者将这种状态称为"责任真空"——评审意见的生产与评审决策的承担之间出现了断裂。

这个问题的严重性在合规敏感场景下会被放大。例如金融、医疗行业的代码变更往往需要留痕审计，如果一条 AI 评论指出了潜在问题但被忽略，事后追责时"谁应当为忽略负责"就成了难以回答的问题。笔者认为，解决责任真空的关键不是给 AI 赋予责任（这在法律与伦理上都站不住脚），而是在流程上强制建立"AI 意见—人类决策"的显式映射：每一条被忽略的高置信度 AI 意见，都应当要求人类评审者给出简短理由。这一机制的成本不高，但能把隐性的责任断裂变成显性的决策记录。

2.3 问题定义的三个层次

为避免讨论失焦，需要把"边界怎么划"拆成三个可分别回答的层次。第一层是能力边界：AI 在什么类型的评审任务上可靠，什么类型上不可靠。第二层是流程边界：AI 意见在什么环节介入，是否具有阻断合并的权限。第三层是责任边界：当 AI 意见与人类判断冲突时，以谁为准，如何留痕。三层边界相互关联但不可混为一谈——很多团队争论不休，恰恰是因为把能力问题当成流程问题，或把流程问题当成责任问题。

笔者认为，三层边界中能力边界是基础但最难精确刻画，因为它依赖具体模型、具体仓库、具体任务分布；流程边界是最容易通过工程手段调整的；责任边界则涉及组织文化与合规要求，技术手段只能辅助不能替代。后文的四象限模型主要服务于能力边界与流程边界的联合刻画，责任边界则通过第七节的落地步骤来保障。

三、原理与技术路线：从 diff 到 inline comment 的四段流水线

3.1 上下文获取：评审质量的第一决定因素

LLM 评审 PR 时，输入远不止 diff 本身。一条高质量的评审意见往往依赖四类上下文：变更代码（diff）、变更文件的完整内容、被调用方的签名与实现、以及仓库级的约定（编码规范、架构约束）。Codex 一类托管服务通常通过仓库索引与检索来获取后两类上下文，OpenCode 等自托管实现则依赖显式的上下文拼接策略。上下文获取的完整度直接决定误报率——大量"AI 说这里有问题"的误报，根源是模型没看到调用方已经做了校验。

工程上可操作的参数包括：上下文窗口预算分配（建议 diff 占 30%—40%，完整文件占 30%，依赖签名占 20%，仓库约定占 10%）、检索深度（调用链展开 2—3 层为宜，过深会引入噪声）、以及变更规模阈值（单 PR 变更行数超过 800 行时，建议拆分评审而非强行塞入上下文）。这些参数并非理论推导，而是笔者在多个中等规模仓库（10 万—50 万行）上调试后的经验区间，具体取值需按仓库特点回归校准。

# 上下文预算分配示例（伪配置）
context_budget:
  diff:        0.35   # 变更本身
  full_file:   0.30   # 变更文件全文
  callee_sig:  0.20   # 被调用方签名与关键实现
  repo_rules:  0.10   # 编码规范/架构约束摘要
  reserve:     0.05   # 留给模型输出的余量
max_pr_lines:  800    # 超过则建议拆分评审

3.2 缺陷定位：行级锚定的两种策略

inline comment 的前提是把意见锚定到具体代码行。主流做法有两种：一是让模型在输出中直接给出文件路径与行号，二是让模型描述问题后由后处理模块做语义匹配。前者实现简单但模型容易给出错误行号（尤其在 diff 行号与文件行号不一致时），后者鲁棒性更好但需要额外的匹配逻辑。prlens、serge 一类工具在工程上通常采用混合策略：模型输出问题描述与代码片段，后处理模块用片段匹配定位行号，匹配失败则降级为 PR 级评论。

本文评述：行级锚定的准确性对评审体验影响极大。一条锚错行的评论会让开发者产生"它根本没看懂"的印象，进而降低对全部 AI 意见的信任。因此笔者认为，宁可降级为 PR 级评论，也不要输出高风险的错误行号。这一原则看似保守，但在信任建立阶段至关重要——AI 评审的信任是易碎品，一次明显的锚定错误可能抵消十次正确意见积累的好感。

3.3 评论抑制：从"能说"到"该说"

评论抑制（comment suppression）是当前工具差异最大的环节，也是决定 AI 评审是否"可用"的关键。抑制策略大致分三类：基于置信度的阈值过滤、基于历史反馈的个性化过滤、基于规则的去重与合并。置信度阈值最直接，但 LLM 的自评置信度校准性有限，实践中更可靠的是"多采样一致性"——同一段代码多次采样，只有多数采样都指出的问题才输出。历史反馈过滤则依赖开发者对评论的"有用/无用"标记，逐步学习团队偏好。

笔者认为，抑制策略的设计应当遵循"少而准"优先于"多而全"的原则。原因在于评审注意力的边际价值递减：前三条高质量意见可能改变合并决策，第十条低质量意见只会增加认知负担。工程上建议把单 PR 的 AI 评论上限设为 5—8 条，超出部分折叠为摘要。这一上限并非拍脑袋，而是与人类评审者的注意力研究结论方向一致——单次评审的有效关注点数量有限，过多信息反而降低决策质量。

3.4 反馈闭环：让评审系统自我校准

完整的流水线还应包含反馈闭环：记录每条 AI 评论的处置结果（采纳、忽略、反驳），定期统计采纳率与误报率，并据此调整抑制阈值与提示词。Codex 一类托管服务在平台侧做这件事，自托管方案则需要团队自己搭建。反馈数据的价值不仅在于调参，更在于为边界划分提供实证依据——哪些类型的意见采纳率高，哪些类型几乎总被忽略，这些统计直接回答了"边界该划在哪"。

需要提醒的是，反馈数据存在选择偏差：开发者倾向于标记明显错误的意见为"无用"，而对"说了等于没说"的意见不作反应。因此统计口径应当区分"显式负反馈"与"无反馈"，前者反映误报，后者反映低价值。两类指标应分别监控，混在一起会掩盖真实问题。

四、边界模型：证据强度 × 可逆性的四象限划分

4.1 两个维度的定义

本文提出的边界模型包含两个维度。证据强度指 AI 意见所依据的证据在多大程度上可被独立验证：硬编码密钥、空指针解引用、明显的资源泄漏属于高证据强度，因为问题存在与否可由确定性工具或人工快速复核；命名风格、抽象层次、注释充分性属于低证据强度，因为判断依赖团队约定与主观偏好。可逆性指若采纳该意见后发现问题判断有误，回退的成本有多高：修改一行代码属于高可逆，调整公共接口或数据模型属于低可逆。

两个维度交叉形成四象限。需要强调，这里的"可逆性"描述的是采纳意见所带来的变更的可逆性，而非缺陷本身的可逆性。这一区分很重要：一个高危缺陷（如 SQL 注入）的修复通常是高可逆的（改一行参数化查询），因此落在"高证据 × 高可逆"象限，适合 AI 直接建议甚至阻断；而一个低危的架构调整建议（如拆分模块）即使证据充分，其变更也是低可逆的，应当由人类主导决策。

4.2 四象限的工程含义

象限Ⅰ是 AI 评审最应发力的区域。这类意见的证据可由确定性工具交叉验证，误报成本低，且修复通常局部化。工程上建议对这类意见启用"阻断式"策略：AI 判定为高置信度时，PR 合并按钮置灰，需人类显式确认或修复。象限Ⅱ需要谨慎：AI 应当输出证据而非结论，例如"该接口的调用方有三处传入了 null，而实现未做判空"，把判断权交给人类。象限Ⅲ适合"建议式"输出，且应当允许开发者一键忽略并记录理由。象限Ⅳ是 AI 评审的禁区，强行输出只会制造噪声与反感。

本文评述：四象限模型的价值不在于分类本身，而在于它把"边界"从模糊的直觉变成了可配置的策略。团队可以据此为每个象限设定不同的输出模板、阻断权限与反馈要求，从而把抽象的"人机分工"落成具体的流水线配置。笔者认为，这比笼统地讨论"AI 能不能替代人类评审"要有意义得多——后者是一个无法证伪的宏大命题，前者是一组可以逐项调优的工程参数。

4.3 边界会随模型能力漂移

必须承认，四象限的划分不是静态的。随着模型在长上下文理解、跨文件推理上的进步，原本落在低证据区的意见（如"这个抽象层次与仓库既有模式不一致"）可能逐渐变得可验证，从而向高证据区迁移。因此边界模型应当作为动态校准的框架，而非一次性结论。工程上建议每季度重跑一次采纳率统计，观察各象限的分布变化，据此调整策略。

另一个漂移来源是团队约定本身的变化。当团队把某类风格问题写进 lint 规则后，它就从"低证据主观问题"变成了"高证据确定性问题"，AI 评审在该项上的职责应当相应退出。这提示我们，AI 评审与规则引擎之间也存在边界，且这条边界会随着规则沉淀而移动。

五、关键数据与案例：误报率、采纳率与噪声抑制的实测口径

5.1 公开研究的可用结论

关于 LLM 代码评审的实证研究在 2023—2025 年快速增长。总体结论可以概括为：LLM 在"发现真实缺陷"上的召回率尚可，但精确率（即输出的意见中真正有价值的比例）普遍偏低，且高度依赖提示设计与上下文供给。多项研究指出，未经抑制策略的原始 LLM 评审意见中，有相当比例属于"正确但无信息量"（如"建议添加注释"）或"与仓库约定冲突"的类型。需要说明，不同研究的任务设定、仓库分布、评价口径差异很大，直接横向比较数字意义有限。

本文评述：笔者不建议把某个具体百分比当作目标，因为评审质量的评价本身高度依赖团队语境。更有意义的做法是建立团队自己的基线：在引入 AI 评审前，统计人类评审的评论数量、采纳率与缺陷逃逸率；引入后按同样口径统计，观察增量。这种前后对比虽然粗糙，但比引用外部数字更能指导决策。

5.2 一个可复用的度量框架

结合工程实践，笔者建议用四个指标刻画 AI 评审的有效性。其一是有效评论率：被开发者标记为有用或实际引发代码修改的评论占比。其二是误报率：被显式反驳的评论占比。其三是阻断准确率：AI 阻断合并的意见中，事后被确认为真问题的比例，这个指标直接关系到阻断权限是否可信。其四是评审时延变化：从 PR 提交到合并的时长，用于观察 AI 是否反而拖慢了流程。

这四个指标应当按象限分别统计。经验上，象限Ⅰ的阻断准确率应当显著高于其他象限，否则说明阻断策略过于激进；象限Ⅲ的有效评论率通常最低，若持续低于阈值，应考虑关闭该象限的输出。度量框架的意义在于把"感觉 AI 有用/没用"变成可讨论的数据，避免团队陷入印象之争。

5.3 案例：一次误报的根因复盘

某团队曾反馈一条典型的误报：AI 指出某函数"未处理返回值可能为 null 的情况"，但该函数的调用方在上一层已做判空。复盘发现，根因是上下文获取阶段只传入了变更文件，未传入调用方代码，模型基于局部信息做出了合理但错误的推断。修复方式是在上下文拼接中加入"直接调用方"的签名与关键判空逻辑，误报随之消失。这个案例说明，大量误报并非模型能力不足，而是上下文工程不到位。

笔者认为，这类复盘应当制度化：每条被标记为误报的评论，都追问"模型缺了什么信息才会这么说"，并据此改进上下文策略。长期积累下来，这份"误报根因清单"比任何通用提示词模板都更有价值，因为它是团队仓库特有的知识沉淀。

六、对比与局限：三类工具形态的能力天花板

6.1 托管服务、自托管服务与评论插件

当前工具大致分三类。第一类是托管服务形态，以 Codex 的 @codex review 为代表，优势是开箱即用、平台侧持续优化上下文与抑制策略，劣势是定制空间有限、代码需出域（对合规敏感团队是硬约束）。第二类是自托管服务形态，以 OpenCode 等开源实现为代表，优势是数据可控、可深度定制，劣势是需要团队自己承担上下文工程与调优成本。第三类是评论插件形态，以 prlens、serge 为代表，聚焦于把 LLM 输出高质量地落成 inline comment，通常与其他评审系统组合使用。

三类形态的能力天花板不同。托管服务的天花板由平台决定，团队能调的主要是触发时机与提示词；自托管的天花板由团队工程能力决定，理论上限更高但下限也更低；评论插件的天花板在于它通常不掌握完整上下文，评审深度受限。选型时应当先明确约束条件（数据能否出域、团队是否有调优人力），再谈能力比较。

6.2 共同局限：三类难以逾越的问题

无论哪类形态，当前 AI 评审都存在三类共同局限。其一是跨仓库推理弱：当缺陷涉及多个仓库的契约一致性时，单仓库上下文不足以支撑判断。其二是运行时信息缺失：性能退化、并发竞态、资源泄漏的长期累积等问题，仅靠静态代码难以可靠识别，需要结合 profiling 与监控数据。其三是价值判断不可替代：是否值得为可读性牺牲性能、是否应当引入新依赖，这类权衡涉及产品与团队偏好，AI 至多提供论据。

本文评述：承认局限不是为了否定工具，而是为了把期望管理做在前面。笔者见过不少团队因为"AI 没发现那个线上事故的根因"而否定整个 AI 评审，这其实是用错了评价标准——线上事故根因往往涉及运行时与跨系统因素，本就不在静态评审的能力范围内。合理的期望是：AI 评审提升常规缺陷的发现率与一致性，降低人类评审的机械负担，而不是替代事故复盘与架构决策。

6.3 与人类评审的互补结构

人类评审的优势恰好在 AI 的短板处：跨系统经验、对业务意图的理解、对团队历史的记忆、以及承担决策责任的能力。因此互补结构的理想形态是：AI 负责"广度扫描 + 证据收集"，人类负责"深度判断 + 责任承担"。具体而言，AI 在 PR 提交后第一时间给出结构化意见，人类评审者在此基础上聚焦于 AI 无法覆盖的维度，而不是重复检查 AI 已覆盖的内容。

这一结构要落地，需要改变人类评审者的阅读习惯：从"逐行读 diff"转向"先读 AI 摘要，再定向深读"。这种转变不会自动发生，需要配套的界面设计与团队约定。笔者认为，这是当前 AI 评审落地中最被低估的环节——工具做得再好，如果人类评审者仍按旧习惯工作，互补结构就无法形成。

七、落地路径：把边界写进流水线的七个步骤

7.1 步骤一至三：基线、分层与触发

第一步，建立基线。在引入 AI 评审前，统计现有 PR 的评论密度、评审时延、缺陷逃逸率，作为后续对比的参照。没有基线的改进无法证明有效。第二步，分层设计。把评审任务分为确定性规则、LLM 语义评审、人类判断三层，明确每层的输入输出与交接方式，避免职责重叠。第三步，设计触发策略。全量触发还是按需触发（如 @codex review 式手动触发）取决于团队规模与成本约束；小团队可先手动触发，观察效果后再考虑自动化。

触发策略还涉及变更规模的处理。建议对超过阈值的 PR 先要求拆分，再进入评审；对文档类、配置类变更可降低评审强度。这些规则应当写进 CI 配置而非口头约定，才能稳定执行。

7.2 步骤四至五：输出模板与阻断权限

第四步，设计输出模板。不同象限使用不同模板：象限Ⅰ输出"问题 + 证据 + 修复建议"，象限Ⅱ输出"证据 + 待人类判断的问题"，象限Ⅲ输出简短建议并附"可忽略"提示，象限Ⅳ不输出。模板的统一有助于开发者快速识别意见类型，降低认知负担。第五步，设定阻断权限。建议初期只对象限Ⅰ开放阻断，且要求高置信度；运行一个季度后，根据阻断准确率决定是否扩大范围。阻断权限一旦滥用，会迅速摧毁团队对工具的信任。

# 象限Ⅰ输出模板示例
[BLOCKER] 潜在空指针解引用
位置: src/order/service.py:142
证据: get_user() 在本仓库 3 处调用中，2 处返回 None 时未判空
建议: 在 142 行前增加 if user is None: return
置信度: 高（多采样一致 4/5）

7.3 步骤六至七：反馈闭环与季度校准

第六步，建立反馈闭环。为每条 AI 评论提供"有用/无用/反驳"三个快捷操作，并强制要求忽略高置信度阻断意见时填写理由。反馈数据按象限聚合，每月review一次。第七步，季度校准。每季度重跑度量框架，观察四象限分布与各指标变化，据此调整抑制阈值、上下文预算与阻断策略。校准会议应当有工程、评审者代表参与，避免单方面调参。

这七个步骤的顺序不宜颠倒：没有基线就无法校准，没有分层就会职责混乱，没有反馈闭环就无法持续改进。笔者建议以季度为周期完整走一遍，前两个季度可适当简化，但基线、分层、反馈三项不可省略。

7.4 拓展资源

延伸阅读与实践参考（均为外部链接，点击在新窗口打开）：

• GitHub Copilot 官方文档——了解托管式代码智能服务的产品形态与权限模型。
• OpenCode 项目主页——自托管代码智能代理的配置与上下文拼接实践。
• GitHub Pull Requests 文档——PR 评审、评论与状态检查的机制说明。
• arXiv cs.SE 最新论文——软件工程方向关于代码评审与 LLM 的最新研究。
• OWASP Top 10——确定性安全规则与 AI 评审分层的参考基准。

八、结论与展望：AI 是证据生产者，人类是责任承担者

回到文章开头的问题：AI 评审与人类评审的边界到底怎么划？本文的答案是，边界不应按"问题严重程度"划，而应按"证据强度 × 可逆性"划。高证据、高可逆的问题，AI 可以阻断；高证据、低可逆的问题，AI 给证据、人类做决策；低证据、高可逆的问题，AI 可建议、人类可忽略；低证据、低可逆的问题，AI 不应输出。这条边界把 AI 定位为证据生产者，把人类定位为责任承担者，既发挥了机器的规模优势，又保留了人类的价值判断与责任主体地位。

展望未来，随着模型在长上下文与跨仓库推理上的进步，四象限的边界会持续漂移，部分低证据问题会变得可验证。但笔者认为，责任边界不会随之消失——即使 AI 能给出更准确的判断，合并决策的责任仍然必须由人类承担，这是工程治理的基本要求，也是合规审计的底线。因此，工具演进的方向应当是让"AI 给证据、人类做决策"这条链路更顺畅、更可追溯，而不是追求"AI 全自动评审"。

对实践者的建议可以浓缩为一句话：先把上下文工程与反馈闭环做扎实，再谈阻断权限与自动化程度。没有前者，后者只会制造噪声与不信任。AI 评审的价值不在它说了多少，而在它说的内容能否真正改变人类的决策质量。

九、主要参考文献