AI 代码审查工具与流程

• 认识 Copilot Code Review 的能力
• 明确其边界
• 工程应用方式

Copilot Code Review 能基于 PR 提供自动审查意见，覆盖风格问题、明显 bug、简单安全模式、重复代码、测试缺失等确定性检查，能提升审查速度与覆盖面。能力边界：它缺乏对复杂业务语义、架构权衡、跨文件影响、深层次越权等上下文密集型问题的判断，且可能产生误报/漏报。工程应用：作为"首审助手"先跑一轮，为人工 reviewer 提供候补意见；将意见按严重度分级，人工确认后采纳；对高价值规则沉淀为自定义规则或审查提示，持续迭代。关键是把 AI 定位为"辅助初筛"而非"最终审批"。

Copilot Code Review 的价值在"快"与"广"，边界在"深"与"准"。工程应用上要"AI 首审 + 人工终审 + 规则沉淀"，既享受提效又守住质量与责任。

• 认识评审 bot 的幻觉风险
• 约束设计手段
• 降低误报

幻觉风险：AI 评审 bot 可能"凭空"指出不存在的缺陷（误报）、引用不存在的规则或 API、把正确的代码误判为问题，降低评审可信度与团队信任。约束设计：①限制审查范围——只审查明确的规则/模式，避免"自由发挥"；②基于证据——要求意见附带规则 ID、代码行号、相似案例，无法论证的不得输出；③设定置信度——只对高置信问题告警，低置信降级为提示；④约束输出格式——只按模板输出问题与建议，抑制无依据的"建议"；⑤人工兜底——AI 意见不自动合并，人工确认后才采纳。目标是让 AI 评审"有据可依、宁缺毋滥"。

幻觉是 LLM 评审的最大可靠性风险。约束的核心是"把 AI 的开放式生成收敛为证据驱动的检查"，用规则关联、置信度分级与人工确认，把误报抑制到可接受水平。

• 认识 AI 审查的三大局限
• 分析局限成因
• 应对策略

三大局限：①架构判断——AI 难以评估"这个设计是否符合团队架构、模块边界、可扩展性、依赖方向"，因为它缺乏对整体架构意图与演进史的理解；②业务语义——AI 无法真正理解业务规则与领域约束，难以判断"这个逻辑是否符合业务"，易漏掉业务级错误；③跨文件上下文——AI 审查单文件时看不到跨模块/跨服务的调用关系、数据流与副作用，易漏掉"看似局部实则全局"的问题。应对：把 AI 定位为"单文件/局部的快速检查"，对架构、业务语义、跨文件影响的判断交给人工 reviewer，并让 AI 在注入相关上下文后辅助但不下定论。

局限的根因是 AI 缺乏"全局上下文与真实业务理解"。审查策略上应"AI 管局部显性、人工管全局语义"，明确分工以补齐 AI 的盲区。

• 认识上下文注入对审查质量的影响
• 设计上下文输入的方法
• 提升建议精准度与可执行性

注入设计：①仓库规范——把编码规范、架构约束、命名约定、do/don't 注入审查提示，让 AI 按团队标准审查而非通用标准；②领域词汇表——提供业务术语、领域概念及其含义，帮助 AI 理解代码语义，减少"看不懂业务"的误判；③历史缺陷模式——注入团队历史 PR 中反复出现的缺陷类型及修复范式，让 AI 优先关注这些高风险点。为提升可执行性，要求 AI 输出"问题 + 依据（规则/行号）+ 具体修复建议"，并给出可采纳/拒绝的选项。上下文要"精选、结构化、版本化"，避免噪声稀释。

AI 审查的精准度取决于"它了解的上下文"。注入规范、词汇与历史缺陷，本质是把团队知识"喂"给 AI，让它从"通用审查"升级为"贴合团队业务的审查"，从而提升建议的可执行性。

• 了解主流 AI 评审工具定位
• 对比能力维度
• 选型考量

