代码审查推理提示词的目标不是让模型简单地说出代码哪里不好，而是要求它按照特定推理路径判断代码是否存在安全风险与性能问题。很多通用提示词只包含一句请审查以下代码，模型自然会倾向于输出最容易被接受的意见，例如命名不规范、函数过长或缺少注释。这些意见并非错误，但它们无法替代针对SQL注入、越权访问、算法复杂度退化、无效数据库查询等实质性问题的检查。要让模型在安全与性能维度上给出可靠结论，需要从提示词结构、角色设定、推理步骤和输出格式四个层面重新设计。
一、为什么通用代码审查提示词容易漏掉严重问题
通用提示词的最大问题是缺乏推理目标。当用户输入请帮我审查这段代码时，模型会把任务理解为给出改进建议，而不是按风险等级追踪缺陷。由于安全漏洞和性能瓶颈通常需要跨函数、跨模块甚至跨信任边界分析，模型在没有明确指令的情况下很难自动采用攻击者视角或性能剖析视角。于是输出结果往往偏向代码风格、可读性和简单重构建议，因为这些内容在代码文本中更直观，也更容易生成。
例如下面这段代码包含一个明显的SQL注入风险，同时存在循环内重复查询数据库的性能问题。如果提示词只要求审查代码，模型可能只提到变量命名不够清晰，或建议将SQL语句提取为常量。只有当提示词显式要求分析所有外部输入如何进入SQL命令，以及循环体内是否存在重复I/O时，模型才会沿着安全与性能两条推理链查找问题。
def get_user_orders(customer_id):
orders = []
for row in fetch_all_rows("SELECT id FROM orders"):
order = db.query("SELECT * FROM order_items WHERE order_id = " + row["id"])
if order["customer_id"] == customer_id:
orders.append(order)
return orders
要让模型稳定发现这类问题，提示词必须将任务从模糊审查转化为结构化推理。关键做法包括：明确要求模型先列出所有外部输入，再跟踪这些输入是否进入敏感操作；要求模型对每一个循环和查询评估时间复杂度与I/O次数；最后要求模型给出证据路径，而不是只给结论。这样即使模型输出不算完美，推理链也能暴露出它是否真正检查了关键风险。
二、安全漏洞推理Prompt的设计要点
安全漏洞推理提示词应当从攻击面识别开始，而不是从代码风格开始。提示词可以要求模型先找出代码中所有来自用户请求、文件内容、第三方接口或环境变量的输入，然后判断这些输入是否被直接拼接到SQL语句、命令执行、文件路径、HTML输出、反序列化过程或权限判断中。这样的推理顺序会强制模型关注信任边界，从而减少漏掉注入类漏洞的情况。
除了注入类问题，还应当要求模型检查身份认证与授权逻辑。很多业务代码在获取当前用户后，并没有校验该用户是否有权访问指定资源。提示词可以加入明确规则：如果代码中存在根据ID查询资源的操作，必须判断是否校验了资源归属；如果存在管理员功能，必须判断是否进行了权限分离。这样模型就不会只盯着语法问题，而是会从越权访问角度审查业务流程。
一个可复用的安全审查Prompt模板如下。它把角色、威胁模型、推理顺序和证据要求都写清楚，模型可以按照固定方式输出，便于后续验证和筛选。
你是一名安全代码审查专家。请以攻击者视角审查下面的代码，重点查找可被利用的安全漏洞。 审查步骤： 1. 列出所有外部输入来源，包括HTTP参数、请求体、文件、环境变量、第三方返回数据。 2. 追踪每个外部输入到达的敏感操作，包括SQL拼接、命令执行、路径拼接、HTML渲染、反序列化、权限判断。 3. 判断是否存在缺失的身份认证或越权访问。 4. 检查敏感信息是否被明文记录、返回或输出。 输出要求： - 漏洞名称 - 触发路径 - 风险等级：高、中、低 - 可利用条件 - 修复建议 - 验证方式 如果没有发现漏洞，也要说明你追踪了哪些输入与敏感操作。
这个模板的关键在于不给模型跳过安全分析的机会。询问如果没有发现漏洞也要说明追踪过程，能够促使模型真正执行输入追踪，而不是直接输出未发现漏洞。对于批量代码审查或CI场景，还可以要求模型输出JSON格式，方便后续自动化解析和告警聚合。
三、性能问题推理Prompt的设计要点
性能问题通常不像安全漏洞那样有明确的攻击路径，但同样可以通过推理提示词来定位。性能推理的核心是要求模型识别重复计算、不必要的I/O、低效数据结构和不合理的算法复杂度。提示词可以让模型先标记所有循环、递归、数据库访问、网络调用和文件读写，然后逐项分析这些操作的执行频率与代价。
例如循环内查询数据库是性能审查中最典型的问题之一。模型如果只是通读代码，可能会认为代码逻辑正确而忽略N+1查询。提示词应当明确指出：如果一个查询位于循环体内，且查询参数来自循环变量，则大概率存在N+1查询问题，需要判断是否可以合并查询、批量加载或使用缓存。类似地，对列表执行成员判断时，如果列表规模较大且重复执行，可能存在O(n)查找被错误用于热路径的问题。
以下是一个性能审查Prompt模板，它要求模型以复杂度和I/O次数为证据，而不是凭感觉判断性能好坏。
你是一名性能优化专家。请审查下面的代码，找出影响性能的关键问题，并给出可验证的优化建议。 分析步骤： 1. 标出所有循环、递归、数据库查询、远程调用、文件读取操作。 2. 对每个循环分析时间复杂度，并判断循环体内是否存在重复I/O。 3. 检查是否存在N+1查询、无限制分页、缺失索引、重复计算或大对象拷贝。 4. 分析缓存策略是否合理，是否存在缓存穿透、缓存雪崩风险。 5. 判断并发场景下是否存在锁粒度过大、临界区过长或共享资源竞争。 输出要求： - 问题位置 - 问题类型 - 当前复杂度或I/O次数 - 触发条件 - 优化方案 - 优化后复杂度预估 - 验证方法
要求模型给出当前复杂度与优化后复杂度预估，可以把性能建议变成可以比较、可以验证的结果。模型在回答时会倾向于进行实际代码分析，而不是只说这段代码可能性能较差。对于复杂项目，还可以在提示词中提供数据库表结构、索引信息和典型数据量，让模型基于更真实的输入进行推理。
四、将安全与性能合并到同一条推理提示词中
在实际代码审查中，安全问题和性能问题往往交替出现。例如一个接口先查询全部数据再在内存中过滤，既可能造成内存占用过高，也可能因为把过多数据返回给前端而暴露敏感字段。因此，将安全与性能合并到一个推理提示词中，可以让模型从两个维度同时审视代码，避免分两次调用带来的上下文割裂。
合并提示词时，可以采用分阶段推理结构。第一阶段先做安全分析，第二阶段做性能分析，第三阶段输出合并结论。这样模型在安全分析阶段建立的输入追踪结果，可以直接复用到性能分析阶段，例如某个输入先被拼接到SQL语句中，又在循环内被重复查询，这种关联在单次推理中更容易被发现。
你是一名资深代码审查工程师。请对以下代码执行两阶段推理审查。 第一阶段：安全推理 - 追踪外部输入到敏感操作的完整路径。 - 检查注入、越权、敏感信息泄露、不安全加密。 第二阶段：性能推理 - 定位循环、查询、I/O和重复计算。 - 检查N+1查询、无限制结果集、高复杂度算法。 第三阶段：合并判断 - 按严重程度排序输出所有问题。 - 对每个问题说明它属于安全问题还是性能问题。 - 给出触发路径、风险等级、修复建议和验证方式。 要求：不得输出与安全和性能无关的风格建议。
这种合并方式的优点是减少模型输出的无关内容，把审查范围严格限定在安全和性能两个维度。当模型试图跳回变量命名或注释建议时，提示词末尾的限制条件会把它拉回主线。对于团队协作，还可以将这类提示词保存为内部代码审查规范的一部分，保证不同成员调用大模型时获得一致的问题分类。
五、推理Prompt的输出格式与验证方法
模糊的自然语言输出虽然易读，但在工程流程中难以复用。好的推理提示词应当为输出指定稳定格式，最好使用表格或JSON结构。例如安全漏洞可以输出为漏洞名称、触发路径、风险等级、修复建议和验证方法五列，性能问题可以输出为问题位置、当前复杂度、优化方案和预期提升四列。这样审查结果可以直接进入缺陷跟踪系统，也便于后续统计模型漏报率。
为了让模型输出可验证结论，提示词可以要求每个问题都附带触发条件与验证代码。例如对于SQL注入问题，要求模型给出一个可能导致注入的输入示例；对于N+1查询问题，要求模型给出循环次数与查询次数的对应关系。这样审查人员可以快速验证模型是否正确，而不是被看似专业的描述说服。
{
"issues": [
{
"type": "security",
"title": "SQL注入",
"severity": "high",
"path": "request.customer_id -> db.query",
"trigger": "customer_id=1 OR 1=1",
"fix": "使用参数化查询",
"verify": "输入恶意customer_id后观察返回数据"
},
{
"type": "performance",
"title": "N+1查询",
"severity": "medium",
"path": "for row in rows -> db.query",
"trigger": "orders表存在1000条记录时触发1001次查询",
"fix": "使用IN查询或批量关联查询",
"verify": "比较优化前后数据库查询次数"
}
]
}
在真实项目中，模型输出的JSON字段可能不完全符合团队要求，因此建议在提示词末尾加入一个小的格式约束检查。例如要求模型检查输出是否包含所有必填字段，如果不完整则重新生成。还可以将输出接入一个轻量校验脚本，解析JSON并检查字段完整性。这种方式成本很低，却能显著提升大模型在代码审查任务中的可用性。
六、工程化落地与持续优化提示词
代码审查推理提示词不应只在单次对话中使用，而应纳入团队提示词库进行版本管理。可以将安全审查、性能审查和合并审查三种模板分别存为独立文件，并记录每次修改的原因。随着项目业务逻辑变化，提示词也需要调整，例如新增文件上传功能后，安全审查模板应加入文件类型、路径穿越和恶意内容检查；新增缓存层后，性能模板应加入缓存一致性分析。
为了评估提示词质量，可以准备一组包含已知漏洞和性能缺陷的代码样例作为评测集。每次修改提示词后，让模型审查这些样例，统计安全漏洞的检出率、性能问题的定位准确率和无关建议数量。如果发现模型反复漏报某类问题，就在提示词中补充该问题的识别规则。持续迭代后，提示词会逐渐积累团队专属的审查经验。
工程化落地还可以将推理提示词与CI流程结合。例如在合并请求中调用大模型，把输出结果作为审查评论自动发布，并标记security或performance标签。但模型输出不应直接作为阻断合并的唯一依据，而应由人工确认关键风险。提示词可以要求模型对每个问题附上确定性说明，例如该问题是否容易被远程利用、是否依赖特定配置。这样做既利用了模型的分析效率，也保留了人对安全结论的最终判断权。