DeepSeek代码评审需锚定具体位置、绑定缺陷类型库、禁用模糊形容词：必须指出第X行或函数Y，引用真实缺陷示例，且每条意见须含“将【A】改为【B】”等可验证动作，否则作废重写。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
deepseek在生成代码评审意见时容易泛泛而谈，比如只写“建议优化性能”“逻辑不够清晰”，却不说具体哪行代码、什么场景下慢、变量命名哪里歧义。这类空洞反馈对开发者毫无实操价值，反而增加沟通成本。用上下文锚定问题位置
在提示词开头明确要求DeepSeek必须引用具体代码片段：把待评审代码块原样嵌入提示词，并强制它在每条意见中写出第X行或函数Y内部这样的定位信息。
不加这句约束，模型会默认从宏观层面评论，结果就是满篇“可读性有待提升”“建议解耦”。加上后，它必须落到字节层面——哪怕代码只有三行，它也得指出第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块。
