企业官网建设流程全解析

简介：《DeepSeek从入门到精通》PDF面向希望系统了解并上手DeepSeek的普通用户、开发者与AI学习者，围绕其能力边界、使用方法与进阶路径展开。内容涵盖DeepSeek-R1开源可免费商用、复杂任务处理，以及智能对话、文本生成、语义理解、计算推理、代码生成等场景，并介绍联网搜索、深度思考、文件上传和图片文字读取功能；重点比较推理模型与非推理模型、概率预测与CoT链式推理的差异，结合数学证明、创意写作、代码生成等任务说明模型选择、提示语策略及常见误区。压缩包共1个PDF文件，约4.83MB，已有730人学习。适合作为系统阅读材料，帮助读者按任务类型选模型、优化提示语并理解应用边界。

1. 拿到这份《从入门到精通》我先翻的是提示语那几页：它其实是一份选型手册

上周有做投放的朋友问我，DeepSeek 到底怎么用才不像在跟搜索引擎聊天。我把手里这份 2025 年 2 月初版本的《DeepSeek 从入门到精通》讲义翻给他看，重点压根不在“能写文案、能改代码”那串功能罗列上，而是中间那几页把模型分成推理和通用两条线、再给出两套提示语策略的对照表。这份材料出自某高校新媒体研究团队，通篇没有一句 API 参数，讲的是同一件事：什么任务交给哪类模型，需求该怎么表达。适合已经把对话跑起来、但产出时好时坏的人；纯新手照着也能走，只是前半部分会觉得偏概念。

2. 模型先分清：推理模型和通用模型不是“新旧两代”

选型的混乱几乎都来自一个误解，把推理模型当成通用模型的升级版。这份讲义把它拆得很干脆：两者是训练目标不同，不是能力高低不同。搞清楚这一层，后面所有提示语技巧才有落点。

2.1 快思慢想的坐标系：两组能力别混着比

讲义用 CoT 链式思维的出现作为分水岭，把大模型切成两类。一类是概率预测型的快速反应模型，靠大量语料训练出的模式匹配，一句话进来，下一个词的概率分布就出去了，快、便宜、覆盖面广；另一类是链式推理的慢速思考模型，把问题拆成若干步，逐步推演再给答案，慢、算力成本高，但在逻辑密度大的任务上明显更稳。DeepSeek-R1 属于后者，开源且允许商用，这一点对要把它塞进业务流程的团队来说，比榜单排名实在得多。

两类的差异可以摊开成一张表看：

表格最右一列容易被读成“推理模型全面更强”，这是第一个坑。讲义自己就写了反面：发散性任务比如诗歌创作，推理模型反而吃亏，它会把一首诗写成论证文。强弱判断那句话值得抄下来——并非全面更强，仅在其训练目标领域显著优于通用模型。反过来，通用模型在需要严格逻辑链的任务上会跳过关键步骤，你以为它推了，其实它是顺着语感接下去的。

我一般这么用：涉及数字、代码正确性、多步因果的，走推理；涉及语气、创意、多轮闲聊、格式转换的，走通用。同一件事两头都要，就拆成两轮，先用推理把结论和依据定下来，再用通用把结论写成人话。这个组合在写技术方案、写复盘报告时特别省事，前者负责逻辑不自洽，后者负责不像机器写的。

2.2 选型三问：拿到任务先问自己三句话

讲义给的原则是“优先根据任务类型而非模型热度选择”，落到操作上，我会在开对话前先过三个问题：

1. 这个任务有没有唯一正确答案，需要把推导过程摆出来？数学证明、代码正确性、多步业务推演，答案是要被检验的，选推理。
2. 输出是收敛的还是发散的？写十条广告语、起二十个标题、模拟一段客服对话，要的是多样性，选通用。
3. 我能不能自己验证结果？能验证且需要看过程的，用推理并让它给中间结果；不能验证但要创意的，用通用并多给示例把方向框住。

第三个问题最容易被跳过。很多人把“我不懂这个领域”当成选推理模型的理由，其实恰恰相反——你不懂，就没法判断它推得对不对，这时候更该做的是把任务拆小、要求它给可核对的中间产物，而不是换一个“更聪明”的模型然后全盘接受。

讲义里那张任务与提示语策略的对照表，本质就是把这三问的答案固化下来：

