DeepSeek从入门到精通：提示词、API接入与避坑实战指南

简介：清华大学新闻与传播学院新媒体研究中心出品的《DeepSeek：从入门到精通》PDF指南，面向希望系统掌握DeepSeek大模型应用方法的AI学习者与从业者。内容覆盖DeepSeek是什么、能做什么、如何使用三大主线，重点讲解推理模型与通用模型的差异、CoT链式思维提示语策略、从指令驱动到需求导向的提问升级路径，并结合数学证明、创意写作、代码生成等场景给出模型选型与提示语设计建议。资源为单个PDF文件，大小5.92MB，版式清晰、图文并茂，适合作为快速上手与进阶实践的案头手册。目前已有9312人学习下载，认可度较高。通过这份指南，读者可学会根据任务类型精准选择模型、设计高效的提示语，也能理解DeepSeek国产免费开源的优势及其在文本生成、语义理解、代码辅助等场景中的应用边界，在人人都会用AI的环境中脱颖而出。

1. 为什么“DeepSeek从入门到精通”值得照着练一遍

最近很多人转发《DeepSeek从入门到精通》，但真正照着练完的并不多。大多数人的收藏夹里又多了一个吃灰链接，因为文档讲的是“能做什么”，没讲“在什么场景下怎么逼着模型把事做对”。我第一次用DeepSeek时也踩过同样的坑：把它当搜索引擎，想到什么问什么，结果拿回来一段还算正确但完全不能直接用的客套话。

后来我把用法倒过来。先不急着写提示词，而是确定三件事：这个任务该交给通用对话还是深度推理，要不要开联网，输出格式到底长什么样。顺序一旦摆对，DeepSeek的表现会立刻上一个台阶。所谓从入门到精通，拆开其实就是三步——选对模式、写好提示词、管好参数。

这篇笔记适合两类人：一类是刚注册账号、只会把问题贴进对话框的新手；另一类是已经在调 API、但总觉得回答不稳的开发者。我会按模型选型、网页端操作、API 接入、避坑、自动化验收的顺序来讲，每步都给出可以直接抄走的东西，不绕弯子。

2. 拆开第一步：分清DeepSeek的通用对话与深度推理，再写提示词

很多人拿到 DeepSeek 的第一反应是直接问，问完之后再根据结果猜它的性格。这其实是在用“黑匣子”的心态对待一个可配置工具，翻车概率很高。正确做法是先确认用的哪个模式、处理的是什么类型任务，再决定提示词怎么写。

2.1 两个模式不是聪明和笨的差别，而是快和慢的差别

DeepSeek 在网页端和 App 端通常提供两种使用模式：通用对话和深度推理。通用对话响应快，适合日常文本处理；深度推理会先展开一段内部思考过程，再给出答案，适合数学、逻辑、算法这类需要推导的任务。新手最容易犯的错误是把所有问题都丢给深度推理，觉得“贵的更聪明”，结果响应慢、token 消耗高，答案在简单问题上反而因为想太多而不够直接。

我一般按任务类型做选择，参考下表：

选择时最核心的判断标准是：这个任务是否需要“解释推导过程”。如果只要最终结论，哪怕是复杂问题，用通用对话也够；只有当你需要它展示为什么选这个方案时，再切深度推理。注意，深度推理的答案往往更长，如果你的下游脚本只取content字段，可能会把推理内容或附带说明一起带出来，要提前做好过滤。

2.2 上下文窗口不是无限记事本

DeepSeek 支持上传文档并把内容放进上下文里处理。很多新手误以为“放进去”等于“逐字精读”，其实模型是在有限窗口内做采样与注意力分配。你把一本 200 页的操作手册整个丢进去，它会优先关注开头、结尾和中间重复出现的主题词，细节容易被稀释。这不是模型不行，而是使用方式没有匹配它的工作方式。

我处理长文档一般走三步：

