企业官网建设流程全解析

简介：这份《DeepSeek从入门到精通》由清华大学新闻学院与人工智能学院团队编写，面向希望系统掌握国产开源推理模型的研究人员、开发者与AI应用从业者。内容从DeepSeek的背景与能力边界讲起，逐层展开智能对话、文本生成、语义理解、代码生成与调试等应用场景，并重点剖析DeepSeek-R1的推理特性，通过推理模型与通用模型的维度对比，说明各自优势领域与选型原则。提示语设计部分尤为充实，涵盖指令驱动、需求导向、混合模式与启发式提问等策略，并给出数学证明、创意写作、代码生成等任务下的有效提示与应避免的写法，最后落到从「下达指令」到「表达需求」的思维转变。压缩包内仅含1个PDF文件，约5.4MB，按章节编排、图文对照，便于通读与按需查阅，目前已有3005人学习。

1. 一份九十页的手册值不值得下：先摸清 DeepSeek 的能力边界

翻这份《DeepSeek 从入门到精通》之前，我以为又是一份产品介绍拼盘，读到第三部分才改观：它把「选哪个模型、提示语怎么写、需求怎么表达」这三件事拆成了能照着填的表格，而不是泛泛讲 AI 多强。它讲的是 DeepSeek-R1 这类开源推理模型的能力边界——文本生成、语义理解、知识推理、代码补全，外加联网搜索、深度思考和文件上传读图识字。适合每天要出稿、出方案、出代码，把模型当生产工具的人；不适合找微调脚本、推理部署、量化加速的人，手册里没有这些工程侧内容，这一点它自己也没藏着。后面几章我按「选型—提示语—需求表达—避坑」这条线，把它里面真正能抄作业的部分拆出来。

2. 推理模型与通用模型：两条技术路线怎么选、提示语差在哪

2.1 CoT 链式思维把大模型劈成了两半

手册里最有价值的一张图，是把模型按 CoT（Chain-of-Thought，链式思维）分成两类：一类靠概率预测快速给答案，一类靠链式推理逐步推演。这个分法不新鲜，但它把两类模型在七个维度上的差异列成了对照表，而且列得很实在——不是「谁更强」，而是「谁在哪类任务上更强」。这对一线使用者的意义在于：你手上 80% 的翻车，根本不是模型不行，是拿创意任务的写法去问数学题，或者拿数学题的写法去要文案。

这张表要横着读，不要竖着读。竖着读会得出「推理模型全面更强」的错误结论，而手册在正文里明确写了：推理模型的劣势领域是发散性任务，比如诗歌创作；通用模型的劣势是需要严格逻辑链的任务，比如数学证明。所谓「强弱判断」，结论是「并非全面更强，仅在其训练目标领域显著优于通用模型」。这句话我建议贴在显示器边上，它能挡掉一半「换个更贵的模型就解决了」的冲动。

再往下看一层，手册把两类模型的提示语策略差异点破了：推理模型已经把推理逻辑内化了，提示语只需要明确任务目标和需求，不需要逐步指导，模型会自动生成结构化的推理过程——你强行拆解步骤，反而可能限制它的能力。通用模型相反，它依赖提示语补偿能力短板，你得显式引导推理步骤，否则它可能跳过关键逻辑。这条差异是我在实战里踩得最狠的一处，后面 2.3 会拿具体例子对照。

2.2 选型对照表：先看任务类型，再看模型热度

手册给了一张「任务需求与提示语策略」的对照表，覆盖数学证明、创意写作、代码生成、多轮对话、逻辑分析五类典型任务。我按自己的使用习惯重排了一下，把「要避免的提示策略」这一列提前，因为这一列才是真正省钱的部分——写错了不是效果差一点，是整轮重来。

选型有个比表格更快的判断法，我一般按三条过一遍。第一条，这个任务的中间步骤需不需要自洽可查？比如数学推导、代码逻辑、多步决策，答案是要，那就上推理模型。第二条，输出能不能一眼验对？文案、命名、头脑风暴这类没有唯一答案的任务，验对成本高，通用模型反而更灵活。第三条，失败代价多大？如果错了要返工半小时以上，优先推理模型；如果错了改两个字就行，用快的那个。这三条比背模型榜单有用，因为榜单三个月一换，任务形态几年不变。

这里要提醒一个容易上头的地方：推理模型不是「更聪明的通用模型」，它是「为特定目标重新训练过的模型」。手册里那句「通用场景更灵活，但专项任务需依赖提示语补偿能力」反过来也成立——推理模型在专项任务上强，在开放场景里反而容易被自己的推理链绑住。我见过有人拿推理模型写营销短句，出来一股论文摘要味，这就是用错了地方。