这张表我打印出来贴在显示器边上用了两周，最大的收获不是记住了哪一行，而是养成了“先看右两列”的习惯——多数翻车不是因为模型不行，是因为写法和模型类型对不上。

2.3 同一需求两套写法：把差异落到具体句式

抽象地讲“提示语要适配模型”没什么用，落到句子上才有感觉。讲义举的五组对照，我挑三组展开说。

数学证明这组最能说明问题。对推理模型，一句“证明勾股定理”就够了，它自己会走完辅助线、相似三角形、面积关系那套链条；你要是贴心地写“先画直角三角形，再列面积公式，最后化简”，反而可能把它按在你的路径上，走到一半卡住。对通用模型就完全反过来，必须显式要求分步，还得给一个步骤样例，否则它很可能直接甩出结论，中间过程是补出来的，看着顺但经不起推敲。

创意写作这组是个反直觉的例子。给推理模型写“按时间顺序列出三个情节”，它会把故事写成流程说明；正确姿势是给风格锚点和开放空间，比如“以极简克制的笔法写一个关于误车的故事”，让它自己组织。给通用模型则要反过来收紧，明确字数、必须出现的意象、禁止的套路，不然它会滑向最平庸的表达。

代码生成这组差异最实用。推理模型适合一句话下单：“用 Python 实现快速排序，带注释”，它会自动处理边界；通用模型则需要你把输入输出格式、时间复杂度要求、要不要测试样例全写清楚，它负责按图施工。我在实际项目里两种都用：算法骨架让推理模型出，样板代码和胶水层让通用模型写，因为后者对框架 API 的熟悉度往往更均衡。

还有一条讲义里点了但容易被忽略：不要对推理模型用“你是一位资深 XX”这类角色扮演式启发。它确实能触发自解释，但也会把注意力从逻辑主线上拽走，尤其是你后面还要追问细节的时候，前面那层人设会一直干扰它。角色扮演留给通用模型更合适，那是它的主场。

3. 提示语拆成三件套：指令、上下文、期望各管什么

讲义对提示语的定义很朴素：你输入给模型的指令或信息，用来引导它产出特定结果。它可以是一个问题、一段详细指令，也可以是一整个任务描述。朴素归朴素，但后面那句“基本结构包括指令、上下文和期望”才是能直接抄的部分。

3.1 三件套的边界：哪一件缺了会怎样

指令是核心，明确告诉模型要做什么；上下文提供背景，帮它理解任务落在什么场景里；期望则明确或隐含地表达你对输出的要求。三件缺一件，症状各不相同，而且很好辨认：

举个人人都遇到的例子。“帮我写个周报”，这是只有指令，输出必然是那种放之四海皆准的套话。加上期望：“三段，每段一个进展加一个阻塞，不超过 300 字”，输出立刻收敛。再加上下文：“我是后端，本周做的是订单服务拆分，阻塞是联调环境不稳定”，这才有具体内容。三件套齐全的提示语，长度往往比一句指令长三五倍，但返工次数会掉下来。

讲义的表述里，期望可以是明确也可以是隐含的。我的经验是别赌隐含——你想要表格就写“用表格”，想要 Markdown 就写“用 Markdown 标题分级”，想要它别加客套话就写“直接给结论，不要开场白”。这些不是矫情，是省掉后面三轮修改。

3.2 六种提示语类型及其失效场景

讲义把提示语分成六类，我把它们的适用边界和翻车点整理在一起：

这张表最有用的是最后一列。角色扮演型在通用模型上是利器，在推理模型上经常是负资产；分析型提示语如果没有附上材料，模型只能靠记忆编，看着像分析其实是复述；多模态那一条，讲义提到支持文件上传和图片文字识别，实际用的时候扫描件倾斜、表格线断裂都会让识别结果错位，重要数字必须回原图核对。

3.3 从“下指令”到“表达需求”：三种策略的取舍

讲义里有一段标题我印象很深：从“下达指令”到“表达需求”。它给了三种策略，不是三选一，而是按任务复杂度切换：

• 指令驱动：直接给明确步骤或格式要求。适合简单任务、需要快速执行。优势是精准高效，风险是限制了模型自主优化的空间。
• 需求导向：描述问题背景与目标，由模型自己规划路径。适合复杂问题、需要模型自主推理。优势是能激发深层推理，风险是需求边界不清时会跑偏。
• 混合模式：需求描述加关键约束条件。兼顾目标与细节，是日常最常用的一种，风险是约束给多了会捆住手脚。

