企业官网建设流程全解析

简介：这份由清华大学新闻与传播学院新媒体研究中心团队整理的 PDF 文档，面向希望系统理解 DeepSeek 与国产大模型应用的初学者、开发者、内容创作者和技术管理者，帮助厘清模型能力边界、适用任务与提示语设计方法。资料围绕 DeepSeek-R1 的开源推理特性，讲解智能对话、文本生成、语义理解、计算推理、代码生成与文件读取等场景，并重点对比推理模型与通用模型在优势领域、性能本质、决策方式和创造力上的差异，延伸到链式思维、快思慢想及任务需求与提示语策略匹配。压缩包内共 1 个 PDF 文件，约 4.8MB，便于集中阅读和检索。已有 2431 人学习下载，适合用来建立从模型选择、提示语撰写到常见误区规避的入门框架，也可作为团队培训与技术选型时的参考材料。

1. 一份讲 DeepSeek 的 PDF，为什么值得占掉一个下午

很多人手机里躺着 DeepSeek 的账号，每天也问几句，但输出质量忽高忽低，说不清问题出在哪。这份《DeepSeek：从入门到精通》出自某高校新媒体研究团队的内部讲义，把“DeepSeek 是什么、能做什么、怎么用”拆成三层：模型能力边界、提示语策略、需求表达方式。它不教部署，也不讲 API 调用，真正有价值的是把“同一个问题换个问法，结果差一倍”这件事，落成了可以照抄的规则表。适合已经在日常工作中用对话模型、但还没形成自己方法论的人。

2. 推理模型与通用模型：R1 和对话模型的分工线画在哪

绝大多数人用不好 DeepSeek，根源不在提示语写得丑，而在第一步就选错了模型。把需要严格逻辑链的任务丢给通用模型，它会跳过关键推导直接给结论；把创意发散的活交给推理模型，它会把一首诗写成工程说明书。这份材料把两类模型的差异讲得比较透，值得先花时间把这条线画清楚，后面所有提示语技巧都建立在这条线上。

2.1 快思慢想：差别不在参数量，在愿不愿意在答案前花 token

通用模型走的是概率预测路线，本质是给定上下文预测下一个最可能的词，训练目标是拟合语言的分布，所以响应快、算力成本低，擅长文本生成、创意写作、多轮对话这类多样性高的任务。推理模型走的是链式推理路线，在给出最终答案之前先生成一段较长的中间推导，把“怎么想”本身当作可优化的对象，用强化学习一类手段去打磨这条推理链，因此在数学推导、逻辑分析、代码生成、复杂问题拆解上明显更强。

这里有个容易误解的点：推理模型不是“更聪明的通用模型”，而是“训练目标不同的专用模型”。它在自己训练目标覆盖的领域显著领先，在发散性任务上反而可能吃亏。反过来，通用模型在开放场景更灵活，但碰上需要严格逻辑链的数学证明，就得靠提示语把步骤补回去。材料里用“快思慢想”概括这对关系，我认为比“强弱”这种说法准确得多——快模型负责即时反馈和结构明确的问题，慢模型负责需要逐步推演的问题。

这张表建议直接截图存下来，接到任务先对一眼。我自己的经验是，凡是最终答案能被验证对错的（算出一个数、跑通一段代码、证明一个命题），优先推理模型；凡是最终答案只有好坏没有对错的（文案、命名、方案脑暴），优先通用模型。

2.2 任务分流：把“选哪个模型”变成一张可查的表

光知道原理不够，落到日常得有判断动作。材料给的原则是“优先根据任务类型而非模型热度选择”，这句话看着平淡，实际能省下大量返工。下面是按常见工作场景整理的分流表，判断依据一栏是关键——它决定了你在结果不对时该换模型还是改提示语。

分流的核心不是“谁更强”，而是“这个任务的失败模式是什么”。逻辑任务的失败模式是“步骤跳步导致结论错”，所以要推理模型；创意任务的失败模式是“千篇一律”，所以要通用模型的多样性。搞清失败模式，选型就不会摇摆。

2.3 用一次小实测把边界摸出来

