用 DeepSeek 写代码：三种任务拆法，和它最容易错的地方

写代码的效果差别，八成不在提示词写得好不好，而在你给没给对上下文。1M 窗口很容易变成「全都塞进去」，结果关键文件被淹没在一堆无关代码里。按任务分三类，每类只给必要的东西。

三种任务，三种给法

单文件改动。 目标明确、影响面小，直接把整个文件贴进去，加一句改动要求。这类任务不需要解释项目结构，它读完文件就能动手。输出要求「返回完整文件」而不是 diff，避免自己拼补丁。

跨文件重构。 只给三样：要改的接口签名、所有调用点的位置和片段、项目的目录树。不要给全仓库。改完之后最容易出问题的是遗漏调用点，所以要在提示里明确「列出你找到的全部调用点，再动手改」，让它先输出清单，你确认后再执行。

修 bug。 给失败测试的完整输出、报错栈、相关的那几个文件，以及一句「先解释根因再改」。跳过根因直接改，是它最常犯的错——会把异常吞掉，测试通过，问题还在。

上下文给的顺序有讲究

前部稳定、后部变化。项目约定、技术栈、代码风格放最前面并保持不变，具体任务放最后。这不只是习惯问题：命中缓存的输入按 $0.003 每百万 token 计，未命中是 $0.15，差 50 倍。同一套系统提示反复用，前部固定就能一直吃这个价。

代码库大的时候，用「锚点」代替全文。比如只给 src/api/client.ts:40-90 这一段，再附一句「其余部分按现有约定处理」。它会自己推断风格，通常比塞进三千行无关代码更准。

两个只在思考模式下出现的坑

思考模式默认是开的，这带来两个反直觉的行为。

温度参数失效。开了 thinking 之后 temperature 不生效，想要更确定的输出，改用 reasoning_effort 在 low / high / max 之间调。低难度任务用 low，能省下大量思考 token。

工具调用要回传思维链。带工具的多轮对话里，reasoning_content 必须原样带回下一轮，否则接口返回 400。不带工具时它会被忽略，可以省略。同一个 400 还会出现在 tool_choice: "required" 上——思考模式下不接受强制工具调用，需要先关掉 thinking。

另外，FIM（中间填充）补全目前是 beta，且只在关闭思考时可用。想拿它做 IDE 补全，别指望开箱即用。

它最容易错的三处

编造不存在的 API。 越冷门的库越容易中招：参数名看着合理，实际不存在。防御办法是要求它对每个新引入的调用标注来源文件，或者干脆禁止新增依赖，只允许用项目里已经出现的函数。

静默改无关代码。 顺手格式化、顺手改个变量名、顺手升个版本。这类改动不会报错，但会让 review 变得极慢。在提示里写明「除目标函数外不得修改任何行」，并在提交前用 diff 检查行数变化。

测试通过但没修好。 它倾向于让测试变绿，而不是让逻辑正确。所以验收不能只看测试结果，还要看它是否修改了测试文件本身——改了测试的修复，一律打回。

一个可以直接用的骨架

项目：Node 20 + TypeScript，禁止新增依赖
约束：除 src/order/calc.ts 外不得修改任何文件
任务：calculateTotal 在数量为 0 时返回 NaN，先说明根因
输出：完整文件 + 改动点列表

四行足够。项目、约束、任务、输出格式，缺哪一行都会让它自由发挥。

验收按这个顺序

先看改了哪些文件，再看测试有没有被改，最后看逻辑是否符合需求描述。三步都过再合并。工具层面的横向对比可以看 AI 编程工具怎么选，如果团队已经在用 字节 TRAE 这类集成环境，DeepSeek 更适合放在「需要长上下文读整个模块」的环节，而不是逐行补全。

最后提醒一句：deepseek-chat 和 deepseek-reasoner 已在 2026 年 7 月 24 日停用，配置文件里还留着这两个名字的项目，先改成 deepseek-flash，否则调不通。