还有一类是启发式提问，比如“为什么选梯度下降而不是别的优化方法”。它能触发模型自解释，适合做技术选型的思维陪练，但很容易偏离核心目标，问着问着就变成闲聊。我的做法是把它限制在一轮之内，得到解释就收，不让它继续发散。

三种策略的切换信号其实很清楚：任务一句话能说清就用指令驱动；任务需要它做判断、做取舍就用需求导向；任务既要它判断又有硬约束，比如预算、字数、技术栈，就用混合模式，把约束单列成条目。

3.4 五类需求的表达公式

讲义把日常需求归成五类，每类给了一个表达公式和两种模型的适配策略。这张表是全篇最值得直接抄走的部分：

公式本身不难，难的是把需求归类。举个讲义里的决策需求例子：降低物流成本有两个方案，一是自建区域仓库，初期投入高但长期成本低，二是与第三方合作，按需付费但灵活性高，要求按 ROI 模型对比五年总成本并给推荐。这个句式的骨架就是目标（降本）、选项（自建或合作）、评估标准（五年 ROI）。缺了评估标准，模型只能泛泛说“各有优劣”；缺了选项，它会自己造两个不相关的方案。

验证需求的例子也很典型：给一个论文结论“某神经网络优于传统方法”，要求验证实验数据是否支持、对照组设置是否有偏差、重新计算显著性。这套写法的价值在于它把“帮我看看对不对”这种无效提问，换成了三条可执行的检查项。至于执行需求，关键是输出格式要写死——把 C 代码转成 Python，保持时间复杂度不变、用 numpy 优化数组操作、输出带时间测试的完整代码，这三条约束一给，返工率直线下降。

4. 落到工作流：四个高频场景的复现步骤

讲义里的场景覆盖很广，文本生成、语义分析、情感分析、意图识别、代码调试都提到了。挑对日常最有用的几个，把步骤写细，照着走就行。

4.1 长文档摘要：先切结构再压字数

最常见的翻车是一上来就写“把这篇文章总结成 300 字”，结果开头讲得细，后半部分一句话带过。原因不玄学，模型在压缩时倾向于优先保留前文信息，越往后权重越低。稳妥的四步是这样的：

第一步，先让它出结构。提问“列出这份文档的章节标题和每节核心论点，不要摘要，只列结构”，拿到骨架你就能判断它有没有读全。

第二步，按节压缩。把文档按章节切开，逐节投喂，每节要求“保留数字、结论和限定条件，输出 3 条以内”。分段处理比整篇丢进去稳得多。

第三步，合并去重。把各节结果拼起来再让它合并，“合并以下分节摘要，去掉重复表述，保持原有结论顺序”。

第四步，反向自检。加一句“指出合并后的摘要中，有哪些结论在原文里找不到明确出处”。这一步经常能揪出它自己补出来的内容，尤其是数字和因果判断。

提示：涉及合同条款、财务数字、技术参数的长文档，第四步不能省。模型补出来的数字看起来和原文一样自然，肉眼很难分辨。

4.2 代码生成与调试：把验收标准写进需求

代码场景的提示语，我一般按四段写：任务、约束、验收、输出格式。任务一句话，约束列条目，验收写测试样例，输出格式指明语言和文件结构。比如要一个配置读取模块：

任务：写一个读取 YAML 配置的函数。 约束：只用标准库加 PyYAML；配置缺失时抛自定义异常而不是返回 None；支持环境变量覆盖，前缀统一。 验收：给三个测试用例——正常读取、字段缺失、环境变量覆盖优先级。 输出：单个 Python 文件，函数带 docstring，最后附 pytest 用例。

调试时的写法反过来，信息越全越好：贴最小复现片段、完整报错栈、运行环境和版本、已经试过的两种方案及结果。最忌讳的是只说“报错了”然后截半行日志——那不是提示语，那是猜谜。

代码生成还有个隐性成本：模型给的代码能跑，但和你项目的风格、日志规范、异常体系不匹配，合并时改的时间比自己写还长。我的做法是在约束里塞一段现有代码作为风格样例，明确说“异常处理、日志、命名参照这段代码”。多花两行字，省半小时返工。

