本攻略围绕 DeepSeek 代码审查的完整流程，讲清提示词设计、上下文组织、结果验证与工程集成，帮助团队把模型能力落到日常研发。
在合并请求、遗留系统改造和依赖升级审计中，代码审查既要发现缺陷，也要控制评审成本。DeepSeek 可以承担初筛和解释性审查，但把它当成自动审批器会带来误报和漏报。更可靠的，是把审查目标、代码上下文、技术栈约束和输出格式纳入固定工作流，并明确人工复核边界。
1. 审查目标界定与提示词构造
使用 DeepSeek 做代码审查前，先要界定审查目标。不同场景关注点差异很大，安全审计要重点看注入、越权、敏感信息泄露和依赖漏洞，性能审查要关注循环查询、重复计算、锁粒度和缓存穿透，可维护性审查则看命名、分层、重复代码和异常处理。如果一开始只说帮我看看代码，模型容易给出泛泛的代码风格建议，真正高风险问题反而被淹没。实践中可以按合并请求的变更类型选择目标，新增接口重点看参数校验和幂等，修改数据访问重点看事务和索引，删除逻辑重点看调用方兼容性。
提示词需要包含角色、代码范围、技术栈、关注点、严重级别和输出格式。例如可以写：你是一名资深 Java 后端审查者，请审查以下 diff，重点检查空指针、事务边界、并发安全、SQL 注入和日志泄露。按阻断、严重、一般、建议四级输出，每个问题给出文件路径、行号、触发条件、影响和修复建议。无法确认时标注疑似，不要臆测未提供的代码。这种提示词把模型从自由聊天拉入审查任务，输出也更容易被后续工具解析。温度参数建议调低，减少创造性联想，要求模型先列证据再给结论。
对同一段代码，可以设计两轮提示。第一轮做缺陷扫描，要求只报高置信问题；第二轮做修复验证，让模型针对已确认问题生成补丁和测试用例。两轮之间保留上下文，但不要把所有历史对话无差别拼接，否则模型容易被早期错误判断带偏。提示词还应版本化管理，团队按语言和框架沉淀模板，例如 Java 后端、React 前端、Go 微服务、Python 数据处理分别维护，这样审查质量更稳定。
2. 上下文组织与分块审查策略
代码审查的质量很大程度取决于上下文是否足够且不过载。只给一个函数，DeepSeek 很难判断参数来源、调用约定和异常传播；把整个仓库一次性投喂，又会引入大量无关代码，增加成本并稀释注意力。更可行的做法是按变更 diff 为主干，补充文件路径、类声明、导入、相关接口、配置项和测试文件。对于跨文件调用，至少提供调用方和被调用方的关键片段，让模型看到数据如何流入和流出。大型合并请求动辄数千行，单次审查应分块处理，可以按模块、按调用链或按风险等级拆分，每块控制在几百行变更加必要上下文。
分块不是简单截断，而是保留语义完整性。审查支付回调时，需要给订单状态机、幂等表结构、重试策略和异常处理；审查权限校验时，需要给角色模型、路由配置和中间件顺序；审查前端组件时，需要给父组件传参、状态管理和副作用依赖。若上下文缺失，提示词中应明确要求模型列出需要补充的信息，而不是强行猜测。团队可以建立上下文清单，按代码类型规定必须附带的文件，例如数据库变更附带迁移脚本和回滚方案，接口变更附带 OpenAPI 定义和调用示例。
分块之后还要确定审查顺序。通常先看高风险入口，例如认证、支付、数据删除、文件上传和外部命令调用，再看核心业务逻辑，最后看工具方法和样式代码。每块输出单独保存，最后合并去重。DeepSeek 在长上下文下仍可能忽略中段内容，因此把最关键的文件放在提示词前部，并明确要求逐项检查，能提升召回。对于重复出现的问题，可以在后续分块中引用前文结论，要求模型判断是否同类缺陷，避免同一问题在多个文件里被反复报告。
3. 缺陷识别重点与结果复核方法
DeepSeek 在常见缺陷识别上表现稳定，尤其是空指针、数组越界、资源未关闭、SQL 拼接、命令注入、跨站脚本、竞态条件、异常吞没、硬编码密钥和日志打印敏感字段。实际案例中，模型曾指出 Java 代码用 equals 比较 BigDecimal 会导致精度判断失败，建议改用 compareTo；也指出 Python 脚本打开文件后未使用上下文管理器，异常路径下文件句柄可能泄漏；在前端代码中，它能发现 useEffect 依赖数组缺失导致重复请求，在 Go 代码中能提示循环变量捕获和 defer 执行时机问题。这些问题的共同点是模式明确，模型可以结合语言规则给出解释。
但模型输出必须复核。DeepSeek 可能把正常写法误判为缺陷，也可能编造不存在的行号或依赖行为。降低误报的关键是要求证据链：问题对应哪一行，触发条件是什么，影响范围有多大，修复后如何验证。对于安全类问题，可以要求给出攻击路径或测试用例；对于并发问题，可以要求说明交错顺序；对于性能问题，可以要求估算数据量和调用次数。人工复核时优先看阻断和严重级别，再抽查一般建议。若模型无法给出具体触发条件，通常应降级为疑似或忽略。
复核还要结合项目规则。团队可以维护自己的审查清单，把通用规则和业务规则分开。通用规则包括空值处理、异常捕获、日志脱敏、事务边界和单元测试覆盖；业务规则包括订单状态流转、库存扣减顺序、权限继承和审计留痕。把规则文件作为提示词的一部分，能显著减少正确但无用的建议。对于重复误报，记录到反馈集并更新提示词，例如禁止模型在未看到配置文件时判断连接池大小，禁止在没有基准测试时断言性能瓶颈。经过几轮迭代，DeepSeek 的输出会从泛泛评论转向可执行的审查意见。
4. 工程集成与团队协作落地
要把 DeepSeek 代码审查变成稳定能力，需要接入研发流程而不是停留在聊天窗口。常见做法是在合并请求创建或更新时触发流水线，拉取 diff 和必要上下文，调用 DeepSeek API，将结果以评论或检查项形式回写到 GitLab、GitHub 或企业代码平台。流水线中要设置超时、重试和成本上限，只审查新增和修改行，避免每次全量扫描。对于敏感项目，应使用私有化部署或符合数据合规的接口，代码传输前做脱敏，密钥放入密钥管理服务，审查日志保留必要字段即可。集成初期可以只对高风险目录开启，例如支付、认证、数据访问和基础设施代码，再逐步扩大范围。
团队分工也需要调整。DeepSeek 适合做第一轮初筛，把明显缺陷、风格问题和测试缺口标出来，人类审查者则集中处理业务语义、架构取舍和跨团队影响。审查意见不能直接当成合并门槛，除非经过规则校准并达到可接受的误报率。可以设置分级策略，阻断级问题必须人工确认后修复，严重级问题要求回应，一般和建议级问题进入待办列表。对于模型提出的补丁，不能直接合并，必须经过测试和代码所有者确认，尤其是涉及资金、权限和数据删除的逻辑。
持续优化依赖数据反馈。团队可以记录每次审查的命中数、误报数、修复时长和漏报案例，按语言、框架和目录分析薄弱环节。提示词、上下文清单和规则库都应有版本号，变更后用小样本回归测试，避免修好一个问题又引入一批误报。当某类误报反复出现时，不要只抱怨模型，而应补充项目约束和反例。经过这种工程化运营，DeepSeek 在代码审查中的角色会逐渐清晰：它不替代评审者，但能显著压缩机械检查时间，让团队把精力留给真正需要判断力的部分。
