简介《DeepSeek从入门到精通》是清华大学团队推出的PDF学习指南面向具备AI基础的技术人员与研究者讲解国产开源推理模型DeepSeek-R1的应用与原理。资源包仅含1个PDF文档大小5.35MB覆盖智能对话、文本生成、语义理解、代码补全等核心场景并对比推理模型与通用模型的差异介绍“快思慢想”与链式推理。文件重点讲解提示语策略推理模型可直接表达需求通用模型需显式引导通过数学证明、创意写作、代码生成等案例展示指令驱动、需求导向、混合模式、启发式提问四类策略。还梳理了从“下达指令”到“表达需求”的进阶路径帮助读者理解“怎么做”与“为什么这样做”。已有1936人学习适合希望提升大模型应用层次、掌握国产开源工具精要的从业者兼具理论深度与实操指导价值。1. DeepSeek 开源推理模型为什么它值得从入门到精通2025 年开工第一天我接了个活儿用 DeepSeek 给客户做一个私有知识库问答机器人。当时我对 DeepSeek 的认知还停留在「国产开源模型网上口碑不错」结果一上手发现真正拉开差距的不是模型本身而是会不会用。同样一个模型有人把它当百度用问一句答一句有人把它当推理引擎甩给它一个复杂问题它能自己拆解、验证、输出完整方案。DeepSeek 是国产开源推理模型里少数能免费商用的选择R1 系列在数学推理、代码生成和逻辑分析上的表现尤其突出。这份来自清华团队整理的入门资料核心就讲三件事DeepSeek 能做什么、推理模型和通用模型怎么选、提示语怎么写才不浪费模型能力。适合两类人——想快速上手的开发者和需要把 AI 写进工作流的技术管理者。2. 推理模型和通用模型的选型先懂快慢思考再谈提示语2.1 快慢思考的划分推理模型到底「推理」了什么很多人误以为推理模型就是「更聪明的模型」其实不是。CoT 链式思维出现之后大模型被明确分成了两类一类是概率预测的快速反应模型典型代表是 ChatGPT 4o响应快、算力成本低但遇到需要严格逻辑链的任务容易跳步另一类是链式推理的慢速思考模型比如 DeepSeek-R1 和 OpenAI o1它们会把问题拆成步骤逐步推导算力成本更高但在数学证明、代码生成和复杂问题拆解上明显更稳。这份入门资料里有一个很反直觉的点推理模型并非全面更强。在诗歌创作、开放闲聊这类发散性任务上通用模型反而表现更好因为推理模型过于执着于逻辑链路会把天马行空的创意硬生生拉回结构化框架。强弱判断要看训练目标推理模型专精于逻辑密度高的任务通用模型擅长多样性高的任务。这一点决定了后面所有提示语策略的走向。理解快慢思考的差异直接影响你用 DeepSeek 的方式。快思考模型适合即时反馈场景比如快速问答、标题生成慢思考模型适合需要深度推演的复杂问题比如算法设计、数据分析和方案对比。如果你拿推理模型去做创意发散又拿通用模型去推数学证明两头都会翻车。2.2 一张选型对照表先看任务类型再看模型热度资料里给了一张很实用的对照表我直接复述并加了实际使用维度可以打印出来贴在工位上。维度推理模型DeepSeek-R1 类通用模型GPT-4 类优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作需要严格逻辑链的任务如数学证明性能本质专精于逻辑密度高的任务擅长多样性高的任务提示语要求简洁聚焦目标信任其内化能力需要显式引导推理步骤补偿能力短板决策能力能自主分析、实时决策依赖预设算法和规则响应速度慢速思考算力成本高响应快算力成本低选型原则很简单优先根据任务类型而非模型热度来选择。数学、代码、逻辑分析任务无脑选推理模型创意写作、开放闲聊、情感互动选通用模型更省心。用错了模型后面怎么写提示语都是事倍功半。2.3 实操演练同一道题跑两个模型看差异在哪儿入门最快的方式不是读文档而是亲手做对比实验。我一般会准备一套固定的测试题同时发给推理模型和通用模型从三个维度记录输出差异。# 对比测试脚本同一任务跑两个模型记录差异 import json test_cases [ { task: 证明勾股定理, model: deepseek-reasoner, # 推理模型 prompt: 证明勾股定理 }, { task: 写一首关于秋天的现代诗, model: deepseek-chat, # 通用模型 prompt: 写一首关于秋天的现代诗 } ] for case in test_cases: print(f模型: {case[model]} | 任务: {case[task]}) print(f提示语: {case[prompt]}) # 实际运行时这里会调用 API 获取响应 # 重点观察三个维度 # 1. 输出是否分步推导 # 2. 是否主动校验中间结果 # 3. 面对开放性任务是否显得「用力过猛」参数说明deepseek-reasoner是推理模型端点适合需要慢速思考的任务deepseek-chat是通用对话端点适合快速响应。跑完对比你会发现推理模型在面对开放创作题时常常会自动添加逻辑框架比如「从意象、节奏、情感三个层面展开」这就是它的惯性。反过来通用模型面对数学证明题时经常省略关键推导步骤直接给出结论看起来合理但经不起推敲。做完这组对比你就明白为什么提示语策略要分模型设计了。3. 提示语策略的四个转向从「下达指令」到「表达需求」3.1 提示语的三要素指令、上下文、期望资料里对提示语的定义很精炼提示语是用户输入给 AI 系统的指令或信息用于引导 AI 生成特定输出。它由三个基本结构组成——指令Instruction、上下文Context和期望Expectation。指令是核心明确告诉 AI 要执行什么任务上下文提供背景信息帮助 AI 准确理解任务场景期望表达你对输出的要求包括格式、长度、风格等。这里有个常见的理解偏差很多人以为提示语越长越好把背景信息一股脑塞进去结果反而稀释了指令。一个好的提示语指令必须清晰且优先级最高上下文只用补充必要背景期望要在最后明确收口。比如「将以下内容翻译为法语Hello, world指令是翻译上下文是源文本期望是目标语言。三要素缺一不可但各自的位置和比例要拿捏。资料里总结的六个类型也很有用指令型、问答型、角色扮演型、创意型、分析型、多模态型。实操中我通常会把多个类型叠加使用比如「扮演一个 19 世纪的历史学家分析拿破仑崛起的原因用 300 字给出三个关键因素」就是角色扮演 分析 期望的组合。3.2 五类需求表达公式把「要什么」翻译成「怎么问」这是整份资料里价值密度最高的部分——五类需求表达公式。它解决的核心问题是用户脑子里有明确需求但不知道怎么转换成 AI 能理解的语言。需求类型特点需求表达公式决策需求需权衡选项、评估风险、选择最优解目标 选项 评估标准分析需求需深度理解数据、发现模式或因果关系问题 数据/信息 分析方法创造性需求需生成新颖内容主题 风格/约束 创新方向验证需求需检查逻辑自洽性、数据可靠性结论/方案 验证方法 风险点执行需求需完成具体操作任务 步骤约束 输出格式拿决策需求举例。错误问法「我要不要自建仓库」——没有选项、没有评估标准。正确问法「为降低物流成本现有两种方案①自建区域仓库初期投入高、长期成本低②与第三方合作按需付费、灵活性高。请根据 ROI 计算模型对比 5 年内的总成本并推荐最优选择依据。」后者把目标、选项、评估标准全部补齐模型才能给出高质量的对比分析。资料里这部分的实战技巧非常密集尤其是「验证需求」——很多人不知道让 AI 检查自己的结论时要给出验证方法和风险点否则它只会顺着你的话说。3.3 一个可复用的提示语模板库把公式固化成代码公式看懂了不算掌握我习惯把常用公式固化成模板库写入代码里随取随用。# 通用提示语模板库按需求类型预置结构 prompt_templates { decision: 目标{goal}\n选项{options}\n评估标准{criteria}\n请对比所有选项给出推荐结论及依据。, analysis: 问题{question}\n数据{data}\n分析方法{method}\n请输出分析结论并指出关键变量之间的因果关系。, creation: 主题{topic}\n风格/约束{constraints}\n创新方向{direction}\n请生成完整内容避免落入常见套路。, verification: 需验证的结论{conclusion}\n验证方法{method}\n风险点{risks}\n请检查逻辑自洽性给出验证结果。, execution: 任务{task}\n步骤约束{steps}\n输出格式{format}\n请按要求执行并输出结果。 } # 使用示例生成一个决策需求提示语 prompt prompt_templates[decision].format( goal降低物流成本, options①自建区域仓库 ②与第三方合作, criteriaROI计算模型对比5年总成本 ) print(prompt)逻辑说明模板库的意义不是让你死记硬背而是把方法论的五个维度固化下来避免临场遗漏关键要素。参数说明{goal}是决策目标{options}是候选方案列表{criteria}是评估标准这三个参数对应决策需求公式的三要素。实际使用时你可以根据任务类型调用对应模板再填充具体参数。这在批量生成任务里特别好用——用程序循环填充参数自动生成 N 条结构化提示语比每次手写效率高一个量级。3.4 从「下达指令」到「表达需求」的思维转向资料里有一句话值得反复琢磨从下达指令到表达需求这不是文字游戏而是使用 AI 的思维方式转变。下达指令的人关心的是「我怎么操作」表达需求的人关心的是「我想要什么结果」。前者把 AI 当成执行工具后者把 AI 当成协作对象。我见过太多人写提示语时习惯性使用「启发式」指令——给推理模型设定角色、要求它分步思考。资料里明确指出这是一个误区推理模型已经内化了推理逻辑你强行拆解步骤反而限制了它的能力。正确做法是「要什么直接说」信任它的内化能力。反过来通用模型需要的是「缺什么补什么」——你显式要求它分步思考、提供示例否则它容易跳过关键逻辑环节。实际使用中「描述问题背景与目标」比「给我三个建议」效果好得多。前者把需求边界定义清楚模型知道该往哪个方向发力后者太开放模型只能给泛泛的答案。把「我要一个方案」改成「我要一个 5 万元预算内的市场推广方案目标用户是 25~35 岁城市白领下月执行」你会发现输出质量完全不一样。4. 把 DeepSeek 接到自己的链路API 调用、本地部署与工具链配置4.1 三条接入路径怎么选网页端、API、本地部署是现在接入 DeepSeek 的三条主流路径适用场景完全不同。网页端用起来最省事打开 chat.deepseek.com 就能开聊适合日常体验、个人学习和快速验证想法。API 适合开发者——你写的程序需要自动调用模型能力无论是批量文本处理、代码审查还是构建一个机器人服务API 都是最直接的方式。本地部署适合数据敏感场景模型权重下载到自己的机器上运行不经过第三方服务器代价是需要准备显卡和显存。我一般给客户做方案时这样推荐数据不能出内网的必须本地部署数据可以出内网的先用 API 跑通再评估要不要迁移到本地个人学习网页端就够。三条路径的模型能力差异不大差异主要在部署成本和调用方式。另外提一句DeepSeek 的 API 格式对 OpenAI 生态很友好很多现成的工具可以直接改 base_url 和模型名就接入迁移成本非常低。4.2 用 Python 调 API最小可运行的示例写一个最基础的 API 调用示例唤起对话。代码里用到的是 OpenAI SDK 的兼容模式这是社区里最常见的接入方式。# 使用 OpenAI SDK 兼容模式调用 DeepSeek API from openai import OpenAI client OpenAI( api_keysk-这里是你的密钥, base_urlhttps://api.deepseek.com/v1 # DeepSeek 的 OpenAI 兼容端点 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型需要复杂推理时换 deepseek-reasoner messages[ {role: system, content: 你是一个严谨的数据分析师。}, {role: user, content: 分析近三年新能源汽车销量数据指出增长趋势与政策关联性并预测 2025 年市占率。使用 ARIMA 模型并解释参数。} ], temperature0.3, # 分析类任务建议低温保证稳定性 streamFalse ) print(response.choices[0].message.content)逻辑说明先创建客户端指定 DeepSeek 的接口地址和密钥然后调用聊天补全接口传入模型名和消息列表。system消息用来设定角色背景user消息是实际任务。temperature控制输出的随机性数值越低越稳定0.3适合分析任务0.7~1.0适合创意任务。注意到这里deepseek-chat是通用对话端点如果你要处理数学证明、复杂代码生成这类任务把模型名换成deepseek-reasoner效果更好。4.3 本地部署Ollama 起一个离线实例本地部署的场景这两年越来越常见。原因很实在数据敏感、成本控制、定制化需求。Ollama 是目前最省心的本地运行方案一条命令就能把模型拉下来跑起来。# 安装并运行 Ollama curl -fsSL https://ollama.ai/install.sh | sh # 拉取 DeepSeek 蒸馏模型按显存选择规格 ollama pull deepseek-r1:7b # 启动本地服务 ollama serve命令完成后模型就运行在本地的 11434 端口上你可以在本地代码里用刚才的 OpenAI 兼容方式接入只不过 base_url 要改成http://localhost:11434/v1。需要注意的启动参数是OLLAMA_NUM_PARALLEL它控制并发请求数。默认值在单用户场景够用但如果部署成团队服务建议显式设置成一个合理值比如 4避免多个请求同时进来时内存被吃穿。工具链接入方面很多开发者把 DeepSeek 接到编辑器里用。常见做法是通过 Continue 或 Cline 这类插件配置里指定baseUrl和model指向 DeepSeek 的 API。这样写代码时的补全和解释就用自己的模型跑了私密性和成本都可以拿捏。5. 避坑手记DeepSeek 实操中最常见的五个翻车现场5.1 给推理模型叠角色扮演输出反而变空洞现象给 DeepSeek-R1 加了一个很完整的角色设定「你是一位拥有 20 年经验的首席架构师请分五步设计系统」结果输出变得又长又空推理深度还不如直接提问。原因推理模型已经内化了推理逻辑角色扮演这类启发式提示会干扰它的逻辑主线让它把注意力放在「演好角色」而不是「解决问题」上。资料里明确提醒过不要对推理模型使用启发式提示。解决直接给目标和约束。「设计一个日活百万的电商系统要求给出架构图文本描述、数据库选型和分库分表策略。」去掉角色设定输出质量立刻回来。5.2 通用模型直接做数学证明答案看着对但经不起推敲现象用普通对话模型求「证明勾股定理」它给了三步证明思路看起来完全合理但中间一步跳过了关键的相似三角形推导。原因通用模型的训练目标偏向语言生成不擅长复杂逻辑链路。你直接抛复杂问题时它没有显式的推理链支撑只能根据概率预测拼凑出「像样的答案」。解决拆解步骤显式要求分步思考。「第一步画出直角三角形并标出边长第二步列出相似三角形关系第三步推导平方关系。」每一步验证通过后再让模型继续下一步。5.3 本地部署模型直接 OOM程序秒挂现象在 8GB 显存的机器上直接ollama run deepseek-r1:32b启动没几秒就 OOM进程被杀。原因模型参数量与显存要求不匹配。32B 模型在 FP16 精度下就需要大约 64GB 显存8GB 完全不够跑。解决先看显存选规格。7B 模型量化后大约 4~6GB 显存可以在消费级显卡上跑你还可以用OLLAMA_NUM_PARALLEL1限制并发加载时设置OLLAMA_CONTEXT_LENGTH2048减小 KV 缓存占用。先把小规格跑通再逐步升级。5.4 API 报错 tool calls 相关上下文里的工具消息缺失现象调用 API 开启函数调用功能后请求报错提示类似「messages tool calls need immediate results」模型已经发起了工具调用但它期望的后续内容没有出现。原因OpenAI 兼容模式下的函数调用协议要求当模型返回tool_calls时下一轮对话必须把对应结果以tool角色消息回传。很多新手在第一个消息里收到工具调用就直接结束了会话没有完成回传动作协议就不满足。解决收到tool_calls后构造 role: tool, tool_call_id: 上一步返回的 ID, content: 工具执行结果} 消息追加到消息列表里再发起第二次补全请求。把「模型调用工具 → 工具返回结果 → 模型继续作答」当成一个完整回合来处理就不会断链。5.5 温度调太高代码生成结果完全不可控现象把temperature调到 0.9 让模型写一段排序算法结果它输出了一个能跑但结构混乱的版本注释位置随机甚至有一次把冒泡排序写成了选择排序的变体。原因温度控制采样随机性高温度下模型更倾向探索多样化的表达这在创意任务里是优点但代码生成要求精确性和一致性高温度会让逻辑链条变得不稳定。解决代码生成任务把temperature控制在 0~0.3 区间创意写作再调到 0.7 以上。同一份代码任务跑三次取一致版本是我自己的底线操作。6. 进阶验证用「需求公式 输出检查表」批量验收生成质量入门的人学会写提示语进阶的人学会验收提示语。我的习惯是任何一个重要输出都必须过一遍需求公式和输出检查表。需求公式检查的是提示语本身是否完整——目标、选项、评估标准、约束条件是否都给了输出检查表检查的是模型返回的内容是否真正满足需求。一前一后配合才能在批量化场景里稳定复用。以「决策需求」为例收到模型输出后按以下清单逐条验证是否明确对比了所有提供的选项还是只挑了其中一两个展开。是否使用了你提供的评估标准没有自创一套标准偷换概念。是否给出了推荐结论还是只列了优缺点把决策推回给你。数值计算部分是否可复算关键公式和数据来源是否标注清楚。逻辑上是否有遗漏的成本项比如只算建设成本不算运维成本。验证类需求是另一个容易出彩的地方。让 DeepSeek 验证一份实验数据你可以要求它重新计算 p 值、检查对照组设置是否存在偏差、对比实验数据是否支持结论。这些都是资料里的原话但落实到提示语里要明确要求输出验证过程和原始计算结果而不是一句「支持该结论」了事。写一个脚本把这套验收流程固化下来批量跑效果更好。# 批量验收脚本循环测试用例记录通过率 test_requirements [ {task: 决策需求, prompt_file: prompts/decision.json}, {task: 分析需求, prompt_file: prompts/analysis.json}, {task: 创造性需求, prompt_file: prompts/creation.json} ] for req in test_requirements: responses run_model(req[prompt_file], n3, temperature0.2) # 逐条套用输出检查表打通过/不通过标记 pass_rate sum(check_output(r) for r in responses) / len(responses) print(f{req[task]}: {pass_rate:.0%} 通过)跑批次的建议是每个任务重复 3~5 次取通过率而非单次结果来判断因为随机采样会影响输出波动单次结果说明不了问题。低温度下通过率应该居高如果低于 60%大概率是提示语本身缺了关键参数回去补公式要素不要执着于换说法。我自己的教训是之前依赖单次输出就上线 AI 客服系统结果有一半的回答偏离需求用户投诉不断。从那以后我每次交付一份 AI 生成内容都强制走一遍这套流程先明确需求类型再选模型再套模板写提示语最后逐条对照检查表打分通过率。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek推理模型从入门到精通：提示语策略、API接入与避坑指南
简介《DeepSeek从入门到精通》是清华大学团队推出的PDF学习指南面向具备AI基础的技术人员与研究者讲解国产开源推理模型DeepSeek-R1的应用与原理。资源包仅含1个PDF文档大小5.35MB覆盖智能对话、文本生成、语义理解、代码补全等核心场景并对比推理模型与通用模型的差异介绍“快思慢想”与链式推理。文件重点讲解提示语策略推理模型可直接表达需求通用模型需显式引导通过数学证明、创意写作、代码生成等案例展示指令驱动、需求导向、混合模式、启发式提问四类策略。还梳理了从“下达指令”到“表达需求”的进阶路径帮助读者理解“怎么做”与“为什么这样做”。已有1936人学习适合希望提升大模型应用层次、掌握国产开源工具精要的从业者兼具理论深度与实操指导价值。1. DeepSeek 开源推理模型为什么它值得从入门到精通2025 年开工第一天我接了个活儿用 DeepSeek 给客户做一个私有知识库问答机器人。当时我对 DeepSeek 的认知还停留在「国产开源模型网上口碑不错」结果一上手发现真正拉开差距的不是模型本身而是会不会用。同样一个模型有人把它当百度用问一句答一句有人把它当推理引擎甩给它一个复杂问题它能自己拆解、验证、输出完整方案。DeepSeek 是国产开源推理模型里少数能免费商用的选择R1 系列在数学推理、代码生成和逻辑分析上的表现尤其突出。这份来自清华团队整理的入门资料核心就讲三件事DeepSeek 能做什么、推理模型和通用模型怎么选、提示语怎么写才不浪费模型能力。适合两类人——想快速上手的开发者和需要把 AI 写进工作流的技术管理者。2. 推理模型和通用模型的选型先懂快慢思考再谈提示语2.1 快慢思考的划分推理模型到底「推理」了什么很多人误以为推理模型就是「更聪明的模型」其实不是。CoT 链式思维出现之后大模型被明确分成了两类一类是概率预测的快速反应模型典型代表是 ChatGPT 4o响应快、算力成本低但遇到需要严格逻辑链的任务容易跳步另一类是链式推理的慢速思考模型比如 DeepSeek-R1 和 OpenAI o1它们会把问题拆成步骤逐步推导算力成本更高但在数学证明、代码生成和复杂问题拆解上明显更稳。这份入门资料里有一个很反直觉的点推理模型并非全面更强。在诗歌创作、开放闲聊这类发散性任务上通用模型反而表现更好因为推理模型过于执着于逻辑链路会把天马行空的创意硬生生拉回结构化框架。强弱判断要看训练目标推理模型专精于逻辑密度高的任务通用模型擅长多样性高的任务。这一点决定了后面所有提示语策略的走向。理解快慢思考的差异直接影响你用 DeepSeek 的方式。快思考模型适合即时反馈场景比如快速问答、标题生成慢思考模型适合需要深度推演的复杂问题比如算法设计、数据分析和方案对比。如果你拿推理模型去做创意发散又拿通用模型去推数学证明两头都会翻车。2.2 一张选型对照表先看任务类型再看模型热度资料里给了一张很实用的对照表我直接复述并加了实际使用维度可以打印出来贴在工位上。维度推理模型DeepSeek-R1 类通用模型GPT-4 类优势领域数学推导、逻辑分析、代码生成、复杂问题拆解文本生成、创意写作、多轮对话、开放性问答劣势领域发散性任务如诗歌创作需要严格逻辑链的任务如数学证明性能本质专精于逻辑密度高的任务擅长多样性高的任务提示语要求简洁聚焦目标信任其内化能力需要显式引导推理步骤补偿能力短板决策能力能自主分析、实时决策依赖预设算法和规则响应速度慢速思考算力成本高响应快算力成本低选型原则很简单优先根据任务类型而非模型热度来选择。数学、代码、逻辑分析任务无脑选推理模型创意写作、开放闲聊、情感互动选通用模型更省心。用错了模型后面怎么写提示语都是事倍功半。2.3 实操演练同一道题跑两个模型看差异在哪儿入门最快的方式不是读文档而是亲手做对比实验。我一般会准备一套固定的测试题同时发给推理模型和通用模型从三个维度记录输出差异。# 对比测试脚本同一任务跑两个模型记录差异 import json test_cases [ { task: 证明勾股定理, model: deepseek-reasoner, # 推理模型 prompt: 证明勾股定理 }, { task: 写一首关于秋天的现代诗, model: deepseek-chat, # 通用模型 prompt: 写一首关于秋天的现代诗 } ] for case in test_cases: print(f模型: {case[model]} | 任务: {case[task]}) print(f提示语: {case[prompt]}) # 实际运行时这里会调用 API 获取响应 # 重点观察三个维度 # 1. 输出是否分步推导 # 2. 是否主动校验中间结果 # 3. 面对开放性任务是否显得「用力过猛」参数说明deepseek-reasoner是推理模型端点适合需要慢速思考的任务deepseek-chat是通用对话端点适合快速响应。跑完对比你会发现推理模型在面对开放创作题时常常会自动添加逻辑框架比如「从意象、节奏、情感三个层面展开」这就是它的惯性。反过来通用模型面对数学证明题时经常省略关键推导步骤直接给出结论看起来合理但经不起推敲。做完这组对比你就明白为什么提示语策略要分模型设计了。3. 提示语策略的四个转向从「下达指令」到「表达需求」3.1 提示语的三要素指令、上下文、期望资料里对提示语的定义很精炼提示语是用户输入给 AI 系统的指令或信息用于引导 AI 生成特定输出。它由三个基本结构组成——指令Instruction、上下文Context和期望Expectation。指令是核心明确告诉 AI 要执行什么任务上下文提供背景信息帮助 AI 准确理解任务场景期望表达你对输出的要求包括格式、长度、风格等。这里有个常见的理解偏差很多人以为提示语越长越好把背景信息一股脑塞进去结果反而稀释了指令。一个好的提示语指令必须清晰且优先级最高上下文只用补充必要背景期望要在最后明确收口。比如「将以下内容翻译为法语Hello, world指令是翻译上下文是源文本期望是目标语言。三要素缺一不可但各自的位置和比例要拿捏。资料里总结的六个类型也很有用指令型、问答型、角色扮演型、创意型、分析型、多模态型。实操中我通常会把多个类型叠加使用比如「扮演一个 19 世纪的历史学家分析拿破仑崛起的原因用 300 字给出三个关键因素」就是角色扮演 分析 期望的组合。3.2 五类需求表达公式把「要什么」翻译成「怎么问」这是整份资料里价值密度最高的部分——五类需求表达公式。它解决的核心问题是用户脑子里有明确需求但不知道怎么转换成 AI 能理解的语言。需求类型特点需求表达公式决策需求需权衡选项、评估风险、选择最优解目标 选项 评估标准分析需求需深度理解数据、发现模式或因果关系问题 数据/信息 分析方法创造性需求需生成新颖内容主题 风格/约束 创新方向验证需求需检查逻辑自洽性、数据可靠性结论/方案 验证方法 风险点执行需求需完成具体操作任务 步骤约束 输出格式拿决策需求举例。错误问法「我要不要自建仓库」——没有选项、没有评估标准。正确问法「为降低物流成本现有两种方案①自建区域仓库初期投入高、长期成本低②与第三方合作按需付费、灵活性高。请根据 ROI 计算模型对比 5 年内的总成本并推荐最优选择依据。」后者把目标、选项、评估标准全部补齐模型才能给出高质量的对比分析。资料里这部分的实战技巧非常密集尤其是「验证需求」——很多人不知道让 AI 检查自己的结论时要给出验证方法和风险点否则它只会顺着你的话说。3.3 一个可复用的提示语模板库把公式固化成代码公式看懂了不算掌握我习惯把常用公式固化成模板库写入代码里随取随用。# 通用提示语模板库按需求类型预置结构 prompt_templates { decision: 目标{goal}\n选项{options}\n评估标准{criteria}\n请对比所有选项给出推荐结论及依据。, analysis: 问题{question}\n数据{data}\n分析方法{method}\n请输出分析结论并指出关键变量之间的因果关系。, creation: 主题{topic}\n风格/约束{constraints}\n创新方向{direction}\n请生成完整内容避免落入常见套路。, verification: 需验证的结论{conclusion}\n验证方法{method}\n风险点{risks}\n请检查逻辑自洽性给出验证结果。, execution: 任务{task}\n步骤约束{steps}\n输出格式{format}\n请按要求执行并输出结果。 } # 使用示例生成一个决策需求提示语 prompt prompt_templates[decision].format( goal降低物流成本, options①自建区域仓库 ②与第三方合作, criteriaROI计算模型对比5年总成本 ) print(prompt)逻辑说明模板库的意义不是让你死记硬背而是把方法论的五个维度固化下来避免临场遗漏关键要素。参数说明{goal}是决策目标{options}是候选方案列表{criteria}是评估标准这三个参数对应决策需求公式的三要素。实际使用时你可以根据任务类型调用对应模板再填充具体参数。这在批量生成任务里特别好用——用程序循环填充参数自动生成 N 条结构化提示语比每次手写效率高一个量级。3.4 从「下达指令」到「表达需求」的思维转向资料里有一句话值得反复琢磨从下达指令到表达需求这不是文字游戏而是使用 AI 的思维方式转变。下达指令的人关心的是「我怎么操作」表达需求的人关心的是「我想要什么结果」。前者把 AI 当成执行工具后者把 AI 当成协作对象。我见过太多人写提示语时习惯性使用「启发式」指令——给推理模型设定角色、要求它分步思考。资料里明确指出这是一个误区推理模型已经内化了推理逻辑你强行拆解步骤反而限制了它的能力。正确做法是「要什么直接说」信任它的内化能力。反过来通用模型需要的是「缺什么补什么」——你显式要求它分步思考、提供示例否则它容易跳过关键逻辑环节。实际使用中「描述问题背景与目标」比「给我三个建议」效果好得多。前者把需求边界定义清楚模型知道该往哪个方向发力后者太开放模型只能给泛泛的答案。把「我要一个方案」改成「我要一个 5 万元预算内的市场推广方案目标用户是 25~35 岁城市白领下月执行」你会发现输出质量完全不一样。4. 把 DeepSeek 接到自己的链路API 调用、本地部署与工具链配置4.1 三条接入路径怎么选网页端、API、本地部署是现在接入 DeepSeek 的三条主流路径适用场景完全不同。网页端用起来最省事打开 chat.deepseek.com 就能开聊适合日常体验、个人学习和快速验证想法。API 适合开发者——你写的程序需要自动调用模型能力无论是批量文本处理、代码审查还是构建一个机器人服务API 都是最直接的方式。本地部署适合数据敏感场景模型权重下载到自己的机器上运行不经过第三方服务器代价是需要准备显卡和显存。我一般给客户做方案时这样推荐数据不能出内网的必须本地部署数据可以出内网的先用 API 跑通再评估要不要迁移到本地个人学习网页端就够。三条路径的模型能力差异不大差异主要在部署成本和调用方式。另外提一句DeepSeek 的 API 格式对 OpenAI 生态很友好很多现成的工具可以直接改 base_url 和模型名就接入迁移成本非常低。4.2 用 Python 调 API最小可运行的示例写一个最基础的 API 调用示例唤起对话。代码里用到的是 OpenAI SDK 的兼容模式这是社区里最常见的接入方式。# 使用 OpenAI SDK 兼容模式调用 DeepSeek API from openai import OpenAI client OpenAI( api_keysk-这里是你的密钥, base_urlhttps://api.deepseek.com/v1 # DeepSeek 的 OpenAI 兼容端点 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型需要复杂推理时换 deepseek-reasoner messages[ {role: system, content: 你是一个严谨的数据分析师。}, {role: user, content: 分析近三年新能源汽车销量数据指出增长趋势与政策关联性并预测 2025 年市占率。使用 ARIMA 模型并解释参数。} ], temperature0.3, # 分析类任务建议低温保证稳定性 streamFalse ) print(response.choices[0].message.content)逻辑说明先创建客户端指定 DeepSeek 的接口地址和密钥然后调用聊天补全接口传入模型名和消息列表。system消息用来设定角色背景user消息是实际任务。temperature控制输出的随机性数值越低越稳定0.3适合分析任务0.7~1.0适合创意任务。注意到这里deepseek-chat是通用对话端点如果你要处理数学证明、复杂代码生成这类任务把模型名换成deepseek-reasoner效果更好。4.3 本地部署Ollama 起一个离线实例本地部署的场景这两年越来越常见。原因很实在数据敏感、成本控制、定制化需求。Ollama 是目前最省心的本地运行方案一条命令就能把模型拉下来跑起来。# 安装并运行 Ollama curl -fsSL https://ollama.ai/install.sh | sh # 拉取 DeepSeek 蒸馏模型按显存选择规格 ollama pull deepseek-r1:7b # 启动本地服务 ollama serve命令完成后模型就运行在本地的 11434 端口上你可以在本地代码里用刚才的 OpenAI 兼容方式接入只不过 base_url 要改成http://localhost:11434/v1。需要注意的启动参数是OLLAMA_NUM_PARALLEL它控制并发请求数。默认值在单用户场景够用但如果部署成团队服务建议显式设置成一个合理值比如 4避免多个请求同时进来时内存被吃穿。工具链接入方面很多开发者把 DeepSeek 接到编辑器里用。常见做法是通过 Continue 或 Cline 这类插件配置里指定baseUrl和model指向 DeepSeek 的 API。这样写代码时的补全和解释就用自己的模型跑了私密性和成本都可以拿捏。5. 避坑手记DeepSeek 实操中最常见的五个翻车现场5.1 给推理模型叠角色扮演输出反而变空洞现象给 DeepSeek-R1 加了一个很完整的角色设定「你是一位拥有 20 年经验的首席架构师请分五步设计系统」结果输出变得又长又空推理深度还不如直接提问。原因推理模型已经内化了推理逻辑角色扮演这类启发式提示会干扰它的逻辑主线让它把注意力放在「演好角色」而不是「解决问题」上。资料里明确提醒过不要对推理模型使用启发式提示。解决直接给目标和约束。「设计一个日活百万的电商系统要求给出架构图文本描述、数据库选型和分库分表策略。」去掉角色设定输出质量立刻回来。5.2 通用模型直接做数学证明答案看着对但经不起推敲现象用普通对话模型求「证明勾股定理」它给了三步证明思路看起来完全合理但中间一步跳过了关键的相似三角形推导。原因通用模型的训练目标偏向语言生成不擅长复杂逻辑链路。你直接抛复杂问题时它没有显式的推理链支撑只能根据概率预测拼凑出「像样的答案」。解决拆解步骤显式要求分步思考。「第一步画出直角三角形并标出边长第二步列出相似三角形关系第三步推导平方关系。」每一步验证通过后再让模型继续下一步。5.3 本地部署模型直接 OOM程序秒挂现象在 8GB 显存的机器上直接ollama run deepseek-r1:32b启动没几秒就 OOM进程被杀。原因模型参数量与显存要求不匹配。32B 模型在 FP16 精度下就需要大约 64GB 显存8GB 完全不够跑。解决先看显存选规格。7B 模型量化后大约 4~6GB 显存可以在消费级显卡上跑你还可以用OLLAMA_NUM_PARALLEL1限制并发加载时设置OLLAMA_CONTEXT_LENGTH2048减小 KV 缓存占用。先把小规格跑通再逐步升级。5.4 API 报错 tool calls 相关上下文里的工具消息缺失现象调用 API 开启函数调用功能后请求报错提示类似「messages tool calls need immediate results」模型已经发起了工具调用但它期望的后续内容没有出现。原因OpenAI 兼容模式下的函数调用协议要求当模型返回tool_calls时下一轮对话必须把对应结果以tool角色消息回传。很多新手在第一个消息里收到工具调用就直接结束了会话没有完成回传动作协议就不满足。解决收到tool_calls后构造 role: tool, tool_call_id: 上一步返回的 ID, content: 工具执行结果} 消息追加到消息列表里再发起第二次补全请求。把「模型调用工具 → 工具返回结果 → 模型继续作答」当成一个完整回合来处理就不会断链。5.5 温度调太高代码生成结果完全不可控现象把temperature调到 0.9 让模型写一段排序算法结果它输出了一个能跑但结构混乱的版本注释位置随机甚至有一次把冒泡排序写成了选择排序的变体。原因温度控制采样随机性高温度下模型更倾向探索多样化的表达这在创意任务里是优点但代码生成要求精确性和一致性高温度会让逻辑链条变得不稳定。解决代码生成任务把temperature控制在 0~0.3 区间创意写作再调到 0.7 以上。同一份代码任务跑三次取一致版本是我自己的底线操作。6. 进阶验证用「需求公式 输出检查表」批量验收生成质量入门的人学会写提示语进阶的人学会验收提示语。我的习惯是任何一个重要输出都必须过一遍需求公式和输出检查表。需求公式检查的是提示语本身是否完整——目标、选项、评估标准、约束条件是否都给了输出检查表检查的是模型返回的内容是否真正满足需求。一前一后配合才能在批量化场景里稳定复用。以「决策需求」为例收到模型输出后按以下清单逐条验证是否明确对比了所有提供的选项还是只挑了其中一两个展开。是否使用了你提供的评估标准没有自创一套标准偷换概念。是否给出了推荐结论还是只列了优缺点把决策推回给你。数值计算部分是否可复算关键公式和数据来源是否标注清楚。逻辑上是否有遗漏的成本项比如只算建设成本不算运维成本。验证类需求是另一个容易出彩的地方。让 DeepSeek 验证一份实验数据你可以要求它重新计算 p 值、检查对照组设置是否存在偏差、对比实验数据是否支持结论。这些都是资料里的原话但落实到提示语里要明确要求输出验证过程和原始计算结果而不是一句「支持该结论」了事。写一个脚本把这套验收流程固化下来批量跑效果更好。# 批量验收脚本循环测试用例记录通过率 test_requirements [ {task: 决策需求, prompt_file: prompts/decision.json}, {task: 分析需求, prompt_file: prompts/analysis.json}, {task: 创造性需求, prompt_file: prompts/creation.json} ] for req in test_requirements: responses run_model(req[prompt_file], n3, temperature0.2) # 逐条套用输出检查表打通过/不通过标记 pass_rate sum(check_output(r) for r in responses) / len(responses) print(f{req[task]}: {pass_rate:.0%} 通过)跑批次的建议是每个任务重复 3~5 次取通过率而非单次结果来判断因为随机采样会影响输出波动单次结果说明不了问题。低温度下通过率应该居高如果低于 60%大概率是提示语本身缺了关键参数回去补公式要素不要执着于换说法。我自己的教训是之前依赖单次输出就上线 AI 客服系统结果有一半的回答偏离需求用户投诉不断。从那以后我每次交付一份 AI 生成内容都强制走一遍这套流程先明确需求类型再选模型再套模板写提示语最后逐条对照检查表打分通过率。希望帮到你。本文还有配套的精品资源点击获取