企业官网建设流程全解析

简介：这份PDF资料源自清华大学新闻与传播学院新媒体研究中心团队，面向希望系统掌握DeepSeek大模型的初学者与进阶用户，帮助读者厘清推理模型与通用模型的能力边界，并掌握提示语设计的差异化策略。内容围绕DeepSeek是什么、能做什么、如何使用、如何从入门到精通展开，涵盖文本生成、语义分析与情感识别、代码生成与调试、联网搜索与文件读取等应用场景，并深入对比推理大模型在数学推导、逻辑分析与复杂问题拆解上的优势，以及通用模型在创意写作与多轮对话中的灵活性，同时讨论提示语策略差异与人工智能伦理议题。资源包为1个PDF文件，约5.5MB，结构清晰、图文并茂，便于按章节检索学习。目前已有311人学习，适合作为大模型应用入门与提示语优化的参考读本。

1. 拿到这份 DeepSeek 手册，先别急着翻提示语模板

上周有个做后端的朋友问我，DeepSeek 到底该怎么用才算“用明白”。他手里已经攒了十几个提示语模板，遇到问题还是习惯性打开搜索框。我让他把这份清华团队整理的《DeepSeek 从入门到精通》翻到推理模型和通用模型对比那一页，他看完沉默了一会儿说，原来之前一直在用通用模型的思路去指挥推理模型。

这份手册解决的就是这个错位问题。它不讲 API 怎么调、参数怎么传，而是把 DeepSeek-R1 这类推理模型和 GPT-4 这类通用模型在任务分配、提示语策略上的差异拆开讲清楚，再落到文本生成、语义分析、代码补全这些具体场景。适合两类人：一是天天跟大模型打交道但总觉得输出不稳定的开发者，二是想把 AI 嵌进业务流程、需要判断什么任务该交给哪种模型的产品和运营。手册本身是文档型资源，不是代码包，所以下面我按“怎么读、怎么用、哪里会翻车”来拆。

2. 推理模型与通用模型的分工逻辑：为什么你的提示语总在打架

2.1 两类模型的本质差异不在参数量，在训练目标

手册里把模型分成“概率预测（快速反应）”和“链式推理（慢速思考）”两类，这个分法比单纯说“推理模型更强”要准确得多。DeepSeek-R1 这类推理模型在训练阶段强化了逻辑链，遇到数学推导、代码生成、复杂问题拆解时，它会自动展开中间步骤；而通用模型走的是大规模文本预训练路线，擅长语言生成、多轮对话、开放性问答，但碰到需要严格逻辑链的任务，它不会主动补步骤，你得在提示语里把步骤喂给它。

这个差异直接决定了提示语怎么写。手册里有一句话我划了重点：对推理模型用“启发式”提示，比如角色扮演、分步引导，反而可能干扰它的逻辑主线。我见过有人让 DeepSeek-R1 解一道概率题，提示语写了“请你先画图、再列公式、最后计算”，结果模型被这些外部步骤带偏，中间跳了一步条件概率的推导。换成直接说“证明这个结论”，它自己生成的推理链反而更完整。

反过来，通用模型你不能“过度信任”。直接扔一个复杂逻辑问题过去，它可能跳过关键验证步骤，给出一个看起来合理但经不起推敲的答案。手册里给的对策是显式要求分步思考、提供示例，用提示语补偿它的能力短板。

2.2 任务类型决定模型选择，别按热度选

手册里列了一张任务类型与模型适配的表，我把它整理成下面这个对照，方便你直接对着业务场景查：

这张表的价值在于，它把“选哪个模型”从感觉变成了判断。我自己的习惯是，拿到任务先问一句：这个任务需不需要模型自己把中间逻辑走一遍？需要就走推理模型，不需要就走通用模型。手册里那句“优先根据任务类型而非模型热度选择”看着平淡，实际能省掉大量反复调提示语的时间。

2.3 提示语策略的三种模式与适用边界

手册把提示语策略分成指令驱动、需求导向、混合模式三类，这个分类比常见的“角色+任务+格式”模板更有操作性。指令驱动适合简单任务，比如“用 Python 写一个快速排序函数，输出带注释”，目标明确、步骤清晰，模型不需要自主规划。需求导向适合复杂问题，比如“我需要优化用户登录流程，请分析当前瓶颈并提出三种方案”，你把背景和目标说清楚，让模型自己规划路径。混合模式介于两者之间，给目标也给关键约束，比如“设计一个三日游计划，包含两个指定景点，预算控制在两千以内”。

