gemini代码评审需明确角色、上下文、检查维度和输出格式：设定安全导向评审员角色；强制提供调用链与输入来源；分高/中/低危三层检查项；绑定业务场景；输出结构化表格，禁用模糊表述。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Gemini做代码评审时，提示词写得模糊或太泛会导致它跳过关键逻辑漏洞、忽略安全边界、甚至把有缺陷的代码当成“风格问题”一带而过。你需要让模型明确知道评审目标、关注维度、上下文边界和输出格式。
明确评审目标与角色设定
第一步：在提示词开头直接定义Gemini的角色和任务性质。不要写“请帮忙看看这段代码”，而要写成“你是一名有5年后端开发经验的安全导向型代码评审员，本次任务是严格审查以下Python函数是否存在可利用的注入风险、权限绕过或资源泄漏”。角色越具体，模型越少自由发挥。
第二步：用【必须拒绝评审未提供上下文的代码片段】作为硬性前提。如果只丢一段孤立函数，Gemini容易基于通用假设补全逻辑，结果偏离真实调用链。必须要求附带调用方示例、输入来源（如HTTP参数/数据库读取）、依赖库版本。
指定必须检查的维度
方法一：按严重性分层列出检查项
① 高危项（发现即标红）：SQL拼接、eval/exec调用、用户输入直入系统命令、硬编码密钥、未校验的反序列化入口。
② 中危项（需说明修复路径）：缺失输入长度限制、日志打印敏感字段、异常捕获后吞掉错误信息。
③ 低危项（仅当存在才提）：PEP8风格违规、变量命名不一致。
方法二：绑定业务场景限定范围
例如：“本服务处理金融转账请求，请重点验证account_id是否经OAuth scope校验、金额是否二次服务端校验、幂等token是否被正确解析并查重”。脱离业务谈“代码质量”等于无效评审。
控制输出格式与颗粒度
要求Gemini用表格形式返回结果：第一列“问题位置（行号+代码片段）”，第二列“问题类型（高危/中危/低危）”，第三列“依据（引用OWASP Top 10或CWE编号）”，第四列“修复建议（给出可粘贴的修改后代码行）”。禁止出现“建议优化”“可以考虑”这类模糊表述。
这一步操作起来很简单，直接把文件拖进去就行。但要注意：【若输出中出现‘可能’‘或许’‘一般建议’等不确定性词汇，立即终止本次评审并重写提示词】。