别人的分流表只能当起点，自己业务里的边界要靠实测。我的做法是固定三个任务，两类模型各跑一遍，记录四个观察点。三个任务分别覆盖：一个可验证的数值/逻辑任务（比如让它核算一段带条件的成本）、一个纯创意任务（比如给同一个产品写五条不同风格的短文案）、一个半结构化的代码任务（比如把一段脚本改写成带异常处理的版本）。四个观察点是：答案是否可验证、输出里是否自带推导、你需要改几轮才能用、单次响应耗时。

跑完这一轮，你会得到一张只属于自己的对照表。我一般会把结论写成一句话贴在笔记顶部，比如“凡是带金额核算的需求一律走推理模型，凡是写标题一律走通用模型”，避免每次重新纠结。

提示：实测时不要换提示语，两类模型用同一句话跑，否则测出来的是提示语差异，不是模型差异。

3. 提示语的双轨写法：同一件事，两种模型要两套说法

画完模型分工线，第二个高频翻车点就来了：很多人一套提示语模板用到底，对推理模型和对通用模型说一样的话。材料里明确写了，两类模型的提示语策略是相反的——对推理模型要“要什么直接说”，对通用模型要“缺什么补什么”。这一章把双轨写法拆开讲，顺便回答那个老问题：模型越来越强，还要不要学提示语。

3.1 提示语的三段结构：指令、上下文、期望

不管写给哪类模型，一条合格的提示语都包含三块。指令是核心，明确告诉模型执行什么任务；上下文提供背景，让它理解边界和前提；期望则明确输出要求，包括格式、长度、语气、是否要给出依据。材料把提示语的角色拆成三个：沟通桥梁（把人类意图翻译成模型能懂的表述）、任务定义器（明确要完成什么）、输出塑造器（影响输出的形式和内容）。

三段结构是最小可用集。我自己的习惯是先写指令，写完检查一遍“这句话里有没有两个动词”，有就拆开；再补上下文，重点补那些“我以为是常识但模型不知道”的信息；最后写期望，把输出格式当成接口来约定。

3.2 对推理模型：要什么直接说，别替它安排思路

推理模型已经把推理逻辑内化了，它会在内部自动展开推导。这时候你再写“请一步步思考”“先分析再总结”，反而可能干扰它的逻辑主线，让它去演一个“思考的样子”，输出变长却不一定更准。材料里的原话是“推理模型提示语更简洁，只需明确任务目标和需求，因其已内化推理逻辑；无需逐步指导，模型自动生成结构化推理过程”。

反例和正例对照会直观很多：

规律很清楚：推理模型缺的不是方法，是清晰的目标。你越替它规划路径，它越容易在你划的框里打转。要注意的是“简洁”不等于“含糊”，输入输出的边界、数据的口径、代码的运行环境，这些该给的还得给，只是不给推理步骤。

3.3 对通用模型：缺什么补什么，把步骤显式写出来

通用模型的短板正好相反：它不会自动展开严格推理，遇到复杂问题容易跳过关键环节直接给结论。所以提示语要做的是补偿性引导——显式要求分步思考，提供示例，把输入输出格式定死。材料里给的说法是“依赖提示语补偿能力短板，如要求分步思考、提供示例”。

具体动作有三个。第一，把复杂问题拆成有序的子问题，要求按顺序回答；第二，给一个输入输出样例，让它照格式填；第三，明确要求“先列假设，再给结论，最后说明结论成立的条件”。这三招在文案类、摘要类、多轮对话类任务里都稳。

这里有个边界要提醒：补偿性引导加得太多，会把通用模型逼成一台填空题机器，创意类任务反而会僵。所以补偿只针对“结构性缺失”，不针对“创意空间”。

3.4 六类提示语：知道什么时候用哪一种

材料把提示语分成六类，实际用起来，这六类不是并列选项，而是对应不同的任务形态。

关于“还要不要学提示语”这个问题，材料的态度很清楚：要学，但重心变了。过去学的是措辞技巧，现在学的是需求定义——把模糊的“帮我写个好点的方案”变成“目标、约束、评估标准”三件套。模型越强，措辞的重要性越低，需求清晰度的重要性越高。这个判断我认同，后面一章基本就是围绕“怎么把需求说清楚”展开。

4. 需求表达的五个类型：从“下指令”换成“提需求”的具体改法