这里有个容易踩的坑：很多人把需求导向用成了“什么都不说清楚”。手册里强调需求导向也要“清晰定义需求边界”，不是扔一句“帮我优化一下”就完事。我一般会在需求导向的提示语里至少写清三件事：当前状态是什么、期望达到什么、有哪些不能动的约束。这三样缺一个，模型的输出就容易飘。

3. 把提示语落到五类业务需求：从决策到执行的写法拆解

3.1 决策需求与分析需求的提示语结构

手册把业务需求分成决策、分析、创造性、验证、执行五类，每类给了需求表达公式和适配策略。决策需求的公式是“目标 + 选项 + 评估标准”，推理模型适合做逻辑推演和量化分析，通用模型适合直接给建议。举个例子，物流成本优化那个场景，提示语写“现有两种方案：自建区域仓库和第三方合作，请根据 ROI 计算模型对比五年总成本并推荐”，这就是把选项和评估标准都摆出来，让推理模型去算。

分析需求的公式是“问题 + 数据/信息 + 分析方法”。手册里的示例是给一份 CSV 数据，要求说明增长趋势、预测市占率并解释 ARIMA 模型参数。这类提示语的关键是把数据来源和分析方法都写进去，否则模型只能给泛泛的结论。我实际用的时候会再加一句“如果数据不足以支撑结论，请明确指出缺什么”，这一句能挡掉不少硬编出来的分析。

3.2 创造性需求与验证需求的约束写法

创造性需求的公式是“主题 + 风格/约束 + 创新方向”。手册里智能家居产品的例子写得很具体：解决独居老人安全问题、结合传感器网络和 AI 预警、提供三种技术路线的原型草图说明。注意这里“三种技术路线”就是一个硬约束，没有这个数字，模型可能只给一种方案就收尾。创造性任务最怕开放式指令，你给的自由度越大，输出越容易变成正确的废话。

验证需求的公式是“结论/方案 + 验证方法 + 风险点”。手册里的示例是验证一篇论文的结论是否成立，要求检查实验数据、对照组偏差、重新计算 p 值。这类提示语在推理模型上效果明显，因为它需要模型自己设计验证路径、排查矛盾。我一般会把“请列出你不确定的地方”作为固定收尾，让模型把置信度低的部分标出来，比它硬给一个确定答案有用。

3.3 执行需求的步骤约束与输出格式

执行需求的公式是“任务 + 步骤约束 + 输出格式”。手册里 C 语言转 Python 的例子要求保持时间复杂度不变、用 numpy 优化数组操作、输出带时间测试的完整代码。这三条约束分别管正确性、性能和可验证性，缺一条输出质量就下一个台阶。

下面这段是我按手册思路写的一个执行需求提示语，你可以直接改成自己的任务：

# 这不是调用代码，是提示语的结构化写法示例 prompt = """ 任务：将下面这段 Java 数组去重逻辑转换为 Python。 步骤约束： 1. 保持原算法的时间复杂度不变； 2. 使用 Python 内置数据结构优化可读性； 3. 输出完整可运行代码，附带一组测试用例。 输出格式：先给代码块，再给测试结果说明。 原始代码： {java_code} """

这段提示语里，“保持时间复杂度不变”是正确性约束，“用内置数据结构”是实现路径约束，“附带测试用例”是可验证性约束。三条约束各管一个维度，模型不容易在某一个维度上偷懒。参数上唯一要改的是{java_code}占位符，换成你的实际代码。注意别在步骤约束里写“先做什么再做什么”这种过细的指令，执行需求交给推理模型时，过细的步骤反而限制它选更优的实现方式。

4. 本地部署与在线使用的取舍：Ollama 路线的实际边界

4.1 在线入口和本地部署各自适合什么场景

手册里给了两个使用入口：在线对话平台和本地部署（走 Ollama）。在线入口适合快速验证提示语效果、处理不敏感的一般任务，开箱即用，不用管显存和量化。本地部署适合数据不能出内网、需要批量跑任务、或者想固定模型版本做对比实验的场景。

这里要泼一盆冷水：本地部署的体验和在线版本不是一回事。Ollama 拉下来的模型经过量化，推理质量和在线满血版有差距，尤其是长链推理任务，量化后的模型更容易在中途丢步骤。我一般建议先用在线版把提示语调稳定，确认任务类型和提示语策略匹配之后，再考虑本地部署。顺序反了的话，你会把量化带来的质量下降误判成提示语写得不好，来回改提示语，白折腾。

4.2 Ollama 拉取与运行的实操步骤

本地部署的常见做法是走 Ollama，步骤不复杂，但有几个参数值得说清楚：

# 拉取模型，具体 tag 以你本地 Ollama 支持的版本为准 ollama pull deepseek-r1 # 运行并进入交互 ollama run deepseek-r1 # 如果要调上下文长度，用参数覆盖，默认值偏小 ollama run deepseek-r1 --parameter num_ctx 8192