4.3 知识推理与交叉验证：让它自证

推理类任务最怕的是“看起来推了”。有三个动作能把过程逼出来：一是要求给中间结果，比如“每步计算后写出当前数值”；二是要求列反例，“给出三个会让这个结论不成立的条件”；三是换表述重问一次，看结论是否稳定。

交叉验证在事实性问题上尤其管用。同一件事用两种问法问，一次问“这个说法成立吗，依据是什么”，一次问“这个说法在什么情况下不成立”。两次答案如果互相矛盾，说明模型对这块知识并不确定，那就别采信，回去查原始资料。

注意：联网搜索和深度思考是分开的开关。开了搜索不等于结果一定准，来源质量仍然要自己看一眼；开了深度思考也不等于逻辑一定对，长链条里任何一步错了后面全歪。两个都开的时候，先看它引用了什么，再看它推了什么。

4.4 用一个脚本把提示语模板管起来

手工改提示语最大的问题是没法对比。今天调一版觉得好，明天再调一版，两周后想回头找当初那版，聊天记录已经翻不到了。我一般会建一个极简的模板库，把讲义里那三类策略和五类需求公式固化成条目，跑完把结果记进 CSV，做 A/B 对比。

# prompt_lib.py —— 提示语模板库：固化策略类型，记录每次结果 import csv import json import pathlib from datetime import datetime # 模板结构：id -> 元信息 + 带槽位的正文 # model_type: reasoning / general，决定这条模板只能投给哪类模型 # strategy: 指令驱动 / 需求导向 / 混合模式，对应讲义里的三种策略 # need: 决策 / 分析 / 创造 / 验证 / 执行，对应五类需求公式 TEMPLATES = { "verify_paper": { "model_type": "reasoning", "strategy": "需求导向", "need": "验证", "text": ( "以下是一份研究结论：{conclusion}。请验证：" "1) 实验数据是否支持该结论；2) 对照组设置是否存在偏差；" "3) 重新计算显著性并说明判断依据。" ), }, "creative_slogan": { "model_type": "general", "strategy": "混合模式", "need": "创造", "text": ( "主题：{topic}。风格：{style}。" "输出 {n} 条不超过 12 字的标语，避免使用‘赋能’‘引领’这类词。" ), }, } def render(template_id: str, **slots) -> str: """按槽位填充模板，缺失槽位直接报错，避免半成品提示语流出去""" tpl = TEMPLATES[template_id] try: return tpl["text"].format(**slots) except KeyError as e: raise ValueError(f"模板 {template_id} 缺少槽位: {e}") from e def log_result(path: str, template_id: str, output: str, score: int, note: str = "") -> None: """把每次输出记进 CSV，score 用 1-5 主观打分，方便后面横向比""" file = pathlib.Path(path) is_new = not file.exists() with file.open("a", newline="", encoding="utf-8") as f: writer = csv.writer(f) if is_new: writer.writerow(["time", "template_id", "model_type", "score", "note", "output"]) tpl = TEMPLATES[template_id] writer.writerow([ datetime.now().isoformat(timespec="seconds"), template_id, tpl["model_type"], score, note, output[:500], ]) if __name__ == "__main__": print(render("creative_slogan", topic="家用净水器", style="克制、不夸张", n=5)) # 跑完把输出贴回来打分，同一模板换个模型再跑一遍，就有了第一条对比数据

这段代码不长，三个设计点值得说一下。model_type这个字段是硬约束，模板标了 reasoning 就不该投给通用模型，写死在元信息里比记在脑子里可靠。render里槽位缺失直接抛异常，是为了防止半成品提示语流出去——{conclusion}没填就发出去，模型会把它当占位符糊弄过去，你还以为是自己表达不清。log_result只截前 500 字，是为了让 CSV 能直接丢进表格软件看，太长的输出反而没人读。参数上，score用 1 到 5 的主观分就够，关键不是精确，是同一批模板之间能排出先后。

5. 避坑与排查：五条翻车记录

下面这几条都是我自己踩过或者看着同事踩的，按“现象、原因、解决”写，遇到类似症状可以对着排。

5.1 提示语层面的三个坑

第一条，给推理模型加了角色扮演和“请一步步思考”。

