Grok 4.5 代码审查助手提示词设计方法

如果直接把代码丢给 Grok 4.5，得到的审查意见往往是在复述“代码没问题”或“建议优化性能”这类泛泛结论。要让 Grok 4.5 输出可用的代码审查意见，需要先把审查范围、输出格式、禁止行为写成清晰约束，并准备两个样本做对比测试，逐步把提示词调成适合当前代码库的状态。

设计要点：提示词必须限定审查维度、要求逐行定位、指定输出结构，同时明确禁止空泛建议。适用场景：代码片段审查、MR/PR 初审。操作动作：把提示词复制到 Grok，粘贴代码并注明上下文。验证方式：用两个有问题的片段对比调整前后输出。风险边界：提示词效果随模型版本和代码类型变化，不能一次调好，需要结合具体环境确认。

确定审查要点和输入格式

代码审查提示词的第一个任务是让模型知道“看什么”。你不提维度，模型就会按自己的理解挑几个问题说，覆盖面随机。

建议在提示词里明确列出审查维度，通常包括：

安全性：SQL 注入、命令注入、硬编码密钥、敏感信息暴露。
性能：不必要的循环、N+1 查询、在循环内执行 IO 操作。
健壮性：异常处理缺失、边界条件、空指针风险。
可读性：命名是否清晰、函数是否过长、逻辑是否重复。
兼容性：改动是否影响旧接口或外部调用。

输入格式也要固定。让用户用代码块粘贴完整片段，并在代码块前注明语言、框架、上下文。例如：

以下代码来自 Python/Flask 的订单接口，功能是更新订单状态。
审查重点：安全性和边界条件。

def update_order(order_id, status):
    sql = "UPDATE orders SET status = '" + status + "' WHERE id = " + order_id
    db.execute(sql)

注意这里只是示例，实际粘贴时把代码放在代码块中，Grok 才能区分代码和说明文字。

编写带约束的角色提示词

光列维度还不够，模型需要知道自己的身份和输出约束。下面是一个可直接复制的提示词模板，你可以把维度列表替换成自己的关注点。

你是一名资深代码审查工程师。你的任务是对用户提供的代码做静态审查，不执行代码，也不生成测试用例。

审查维度：
- 安全性：注入、硬编码密钥、越权访问
- 性能：热点循环、数据库查询次数、资源泄漏
- 健壮性：异常处理、边界条件、并发问题
- 可读性：命名、函数长度、逻辑复杂度

输出格式：
按问题严重级别从高到低列出，每个问题必须包含：
行号、问题类型、严重级别（高/中/低）、问题描述、修改建议。

禁止行为：
- 不要输出代码中没有依据的猜测
- 不要只说"建议优化性能"，必须给出具体位置和修改方向
- 不要修改用户提供的代码，只在建议中说明怎么改
- 如果代码没有发现某个维度的问题，就写"未发现"，不要强行凑数

这个模板的关键是把“禁止行为”写清楚，因为模型经常倾向于输出安全但无用的套话。你可以根据业务场景增加“只审查改动行”或“忽略测试代码”等限制。

设计输出结构示例

为了让审查结果能被快速定位和分类，建议在提示词中指定一个固定的输出结构。下面是一个示例，字段可以增减，但需要保持一致性。

审查结果：

1. [高/中/低] 行号：12，问题类型：SQL注入
   - 描述：直接拼接用户输入到 SQL 查询
   - 建议：使用参数化查询，例如 cursor.execute("update ...")

2. [中] 行号：20，问题类型：性能
   - 描述：循环内调用 send_email，可能造成阻塞
   - 建议：将邮件发送放入队列，或使用异步任务
...

要求模型输出这种结构，比让模型自由组织语言更容易提取关键信息。实际使用时，可以把问题级别限定为你习惯的等级，如“严重/一般/提示”。

迭代调优提示词的测试流程

提示词不是写一次就能用，需要准备两个有问题的代码片段作为测试样本，观察调整前后输出差异。

下面两个片段，每个都包含明显问题，适合用来测试。

# 片段A：Python
user_input = request.args.get('name')
query = 'SELECT * FROM users WHERE username = ' + user_input
db.execute(query)

# 片段B：JavaScript
for (let i = 0; i < items.length; i++) {
  const result = await db.query('SELECT ... WHERE id = ' + items[i]);
  process(result);
}

测试流程：

先用最简提示词“请审查这段代码”，记录输出。
换用带维度和输出结构的提示词，再对同一片段运行。
比较两次输出的差异，重点看：问题数量是否增加、定位是否准确、建议是否具体。
如果某个维度漏检，就把该维度写成更具体的禁止行为或增加例子。

例如，第一次输出可能只有“可能存在 SQL 注入”，改进后能给出“行号 2，拼接 user_input 导致的注入，建议改用参数化查询”这样的结果。通过反复对比两个样本，可以快速找到当前提示词的弱点。