主流工具各有侧重：CodeRabbit 侧重 PR 摘要、逐行评论与缺陷检出，强调"代码理解 + 可操作建议"；Greptile 侧重"代码库理解"，对大型代码库的架构与上下文理解强，能生成架构图与上下文化见解；Qodo（原 Codium）侧重测试生成与缺陷分析，审查与测试联动；Cursor BugBot 侧重 inline 的 bug 检测与快速反馈，融入 Cursor 工作流。选型维度：①PR 摘要——需要快速理解变更概览还是需逐行评论；②架构图——是否需要宏观代码库结构理解；③缺陷检出侧重——风格/安全/逻辑/测试；④成本模型——按 token/按仓库/按席位，评估用量与预算。选型应结合自身体系（代码库规模、工具链、团队流程）与预算，做 POC 对比而非仅看厂商宣传。

工具选型是"需求匹配"而非"功能堆叠"。不同的工具在摘要、架构理解、缺陷侧重、成本上各有取舍，需结合团队实际场景与预算，用真实 PR 做对比评测后再定。

• 理解两种审查模式
• 比较能力边界与可靠性
• 适用场景

静态规则 AI 审查：基于注入的规则与模式对代码做一次性检查，输出"符合/违反规则"的结论，速度快、可解释，但相对静态，无法验证代码实际行为。Agentic Code Review：AI 以"多轮自省"方式运行——先读代码，提出假设，执行测试/静态扫描/检索上下文，再根据结果修正结论，最后给出经验证的结论。它更接近"深度审查"，能发现"运行结果层面"的问题，但更慢、更贵、可能存在"执行误导"（AI 误读测试结果）。可靠性上，静态规则"稳定可复现但浅"，Agentic"深但复杂、需约束"。实践中可结合：静态规则做快速拦截，Agentic 用于高风险/复杂变更的深度审查。

二者是"快浅"与"深慢"的权衡。静态规则稳定可解释，Agentic 能通过执行验证加深理解，但复杂与成本更高；应根据变更风险与成本选择，并给 Agentic 设定"结论须有依据"的约束提升可靠性。

• 理解"AI 批准不等于人工批准"原则
• 设计强制人工 review 的政策
• 防止流程形式化

原则：AI 审查通过只是"机器认为没有明显问题"，不等于"人工确认符合业务与架构"，后者才是最终责任决策。政策设计：①规则上——明确"AI 意见不得作为合并的最终批准"，必须有人工 reviewer 的 approve 才能合并；②分级上——高风险变更（安全、资金、核心逻辑）强制人工精审，低风险可人工快速复核；③防形式化——要求人工 reviewer 对 AI 意见给出"采纳/拒绝+理由"，记录审查痕迹，防止"直接点通过"；④度量上——跟踪人工 review 的采纳率、拒绝率与"秒过"率，识别形式化倾向；⑤责任上——明确"AI 通过"不减轻人工责任。目标是让 AI 辅助、人工负责，流程不沦为空转。

防止 AI 代审的关键是"职责不可转移 + 流程可度量"。AI 负责提效，人类负责决策与责任；通过强制人工批准、留痕与度量，杜绝"AI 通过就合并"的流程形式化。

• 设计人机协作审查流程
• 明确分工与反馈机制
• 流程迭代

流程设计：分工——AI 负责首审（风格、明显 bug、安全模式、测试建议、复杂度），人工负责终审（架构、业务语义、跨文件影响、最终批准），AI 意见按置信度分级供人工参考；反馈——人工对 AI 意见标记"采纳/拒绝/误报"，这些反馈回流给 AI 审查的规则与提示，优化后续审查；迭代——定期复盘 AI 审查的检出率与误报率，调整规则阈值、上下文输入与审查范围，形成"审查-反馈-优化"的闭环。关键是把 AI 当"可训练的协作者"而非"一次性工具"。

人机协作审查的核心是"明确分工 + 反馈闭环 + 持续迭代"。AI 提效、人工把关、反馈优化，三者循环使 AI 审查质量随团队沉淀而提升，审查流程更加高效精准。

