简介：《DeepSeek从入门到精通》是一份面向AI初学者、开发者与内容创作者的PDF学习资料，由清华大学新闻与传播学院新媒体研究中心团队编写，系统讲解DeepSeek的能力边界与实战用法。内容覆盖智能对话、文本生成、语义理解、计算推理与代码补全等应用场景，并深入对比推理大模型与非推理大模型在逻辑推理、数学推导、创意写作等任务上的差异，同时给出提示语策略、任务需求匹配与模型选择原则，帮助读者从“下达指令”进阶到“表达需求”。资源包共1个PDF文件，大小约5.36MB，结构清晰、图文并茂，便于按章节检索学习。目前已有1011人学习下载，适合希望系统掌握DeepSeek使用方法、提升AI协作效率的读者参考。
1. 从“会聊天”到“能干活”：DeepSeek 从入门到精通到底在学什么
很多人第一次用 DeepSeek，都是把它当成一个更聪明的搜索框：问一句，答一句，答完就关。但真正把它用进工作流的人会发现，差距根本不在“问得好不好”，而在“有没有把它当成一个可配置、可复用、可验证的推理组件”。我见过太多人卡在同一个地方——模型明明能写代码、能读文档、能做结构化抽取，可自己用起来就是不稳定，换个问法结果就飘，长文档一塞就丢细节。问题不在模型，在于没有把提示词、上下文、参数和验证环节当成一套工程来做。
这篇笔记面向三类人：刚接触 DeepSeek、想把它接进日常开发或文档处理流程的新手；已经会用但结果忽好忽坏、想搞清楚边界和参数的熟手；以及想评估“这个方向值不值得投入时间”的技术负责人。我会按“先立住概念和选型理由，再落到可复现的命令、配置和排错”的顺序讲，中间会给出能直接抄的代码块和参数表，也会把我在实际项目里踩过的坑按“现象→原因→解决”写清楚。读完你应该能独立搭起一条从调用、提示词组织、长上下文处理到结果校验的最小链路，并且知道哪些参数该动、哪些别乱动。
2. 先搞清楚 DeepSeek 的三种接入姿势：网页、API 与本地化部署
2.1 网页端适合验证想法，不适合做流水线
网页端最大的价值是“零成本试错”。你可以在几分钟内验证一个提示词模板是否可行，比如让它把一段非结构化日志转成 JSON，或者让它解释一段报错。但它有三个硬伤：无法批量、无法固定参数、无法嵌入你自己的校验逻辑。我一般把网页端当成“草稿纸”，任何要重复三次以上的任务，都会立刻转到 API。
这里有个反直觉的结论：网页端回答质量高，不代表 API 调用也能复现。因为网页端背后可能叠加了系统提示、上下文压缩和默认参数，你看到的输出是“调好的结果”，不是“裸模型的结果”。所以做技术选型时，永远以 API 或本地部署的实际输出为准。
2.2 API 调用：最小可运行示例与关键参数
下面这段 Python 代码是我常用的最小调用模板，基于 OpenAI 兼容接口风格，DeepSeek 的 API 也遵循类似协议。注意我故意把温度、最大长度和系统提示都显式写出来，方便后面调参。
# deepseek_min_call.py # 最小可运行调用模板，重点看三个参数：temperature、max_tokens、system import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), # 从环境变量读取，不要硬编码 base_url="https://api.deepseek.com" # 常见做法是走兼容接口地址 ) resp = client.chat.completions.create( model="deepseek-chat", # 对话场景常用模型标识 messages=[ {"role": "system", "content": "你是一个严谨的日志分析助手，只输出 JSON，不要解释。"}, {"role": "user", "content": "把下面日志转成 JSON：ERROR 2024-06-01 db timeout after 30s"} ], temperature=0.2, # 抽取类任务压低随机性 max_tokens=512, # 防止无限输出，也控制成本 top_p=0.9 # 与 temperature 二选一为主，别同时大改 ) print(resp.choices[0].message.content)逻辑说明：system负责定角色和输出格式，user放具体任务，temperature控制随机性。参数说明：抽取、分类、代码生成建议temperature在 0.1~0.3；创意写作可以到 0.7~1.0；max_tokens要略大于你预期输出的长度，太小会被截断，太大会增加无效成本。top_p一般保持 0.9 左右，和temperature不要同时大幅调整，否则输出风格会变得难以复现。
2.3 本地化部署：什么时候值得自己扛机器
本地化部署的核心动机通常有三个：数据不出内网、调用量极大需要摊薄成本、需要固定某个版本做长期验证。常见做法是用推理框架加载开源权重，再套一层兼容接口。但我要提醒一句：本地部署的“精通”门槛不在模型本身，而在显存、量化、并发和上下文长度这四件事的平衡。如果你只是偶尔用，API 的性价比远高于自己维护。
选型建议可以看下面这张表：
| 接入方式 | 适合场景 | 主要限制 | 我一般怎么用 |
|---|---|---|---|
| 网页端 | 验证提示词、临时问答 | 无法批量、参数不可控 | 草稿纸，验证完就转 API |
| API | 批量处理、嵌入系统 | 依赖网络、按量计费 | 主力方式，配合重试和校验 |
| 本地部署 | 数据敏感、超高频调用 | 显存与并发瓶颈 | 只在明确需要时上，先小规模压测 |
3. 提示词工程：把“随口问”变成可复用的结构化指令
3.1 三段式模板：角色、约束、输出格式
我见过最普遍的翻车现场，是提示词里只有任务没有约束。比如“帮我总结这段文档”，模型会自由发挥，长度、格式、重点全凭运气。可复用的模板应该包含三段：角色（你是谁）、约束（不能做什么、必须做什么）、输出格式（用什么结构交付）。下面是一个文档抽取模板。
# prompt_template.py # 三段式提示词模板，适合合同、报告、日志等结构化抽取 SYSTEM_PROMPT = """你是一名信息抽取引擎。 约束： 1. 只依据用户提供的文本作答，不得编造。 2. 找不到的字段填 null，不要猜测。 3. 输出必须是合法 JSON，不要加 markdown 代码块标记。 输出格式： {"title": string, "date": string, "amount": number, "parties": [string]} """ def build_user_prompt(raw_text: str) -> str: # 把原文放在明确的分隔符内，减少模型把指令和内容混淆 return f"请抽取以下文本：\n<<<\n{raw_text}\n>>>"逻辑说明：SYSTEM_PROMPT把角色、约束、格式一次性说死，build_user_prompt用<<< >>>把待处理文本包起来，避免模型把文本里的句子当成新指令。参数说明：分隔符可以换成任意不常见符号，关键是“内容区”和“指令区”要视觉隔离。如果你的文本里本身包含<<<，就换一组更冷门的符号。
3.2 少样本示例：给两个例子比说十句要求管用
当输出格式复杂时，光靠文字描述约束，模型还是会飘。这时候加一两个输入输出示例，效果立竿见影。注意示例要覆盖边界情况，比如字段缺失、多值、空字符串。
# few_shot.py # 用两个示例锁定输出格式，第二个示例专门演示字段缺失 FEW_SHOT = [ {"role": "user", "content": "文本：合同A，2024-01-01，金额1000，甲方X，乙方Y"}, {"role": "assistant", "content": '{"title":"合同A","date":"2024-01-01","amount":1000,"parties":["X","Y"]}'}, {"role": "user", "content": "文本：备忘录，无日期，无金额，参与方只有Z"}, {"role": "assistant", "content": '{"title":"备忘录","date":null,"amount":null,"parties":["Z"]}'} ]逻辑说明：第二个示例专门演示null的写法，这比在系统提示里写十遍“找不到填 null”都有效。参数说明：示例数量控制在 2~4 个，太多会挤占上下文，也会让模型过度拟合示例表面格式。示例里的字段名必须和系统提示里的输出格式完全一致，否则模型会自己发明字段。
3.3 让模型“先想再答”的正确姿势
对推理类任务，直接要答案往往不如让它先列步骤。但要注意，不是所有任务都适合“先想再答”——抽取类任务如果让它先推理，反而容易引入噪声。我的经验是：数学、逻辑、多跳问答适合显式要求分步；格式转换、分类、抽取适合直接输出。如果你不确定，可以先用小批量对比两种方式的结果一致性。
4. 长上下文与文档处理：别把“能塞进去”当成“能读懂”
4.1 上下文窗口的真实边界：位置和干扰
很多人以为上下文窗口大，就可以把整本书塞进去。实际测试会发现，模型对开头和结尾的信息召回率明显高于中间，这就是常说的“中间遗忘”。另外，无关段落越多，关键信息被淹没的概率越大。所以长文档处理的第一步不是“塞”，而是“筛”。
我一般会做两级处理：先用关键词或向量检索把相关段落挑出来，再按重要性排序，把最关键的放在开头和结尾。如果必须全文送入，就在系统提示里明确告诉模型“重点看第几节”，给它一个注意力锚点。
4.2 分块、检索、重排的最小实现
下面是一个不依赖外部向量库的最小分块与检索示例，适合快速验证思路。
# chunk_retrieve.py # 按段落分块，用关键词重叠度做粗排，适合小规模文档快速验证 def chunk_text(text: str, max_len: int = 500): paragraphs = [p.strip() for p in text.split("\n") if p.strip()] chunks, buf = [], "" for p in paragraphs: if len(buf) + len(p) <= max_len: buf += p + "\n" else: chunks.append(buf.strip()) buf = p + "\n" if buf: chunks.append(buf.strip()) return chunks def rough_rank(query: str, chunks: list): # 用字符重叠度做粗排，真实项目可换成向量相似度 q = set(query) scored = [(len(q & set(c)) / (len(q) + 1), c) for c in chunks] return [c for _, c in sorted(scored, reverse=True)[:3]]逻辑说明：chunk_text按段落累积到接近max_len再切块，避免把一句话切断；rough_rank用字符集合重叠度做粗排，虽然粗糙，但足够验证“先筛后送”是否有效。参数说明：max_len一般设在 300~800 字之间，太小会丢上下文，太大会降低检索精度。真实项目里把rough_rank换成向量检索即可，但分块逻辑可以保留。
4.3 引用与溯源：让输出可验证
长文档任务最怕模型编造。我的做法是要求它在输出里带上原文片段作为引用，哪怕只是短句。这样你一眼就能看出它是真读到了，还是在自己编。如果它引用的片段在原文里找不到，直接判定该条结果不可信。
5. 避坑与排查：那些让我连夜改代码的瞬间
5.1 输出 JSON 解析失败：现象、原因、解决
现象：明明系统提示里写了“只输出 JSON”，程序里json.loads还是报错。原因通常有三个：模型加了 markdown 代码块标记、输出被max_tokens截断、文本里本身有未转义引号。解决：第一，在解析前先做一次清洗，去掉json 和包裹；第二，把max_tokens调大并检查finish_reason是否为length；第三，要求模型对引号做转义，或者在提示词里明确“字符串内双引号用反斜杠转义”。
5.2 结果不稳定：同一输入两次输出不一样
现象：同样的提示词，两次调用结果差异很大。原因：temperature过高、top_p设置不当、或者模型版本在后台发生了更新。解决：把temperature降到 0.2 以下，固定top_p，并在系统提示里加入“输出必须确定”的约束。如果仍然飘，考虑换用更小的模型做抽取，或者把任务拆成多个确定性更强的子步骤。
5.3 长文档丢细节：中间段落被忽略
现象：文档明明送进去了，模型却对中间某段的关键信息视而不见。原因：中间遗忘加上无关内容干扰。解决：先检索后送入，把关键段落提到开头或结尾；或者在提示词里显式指出“请重点阅读第 3 节关于金额的条款”。我一般还会在输出里要求它复述关键句，用来验证是否真的读到了。
5.4 成本失控：调用量不大但账单很高
现象：每天只跑几百次，费用却超出预期。原因：max_tokens设得过大、把整篇文档反复送入、或者失败重试没有上限。解决：给max_tokens设一个合理上限，对长文档做缓存，重试次数控制在 2~3 次并加退避。另外，抽取类任务优先用小模型，复杂推理再用大模型，能省下不少。
5.5 本地部署显存爆掉：现象、原因、解决
现象：加载模型时直接 OOM。原因：量化等级不够、上下文长度设得太大、并发数过高。解决：先用量化版本降低显存占用，把上下文长度从默认值往下调，并发从 1 开始压测。如果还是不够，就换更小的模型规格，别硬扛。
6. 进阶技巧：用校验链路把 DeepSeek 的输出变成可信数据
6.1 三层校验：格式、规则、抽样人工
要把模型输出接进生产流程，光靠提示词不够，必须加校验。我一般分三层：第一层格式校验，用 JSON Schema 或正则检查结构；第二层规则校验，比如金额必须为正数、日期必须合法；第三层抽样人工，每天抽 1%~5% 的结果人工核对，发现系统性偏差就回头改提示词或加示例。
# validate.py # 两层校验示例：格式 + 业务规则 import json def validate_output(raw: str): try: data = json.loads(raw) except json.JSONDecodeError as e: return False, f"JSON 解析失败: {e}" if not isinstance(data.get("amount"), (int, float)) and data.get("amount") is not None: return False, "amount 类型错误" if data.get("amount") is not None and data["amount"] < 0: return False, "amount 不能为负" return True, "ok"逻辑说明：先做 JSON 解析，再做字段类型和业务规则检查。参数说明：业务规则根据你的场景增删，关键是“校验失败要有明确原因”，方便定位是提示词问题还是模型能力问题。
6.2 用对比测试决定该不该换模型或换提示词
当你犹豫要不要换模型、换提示词时，别凭感觉。建一个 50~100 条的小测试集，覆盖正常、边界、异常三类输入，每次改动后跑一遍，统计格式正确率和字段准确率。只有准确率提升超过 5% 且成本可接受，才值得切换。这个习惯帮我省下了很多次“为了新而新”的折腾。
6.3 我自己的使用习惯
我现在拿到任何新任务，第一件事不是写提示词，而是先想清楚“输出长什么样、怎么校验、失败怎么办”。提示词只是中间一环，前后两端的工程化才是稳定性的来源。另外，我会把每次有效的提示词和参数组合存进一个版本库，标注适用场景和已知问题，下次遇到类似任务直接复用，而不是从头再猜。希望帮到你。
本文还有配套的精品资源，点击获取
