多角色AI代码审查实战：三份提示词让大模型精准揪出漏洞

我最近让 AI 帮我 review 一段登录模块的 Python 代码，它回我一句“整体逻辑清晰，部分地方建议优化”，然后列了几条不痛不痒的“变量命名可以更清晰”之类的废话。那一刻我明白了：不是大模型不能审代码，是我的问法太懒了。后来我把提示词改成“让 AI 扮演三位专家轮流审”——一个挑刺、一个找漏洞、一个补测试，效果完全不一样，真的翻出了两个潜在的安全问题和一个边界条件 bug。

这篇文章就聊聊这套多角色代码审查的方法：三份可以直接抄的专家提示词、完整的实操流程、以及我踩过的坑。适合想让大模型真正帮自己检查代码、又不想被“正确的废话”糊弄的开发者和安全测试人员。文章里没有藏着掖着的理论，全是能直接用的东西。

1. 为什么让 AI 换三个专家身份审代码，而不是一次性问它“帮我看看”

很多人的第一反应是，AI 那么强，直接问它“这段代码有什么问题”不就完了吗？实测下来的结论是：不行。这不是模型能力问题，是提问方式问题。

1.1 一次普通提问，得到的往往是“阳光版”回答

大模型默认的输出策略是“礼貌且有帮助的”。你让它“帮我看代码”，它会倾向给一个折中的、积极的反馈——因为你没说希望它挑刺，它就不会主动把自己切换到“毒舌模式”。于是你拿到的基本是：代码整体结构不错，建议增加单元测试，注意变量命名……这种话你让实习生看一眼代码也能写出来。

更麻烦的是，普通提问下模型会自行选择关注点。同一段代码，这次它可能盯着性能，下次它盯着命名，再下次它突然聊起架构。审查结果不稳定，没有统一标准，你就没法依赖它发现深层问题。

1.2 角色分离的本质：把大模型的“好人”人格锁起来

用角色扮演提示词，本质上是把大模型的默认人格“关掉”，强制它加载另一套行为模式。你告诉它“你是一个尖刻的、有 10 年经验的资深工程师，你的任务是在这段代码里找出所有问题，并且不许客套”，它的输出风格和关注点就会随即切换。

这个机制在认知科学上有个通俗的解释：人收到不同的任务指令，大脑会激活不同的知识网络。大模型也是类似的——给它不同角色，它调用的“知识分布”就不同。挑刺专家会优先关注逻辑分支和边界条件，漏洞专家会优先关注输入验证和攻击面，测试专家会优先关注覆盖率和用例设计。三双眼睛看的是同一段代码，但看到的完全是不同的东西。

我把三个专家的分工做成了一张对照表，方便理解：

这三个角色不是重复劳动，而是互补覆盖。逻辑审查查的是“这代码在正常情况下跑得对不对”，漏洞审查查的是“这代码在恶意输入下会不会崩”，测试审查查的是“哪些场景根本没人验证过”——三者交集之处，才是真正的代码质量盲区。

1.3 到底怎么定“人设”，才能让 AI 不客套、不跑偏

这里有个小技巧值得单独说。给角色的描述不能太短，比如只说“你是代码审查专家”是不够的。模型会认为这句话只是一个角色标签，行为上不会产生质的改变。要给它一个“任务边界、行为规范、输出格式”三合一的完整设定。

任务边界告诉模型这次审什么；行为规范告诉模型不许说什么、必须说什么；输出格式决定它是给列表、表格还是带行号的报告。三者齐全，模型的输出才会真正有用。后文我会给出三份完整的提示词模板，直接复制改成你的项目就行。

2. 三位专家的提示词设计：三份可直接复制的模板

这套方法的核心资产就是提示词。我用过很多版本，下面这三份是目前效果最稳定的。

2.1 挑刺专家：先把“逻辑怪怪的”变成具体问题

挑刺专家的提示词我这样写：