num_ctx这个参数是本地部署最容易忽略的一个。默认上下文窗口偏小，你贴一段长代码或者长文档进去，超出部分会被截断，模型的表现就会莫名其妙地变差。处理长文本任务时把它调到 8192 甚至更高，具体上限看你机器的显存。另一个要留意的是温度参数，推理模型做逻辑任务时温度调低一些输出更稳定，创意任务再调高，这个和在线版的调节逻辑一致。

4.3 本地部署的质量验证方法

本地跑起来之后别急着上生产任务，先做一轮对照验证。我的做法是拿同一组提示语，分别跑在线版和本地版，对比三类输出：逻辑链是否完整、代码是否能直接运行、长文档摘要是否漏掉关键段落。如果本地版在逻辑链上明显短一截，大概率是量化损失或者上下文截断，先调num_ctx再考虑换更大的模型版本。这个验证步骤花不了多少时间，但能帮你把“模型能力问题”和“部署配置问题”分开，后面排查起来有方向。

5. 避坑：提示语和模型选型里最容易翻车的四件事

5.1 对推理模型做角色扮演，逻辑链反而断了

现象：给 DeepSeek-R1 加一句“你是一位资深数学教授”，让它解一道证明题，输出的推理步骤比不加角色时还少。

原因：推理模型的推理链是训练阶段内化的，外部角色设定会引入额外的语义引导，干扰它原本的推理主线。手册里明确写了不要对推理模型用启发式提示。

解决：逻辑类任务直接抛问题，最多补一句输出格式要求。角色扮演留给通用模型做创意任务用。

5.2 通用模型直接问复杂推理，答案看着对但经不起验算

现象：用通用模型算一个多步概率问题，它给了一个结构完整的答案，但中间某一步的条件概率用错了，最后结果偏差很大。

原因：通用模型不主动展开验证步骤，它按概率预测下一个 token，看起来连贯不等于逻辑正确。

解决：要么换推理模型，要么在提示语里显式要求“分步推导并标注每一步的依据”。手册里“缺什么补什么”说的就是这个。

5.3 本地部署上下文截断，长文档摘要漏关键段

现象：本地 Ollama 跑长报告摘要，输出只覆盖了前半部分，后半部分的核心结论完全没提。

原因：num_ctx默认值偏小，超出窗口的内容被静默截断，模型根本没见过后半段。

解决：调大num_ctx，或者在提示语里要求模型先确认收到了完整文档再开始摘要。后者是个低成本的保险，模型会告诉你它实际看到了多少内容。

5.4 提示语约束堆太多，模型顾此失彼

现象：一条提示语里写了七八条约束，输出满足了格式要求，但核心任务的正确性反而下降。

原因：约束之间可能互相冲突，比如既要求“简洁”又要求“覆盖所有边界情况”，模型只能做取舍，取舍的结果往往牺牲正确性。

解决：按手册的五类需求公式，每类需求抓两到三条关键约束，正确性约束优先于格式约束。格式问题可以后处理，正确性问题后处理不了。

6. 用对照实验把提示语调稳：一个可复用的验证习惯

提示语调优最怕的是“改完感觉好了一点”，没有对照就没有判断。我现在的习惯是，每类业务需求固定准备三组提示语：一组按手册的公式写，一组加角色设定，一组只给最简指令，然后拿同一批输入跑一遍，按正确性、完整性、格式合规三个维度打分。这个做法不复杂，但能把“玄学调参”变成有记录的对比。

具体操作上，我会建一个表格，每行是一组提示语，每列是一个测试用例，单元格里填通过或不通过。跑完一轮，哪组提示语在哪个用例上翻车一目了然。手册里那张“任务类型与提示语策略”的对照表可以直接当评分标准的底稿，比如推理模型的任务就看逻辑链是否完整，通用模型的任务就看约束是否被遵守。

还有一个细节值得说：验证提示语的时候，输入样本要覆盖边界情况，不能只拿正常数据跑。我吃过亏，一组提示语在正常输入上表现很好，换成一个字段缺失的输入就直接编数据。从那以后我每次调完提示语，都强制走一遍“缺字段、超长文本、格式错乱”这三类异常输入，确认模型是明确说“信息不足”而不是硬编。这个习惯比任何模板都管用。

手册里关于 AI 伦理的那部分讨论，落到实操上其实就是一句话：推理模型作为受控工具，它的输出需要人来验证，尤其是验证类和分析类任务，别把模型的结论直接当最终结论用。希望这份拆解帮到你，少走几轮来回改提示语的弯路。

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