要让Gemini在代码评审中给出具体、可执行的修改建议，关键在于用提示词锁死输出粒度和上下文锚点：明确评审依据、强制逐行定位、禁用模糊表达、绑定团队高频错误模式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
想让Gemini在代码评审中给出具体、可执行的修改建议，而不是泛泛而谈“建议优化”“考虑重构”，关键在于用提示词锁死它的输出粒度和上下文锚点。
明确限定评审依据
在提示词开头就写明：「你是一名资深后端工程师，正在评审一段Python Flask API代码。请严格基于以下三点展开评论：① 该函数是否直接暴露了未校验的用户输入；② 是否存在SQL字符串拼接；③ HTTP状态码是否与业务语义匹配。不讨论代码风格、注释密度或未来扩展性。」
这一步强制模型放弃自由发挥空间，避免它用“可读性待提升”这类空洞表述替代实质判断。
要求逐行锚定问题位置
在提示词中加入硬性指令：「每条意见必须包含：『文件名:行号』前缀（如 user_api.py:47），接着用『问题』『风险』『修复』三段式展开。不允许出现‘某处’‘部分逻辑’等模糊指代。」
例如正确输出应为：user_api.py:47 问题：request.args.get('id') 未做类型转换 → 风险：整型ID参数被传入字符串导致SQL注入 → 修复：改用 request.args.getint('id', 0) 并检查返回值是否为0。
【若未指定行号前缀，Gemini大概率退回笼统建议】
提供对比样例压制模糊表达
方法一：在提示词末尾附一个差样例+好样例对比：
❌ 差样例：“数据库查询可以考虑加缓存。”
✅ 好样例：“orders_service.py:112：当前每次GET /order/{id} 都直连MySQL → 缓存穿透风险 → 建议在Redis中设置空值缓存（EX 60），键格式为 'order_cache_null_{id}'。”
方法二：直接禁用高频模糊词：「禁止使用‘可以’‘建议’‘考虑’‘可能’‘一般’‘通常’——所有结论必须是肯定句，且带技术依据（如PEP 8第5.2条、OWASP A1-2021、SQLAlchemy 2.0文档#session-execution）」。
绑定真实错误模式库
第一步：列出你团队近期高频出错的3类模式，比如：
① FastAPI路径参数未声明类型导致Pydantic绕过校验
② Django ORM中filter()误用双下划线引发N+1
③ 日志中硬编码敏感字段名（如'password'、'token'）
第二步：在提示词中写：「本次评审优先扫描以上三类模式。若发现匹配，必须按『模式编号+触发代码片段+修复后代码』格式输出。未命中时不强行凑数。」
这一步让Gemini从“通用AI评审员”切换成“你团队专属Bug探测器”，输出自然聚焦。