1. 上传文档后，先问“这份文档的结构是什么”，让它输出章节列表；
2. 再指定“只分析第几章，不要提其他章节”，把注意力收窄；
3. 要求它引用原文里的句子作为依据，避免它自己脑补内容。

这套流程能把一次“大锅烩”式提问变成多次“精准定位”，回答质量会有质的提升。另外，同一个会话里的旧问题会一直留在上下文中，新问题容易受之前讨论的影响。如果新任务和旧话题无关，宁可新开一个会话，也不要省这一步。

2.3 联网搜索别一直开着

DeepSeek 的联网搜索需要手动打开，默认并不会自动联网。很多人不知道这一点，以为它回答的就是实时信息，结果问出过时内容后才开始骂模型。联网开关的价值在于扩大信息源，副作用是响应变慢、回答变啰嗦，还会把网络上的噪声带进结果里。

我的习惯是分场景决定：

• 查新闻、政策、行情等有时效信息时，打开联网，并且要求它列出信息出处；
• 分析自己上传的文档或本地资料时，关掉联网，避免外部信息干扰；
• 写代码时也关掉，防止它把网上的过时写法混进你的工程里。

如果你确认已经打开联网，但答案仍然陈旧，有一个值得怀疑的方向是搜索链接本身命中了低质量页面。这时可以追问“你查到的信息来源是什么时间”，让它把引用链接的发布时间列出来，人工做二次判断。联网是辅助手段，不代表它能替你做事实核查。

提示：网页端通常会显示当前会话使用哪种模式，切换前留意一下开关状态，别凭感觉以为自己在用深度推理。

3. 网页端实操：四槽位提示词把DeepSeek的回答质量拉起来

网页端是大多数人的起点。很多人抱怨“DeepSeek 回答太模板化”，其实问题出在输入本身。模型不是读心术，你给一个含糊指令，它只能回一个含含糊糊的答案。把提示词拆成四个槽位之后，输出质量会立刻提升。

3.1 一个能直接套用的提示词骨架

网上讲提示词的文章很多，真正能落地的不多。我用的这套骨架来自一个很朴素的经验：你给模型的信息越像一份内部任务单，它越容易交出符合预期的结果。骨架由四部分组成：角色、背景、任务、输出格式。

先用一个最小模板看效果：

角色：你是一名有5年测试经验的Python工程师 背景：我有一段用requests编写的接口测试脚本，经常因为超时失败 任务：帮我改成带3次重试的版本，并加上日志 格式：先给出修改后的完整代码，再列出你改动的3个地方

这段提示词和“帮我改改这个脚本，总是超时”的区别在于：它给了模型一个身份约束，让它用测试工程师而非通用助手的视角处理问题；给了背景，让它知道你提的超时不是偶发现象；给了任务边界，明确要带重试；给了输出格式，避免它先讲一堆原理再给代码。四个槽位里，新手一般会漏掉“输出格式”和“角色”，这两个恰恰对稳定性影响最大。

3.2 把“总结”写成“规定动作”，而不是“随便说说”

“帮我总结一下这份会议纪要”是典型的低质量提示词。模型接收到这种指令后，会按训练时的习惯输出一份“正确的废话”：先说背景、再说意义、最后给个不痛不痒的结论。想要深度落到工作里，就得把总结要求拆成条目，并指定每一条的格式。

阅读下面这份会议纪要，只输出以下内容： 1) 3条明确决定，每条不超过20字 2) 2个待办事项，按“负责人-截止日期-事项”格式 3) 风险项，没有就写“无” 4) 下一步行动时间线 不要输出背景介绍，不要输出判断意见。

注意最后一句“不要输出背景介绍”，这比只写“请总结”更有约束力。模型在处理负面指令时表现往往比正面指令更稳定，因为它能明确知道哪些内容不该出现。如果你需要在团队里用 DeepSeek 批量处理类似文档，这套模板可以直接复用，只需要改任务名和条目数。

