DeepSeek代码评审提示词怎么加入具体使用场景

用DeepSeek做代码评审，很多人会发现自己给的提示词像在跟一个“代码规范检查器”聊天——它只会说“变量命名不规范”“缺少异常处理”这类泛泛而谈的废话。但当你真的需要它判断一段支付回调验签逻辑是否漏校验时间戳、是否允许重放攻击时，它却完全答不上来。

问题出在哪？提示词里没有业务逻辑，没有项目上下文。怎么才能让AI真正理解代码背后的业务逻辑呢？关键在于把场景细节喂给它。

明确写出当前模块的职责和边界

在提示词开头第一句，就得把模块的职责说清楚。比如：“你正在评审一个微信小程序的订单退款回调接口，该接口接收微信服务器推送的refund_notify消息，完成本地退款状态同步并返回success响应。”

这一步省不得。如果不说清楚是“退款回调”而不是“支付回调”，模型就可能按通用支付逻辑提建议，比如要求校验prepay_id——但退款回调里压根没这个字段。

贴出真实调用链路中的上下游依赖

一种做法是直接列出关键依赖项：“上游：微信支付平台（推送JSON格式refund_notify）；下游：本地订单服务（更新order表refund_status字段）、财务对账服务（异步写入refund_log）。”

另一种更狠的做法，是用代码片段暴露隐式契约。贴出实际收到的请求体示例（记得脱敏），重点保留字段名、嵌套结构和空值情况。比如：{"refund_id":"wx123456","out_refund_no":"REF20240520001","refund_fee":100,"success_time":""}——这里的success_time为空，说明当前版本不校验成功时间。提示词里必须声明“暂不校验success_time字段，因微信文档明确该字段在部分失败场景下为空”。

标注当前代码所处的部署环境与约束

先说运行环境：“代码部署在阿里云函数计算FC，冷启动延迟敏感，禁止在回调内发起外部HTTP请求。”

再指出框架限制：“使用Spring Boot 2.7.x，不支持@Schema注解，DTO类无法自动生成OpenAPI文档。”

最后声明数据一致性要求——这是重中之重：

给出本次评审最关心的3个风险维度

按严重性排序是个好办法：① 资金安全：是否可能造成重复退款或漏退款；② 接口可用性：是否可能因微信签名验证失败导致整批回调被丢弃；③ 审计合规：日志是否记录了微信原始报文全文（含敏感字段脱敏）。

还可以用否定句锁定盲区：“不要检查缩进风格或import顺序；不要建议增加单元测试覆盖率——当前阶段只聚焦线上故障拦截能力。”这样一来，模型就知道该把精力花在哪了。