我第一次认真对待"代码审查清单提示词"这件事，是在一次深夜的PR评审里。那一天我连续看了十七个合并请求，眼睛发酸，脑子发木，等到第十八个的时候，我发现自己居然漏掉了一个明显的空指针风险。那一刻我意识到，人脑不是流水线，审查质量会随着疲劳和时间波动。后来我开始琢磨，能不能把团队里那些零散的经验、口口相传的规矩、文档里沉睡的检查项，变成AI能理解、能稳定执行的东西。这就是我理解代码审查清单提示词的起点——它不是一份漂亮文档，而是一套让审查动作可以被重复、被检验的工作语言。
1.1 代码审查清单与提示词的边界：人工经验、规则清单与AI辅助审查
我经常被问到一个问题：这三者到底怎么区分。我的回答很朴素——人工经验是老师傅的手感，规则清单是把手感写成了条目，提示词则是把这些条目翻译成AI听得懂的指令。三者不是替代关系，而是接力关系。老师傅能嗅到代码里那股"不对劲"的味道，规则清单负责把味道拆解成可检查的信号，提示词负责在每次审查时把这些信号稳定地递给AI。我见过一些团队直接把静态检查规则丢给大模型，结果AI回了一堆"建议关注可读性"的空话，问题就出在这个翻译环节没做好。
边界感很重要。人工经验最贵，也最不可复制，一个资深工程师看一眼就知道这段并发逻辑会在高负载下炸掉，这种判断力目前AI还学不来。规则清单擅长覆盖已知模式，比如"禁止明文存储密钥""接口必须有超时设置"，它的优势是确定性，劣势是僵化。AI辅助审查站在中间，它能读懂上下文、能串联多个文件、能给出解释，但它需要清晰的指令边界，否则就会自由发挥。
我自己的做法是：把人工经验当成提示词的原材料，定期把评审会上吵出来的共识沉淀进清单，再把这些清单改写成带上下文、带示例、带输出格式的提示词。这个过程像酿酒，急不得。
1.2 提示词在代码审查中的价值：一致性、可追溯性与审查效率
一致性这件事，吃过亏的人最有发言权。我们团队曾经有五个人轮流做Code Review，同一个类型的SQL注入风险，A会标红，B会放过，C会在评论里写一句"这里注意一下"就完事。新人进来完全懵，不知道该听谁的。把审查要点写进提示词之后，每次AI都用同一套标准过一遍，漏报率明显下来了。这不是说AI比人强，而是说它不会因为今天心情不好就少看两眼。
可追溯性是我后来才体会到的价值。提示词里要求AI引用具体的代码位置、给出问题证据、标注严重级别，这些输出天然就是一份审查记录。出了线上事故回头复盘，我们能翻出当时的审查结论，看清楚是规则没覆盖、还是提示词写得含糊、还是人工复核时被忽略了。这种"能倒查"的能力，对团队改进太重要了。以前审查意见散落在PR评论里，翻起来像考古。
审查效率的提升比较直观。AI做第一轮扫描，把明显的问题挑出来，人工 reviewer 就只需要聚焦在架构判断、业务逻辑和风险权衡上。我算过一笔账，一个中等规模的PR，纯人工初筛大概要二十分钟，AI辅助能压到七八分钟，省下来的时间可以多讨论几个真正棘手的设计问题。
1.3 设计目标：可执行、可复用、可度量、可演进
可执行是我给自己的第一条硬规矩。提示词里不能出现"注意代码质量""确保安全性良好"这种话，AI拿到这种指令只能回你一堆正确但没用的废话。什么叫可执行？就是每个检查项都要能落到具体的代码特征上，比如"检查所有对外HTTP调用是否设置了连接超时和读取超时"，这种指令AI能对着代码一行行比对。
可复用性决定了这套东西能不能规模化。我最初写的提示词是给Java项目用的，后来来了个Go项目组想用，发现里面全是Spring的上下文，完全跑不动。那次之后我开始做变量化设计，把语言、框架、团队规范抽成参数，同一套骨架适配不同技术栈。复用不是偷懒，是让好经验流动起来。
可度量听起来有点工程化，但我觉得特别实在。提示词好不好，不能靠感觉，得看问题命中率、误报率、建议采纳率这些指标。我们每个月会抽一批AI审查结果和人工结论做对比，数据难看就回去改提示词。可演进是同一件事的延续——代码库在变，团队规范在变，提示词也得跟着长，不能写一次就供起来。
1.4 常见误区：清单堆砌、泛化建议、缺少上下文与严重级别
清单堆砌是最常见的坑，我自己也踩过。刚开始热情高涨，往提示词里塞了六十多条检查项，结果AI的输出变成了一份冗长的检查报告，重点全被淹没了。后来我学会做减法，把检查项按风险和场景分层，核心的十来条每次都跑，边缘的按需触发。清单不是越长越好，是要让人看得下去、让AI抓得住重点。
泛化建议是另一个高频问题。"建议优化代码结构""考虑增加注释"——这种话谁都会说，说了等于没说。我要求提示词里的每条指令都绑定具体的判断条件和输出要求，比如"如果方法超过五十行且包含三层以上嵌套，标注为可维护性问题并给出拆分建议"。泛化建议的本质是提示词作者自己没想清楚，把模糊丢给了AI。
缺少上下文会让审查结论跑偏。同一个"删除字段"的操作，在内部工具里是正常重构，在对外API里就是破坏性变更。提示词里不写明变更类型、影响范围、调用方情况，AI只能瞎猜。我现在写提示词，上下文部分花的精力不比检查项少。
严重级别缺失是我见过最要命的问题。AI把"变量命名不规范"和"存在越权访问风险"并列输出， reviewer 的注意力就被稀释了。提示词必须要求AI给每个问题打级别，阻塞级、重要级、建议级分清楚，这样人工复核才知道先看哪里。没有级别的审查清单，就像没有红绿灯的十字路口。
写到这里我停下来想了想，这一章讲的其实是一种心态转变——从"让AI帮我看看代码"变成"我要教会AI怎么像我们团队一样看代码"。前者是碰运气，后者是建能力。下一章我会聊怎么把这套认知落成结构化的提示词框架，那部分更偏手艺活，坑也更多。
上一章末尾我说过，从"让AI帮我看看代码"到"教会AI像我们团队一样看代码"，中间隔着一套结构化的手艺。这一章就聊这套手艺怎么落地。我自己摸索这套框架花了差不多四个月，中间推翻重来了好几版，现在回头看，那些走弯路的经历反而比结论更有意思。
2.1 四要素框架：角色设定、审查上下文、任务指令与输出约束
最早我写提示词，就是把检查项一股脑列出来，像给实习生发了一张长长的备忘录。效果很糟，AI经常抓错重点，或者对着一个Java文件侃侃而谈Python的规范。后来我意识到，一份能用的审查提示词，得先解决"你是谁、你在看什么、你要干什么、你要怎么交付"这四个问题。
角色设定不是写句"你是一个资深工程师"就完事了。我现在会写得具体一些，比如"你是一名有十年经验的后端工程师，熟悉Spring生态和常见安全漏洞模式，审查风格偏保守，宁可多报也不漏掉高危问题"。不同角色定位会让AI的输出风格明显不一样。有一回我把角色改成"你是一名严格的安全审计员"，同一个PR，AI硬是多挖出了三个权限校验问题。
上下文这一块，我吃过最大的亏是只给代码片段不给背景。那次我拿一个内部工具的小改动去测提示词，AI洋洋洒洒列了八条兼容性风险，实际上那个接口压根没有外部调用方。吃一堑长一智，现在我的上下文段落会写清楚变更类型、涉及的模块、调用方范围、是否涉及对外API、团队的技术约束。
任务指令和输出约束是框架的后半截。任务指令回答"查什么、怎么查"，输出约束回答"怎么报、报多细"。我习惯把任务指令拆成几个审查步骤，让AI先通读变更、再逐项检查、最后汇总分级。输出约束用得最多的是那几项：每个问题必须有代码位置、必须给证据、必须标级别、必须给修复建议。约束越具体，AI的自由发挥空间越小，结论越稳。
2.2 审查维度清单：正确性、安全性、性能、可维护性、可读性、测试与依赖合规
维度清单我改过很多次。最开始列了十几个维度，AI每个都回复一遍，输出长得像一份体检报告，看得人头疼。现在我把维度压到六个：正确性、安全性、性能、可维护性、可读性、测试与依赖合规。这六个基本覆盖了我们团队代码评审中的绝大多数争议点。
正确性排在最前面是刻意的。逻辑错误、边界条件、空值处理、并发竞态，这些是真正能让线上炸掉的。我要求AI对正确性维度做重点检查，输出里这一项必须排在前面。安全性紧随其后，重点盯输入校验、权限判断、敏感数据、注入风险。性能维度我不要求AI面面俱到，只让它关注明显的反模式，比如循环里打数据库、N+1查询、无界缓存。
可维护性和可读性放得靠后，是因为这两项最容易产生空泛建议。我给它们加了约束：可读性问题必须落到具体的方法长度、命名规范、注释缺失这些可观察的特征上。测试与依赖合规则是团队特别要求的，新增依赖的许可证、版本冲突、测试覆盖缺口，这些在以往的人工审查里经常被忽略。
我印象很深的是有一次，一个PR引入了一个License是GPL的第三方库，人工评审时没人注意到。提示词加上依赖合规检查后，AI在审查意见里直接标了出来，虽然置信度不高，但至少给了reviewer一个提醒。这件事让我更确信，维度清单的价值不在于查得多，而在于每个维度都能落到具体信号上。
2.3 严重级别与输出格式：问题定位、证据引用、修复建议与置信度
严重级别这件事，我在第一章末尾吐槽过。真正落地的时候，我发现分级本身比批评别人更难。团队里对"什么算阻塞级"一直吵不出统一标准。后来我们干脆参考线上事故等级，把问题分成P0阻塞、P1重要、P2建议三档，再把每档的定义写进提示词里。
P0是会导致线上故障或数据泄露的问题，比如空指针、未授权访问、SQL注入。P1是影响性能、可维护性或存在潜在风险的问题，比如缺少超时、依赖冲突、日志泄露敏感信息。P2是风格、命名、注释类建议。提示词里我把这三档写清楚，还给了判断示例，AI的分级结果才逐渐稳定下来。
输出格式我要求四件套：位置、证据、修复建议、置信度。位置要精确到文件、行号或方法名。证据是AI引用的具体代码片段或上下文，这条特别关键，能防止它凭空编造问题。修复建议要具体到能落地的改法，不能只说"建议优化"。置信度用高、中、低三档表示，低于中档的结论我会让AI明确标注"需要人工确认"，避免制造噪音。
置信度这个字段最初是被团队同事吐槽最多的，说多此一举。用了几个月之后，反而是它最受欢迎。因为reviewer可以按置信度排序看意见，高置信度的先处理，低置信度的快速扫一眼放过。AI也不会因为不自信就干脆不说，它可以用低置信度把可疑的地方标出来。
有一次AI对一个for循环里的字符串拼接给了中等置信度的性能提示，人工reviewer本来觉得无所谓，后来用性能测试一跑，那个循环确实在处理大列表。这种"AI可疑、人工验证"的配合模式，我觉得比让AI装得很确定要健康得多。
2.4 正反例与少样本示例：提升审查结论稳定性
示例这件事，我是被逼着学会的。刚开始我写的提示词全是抽象规则，AI每次执行都像抽盲盒。同一条"检查日志是否包含敏感信息"的规则，它有时候会报出手机号打码问题，有时候又完全忽略。我百思不得其解，后来拿去问提示词方面有经验的朋友，他说了一句话点醒我：你给规则，AI只能猜标准；你给示例，AI才能对答案。
正例是告诉AI什么情况该报。比如我会贴一段日志代码，其中log.info里打印了完整的用户身份证号，并写明"这种情况应标注为P0，理由是违反敏感信息不得入日志的规范"。反例是告诉AI什么情况不该报。比如一段代码里参数名用单字母i，有些人可能觉得不规范，但我们团队规范允许循环变量这样用，我就会把这个场景作为反例写进去，让AI不要报。
少样本示例的数量我也试过。给太多，提示词变得极其冗长，成本和延迟都上去了。给太少，结论又不稳。我现在的经验是三到五个示例最合适，覆盖高危问题、边界情况、常见误报这三类。示例要贴着团队实际代码风格写，别从网上抄通用示例，AI认得出那种"教科书味"，效果会打折。
反例的重要性怎么强调都不过分。AI特别容易过度报告，一点点风吹草动就当作问题。少样本反例是给它划红线的有效手段。我们团队现在维护了一个小小的"误报库"，每发现一次AI误报，就抽一段精简后的正反例补进提示词里。这个库越长，审查结论的噪音越少。
2.5 变量化设计：语言、框架、变更类型与团队规范适配
变量化是我从一次失败里学来的。当时我们团队Java项目用得很顺手，隔壁Go项目组的负责人跑来找我，说你那套提示词能不能借我们用用。我很爽快地给了，结果他试完回了一句："你这提示词里怎么全是Spring注解和JPA，我们的代码它完全看不懂。"那次经历让我意识到，硬编码的提示词只能服务于一个技术栈，想推广就得做变量化。
我的做法是把提示词拆成骨架和变量两层。骨架部分放通用的审查逻辑和输出格式，变量部分包括编程语言、框架版本、团队特有的编码规范、变更类型、可以引用的参考文档。语言和框架是基础变量，变更类型更细，比如新增功能、缺陷修复、重构、配置变更，不同类型下重点检查的维度不一样。重构类变更我会让AI特别关注行为一致性，配置变更则要留意环境差异。
团队规范变量是最有意思的一块。每个团队都有自己的脾气，有的特别看重日志规范，有的特别在意接口向后兼容。把这些团队特有的偏好写成变量注入提示词，AI的审查结论会更贴近团队的审美。我们团队有一条规矩：新增公共方法必须写Javadoc，我把这条也写进了规范变量里，AI现在看到没注释的公共方法会主动提一句。
变量化做到位之后，同一套骨架可以适配多个项目组，维护成本也降了下来。哪条规则要改，改骨架；哪个项目有特殊要求，改变量。这种分层让我少了很多重复劳动，也让好经验真正流动起来。
这一章聊的都是"怎么写"，有点偏手艺，实际用起来你会发现边界没那么清晰，写的过程中常要回头调上一节。我下章会说具体模板和工程化最佳实践，那部分更贴近日常使用，坑也会更细。写提示词这件事，我现在最大的一点体会是：别追求一次写完，追求每次都比上次少一个坑。
上一章结尾我说过，这一章要讲具体模板和工程实践。写这一章我心里有点打鼓，因为模板这东西一旦写出来，就很容易被人当成"抄了就能用"的答案。真实情况是，我们团队现在跑的那几套模板，没有一套是我当初原样写出来的，全是被PR打脸打出来的。我把过程中最有用的几套拿出来摊开讲，顺带说说提示词工程里那些坑。
3.1 通用AI代码审查清单提示词模板：输入、检查项与输出结构
通用模板是我最先搭起来的一套，也是被改得最惨的一套。最开始我往模板里塞了十二个输入字段，从项目名到开发者心情都想让AI知道，结果AI经常抓错重点，检查输出全靠猜。后来我砍到四个输入块：代码变更内容、变更背景说明、团队规范摘要、本次审查的关注重点。输入越少，每次填写的负担越轻，模板的存活率越高。
检查项这块，我不再让AI自己遍历全部维度。通用模板里我把检查项分成"必查"和"抽查"两层。必查是正确性、安全性、空值边界这类硬骨头，每份PR都要过。抽查是性能、可读性、测试补充建议，根据变更类型决定要不要开。这样做的直接后果是输出短了不少，reviewer看得下去，模板在团队里活下来的概率也就高了。
输出结构我固定在四段：结论摘要、问题清单、整体风险评估、需要人工确认的事项。结论摘要限三句话，逼着AI先说重点。问题清单按严重级别排序，每条都要带位置、证据、修复建议、置信度。整体风险评估那段是留给"没有具体问题但有隐患"的场景用的，比如某次重构虽然没有现成bug，但改变了缓存失效的时序。这段结构后来被几个兄弟团队原样抄走了，我挺意外的，因为当初加它只是想给自己留个台阶。
3.2 PR与Diff增量审查模板：变更范围、影响面与回归风险
全量审查代码库是件奢侈的事，日常跑得最多的还是PR和Diff的增量审查。增量模板跟通用模板最大的区别在于，它得先搞清楚"这次改动碰了哪些人"。我吃过一次亏，AI只盯着diff里的几十行代码看，把一个接口返回值的类型改了，调用方三个模块它一个都没提。上线前人工review才拦下来，那次之后我把影响面分析硬加进了增量模板。
变更范围这块我要求AI先说三件事：改了什么文件、改了什么行为、改动属于新增、修复还是重构。讲清楚这三件事，后面的审查才不会脱缰。影响面分析我给的指令是"找出所有可能被本次变更直接或间接影响的调用方、配置项、数据表与对外接口"，并且要求AI在证据里贴出它定位到的引用代码。回归风险是我最看重的部分，我让AI针对每处变更列出至少一条具体的回归场景，比如"用户未登录时调用该接口会走到新增的分支逻辑，需验证降级路径"。回归场景嫌少不嫌多，写得太空泛我会打回去重跑。
增量模板里我还加了一个小机制：要求AI判断本次改动是否触及敏感区域，比如支付、权限、用户数据、外部依赖升级。只要命中任意一项，输出里就要自动附带一段"建议人工重点复核"的提示。这个机制很笨，就是关键词匹配，但它确实帮我们拦下过几次本该升级审查级别的PR。
3.3 专项模板：安全审查、性能审查、测试覆盖、API兼容性与依赖风险
通用模板和增量模板管的是日常，专项模板管的是那些一旦漏掉就要出事的场景。我们团队现在常驻的专项模板有五个：安全审查、性能审查、测试覆盖、API兼容性、依赖风险。每个模板我都单独调过，脾性和通用模板完全不一样。
安全审查模板是约束最狠的一个。我要求AI对每一处输入处理、权限判断、序列化与反序列化、对外接口都显式给出结论，哪怕结论是"未发现风险"也要写。这个"显式无风险"的要求一开始让输出变得很长，我后来折中了一下，让它把无风险项的结论合并成一行汇总，只把可疑点展开。安全模板的角色设定我也改成了偏执型，明确告诉AI"宁可标注误报也不要漏报高危"，这跟我其他模板里的保守设定是反着来的。
性能审查模板的核心是限制观察范围。我不指望AI能算时间复杂度算得比profiler准，只让它盯几类典型反模式：循环里调数据库或RPC、缺失分页、无界集合、重复序列化、锁粒度问题。每报一条都要说明触发条件，比如"当列表元素超过千级时该实现退化为平方复杂度"。测试覆盖模板更简单，要求AI列出本次变更中未被测试覆盖的分支与边界条件，并给出建议补充的测试用例名称。API兼容性模板重点盯方法签名、返回结构、枚举值、异常类型的变化，依赖风险模板盯许可证、版本冲突与已知漏洞库。
这五个模板里，最容易被低估的是依赖风险。人工review时没人会去查一个新引入的库是不是GPL、是不是有已知CVE，AI在这件事上比人靠谱得多。我们有一次因为一个间接依赖的版本冲突排查了大半天，后来把它写进模板的检查项里，AI一眼就标出了传递依赖树里的两个冲突版本。这件事之后，我对专项模板的态度从"锦上添花"变成了"没有不行"。
3.4 代码审查提示词工程最佳实践：分步审查、约束幻觉、要求引用代码位置、避免空泛结论
模板解决的是"查什么"，提示词工程解决的是"怎么让AI查得靠谱"。这部分我踩坑最多，说起来都是血泪。
分步审查是我现在所有模板的默认打法。别指望一句话让AI既找问题又给方案还做分级，它经常顾此失彼。我给的任务链一般是三步：先通读变更并复述改动意图，再按检查项逐条排查并收集证据，最后汇总排序输出。三步之间我会让它明确输出中间产物，比如"第一步结论：本次改动新增了用户导出接口，涉及两个数据表查询"。中间产物看着啰嗦，但它能让我发现AI哪一步开始跑偏，调试起来快多了。
约束幻觉是提示词工程的命门。AI最擅长的两件事：编造不存在的问题、编造不存在的代码位置。我治它的办法是强制引用。所有问题必须附带原文片段，片段必须能在输入代码里找到，找不到就不许报。我还加了一句硬约束："若无法在提供的代码中定位到具体行，请将该条问题标注为无法定位并说明原因"。这句话上线之后，AI凭空报问题的频率肉眼可见地降了下来。
避免空泛结论这件事，我是用惩罚式指令做到的。提示词里我直接写"禁止输出'建议优化代码结构''提升可读性'这类无具体指向的建议，每条建议必须包含可执行的修改动作和修改位置"。写了这条之后，AI的"建议优化"少了很多，取而代之的是"将第42行的方法拆分为参数校验与业务处理两个私有方法"。偶有漏网之鱼，我就在评审提示词资产时把它拎出来补进反例。
3.5 模板版本管理、评审机制与团队提示词资产库
模板一旦超过三套，管理就成了大问题。早期我们团队就是在各种聊天记录和文档里散落着不同版本的提示词，有人改了没同步，有人用的是两周前的旧版，同一条PR跑出两种结论，扯皮扯到半夜。后来我下决心把它当代码管，专门建了个仓库，模板、变量、示例、反例各自分目录存，走Git流程。
版本管理这块我们踩过两个坑。一个是命名混乱，v1、v1-final、v1-final2这种名字出现了好几轮，后来统一改成"模板名-语义版本-适用范围"的格式，比如"security-review-v2.3-java"。另一个是变更没记录，有人悄悄调了一句约束，结果全线输出风格都变了。现在我们要求任何提示词改动都必须带变更说明、变更原因和至少一个测试PR的对比结果，没这些不许合入。
评审机制我参考了代码评审的思路。提示词改动同样要走MR，至少一个熟悉该模板的同事看过，涉及安全检查项的改动还要拉安全组的同学过一遍。评审时我让大家重点看三件事：约束有没有被削弱、示例有没有过期、输出结构有没有破坏下游解析。团队提示词资产库这块我们做得还不算成熟，目前是一个索引页加一个误报案例库。索引页列清楚每套模板的负责人、适用项目、最近一次变更时间。误报案例库存的是真实误报的脱敏片段和对应的反例补充。这个库最大的价值不是让AI变聪明，而是让新同事少走我们走过的弯路。
写到这我回头看了一眼，这一章讲的模板和工程实践其实都不复杂，难的是坚持把它们当资产来经营。下章我会讲落地和评估，那部分更像一场持久战，模板只是弹药，真正决定胜负的是流程和习惯。
上一章结尾我说过，模板只是弹药，真正决定胜负的是流程和习惯。这一章我就把弹药搬上战场之后发生的事讲清楚。说实话，这部分比写提示词难多了，写提示词是我一个人对着电脑较劲，落地推行是跟一群人、一堆系统、一堆旧习惯较劲。我们团队从第一版审查机器人上线到现在，前后折腾了大半年，中间有过两次差点被叫停。我把过程拆开讲，能少踩一个坑算一个。
4.1 融入PR流程与工具链：代码托管平台、CI、审查机器人与人工复核
第一次上线审查机器人，我犯了个很典型的错误：把它做成了“额外一步”。那时候的流程是开发者提PR， reviewer看完代码，再手动去某个页面贴一遍提示词，等AI返回结果，自己复制回来。听着都累。上线两周，使用率掉到三成以下，有人在群里直接说“这玩意儿比我写代码还费劲”。那次之后我才明白，AI审查要活下来，必须长在PR流程里，不能挂在流程外面。我们把机器人接到了代码托管平台的PR事件上，提PR自动触发，结果以评论形式贴在PR里，跟代码行号对齐。开发者不用离开页面，reviewer也不用多开一个窗口。
工具链这块我们走的是“轻集成”路线。代码托管平台负责触发和展示，CI负责跑静态检查与测试，审查机器人负责把AI结论作为一条独立的检查项回写。有人问我要不要做成强制门禁，我的答案是不做。AI审查结论只作为参考检查，不阻塞合并，但会在PR页面上标出风险等级。真正卡合并的仍然是CI里的编译、单测和安全扫描。这个边界我们内部吵过好几次，主张强门禁的同事认为不卡就没有约束力，我的顾虑是误报一旦卡住正常发布，团队会直接把机器人关掉。后来折中了一个办法：连续两周误报率低于阈值的项目，可以申请把“高危问题未处理”设为软提醒，由项目负责人自己决定是否升级为阻塞项。
机器人接入的头一个月，我最常干的活是看日志。不是看AI报了什么，是看它什么时候没触发、什么时候超时、什么时候输出格式把下游解析弄崩了。有一次机器人把一段JSON输出截断了，PR页面直接显示“审查失败”，开发者以为是自己代码有问题，排查了半天。那次之后我加了两层保险：输出做结构化校验，解析失败就降级成纯文本摘要，同时给机器人加了一个“健康检查”定时任务。这些事听起来跟提示词毫无关系，可它们决定了提示词有没有机会被用上。
4.2 人机协同边界：AI初筛、人工判断与责任归属
人机边界这件事，我一开始想得太简单。我以为把AI定位成“初筛工具”就完了，实际跑起来才发现，开发者对“初筛”两个字的理解千差万别。有人把AI结论当圣旨，AI说没问题就直接点合并；有人完全不信，AI报什么都不看。这两种极端都出过事。前一种漏掉了一个AI没识别出的空指针分支，后一种把一个真实的安全隐患拖到上线前才被安全组拦住。我后来在团队里反复讲一句话：AI负责“多看一遍”，人负责“拍板”。
责任归属这块我们定得很明确。PR的最终责任在提交者和reviewer，AI不承担任何责任，也不能作为“AI说可以”的免责理由。审查机器人输出的每条问题都带置信度，置信度低的会标成“建议人工确认”，置信度高的也不会自动通过。我要求reviewer在PR评论里对AI提出的高危问题逐条回应，要么修复，要么说明不修复的理由。这个动作看着形式化，它解决的是一个很隐蔽的问题：AI报了一堆问题，reviewer点了个“已阅”，最后谁也没真正处理。
人工复核的精力分配我们也调过。早期AI输出太长，reviewer看两条就烦了，后面的直接划过。我把输出砍到只保留“必须看”的部分：高危问题全量展示，中低危问题折叠，整体风险评估放最前面。reviewer先看三句话摘要，有兴趣再展开。这个改动之后，PR评论区的有效讨论明显多了。我自己有个判断标准：如果reviewer在PR里引用AI结论跟作者讨论，说明协同起作用了；如果评论区只有机器人自言自语，那这套流程就是摆设。
4.3 评估指标：问题命中率、误报率、建议采纳率、审查时长与缺陷逃逸率
评估这件事，我最怕两种做法：一种是拍脑袋说“感觉有用”，另一种是堆一堆指标没人看。我们团队最后留了五个指标，每个都有明确的采集方式和责任人。问题命中率看的是AI报的问题里，人工确认为真的比例。误报率反过来，人工标记为误报的比例。建议采纳率看的是AI给出的修复建议里，最终被合入代码的比例。审查时长是PR从提交到首次人工review的时间，用来观察AI有没有真的帮人省时间。缺陷逃逸率是上线后发现的、本可以在review阶段拦住的问题比例，这个指标最难采，我们目前只对P1、P2级故障做回溯。
采集方式上，我们没有搞复杂的标注系统。命中率和误报率靠PR评论里的固定标签，reviewer点一下“确认”或“误报”就行，机器人自动汇总。建议采纳率靠对比AI建议片段和最终diff，人工抽检加脚本粗筛。审查时长直接从平台API拉。缺陷逃逸率靠故障复盘会上一项一项对。这些数据每周出一张简表，不排名、不通报，只放在团队文档里。我特意不做排名，一旦排名，大家就会为了指标好看去点“确认”，数据就废了。
指标跑起来之后，有些结论跟我预想的不一样。我原以为AI能把审查时长压下去，实际数据只降了百分之十几，因为reviewer省下的时间又花在看AI结论上了。真正明显的是缺陷逃逸率，尤其是安全类和依赖类问题，上线后的相关故障少了一截。误报率最高的是性能审查模板，AI特别喜欢报“可能存在性能问题”，证据又不够硬。这些数据后来直接影响了提示词的迭代方向，性能模板被我砍掉了三分之一的检查项。
4.4 反馈闭环：误报归因、提示词迭代与清单增删机制
误报归因是我们每周必做的一件事，做起来很枯燥。我把误报分成四类：AI看错了代码、AI看对了代码但判断过重、提示词没给够上下文、团队规范本身没写清楚。四类里面，前两类靠调提示词解决，第三类靠补输入，第四类最麻烦，得回去改团队规范。有一次连续三周，同一个“空值检查”问题被标误报，我一开始以为是AI太敏感，追下去才发现是团队的空值处理规范只写在某个人的脑子里，代码里两种写法都有。那件事之后我们在提示词里加了一段“团队空值约定”的变量，也顺手把规范文档补了。
提示词迭代我们现在走的是小步快跑。每周收集误报和漏报案例，挑出重复出现的问题，改一版提示词，拿历史PR回放测试，对比改动前后的输出差异。回放测试这件事我强烈推荐，它比在真实PR上试错便宜太多。我们攒了一个包含五十条历史PR的回归集，每次改提示词都跑一遍，看命中率和误报率有没有明显波动。有一回我改了一句严重级别定义的措辞，回放发现高危问题数量翻了一倍，赶紧回滚。没有这个回归集，这种改动可能要到线上炸了才知道。
清单增删机制我们定了个土规矩：任何检查项想加进去，必须附带至少一个真实漏报案例；任何检查项想删掉，必须连续两个月没有命中记录，并且有至少两个人确认它没用。加项容易减项难，这是故意的。团队天然有堆清单的冲动，出了事就想加一条，加到最后清单变成一本没人看的书。我宁可清单短一点，每条都有人真正在意。现在我们的通用清单稳定在九条，专项清单最多的安全审查有十四条，比第一版少了将近一半。
4.5 组织推广：培训、示例库、清单治理与持续度量
推广这件事我走过弯路。最早我搞了一次全员培训，讲了一个小时提示词怎么写、模板怎么用，讲完大家鼓掌，第二天使用率没动。后来我换了打法，不做大课，做小范围结对。每个小组拉一个“种子选手”，我跟他一起过两三个真实PR，让他自己感受AI在哪有用、在哪添乱。种子选手回到组里再带其他人。这个办法慢，可它管用。人对自己亲手试过的东西才有信任，听讲座听不来习惯。
示例库是我们后来补的。索引页列模板，示例库列场景。每个场景写清楚：什么类型的PR、用了哪套模板、AI报了什么、人工怎么判断、最后怎么处理。示例库不追求多，追求真。我们目前攒了三十多个场景，覆盖安全、依赖、API兼容性这些高频区。新同事入职第一周就被要求读五个示例，然后拿一个历史PR自己跑一遍。这个动作比任何文档都直观。清单治理这块我们设了一个虚拟角色，叫“清单守门人”，轮流担任，负责每月过一遍检查项、清理过期示例、汇总误报趋势。这个角色不占多少时间，它解决的是“没人对清单整体负责”的问题。
持续度量我现在的态度比半年前平和了。早期我恨不得每天看数据，看到误报率上升就焦虑。后来想明白了，这套东西的价值不在某一天的指标，在团队有没有形成“提PR、看结论、留反馈”的循环。我们现在每季度做一次回顾，看五个指标的趋势，看清单增删记录，看示例库更新情况。趋势比绝对值重要，循环比工具重要。这话说起来像口号，可它是我被数据折腾了半年之后最真实的体会。
写到这儿，这个系列想讲的东西基本讲完了。从认知、结构、模板到落地，每一步我都尽量把真实踩过的坑摊开。代码审查清单提示词不是什么魔法，它是一套需要经营的工具资产。工具会旧，流程会变，团队会换人，能留下来的只有那套让工具持续变好的习惯。
