进行代码评审时，若希望DeepSeek输出的反馈从空洞的“请优化”升级为可直接粘贴的修复代码，关键在于为其设定清晰的执行路径。核心流程分为三步：判断→归因→建议。每一步都必须绑定具体的代码物理位置，严禁使用“上述代码”“相关部分”这类模糊表述，最终按风险等级、触发条件、验证方式进行结构化输出——唯有如此，AI才会给出可落地的具体意见，而非泛泛而谈的无效内容。

不要指望AI能自行领悟。你必须在提示词中明确指示：先精准定位逻辑缺陷、安全风险或性能瓶颈，再清晰说明可能引发的后果，最后附上可直接替换的代码片段。否则，它只会生成一堆“建议优化”“建议重构”的笼统反馈，与未做评审毫无区别。

明确要求AI执行“判断→归因→建议”三步链路

在提示词开头直接定义推理流程：你必须严格按照以下顺序响应——①明确指出是哪一行、哪个函数存在何种类型的问题；②用一句话阐述该问题会导致的实际后果，例如空指针引发系统崩溃、SQL拼接导致注入风险；③提供可直接粘贴替换的代码片段。这一步骤强制模型放弃跳跃式结论，若不满足三步结构则不予输出任何内容。简而言之，就是逼迫它按顺序逐步推理，不得跳步、不得省略任何关键环节。

绑定上下文锚点，禁用模糊指代

所有判断必须绑定到代码中的物理位置：使用“第X行”“func_name()函数内部”“if条件分支中”等明确标识。严禁出现“上述代码”“相关部分”“该处”这类无指向的模糊表述。如果原始代码没有行号——你必须自行添加行号后再引用，否则定位都无法完成，代码评审也就失去了价值。绝不允许AI打马虎眼、含糊其辞。

方法一：用角色+约束模板锁定输出格式

设定具体角色，例如“你是一名拥有5年Java后端开发经验的资深SRE，正在审查生产环境告警频发的服务代码”。同时附加硬性约束：“每条评审意见必须包含【风险等级：高/中/低】+【触发条件：如并发量超过100时必然出现】+【修复后验证方式：如增加日志打印response.status】”。这会让AI自动过滤掉“命名不够语义化”这类低优先级意见，只保留可验证、可归责的关键结论。模板一经设定，输出质量立刻提升一个档次。

方法二：示例驱动，用错误样本反向训练AI

在提示词末尾附上一段典型的失败案例，效果立竿见影。

❌ 错误示范：“这个循环可以优化”——没有行号、没有说明瓶颈所在、没有提供替换方案。等同于什么都没说。

✅ 正确示范：“第47行for循环遍历ArrayList时反复调用size()，JVM无法内联该方法，在Android 8.0以下系统会触发额外GC；建议改为 int len = list.size(); for (int i = 0; i < len; i++)”。AI看到这样的颗粒度后，后续所有输出都会自动带上行号、JVM版本约束以及字节码层面的归因分析。一个正反样本的对比，效果远超十句指令。

堵住“假装思考”漏洞的关键开关

最后还需要加上一道保险锁。在提示词结尾追加一条不可绕过的指令：“如果代码中不存在符合以下任一条件的问题，则必须仅输出‘未发现高危问题’，不得编造、不得扩展、不得解释原因”。所列条件包括：空指针访问路径、硬编码密钥、正则回溯爆炸、未关闭的数据库连接、越界数组访问。这一步能有效砍掉AI为凑数而生成的“建议增加注释”“考虑使用Builder模式”等无关废话，确保每条输出都对应真实的风险点。没有高危问题就是没有，绝不让AI硬挤内容。这才是真正高效、可落地的代码评审提示词设计方法。