3.3 多轮对话里“改稿子”的三步动作

很多人改 AI 生成的内容时，习惯说“整体再改一下”，得到的往往是另一篇同样模板化的文章。想要改到位，最有效的方式是“指着改”。这个习惯我从编辑工作里带过来，用在大模型上一样好使。

第一步是指出位置，不说“第二段的表达不好”，而说“第三段整段删掉”；第二步是给参考，把你自己写的或者期望的说法贴一小段进去，告诉它“语气改成这样”；第三步是限范围，明确说“只改第二点，其他部分不要动”。三步配合下来，模型会变成听话的改稿助手，而不是每次都给你一个新版本让你重新习惯一遍。

这套做法背后有一个关键点：DeepSeek 的上下文是累积的。你在同一会话里多次修正，它会慢慢总结出你的偏好。如果你每轮都重新开对话重讲需求，等于每次都从零开始，难以积累风格。我的建议是：把一次改稿过程当做一个项目窗口，不要在项目进行中反复横跳。

4. API接入：用Python调通DeepSeek并稳定住输出

网页端适合交互式使用，想要批处理、接业务系统，就得走 API。API 接入并不复杂，核心是把请求结构调通、把参数设稳定、把异常处理写对。这三个点分别处理好了，DeepSeek 才能成为你系统里的一个可靠组件。

4.1 两种接入姿势：官方接口与统一网关

我接触到的接入方式有两种。第一种是直接调 DeepSeek 官方接口，它兼容 OpenAI Chat Completions 格式，用 API Key 做鉴权，适合个人项目和早期试验。第二种是通过公司内部的统一 AI 网关接入，网关层负责统一鉴权、成本统计、敏感词过滤，适合多个团队共用和多模型切换的场景。

如果只是自己写脚本跑数据，直接调官方接口最省事。如果是在公司生产环境里，我的建议是让网关层帮你把模型版本、限流策略、审计日志统一管起来，不然每次换模型都要通知所有下游改配置，运维成本会很高。无论选哪种，都不要在代码里硬编码 API Key，更不要把 Key 提交到 Git 仓库里。写在环境变量或本地配置文件中，并在服务端做权限控制，这是最基本的安全习惯。

4.2 最小可用代码：一个请求调通对话接口

下面这段代码是最小可用版本，用 requests 完成一次对话请求，适合快速验证。确认通了再封装成函数。

import requests API_KEY = "sk-your-key" # 建议用环境变量读取，不要写死在代码里 BASE_URL = "https://api.deepseek.com" # 兼容OpenAI的接口地址 payload = { "model": "deepseek-chat", # 通用对话模型；按官方文档确认当前可用模型名 "messages": [ {"role": "user", "content": "用两句话解释什么是上下文窗口，不要使用比喻"} ], "temperature": 0.3, # 低温度，让输出更稳定 "max_tokens": 512, # 限制单次输出长度，避免超出预算 "stream": False # 关闭流式，方便先看整体结果 } resp = requests.post( f"{BASE_URL}/chat/completions", headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=60 ) resp.raise_for_status() print(resp.json()["choices"][0]["message"]["content"])

这段代码有几个关键点。messages是一个消息列表，即使只用一轮对话，也要包在 list 里，因为后续多轮对话就是不断往这个列表追加消息。temperature控制随机性，值越低输出越接近确定性，业务场景建议先设置在 0.2 到 0.4 之间。max_tokens是输出上限，不是总 token 数，别把输入长度也算在里面。timeout建议至少 60 秒，深度推理场景响应时间更长，设太短容易被误判为超时。

4.3 参数怎么调：让输出从“随机”变“稳定”

同样一段提示词，参数不同结果可能完全不同。有人嫌模型“忽冷忽热”，其实是temperature和top_p配合出了问题。这两个参数的官方含义不同，但在实际效果上都会影响随机性。