• 认识通知噪声问题
• 治理手段（订阅粒度、忽略规则、批量处理）
• 处理体验

通知噪声：AI 审查意见过多、误报多会导致 reviewer 被大量无效通知淹没，降低关注度。治理：①订阅粒度——按"变更类型/风险等级/模块"精细订阅，只通知相关 reviewer 的高优先级事项，避免"每个 PR 都打扰所有人"；②忽略规则——基于规则 ID、风险等级、模块建立忽略/豁免清单，对低价值或已知误报项自动忽略；③批量处理——汇总同类意见、批量忽略/批量采纳，而非逐条处理；④分级通知——只对"阻断级/高置信"问题实时通知，低置信问题汇总在每日报告。目标是让 reviewer 只看到"值得看"的通知。

通知噪声治理的本质是"让有限注意力聚焦高价值"。通过订阅粒度、忽略规则与批量处理，把 AI 的意见从"淹没"变为"精选"，维护 reviewer 对 AI 审查的信任与效率。

• 设计审查度量指标
• 数据采集与可信度
• 持续改进

度量指标：①缺陷发现率——AI 指出且被确认为真实缺陷的比例（真阳率），衡量 AI 的检出能力；②误报率——AI 指出但实为误报的比例（假阳率），衡量噪声；③评审效率——人工 reviewer 处理一个 PR 的时间、首过时间、审查吞吐，衡量提效。数据采集：用"人工确认标记"统计 AI 意见的真阳/假阳，用时间戳统计评审耗时。改进：用缺陷发现率与误报率评估 AI 审查质量，调整规则与上下文；用效率指标评估投入产出。关键是建立"AI 意见 → 人工确认 → 统计"的闭环，让度量可信。

审查度量要"既看检出又看噪声"。缺陷发现率反映能力，误报率反映可接受度，效率反映价值；三者结合才能判断 AI 审查是否"真有用"，并据此迭代规则与上下文。

• 理解 AI 与人工的分工
• 识别 AI 擅长项
• 识别必须人工项

AI 擅长：风格与规范（命名、格式、lint）、简单 bug（NPE、null 检查、资源未释放）、常见安全模式（注入、XSS、硬编码密钥）、重复代码、测试缺失、明显复杂度问题。必须人工判断：架构正确性（设计是否符合模块边界、依赖方向、可扩展性）、业务语义（逻辑是否符合业务规则与领域约束）、跨文件/跨模块影响、权衡取舍（性能与可读性、改动范围）、以及最终的责任批准。分工原则是"AI 管确定性、可枚举、局部检查，人工管判断性、全局、业务决策"。

AI 与人工的分工基于"确定性 vs 判断性"。AI 擅长规则化、可枚举、局部的检查，人工擅长需要业务上下文、全局视野与权衡的决策，二者互补而非替代。

• 理解误报来源
• 治理手段（规则阈值、基线库、置信度）
• 降低噪音效果

误报治理手段：①规则阈值——对规则设置合适的阈值（如复杂度、长度、风险等级），过高/过低都会产生误报或无报，需校准；②基线库——把"已被确认的误报/豁免"记录成基线库，AI 审查时对命中基线库的模式自动忽略，避免重复误报；③置信度标注——让 AI 输出置信度（高/中/低），高置信才告警/阻断，低置信降级为提示或直接忽略，reviewer 只关注高置信项。三者结合能显著降低噪音，让 AI 审查意见"少而准"。

误报的根源是"规则过宽 + 无学习 + 无分级"。阈值校准定标准、基线库记经验、置信度标可靠，三者协同把 AI 审查从"什么都报"收敛为"报得准"。

• 认识 AI 审查的能力维度
• 各维度可靠程度
• 边界与使用