提示语写得再工整，如果需求本身是模糊的，输出一定是飘的。材料里最有实操价值的部分，是把日常需求归成五类：决策、分析、创造性、验证、执行。每一类都有对应的表达公式和适配策略，而且推理模型和通用模型的适配方式不一样。这一章把五类逐一拆开，每类给公式、给正例、给反例。

4.1 决策需求与分析需求：把评估标准和数据一起递过去

决策需求的公式是“目标 + 选项 + 评估标准”。缺任何一块，模型就只能给你一段正确的废话。它的特点是需要权衡、评估风险、选出最优解，所以推理模型在这里更合适——它能把每个选项的成本收益摊开算。通用模型的策略是直接给建议，依赖经验归纳，适合你只想听个倾向性意见的时候。

一个可以直接抄的写法是：“为降低仓储成本，现有两种方案：一是自建区域仓，初期投入高、长期单件成本低；二是与第三方合作，按需付费、灵活性高。请按五年总成本口径对比，列出各自的盈亏平衡点，并给出推荐及理由。”这里“五年总成本口径”就是评估标准，模型有了它才不会各说各话。

分析需求的公式是“问题 + 数据/信息 + 分析方法”。它的目标是发现模式或因果关系，需要深度理解材料，所以要附上原始数据，并要求模型说明分析路径。推理模型的适配策略是触发因果链推导和假设验证，通用模型则容易停在表层总结。我的习惯是明确写“先描述现象，再给可能的因果解释，最后说明哪些结论需要补充数据才能确认”，这三段能有效压住模型的过度归纳。

4.2 创造性需求与验证需求：约束边界，而不是约束过程

创造性需求的公式是“主题 + 风格/约束 + 创新方向”。这类任务交给通用模型更合适，因为它的多样性更强；推理模型在这里容易把创意写成结构化的分析报告。关键是约束要落在边界上，不要落在过程上——你可以规定读者、语域、字数、禁用词，但不要规定“第一段写什么、第二段写什么”。

验证需求的公式是“结论/方案 + 验证方法 + 风险点”。这类任务最容易被忽略，很多人拿到一个结论就直接用了，没让它自证。正确做法是要求模型自己设计验证路径并排查矛盾，比如给一段结论，让它检查数据是否支持、对照组是否有偏差、关键指标是否需要复算。这类任务推理模型优势明显，因为它愿意把验证过程展开。

4.3 执行需求：把输出格式当成接口来写

执行需求的公式是“任务 + 步骤约束 + 输出格式”。它的特点是要求严格按指令执行、不需要模型自主发挥，典型场景是格式转换、批量改写、代码翻译。这类需求最忌讳“你看着办”，因为执行类任务一旦自由发挥，结果就没法批量使用。

写法上，我一般把输出格式写成类似接口约定的形式：字段有哪些、顺序如何、空值怎么表示、单位是什么、要不要表头。比如把一段 C 代码转成 Python，除了语言要求，还要约定“保持时间复杂度不变、用 numpy 优化数组操作、附一个带耗时对比的测试用例”。这三条一给，输出就基本能直接用。

五类需求不是互斥的，一个真实任务往往是“分析 + 决策”或者“验证 + 执行”的组合。处理办法是拆开写：先用分析需求拿到结论，再用决策需求做选择，最后用执行需求落成具体产物。一条提示语里塞两种需求，模型通常只会认真执行后半段。

5. 避坑：五类翻车现场与排查顺序

前面几章讲的是怎么用对，这一章讲的是用错了长什么样。下面五条是我在实际使用和整理这份材料过程中反复遇到的，每条按“现象—原因—解决”写，建议对照自己的使用习惯过一遍。

第一条：对推理模型写“请一步步思考”，输出变长但准确率没升。现象是回答里出现了大量“首先、其次、最后”的套话，推导看着完整，关键步骤却是空的。原因是推理模型本身已经在内部展开推理，外部再要求它表演思考过程，等于让它把算力花在组织语言上，而不是解题上，材料里把这个叫“干扰其逻辑主线”。解决办法是把提示语砍到只剩任务目标和必要约束，把“怎么想”交还给模型；如果确实需要看到推导，改成“给出结论并附关键步骤”，而不是“请一步一步思考”。

