DeepSeek把代码评审意见写得更具体提示词怎么避免内容太空

先说个事：DeepSeek做代码评审时最容易犯的毛病，就是泛泛而谈。比如扔一句“建议优化性能”“逻辑不够清晰”，然后就没有然后了——具体哪行代码慢？什么场景下卡？变量命名哪里歧义？一个字都不说。这种空洞反馈，对开发者而言等于没反馈，反而还得花时间猜你到底在说啥。

要解决这个问题，得从三条路下手。每一招都能直接把AI的输出精度拉到能用级别。

用上下文锚定问题位置

怎么堵住这个口子？很简单：在提示词开头就把规矩定死。把待评审的代码块原样嵌进去，然后死咬住一条规矩——每提一条意见，必须标注具体行号或者函数名。

不加上这个约束，模型天生爱从宏观层面评论，结果就是满屏的“可读性有待提升”“建议解耦”。一旦加上，它就得落到字节层面做文章：哪怕你只给了三行代码，它也得精准指出“第2行的for循环没处理len(arr)==0这个边界”。这才是评审该有的颗粒度。

绑定真实缺陷类型库

光有位置还不够，得让它知道该往哪个方向挑毛病。两块内容缺一不可：

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

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

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

禁用模糊形容词指令

这一步，目标明确：把套话扼杀在摇篮里。操作起来其实也就三步：

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

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

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

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