☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让deepseek代码评审贴近真实场景，需注入pr上下文、指定评审角色口吻、嵌入项目铁律、绑定证据链，并利用git元数据激活ast差异分析。
让deepseek生成的代码评审结果贴近真实开发场景中的评审意见，关键在于注入上下文细节、模拟团队协作语言、规避ai通用话术。真实评审不是罗列规则，而是结合项目现状、历史问题和成员习惯给出可执行反馈。
用真实PR上下文包裹评审请求
不要只丢一段孤立代码给DeepSeek。在prompt中必须包含：当前分支名、关联的Jira编号、最近3次同类PR的评审结论摘要、本模块近期高频缺陷类型（如“过去两周SQL注入告警70%来自UserDao层”）。
示例prompt开头：【必须写明PR标题与背景】 “PR #482：合并feature/auth-refactor到develop，修复登录态失效问题。Jira：AUTH-192。注意：上月该模块因硬编码密钥被安全组打回2次，且git blame显示UserAuthServiceImpl.java近3次修改均出自同一开发者。”
这一步不加上下文，DeepSeek会默认按通用安全规范输出，无法体现团队真实约束条件。
强制模型模仿特定角色口吻
方法一：指定身份+语气限制
在prompt末尾明确要求：“你是一名有5年Java后端经验、目前在支付网关组的资深开发，评审风格直接、带轻微吐槽但附带可复现的测试步骤。禁用‘建议’‘可以考虑’等模糊表述，改用‘删掉’‘必须加try-with-resources’‘这里已出过两次NPE，见AUTH-188’。”
方法二：提供历史评审原文作为few-shot样本
粘贴1条团队内真实高赞评审评论（含时间戳、人名、原始链接），例如：“@张伟 2025-06-12 在UserAuthServiceImpl.java第87行：别用Date()构造token过期时间，本地时钟漂移会导致集群间校验失败。上个月订单服务就因此漏发12笔通知。改用System.currentTimeMillis() + offset。”
【样本必须带具体行号、故障现象、历史事故编号】 模型才能学会提取真实要素，而非泛泛而谈。
注入项目级硬性约束
第一步：整理出本项目不可协商的3条铁律
例如：① 所有数据库密码必须走Vault API获取，禁止任何字符串拼接；② Spring Boot Actuator端点仅允许/health和/info开放；③ DTO类字段命名必须与OpenAPI定义完全一致。
第二步：在每次评审prompt中前置声明
“本项目严格执行以下规则：[粘贴上述3条]。若代码违反任一条，必须标为blocker级并引用对应GitOps策略文档URL。”
第三步：要求模型输出时绑定证据链
每条问题必须包含：触发路径（如“调用链：LoginController→AuthService→UserDao”）、复现步骤（如“curl -X POST /login -d 'user=admin' -d 'pass=123'”）、修复后验证方式（如“启动本地H2 DB，执行testLoginWithInvalidPasswordShouldReturn401”）。
没有可执行验证路径的评审意见，在真实团队中会被直接忽略。
用Git元数据激活上下文感知
第一步：从git log提取本次变更的关键特征
运行命令：git log -n 5 --oneline --grep="AUTH" origin/develop..HEAD，获取最近5次含AUTH关键词的提交摘要。
第二步：将摘要压缩成一句话嵌入prompt
例如：“注意：本次重构紧随AUTH-191（JWT签名校验优化）之后，且AUTH-189明确要求所有密码字段日志脱敏——但当前代码仍打印了passwordHash字段。”
第三步：要求模型对比变更前后的AST差异
在prompt中加入：“对比diff前后UserAuthServiceImpl.java的AST节点变化，重点检查SecurityContextPersistenceFilter的拦截范围是否扩大。”
这步跳过会导致模型无法识别“看似合理实则破坏原有安全边界”的隐性风险。
