简介：一份围绕DeepSeek使用方法的指南，重点挖掘多数用户忽略的实用技巧；无论你是刚接触推理模型的初学者，还是希望提升问答质量的进阶用户，都能从这份资料中找到适合自己的用法。资源包内只有1个PDF文件，大小约6.47MB，便于随时查阅。指南先介绍网页端和手机端两个使用入口，以及深度思考、联网搜索等关键功能的适用场景，再说明如何通过官方状态页判断服务是否稳定，遇到服务器繁忙提示时能够快速定位原因。作者还系统比较了推理型大模型与指令型大模型的差异，提出“背景加需求加约束条件”的万能提问模板，并配以多个主流模型的同题回答对比，展示DeepSeek自动补充细节、让答案更具体形象的特点；若回答深度不足，可继续让AI就某一点展开讲解，使其成为日常学习、工作与生活的得力助手。目前已有134人学习，适合所有想释放DeepSeek潜能的用户。

1. 最有用的 DeepSeek 使用指南，往往输在 API 调用姿势上

同一个问题丢给 DeepSeek，有人拿到一段能直接跑的代码，有人只得到一段正确的废话。差距不在模型本身，而在调用姿势：参数怎么配、上下文怎么管、工具调用结果怎么回传、指令怎么给。这份标题叫“80% 的人都不知道的使用技巧”的指南，本质上说的就是这些没人写进快速开始文档里的细节。我平时帮团队接 DeepSeek，不管是官方 API、vLLM 本地部署，还是接 Codex、企业微信这类工具链，踩的坑高度集中在这几个点上。这篇笔记把它们整理成可直接照做的方案，适合正在用 DeepSeek 但觉得效果不达预期的人，也适合准备把它部署进业务系统的开发者。

2. 指令与参数：把 DeepSeek 当推理引擎，别当聊天框

2.1 指令遵循风格：DeepSeek 更吃“任务契约”，不是“角色扮演”

很多人在 ChatGPT 上养成了“你是一个资深的……请帮我……”的提问习惯，这套搬到 DeepSeek 上能用，但远不是最优解。DeepSeek 系列模型在训练时对齐了较强的指令遵循能力，它对“任务描述 + 输入数据 + 输出格式约束”这种结构化契约的响应质量，明显好过对模糊角色的响应质量。

我一般会把提示词拆成三段：任务目标、输入材料、输出契约。任务目标用一句话说清楚要做什么；输入材料单独给，不让模型从冗长对话里自己翻；输出契约写死格式，比如“只输出 JSON，不要代码块包裹”。DeepSeek 对 JSON 输出的遵循度很高，但前提是你在提示词里明确说了“不要输出多余文字”，否则它会在 JSON 前后加解释。

实际调用时，还有一个容易被忽略的点：DeepSeek 对 system 和 user 消息的内容是有权重差异的。system 消息里的约束比 user 消息里的更稳定，所以像“禁止追问、直接给结论”“如果信息不足，输出 UNKNOWN”这类硬规则要放 system，不能放 user。否则用户输入一长，末尾的约束容易被模型忽略。

2.2 参数设置：temperature、top_p、max_tokens 的推荐基准

DeepSeek 的 API 参数和 OpenAI 兼容，但默认值不一定适合你的场景。官方接口默认的 temperature 在通用对话上表现尚可，可一旦做代码生成、JSON 抽取、分类打标这类任务，必须手动调。

我做过的经验值是：代码生成与格式化输出，temperature 设在 0.1 到 0.3 之间，top_p 保持 1.0 或降到 0.9；创意写作、头脑风暴，temperature 拉到 0.8 以上，top_p 相应降到 0.9 以下；信息抽取和问答，temperature 设 0，让模型尽量走确定路径。这里面最玄学的不是 temperature 本身，而是 top_p 与它的联动。调参时先固定一个，只动另一个，不然两个一起改，翻车了都找不到是谁的锅。

max_tokens 是一个高频误解点。它限制的是输出长度，不是输入长度。很多人把 max_tokens 设成 4096，以为能处理长文档，结果输入一长，输出直接被截断。DeepSeek 会先吃掉输入上下文，再把剩余额度分配给输出，输入越长，实际可输出的 token 越少。所以做长文档摘要时，max_tokens 要预留足够空间，或者干脆用流式输出分段拿结果。

2.3 上下文管理：长对话怎么做记忆裁切与关键信息回填

DeepSeek 的上下文窗口虽然大，但不意味着你可以无限堆对话。上下文一长，有两个问题：一是 token 费用线性上涨，二是模型对早期信息的注意力衰减，回答质量明显下滑。我常用的做法是“分段压缩 + 关键信息回填”。