现在你是一位有 10 年一线开发经验的资深软件工程师，性格直率，讲究逻辑，讨厌废话。下面我会给你一段代码，请你以代码审查（Code Review）的方式审查它。 审查维度： 1. 逻辑错误与边界条件：空值、越界、数值溢出、并发竞争、资源未释放等 2. 可维护性：命名是否表意、函数是否过长、职责是否混乱、是否存在重复代码 3. 性能隐患：不必要的循环、重复计算、N+1 查询、缓存使用不当 4. 异常处理：是否吞掉了异常、错误分类是否合理、是否有恢复机制 输出要求： - 每条问题按严重程度分级，使用“严重 / 中等 / 轻微”三级 - 每条问题给出所在位置（函数名或具体行号）、问题描述、修改建议 - 某一方面确实没有问题就直接跳过，不要写“这方面表现良好”这类客套话 - 严禁输出“仅供参考”“建议优化”等无意义表述，所有建议必须具体可执行

这里的关键是“严禁输出无意义表述”这一条。不加上这句话，模型还是会忍不住写一些正确的废话。加上之后，输出会明显变得更尖锐、更具体。

我试过把同一段带空指针隐患的代码分别用普通提问和这个提示词去测。普通提问下模型甚至没有提到那段可能空指针的代码；用挑刺专家提示词后，它不仅指出了空指针，还补充了“当列表为空时会直接报 IndexError，而调用方并没有捕获它”——这是靠代码逻辑推演才看得出来的。

2.2 漏洞专家：让 AI 戴上安全审计的眼镜

安全审查比逻辑审查更依赖“专业视角”，因为有些漏洞在正常逻辑下完全看不出来，只有在特定攻击场景下才会触发。漏洞专家的提示词：

现在你是一位资深应用安全工程师，精通 OWASP Top 10、CWE 漏洞分类和渗透测试。我将给你一段代码，请以安全审计的方式检查它。 重点排查方向： - 注入类：SQL 注入、命令注入、代码注入（重点看用户输入是否被直接拼接进敏感操作） - XSS 与输出编码：前端输出是否转义、是否使用了 innerHTML 等危险方法 - SSRF：外部 URL 是否可控、是否缺少协议和域名限制 - 路径穿越：文件路径拼接是否规范化、是否使用 os.path.realpath 校验 - 反序列化：是否反序列化了不可信数据、是否缺少类型校验 - 越权访问：接口是否校验用户身份与资源归属 - 敏感信息泄露：硬编码密钥、Token 泄露、日志中打印敏感数据 输出要求： - 每条安全问题标注 CWE 编号与风险等级（高/中/低） - 用一句话描述攻击者如何利用该问题，例如构造什么样的 payload - 给出修复建议，并附上修复后的关键代码示例 - 如果没有发现某个方向的问题，直接跳过该方向，不要写“未发现安全隐患”

“用一句话描述攻击者如何利用”是整份提示词里最出效果的一条。因为大模型被要求“讲一个攻击故事”，它就必须把代码执行流程推演一遍，推演过程中容易发现逻辑断点。我遇到过一次很典型的场景：一段下载文件的接口，普通检查完全看不出问题，但漏洞专家提示词直接推演出“文件名来自 URL 参数，攻击者传 ../../etc/passwd 就能读到服务器任意文件”，判断依据是 CWE-22 路径穿越——这就是角色设定对输出质量的提升。

2.3 测试专家：问“有没有测试”太基础，要问“盲区在哪”

最后一个专家是测试专家。很多开发者自己写代码不写测试，让 AI 补测试的价值就在这。但要让它真正帮上忙，问题不能只停留在“请帮我写测试”。

