最近我一直在做一件事让AI切换成3个专家身份来审我的代码——一个负责挑刺一个负责找漏洞一个负责补测试。效果出乎意料很多平时Code Review里会被忽略的问题AI都能提前翻出来。这篇文章就是记录我这几轮折腾下来总结出的整套玩法包括提示词、审查流程、以及后来踩过的坑。如果你是自己写代码的独立开发者或者在带一个没有专职QA的小团队这套方法可以直接拿来用。1. 为什么是3个专家角色而不是一个万能AI1.1 一个AI同时干三件事效果并不好一开始我试过把“审查质量安全测试”写进同一个提示词里让AI一次给全结果看起来很全面但每块都不够深。代码审查本身是多目标的可维护性、安全性、测试完备性它们的判断维度和优先级完全不同混在一起很容易互相稀释。比如审查可读性时AI可能会纠结某一行代码会不会有被注入的风险转头去建议加过滤反而把结构优化建议带偏了。打个比方就像让一位医生同时看内科、外科和骨科。不是医生不专业而是注意力一分散诊断深度必然打折。AI也是一样角色明确之后每一条建议都会更聚焦也更像真正有经验的专家在说话。后来我把三个任务拆成三个独立会话每个会话只保留一个“人设”输出质量立刻提升了一个档次。还有一层原因跟上下文窗口有关系。现在主流AI模型都要在有限的上下文里做推理如果同时塞进去“代码质量、安全漏洞、测试设计”三套标准模型很容易顾此失彼。尤其是在审查长文件时前半段还按代码质量专家说话后半段就可能变成什么都掺一脚的“万能助手”。这种角色漂移对审查结果影响很大拆成单角色之后基本能避免。1.2 三个角色如何分工协作我的分工方式很固定每个角色只负责一块挑刺专家负责代码可读性、可维护性、性能隐患、设计模式和边界条件。安全审计员负责漏洞排查、输入校验、权限控制、敏感数据流和依赖安全。测试军师负责测试覆盖、边界值、异常路径、mock策略和CI集成。这三个角色不是各说各话而是有依赖顺序的。先让挑刺专家把结构和可读性改干净再让安全审计员做加固最后让测试军师补用例。如果顺序反过来测试用例很可能是针对旧接口写的等结构一改又得推倒重来浪费不少时间。另外每个角色都必须输出统一的“问题清单优先级是否阻塞”格式这样三份报告才能合并成一张可执行的任务表。后面我会给出可直接复制的提示词模板你只要把代码块替换成自己的代码就能用。2. 第一个身份挑刺专家专治代码质量和可维护性2.1 挑刺专家主要盯哪些点挑刺专家本质上是把资深工程师做Code Review时的经验沉淀成一套固定检查清单。我在实际提示词里会让AI重点盯下面这几类问题可读性命名是否语义化、函数是否过长、注释到底在解释“做了什么”还是“为什么这么做”。重复代码同一套逻辑是否在多处复制有没有提取公共方法的必要。复杂度循环嵌套、分支条件过深、函数入参超过五六个都是明显信号。异常处理异常有没有被静默吞掉资源有没有释放事务边界是否清晰。并发隐患共享变量是否被裸奔修改锁粒度是否合适异步回调顺序是否可控。性能问题循环内发请求、N1查询、字符串循环拼接这类问题。举个很简单的例子如果给AI下面这段代码def process(items): result [] for i in range(len(items)): for j in range(len(items)): if items[i] items[j] and i ! j: result.append(items[i]) return result挑刺专家应该很快指出双重循环导致O(n²)复杂度而且i和j相等时已经跳过但重复元素会反复被加入结果正确性也有问题。继续追问的话AI会给出用集合去重并统计频次的重构方案。这种能力在真实Code Review里非常实用因为人类看自己的代码很容易“亲妈滤镜”AI反而能不带感情地把问题点出来。2.2 可复用的挑刺提示词我目前用的挑刺提示词长这样你可以直接复制你现在是一位有10年经验的资深代码评审专家。请从代码可读性、可维护性、性能隐患、边界条件、设计模式这五个维度审查下面的代码。 对每个发现的问题请按以下格式输出 1. 问题位置函数名或行号 2. 问题说明 3. 严重级别高/中/低 4. 是否阻塞合并是/否 5. 具体修改建议 不要输出与问题无关的赞美也不要复述代码直接给结论。 [在这里粘贴代码]这里两个关键设计是“严重级别”和“是否阻塞合并”。没有这两个字段AI会给你列一大堆问题但你不知道哪些要立刻改、哪些可以攒着。一旦要求它给“是否阻塞”它就必须做优先级判断出来的结果更像一个负责任的老同事而不是一个只会挑毛病的机器人。实操中我还有一个习惯不要一次性把整个仓库喂进去一次只审一个文件或一个函数高效且不会让上下文爆炸。如果改了代码就给AI看diff而不是整段新代码这样它更容易识别改动有没有引入新问题。实测下来把项目结构和模块职责先一句话告诉AI再让它审查某个核心文件发现跨文件设计问题的概率会高很多。3. 第二个身份安全审计员专门追着漏洞跑3.1 安全审计的眼神应该放在哪里安全审计员这个角色最容易让人兴奋也最容易翻车。我要先说清楚我们聊的是防御性代码审查不是教你攻击。安全审计的核心是从数据流和信任边界入手看看哪些输入可能是不可信的哪些操作被放到不合适的权限上下文里执行了。我让AI重点关注这几类问题注入类SQL注入、命令注入、跨站脚本XSS本质都是“不可信输入拼接到了敏感操作里”。失效访问控制水平越权、垂直越权典型症状是判断用户身份时只依赖前端传参。不安全反序列化把外部输入直接扔给反序列化框架这在Java和Python里都出现过大量漏洞。路径穿越拼接文件路径时没过滤../这类特殊序列。硬编码敏感信息密钥、数据库地址、token直接写在代码里。使用含漏洞的组件依赖库版本过旧某些CVE编号就是针对特定版本组件的。这里想特别说一下“第三方依赖”。很多安全问题不在你自己的代码里而在你引用的库里面。我会把requirements.txt或package-lock.json摘出来喂给安全审计员让它识别哪些依赖存在已知风险模式然后去官方公告核对。AI不一定能记住最新的CVE编号但它可以帮你把“哪些库是老旧且敏感的”筛出来这本身就是价值。3.2 安全审查提示词与关键参数给安全审计员的提示词我会比挑刺专家更强调“触发条件”。模板如下你现在是一位资深应用安全工程师。请以攻击者的角度审视下面的代码但只输出防御性改进建议。 请按OWASP Top 10的分类逐项检查注入、失效身份认证、敏感数据暴露、XML外部实体、失效访问控制、安全配置错误、跨站脚本、不安全的反序列化、使用含漏洞的组件、日志与监控不足。 对每个风险请输出 1. 风险点位置 2. 触发条件必须具体到输入字段和调用路径 3. 可能造成的后果 4. 严重级别高/中/低 5. 防御性修复建议 注意只做防御性分析不输出任何攻击方法。 [在这里粘贴代码]“触发条件必须具体”这句特别重要。AI有时候会把“潜在风险”无限放大说这里可能有问题、那里也可能有问题但仔细一看根本触发不了。要求它写清触发条件后很多误报会自己消失。比如它说“用户输入可能导致路径穿越”你就追问一句“要经过哪些过滤在什么条件下才能真正构造出../”AI一推演就会承认限制很多。还有一条安全经验不要把密钥、数据库连接串、真实手机号/身份证号喂给AI。AI服务本身有自己的数据保留策略你无法控制它会不会被第三方看到。我平时会把敏感字段换成fake数据再让AI审即使AI给出的修复合入也不会牵涉真实生产数据。4. 第三个身份测试军师把没写的测试补上4.1 审查完代码之后为什么还要审测试很多团队的Code Review只看功能代码压根不管测试代码。结果就是代码写得很热闹但高危路径全裸奔。测试军师这个角色就是来解决这个问题它不仅看“现有代码对不对”还要看“哪些测试没写、为什么需要写、以及怎么写到点子上”。这背后的逻辑很简单代码审查看到的是“已经存在的代码”而测试设计看到的是“可能存在的未来场景”。一个函数今天能跑通正常输入不代表它能在并发、超时、磁盘满、外部服务挂掉的时候还能保持正确。测试军师存在的意义就是把这些容易被忽略的边界拉出来。在我实际使用中测试军师至少能产出三类东西缺失用例清单、可执行的pytest测试代码、以及针对现有测试的“无效断言”诊断。第三类特别容易被人忽略——很多测试函数跑一遍是绿的但它没有做任何有意义的断言等于什么都没测出来。4.2 让AI生成测试补全方案测试军师的提示词模板如下你现在是一位资深测试开发工程师非常熟悉pytest和自动化测试最佳实践。 请为下面的代码补全测试方案 1. 覆盖正常路径、异常路径、边界条件 2. 对每条用例说明设计意图 3. 测试代码使用pytest假设外部依赖都已mock 4. 每个测试函数只做一件事优先使用参数化 [在这里粘贴代码]举一个非常简单的函数def calculate_discount(price, is_vip): if price 0: raise ValueError(price must be 0) return price * 0.8 if is_vip else price * 0.9AI会很快给出类似下面的pytest用例import pytest def test_normal_user_discount(): assert calculate_discount(100, False) 90 def test_vip_discount(): assert calculate_discount(100, True) 80 def test_negative_price_raises(): with pytest.raises(ValueError): calculate_discount(-1, False) def test_zero_price_boundary(): assert calculate_discount(0, False) 0这段代码看起来简单但从测试设计角度看已经覆盖了正常路径、VIP分支、异常路径和边界值。真正有价值的不是这些基础用例而是当函数变成几百行、依赖多个外部服务时AI仍能帮你梳理mock策略和测试优先级。我会让它把用例按“高优/中优/低优”排列这样至少能保证核心路径先被保护起来。另外AI生成的测试也需要人工review。我遇到过它生成一个“测试”只调用了函数但没写断言看起来在跑实则毫无意义。所以要追加一条规则“每个测试函数必须包含至少一个明确断言最好结合参数化批量验证边界条件。”加了这条之后输出质量会明显提升。5. 三人联动的实操全流程5.1 喂给AI的材料怎么准备想让三个专家角色发挥稳定喂给他们的材料不能只有裸代码。我一般会准备四样东西代码文件或diff、一句话需求背景、关键依赖列表、已知风险项。需求背景尤其重要比如“这是一个对外提供JSON接口的后端服务”和“这是一个内部CLI工具”安全审查和测试设计的侧重点完全不一样。材料准备还有一个安全红线脱敏。提交给AI的任何代码都不要包含真实密钥、token、数据库连接串、个人信息。我在实际操作中会把敏感字段全部替换成fake_value或your_token_here然后再让AI审查。这样即使对话内容被AI服务记录或用于其他用途也不会造成真实资产泄露。如果你的代码仓库特别大别想着把整个项目一次性丢进去。先把模块结构树拆出来让AI识别高风险模块再对每个高风险模块分别开一个会话。这个“总览分模块”的组合是目前我在长文件上验证过最稳定的方案。5.2 三轮审查的推荐节奏我实际使用的流程分四步第一轮总览让通用AI看整个项目结构、核心模块职责和数据流方向输出一份“风险地图”。第二轮三个专家并行根据风险地图把高风险模块分别交给挑刺专家、安全审计员、测试军师三个独立会话让它们并行产出三份报告。第三轮人工汇总把三份报告合并去重、按优先级排序生成可执行任务清单。第四轮迭代回归修改完再让AI审patch确认没有引入新问题。为什么一定要并行而不是同一个会话里依次切换角色因为我在实际测试中发现同一个会话里切换角色会严重“串味”。AI第三个角色出场时经常忘记前面角色定下的规则又回到“万能助手”模式。三个独立窗口各干各的角色约束保持得最好最终报告也更干净。人工汇总这一步千万别跳过。AI三份报告里会有重复问题也可能有互相矛盾的建议比如安全审计员让你加全局过滤但挑刺专家提醒你全局过滤会影响性能。这种冲突只有人才能判断哪一种更适合当前业务场景。5.3 把审查结论接入CI/CD如果你一个人在本地跑这套流程已经很满足那可以不用管这一节。但只要你还有一个小团队或者项目经常有外部协作就应该把AI审查结论变成一条不会流失的流水线。比较简单的做法是在GitLab CI或其他CI平台里增加一个pytest任务先跑AI生成的测试用例跑挂了就把失败信息直接发到Merge Request评论里。再配合SonarQube之类的静态扫描工具做质量门禁让“复杂度超标”和“新增高危安全漏洞”都以数字形式出现在同一份报告里。我的原则是AI审查结果默认作为“建议”而非“硬门禁”。因为AI会误报直接卡住流水线会导致大家不再信任这套机制。但有一类结论可以作为硬门禁——AI明确指出且人工复核过的高危安全漏洞。安全漏洞这种问题是“宁可错杀不可放过”人工确认后把它变成阻塞合并条件是非常值得的。6. 踩坑记录与快速排查手册6.1 我在实际使用中踩过的坑先说最容易遇到的AI幻觉。它会一本正经地推荐一个并不存在的API或者“标准库函数”有时候连函数签名都是编的。解决办法是要求它在建议里注明出处或者在采纳前人工查一下文档。我吃过一次亏把AI推荐的“标准库函数”写到了代码里结果测试一跑直接ImportError特别尴尬。第二个坑是上下文丢失。文件一长AI就会忘记开头几行的关键定义导致它给出的建议基于一个被截断的上下文。这个问题跟模型能力有关但也跟你输入的方式有关。我的做法是先把文件的职责用一句话总结给AI再把文件拆成几个逻辑片段分段审查每段开始前都重复一遍关键约定。实测下来漏判率会下降不少。第三个坑是角色漂移。在长对话里AI很容易从“安全审计员”变成一个“什么都给建议的普通助手”。解决方法是每个会话都减少无关闲聊并且在每轮追问前都加一句“请继续以你当前角色输出”。如果角色已经漂移得厉害不要浪费时间纠正直接开新会话重新跑一遍更省事。6.2 如何验证AI结论避免引入新问题AI给的结论要像同事提交的代码一样被review不能因为它顶着“专家身份”就直接合并。我的验证方法是“最小复现”当安全审计员说某个接口存在高风险问题时我就让它把触发条件写成可运行的测试用例然后真正跑一遍看能不能复现。能复现的问题才值得修不能复现的可以降级为观察项。还有一条专门针对安全修改的经验AI改动了权限校验、加解密逻辑、token校验这类核心安全代码时一定要额外仔细审最好有第二个人工复核。因为AI生成的补丁可能只解决了表面症状却引入了新的逻辑漏洞。比如为了过滤XSSAI可能把所有输入都转义结果影响了业务层原本允许的富文本展示。这种情况在代码审查里非常常见。最后分享一个我一直在用的小技巧在每个提示词最后都加一句“请用表格汇总问题清单包含位置、原因、建议、优先级、是否阻塞”。这样三份角色报告可以轻松合并成一张任务表排序、指派、跟踪都特别顺手。我自己实际操作下来的体会是让AI换3个专家身份审代码本质上不是让AI替你思考而是帮你自己把该问的问题问全。以前我做Code Review脑子里也有一套检查清单但难免偷懒只挑眼熟的问题看。现在有了三份独立报告我反而被迫把代码从质量、安全和测试三个角度重新过了一遍很多隐患都在写进正式评论之前就被提前按住了。这套方法不完美但确实让我这个没有专职QA的小团队第一次感觉到了“有人在背后兜底”的踏实感。