具体操作是：每轮对话结束后，把这一轮的结论用一个小模型或正则抽出来，压缩成结构化摘要，存到一个独立的 summary 字段里。下一轮请求时，messages 结构是“system + summary + 最近 N 轮原始对话 + 新用户输入”。这样既保住了长期记忆，又不会让上下文无限膨胀。

还有一种做法是直接裁掉中间轮次，只保留第一轮和最后一轮。但要注意：如果最后一轮引用了中间某个数据，模型会因为没有上下文而一本正经地编一个。所以回填很重要，裁掉之前先把关键数字、文件名、约束条件提取出来，放在 system 里。这个动作既是工程问题，也是提示词问题，做得好不好直接影响结果可靠性。

2.4 用“子任务拆分”替代“一步到位”，模型会更稳

DeepSeek 处理复杂任务时，一步到位的效果往往不如拆成多步调用。常见做法是先让模型做信息抽取，把关键字段抽出来；再基于字段做判断或生成。两步走虽然多一次 API 调用，但每一步的任务都足够单一，输出稳定性和可调试性都远好于一次超长指令。

在代码里体现为两次独立请求。第一次请求 system 提示“抽取用户输入中的所有数值和单位，输出 JSON”；第二次再把 JSON 作为输入，让模型基于这些数据写结论。这样做还有一个附带好处：任何一步出问题，你能立刻定位是抽取错了还是生成错了。不要嫌多一次调用费钱，返工重试的成本通常更高。

3. DeepSeek API 如何调用：一条 curl 跑通与三处选型边界

3.1 官方 API 的最小可用调用：curl 与 OpenAI SDK 兼容写法

DeepSeek 的 API 兼容 OpenAI 格式，这意味着你可以直接用 openai 的 Python SDK 接，不用额外封装。最小可用调用我一般这样写：