我的经验是：不要同时去调这两个值。temperature和top_p都调太高的后果是双重随机，输出质量很难复现。常见做法是把top_p固定在 0.8 附近，只拿temperature做微调；或者反过来也行，关键是让一个参数充当固定底座，另一个做调节旋钮。

import time def call_with_retry(payload, max_retries=3): for attempt in range(max_retries): try: resp = requests.post( f"{BASE_URL}/chat/completions", headers={"Authorization": f"Bearer {API_KEY}"}, json=payload, timeout=60 ) resp.raise_for_status() return resp.json() except requests.exceptions.HTTPError as e: if resp.status_code == 429: # 限流 time.sleep(2 ** attempt) # 退避等待 else: raise return None

这段代码演示了最基础的限流处理。遇到 429 限流时，按 2 的指数次幂退避，第一轮等 2 秒，第二轮等 4 秒，第三轮等 8 秒。如果三次都失败，返回None让上层逻辑决定是否跳过。重复请求前还可以对相同文本做本地缓存，避免同一段内容反复调用消耗 token。记住一句话：把默认值作为基准，少做花式调整，大多数业务的输出稳定性问题都出在提示词而不是参数上。

5. DeepSeek避坑与排查：五个高频翻车现场和处理办法

用的时间久了你会发现，DeepSeek 的问题绝大多数都不是模型不行，而是用法没对上。这一章我整理了五个高频翻车场景，每条都是“现象、原因、解决”三段式，可以直接当排查手册用。

5.1 长文生成到一半突然断掉

现象：让它写一份 3000 字的方案，写到中间突然停住，像没写完一样，也没有报错。

原因：max_tokens设小了。模型生成到长度上限后会被强制截断，但它不会主动提示你这是因为截断，而是看起来像正常到了结尾。另外，深度推理模式会优先消耗输出 token 在推理阶段，留给最终答案的长度会更少。

解决：先把max_tokens调大，比如 2048 或更高；如果你确认需要更长内容，把任务拆成多段，分段生成再拼接。调试时查看返回结果里的finish_reason字段，如果值是length，就说明确实是被截断了。

5.2 问了实时新闻，答案却是旧闻

现象：问“今天有什么重要政策发布”，DeepSeek 给出的内容看起来像上周甚至上个月的。

原因：网页端默认没有打开联网搜索。当前对话模型的知识有截止时间，不联网的情况下，它只能靠训练时的记忆回答，自然跟不上新消息。

解决：提问前手动打开联网搜索开关，再发起消息。打开后如果答案仍像旧闻，继续追问“你引用的信息来源是什么时间”，让它列出链接和发布时间，人工确认一下。记住，联网搜索不是全自动功能，它需要你针对每次会话手动决定开或关。

5.3 提示词写了“只输出JSON”，结果前面还带解释

现象：你要求“只返回 JSON 对象”，模型却在 JSON 前面加一句“好的，这是你的结果”，甚至用 Markdown 代码块把 JSON 包起来。

原因：提示词里只提了要求，没有给输出示例。模型在训练时见过大量对话式 JSON 返回，它默认按最常见的对话习惯处理，而你的指令没有帮它锁定格式。

解决：在提示词里补一个最小的 JSON 示例，让它照着格式输出。示例位置放在指令末尾，紧挨着任务内容。如果你走 API，还可以把response_format设为 JSON 对象模式，再配合示例，基本不会再出现多余解释。

请将下面这段投诉内容输出为JSON对象，不要带Markdown标记。 {"summary": "一句话概括投诉内容", "suggestion": "建议解决方案", "priority": "高"}

5.4 API并发一高就报429限流错误

现象：脚本里用 for 循环批量调用，并发提到二三十以后，大量请求返回 429 或者超时。

原因：API 账号有并发和速率限制，单账号短时间发出太多请求会被限流。很多新手只在请求层做了简单 retry，没有退避机制，导致限流一过又有大量请求挤进来，形成恶性循环。

