★ FEATURED ARTICLE 简介一份围绕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_keysk-xxxxxxxx, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是信息抽取器只输出 JSON。}, {role: user, content: 从这句话里抽取日期和金额今天花了 128 元打车。} ], temperature0.1, max_tokens256, streamFalse ) 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 8000tensor-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、企业微信到 CCSwitch4.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 chatenv_key指定的是环境变量名Codex 会从环境变量里读 key不用在配置文件里明文写。wire_api设成chat表示走 chat completions 协议。这里容易翻车的是base_url结尾不要跟/v1Codex 会自动拼路径。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 CLIVSCode 只当编辑器用。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_keysk-xxx, base_urlhttps://api.deepseek.com) app.route(/webhook, methods[POST]) def webhook(): data request.get_json() user_msg data.get(text, ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是企业微信助手回答简洁不超过 200 字。}, {role: user, content: user_msg} ], max_tokens300, temperature0.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-officialapi_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 匹配导致报错。解决方法是严格按顺序拼 messagesmessages.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 库在流式模式下没有设置streamTrue导致连接被服务端提前断开。换用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 就占了七八千。如果上下文窗口是 8192max_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降到 4096OOM 现象通常会消失。还有一类 OOM 是并发请求引起的vLLM 的并发数是隐式的由显存余量决定。并发一高KV cache 超限也会有 OOM。解决方法是加--max-num-seqs参数限制同时处理的序列数。设成 4 就是同一时间最多 4 个请求并行多出的排队。5.5 temperature 设置导致输出格式不稳定JSON 解析偶发失败现象是同样的提示词90% 的请求能输出合法 JSON10% 的请求会在 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% 技巧”大半其实就藏在这些参数、回传和回归测试的细节里希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
