简介：这份PDF资料是清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的《DeepSeek从入门到精通》手册，面向希望系统掌握DeepSeek大模型应用的开发者、内容创作者与AI学习者，帮助读者从基础认知走向进阶实战。资源包共1个PDF文件，大小约4.14MB，内容围绕DeepSeek是什么、能做什么、如何使用以及如何从入门到精通展开，涵盖文本生成、自然语言理解与分析、编程与代码相关、常规绘图等核心应用场景。手册重点剖析了推理模型与非推理模型在优势领域、性能本质、决策能力与伦理问题上的差异，并给出提示语策略差异、任务需求与提示语策略匹配等实用方法，如数学证明选推理模型、创意写作选通用模型，以及指令驱动、需求导向、混合模式等提示语设计原则。目前已有334人学习，适合希望根据任务类型合理选择模型、提升AI使用效率的读者参考。
1. 从一份被疯传的文档说起：普通人到底能用它做什么
最近不少人在转一份叫《DeepSeek从入门到精通》的文档，署名是某高校新闻与传播学院下设的新媒体研究机构。我花了一个周末把它从头到尾翻了一遍，又对着自己手头的几个实际任务做了验证。先说结论：这份文档最大的价值不是教你“怎么注册账号”或者“怎么问问题”，而是它把大模型当成一个可拆解、可编排、可复用的生产力组件来对待，而不是一个聊天玩具。
如果你之前用过一些对话式 AI，但总觉得“好像什么都能干，又好像什么都干不好”，那这份文档提供的思路值得你花时间。它面向的不是算法工程师，而是内容创作者、运营、产品经理、行政人员这类需要大量处理文字、表格、信息的角色。核心问题只有一个：怎么把 DeepSeek 的能力稳定地嵌入到你每天的工作流里，而不是每次都要重新“碰运气”式地提问。接下来我会按“先理解它是什么、再动手搭一个最小可用流程、然后避开几个高频翻车点”的顺序，把这份文档里真正能落地的部分拆开讲。
2. 先搞懂 DeepSeek 的三种调用姿势：网页、API 与本地部署
2.1 网页端适合做什么，不适合做什么
网页端是最低门槛的入口，打开浏览器就能用。它适合三类任务：一次性文案生成、长文档的快速摘要、以及需要多轮对话逐步澄清的复杂需求。比如你拿到一份 30 页的行业报告，想先提取核心观点，直接粘贴进去让它分段总结，效率比人工翻要高得多。
但网页端有两个硬伤。第一，上下文长度受限于页面实际能粘贴进去的内容量，超长文档会被截断，而且你很难精确控制它到底读了哪几段。第二，无法自动化。你没法让网页端每天定时读取某个文件夹里的新文件并输出摘要。所以网页端适合“人肉触发”的探索性任务，不适合固定流程的批量处理。
2.2 API 调用的最小可用示例
当你需要把 DeepSeek 接入自己的脚本或工具时，API 是唯一选择。下面是一个 Python 的最小调用示例，假设你已经拿到了 API Key 并设置好了环境变量。
import os from openai import OpenAI # 从环境变量读取密钥，避免硬编码在代码里 client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" # 注意 base_url 要指向 DeepSeek 的端点 ) # 构造一个明确角色和任务的请求 response = client.chat.completions.create( model="deepseek-chat", # 通用对话模型，适合大多数文本任务 messages=[ {"role": "system", "content": "你是一个严谨的技术文档摘要助手，只输出要点，不添加评论。"}, {"role": "user", "content": "请把下面这段文字压缩成三条要点：\n\n" + open("report.txt").read()[:3000]} ], temperature=0.3, # 低温度让输出更稳定，适合摘要类任务 max_tokens=500 ) print(response.choices[0].message.content)这段代码的逻辑很直白：用 system 消息锁定角色和行为边界，用 user 消息传入实际内容。temperature设成 0.3 是为了减少随机性，摘要任务不需要创意。max_tokens限制输出长度，防止它自由发挥写一大段。注意base_url必须指向 DeepSeek 的 API 地址，否则会默认走到其他服务商那里去。
参数上最需要留意的是model字段。DeepSeek 目前提供不同定位的模型，通用对话选deepseek-chat，需要更强推理能力的场景可以换deepseek-reasoner。后者在数学和逻辑题上表现更好，但响应速度会慢一些，成本也更高。我一般会在处理合同条款比对、数据校验规则生成这类任务时切到 reasoner，日常文案和摘要用 chat 就够了。
2.3 本地部署的适用边界
本地部署听起来很美好，但实际门槛不低。你需要有足够的显存来加载模型权重，7B 参数量的模型在 FP16 精度下大约需要 14GB 显存，量化到 4bit 可以压到 4GB 左右，但输出质量会下降。如果你只是处理一些不涉及敏感信息的公开文本，用 API 更省心。本地部署的真正价值在于两点：一是数据完全不出内网，适合处理内部文档；二是可以离线运行，不受网络波动影响。
我见过不少团队一上来就折腾本地部署，结果卡在环境配置和显存不足上，反而耽误了正事。比较务实的路径是：先用 API 把流程跑通，验证了效果和收益之后，再评估是否值得投入硬件做本地化。如果确实需要本地跑，优先考虑用 Ollama 这类工具拉取量化版本，一条命令就能启动，比手动配置 PyTorch 环境省事得多。
3. 把 DeepSeek 变成工作流组件：三个可复现的编排模式
3.1 模式一：批量文件摘要与结构化输出
假设你每天要处理几十份会议纪要，需要从中提取“决策事项”和“待办任务”。手动复制粘贴到网页端效率太低，用脚本批量处理才是正解。下面这个脚本会遍历指定文件夹下的所有 txt 文件，逐个调用 API，并把结果按固定格式写入一个汇总文件。
import os import json from openai import OpenAI client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) def summarize_file(filepath): with open(filepath, "r", encoding="utf-8") as f: content = f.read()[:4000] # 截断防止超长，实际可根据模型上下文调整 prompt = f"""请从以下会议纪要中提取两类信息： 1. 决策事项：已经拍板确定的事情 2. 待办任务：需要后续跟进的事项，注明负责人（如果有） 以 JSON 格式输出，键为 "decisions" 和 "tasks"，值为字符串数组。 如果某一类为空，返回空数组。 纪要内容： {content} """ response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], temperature=0.1, response_format={"type": "json_object"} # 强制 JSON 输出，方便后续解析 ) return json.loads(response.choices[0].message.content) # 遍历文件夹并汇总 results = {} for filename in os.listdir("./meetings"): if filename.endswith(".txt"): results[filename] = summarize_file(os.path.join("./meetings", filename)) with open("summary.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2)关键点在于response_format={"type": "json_object"}这个参数。它会让模型尽量输出合法的 JSON，减少你手动解析的麻烦。但注意，模型仍然可能偶尔输出不符合你预期结构的 JSON，所以生产环境里最好加一层校验和重试逻辑。另外temperature设到 0.1 是为了让提取结果尽可能一致，同一份纪要跑两次不应该得到差异很大的输出。
3.2 模式二：多轮对话中的上下文管理
很多人抱怨模型“聊着聊着就忘了前面说过什么”，其实是因为没有正确管理对话历史。API 本身是无状态的，每次请求都需要你把之前的对话内容一并传进去。下面是一个带上下文裁剪的对话循环示例。
messages = [ {"role": "system", "content": "你是一个产品需求分析助手，回答要简洁，每次不超过三句话。"} ] def chat(user_input): messages.append({"role": "user", "content": user_input}) # 保留 system 消息和最近 10 轮对话，防止 token 超限 if len(messages) > 21: messages[:] = [messages[0]] + messages[-20:] response = client.chat.completions.create( model="deepseek-chat", messages=messages, temperature=0.7 ) reply = response.choices[0].message.content messages.append({"role": "assistant", "content": reply}) return reply这里的裁剪策略是保留 system 消息加上最近 20 条消息（10 轮问答）。为什么要保留 system 消息？因为它定义了助手的角色和行为边界，丢掉之后模型可能会“跑偏”。裁剪阈值需要根据你实际使用的模型上下文长度来调整，一般留出 20% 的余量给输出。
3.3 模式三：用提示词模板固化输出格式
如果你需要模型每次都以固定格式输出，比如生成周报、产品描述、邮件回复，最好的办法是写一个提示词模板，把变量部分留出来。下面是一个生成周报的模板示例。
WEEKLY_TEMPLATE = """你是一个周报生成助手。请根据以下信息，生成一份结构清晰的周报。 本周完成事项： {completed} 下周计划： {planned} 遇到的问题： {issues} 要求： - 用 Markdown 格式输出 - 分为“本周完成”“下周计划”“风险与求助”三个部分 - 语言简洁，每条不超过两句话 - 不要添加额外评论 """ def generate_weekly(completed, planned, issues): prompt = WEEKLY_TEMPLATE.format( completed=completed, planned=planned, issues=issues ) response = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], temperature=0.5 ) return response.choices[0].message.content模板的好处是输出格式稳定，你不需要每次都在提示词里重复描述要求。把模板单独存成一个文件或常量，后续修改也方便。注意模板里的占位符要和format的参数名一一对应，否则会报 KeyError。
4. 避坑指南：五个让我熬夜排查的常见问题
4.1 输出格式忽好忽坏，JSON 解析频繁失败
现象：明明在提示词里写了“以 JSON 格式输出”，但模型有时候返回带 Markdown 代码块的 JSON，有时候在 JSON 前后加解释文字，导致json.loads直接报错。
原因：模型对“JSON 格式”的理解是宽松的，它认为把 JSON 放在代码块里也算“JSON 格式”。另外温度设得太高也会增加格式漂移的概率。
解决：第一，在提示词里明确写“直接输出 JSON，不要用代码块包裹，不要添加任何解释文字”。第二，使用 API 提供的response_format={"type": "json_object"}参数。第三，在代码里加一层容错：先尝试直接解析，失败则用正则提取第一个{到最后一个}之间的内容再解析。第四，把 temperature 降到 0.1 以下。
4.2 长文档处理时后半段信息丢失
现象：给模型一篇 8000 字的文章让它总结，结果它只总结了前 3000 字的内容，后面的关键信息完全没提到。
原因：模型的上下文窗口有上限，超出部分会被截断。而且很多模型对开头和结尾的内容注意力更强，中间部分容易被忽略。
解决：如果文档确实很长，不要一次性塞进去。分成多个片段分别摘要，再把摘要结果合并起来做二次总结。或者用“滑动窗口”的方式，每次传入一部分内容并带上上一轮的摘要作为上下文。另一种做法是在提示词里明确要求“请确保覆盖文档的所有主要部分，不要只关注开头”。
4.3 API 调用频繁超时或返回 429 错误
现象：批量处理任务时，跑到一半开始大量报错，提示请求过于频繁或超时。
原因：触发了服务端的速率限制。免费或低档位的 API 套餐通常有每分钟请求数上限。
解决：在代码里加退避重试逻辑。最简单的做法是捕获异常后time.sleep几秒再重试，重试次数设个上限比如 3 次。下面是一个简单的重试装饰器。
import time from functools import wraps def retry_on_failure(max_retries=3, delay=5): def decorator(func): @wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt == max_retries - 1: raise print(f"请求失败，{delay}秒后重试：{e}") time.sleep(delay) return wrapper return decorator把@retry_on_failure()加在你的 API 调用函数上就行。如果批量任务量很大，最好在每次请求之间主动加一个短延迟，比如 0.5 秒，比被动等报错再重试更平滑。
4.4 模型“一本正经地胡说八道”
现象：问它一个具体的数据或事实，它给出了一个看起来很像真的但实际错误的答案。
原因：大模型本质上是概率生成模型，它倾向于生成“看起来合理”的文本，而不是“真实”的文本。当它不知道答案时，可能会编造一个。
解决：对于事实性问题，在提示词里加一句“如果你不确定，请直接说不知道，不要猜测”。另外，关键数据一定要人工核对，不要直接采信模型输出。如果任务涉及大量事实查询，考虑结合检索增强生成的方式，先检索到相关文档再让模型基于文档回答。
4.5 中文标点和英文标点混用导致下游处理出错
现象：模型输出的文本里混用了中文逗号和英文逗号，导致后续用逗号分割字段时出错。
原因：模型在生成中文内容时，标点选择并不总是稳定的，尤其是在中英混合的上下文里。
解决：在提示词里明确要求“全部使用中文标点”或“全部使用英文标点”，根据你的下游处理逻辑来定。如果输出已经产生了，可以在代码里做一次标点归一化替换，把英文逗号替换成中文逗号（或反过来），但要注意不要误伤数字中的小数点或代码片段。
5. 进阶技巧：用少样本示例把输出质量拉高一个档次
前面讲的都是基础操作，这一章说一个我反复验证过、效果最明显的技巧：在提示词里给例子。大模型对示例的敏感度远超你的想象。同样一个任务，只写指令和写指令加两三个示例，输出质量的差距可能是“勉强能用”和“直接能用”的区别。
具体做法是在提示词里构造一个“输入-输出”对的列表，让模型模仿示例的格式和风格。下面是一个提取产品评论中“情感倾向”和“关键问题”的示例。
FEW_SHOT_PROMPT = """请从用户评论中提取情感倾向（正面/负面/中性）和关键问题（如果没有问题则填“无”）。 示例1： 评论：这个耳机音质不错，但是戴久了耳朵疼。 输出：{"sentiment": "负面", "issue": "佩戴舒适度差"} 示例2： 评论：物流很快，包装完好，产品符合描述。 输出：{"sentiment": "正面", "issue": "无"} 示例3： 评论：还行吧，跟描述差不多，没什么惊喜。 输出：{"sentiment": "中性", "issue": "无"} 现在请处理这条评论： 评论：{review} 输出："""注意示例的选择要覆盖你期望模型处理的各种情况。上面三个示例分别覆盖了“有褒有贬”“纯正面”“中性”三种情况。如果你只给正面示例，模型可能会把所有评论都判成正面。示例的数量一般 2 到 5 个就够了，太多会占用宝贵的上下文长度。
另一个技巧是在示例里故意展示你期望的边界行为。比如你希望模型在遇到不确定的情况时输出“无法判断”，那就在示例里加一条这样的案例。模型会倾向于模仿示例中的行为模式，这比在指令里写十遍“不确定时要说无法判断”都管用。
还有一个容易被忽略的点：示例的格式要和你期望的输出格式完全一致。如果你希望输出是 JSON，示例的输出就必须是合法的 JSON，不要在里面加注释或多余的空格。模型对格式的模仿是像素级的，你给什么格式，它就还什么格式。
最后说一个我自己的习惯：每次新建一个提示词模板后，我会先用 10 条左右的测试数据跑一遍，人工检查输出质量。如果发现某类输入的处理效果不好，就针对性地补一个示例进去，再跑一遍。通常迭代两三轮，输出质量就能稳定在一个可接受的水平。这个过程花的时间，远比每次手动修改模型输出要少。希望帮到你。
本文还有配套的精品资源，点击获取