现在你是一位测试架构师，擅长单元测试、集成测试和测试用例设计。请为以下代码设计一套完整的测试补充方案。 任务步骤： 1. 分析被测代码的输入域与输出域 2. 找出当前测试覆盖的盲区：happy path 之外的分支、异常输入、边界值、空值 3. 设计测试用例，覆盖正常流程、异常流程、边界条件、并发场景、安全场景 4. 给出最小必要测试集，标注每个用例应当放到单元测试层还是集成测试层 输出要求： - 用 Markdown 表格输出测试用例，包含字段：用例名称、测试数据、预期结果、对应检查点 - 对每个用例补充一句说明，解释“为什么测这个” - 如果被测代码没有现有测试，直接给出最小测试集即可，不要先批评代码没有测试

注意最后一条，“不要先批评代码没有测试”——这是防止模型跑偏的关键约束。我最初版本没有这句话，结果模型花了三分之一篇幅在讲“这段代码测试覆盖率为零，非常危险，建议立即补充”，正事没干多少。加上约束后，它就老实输出用例表格了。

2.4 三份提示词的共同点：可量化、可定位、禁止空话

回头看这三份提示词，它们的骨架是相同的，可以提取成一套通用公式：

• 角色加载（明确资历与性格）
• 审查维度清单（告诉模型看哪几类问题）
• 输出格式要求（分级、定位、给出建议）
• 禁止事项（不许客套、不许空谈、不许跑题）

这套公式适用于任何代码审查场景。你可以把维度清单换成大数据性能、前端兼容性、算法复杂度，甚至换成去审查一段 SQL 脚本，模板都不会失效。这也是我觉得这套方法比单个“代码审查”提示词更值得分享的原因——它不是死板的一招，而是一种可迁移的思维框架。

3. 实操全流程：从贴代码到输出一份能用的审查报告

提示词有了，接下来是操作流程。我自己迭代过好几轮，下面的流程是效率最高、结果最稳定的一版。

3.1 喂代码前的关键一步：用一段话交代背景

很多人直接把代码扔给 AI，然后问“有问题吗”。这种做法的误差很大。大模型不了解你的代码是干什么的、目标是什么环境、哪个部分是核心逻辑，它就只能在通用层面提建议。

我会在贴代码之前先给一段 Context，例如：

这是一个 Flask 写的文件下载接口，Python 3.10，运行在 Linux 服务器上。 核心逻辑是 verify_token -> read_file -> send_file，其中 verify_token 校验用户身份， read_file 按文件名读取服务器本地文件。 重点关注登录绕过和文件读取的安全性，另外函数 read_file 的边界条件请重点检查。

给大模型交代的项目背景，其实和给新入职同事交代的背景是一样的：它的职责边界、核心流程、你最担心的风险点。模型带上这些信息后再审代码，就不会出现“这段代码应该加数据库索引”这种八竿子打不着的建议。

3.2 跑了三轮，分别拿到三份报告

实操时我会开三个独立的对话窗口，或者在一个对话里分三段进行。推荐用三个独立窗口，因为独立上下文可以避免角色之间互相干扰。

第一轮：贴代码 + 挑刺专家提示词，等它输出问题清单。

第二轮：贴同样的代码 + 漏洞专家提示词。这里要说个经验：第二轮我会把第一轮的输出“藏起来”，不提前让漏洞专家看到。否则它会顺着挑刺专家的思路走，丧失了独立视角。三个角色独立审查，再合并结果，效果最好。

第三轮：贴代码 + 测试专家提示词。测试专家的输出是一张用例表格，这时候我通常会让它结合代码的实际情况给出测试数据示例，而不是只写“测试数据：空字符串”这种干巴巴的描述。

实际跑下来一轮的时间大概是：挑刺专家 30～60 秒，漏洞专家 60～90 秒，测试专家 60 秒左右。整个流程 5 分钟内可以完成，而人工 review 同样的代码至少要 20 分钟以上，而且不一定想得这么全。

3.3 第四步：让 AI 当主持人，把三份报告汇总排序