AI 审查能力分三块：①风格——命名、格式、规范一致性，可靠度高，可自动执行；②缺陷——逻辑 bug、边界、异常处理、资源管理，可靠度中等，能发现常见问题但需人工确认；③安全建议——注入、鉴权、密钥管理等模式，可靠度中等，能提示风险但业务级越权等需人工。能力边界：AI 在"规则化、模式化"的检查上可靠，在"需要业务与全局"的判断上不足。使用上：风格检查可自动采纳，缺陷与安全建议要人工确认并分级处理。

AI 审查能力是"风格高可靠、缺陷中可靠、安全中可靠、业务低可靠"的分层。理解这个边界能指导"哪些可自动、哪些需人工"，避免高估或低估 AI。

• 设计审查提示
• 规则与上下文的输入方式
• 提升质量

提示设计要点：①规则输入——把团队规范、审查清单、do/don't、禁用 API 等显式写入提示，让 AI 按团队标准审查并输出"命中哪条规则"；②上下文输入——注入相关代码、仓库规范、领域词汇、历史缺陷，帮助 AI 理解代码语义；③输出约束——要求 AI 按模板输出"问题 + 依据（规则/行号）+ 严重度 + 建议"，并给出可采纳/拒绝的判断；④范围约束——明确"只审查 XX 范围、只看 XX 类问题"，避免发散。规则与上下文要精选、结构化、可版本化，并随反馈迭代。

审查提示是"AI 审查的指挥棒"。规则赋予标准、上下文赋予理解、输出约束赋予可执行性，三者设计得当，AI 审查才能贴合团队、精准可执行。

• 理解可复核性的价值
• 附带依据的方式
• 支撑人工决策

可复核性指 AI 的每条建议都能被人工验证真假。实现方式：①规则 ID——每条建议标注命中的规则/规范编号，人工可查规则原文；②代码行号——精确到问题所在行与相关代码，人工可定位；③相似案例——若由历史缺陷模式触发，附上相似案例或修复范式；④上下文——说明"为什么判定为问题"的依据。这些依据让人工 reviewer 能快速判断"采纳/拒绝/忽略"，权威结论基于证据而非 AI 的"感觉"。对无依据的建议，应视为低可信并降级。

可复核性把 AI 审查从"黑盒建议"变成"可审计证据"。规则 ID、行号、案例、依据让人工能验证每一条建议，既提升采纳效率，也抑制幻觉与误报。

• 设计基准评测
• 用历史 PR 缺陷集
• 避免厂商指标误导

可信基准评测设计：①数据——用"带标注的历史 PR 缺陷集"（已知哪些 PR 有真实缺陷、缺陷在哪），作为金标准；②指标——衡量检出率（召回：真实缺陷被 AI 找出的比例）、误报率（AI 报出的意见中错误的比例）、精准率；③评测——在同一批 PR 上运行工具，对比其输出与金标准，计算检出率与误报率；④避免误导——不用厂商的演示场景，用自己真实的、覆盖多种缺陷类型的 PR 集；注意排除"演示集恰好匹配"的情况，并看"真实项目中的表现"而非"宣传截图"。同时评测要长期、多样化，避免单次偶然。

可信评测的关键是"用自己的金标准数据 + 客观指标 + 真实场景"。检出率与误报率是"剪刀差"，要看两者平衡（不可只看检出率），且要基于真实 PR 集而非厂商演示，才能得到可信选型依据。

• 设计意见分级与门禁
• 与人工意见合并
• 避免误阻断/漏放

映射：按严重度与置信度把 AI 意见分为两类——blocking（高危安全、明确逻辑错误、高置信度）与 non-blocking（风格、低置信、建议）。接入门禁：blocking 意见接入 CI 合并门禁，未解决则禁止合并；non-blocking 仅告警，不阻塞。与人工意见合并：人工意见优先级高于 AI——人工标记的 blocking 必阻断；AI 的 blocking 若被人工判定为误报，可降级为 non-blocking。设计上要"AI 阻断可被人工豁免、人工阻断不可被 AI 豁免"，并记录豁免理由，避免 AI 误阻断拖慢交付或漏放缺陷。

