DeepSeek 在后端工程师手里，价值集中在两件事：把接口草案里的漏洞提前问出来，把线上报错的范围从一大片缩到两三个方向。它不接你的监控，也看不到调用链，所以回答能不能用，取决于你给的材料。下面按接口评审、故障定位、材料脱敏三段讲，最后说清它做不到的部分。
接口评审：让它当反方
把草案交给模型，常见的问题是问法太客气："帮我看看这个接口设计有没有问题。"换来的是一堆"建议增加鉴权""建议完善文档"。有效的问法是给它一份审查清单，让它逐条对照。
一份够用的草案要包含：路径与方法、请求字段与类型、响应结构与错误码、是否需要幂等、调用方是谁、预估调用量级、超时与重试约定。缺了这些，它只能给通用建议。
让它输出的东西也要定死：边界情况（空值、超长、并发、重复提交）、异常路径（下游超时、部分成功）、错误码是否覆盖主要失败原因、分页方式（游标还是偏移）、限流维度（用户、租户、接口）。最后加一条"列出需要我向业务方确认的问题"，这一条经常比前面几条更有用。模板不必每次从零写，可以先把公开示例改成自己的约束，再固定下来。
判断标准：如果评审意见里没有"需要确认"的条目，说明它只是在复述通用规范，不是在评你的接口。
它当审查者比当设计者更合适。设计需要业务上下文和取舍，挑毛病只需要经验和清单。
故障定位：先缩范围，再谈原因
报错信息、相关日志、最近改动，这三样给全，效果远好于"我的服务挂了，怎么办"。
要求它按可能性排序列出三到五个原因，每条后面必须跟"怎么验证"——查哪条日志、跑哪条命令、看哪个指标。一条无法验证的原因，价值等于零。
这一步的作用是缩小范围，不是给答案。排查的本质是二分：最近有没有发版、依赖有没有升级、配置有没有变、流量结构有没有变。把这四个问题先问一遍，通常能砍掉一半方向。先判断任务类型再决定要不要展开长推理，这套思路和深度思考模式的开关判断是一回事：简单定位不必长篇推理，复杂因果才值得展开。
判断标准：头一条原因能不能在两分钟内用一条命令排除。能，就继续往下问；不能，说明材料还不够。
日志怎么给：三段就够
报错栈、报错前后各 20 行、请求入口的关键参数（脱敏后）。这三段基本能覆盖八成问题。
不要贴整个日志文件。上下文越长，模型越容易抓住不重要的行做文章，前后矛盾的信息也会互相干扰。如果确实是长链路问题，按请求 ID 过滤出一条完整调用链，比给一万行杂日志有效。
把运行环境说清楚：语言与框架、数据库类型、部署形态（容器还是裸机）、是否经过网关。版本相关的行为差异以官方文档为准，不要采信模型对某个版本"应该是这样"的描述。
排查过程建议单独开一个会话，事后把结论整理进会话历史，下次遇到同类问题能直接翻记录，不用重新描述一遍现场。
五类故障的处置差异
| 故障类型 | 给它什么材料 | 期望它输出什么 | 判断标准 |
|---|---|---|---|
| 5xx 突增 | 错误分布（按接口、按实例）、发版时间点、依赖状态 | 按变更、资源、依赖三类归因的假设 | 每条假设都能对应到一个监控面板 |
| 接口超时 | 超时阈值、P99 曲线、下游耗时拆分 | 耗时集中在哪一段，如何验证 | 能定位到具体下游或连接池 |
| 数据不一致 | 两条数据的写入时间、事务边界、重试记录 | 并发、事务、幂等上的缺口 | 能复现出至少一条不一致路径 |
| 依赖升级后异常 | 版本差异、报错栈、调用方式 | 不兼容点清单 | 能对应到官方变更记录的具体条目 |
| 偶发难复现 | 发生频率、请求特征、机器分布 | 还需要补哪些日志和指标 | 下次发生时能自动留下证据 |
表格的用法是照第四列判断：给不出可验证路径的，继续补材料，别急着改代码。
它看不到的那些东西
它看不到你的监控、链路追踪、配置中心，也不知道你们历史上的技术债和"这块不能动"的原因。所有需要看运行时状态才能得出的结论，它只能猜。
它会编造不存在的库函数、配置项和版本行为。凡是涉及具体接口签名、参数默认值、错误码含义，回官方文档核对一遍，这一步不能省。
它不能替你决定业务规则。退款该不该允许、订单能不能拆、幂等键用哪个字段，这些是业务约定，模型给的只是建议。
它生成的 SQL 和脚本不要直接上生产。执行前看执行计划，确认索引命中、扫描行数、是否锁表。
安全边界要说清：数据库口令、令牌、证书内容、内网地址与端口、真实用户数据，这五类不上传。需要它帮忙时用改过的样本：表名换掉、字段值替换、IP 改成保留地址。
一份可复用的评审提问
接口草案评审模板
这是我设计的接口草案：{粘贴}。业务场景是{场景}，调用方是{调用方}，预估量级是{量级}。请按以下顺序输出：
- 边界情况：空值、超长、并发、重复提交，各会出现什么后果
- 异常路径：下游超时、部分成功、重试放大，接口怎么表现
- 错误码：是否覆盖主要失败原因，有没有无法区分的场景
- 分页、幂等、限流：给出具体方案与取舍
- 需要我向业务方确认的问题清单
不要替我决定业务规则；不确定的地方标出来，不要补全。
三个协作中的疑问
日志太长放不进上下文怎么办？按请求 ID 抽一条链路，或者只给报错栈加前后 20 行再加入口参数。宁可分三次问，也不要把无关日志堆进去。每次只问一个假设，回答质量更稳定。
它给的方案和团队规范冲突怎么办？把规范作为约束写进提问，比如"统一用游标分页""错误码必须落在既有区段"。规范不进去，它只会给通用做法。冲突时以团队规范为准，让它在框架内给方案。
怎么判断它在编接口？三个信号：给不出版本号和文档位置；参数名很顺口但你在文档里搜不到；示例代码混用了两个版本的写法。出现任意一个，就去官方文档确认，别直接粘进项目。