2.3 提示语策略的差异落地：推理模型给目标，通用模型给台阶

理论说完，落到能抄的写法。同一个需求，两类模型的提示语结构完全不同，下面这组对照可以直接套。

左边那一列看着「敷衍」，其实是有意为之。推理模型的目标是让它自己规划路径，你给的步骤越细，它越可能把你的中间步骤当成硬约束，反而绕开更优的解法。右边那一列看着啰嗦，是因为通用模型本身没有内化的推理链，你必须把台阶一级一级铺出来，它才走得稳。

还有一种情况手册没写透，但实战里很常见：混合任务。比如「分析这份销售数据并给出三条可执行建议」，前半段是分析（要推理），后半段是建议（要发散）。我一般拆成两轮：第一轮用推理模型跑分析，拿到结论和依据；第二轮把结论丢给通用模型做发散，让它给方案。硬塞进一条提示语里，模型往往在「分析不够深」和「建议太笼统」之间二选一。这种拆分不增加多少成本，但输出质量差一个档。

3. 提示语设计的三层结构：指令、上下文、期望怎么写才不塌

3.1 提示语的本质与六种类型

手册对提示语的定义很朴素：用户输入给 AI 系统的指令或信息，用于引导 AI 生成特定输出或执行特定任务。它把这个东西的本质拆成四个角色——沟通桥梁（连接人类意图和 AI 理解）、上下文提供者（给 AI 必要背景）、任务定义器（明确要完成什么）、输出塑造器（影响输出形式和内容），外加一个能力引导器（引导 AI 调用特定能力）。这五个角色解释了为什么同一句话，加不加背景，输出差很远。

类型上它列了六种，我按使用频率排了序，并补了各自的失效场景：

这里有个和 2.1 呼应的点：角色扮演型提示语在通用模型上是好用的技巧，在推理模型上却可能变成干扰项，手册原话是「不要对推理模型使用启发式提示（如角色扮演），可能干扰其逻辑主线」。所以类型本身没有优劣，要看你把哪类模型摆在对面。

3.2 三层结构的写法：指令要动词开头，上下文要给约束，期望要可验收

手册把提示语拆成指令、上下文、期望三层。这个拆法不复杂，但每一层都有具体的写法讲究，光知道三层没用，得知道每层写多少、写什么。

指令层的要求是「动词开头，一条指令一个任务」。常见错误是把三个任务塞进一句话，比如「帮我分析这份报告，顺便改一下格式，再想个标题」。模型会挑最容易的那个做，剩下的糊弄过去。正确做法是拆成三轮，或者至少在主指令后明确优先级。

上下文层是三层里最容易偷懒、也最影响结果的一层。手册给的示例是「假设你是一位十九世纪的历史学家，评论拿破仑的崛起」，这里的角色设定就是上下文。实际工作里，上下文至少包含四类信息：背景（这件事的来龙去脉）、数据（要处理的原素材）、约束（预算、字数、格式、不能出现什么）、读者（输出给谁看）。四类里缺两类以上，输出基本要靠运气。

期望层的关键词是「可验收」。不要说「写得好一点」，要说「不超过 200 字、三段、每段一个论点、不出现专业术语」。可验收的标准有个简单测试：把输出拿给同事看，他能不能在不问你的情况下判断合格与否。能，就是可验收；不能，就是没写清。

把三层拼起来，我常用的填空模板是这样：

指令：用 [动词] 完成 [具体产出物]，面向 [读者]。 上下文：背景是 [一句话交代来龙去脉]；素材是 [粘贴数据或说明文件]；约束是 [字数/格式/禁用内容/预算范围]。 期望：输出 [结构，如三段式/表格/编号列表]，每部分包含 [要素]，总长度 [范围]，验收标准是 [能否被直接使用]。

这个模板不是让你每次都写满，而是让你每次写完检查一遍：三层里哪层是空的？空的那层，就是输出质量的天花板。

3.3 三种策略模式：指令驱动、需求导向、混合模式

手册把提示语策略分成三种模式，这个分法比「好提示语/坏提示语」的二分有用得多，因为它承认了不同场景需要不同写法。

三种模式对应三种失败形态，这也是我踩过的：指令驱动用过头，模型变成一个执行器，遇到它没见过的边界就卡死，不会自己找路；需求导向用过头，模型自由发挥，输出看着漂亮，跟你真正要的东西偏了十万八千里；混合模式最难写，约束给少了等于需求导向，给多了等于指令驱动，中间那条线得靠试。

手册里那句总结我认为是整份文档的题眼：从「下达指令」到「表达需求」。这不是文风问题，是协作姿态的转变——你把模型当执行器，它就只能做你想到的事；你把模型当协作者，它才可能补上你没想到的部分。当然前提是需求边界说清楚，否则协作变成放羊。