意见分级与门禁要"AI 辅助、人工高于 AI"。blocking/non-blocking 基于严重度与置信度，合并时人工决策优先，AI 阻断可豁免但需留痕，既利用 AI 的速度又守住人工的责任。

• 理解跨时区评审问题
• AI 首审压缩响应时间
• 人工聚焦高价值

跨时区团队评审队列积压的核心问题是"等待人工 reviewer 上线"导致首过时间长。AI 首审的价值：PR 提交后由 AI 立即首审，产出即时意见，压缩"提交到首次反馈"的响应时间；同时用 AI 做分类分级——检出明显问题、标记高风险、过滤低风险，让人工 reviewer 上线时能直接聚焦高价值意见，而非从零读 PR。此外可设置"AI 初审通过 + 高风险人工复核"的门禁，让低风险 PR 不必等待人工。人工聚焦策略：按 AI 的置信度与风险分级，优先处理 blocking/高危项，低置信项可批量或忽略。

AI 首审把"等待人工"的瓶颈转化为"AI 即时反馈 + 人工聚焦"。AI 压缩响应时间、分级减负，人工专注高价值决策，跨时区下评审吞吐与质量都得到提升。

• 理解代码上传的隐私风险
• 脱敏、隔离部署、数据留存
• 合规政策

代码上传第三方 AI 服务存在"代码泄露、训练数据污染、敏感信息外泄"风险。政策制定：①脱敏——上传前对代码做脱敏（移除密钥、凭证、个人数据、内部命名），或用工具自动替换敏感信息；②隔离部署——对高敏感代码使用私有化/本地部署的 AI 服务，或选择提供数据隔离承诺的厂商，避免代码进入外部训练；③数据留存——明确服务商的数据留存与删除条款，禁止留存用于训练或无期限存储，签订数据处理协议（DPA）；④访问控制——限制谁可上传、上传范围，并审计日志。落地时按"代码敏感度分级"决定用公有云 AI 还是本地模型。

隐私合规的核心是"代码是敏感资产，上传需受控"。脱敏、隔离、留存、访问控制四层保障，配合敏感度分级，才能既用 AI 提效又不泄露核心资产。

• 理解发现到规范转化的路径
• 沉淀为 CI 门禁
• 持续治理

转化路径：①一次性发现——AI 审查或人工审查发现某问题；②确认价值——人工确认该问题真实、常见、值得拦截；③固化为规则——把问题的判断条件写成静态分析规则（如 SonarQube 规则、lint 规则）或审查清单项；④接入 CI 门禁——把规则设为 CI 阻断/告警，让后续代码自动拦截；⑤沉淀为规范——把规则写入团队编码规范文档，供 AI 生成与人工编写共同遵循；⑥迭代——根据新发现与误报持续追加/调整规则。形成"发现→固化→门禁→规范→迭代"的闭环。

转化路径让"一次性发现"变成"永久防线"。通过规则化接入 CI 门禁并沉淀为规范，防止同一问题反复出现，把 AI 审查的价值从"查一次"升级为"持续拦截"。

• 理解误报治理手段
• 阈值校准
• 人工复核兜底

误报治理的两条主线：①阈值——对规则与风险等级设置合理阈值（如复杂度、严重度、置信度），校准"报什么、报多严"，过高阈值减少误报但可能漏报，过低阈值误报多，需权衡校准；②人工复核——对 AI 判定为"阻断/高危"的意见强制人工复核，确认真伪，误报的直接豁免并记录，避免错误阻断；同时把"被确认的误报"反馈给规则库，收敛后续误报。阈值定"标准"，人工复核兜"可靠"，两者结合让 AI 审查"少误报、不误放"。

阈值与人工复核是误报治理的"校准 + 兜底"。阈值从源头控制报出范围，人工复核确认每条重要意见，并把误报反馈回规则库，形成收敛循环。