AI使用攻略 · 2026-11-05

DeepSeek 编程链路：从报错解读到代码重构的提示词序列

写代码遇到报错，很多人的第一反应是把整段代码和报错一股脑丢给模型，然后收到一段看起来对、跑起来不对的建议。问题不在模型，在喂法。DeepSeek 的 V 系列适合快速解读报错、改小段代码；R 系列的深度思考模式适合多文件耦合、异步竞态、复杂数学这类需要逐步推演的问题——注意深度思考的开关在对话界面和 API 里都可以控制，简单任务没必要开，开了慢也费 token。下面这条「报错解读 → 根因定位 → 重构」的提示词序列，是我在真实项目里反复用的一套，直接复制改参数就能跑。

第一步：报错解读，别让模型猜

报错解读是简单任务，用 V 系列、不开深度思考。要点是给足上下文但限制输出格式，避免模型开始长篇大论讲原理。

我遇到以下报错，请帮我解读：

【报错信息】
（粘贴完整 traceback，别截断最后一行）

【相关代码】
（粘贴报错指向的函数或代码段，10~50 行为宜）

【运行环境】
语言/版本：Python 3.11
关键依赖：FastAPI 0.115, SQLAlchemy 2.0（按实际填）

请按以下格式输出，不要展开无关背景：
1. 报错直接原因（一句话）
2. 出错的具体代码位置
3. 2~3 个可能的触发场景，按可能性排序

关键在「不要展开无关背景」这句。DeepSeek 中文语境理解好，你不说限制它就默认给你写小作文。traceback 一定要粘完整，尤其最后一行和堆栈中间帧，截断是最常见的翻车原因。

第二步：根因定位，这时候才开深度思考

如果第一步给出多个可能场景、你分不清哪个是真凶，切到 R 系列开深度思考。这个阶段不要用「你是一位资深架构师」之类的角色扮演开头——深度思考模型吃的是清晰约束，不吃花活。直接把已知事实和验证条件摆出来。

以下报错有三个候选原因，请逐一推演判断哪个成立：

【候选 1】数据库连接池耗尽：依据是高峰期才出现
【候选 2】异步任务里同步调用 ORM：依据是代码中 async def 内有 session.query()
【候选 3】超时配置过短：依据是偶发且堆栈含 timeout

【约束】
- 生产环境只读，不能随意加日志重启验证
- 请针对每个候选给出一个改动最小、可在线上验证的验证方法
- 如果信息不足以判断，明确指出还缺什么信息，不要硬猜

「不要硬猜」和「指出缺什么信息」这两句很值钱。深度思考模式下它会真的逐步排除，而不是挑一个听起来合理的糊弄你。

第三步：重构提示词，先方案后代码

定位到根因后别直接要代码。让 DeepSeek 先出重构方案，你确认方向对了再让它写，返工率低很多。

针对上述确认的根因（数据库连接池耗尽），请重构这段代码：

【现有代码】
（完整粘贴）

【重构要求】
1. 优先复用现有连接池，不引入新依赖
2. 保持函数签名不变，调用方无需修改
3. 明确标注每处改动的原因
4. 改完后列出：需要补的测试用例、可能的回归风险

先输出改动方案清单让我确认，再输出完整代码。

「先输出方案再输出代码」是把深度思考用在刀刃上的写法——它会在方案阶段把权衡想清楚，代码阶段的错误率明显下降。

两个常见踩坑

一是把整个仓库丢进去问「这段代码有什么问题」。上下文越长，注意力越分散，长上下文的能力和价格优势都不是这么用的。按函数或模块切片，一次解决一个问题。二是简单报错也开深度思考，一个拼写错误的变量名触发几分钟的推演，纯属浪费；报错信息一眼能看懂的，V 系列直接问就够。

这套序列的核心思路就一句话：把「解读、定位、重构」拆成三次独立提问，每次只给模型解决该问题所需的最小上下文，简单问题用 V 系列，需要推演的再开深度思考。复制上面的模板改改参数，下个报错就能试。