三份报告拿在手里，信息量很大但比较零散。挑刺专家列了 12 条，漏洞专家列了 5 条，测试专家列了 20 个用例。哪几个是马上要处理的？哪几个是随手改了就行？这时候我会再开一个对话，把三份报告一起贴进去，用一段汇总提示词：

你是项目经理。这是三位工程师分别 review 同一段代码后的输出： [贴三份输出] 请合并去重，按以下优先级给出一份总报告： 一、必须立即修复（存在安全风险或会导致功能崩溃） 二、建议本轮修复（明显的逻辑 bug） 三、可以后续优化（风格、结构、测试补充） 对每一个问题标注来源（来自挑刺/漏洞/测试），并在表格最后列出“当前已有的测试用例清单”。

这一步很像让三个专家坐在一起开会，AI 当主持人。它做的工作主要是去重和排序，模型对这两类任务完成度很高，基本不需要人工再整理格式。最终拿到手的，就是一份可以直接照着改代码的问题清单。

我自己跑完整个流程后有个很直观的感受：单独用任意一个专家，都会有漏检；三个专家加汇总，所有类型的问题都能被覆盖到。有一次在同一个接口里，挑刺专家发现了“sess 查询可能返回 None”，漏洞专家发现了“用户传入的 product_id 直接拼进 SQL”，测试专家发现了“价格字段没有测过负数”。这三类问题如果只问一次 AI，最多被问出来一条，还大概率是最不痛不痒的那条。

4. 避坑实录：AI 审查常见的五个坑

方法好用归好用，坑也不少。这部分是我实际踩过的，整理成了五个高频问题。

4.1 最大的坑：AI 会一本正经地胡说八道

大模型存在幻觉问题，在代码审查场景里表现得尤其隐蔽。它会引用一个根本不存在的 CVE 编号，可能会说“这里存在 CVE-2024-38819 漏洞”但细看代码根本没有对应风险；它还可能编造行号，说第 45 行有问题，但你的代码总共才 30 行。

遇到 AI 输出的安全问题，必须人工验证。我的验证方法是：先看它说的位置是否存在，再按它描述的攻击路径在本地写一个最小复现脚本，能打穿才算数。有一次它信誓旦旦说“这里的 SQL 拼接可被注入”，我跟踪下去发现参数被框架的 ORM 参数化了，根本不存在注入风险。所以记住这句话：AI 审查是放大器，不是裁决者。它的输出必须经过一次人工复核，才配叫结论。

4.2 单轮审查覆盖面太窄，要用“多轮追问”逼出细节

第一次跑出来的报告往往只能覆盖 60% 的问题。剩下 40% 藏在细节里，需要追问逼出来。我常用的追问句式：

- “针对上面第 3 条，攻击者还有哪些变体 payload 能绕过建议的过滤器？” - “这个函数在并发调用下会怎样？请推演 10 个线程同时访问的场景。” - “如果上游依赖升级到 2.0 版本，这段代码会出什么问题？”

这种追问本质上是在逼模型做“思维链推演”。它被迫把执行路径一步步展开，很多平时收敛在概率分布里的问题会被显式地暴露出来。

4.3 代码太长喂不进去怎么办：按函数维度拆，而不是按行数拆

上下文窗口有上限，一次塞整个项目不现实。我的做法是：只挑核心文件的关键函数喂，而不是把整个文件复制进去。

比如审查一个 Web API，我会抽四个部分：路由入口函数、数据库查询函数、文件处理函数、鉴权函数。每个函数单独跑一轮三个专家，耗时翻倍但效果值得。还有一个替代方案：先用普通提问让 AI 输出“这份文件的函数清单”，再按清单批量投喂，效率更高。

对于超过上下文窗口的较大项目，也可以用“分层审查”：先审路由层，再审服务层，最后审数据层。每一层单独出报告，汇总时按模块归档。这个方式比一次性硬塞更贴合实际代码审查的粒度。

4.4 新版代码和旧版代码混着喂，模型会彻底混乱

