通义千问代码评审需强制约束维度、锚点、动词与缺陷模式：①开头定义5个硬性维度及示例句式；②必须引用文件名:行号、函数名(参数)、具体值；③禁用“建议”等虚词，改用可验证动作；④末尾附3类真实缺陷反例并要求匹配标签输出修复方案。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
通义千问在代码评审中给出“建议优化逻辑”“注意边界条件”这类泛泛而谈的反馈，无法指导开发者定位具体哪行代码、哪个变量、哪种输入会出问题，导致评审意见形同虚设。明确指定评审维度与颗粒度
在提示词开头直接定义本次评审必须覆盖的5个硬性维度：空指针风险、循环终止条件、浮点数比较方式、敏感信息硬编码、日志是否泄露用户ID。每个维度后紧跟示例句式：“若存在空指针风险，请指出具体变量名、所在文件行号、触发该风险的调用路径。”
这一步不执行就跳过后续所有分析——【缺少维度约束时，模型默认按通用模板输出，必然笼统】。
强制绑定代码上下文锚点
要求模型必须引用原始代码中的真实元素：函数名、参数名、常量名、注释关键词。禁止出现“某个变量”“某处判断”“类似写法”等模糊指代。
方法一：在提示词中写死引用格式——“请严格按『文件名:行号』+『函数名(参数)』+『具体值/表达式』三段式输出，例如：utils.py:47 → validate_token(expiry_time) → expiry_time < 0”。
方法二：把待评审代码块前插入人工标注的唯一锚点，如“// REVIEW-ANCHOR-20240511-A”，再在提示词中要求“所有意见必须包含最近的REVIEW-ANCHOR编号”。
禁用抽象动词，替换为可验证动作
删掉提示词里所有“优化”“加强”“完善”“考虑”“建议”等虚词。替换成带验证标准的动词：
✘ 原提示词片段：“建议加强异常处理”
✓ 替换为：“列出所有可能抛出的Exception子类；对每个子类，说明是否被当前try-catch捕获；若未被捕获，指出该异常首次生成的代码行及上游调用栈深度”。
这一步卡住模型的模糊空间——【没有可枚举、可计数、可定位的验收标准，模型只能编造通用话术】。
注入缺陷模式库与反例对照
在提示词末尾附3条真实缺陷反例（含修复前后代码片段），每条标注类型标签：
① 【空指针】旧：if (user.getProfile() != null && user.getProfile().getAvatar() != null) → 新：Objects.nonNull(user) && Objects.nonNull(user.getProfile()) && Objects.nonNull(user.getProfile().getAvatar())
② 【整数溢出】旧：int total = countA + countB; → 新：long total = (long)countA + countB;
③ 【SQL拼接】旧：String sql = "SELECT * FROM users WHERE id = " + userId; → 新：JdbcTemplate.query(sql, new Object[]{userId}, rowMapper);
要求模型评审时，必须先匹配缺陷模式标签，再输出对应修复方案。
