简介这份由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室余梦珑博士后团队编撰的《DeepSeek从入门到精通》PDF面向希望系统掌握DeepSeek的开发者、内容创作者与AI应用爱好者帮助读者从基础使用进阶到提示语设计的创新应用。资源包共1个PDF文件大小约6.45MB内容完整、结构清晰便于通读与检索。文档系统梳理了DeepSeek-R1的核心能力与适用场景涵盖智能对话、文本生成、语义理解、计算推理与代码补全并对比推理模型与通用模型的优劣介绍“快思慢想”概念。重点展开提示语设计策略包括信息类、结构类、控制类元素组合矩阵提示语链的CIRS与SPECTRA模型以及三链融合、语用意图分析、主题聚焦与细节增强等方法并针对缺乏迭代、过度指令、幻觉生成等常见陷阱给出应对策略。实战部分通过气候变化写作、网络安全、智能家居等案例演示完整流程已有3131人学习适合希望提升AI输出质量、构建个人提示词体系的读者。1. 从一份 104 页的 DeepSeek 手册说起它到底能帮你解决什么很多人第一次听到「DeepSeek 从入门到精通」这类标题第一反应是——又是一份堆概念的 PPT 合集。但真正翻过清华系那份 104 页 PDF 的人会发现它讲的不是「AI 有多厉害」而是把 DeepSeek 这类大模型从「怎么问」到「怎么部署」再到「怎么接进业务」的链路拆开讲了一遍。这份材料的价值不在于它有多深而在于它把提示词设计、本地部署、API 调用、文档解析这几件事串成了一条可执行的路径。如果你是从业者带着「我想把 DeepSeek 用起来」的诉求来的那这份手册对应的其实是四个具体问题提示词怎么写才不翻车、本地怎么跑起来、API 怎么接、PDF 这类文档怎么喂进去。下面我按自己实际落地的顺序把这四个问题拆开讲中间会穿插那份 104 页材料里值得抄作业的部分也会补上它没写透的坑。2. 提示词工程从「破甲」到结构化输出的可控路径2.1 为什么直接问 DeepSeek 经常得到「正确的废话」大模型默认的输出风格是「安全、全面、不得罪人」所以你问「帮我写个方案」它给你的往往是放之四海皆准的模板。这不是模型能力问题是提示词没有约束输出空间。清华那份 PDF 里反复强调一个观点提示词的本质是「缩小模型的解空间」而不是「求它帮你做事」。具体到操作上我一般会把提示词拆成四层角色设定、任务边界、输出格式、反面约束。角色设定决定语气和知识域任务边界决定它不跑题输出格式决定你能不能直接拿去用反面约束决定它不写废话。这四层缺一层输出质量就会明显下降。# DeepSeek 结构化提示词模板可直接复用 prompt_template # 角色 你是一名有 10 年经验的 {domain} 工程师擅长把复杂问题拆成可执行步骤。 # 任务 针对以下输入输出一份 {output_type} 输入{user_input} # 输出格式 1. 先用一句话给出结论 2. 再分 3 条列出关键理由每条不超过 40 字 3. 最后给一个可执行的下一步动作 # 约束 - 不要写「综上所述」「总而言之」这类套话 - 不要重复输入内容 - 如果信息不足直接说「缺少 X 信息」不要编造 这段模板的关键在最后一段约束。很多人写提示词只写「你要做什么」不写「你不要做什么」结果模型会用大量过渡句和总结句把有效信息稀释掉。参数上domain和output_type是变量实际调用时替换成具体值user_input建议控制在 500 字以内太长会导致模型注意力分散。2.2 用 few-shot 把输出格式钉死光靠文字描述格式模型有时候还是会自由发挥。更稳的做法是给 1 到 2 个示例也就是 few-shot。示例不需要多但必须覆盖你想要的格式和你不想要的格式。# few-shot 示例让 DeepSeek 按固定结构输出技术排查步骤 messages [ {role: system, content: 你输出排查步骤时必须按「现象 → 原因 → 解决」三段式。}, {role: user, content: 接口返回 502}, {role: assistant, content: 现象接口返回 502。原因网关后端服务不可达。解决检查后端进程是否存活确认端口监听。}, {role: user, content: 数据库连接超时} ] # 模型会按同样的三段式输出不需要再重复格式要求这里有个细节示例里的 assistant 回复要写得短、准、不带解释性废话。如果你示例里写了一大段背景模型就会学着写一大段背景。few-shot 的本质是「用例子定义风格」不是「用例子补充知识」。2.3 参数怎么设temperature 和 top_p 的取舍DeepSeek 的 API 里temperature和top_p是最常被乱设的两个参数。我的经验是做代码生成和结构化输出时temperature设 0.2 到 0.3top_p设 0.9做创意文案时temperature可以到 0.8但top_p不要同时调高否则输出会飘。场景temperaturetop_p说明代码生成0.20.9低随机性保证语法稳定技术文档摘要0.30.9保留一定灵活性创意文案0.80.9只调 temperature不动 top_p数据标注0.10.8接近确定性输出注意不要同时把 temperature 和 top_p 都调到很高这两个参数是叠加放大的一起调高会让输出完全不可控。3. 本地部署 DeepSeek从模型选择到显存算账3.1 先算显存再选模型版本本地部署 DeepSeek 最常见的翻车方式是下载了模型跑起来发现显存不够或者速度慢到没法用。所以第一步不是装环境是算账。DeepSeek 有多个尺寸的模型7B、13B、33B 甚至更大的版本显存需求和推理速度差别很大。粗略估算公式FP16 精度下显存需求约等于参数量 × 2GB。7B 模型约 14GB13B 约 26GB33B 约 66GB。如果做 4-bit 量化显存可以降到约四分之一。所以一张 24GB 显存的卡跑 7B FP16 没问题跑 13B 需要量化跑 33B 基本不现实。# 用 ollama 拉取并运行 DeepSeek 量化版本常见做法 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 查看模型运行时的显存占用 nvidia-smi --query-gpumemory.used --formatcsv -l 1ollama pull会自动选择适合当前硬件的量化版本deepseek-r1:7b是模型标识冒号后面是标签。运行后另开一个终端用nvidia-smi观察显存如果接近满载说明需要换更小的量化版本或者减少并发。3.2 用 vLLM 做生产级部署的配置要点如果只是自己用ollama 够了。但如果要接业务、要并发vLLM 是更常见的选择。vLLM 的核心优势是 PagedAttention能把显存利用率拉高吞吐量比朴素推理高好几倍。# vLLM 启动 DeepSeek 服务示例配置 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 8000tensor-parallel-size是张量并行数单卡设 1多卡设卡数。gpu-memory-utilization控制显存占用比例0.9 表示留 10% 余量设太高容易 OOM。max-model-len是最大上下文长度设得越大显存占用越高8192 是 7B 模型比较稳妥的值。启动后用 OpenAI 兼容接口测试from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyempty) resp client.chat.completions.create( modeldeepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages[{role: user, content: 用一句话解释什么是张量并行}], temperature0.3 ) print(resp.choices[0].message.content)base_url指向本地 vLLM 服务api_key随便填因为本地服务不校验。model参数必须和启动时的--model一致否则会报模型不存在。3.3 量化版本的选择GPTQ 还是 AWQ量化是本地部署绕不开的话题。常见的有 GPTQ 和 AWQ 两种GPTQ 出现早、生态全AWQ 在部分模型上精度保留更好。我的经验是如果模型有官方 AWQ 版本优先用 AWQ如果没有用 GPTQ 的 4-bit 版本也不会差太多。量化方式精度损失显存节省适用场景FP16无基准显存充足追求最高质量GPTQ 4-bit较小约 75%通用场景生态成熟AWQ 4-bit较小约 75%有官方 AWQ 版本时优先GGUF Q4中等约 75%CPU 推理或混合推理提示量化版本不是越小越好。2-bit 量化虽然省显存但输出质量下降明显技术文档生成场景下会出现语法错误和逻辑断裂。4. 文档解析与 PDF 投喂把 104 页手册变成可检索知识库4.1 PDF 解析的三种路线和选择依据把 PDF 喂给 DeepSeek 之前得先把 PDF 变成文本。这一步的坑比模型本身还多。常见路线有三种直接抽文本、OCR 识别、版面分析后结构化抽取。直接抽文本适合电子版 PDF速度快但遇到扫描件就废了OCR 适合扫描件但中文识别率参差不齐版面分析适合表格多、排版复杂的文档成本最高但效果最好。# 用 pdfplumber 抽取电子版 PDF 文本适合清华手册这类排版规整的文档 import pdfplumber def extract_pdf_text(pdf_path): full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text page.extract_text() if text: full_text.append(text) return \n.join(full_text) content extract_pdf_text(deepseek_guide.pdf) print(f总字符数{len(content)})extract_text()对规整排版的 PDF 效果很好但如果 PDF 里有分栏、表格、图片文字抽出来会乱序。判断标准很简单抽完后随便找一页对照原文如果段落顺序对得上就能用如果串行严重就得换版面分析方案。4.2 分块策略为什么不能整本塞进去104 页 PDF 大概有 5 到 8 万字直接塞进模型上下文不现实而且效果差——模型在长上下文里会丢失中间部分的信息。所以必须分块。分块的核心是「按语义边界切不按字数硬切」。# 按段落分块并保留重叠部分 def chunk_text(text, chunk_size500, overlap50): paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) chunk_size: chunks.append(current) current current[-overlap:] para # 保留重叠避免语义断裂 else: current \n\n para if current: chunks.append(current) return chunks chunks chunk_text(content) print(f分块数{len(chunks)}平均长度{sum(len(c) for c in chunks)//len(chunks)})chunk_size设 500 字左右比较稳太大检索精度下降太小语义不完整。overlap设 50 字作用是让相邻块之间有重叠避免一个完整句子被切到两个块里导致检索时丢信息。4.3 用嵌入模型建索引并接 DeepSeek 做问答分块之后用嵌入模型把每个块转成向量存进向量库。检索时把用户问题也转成向量找最相似的几个块拼进提示词里让 DeepSeek 回答。# 用 sentence-transformers 做嵌入配合 DeepSeek 做问答 from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(BAAI/bge-small-zh-v1.5) embeddings model.encode(chunks, normalize_embeddingsTrue) def search(query, top_k3): q_emb model.encode([query], normalize_embeddingsTrue) scores np.dot(embeddings, q_emb.T).flatten() top_idx np.argsort(scores)[-top_k:][::-1] return [chunks[i] for i in top_idx] # 检索后拼进 DeepSeek 提示词 context \n\n.join(search(DeepSeek 本地部署显存怎么算)) prompt f根据以下资料回答问题不要编造资料外的内容\n{context}\n\n问题DeepSeek 本地部署显存怎么算normalize_embeddingsTrue让向量归一化之后用点积就能算余弦相似度。top_k3是返回最相似的 3 个块太多会稀释关键信息太少可能漏掉答案。提示词里加一句「不要编造资料外的内容」能明显降低幻觉。5. 避坑与排查那些手册里没写透的翻车现场5.1 现象模型输出一半突然截断原因max_tokens设得太小或者上下文长度超了。DeepSeek 的 API 默认max_tokens可能只有 512生成技术文档时根本不够。解决显式设置max_tokens一般设 2048 到 4096。同时检查输入加输出的总长度是否超过模型上限超了就得分段处理。5.2 现象本地部署后响应速度极慢每秒不到 1 个字原因模型跑在 CPU 上或者显存不够导致频繁换页。用nvidia-smi看显存占用如果接近 100% 且 GPU 利用率低就是显存瓶颈。解决换更小的量化版本或者减少max-model-len。如果是 CPU 推理换 GGUF 格式的量化模型速度会好一些但别指望能和 GPU 比。5.3 现象PDF 解析出来全是乱码或空白原因PDF 是扫描件没有文本层extract_text()自然抽不出东西。或者 PDF 用了非标准编码。解决先用pdfplumber检查page.extract_text()是否返回空如果为空就转 OCR 路线。中文 OCR 可以用 PaddleOCR识别率比 Tesseract 好不少。5.4 现象检索出来的内容和问题不相关原因分块太大导致语义被稀释或者嵌入模型不适合中文。bge-small-zh是中文场景比较稳的选择但如果文档里有大量专业术语可能需要换更大的嵌入模型。解决先把chunk_size降到 300 试试如果还不行换bge-base-zh或bge-large-zh。另外检查检索时是否做了归一化没归一化的话相似度计算会偏。5.5 现象DeepSeek 回答时编造资料里没有的内容原因提示词没有约束「只根据资料回答」或者检索到的资料本身不包含答案模型就自己编了。解决提示词里明确写「如果资料中没有答案直接说不知道」。另外可以在检索后加一个相关性阈值相似度低于阈值的块不拼进提示词宁可让模型说不知道也不要让它编。6. 进阶技巧用 DeepSeek 做文档问答的验证与调优把上面这套跑通之后下一步是验证它到底靠不靠谱。我一般会做两件事一是构造一批「已知答案」的问题看检索和回答的命中率二是故意问一些资料里没有的问题看模型会不会老实说不知道。构造测试集的方法很简单从 PDF 里随机抽 20 个段落每个段落手动写一个问题答案就在段落里。然后跑一遍统计检索命中率和回答准确率。如果检索命中率低于 80%说明分块或嵌入模型有问题如果检索命中但回答错说明提示词或模型能力有问题。# 简易验证脚本统计检索命中率 test_cases [ {question: DeepSeek 本地部署显存怎么估算, answer_keyword: 参数量}, {question: vLLM 的 gpu-memory-utilization 是什么, answer_keyword: 显存占用}, # ... 更多测试用例 ] hit 0 for case in test_cases: retrieved search(case[question]) if any(case[answer_keyword] in chunk for chunk in retrieved): hit 1 print(f检索命中率{hit}/{len(test_cases)} {hit/len(test_cases)*100:.1f}%)answer_keyword是答案里的关键锚点不需要完整匹配只要检索到的块里包含这个词就算命中。这个方法粗糙但有效能快速判断检索环节有没有大问题。调优的顺序是先调分块再调嵌入模型最后调提示词。因为分块和嵌入决定「能不能找到」提示词决定「找到后能不能答对」。顺序反了会浪费很多时间在提示词上结果发现根本是检索没找到。还有一个我踩过的坑不要用同一个模型既做嵌入又做生成。嵌入模型和生成模型的目标不一样混用效果通常不好。嵌入用专门的bge系列生成用 DeepSeek各司其职。最后说个习惯每次改完参数我都会把测试集跑一遍记录命中率和准确率的变化。不记录的话改着改着就忘了哪个参数是有效的。这套文档问答的方案从分块到检索到生成每个环节都有可调参数但真正影响大的就那么两三个找到它们靠的不是直觉是反复验证。希望帮到你。本文还有配套的精品资源点击获取