简介这份PDF资料是清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的《DeepSeek从入门到精通》手册面向希望系统掌握DeepSeek的开发者、内容创作者与AI学习者帮助读者从基础认知走向进阶应用。资源包内仅含1个PDF文件大小约4.14MB内容以图文并茂的章节结构呈现便于通读与检索。手册系统梳理了DeepSeek的核心能力包括智能对话、文本生成、语义理解、计算推理、代码生成补全等应用场景并深入讲解推理模型与非推理模型的差异、快思慢想效能对比、提示语策略差异及任务与模型匹配原则。读者可借此理解推理模型与通用模型在数学证明、创意写作、代码生成等任务中的选择逻辑掌握从下达指令到表达需求的提示语设计方法并了解伦理问题与使用误区。目前已有334人学习适合希望提升AI使用效率、构建模型选型与提示语设计能力的读者参考。1. DeepSeek 从入门到精通一个新媒体团队踩过的真实路径第一次把 DeepSeek 接进内容生产流程时我以为它就是个更便宜的通用大模型结果第一周就被打脸——同一个提示词在网页端跑得好好的换到 API 调用后输出风格完全变了。后来才搞明白网页端默认套了一层系统提示词和采样参数而 API 是裸的。这个坑让我意识到DeepSeek 从入门到精通核心不是背多少提示词模板而是搞清楚它在不同接入方式下的行为差异、参数边界和适用场景。这篇笔记面向三类人一是刚接触 DeepSeek、想把它用起来的运营和内容同学二是准备把 DeepSeek 接入自己工具链的开发者三是已经在用但总觉得输出不稳定的从业者。我会按先搞懂它是什么 → 再跑通最小可用 → 然后调参和避坑 → 最后落到进阶技巧的顺序讲每一步都给可复现的命令和参数不堆概念。2. 先搞清楚 DeepSeek 的三种接入方式与选型逻辑2.1 网页端、API、本地部署到底怎么选很多人一上来就问DeepSeek 怎么本地部署但其实大部分内容团队根本不需要本地部署。选型逻辑很简单看三个维度数据敏感度、调用频率、预算。网页端适合个人快速验证想法零成本但没法批量、没法自动化、输出不可控。API 适合有开发能力、需要批量处理或接入自有系统的团队按 token 计费可控性最强。本地部署适合数据绝对不能出内网、且有 GPU 资源的场景但门槛高、维护成本大。接入方式适合场景成本可控性门槛网页端个人验证、临时问答零低无API批量处理、系统集成按量计费高需开发本地部署数据敏感、离线环境硬件运维最高高我一般建议先用网页端跑通提示词逻辑确认效果后立刻转 API 做小批量测试别在网页端反复调参——因为网页端的参数你根本看不到。2.2 API 调用的最小可用代码下面这段 Python 代码是我用得最多的最小调用模板跑通它只需要一个 API Key# DeepSeek API 最小调用模板 # 依赖pip install openai from openai import OpenAI client OpenAI( api_key你的API_KEY, # 从控制台获取不要硬编码进代码仓库 base_urlhttps://api.deepseek.com # DeepSeek 兼容 OpenAI SDK 的接入地址 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型另有推理模型可选 messages[ {role: system, content: 你是一个严谨的中文技术编辑输出不带废话。}, {role: user, content: 把这段话压缩到50字以内...} ], temperature0.3, # 低温度适合事实性、格式化任务 max_tokens512, # 控制输出长度上限防止跑飞 streamFalse # 先关流式方便调试完整输出 ) print(response.choices[0].message.content)逻辑说明base_url是关键DeepSeek 兼容 OpenAI 的 SDK 协议所以不用装额外的包。system消息决定了模型的人格这一步比 user 消息更重要。temperature设 0.3 是因为压缩改写类任务需要稳定如果你做创意文案可以调到 0.8 以上。参数说明max_tokens不是越大越好设太大会让模型凑字数设太小会截断。一般中文任务按目标字数 × 1.5估算。stream在调试阶段建议关掉方便看完整输出上线后再开流式提升用户体验。2.3 模型选择通用模型和推理模型别用混DeepSeek 目前主要提供两类模型通用对话模型和推理模型。通用模型响应快、成本低适合改写、摘要、分类、翻译。推理模型在数学、逻辑、代码调试上更强但响应慢、token 消耗高。常见误用是拿推理模型做简单改写——纯属浪费。我的判断标准如果任务需要多步推理或自我纠错用推理模型如果任务是输入到输出的直接映射用通用模型。这个判断能帮你省下大量成本。3. 把 DeepSeek 接进内容生产流程的完整步骤3.1 从单次调用到批量处理的封装单次调用跑通后下一步是封装成可复用的函数。下面这个封装加了重试和超时是我踩过网络抖动导致整批任务失败之后加的import time from openai import OpenAI client OpenAI(api_key你的API_KEY, base_urlhttps://api.deepseek.com) def ask_deepseek(prompt, system你是一个中文技术编辑, retries3, temperature0.3): 带重试的 DeepSeek 调用封装 for i in range(retries): try: resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: system}, {role: user, content: prompt} ], temperaturetemperature, max_tokens1024, timeout30 # 单次请求超时防止卡死 ) return resp.choices[0].message.content except Exception as e: if i retries - 1: raise # 最后一次还失败就抛出不要静默吞掉 time.sleep(2 ** i) # 指数退避2s、4s、8s return None逻辑说明retries配合指数退避是处理限流和网络抖动的标准做法。timeout30必须设否则遇到慢响应会一直挂着。异常不要静默吞掉否则批量任务里你根本不知道哪条失败了。参数说明temperature在批量任务里建议统一设低值保证输出格式一致。如果做创意类批量生成可以按任务类型分组不同组用不同温度。3.2 批量任务的并发控制与限流批量处理时最容易翻车的是并发太高被限流。我一般用线程池控制并发数同时加一个简单的令牌桶from concurrent.futures import ThreadPoolExecutor, as_completed def batch_process(prompts, max_workers5): 批量处理控制并发数避免触发限流 results {} with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(ask_deepseek, p): idx for idx, p in enumerate(prompts) } for future in as_completed(future_map): idx future_map[future] try: results[idx] future.result() except Exception as e: results[idx] fERROR: {e} return [results[i] for i in range(len(prompts))]逻辑说明max_workers5是保守值具体能开多少取决于你的账户等级和当时的服务状态。as_completed保证按完成顺序收集结果但最后按原始索引排序返回避免顺序错乱。参数说明并发数不要一上来就设 20、50先设 3 跑一批观察是否有 429 错误再逐步往上加。遇到 429 就降并发或加 sleep。3.3 提示词模板的版本管理内容团队最容易乱的是提示词散落在各处。我的做法是把提示词抽成独立文件用 YAML 管理代码里只引用 key# prompts.yaml summarize: system: 你是一个中文技术编辑输出简洁准确。 user: 把以下内容压缩到{length}字以内保留关键数据\n{content} temperature: 0.3 rewrite: system: 你是一个新媒体文案语言口语化但不失专业。 user: 用更口语的方式重写这段话保持原意\n{content} temperature: 0.7逻辑说明把 system、user 模板和 temperature 绑在一起管理改提示词不用动代码。{length}、{content}是占位符调用时用.format()填充。参数说明不同任务的 temperature 差异很大摘要类 0.3、改写类 0.7、创意类 0.9 以上。把温度跟提示词绑定避免每次调用都纠结设多少。4. 参数调优那些文档不会告诉你的边界4.1 temperature 和 top_p 到底调哪个很多人同时调 temperature 和 top_p这是错的。这两个参数都在控制随机性同时调会互相干扰。我的习惯是只调 temperaturetop_p 保持默认。因为 temperature 的直觉更清晰——0 最确定1 最随机。具体边界事实性任务 00.3格式化输出 0.30.5创意文案 0.71.0。超过 1.0 输出会开始出现语病和逻辑断裂不建议用。4.2 max_tokens 设多少才不浪费max_tokens设太大不会多花钱按实际输出计费但会让模型倾向于凑满。设太小会截断。我的经验公式中文任务按目标字数 × 1.5设英文按目标词数 × 1.3设。还有一个隐藏坑如果你用推理模型max_tokens要额外留出推理过程的消耗。推理模型的思考过程也占 token设太小会导致答案还没输出就被截断。4.3 系统提示词的三个反直觉结论第一system 消息比 user 消息更重要。同样一句话放 system 里和放 user 里效果差异明显。第二system 里写不要做什么比要做什么更有效比如不要用感叹号比保持专业语气更管用。第三system 太长会稀释效果控制在 200 字以内最佳。5. 避坑指南五条血泪经验5.1 网页端和 API 输出不一致现象同一提示词网页端输出很规范API 输出风格飘忽。原因网页端默认套了系统提示词和固定参数API 是裸调用。解决把网页端的效果当作参考上限API 里自己补 system 消息和参数不要指望两者一致。5.2 批量任务中途大量失败现象跑 100 条前 20 条正常后面全是超时或 429。原因并发太高触发限流或没设超时导致连接堆积。解决降并发到 35加指数退避重试设 timeout30失败条目单独记录后重跑。5.3 输出格式不稳定JSON 解析老失败现象让模型输出 JSON有时带 markdown 代码块标记有时字段名变了。原因模型对格式的遵循不是 100% 可靠。解决在 system 里明确只输出 JSON不要任何其他文字temperature 设 0并在代码里做容错解析——先尝试直接解析失败则用正则提取 JSON 部分。5.4 长文本处理被截断现象输入一篇长文让模型总结输出不完整或漏掉后半部分。原因输入超过了上下文窗口或 max_tokens 设太小。解决先估算输入 token 数超长文本先分段再汇总max_tokens 按目标输出长度的 1.5 倍设。5.5 成本失控现象月底一看账单远超预期。原因没控制 max_tokens或用了推理模型做简单任务或重复调用没做缓存。解决给每个任务设 max_tokens 上限简单任务用通用模型相同输入做结果缓存。6. 进阶技巧把 DeepSeek 用出专家感的两个具体方法6.1 用角色约束示例三段式提示词普通提示词是帮我写一段产品介绍专家级提示词是角色你是一个有10年经验的产品文案擅长把技术卖点翻译成用户利益。 约束不超过150字不用形容词堆砌每句话必须有具体信息。 示例 输入一款支持离线使用的笔记软件 输出没网也能记。地铁里、飞机上、电梯间打开就写写完自动同步。这个结构的关键是示例——给一个输入输出对模型会模仿这个风格。比单纯描述要口语化有效得多。6.2 用多轮对话做自我审校单次调用很难保证质量我的做法是让模型自己审自己def generate_with_review(topic): 生成 自我审校两轮 draft ask_deepseek(f写一段关于{topic}的100字介绍, temperature0.7) review_prompt f以下是一段介绍请检查1.是否有事实错误 2.是否有冗余表达 3.是否超过100字。 直接输出修改后的版本不要解释。 原文{draft} final ask_deepseek(review_prompt, temperature0.2) return final逻辑说明第一轮用较高温度生成初稿第二轮用低温度做审校。两轮的温度差异是关键——生成要发散审校要收敛。参数说明审校轮的 system 建议设为你是一个严格的文字编辑temperature 设 0.2 以下。这个方法对摘要、文案类任务效果明显对纯事实问答没必要。我自己的习惯是任何要批量产出的内容都先跑 10 条样本人工看一遍确认提示词和参数没问题再放量。这个10 条样本的习惯帮我省了无数次返工。希望帮到你。本文还有配套的精品资源点击获取