百度文库AI代码评审提示词复用流程指南
在百度文库AI中编写代码审查提示词时，许多人反复调参、依赖随机尝试才能获得可用结果。只需围绕三个已验证的维度构建提示词，即可稳定输出高质量审查意见，避免每次手动重写。
明确角色与任务边界
第一步，提示词开头必须固定声明模型的身份和职责范围。直接写：“你是一位有5年后端开发经验的资深代码评审员，专注Python/Ja va/Go三语言，只评审用户提供的代码块，不补充实现、不猜测意图、不生成新代码。”这一步必须做——否则模型会擅自扩写函数、补全缺失类，甚至虚构调用链。所有后续约束都建立在此前提之上。
第二步，强制限定每条意见必须包含三个硬性要素：【问题位置】（精确到文件名+行号或函数名）、【现象描述】（如“连续4层if嵌套”“未校验user_id是否为空”）、【影响说明】（如“增加维护成本”“在高并发下可能触发NullPointerException”）。缺任一要素即视为无效意见，不予输出。
注入项目上下文锚点
方法一：用占位符预留项目特异性信息。例如插入“【当前项目命名规范】:函数用snake_case，布尔变量以is_/has_开头，错误码统一定义在errors.py中”。每次评审前只需替换方括号内内容，无需重写整条提示词。
方法二：要求模型主动识别并引用用户提供的上下文。加入指令：“若用户同时提供了README.md片段或config.yml内容，请优先依据其中定义的框架约束（如‘所有HTTP接口响应必须包含X-Request-ID头’）进行评审，而非通用最佳实践。”
【关键前提】用户必须在每次提交时附带不超过300字的项目上下文摘要，否则模型将按默认规则执行，不主动追问。
结构化输出与格式锁定
第一步，要求所有评审意见必须严格按此JSON Schema输出，不得增减字段：
{ "issues": [ { "file": "api/handler.py", "line": 42, "type": "security", "description": "SQL查询缺少WHERE条件", "impact": "导致全表扫描，响应延迟超2s" } ] }
第二步，禁止出现“可以考虑”“建议注意”“稍作调整”等弱动词短语；必须使用“应改为”“需移除”“必须添加”等强动作指令。这一步卡住80%的泛泛而谈。
第三步，设定输出长度上限——单条意见不超过80字符，总输出控制在1KB以内。过长的输出会导致百度文库AI截断或解析失败。