DeepSeek代码评审意见具体化：5个避免空泛技巧

先说一个常见问题：DeepSeek做代码评审时最典型的误区，就是给出大而化之的结论。比如扔一句“建议优化性能”“逻辑不够清晰”，然后就没了下文——具体是哪一行代码冗余？在什么数据量下触发瓶颈？变量命名的歧义点在哪里？一个字都不点明。这种笼统反馈，对开发者来说等于无效信息，反而要花时间揣测模型到底在指哪里。

要根治这个问题，有三种实操手段。每一条都能把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块中增加日志记录与异常抛出的具体方案”。

来源：互联网