4. 五类需求的需求表达公式：决策、分析、创造、验证、执行怎么写

4.1 需求类型与公式对照表

这一节是手册里最能直接抄的部分。它把日常需求分成五类，每类给了一个表达公式，并配了适配策略。我把公式和适配差异合并成一张表：

这张表的价值在于「公式」那一列。大部分人的提示语是想到哪写到哪，而公式把「必须有的要素」固定下来了——决策必须有选项和评估标准，分析必须有数据和方析方法，验证必须有结论和验证路径。缺一个要素，输出就会在缺的那块上飘。

4.2 逐类拆解：每条公式里哪部分是必需的、哪部分能省

决策需求。公式是「目标 + 选项 + 评估标准」，三个都不能省。手册给的示例是「为降低物流成本，现有两种方案：自建区域仓库（初期投入高、长期成本低）；与第三方合作（按需付费、灵活性高）。请根据 ROI 计算模型，对比 5 年内的总成本并推荐最优选择」。这段的关键是评估标准写死了——ROI、五年、总成本，模型才知道该往哪个方向算。如果只写「哪个方案更好」，它会给你一段正确的废话。

分析需求。公式是「问题 + 数据 + 分析方法」。示例里明确要求「使用 ARIMA 模型并解释参数依据」，这就是把方法锁定了。我的经验是，分析需求里最容易被省略的是数据，很多人贴一句「分析一下最近的销量」，指望模型自己知道数据在哪。正确做法是把 CSV 内容或数据摘要直接贴进去，并说明字段含义，否则模型只能编。

创造性需求。公式是「主题 + 风格/约束 + 创新方向」。示例是「设计一款智能家居产品，要求：解决独居老人安全问题；结合传感器网络和 AI 预警；提供三种不同技术路线的原型草图说明」。三个要求分别对应主题、技术约束、产出形式，缺了第三项，你拿到的就是一段产品愿景而不是可讨论的方案。

验证需求。公式是「结论/方案 + 验证方法 + 风险点」。示例是「某论文结论：神经网络模型 A 优于传统方法 B。请验证：实验数据是否支持该结论；检查对照组设置是否存在偏差；重新计算 p 值并判断显著性」。这类需求用的人少，但价值高——它把模型从「生成答案」切换成「审查答案」，同一个模型换个站位，能挑出你自己漏掉的问题。

执行需求。公式是「任务 + 步骤约束 + 输出格式」。示例是「将以下 C 语言代码转换为 Python，要求：保持时间复杂度不变；使用 numpy 优化数组操作；输出带时间测试案例的完整代码」。三项约束分别锁住了性能、实现方式、交付物形态，这才叫可执行。

4.3 把公式拼成一条完整提示语，并用脚本批量跑

单条提示语好写，难的是同一个任务要跑几十遍、还要比较哪版更好。我一般写个小脚本批量跑，把两种写法的输出拉出来对照。下面这段是常见的调用方式，用 OpenAI 兼容接口，模型标识和参数以官方文档当前列表为准：

