DeepSeek代码评审需输出可落地修改建议：①明确角色与审查范围；②强制“问题→证据→修改”三段式格式；③提供带行号代码；④禁用模糊表述；⑤注入函数签名、调用示例及环境约束。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
让DeepSeek在代码评审时直接输出可落地的修改建议，避免反复追问“这里具体怎么改”“要不要加空行”“变量名该叫什么”，节省至少两轮沟通时间。
用结构化角色指令框定输出边界
在提示词开头明确指定模型身份与约束条件，例如：“你是一名有5年Python后端经验的资深Code Reviewer，只评论PEP 8合规性、边界条件遗漏、潜在N+1查询风险，不评价架构设计或技术选型。”
这一步必须写死范围，否则模型会自发扩展到无关维度，比如突然分析数据库索引策略——它没被授权做这件事。
强制要求“问题→证据→修改示例”三段式输出
在提示词中嵌入固定模板指令：“每条意见严格按以下格式输出：①【问题】+具体缺陷类型（如‘未校验None值’）；②【证据】+引用原文行号和代码片段（如‘第47行：user.profile.get_full_name()’）；③【修改】+可直接粘贴的代码块（含完整上下文缩进）。”
没有这个硬性格式，模型大概率生成“建议加强空值处理”这种模糊表述，开发者还得反向猜哪一行、怎么补。
【关键前提】必须提供带行号的原始代码片段，不能只说“这段代码”——模型无法自行编号，缺行号就无法定位证据。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
用否定清单堵住常见模糊话术
在提示词末尾追加禁止项：“禁止使用以下表述：‘可以考虑’‘建议优化’‘注意潜在风险’‘可能引发问题’‘建议检查一下’。所有意见必须是确定性动作，例如‘删除第32行冗余try-except’‘将第89行的range(0, len(items))改为enumerate(items)’。”
这类模糊动词是来回改稿的根源，模型默认倾向保守表达，必须用禁令强行切换为工程师口吻。
注入真实上下文降低歧义
方法一：附上函数签名与调用方示例。例如：“当前评审函数：def calculate_discount(user: User, items: List[Item]) -> float。上游调用示例：calculate_discount(active_user, cart_items)。”
方法二：标注关键约束。例如：“该服务部署在内存受限的边缘设备，禁止引入任何新第三方依赖。”
没有这些信息，模型可能推荐dataclasses.replace()——但它在Python 3.6以下不可用，而项目锁死在3.5。