现象：回答开头先自我介绍“作为一名资深产品经理”，然后绕了两段才进正题，逻辑链条反而断断续续。

原因：推理模型本身已经内化了推理结构，你再要求它分步，等于在它自己的链条外面套一层壳；角色设定又额外占用注意力，让它把力气花在维持人设上。讲义里那句“不要对推理模型使用启发式提示”说的就是这个。

解决：把角色和“一步步思考”删掉，只留目标、约束、输出格式。删完再做一次对照，多数情况下回答会更短更准。

第二条，数学或代码题答案看着对，一跑就错，中间步骤缺失。

现象：让它算一个多步推导，结论对但过程是跳的；代码逻辑看似合理，边界一测就崩。

原因：多半是用了通用模型还问得太短。通用模型顺着语感往下接，形似推导，实际没有逐步验证；反过来，如果你用的是推理模型却强行拆步骤，也会限制它的推理空间。

解决：先确认模型类型对不对，再决定提示语写法。推理模型直接抛问题，通用模型显式要求分步并给示例，最后统一加一句“给出可验证的中间结果”。

第三条，长文档摘要漏掉后半段关键结论。

现象：一份几十页的材料，摘要里前半部分细节齐全，后半部分的结论、限制条件几乎没提。

原因：一上来就压成固定字数，模型优先保留前文；文档越长，越靠后的内容在注意力分配上越吃亏。

解决：先出结构大纲，再按节压缩，最后合并去重并做反向自检，要求它指出哪些结论找不到原文出处。这套流程比一次成型的摘要慢，但返工少。

5.2 使用习惯上的两个坑

第四条，同一条提示语今天好用、明天崩，产出风格飘忽。

现象：同一个模板，周一生成的文案干脆利落，周三生成的就变得啰嗦，还夹杂一堆形容词。

原因：模板没固定，每次都是现打；而且一直在同一个会话里连续追问，历史上下文越堆越长，模型的输出被前面的对话带偏。

解决：模板写成槽位固化下来，像上节那个脚本一样；重要任务开新会话跑，别在几十轮的老对话里继续追加需求。

第五条，让它“分析数据”，回来一堆通用建议，一个数字都没有。

现象：贴了一段销售数据过去，让它分析，输出是“建议加强渠道建设、优化产品结构”这类放之四海皆准的话。

原因：两个问题叠在一起。一是数据没给全或者格式混乱，它读不出结构；二是需求类型写错了，你想要的是分析需求，写出来却像决策需求，它就跳过分析直接给建议。

解决：数据用表格或 CSV 贴清楚，指明分析方法，比如趋势、同比、异常点；明确要求“每条结论必须挂具体数字”。要决策建议就再单独提一轮，别和分析混在一句话里。

6. 进阶：把提示语当代码管，跑一轮 A/B 就知道该信谁

讲义的最后一层意思，其实不是教你写出多花哨的提示语，而是让你有办法判断哪一版更好。没有对比，所有“我觉得这版更顺”都是自我感觉。

我现在的流程是这样：一个模板固定下来之后，同一批输入分别投给推理模型和通用模型，各跑三遍，输出记进 CSV 打分。三遍是必要的，因为单次输出有随机性，跑一遍就下结论等于抛硬币。评分维度我只留三个——事实有没有错、结构能不能直接用、要不要二次加工。三个维度各打 1 到 5 分，加总排序，比逐字读十遍输出高效得多。

表格跑上两三周，你会得到一份很个人的经验数据：哪类任务用哪个模型、哪种策略返工最少。这份东西比任何通用攻略都准，因为它对应的是你的业务、你的文档、你的验收标准。

还有一个容易被忽略的进阶点：把失败样本留下来。翻车的输出比成功的输出值钱，它直接告诉你边界在哪。我一般在 CSV 里加一列备注，写清楚“为什么这版不能用”，比如“引用了不存在的文献编号”“把同比写成了环比”。攒到十几条，你会发现翻车高度集中在几个固定形态上，针对性改模板，比漫无目的地调提示语有效得多。

从那以后，我每次上新模板都强制先在两类模型上各跑三遍、把分数记进表里再决定用哪版，哪怕只是改了一个词也走一遍。这习惯救过我一次——一条看着完全无害的措辞调整，让验证类模板的准确性从 5 掉到 3，表格一摆就露馅了。希望帮到你。

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