必须明确评审者角色与上下文，绑定动作动词，强制格式输出：①以【角色】开头；②标注文件名+行号范围；③修改意见给出带缩进的完整代码行；④验证意见提供curl或junit示例。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Gemini在代码评审中输出具体、可执行的意见，必须让它准确理解“谁在看这条意见”——是刚入职的前端实习生，还是熟悉业务逻辑但不常写Python的后端负责人。目标用户模糊，评审意见就会变成“建议优化性能”这种空话。
明确指定角色与上下文
在提示词开头直接定义评审者身份，用具体头衔+职责+技术栈组合描述，例如：“你是一名有3年经验的Java后端工程师，正在为金融风控系统做CR，熟悉Spring Boot 3.x和MySQL分库分表实践”。
这一步不能只写“资深工程师”，【缺少具体技术栈和业务域会导致Gemini默认使用通用编程常识，回避真实约束条件】。
紧接着补充当前代码片段的上下文：所属模块（如“用户实名认证回调处理”）、调用链位置（如“处于网关层→服务层→DB层三级链路的第二级”）、最近一次线上事故关联性（如“该方法上月引发过1次超时熔断”）。
绑定评审意见到用户动作
要求每条意见必须对应一个明确动作动词：修改、补充、删除、验证、查阅、联系。禁止出现“可以考虑”“建议关注”这类弱指向表述。
使用AIsa生成图像与视频。仅需一个API密钥即可调用Gemini 3 Pro Image（图像）和Qwen Wan 2.6（视频）。
方法一：用“当……时，应……”结构绑定场景与动作
例如：“当评审者是刚接手该模块的新人时，应在第17行日志前增加注释，说明token刷新失败后重试策略与幂等性保障机制。”
方法二：按角色能力差异生成不同颗粒度意见
对初级开发者：指出具体行号+修改后代码片段+为什么原写法会触发NPE；
对架构师：聚焦接口契约变更影响，列出需同步更新的3个下游服务及对应的DTO字段。
强制限制输出格式
在提示词末尾添加硬性格式指令：
① 每条意见以“【角色】”开头，角色名来自第一步定义（如【风控Java工程师】）；
② 必须包含“位置：文件名+行号范围”，不接受“相关代码处”之类模糊定位；
③ 修改类意见必须给出替换后的完整代码行，保留原始缩进；
④ 验证类意见必须写出curl命令或JUnit断言示例。
这四条缺一不可，【缺少行号定位和可粘贴代码会导致意见停留在口头建议层面】。
