Gemini代码评审提示词怎么写？精选实用技巧

先说个核心判断：用Gemini做代码评审，如果提示词写得模糊或太泛，它会跳过关键逻辑漏洞、忽略安全边界、甚至把有缺陷的代码当成“风格问题”一带而过。要让模型真正发挥作用，关键在于明确评审目标、关注维度、上下文边界和输出格式。

明确评审目标与角色设定

第一步：在提示词开头直接定义Gemini的角色和任务性质。别指望一句“帮我看看这段代码”，Gemini就会认真对待。应该写成：“你是一名有5年后端开发经验的安全导向型代码评审员，本次任务是严格审查以下Python函数是否存在可利用的注入风险、权限绕过或资源泄漏”。角色越具体，模型越少自由发挥，评审结果才越靠谱。

第二步：用【必须拒绝评审未提供上下文的代码片段】作为硬性前提。如果只丢一段孤立函数，Gemini容易基于通用假设去“补全”逻辑，结果很可能偏离真实调用链。必须要求附带调用方示例、输入来源（如HTTP参数/数据库读取）、依赖库版本。上下文越完整，评审越精准。

指定必须检查的维度

方法一：按严重性分层列出检查项，让Gemini知道轻重缓急：

① 高危项（发现即标红）：SQL拼接、eval/exec调用、用户输入直入系统命令、硬编码密钥、未校验的反序列化入口。这类问题一旦出现，必须优先处理。

② 中危项（需说明修复路径）：缺失输入长度限制、日志打印敏感字段、异常捕获后吞掉错误信息。这类问题需要给出明确修复方案，不能只说“建议优化”。

③ 低危项（仅当存在才提）：PEP8风格违规、变量命名不一致。这类问题可以作为附带提醒，但不应该成为评审重点。

方法二：绑定业务场景限定范围。脱离业务谈“代码质量”，等于无效评审。例如：“本服务处理金融转账请求，请重点验证account_id是否经OAuth scope校验、金额是否二次服务端校验、幂等token是否被正确解析并查重”。业务场景锚定后，Gemini才能抓住真正的评审重点。

控制输出格式与颗粒度

要求Gemini用表格形式返回结果：第一列“问题位置（行号+代码片段）”，第二列“问题类型（高危/中危/低危）”，第三列“依据（引用OWASP Top 10或CWE编号）”，第四列“修复建议（给出可粘贴的修改后代码行）”。禁止出现“建议优化”“可以考虑”这类模糊表述，必须明确具体。

这一步操作起来很简单，直接把文件拖进去就行。但要注意：【若输出中间出现‘可能’‘或许’‘一般建议’等不确定性词汇，立即终止本次评审并重写提示词】。评审结果的确定性，直接决定了它是否有实际价值。