解决：一是把并发压下来，建议先跑 batch 4 到 8 并发，观察稳定后再逐步提高；二是加上指数退避重试，代码见上一章；三是记录每次请求的 token 用量和耗时，提前估算成本，别等账单出来再后悔。

5.5 新任务被旧对话污染，模型老是提之前的需求

现象：我在同一会话里先问了 A 项目的接口设计，接着切换话题问 B 项目的文案，结果模型给出的回答里还带着 A 项目的技术名词。

原因：DeepSeek 的多轮对话会把历史消息全部留在上下文里，旧任务的背景会和当前任务混在一起。换成网页端，还会在界面上保留上一轮的内容提示，进一步干扰模型判断。

解决：新任务新开会话，不要在同一会话里连续处理不同项目。走 API 时更简单，只把当前任务需要的消息放进messages列表，不相关的历史不要传给模型。这条看起来不起眼，却是实际使用中省 token、避免错误最有效的习惯。

提示：如果你发现自己每次都要在新会话里重复解释背景，说明应该把常用背景写成一个标准提示词模板，而不是一味靠模型记住。

6. 进阶玩法：用DeepSeek搭一套能验收的自动化工作流

把 DeepSeek 从聊天窗口搬进业务流程，才算真正进入“精通”的地界。这一章的思路是：让它输出机器可读的数据，用缓存和批量策略控制成本，最后用一个固定验收集合验证每一次改动。

6.1 让模型输出固定JSON，接进后端逻辑

做自动化最怕的是模型输出带格式噪声。前面提到过在提示词里加 JSON 示例，这里更进一步，API 层也有一个对应参数，叫response_format。把值设为json_object，模型会尽量输出一个合法的 JSON 对象，而不是 Markdown 或附带解释。

payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一个结构化信息提取器。"}, {"role": "user", "content": "从下面这段文本中提取公司名称和融资轮次：" + text} ], "response_format": {"type": "json_object"}, "temperature": 0.2 }

注意，response_format只是约束格式，不负责保证字段完整。我一般会在后端代码里做一步校验：解析 JSON 后，检查必填字段是否存在，不存在的直接标记为失败并重试。模型偶尔还是会漏字段，靠参数和提示词可以降低概率，但不可能完全消灭。

6.2 批量任务怎么跑才省钱

批量调用 DeepSeek 最怕的不是调用失败，而是重复调用和超长输入。三个习惯能给成本做减法。

第一，对任务文本做去重，记录 hash 到结果的映射，完全相同的输入直接走缓存。第二，输入长度要分桶，超长文本先切块再处理，不要整篇硬塞进一次请求。第三，控制并发水位，不要上来就是几十个线程，稳定的速度比一次性的快更重要，因为限流之后的重试成本很高。

我见过一个典型场景：同一份用户反馈列表，脚本跑了三遍，每遍都重新调用接口，白白烧了三倍 token。加上缓存之后，同样的任务基本只在第一轮产生费用，后续直接读本地结果。

6.3 用“十五问验收集”保住效果

提示词改了一版又一版，怎么判断是变好了还是变差了？我的做法是建一个“十五问验收集”：选 15 个日常最常用的任务，每一个写清楚输入和期望输出特点，每次调整提示词或参数后跑一遍，记录通过率。

这套做法一开始麻烦，但跑过几轮之后价值非常大。它会逼你把“我觉得效果好”变成“15 个用例里 13 个通过，2 个失败，失败原因是格式不稳定”。我自己的习惯是给常用提示词建一个本地 Markdown 版本库，每次改动都记录到对应用例的结果表里。坚持下来我发现，很多当时觉得“更好了”的改动，在验收表里根本经不住复测。

模型内部仍然是黑匣子，但输入、输出、参数和成本都是可以复盘记录的。真正从入门走到精通，不是记住了多少技巧，而是建立了“看到结果就知道对不对”的判断力。希望帮到你。

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