from openai import OpenAI import json client = OpenAI( api_key="你的API_KEY", base_url="https://api.deepseek.com", # 接口地址以官方文档为准 ) # 同一个任务，两种提示语写法：A 为指令驱动，B 为需求导向 PROMPTS = { "A_指令驱动": "写一个 Python 函数，读取 CSV 并计算某列均值。", "B_需求导向": ( "背景：我有一份销售明细 CSV，字段为 date、sku、qty、price，" "其中 qty 存在空值。目标：算出每个 sku 的月度销量均值。" "请先说明你如何处理空值和日期格式，再给出完整可运行代码，" "要求不依赖 pandas 以外的第三方库，并附一个最小测试用例。" ), } def run(prompt: str, model: str = "deepseek-chat", temperature: float = 0.3): resp = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=temperature, # 采样温度，越低越稳定；推理模型侧该参数常被忽略 max_tokens=1200, # 单次输出上限，防止长回答截断关键代码 ) return resp.choices[0].message.content if __name__ == "__main__": result = {} for name, p in PROMPTS.items(): result[name] = run(p) with open("compare.json", "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2) print("done")

这段脚本干的事很简单：把两种写法的提示语放进字典，循环调用，结果落成 JSON 方便人工比对。几个参数值得说清楚。model决定走哪条技术路线，切到推理模型时建议把temperature保留在默认值附近，因为这类模型的采样参数往往不生效，调它属于玄学操作；max_tokens别设太小，代码类输出被截断在中途，你会以为是模型能力问题；base_url换成兼容端点就能接别的服务，脚本本身不用改。

跑完拿到 JSON，别急着看谁的字数多，按三个维度打分：能不能直接运行、有没有处理边界（空值、异常格式）、解释部分是否说清了取舍。我自己的经验是，指令驱动那版通常代码更短、跑得更快，但边界处理基本靠猜；需求导向那版啰嗦，却会把「空值怎么算」这种你没想到的问题提前摆出来。这个对照过程跑上十次，你对自家任务的提示语手感就出来了。

5. 避坑与排查：五条踩过的坑和一套自检清单

5.1 五个坑：现象、原因、解决

坑一：对推理模型写了一大段角色扮演，输出反而变差。现象是加了「你是一位资深分析师」之后，回答开始绕圈，逻辑链断在中途。原因是推理模型内化了推理逻辑，角色设定属于启发式提示，会干扰它的逻辑主线。解决办法是把角色删掉，只留任务目标和约束条件，你会发现输出更干净——这也是手册里明确写的一条：不要对推理模型使用启发式提示。

坑二：拿通用模型直接问复杂推理题，答案看着对，一验就错。现象是数学推导或方案评估里，中间某一步凭空跳过去，结论却很像那么回事。原因是通用模型走概率预测路线，缺乏内化的推理链，遇到需要严格逻辑链的任务会跳过关键步骤。解决办法有两个：换推理模型，或者在提示语里显式要求分步思考并给出示例，让它按你铺的台阶走。

坑三：提示语三层只写了一层，输出飘。现象是模型回答「正确但没用」，说了等于没说。原因是指令写清了，上下文和期望是空的，模型不知道背景、不知道给谁看、不知道什么算合格。解决办法是套用 3.2 的填空模板过一遍，重点补约束和验收标准这两项，通常补完输出质量立刻上一个档。

坑四：验证类需求当成生成类需求提。现象是让它「检查一下这个方案有没有问题」，它回你一段「这个方案整体不错，建议注意以下几点」的客套话。原因是没给验证路径，模型只能按生成任务的习惯走。解决办法是把公式用全：给结论、给验证方法、指明风险点，比如「请检查对照组设置是否存在偏差，并说明判断依据」，它才会真的去挑刺。

坑五：把文件上传当万能入口。现象是传了扫描件或复杂表格，模型读出来的数字和原文对不上。原因是文件上传依赖文字识别质量，扫描模糊、表格跨页、公式图片都会掉信息。解决办法是传之前先确认关键数字，重要数据在提示语里再复述一遍，别指望它 100% 还原——这一步花两分钟，能省掉后面半小时的返工。

5.2 上线前的自检清单

这套清单我贴在便签上，每次写长提示语之前过一遍，比事后调试省事：

清单里最容易忽略的是「是否过度约束」。很多人学会写详细提示语之后，会把每一步都写死，结果模型变成一个高级模板填充器，遇到模板外的输入直接崩。判断标准很简单：如果你的提示语详细到「换个人照着做也能完成」，那模型的价值就只剩打字速度了。

6. 进阶：用十条小样本把提示语调稳

提示语调优最大的问题是没法验证。你觉得改完更好了，可能只是这一条更好。我的做法是建一个十到二十条的小样本集，固定下来反复跑，每次改提示语都过一遍，看总分是涨还是跌。

样本集的字段别搞复杂，五列够用：任务编号、原始需求、期望输出要点、禁用内容、人工评分（一到五分）。构造样本时注意两点：一是覆盖边界，比如空数据、格式错误、超长输入各放一条；二是留两三条「应该拒答或反问」的样本，用来检查模型有没有在不该编的时候硬编。这两类样本最能暴露提示语的漏洞。

评分环节别偷懒用模型自评，模型给自己打分普遍偏高。我一般人工快速过一遍，只打三个档：能直接用、改两句能用、得重写。二十条样本十分钟能过完，比你反复调一条提示语靠谱得多。跑完把低分样本单独拎出来，看它们是不是集中在某一类需求上——如果都集中在验证类，说明你的验证公式没写全；如果都集中在创造性需求，说明约束给多了。

还有个细节：换模型之后样本集要重跑，别拿旧结论套新模型。同一套提示语在推理模型和通用模型上的表现差异，前面几章已经说透了，样本集就是用来量化这个差异的工具。

从那以后我每次要长期用一条提示语，都强制先跑一遍这二十条样本，哪怕只有五分钟。血泪经验是，省下这五分钟，后面往往要花两小时收拾一个「看着能用其实到处漏」的模板。这份手册我最后留在硬盘里的，就是那几张对照表和这套需求公式，别的看过一遍就够了。希望帮到你。

本文还有配套的精品资源，点击获取