收益：
- 能够使用人工智能作为带有类别和严重性标签的初始审查过滤器
- 能够用人的思维过滤结果以验证/误报/应用
- 能够对业务规则、架构和安全关键决策强制执行人工审批要求
代码审查是指开发人员编写的更改在合并之前由其他人审查。好评；它尽早发现错误、共享信息并保持代码库的一致性。但评论很累人，容易分心，而且在时间压力下会变得肤浅。人工智能在这里是一个双重助手：它允许您预先清理自己提交供审查的代码，并以更敏锐的眼光检查其他人的 PR（拉取请求）。
关键的区别在于：人工智能加快并增强了审查，但它不能接管审批的责任。 “AI看起来很干净”这句话并不是背书。最终的“合并”决定取决于了解代码和上下文的工程师。
回顾人工智能的优点和缺点
适合：空检查未命中、资源泄漏（文件/链接保持打开状态）、未捕获的异常、明显错误的条件（>= 而不是 >）、重命名建议、可读性、丢失边缘情况、简单的安全气味（如 SQL 字符串连接）、重复代码检测。
弱点：违反业务规则但需要上下文和时间安排的深层缺陷，例如语法正确的逻辑、架构合规性、实际性能瓶颈、并发错误。人工智能还会产生误报（将实际上不是问题的问题误认为是问题）和漏报（漏掉真正的错误）。因此，它的输出是一个“警告列表”，而不是一个明确的判决。
注意：仅仅因为人工智能说“没问题”并不能证明代码是正确的。假阴性是沉默的；最危险的错误是那些在评论中从未提及的错误。
系统审查步骤
- 给出上下文。将更改的目的、相关问题和接受标准（如果有）添加到提示中。无目的的审查会产生无目的的解释。
- 将其分为几类。要求模型将发现结果分类为“bug/安全/性能/可读性/风格”；这样你就可以将批评与噪音分开。
- 请求严重性标签。给每个发现一个“高/中/低”评级，并包括“原因”和“建议纠正”。
- 用你自己的眼睛过滤它。评估每个发现：是否真实（验证），是否误报（写出理由），是否缺少任何内容（添加您自己的知识）。
- 手动验证关键路径。无需依赖人工智能，自行读取并执行涉及金钱、身份、授权和数据删除的路线。
三个迷你箱
情况 1 — 捕获静默 null 错误。一个团队让 AI 预审了一份 380 行的 PR。该模型标记了一种外部服务响应可能为空的方式，但在代码中没有对此进行检查。人工审核者验证了该路径并添加了空检查；类似的错误导致上一季度的生产中断了 2 个小时。
案例 2 — 误报消除。 AI 循环标记了“可能的性能问题”。审阅者将其视为误报，因为知道该循环最多只能处理 5 个元素（它在枚举上循环）。该模型不了解背景，警告说：了解背景的人做出了正确的决定。
案例 3——AI 错过了业务规则错误。虽然根据活动规则，折扣帐户最多应为 30%，但代码允许 50%。 AI从来没有注意到这个语法上完美的逻辑错误；因为他不知道规则。该错误是由了解验收标准的产品负责人在审查中发现的。经验教训：业务规则验证是一项人类工作。
四个可复制模板
有目的的、分类的审查：
角色：细致的代码审查员。更改目的：{{目的/问题}}查看此差异。提供以下类别的发现：[Bug] [Security][Performance] [Readability] [Style]。对于每个发现：文件：行、严重性（高/中/低）、原因、建议修复。如果您不确定，请标记“可能”。你不了解商业规则；向我询问需要遵守规则的地方。{{diff}}
准备检查您自己的代码：
在打开 PR 之前查看此更改。查找：缺少 null/bugcheck、资源泄漏、边缘情况、秘密、未经测试的分支。按优先顺序列出调查结果；建议每条修正 1 行。{{code}}
边缘案例搜寻：
列出此函数可能中断的输入和情况：空、空、太大、负数、并发调用、网络错误、部分数据。对于每种情况，写下预期的行为以及当前代码将执行的操作。{{function}}
安检气味扫描（预筛选）：
在此代码中查找常见的安全问题：SQL/命令串联、未经验证的输入、不可变的嵌入式机密、不安全的反序列化、缺乏权限检查。将调查结果分为“确定/可能/知识”。这是初步筛选；这不是最终裁决。{{code}}
弱提示/强提示
弱者：“这个PR有错误吗？”
强：“目的：将优惠券折扣添加到购物车总额中（折扣不得超过 30% - 您无法自己验证此规则，只需告诉我代码是否施加上限）。检查差异；按类别+严重性+建议的更正给出结果，如果不确定，则标记“可能”。[差异]”
强版明确阐述了AI的意图、业务规则和边界；因此，有用的发现出现了，模型未知的区域仍然清晰。
查找类型
人工智能可靠性
男人的角色
空/错误检查缺失
高
验证并申请
可读性/风格
高
按喜好选择
简单的安全气味
中等
最终确定，用车辆扫描
业务规则合规性
低
这完全是人类。
并发/架构
低
需要专家评审
人工智能审核不能替代人工审核
将人工智能审核定位为“第一道过滤器”：廉价、快速、不知疲倦的初步通过。该过滤器将人类审阅者的注意力从不重要的细节（空间、名称）中解放出来，并将其引导到真正需要思考的地方——业务规则、架构、安全结果。但合并批准是团队内负责人的签名。对于安全关键的变更，必须由至少一名称职的工程师进行独立审查。
提示：将人工智能生成的调查结果列表视为“要检查的事情”而不是“要做的事情”。要么验证并应用每一项，要么用一句话写下你通过它的原因；此跟踪使得审核可审核。
常见错误
- 它的意思是“人工智能看起来很干净”。这是由于漏报而产生的错误信心。
- 没有给出上下文。如果没有目的和接受标准，该模型只能产生肤浅的风格解释。
- 盲目应用误报。修复模型的每个警告可能会破坏正在运行的代码。
- 向模型询问业务规则。模型不知道规则；这要靠人来验证。
- 不要歧视暴力。将关键安全发现和名称建议放在同一个包中会掩盖重要的内容。
综上所述
人工智能是代码审查中不知疲倦的第一个过滤器：它可以很好地捕获空/错误遗漏、边缘情况和简单的安全气味；但它在业务规则、架构和并发性等需要上下文的缺陷方面表现不佳，并且会产生误报和漏报。按类别和严重性请求结果，利用人工智能过滤每个结果，手动验证关键路径。批准始终是负责任的工程师的签名。
应用任务
选择真实的或最近的 PR/差异。首先，让AI用“客观导向、类别审核”模板进行审核。将调查结果放入表格中，然后对每一项做出决定：正确（我已验证）、误报（这是我的推理）或要实施。然后自己巡视一下，尝试找到人工智能缺失的至少一件事（尤其是业务规则或边缘情况）并将其写下来。
清单
- [ ] 我使用人工智能评论作为第一个过滤器，而不是认可。
- [ ] 我将目的和接受标准添加到审阅提示中。
- [ ] 我按类别将发现与噪音分开，并强烈想要它们。
- [ ] 我有意识地过滤每个发现以确认/误报/应用。
- [ ] 作为一个人，我检查业务规则和架构合规性。
- [ ] 我需要合格工程师的批准才能进行安全关键变更。