第二条：拿通用模型直接问复杂计算，答案看着合理但数字是编的。现象是它给出一段流畅的推导，中间某个环节的数突然对不上，你回头验算发现它压根没算。原因是通用模型侧重语言生成，不强调深度推理，遇到多步计算容易跳步，用语言合理性替代数值正确性。解决办法有两个方向：换推理模型，或者在通用模型上做补偿性引导——要求分步、给出计算口径、要求每一步标注数据来源，最后加一句“如某步缺少数据请明确说明，不要假设”。

第三条：一条提示语里塞了互相冲突的约束，输出两头不靠。现象是你要求“专业严谨”又要求“通俗易懂”，要求“控制在 200 字”又要求“覆盖五个方面”，结果模型挑了几个做，其余忽略。原因是约束之间本身存在张力，模型不会告诉你它做了取舍，只会静默降级。解决办法是先给约束排优先级，明确写“优先保证哪一条，其余可放宽”；或者拆成两轮，第一轮出全量内容，第二轮做压缩和改写。

第四条：把“分析”当“执行”提，模型只能靠猜。现象是你说“分析一下这份销售数据的问题”，它给了一堆放之四海皆准的建议。原因是你没给数据，也没给分析口径，模型只能用通用常识填空。解决办法是按分析需求的公式补齐“问题 + 数据 + 分析方法”，把原始数据或关键指标附上，明确要求“结论必须能追溯到具体数据行”；如果数据敏感不能全给，就给统计口径和几个典型样本。

第五条：长文档直接整篇丢进去要摘要，细节全丢。现象是摘要里出现原文没有的表述，或者把关键数字记错。原因是长上下文里信息密度不均，模型在压缩时容易把低频但关键的细节过滤掉，也可能把相近表述合并。解决办法是分段处理：先按章节切块，每块单独摘要并要求“保留原文数字和专有名词”，再做二次汇总；汇总时要求“只使用各段摘要中出现过的信息，不要补充”。

排查顺序我一般按这个走：先看模型选对没有，再看需求类型说清没有，然后看约束有没有冲突，最后才怀疑提示语措辞。绝大多数翻车发生在前三步，措辞问题反而是最少见的。

注意：模型给出“不确定”“建议核实”这类表述时，不要当成废话删掉，那往往是它唯一一次主动暴露风险。

6. 固化成一页检查表：提示语上线前的三问复核与模板库维护

零散技巧记不住，能落地的只有检查表。我把这份材料里的规则压成一页，每次写重要提示语前过一遍，三问足够拦住大部分问题。第一问：这个任务该用哪类模型，失败模式是逻辑错还是太单调？第二问：我写的是指令还是需求，目标、约束、评估标准齐了没有？第三问：输出格式约定清楚没有，字段、长度、依据要求有没有写？

配套的动作是建一个小模板库。按五类需求各存两三个跑通过的模板，每个模板只改参数不改结构，用的时候复制、替换、跑一轮、看结果。模板库要定期清理，把连续两次输出不达标的删掉——模型在迭代，旧模板会过期，留着只会误导自己。

验证方法上，我习惯用“三个反例”来检验一条提示语是否稳定：换一个相近的输入跑一遍、故意给一个边界值跑一遍、把一个约束去掉跑一遍。三次里如果有两次输出结构崩了，说明提示语依赖了某条隐含假设，得把假设写进上下文。这套动作比反复调措辞有效得多，因为它检验的是需求的完整性，不是语言的花哨程度。

还有一个容易被忽略的技巧：把每次跑得好的提示语连同当时的输入输出存一份，标注日期和模型名。过上两个月回头看，你能清楚看到哪些规则是稳定的，哪些只是当时模型的偏好。这个习惯帮我省掉了大量重复试错——有段时间我总觉得自己写的提示语“时灵时不灵”，翻记录才发现，灵的那几次都是需求写得完整，不灵的那几次都是在靠措辞碰运气。

从那以后我每次提需求前都强制走一遍三问复核，宁可多花两分钟把评估标准写清楚，也不愿意在返工上耗半小时。这份 PDF 我按章节拆成了笔记，配上自己整理的对照表和模板，需要的话可以直接取来对着改，希望帮到你。

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