先聊聊常见现象：DeepSeek 在代码评审时最常出现的问题，就是给出过于笼统的评价。比如丢下一句“建议优化性能”“逻辑不够清晰”，然后就没了下文——究竟是哪一行代码拖慢了速度？什么场景下会出现卡顿？变量命名到底哪里容易产生歧义？一个字都不细说。这种空洞的反馈，对开发者来说等于没有反馈，甚至还需要花时间猜测 AI 到底在指什么。

要彻底解决这个痛点，可以从三个方向入手。每一招都能直接提升 AI 输出的精准度，让评审结果达到可直接使用的水平。

用上下文锚定问题位置

怎么堵住这个漏洞？方法很简单：在提示词的开头就明确规定规则。把待评审的代码段完整嵌入，然后强制设定一条要求——每提出一条意见，必须标注具体行号或函数名称。

如果不加这个约束，模型天然倾向于从宏观层面发表评论，结果就是满屏的“可读性有待提升”“建议解耦”。一旦加上这条限制，它就必须落到字节级别去分析：哪怕你只给了三行代码，它也得精准指出“第2行的 for 循环没有处理 len(arr)==0 这个边界条件”。这才是代码评审应有的颗粒度。

绑定真实缺陷类型库

光是定位还不够，还得让模型知道应该往哪些方向去挑毛病。下面两块内容缺一不可：

第一，在提示词末尾附加一份简洁的缺陷分类表。例如：空指针→检查是否调用前未判 null；竞态→看共享变量是否缺锁；硬编码→搜字符串常量是否该抽成配置；重复逻辑→比对相邻 if 块是否结构雷同。这一套组合拳打出去，模型就知道该把注意力集中在哪里。

第二，提供一个真实的带缺陷示例，当作标准答案来参考。比方说摆一段 SQL 拼接的 Java 代码，再给出一条具体的评审意见：“第7行 String sql = "SELECT * FROM user WHERE id=" + id; → 改用 PreparedStatement 防止注入，id 应经校验非负且为数字”。这种示例，模型照着学，输出粒度就不会跑偏。

当然，这里有一个关键前提：示例里的缺陷必须是真实存在的——要么是语法错误，要么是安全漏洞。如果用虚构的“伪缺陷”做模板，模型对缺陷的判断标准就会走偏。

禁用模糊形容词指令

这一步，目标非常明确：把套话扼杀在摇篮里。操作起来实际上只有三步：

第一步，列出黑名单。在提示词里明确交代，禁止使用“较好”“一般”“可能”“大概”“某些情况”“相对”“较”“略”“稍”“有待”“不足”“欠佳”“尚需”这些词。一个都不许出现。

第二步，强制意见格式。每一条意见必须包含可验证的动作，例如“将【A】改为【B】”，或者“在【C】处增加【D】校验”。这样一来，模型自然要给出具体的操作方案。

第三步，兜底校验。额外加一句：“若某条意见未出现‘第 X 行’‘变量 Y’‘函数 Z’任一标识，则整条意见作废重写”。

这一招能把 80% 的套话直接砍掉。原因很简单：模型只要尝试使用“建议增强健壮性”这种表达，就会触发重写机制。结果就是，它不得不主动去翻代码里那个没有加 try-catch 的 catch 块，然后给出“在 catch 块中增加日志记录与异常抛出的具体方案”。