from openai import OpenAI client = OpenAI( api_key="sk-xxxxxxxx", base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是信息抽取器，只输出 JSON。"}, {"role": "user", "content": "从这句话里抽取日期和金额：今天花了 128 元打车。"} ], temperature=0.1, max_tokens=256, stream=False ) print(resp.choices[0].message.content)

这段代码用的是 OpenAI SDK，只改了 base_url 和 model 名称。api_key 从官方控制台创建，建议用环境变量传，别硬编码到代码里。max_tokens 设 256 是因为抽取任务输出很短，给多了反而容易让模型输出多余内容。temperature 设 0.1，保证抽取结果稳定。刚才也说过，JSON 类输出把 temperature 压低是必须的，否则偶尔会出现字段名被模型自由发挥的情况。

如果你只是临时验证连通性，用 curl 更快：

curl -s https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -d '{ "model": "deepseek-chat", "messages": [ {"role": "system", "content": "只回复两个字：成功"}, {"role": "user", "content": "测试"} ], "stream": false, "temperature": 0 }'

curl 里$DEEPSEEK_API_KEY是环境变量，跑之前先在 shell 里 export 好。注意路径是/chat/completions，不是/v1/chat/completions。DeepSeek 的接口地址和 OpenAI 不是完全一致，很多人第一次接入在这里踩坑——base_url 写成了带/v1的路径，导致 404。这个问题在本章后面“常见问题”里还会专门说。

3.2 什么时候该上 vLLM 本地部署：算力门槛与收益临界点

官方 API 不是万能的，团队里有人纠结本地部署，我先给结论：单机没有 A100/H100 级别显存，日常办公场景直接用官方 API 更划算；如果你有 GPU 服务器，并且调用量一个月超过几十万 token，本地部署才有账可算。

本地部署 DeepSeek 的主流方案是 vLLM。vLLM 的好处是吞吐高、显存管理好，而且部署命令很短。最简启动命令是这个：

vllm serve deepseek-ai/DeepSeek-V3-Chat \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

tensor-parallel-size要和你 GPU 卡数对齐，8 卡就写 8，写小了显存装不下，写大了启动直接报错。max-model-len设 8192 而不是模型理论最大值，是为了给并发请求留显存余量。gpu-memory-utilization设 0.9，剩下 10% 留给 CUDA 上下文和碎片。

在 Jetson Orin 这类边缘设备上跑 DeepSeek，做法就不是 vLLM 了，而是量化 + llama.cpp。Jetson Orin 的显存和 GPU 服务器不在一个量级，通常要跑 Q4 量化版本，推理速度能用但谈不上快。这种部署适合数据不能出内网的场景，不适合追求响应速度的业务。本地部署的本质是用电费和硬件成本换数据隐私和边际调用成本，想清楚你的瓶颈到底是钱还是合规。

3.3 官方 API 与本地部署的价格对比：三个决策临界点

我遇过不少团队，本地部署完一看账单，电费加硬件折旧比直接调 API 还贵。这里给大家三个判断临界点：

第一，调用量临界点。月调用量低于几十万 token 时，官方 API 的边际成本远低于自建硬件的摊销成本。第二，并发临界点。业务需要高并发低延迟时，官方 API 的弹性扩缩容优势明显，自建集群要预留 3 倍峰值容量才稳。第三，数据边界临界点。数据绝对不能出内网的业务，没有选择，只能本地。

有一个折中方案也值得提：用官方 API 做开发和原型验证，等流程跑通了，再把高频路径迁到本地部署。这样你不用一开始就砸钱买卡，又能保证生产环境的数据合规。开发阶段用 API，生产阶段跑本地，是当前成本与隐私之间最好的平衡点。

官方价格方面，输入输出分别计价，缓存命中的输入价格远低于未命中，所以高频重复前缀（比如长 system 提示词）尽量保持稳定不变，能显著省钱。这个细节官方定价页有写，但很多人没注意到，实际账单差了 30% 以上。

4. 把 DeepSeek 接进日常工具链：Codex、VSCode、企业微信到 CCSwitch

4.1 Claude Code 与 Codex 接入 DeepSeek：一份配置，团队共享

最近社区里很热的玩法是把 DeepSeek 接进 Claude Code 或 OpenAI Codex 这类编程 Agent。原理很简单：它们都支持自定义模型 provider，只要把 base_url 指到 DeepSeek 的 OpenAI 兼容端点，把模型名改成 deepseek-chat，就能跑起来。

我用 Codex 比较多，配置写在~/.codex/config.toml，最小配置长这样：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"

env_key指定的是环境变量名，Codex 会从环境变量里读 key，不用在配置文件里明文写。wire_api设成chat，表示走 chat completions 协议。这里容易翻车的是base_url结尾不要跟/v1，Codex 会自动拼路径。

Claude Code 接 DeepSeek 也是类似思路，在配置里加一个自定义 provider。社区里有人专门整理过几套配置模板，核心就是那三行：base_url、model、api_key 环境变量。配置完第一件事不是写代码，而是跑一个最简单的“说你好”请求，确认链路通了再放任务进去。

这种接法最大的价值是团队共享：把配置文件提交到 Git 仓库，新人克隆下来 export 一下 API key 就能用，不用每个人单独研究怎么配。唯一要注意的是别把 key 提交进去，用env_key引用环境变量是最安全的方式。

4.2 VSCode 接入 DeepSeek：代码补全与评审的三种接法

VSCode 里接 DeepSeek，常见做法有三种。第一种是装 Continue 这类开源插件，在插件配置里把 provider 指到 DeepSeek；第二种是用 Cline 这类 Agent 插件，同样支持自定义 API 端点；第三种是直接在终端里用 Codex CLI，VSCode 只当编辑器用。

Continue 的配置是 JSON 文件，核心片段如下：

{ "models": [ { "title": "DeepSeek Chat", "provider": "openai", "model": "deepseek-chat", "apiBase": "https://api.deepseek.com", "apiKey": "sk-..." } ] }

provider写openai是因为 DeepSeek 兼容 OpenAI 协议，Continue 会按 OpenAI 的格式去请求。apiBase和刚才说的一样，不加/v1。这段配置里最不建议做的是把 apiKey 写死在 JSON 里，VSCode 插件配置经常被同步到云端，key 会跟着泄露。

代码评审场景和补全不是一回事。补全追求低延迟，适合把 temperature 调低；评审追求覆盖面，适合把 temperature 调高一点，让模型多挑毛病。同一个模型，在两个场景用同一份参数，效果会差很多。我的习惯是补全用 0.1，评审用 0.4，分开配两套模型条目。

4.3 企业微信与公众号接入 DeepSeek：从 API 到对话机器人的最小链路

把 DeepSeek 接进企业微信或公众号，本质是两件事：收消息和回消息。企业微信的机器人接口收到消息后，把文本转发给 DeepSeek API，拿到回复再通过企业微信接口发回去。这个转发逻辑用 Python 写一个 HTTP 服务就行。

最小链路的伪代码框架是这样的：

from flask import Flask, request, jsonify from openai import OpenAI app = Flask(__name__) client = OpenAI(api_key="sk-xxx", base_url="https://api.deepseek.com") @app.route("/webhook", methods=["POST"]) def webhook(): data = request.get_json() user_msg = data.get("text", "") resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是企业微信助手，回答简洁，不超过 200 字。"}, {"role": "user", "content": user_msg} ], max_tokens=300, temperature=0.3 ) reply = resp.choices[0].message.content return jsonify({"reply": reply})

这里的关键是 system 消息里的“不超过 200 字”。企业微信场景下回复太长会刷屏，必须由系统约束。另外消息需要加签名验证，否则任何人都能往你的 webhook 里灌数据，消耗 token 不说，还可能把你的服务当免费 API 用。

公众号的接入比企业微信麻烦一些，因为微信要求先验证服务器地址。验证逻辑是接收echostr参数并原样返回，拿到验证后再处理消息。这一步是纯体力活，按微信文档做就行。真正要注意的是超时：微信要求 5 秒内响应，如果 DeepSeek API 响应超过 5 秒，微信会重试，重试又会重复消耗 token。解决办法是接入缓存，相同问题在窗口期内直接返回历史答案。

4.4 多模型切换与自动化链路：CCSwitch 这类网关值得配吗

团队大了以后，不同成员可能用不同模型，有人用官方 API，有人用本地 vLLM，还有人想对比 Claude。这时候就需要一个统一入口。CCSwitch 这类 API 网关工具做的事就是把所有模型的 endpoint 收敛成一个地址，通过配置切换路由。

一个典型的 CCSwitch 配置思路如下：

providers: - name: deepseek-official base_url: https://api.deepseek.com api_key_env: DEEPSEEK_API_KEY - name: deepseek-local base_url: http://192.168.1.10:8000 api_key: "" routes: - path: /chat/completions default_provider: deepseek-official

api_key留空是因为本地 vLLM 默认不鉴权。default_provider指定默认路由，想切到本地时改一行配置就行。接入之后，所有下游工具（Codex、VSCode、脚本）都指向网关地址，上游模型随便换，下游不用动。这个模式在团队里非常实用，尤其是有人想对比不同模型输出质量的时候，不用一个一个改工具配置。

社区里还常听到 deepseek harness、hermes 这类围绕 DeepSeek 做二次封装的项目。它们的本质是把 API 调用包成可编排的自动化流程，或者对模型做重新打包发布。用之前先确认它有没有对齐官方接口，别让封装层变成黑匣子，出了问题都不知道是模型的问题还是工具的问题。

5. DeepSeek 使用高频踩坑：现象、原因与解决办法

5.1 “messages tool calls need immediate results”：工具调用结果没即时回传

这个是 API 调用里最常见的报错，错误信息是英文的，很多人第一次看到就懵了。现象是：上一轮返回的 assistant 消息里带了 tool_calls，你这一轮没有把工具执行结果以 tool 角色消息追加进去，直接发了新的 user 消息。

原因是 DeepSeek 的协议要求：一旦模型发起工具调用，你必须立刻把工具结果回传，不能跳过。回传格式必须满足两个条件：一是tool_call_id要和上一轮的 id 一致，二是消息角色必须是tool。很多人的代码里漏了 id 匹配，导致报错。

解决方法是严格按顺序拼 messages：

messages.append({ "role": "assistant", "content": None, "tool_calls": [{"id": "call_123", "type": "function", "function": {"name": "get_weather", "arguments": "{\"city\": \"上海\"}"}}] }) messages.append({ "role": "tool", "tool_call_id": "call_123", "content": "晴，25度" })

注意 assistant 消息里的content要传None，不能省。很多报错就是因为它没传或者传了空字符串，被服务端判定为协议不合法。还有tool_call_id必须原样返回，不能自己生成新的 id。工具链里原样透传是铁律。

5.2 “request extension preparation failed”：请求在客户端被拦截

这个报错通常在流式请求或长文本请求中出现，现象是请求发出去后很快失败，服务端返回 4xx，但错误信息指向“extension”。原因大概率在客户端：要么是 HTTP 客户端版本太老，不支持流式响应所需的分块传输；要么是你自己设置的代理层把请求头改坏了。

我遇到过一次是 Python requests 库在流式模式下没有设置stream=True，导致连接被服务端提前断开。换用httpx或者 OpenAI SDK 自带的传输层就正常了。如果用的是自建代理，优先排查代理的 buffering 设置，代理默认缓冲响应体时，流式请求会被憋住直到超时。

排查步骤我一般这么走：先用 curl 直连官方端点，排除自建链路问题；curl 能通就剩客户端和代理，逐步加大请求体长度，找到触发阈值的临界点。这类问题大部分是“请求头写了Accept-Encoding但服务端不支持”导致的，删掉这个头往往就好了。

5.3 上下文过长导致输出被截断：max_tokens 和输入长度混为一谈

现象是：输入一篇长文档，模型的回答明显不完整，往往在关键结论处戛然而止。原因就是前面说过的，max_tokens 限制的是输出，而 DeepSeek 处理请求时先算输入，再算输出。输入越长，可用于输出的 token 越少。

解决方法是先估算输入 token，再倒推 max_tokens。一个中文字符大约是 1.5 到 2 个 token，你输入了 5000 字的中文文档，输入 token 就占了七八千。如果上下文窗口是 8192，max_tokens 还设 4096，服务端直接报错或强制截断。

我的习惯是：长文档任务把 max_tokens 对应到输出需求，而不是窗口大小；窗口不够就先做分段摘要，再把摘要拼起来。与其把整本手册一次丢进去，不如先让模型分段读，最后再汇总。分段耗时更长，但输出完整度稳定得多。

5.4 本地部署显存不足：模型装进去就 OOM

现象是 vLLM 启动时报 CUDA out of memory，或者加载到一半进程被杀。原因通常是tensor-parallel-size没写对，或者是max-model-len设太大，KV cache 直接吃掉全部显存。

解决方法是先看显存总量，再算模型的参数显存。DeepSeek 的稠密模型用 FP16 加载，显存需求可以粗算为参数量的 2 倍。模型加 KV cache 加 CUDA context，至少要留 20% 冗余。启动命令里把gpu-memory-utilization从 0.9 降到 0.8，或者把max-model-len降到 4096，OOM 现象通常会消失。

还有一类 OOM 是并发请求引起的，vLLM 的并发数是隐式的，由显存余量决定。并发一高，KV cache 超限，也会有 OOM。解决方法是加--max-num-seqs参数，限制同时处理的序列数。设成 4 就是同一时间最多 4 个请求并行，多出的排队。

5.5 temperature 设置导致输出格式不稳定：JSON 解析偶发失败

现象是同样的提示词，90% 的请求能输出合法 JSON，10% 的请求会在 JSON 后面多一句解释，或者字段名给加了引号。原因就是 temperature 偏高，模型在概率采样时偶尔漂出约束。

解决方法是把 temperature 调低到 0，同时改进提示词，把“不要输出额外文字”写进 system。还有一招是用强制结构化输出：让接口返回一个已经解析好的 JSON 对象，而不是字符串。OpenAI 兼容协议里有 response_format 参数，DeepSeek 对它的支持要看当前模型版本，能用的场景直接上，省掉解析环节。

但如果你的代码里做了重试，那字符串解析失败不要立刻重试同样的请求，先对失败的输出做一次修正调用：把输出原样交给模型，告诉它“这是你的输出，请修正为合法 JSON”。修正调用比重新生成整个输出便宜得多，也稳定得多。

6. 用回归用例集给 DeepSeek 提示词做验收：让改提示词不再靠玄学

改提示词最大的问题是没后悔药：这次调好了，下次加一句话又不行了，却不知道是哪句话引起的。我的做法是建一个回归测试集，把业务里典型的输入和期望输出固化成用例，每次改提示词都跑一遍，用脚本判分。

最小回归框架长这样：

cases = [ {"input": "今天花了 128 元打车", "expect": ["128", "元", "打车"]}, {"input": "周四下午三点开会", "expect": ["周四", "15:00", "开会"]}, ] def evaluate(prompt): passed = 0 for case in cases: resp = call_deepseek(prompt, case["input"]) passed += all(k in resp for k in case["expect"]) return passed / len(cases)

evaluate的返回值就是这版提示词的评分。字段全部命中的用例算过，跑完得出一个准确率。每次改提示词，先跑一遍看准确率是升是降，再决定要不要保留改动。这样把“感觉上次效果好”变成可量化的数据。

我给团队的建议是至少攒 30 条用例，覆盖正常输入、空输入、超长输入、带格式符的脏输入四类。每次发布提示词变更，回归分数不低于基线才能放行。token 消耗成本不高，但换来的稳定性非常值。

另外记得在日志里记录每次请求的 token 使用量并推送到监控面板。我见过太多团队直到月底账单出来才发现某条 system 提示词让每次调用贵了 3 倍。它会暴露这种“低调的浪费”：同样的输出，缓存命中率低、前缀重复度高、max_tokens 虚高，逐一修完，账单立竿见影地降下来。这些都是我自己一路调过来的血泪经验，希望你不用再走一遍。这份指南的“80% 技巧”，大半其实就藏在这些参数、回传和回归测试的细节里，希望帮到你。

本文还有配套的精品资源，点击获取