简介：围绕 DeepSeek 网页端、API 集成与移动端三大使用场景编写的操作指南，面向需要将大模型能力落地到业务的开发者、技术产品经理及企业服务负责人，也适合想借助 AI 改善用户体验、提升客服自动化程度的产品和运营人员。包内为单个 docx 文档，压缩包整体仅 16KB，结构紧凑，便于按章节随时查阅；目前已有 5984 人学习浏览，是 DeepSeek 入门资料中关注度较高的实用文档。内容覆盖三类环境：网页端给出官网访问、手机号/微信/邮箱注册登录及发起对话的完整流程；API 部分以 Python 为例，从创建 API Key、安装 OpenAI SDK，到调用 DeepSeek 端点并解析响应，配有可修改运行的示例代码；移动端针对无官方 App 的情况，介绍了通过 Chatbox 添加自定义提供方、选择 OpenAI API 兼容模式、填入参数并验证部署，同时可查看 tokens 用量与余额。读者按文档操作即可完成三种接入方式的配置与测试，减少自行摸索的试错成本；整体内容精炼，兼具操作步骤与机制理解，可作为个人学习和团队技术方案的参考。
1. 这份指南要解决什么问题：从聊天框到业务系统的三层跃迁
很多人接触 DeepSeek，是从网页端那个对话框开始的，问几个问题、让它写一段文案，觉得“也就那样”。但真正让它产生价值的用法，是把它从“聊天玩具”变成“生产力工具”。这个工具或者说服务的特别之处在于：它同时提供了零门槛的网页端、可编程的 API 接口，以及能在手机上随身携带的移动端交互方式。这意味着一个人可以从“会用对话框”起步，一路走到“把模型能力嵌入自己的业务流程”，整个过程不需要更换技术栈，也不需要重新学习一套交互逻辑。
我见过不少开发者，在网页端用得顺手以后，想把它集成到自己的系统里，结果卡在了 API 的认证、参数调优和流式输出上，又回头来抱怨“接口不好用”。其实大部分困惑不是因为能力不够，而是没有把三种使用场景放在一条路径上去理解。网页端是探索和验证的地方，API 是自动化和产品化的桥梁，移动端则是场景延伸的入口。这篇笔记会把三层用法拆开讲清楚，给出能直接照做的操作步骤和参数配置，也会把我踩过的坑和排查思路一并交代，就是为了让你在读完以后能直接上手，而不是停留在“我知道了”的层面。
2. 网页端：把对话窗口当成你的交互试验台
2.1 会话管理：多线程对话与上下文隔离的正确打开方式
网页端最常见也是最容易被浪费的功能，是左侧的会话列表。很多人从头到尾只开一个对话框，所有问题都在里面问，结果上下文越滚越长，模型回答越来越“散”，甚至开始答非所问。这不是模型变笨了，而是你把它的“短期记忆”塞得太满了。DeepSeek 的网页端对上下文长度有上限，超出部分会被截断，早期输入的内容就完全失效了。
我一般会按照任务类型来开新会话：写文案归写文案，看代码归看代码，查资料归查资料。每个会话只围绕一个主题，这样上下文窗口能全部用于当前任务，回答质量明显更稳定。尤其是当你需要它分析一段长文本时，单独开一个会话，把文本放进去，让它基于这段文本做摘要、提取要点或翻译，效果远比在旧会话里接着聊要好。
网页端的另一个实用功能是会话重命名。对话多了以后，靠记忆找会话不现实，我习惯在会话开始时就给它一个明确的名字，比如“XX项目周报生成方案”。这样后期间隔几天再回来，通过搜索功能能快速定位到当时的思路和结论。另外，删除会话不等于删除记忆，DeepSeek 官方并不会因为你在网页端删了一个会话，就把它从模型参数里抹掉，这只是清空了你这边的聊天记录视角，不要有“删了就等于没发生过”的错觉。
2.2 文件上传与长文本处理：上传前先做这三件事
网页端支持上传文件，PDF、Word、Excel 这些格式基本都能处理。这里有一个很多人忽视的关键点：文件里的图片和扫描件，模型不一定能“看”到。DeepSeek 是纯文本模型，不具备多模态视觉能力，你把一张扫描版 PDF 传上去，它能提取出来的只有排版压扁的文本层，如果 PDF 本身没有文本层，它就只能读到一堆乱码或空内容。
在用文件上传功能之前，我一般会做三件事：
- 确认文件是文字版 PDF，而不是扫描版。后者建议先转成文本或 Markdown 再上传。
- 文件如果很大，超过了上下文窗口的承受范围，先做一次精简。只把关键段落贴进去，而不是整个文件一股脑丢过去。
- 明确告诉它“接下来基于你刚才看到的文件内容回答我的问题”，把它锚定在文件语境里，避免它跑回自己的知识库去找答案。
另外，上传图片问“这张图里有什么”这类玩法，在网页端是无效的。如果你真的需要处理图片内容，正确做法是先找一个 OCR 工具把图转成文字，再把文字喂给 DeepSeek。这不是绕弯子，而是由它的模型架构决定的，你非要让它看图，它也只能猜，猜出来的答案基本不可信。
2.3 联网搜索的取舍：什么时候开，什么时候一定别开
网页端有一个联网搜索的开关，位置在输入框上方，默认是关闭的。这个开关的语义非常明确：开启后，模型在回答时会检索外部网页信息来补充知识库之外的内容，适合查实时资讯、验证最新事件、找政策文件等场景。
但如果你只是让它写一篇行业分析，或者做一道算法题，我建议不要开联网搜索。原因有二：第一，联网检索到的内容质量参差不齐，有些网页信息会干扰模型的判断，让回答变得冗长且带无关细节；第二，联网搜索会拖慢响应速度，本来几秒能出的答案，可能要等十几秒甚至更久。你在写代码的时候，也完全不需要联网，模型本身的代码能力足以覆盖常见编程问题。
这个开关的设计逻辑其实是在“知识时效性”和“回答稳定性”之间做取舍。我的习惯是：凡是答案有明确对错之分的任务，关联网；凡是答案依赖最新信息、没有固定标准答案的任务，开联网。比如“2025年某地最新人才引进政策”这种问题，必须开联网，因为模型训练数据的截止时间一定早于政策发布日期；而“Python 里怎么把字典按键排序”这种问题，开了联网反而容易把简单问题复杂化。
3. API 集成：把 DeepSeek 变成你系统里的一个函数
3.1 从拿到密钥到第一次调用：完整的最小请求示例
API 集成是 DeepSeek 从“对话工具”升级为“系统组件”的关键一步。第一步是去开放平台注册账号，创建 API Key。这个 Key 是你的系统与 DeepSeek 服务之间的唯一凭证，权限很大，不要把 Key 硬编码在代码里，更不要提交到 Git 仓库。我见过有人把 Key 放在前端代码里，结果被爬虫抓走后疯狂调用，账单直接爆掉。
拿到 Key 以后，我们来看一个最小调用示例。用 curl 就能完成第一次请求：
curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个乐于助人的中文助手"}, {"role": "user", "content": "介绍一下你自己"} ], "stream": false }'这个请求做了四件事：指定模型为deepseek-chat（即 DeepSeek 的通用对话模型），通过messages数组传递了两条消息（一条系统提示词，一条用户问题），关闭了流式输出（stream: false），然后发给 DeepSeek 的 chat completions 端点。如果你把这段代码复制到终端里运行，注意把YOUR_API_KEY换成自己的真实 Key，就能看到类似这种返回：
{ "id": "chatcmpl-xxx", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "你好！我是一个中文语言模型，可以帮你处理文本、回答问题、辅助编程..." }, "finish_reason": "stop" } ], "usage": { "total_tokens": 45, "prompt_tokens": 20, "completion_tokens": 25 } }返回结构里，真正有用的部分是choices[0].message.content，这就是模型生成的回答。usage字段记录了本次调用消耗的 token 数，这个数字直接关联到你的账户余额，做产品的时候一定要关注。一次完整的 API 调用流程就是这么简单：构造请求、带上认证、接收 JSON、解析结果。
3.2 三个关键参数：temperature 的玄学与 max_tokens 的边界
API 请求里有一个参数叫temperature，控制的是输出内容的随机性。取值范围通常是 0 到 2（不同模型默认值略有差异），我把它叫“玄学参数”，因为它的实际效果很难精确预测，但在不同任务上选不同值，确实能明显改变回答风格。
我的经验值是：写代码、做数学题、数据提取这类需要精准回答的任务，temperature设为 0 或 0.1，让模型尽量选择概率最高的输出；写文案、头脑风暴、生成各种创意内容时，temperature设为 0.7 到 1.0，让输出有更多多样性；做翻译或摘要，可以取一个中间值 0.3 左右，既保证准确又有一定灵活性。
另一个参数max_tokens控制单次回答的最大长度。这里有一个很容易踩的坑：新手常常把max_tokens设得特别大，以为这样就能让模型一次给出更完整的回答。但在实际使用中，你更需要关心的是这个参数的上限约束。DeepSeek 的模型单次输出有最大 token 数限制，当你需要超长输出时，正确做法是让它分段生成，或者用“写大纲后逐节填充”的提示词策略，而不是把max_tokens加到上限然后祈祷它一次性成功。我在集成时习惯把max_tokens设为 1024 或 2048，如果一次生成内容不够，再追加一轮“继续”的请求。
还有一个隐藏参数top_p，控制的是候选词的概率累计，一般与temperature搭配使用。我的建议是不要同时调这两个参数，工程上保持top_p为默认值，只调整temperature就够了。同时调会让输出变得难以预测，出问题以后你很难定位是哪边导致的。
3.3 流式输出：为什么你的打字机效果总是不流畅
stream参数可能是网页端和 API 端体验差异最大的地方。网页端的回答是逐字蹦出来的，看起来很流畅；你自己调 API 时如果设置stream: false，就是一个请求发出去，等几十秒，然后一次性收到完整 JSON。这种“等待式”交互在用户体验上是很糟糕的，尤其当你做一个聊天机器人产品时，用户会以为系统卡死了。
流式输出的原理是：服务器把回答内容拆成一段一段的 SSE（Server-Sent Events）数据块，客户端收到一块就渲染一块，这样用户看到的效果就是“打字机模式”。在 Python 里用 OpenAI SDK 调用 DeepSeek（接口协议兼容）时，只需要把stream设为True：
from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", base_url="https://api.deepseek.com" ) response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个代码助手"}, {"role": "user", "content": "写一个Python函数，判断一个字符串是否回文"} ], stream=True, temperature=0.1 ) for chunk in response: delta = chunk.choices[0].delta if hasattr(delta, "content") and delta.content: print(delta.content, end="", flush=True)这里有一个细节：流式返回的每个chunk里，choices[0].delta.content才是本次增量生成的文本片段，需要你把它们按顺序拼接起来。而且流式模式下，最后一个 chunk 的finish_reason会是"stop"，这可以作为生成完成的信号。很多人在做流式输出时卡在“前端一直收不到完整内容”，就是因为没有拼接增量，只取了最后一个 chunk 的文本，那自然只有最后一个字。
在非流式模式下，一次响应就包含完整内容；流式模式则是边生成边传输。如果你在自己的系统里遇到了打字机效果不顺滑、页面卡顿、总是少内容的问题，优先检查这三个地方：后端是否正确拼接了所有 delta、前端是否对 SSE 格式做了正确解析、网络层是否有缓冲拦截导致数据不能实时到达。流式排错排查往往比功能开发更花时间，但它是走向“工业级使用”的必经之路。
3.4 多轮对话与上下文管理：别把所有消息一股脑全丢过去
API 模式下的对话是有状态的吗？答案是没有。服务端不会记住你上一次请求的内容，你每次调用都是“全新对话”。所以当你需要实现多轮对话能力时，你必须把整段对话历史通过messages数组传给服务器。
这是我见过翻车最多的地方：开发者把用户消息全部塞进messages，不截断、不清理，结果一方面是 token 消耗越来越大，账单越来越贵；另一方面是上下文过长后，模型反而抓不住重点，回答质量下降。正确的做法是给对话设置一个窗口大小，比如只保留最近 10 轮消息，更早的消息直接丢弃，或者做摘要后把摘要作为一条 system 消息放进上下文。
def build_messages(history, new_question, max_rounds=10): messages = [{"role": "system", "content": "你是一个简洁的技术助手"}] for item in history[-max_rounds:]: messages.append({"role": item["role"], "content": item["content"]}) messages.append({"role": "user", "content": new_question}) return messages这个函数做了两件事：用max_rounds=10截断历史，超过 10 轮的部分直接丢掉；然后把截断后的历史和当前问题拼接到 messages 里。对于大多数客服机器人、知识库问答等场景，10 轮以内的上下文已经足够，更早的内容对当前回答的参考价值微乎其微。如果你的场景确实需要长对话记忆，建议把历史消息做一次总结，把总结文本作为 system 消息传给模型，而不是把原始消息一股脑全丢过去。同时也要注意，system 消息的优先级高于 user 消息，你可以用 system 消息注入一些稳定的指令（比如“回答尽量简短，不要使用 Markdown 结构”），模型会优先遵循这部分设定。
4. 移动端：把交互延伸到办公室之外
4.1 官方 App 的三种输入方式：语音在特定场景下效率更高
官方 App 的交互基本复刻了网页端的能力，但针对移动场景增加了两个重要特性：语音输入和跨设备同步。语音输入的本质是把你说的话转成文字，再走和网页端相同的对话流程。在办公室以外、不方便打字的场景里，语音的效率提升是显著的。比如通勤路上突然想记录一个灵感，你对着手机说一段话，App 自动转录并发给模型，模型返回文本回答，你再随手转发到文件传输助手或备忘录里留存。我在实际使用中，语音识别的准确率在普通话、非专业术语场景下基本够用，偶尔遇到专有名词或英文缩写时会识别错，我的补救方法是对着它把那个词单独说一遍，或者干脆手动改正。
移动端的第二种输入方式是文件上传。和网页端一样支持文档类文件，但移动端多一个便利之处：可以直接从手机相册、文件 App 里选文件。第三种就是最普通的键盘打字，在电脑不在身边时应急用。三种输入方式对应的是三种典型需求：语音对应“手不方便但嘴方便”，文件上传对应“需要基于文档内容回答”，键盘打字对应“精确表达需求”。搞清楚不同输入方式的优劣势，才能在不同场景下选对交互路径。
4.2 移动端固定场景的价值：工作流最短闭环
移动端真正让 DeepSeek 产生高频价值的，不是和它闲聊，而是把它嵌入固定的工作流。比如我经常收到需要查阅的大型 PDF 文档，一个几百页的标准文件不能全喂给模型处理，所以我的方式是：在电脑端用脚本把 PDF 按章节拆分成多个小文本，逐个在移动端上传询问。因为移动端经常扮演的是“验证结论”的角色，而不是“完整分析”的主角。
如果你做项目管理或内容审核，也可以把检查清单（Checklist）存成文本，需要时发一段给模型，让它按清单逐项核对你的方案，快速发现遗漏。这才是移动端在办公室之外的生存之道：它是一个触手可及的“轻量入口”，但复杂任务仍然优先在电脑端完成。如果你希望随时随地使用这个能力，把手机上的入口当作一个快捷指令来设置，会比你每次打开 App 都重新描述问题要高效得多。
4.3 多终端协同：网页端的会话怎么在手机上接续
DeepSeek 支持多端登录，但有一个很多人的困惑：“我在网页端建的会话，手机上为什么看不到？”这其实和会话同步机制有关。同一个账号下，会话默认会在 Web 端和 App 端之间同步，但这个同步是有延迟的，并非毫秒级实时同步。如果你在电脑端刚创建了一个会话，立刻打开手机端去看，有时候看不到是正常的，稍等几秒或下拉刷新再排查。
多终端协同的正确打开方式，不是“所有端都显示同样的东西”，而是“各取所长”。遇到长文档、复杂代码时，优先在电脑端处理；外出时有急事，用手机跟进一下进度。选型点在于什么时候用哪个端更顺手。有一个细节：不要在手机上做超长文本分析或大规模代码调试，屏幕太小、上下文难以总览，效率很低。如果想重构一段代码，把它完整贴到电脑端的 API 或网页端去处理，比在手机上“划来划去”要靠谱得多。
4.4 通过钉钉/飞书这类应用把它“接入”日常办公
如果你想在移动端获得更顺畅的交互体验，除了官方 App，还可以通过钉钉、飞书这类办公协作工具来实现对接。原理不复杂：办公应用提供自定义机器人或 Webhook 能力，你把 DeepSeek 的 API 封装成一个中转服务，收到办公应用发来的消息，就转发给 DeepSeek，再把 DeepSeek 的回答返回给办公应用。
我在模拟项目X里做过一个最简版本，流程是这些步骤：
- 在飞书（或钉钉）后台创建一个自定义机器人，拿到 Webhook 地址。
- 写一个最简的 HTTP 服务，接收飞书发来的事件请求。
- 从中取出用户发送的文本，拼装 DeepSeek API 请求。
- 把模型回答按飞书消息格式返回。
这个方案的移动端价值在于：不用打开专用 App，直接在飞书里发消息就能获得模型能力，也支持了群聊场景，一个群的人可以把共同问题丢给机器人。我实际跑通过的最小 Python 代码大概是这样：
from flask import Flask, request, jsonify from openai import OpenAI app = Flask(__name__) client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.deepseek.com") @app.route('/webhook', methods=['POST']) def webhook(): data = request.json user_input = data.get('text', '') response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": user_input}], temperature=0.3 ) answer = response.choices[0].message.content return jsonify({"msg": answer}) if __name__ == '__main__': app.run(port=8000)这里的核心是设置base_url="https://api.deepseek.com"，让 OpenAI SDK 能和 DeepSeek 服务正常通信。实际生产环境里还需要验证请求来源、设置访问限制和超时重试，但这个最小实现证明了思路可行。它把移动端交互从一个“看手机屏幕”的动作，变成了“在常驻办公软件里顺手完成”，对于高频轻度用户尤其合适。你可以按照飞书或钉钉各自的事件订阅方式做细微调整，但整体架构是一致的。
5. 避坑与常见问题排查：从网页端到 API 三层各自的翻车点
5.1 网页端一个常见误区是文件上传后它“看不见”内容
现象：我把一个 PDF 上传到 DeepSeek 网页端，让它“总结这份文件的核心观点”，它回复“我还没有看到文件内容，请提供文件文本”。
原因：
这个 PDF 是图片型 PDF，里面的内容是扫描图片，没有文本层。DeepSeek 是文本模型，无法直接识别图像，它“看”到的实际是空白文本。
解决：
先用 OCR 工具（在线或本地均可）将扫描件转为可复制文本，然后复制粘贴到对话框里，再提问。对于文字型 PDF，也要确认没有损坏，可以先用文本编辑器或 PDF 阅读器打开搜一下关键词，验证文本层存在。
5.2 API 调用时报错 401 或 403
现象：
请求返回401 Authentication Fails或403，无法正常获取回答。
原因：
认证信息有问题，大概率是 API Key 无效、填错、或者请求头中Authorization格式不对。最常见的是复制 Key 时多复制了空格，或者 Key 本身已过期。
解决：
先打印出你拼接的整个请求头，确认Bearer后面只有一个空格，Key 里没有换行符。再到开放平台检查 Key 是否过期、是否被手动删除，重新生成一个新 Key 一次跑通。
5.3 流式输出时“打字机”断断续续或卡死
现象：
设置了stream=True之后，前端收到的内容不是连贯的逐字输出，而是一个字一个字蹦，还频繁停顿，甚至到一半断开连接。
原因：
可能有三点：第一，你的代码没有正确拼接所有增量delta，只在最后一个 chunk 里取内容；第二，客户端对 SSE 数据解析存在问题，把多个事件当成一个处理；第三，网络层或服务器超时把长时间的流式连接断掉了。
解决：
先在后端把完整拼接结果打日志，确认模型输出是否完整；再检查前端 EventSource 或 fetch 的流式解析逻辑；最后排查服务端和网关的超时配置，把超时时间调长，不要设默认值 60 秒上限。
5.4 移动端 App 收不到网页端新建的会话
现象：
电脑端网页版对话进行到一半，打开手机 App，发现看不到刚才的会话记录。
原因：
会话同步有延迟，并非实时同步；另外如果账号在不同设备上登录时间点不一致，也会导致视图不一致。
解决：
在 App 端下拉刷新或退出重进会话列表，过几十秒再检查。如果仍然看不到，检查你的账号是否在两个端使用的是同一个入口登录（同一家服务商或同一下发渠道的凭据），不要拿不同登录渠道的账号来对比。
5.5 API 计费消耗太快
现象：
没怎么做几个请求，账户余额告急了，查看用量发现 token 消耗远超预期。
原因：
最常见的是把多轮对话的历史消息全部传来传去，而不做截断。每一轮请求都把全部历史重新发给模型，相当于每轮都在重复计费之前轮次的内容。另一个原因是max_tokens设置得太大，模型生成了大量无用填充。
解决：
按 3.4 节的方式做上下文窗口截断；max_tokens设置一个和你输出预期相符的值；在每次响应的usage字段中统计好 token 数并打日志，做消耗趋势监控。
6. 进阶：让 DeepSeek 从“能回答”变成“好用”的四个技巧
6.1 用 system 消息为特定任务定制回答风格
把 system 消息当作“人设”来用。不是让它扮演角色这种表面玩法，而是用它施加硬性约束。比如我写 API 集成时，会这样写 system 消息：“你是一名资深后端工程师。回答代码问题时，先给出完整代码，再做简要解释。不要谦虚，不要自夸，不要使用 Markdown 表格以外的花哨格式。”这种固定风格的 system 消息对模型输出稳定性提升明显，尤其适合做中台工具。
6.2 结构化输出：让它返回 JSON 而不是自然语言
做程序对接时，自然语言返回是灾难。让模型强制输出 JSON，有几种做法：在 prompt 里明确要求“只输出 JSON，不要输出其他文字”，同时给出目标 JSON 的结构示例。DeepSeek 在指令遵循方面表现不错，格式一般能稳定命中。我在做信息抽取和数据处理时，基本不用再写一堆正则去解析模型输出，一个 JSON 结构直接送入下游流程。
6.3 自我校验循环：让它批改自己的答案
一个高级玩法：让模型生成答案后，自己扮演审查者，把答案当成输入再检查一遍，指出其中的错误或漏洞，然后再修正。对于技术文档、代码审查这类场景，这个循环能显著提升正确率。代价是 token 消耗翻倍，所以只需要语气严谨的任务里才用，而不是每次对话都用。我一般把它用在“关键性的决定”上，比如新方案的评审，或者复杂代码的生成。
6.4 用“温度调度”实现创意任务的质量上限
创意写作类任务适合较高温度（0.8 到 1.0），但高温度下输出质量波动大。我用的策略是：先用低温度（0.2）生成一个稳定骨架，再用较高温度对骨架进行扩展和润色。这个方法等效于“先想清楚再发挥”，在文案生成、标题创作等任务上实测效果比单次高温度生成更稳定。
我在把这些技巧投入实际程序化使用时，最大的教训是：不要过度依赖“感觉”。每换一个场景，都要拿真实样本去试，尤其是温度参数和 system 消息的组合，在不同任务上表现差异很大。你要慢慢积累一套自己的“参数-任务”匹配表，而不是套用别人的默认值。移动端、网页端和 API 端三个入口，同一个模型，但交互节奏完全不同，你要养成针对不同入口设置不同提示词习惯。希望这几点能帮你少走一段弯路，也希望你能在剩下的路径里摸出自己的复用模式。
本文还有配套的精品资源，点击获取