有一次我把两个版本的同一文件同时贴给了 AI，想让它对比差异，结果它输出了一份逻辑上完全矛盾的审查报告——一会说“第 40 行调用了 validate_params”，一会说“该函数不存在”。原因就是我贴进去的两个版本，接口签名不一样，模型不知道以哪个版本为准。

解决方法是保持单一版本审查，如果要对比版本差异，让模型分离成两次审查，最后人工对比。这个坑很容易被忽略，因为模型不会告诉你它混乱了，它只会自信地给出一个混乱的答案。

4.5 别把 AI 的结论直接刷进工单或者 commit 信息里

最后一点，也是团队协作中最容易出问题的点。我见过有人拿 AI 的审查报告直接贴到代码评审系统里当评论，结果被同事指出来“第 3 条说得不对”。我自己的处理方式是：把 AI 输出当草稿，经人工确认后，用自己的语言重新组织一遍再提给别人。这不仅是面子问题，更是责任问题——AI 的分析作为参考有价值，但它不是权威，也不会为你的代码负责。

这里我整理了一张常见问题速查表，方便对照排查：

5. 实测效果与扩展玩法

用这套方法跑了小半年，覆盖了登录接口、文件上传、订单支付逻辑、后台数据导出这几个常见场景，全部都有真实收获。最夸张的一次，是漏洞专家在一段文件上传代码里发现了一个没有限制文件类型的接口，攻击者可以直接传一个 .html 文件上去，变成存储型 XSS——这个要是真上线，后果够喝一壶的。挑刺专家还顺手发现上传的文件名没有随机化处理，会覆盖同名文件，这俩问题加一起，基本把一个高危漏洞讲透了。

当然也不是没遇到过失手。有一次测试专家设计了一堆用例，结果我看完发现它针对的函数根本不是代码里的函数——它根据函数名自己脑补了一个逻辑。所以测试专家的输出我一般只看用例设计思路，具体测试数据是否匹配代码，还是得人工确认。

5.1 扩展玩法一：让 AI 模拟“攻击者”来反驳自己

审完一轮后，我会追加一个刁钻问题：

现在你是攻击者，这段代码是你的目标。请针对上述安全修复方案， 思考至少 3 种绕过方式，然后评估现有修复是否站得住。

这个提问相当于做了一次“红队复盘”。模型会主动寻找修复方案的盲点，补上第一轮审查的缺失。我多次用这招发现修复方案本身不完整，比如只过滤了单引号没过滤双引号、只限制 URL 协议没限制内网地址之类。

5.2 扩展玩法二：把三专家流程做成一个自动化脚本

这套流程其实可以脚本化。用 Python 调大模型 API，把“代码 + 三段提示词”拼成固定模板，跑完合并出 Markdown 报告。我试过用 LangChain 的链式调用来做，每一步一个 Prompt，最后汇总，效果很稳定。考虑到现成工具很多，即便不写代码，市面上主流的大模型客户端也都支持多轮对话和自定义提示词，手动操作完全够用。

5.3 扩展玩法三：适配不同语言和框架

提示词里的审查维度可以根据语言特性做微调。审查 Go 代码时我会加“goroutine 泄漏”和“channel 误用”；审查前端 JavaScript 时会加“闭包变量泄漏”和“事件监听未销毁”；审查 Solidity 合约时会加“重入攻击”和“整数溢出”并配合实际案例中的典型问题类型去验证。三个角色框架不变，只换维度清单，十几秒就能生成一套适合新语言的新提示词。

最后再分享一个小技巧：审查完成后，我会把“问题清单 + 修复方案”喂回模型，让它“给自己两周后的自己留一句话”，总结这些代码最容易在未来上线后爆雷的地方。这句话我会写进代码仓库的 README 备注里，提醒以后的维护同事。这个用法有点取巧，但实际效果比写一大段抽象文档有用得多——因为它帮你把这次审查浓缩成了一段“未来预警”。