企业官网建设流程全解析

简介：《DeepSeek：从入门到精通（清华大学版）》是一份由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室团队整理的 PDF 学习资料，面向普通用户与开发者，解答 DeepSeek 是什么、能做什么、怎么用三大问题。内容围绕 DeepSeek-R1 开源推理模型的智能对话、文本生成、语义理解、代码生成等能力展开，并系统对比推理模型与通用模型在优势领域、性能本质、提示语策略上的差异，帮助读者按任务类型选择合适模型、设计更高效的提示词。资源包含 1 个 PDF 文件，共 3.69MB，图文排版清晰，适合从零起步的系统性学习，也可作为日常使用 AI 工具时的速查参考。已有 2099 人学习下载，适合希望从“下达指令”升级到“表达需求”、提升复杂任务处理效率的读者。

1. 这份"从入门到精通"到底在讲什么

网上流传的《DeepSeek 从入门到精通》常被冠以某高校的名头，很多人硬盘里存了一份，跟着抄了几天提示词，一到生产环境照样翻车。原因在于这份资料的方向不是教你怎么聊天，而是教你怎么把 DeepSeek 用到位。"入门"是调通 API、会写基础提示词；"精通"是能控输出格式、能接工具调用、能建评测集，还能提前避开长上下文丢信息这类隐蔽问题。下面不替任何原稿背书，只按这个标题指向的技术方向，把模型选型、提示词分层、API 接入和落地排错的做法讲完整。适合两类人：刚拿到 key 的初学者顺着走一遍；已经在业务里接了的熟手，直接跳到第 5 章对照踩坑。

2. 先给 DeepSeek 定位：模型选型决定后面 80% 的调参工作

2.1 通用对话模型与推理模型的分工：先选对，再谈调优

DeepSeek 在 API 接入层，最常见的是两类模型：通用对话型和推理型。不同版本的接入名会变，我在实际项目里见过以 deepseek-chat、deepseek-reasoner 这类名字区分的，具体以你开通服务的控制台为准，但两者的分工是稳定的：通用对话模型流畅、快、单价低，适合内容生成、信息抽取、改写润色、翻译分类这类"一次生成、结构可控"的任务；推理模型会在正式回答前多走一段内部推理，数学、逻辑、多步规划、条件判断这类任务明显更稳，代价是首字更慢、单价更高。

这两类模型的差别来自解码流程。推理模型在输出前会先生成一段隐藏的思考链，这也是它延迟高的直接原因；通用对话模型没有这一步，所以快，但遇到需要隐式推理的任务时容易跳步。理解了这一点，就不难判断：凡是"想想再说"的任务，优先推理模型；凡是"看完就说"的任务，通用模型就够了。

我一般按任务性质做三档选择。第一档，摘要、分类、抽取、润色、翻译，一律用通用对话模型，能加格式约束就加，速度是第一位。第二档，代码调试、SQL 生成、数学题、多条件规则判断，用推理模型，但最终结果还是要用结构化输出框回来，不能让它自由发挥。第三档，混合任务，先在通用模型上把格式做稳，再拿推理模型复核一到两个关键结论，而不是所有请求都走贵的。

选型这一步之所以值得单独说，是因为它决定了后面所有工作的基准。推理模型在需要多步推理的任务上准确率可能高出通用模型不少，但在简单抽取任务上几乎没有收益，还多付延迟和成本。我见过一个团队在简单问答场景里全量上推理模型，只因为"听说效果更好"，结果成本翻了几倍，准确率只涨了一个点。选型错了，后面调温度、调提示词都只是在错误的基准上做局部搜索，属于把问题延后。

提示：接入名在不同服务商的实现里有差异，换模型前先在文档里确认名字和计费方式，别在代码里写死逻辑。

2.2 上下文长度与采样参数：别把长上下文当卖点

DeepSeek 系列的上下文窗口做得长，长文本是它的一个卖点，但"长"不等于"好用"。实际约束有两个：一是上下文越长，每次请求的 KV Cache 开销越大，首字延迟和单次成本一起涨；二是模型对长上下文的注意力并不均匀，测试里最常见的现象是开头和结尾记得牢，中间一大段容易"选择性遗忘"。

我的习惯是：能用检索把上下文压到 4K 以内，绝不用 32K 硬塞。真遇到必须长上下文的场景，有两个补救手段：把最关键的约束放在系统提示的末尾复述一遍；把材料里的关键结论在问题里显式引用一次。这两招比单纯加大窗口便宜得多，也有效得多。

采样参数里最常被误用的是 temperature 和 top_p。我一开始也是两个一起调，后来发现结果变得更加不可控。原因是两者都作用于采样阶段：temperature 是对 logits 做缩放后再采样的随机性控制，top_p 是对候选词做累积概率截断，两者同时改会叠加出奇特的分布形态，出了问题很难定位是哪一个造成的。

max_tokens 是很多人忘记设的参数。回答被截断时，表现是"写到一半突然停了"，看起来像模型在胡说，实际是你设的上限不够。还有一个容易被忽略的点：推理模型的内部思考也占用输出长度，从通用模型切到推理模型后如果发现回答变短了，往往不是模型变笨，而是思考过程吃掉了额度。遇到这种情况，先把 max_tokens 拉大一截再判断。

另外强调一句：这些参数都建立在模型能力之上。所谓"玄学调参"，本质是在错误前提下做局部搜索。参数不是不能用，而是要每次只动一个，并且用同一组测试样本验证效果。

2.3 云端 API 还是本地部署：先算这笔账

大模型落地，第一道选择题是"用 API 还是本地部署"。很多人一上来就想私有化，理由是安全，但这个决定应该由成本和运维能力驱动，而不是感性驱动。

API 方式的优势是零运维、按量付费、模型版本始终在线升级；劣势是数据要出内网，且请求量大了之后单次成本会变成一笔持续支出。本地部署的优势是数据不出内网、单次调用边际成本趋近于零、可以做私有微调；劣势是你要养 GPU 资源、处理量化精度、选推理框架、管并发和显存。本地部署不是"下载一个模型就能跑"，我见过不止一个人卡在显存不够和推理加速这一步。

我的判断标准很简单：日请求量低，或业务还在验证期，API 一定更划算；数据敏感度到不能出内网的程度，或者日调用量大到 API 月账单超过 GPU 折旧和电费，再考虑本地。更稳的路径是先在 API 上把业务逻辑验证通，再评估是否迁移，而不是一上来就买卡。

3. 提示词三层写法：把"会问"打磨成"能控"

3.1 第一层结构化：角色-任务-约束三段式

很多人的提示词是一句话："帮我总结这篇文章。"模型确实能答，但格式、详略、立场全凭当天运气。我习惯的三段式模板是：先给角色定位，再说具体任务，最后列硬约束。下面这段是实际用在反馈分析场景里的模板：

你是一个资深数据分析师，擅长从用户反馈中提炼可执行的改进项。 任务：阅读下面的用户反馈，输出本版本存在的三个最严重问题。 约束： 1. 每个问题用一句话描述，不超过 30 字； 2. 每个问题后附一条证据，引用原文片段； 3. 按严重程度从高到低排序； 4. 只输出 Markdown 列表，不要开场白。

这段模板的逻辑分三层。角色行压缩了模型对"该用什么语气、什么领域知识来回答"的猜测空间；任务行明确了唯一目标，避免发散；约束行把不可度量的"写得好"拆成可校验的规则——"排序、引用原文、限字数"都是能在评测时自动验证的。

这也是我要强调的：约束应该可校验，而不是表态度。同一句话，"回答要认真"不可校验，"每个结论必须附数据来源"可校验；"格式要美观"不可校验，"使用 Markdown 二级标题分节"可校验。写提示词时，把每条约束过一遍"能不能自动化检查"这个筛子，留下来的才是有效约束。

这里有一条血泪经验：约束不是越多越好。我把约束从三条加到十条，以为写得越清楚模型越听话，结果模型开始顾此失彼——守住了格式丢了内容，守住了字数丢了证据。原因是约束之间会互相冲突，模型要在矛盾里做取舍，输出质量自然下降。我的阈值是硬约束不超过五条，能合并的合并，覆盖不到的规则交给输出格式去约束。每加一条新约束，都要用同一批测试样本回归一遍，而不是只看当前这一个例子。

3.2 第二层思维链与少样本：复杂任务稳定性的关键

任务一旦需要多步推理，直接要答案的写法会让模型跳步。常见做法是让模型先列推理步骤，再给结论。DeepSeek 对这种显式思维链的追随能力比较强，是少数能在提示词层面把推理过程逼出来的模型之一。

请按以下步骤思考，最后再给结论： 1. 列出题目给出的所有条件； 2. 判断需要用到哪个公式或规则； 3. 代入数值计算，每一步保留中间结果； 4. 检查单位与量级是否合理； 5. 基于以上步骤给出最终答案。 题目：仓库初始库存 500 件，每天进货 200 件、出货 150 件，问第几天库存超过 2000 件？

这里的关键不是"让它好好想"，而是把隐式推理拆成可检查的中间产物。你拿到的不只是一个答案，而是它算到哪一步开始出错的线索。排错时你能直接指出"第三步代入错了"，而不是对着一个错误结论无从下手。

少样本是同一思路的另一面。给一两个完整示例，往往比写五条规则更有效。但示例的选择有讲究：要选"容易答错"的边界样本，而不是选"答得漂亮"的典型样本。比如做意图分类，正样本给"查快递"对应"查询类"，远不如给"帮我看看这个包裹到哪了"这种口语化变体更有信息量。

有一类任务要反着用：推理模型。DeepSeek 的推理模型内部本来就会生成思考链，你再在提示词里要求它显式写步骤，效果不会提升，反而拉长输出、推高成本。我实测对比过同一道规划题，显式思维链让输出长度增加约一倍，正确率没有变化。所以思维链提示词留给通用对话模型，推理模型只需要告诉它"输出格式"就够了。

3.3 第三层输出格式：用 JSON 约束替代"请按格式输出"

"请输出 JSON"这句话模型听得懂，但偶尔会夹带 Markdown 代码块、多余的说明文字，甚至直接输出一个不完整的 JSON。更稳的办法是把格式定义直接写进提示词，并在代码里做两层容错。

{ "issues": [ { "title": "问题一句话", "evidence": "原文引用片段", "severity": "high | medium | low" } ] }

把这段结构粘进提示词的约束区，同时在 system 里写明"只输出 JSON，不要 Markdown，不要解释"。这样组合，实践中解析成功率能到 95% 以上。剩下的少数失败，靠代码兜底：

import json, re raw = resp.choices[0].message.content try: data = json.loads(raw) except json.JSONDecodeError: match = re.search(r"```(?:json)?\s*(.*?)\s*```", raw, re.S) if match: data = json.loads(match.group(1)) # 剥掉代码块标记再试一次 else: data = None # 仍失败就走告警，交给人工处理

这段兜底的逻辑：先按标准 JSON 解析，失败后用正则把json 和之间的内容抠出来再试，还失败就告警而不是静默返回空。生产环境里，兜底逻辑和提示词同样重要。把宝全押在提示词上，等于把稳定性寄托在模型的当天状态上。

4. 用 Python 跑通接入：对话、流式、工具调用一条线

4.1 最小可用脚本：先让一次对话跑起来

DeepSeek 的 API 兼容 OpenAI 协议，用官方 Python SDK 就能接，不需要自己封装 HTTP。先记一个最小脚本：

from openai import OpenAI import os client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], # key 走环境变量，别硬编码 base_url="https://你的服务商地址/v1", # 以你开通服务的文档为准 ) resp = client.chat.completions.create( model="deepseek-chat", # 接入名以控制台为准 messages=[ {"role": "system", "content": "你是一个只输出 JSON 的助手。"}, {"role": "user", "content": "把这句话翻译成英文：你好，世界"}, ], temperature=0.3, max_tokens=512, ) print(resp.choices[0].message.content)

这个脚本的要点就几个：客户端初始化时指定 key 和 base_url；消息列表按 system、user 顺序组织，system 负责定基调，user 放实际请求；temperature 和 max_tokens 在这里已经落到结构化输出的推荐值。

有两点必须强调。第一，key 一定走环境变量或密钥管理服务，不要写进代码仓库。我见过不止一次因为 key 泄露被刷账单的翻车，这是接入大模型最贵的教训。第二，base_url 不要照抄网上的，以你实际开通的服务商文档为准，尾部的 /v1 路径拼写敏感，错了会返回 404 这类报错。

4.2 流式输出：长回答别让用户干等

不开启流式时，接口要等完整回答生成完才返回，一段长总结能让你等十几秒。生产环境建议开流式，首字到达时间会从十几秒缩短到一两秒。代码改动很小：

stream = client.chat.completions.create( model="deepseek-chat", messages=messages, stream=True, ) for chunk in stream: delta = chunk.choices[0].delta.content if delta: print(delta, end="", flush=True)

流式模式的核心是理解 delta 字段的结构：每一块只携带增量内容，不是完整文本。所以拼接逻辑要放在消费侧，比如后端逐块转发给前端走 SSE，而不是在后端拼成完整文本再一次性返回，那样流式就失去了意义。

超时参数也要单独设。流式请求的连接超时给 30 秒左右，读超时按业务容忍度给，比如 120 秒。不要用默认的一刀切超时，长流式请求很容易被默认值误杀。排查这类问题时，先看超时设置，再看网络，不要一上来就怀疑模型。

4.3 工具调用：把 DeepSeek 接进真实业务流程

对话只是最浅的一层。真正把模型变成生产力，靠的是函数调用——让模型决定调用哪个工具、生成参数，你的代码去执行，再把结果喂回给模型。这也是"从入门到精通"的分水岭。

tools = [{ "type": "function", "function": { "name": "query_stock", "description": "查询指定商品在华东仓的实时库存，返回数量和预警阈值", "parameters": { "type": "object", "properties": { "sku": {"type": "string", "description": "商品编码"} }, "required": ["sku"] } } }] resp = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": "查一下 A100 的库存"}], tools=tools, tool_choice="auto", ) msg = resp.choices[0].message if msg.tool_calls: for call in msg.tool_calls: print(call.function.name) # 模型想调用的函数名 print(call.function.arguments) # 模型生成的参数 JSON # 在这里真正执行查询，然后把结果以 tool 角色追加回 messages，再次请求

整个流程分三步，缺一不可。第一步，模型输出"要调用哪个函数、参数是什么"，它只有这个意图，没有执行能力；第二步，你的代码真正执行，查询数据库或调用内部服务，因为模型接触不到你的系统；第三步，执行结果以 tool 角色追加回消息列表，模型基于结果生成最终回答，但你也可以选择直接返回结果给用户，取决于业务设计。

工具描述的好坏直接影响调用成功率。description 写"库存查询"远不如写"查询指定商品在华东仓的实时库存，返回数量和预警阈值"——模型是依据 description 判断"该不该用这个工具"的，写得越具体，调用越准。常见错误是让模型"自己查"，它做不到；另一类错误是工具名和参数名起得含糊，导致模型猜错参数。工具的命名和字段要按"人话"来，让模型少猜。

4.4 对话历史的窗口管理：别让消息数组无限膨胀

接入多轮对话后，最容易被忽视的是 messages 数组的长度。每轮对话都往里追加，时间一长会有两个问题：超出上下文限制导致请求失败；历史消息占用 KV Cache，成本和首字延迟一起涨。更隐蔽的是，过长的历史会让模型抓不住重点——中间轮次的噪音会稀释当前意图。

常见做法是保留 system 消息，把历史截断到最近 N 轮：

MAX_HISTORY = 10 def build_messages(system, history, user): recent = history[-MAX_HISTORY:] # 只保留最近 N 轮 return [{"role": "system", "content": system}] + recent + [ {"role": "user", "content": user} ]

这个函数的逻辑：system 永远保留，历史和当前用户消息做拼接，超过 MAX_HISTORY 的部分直接丢弃。实现简单，但要注意两个边界。一是截断会丢信息，用户十分钟前提的条件可能被截掉，所以进阶做法是把更早的对话压缩成摘要，用摘要替代原始历史；二是按轮数截断对长对话不精确，更稳的是按 token 数截断，用分词器估算每条消息的长度，总长超过阈值就从最早的开始丢。

方案的选择看场景：客服类对话窗口保留 10 轮足够；代码辅助类可以放宽到 20 轮；需要长期记忆的业务，与其硬撑窗口，不如把关键信息落库，需要时检索回来。窗口管理这件事，做得越早越省心，等接口开始报上下文超限再处理就晚了。

5. 落地避坑：五个高频翻车点与排查路径

5.1 提示词写得太满，输出反而更差

现象：约束从三条加到十条，想着越具体越稳定，结果模型开始漏字段、格式错乱，甚至拒绝执行。 原因：约束之间互相冲突，超出模型单次注意力能同时兼顾的量级。尤其是"字数限制"和"信息完整"这类天然互斥的约束，模型只能在矛盾中做取舍。 解决：硬约束砍到五条以内；冲突的约束用优先级排序，例如"信息完整优先，字数放宽到 40 字"；每加一条新约束，都用同一批测试样本回归，而不是只看当前这个例子变好了。

5.2 temperature 调高后 JSON 频繁解析失败

现象：同样的提示词，temperature 从 0.1 调到 0.8，JSON 解析失败率从 2% 涨到 20%。 原因：temperature 控制的是整个输出分布的随机性，结构符号同样会被影响。括号、引号的配对出错，不是模型不理解 JSON，而是采样太散。 解决：涉及结构化输出时 temperature 固定在 0.1~0.3，需要变化就调 top_p 或干脆不调。如果业务必须高温度，加一道"修复步骤"：让模型把夹带了说明文字的内容重写成干净 JSON。这是兜底，不是调参。

5.3 生产环境三件套：超时、重试、限流

现象：高峰期请求大面积失败，报错集中在超时和限流状态码。 原因：只设了一个笼统的超时；重试策略写成"失败立即重试"，反而加重了限流；没有做请求排队。这三个问题叠加，故障会被放大而不是被吸收。 解决：连接超时设 10 秒，读超时按任务给 60~120 秒；重试用指数退避，第一次等 0.5 秒，第二次 1 秒，最多三次；遇到限流响应，读取服务商返回的重试等待时间，而不是自己拍脑袋。这套组合是接任何大模型 API 的通用底座，跟具体模型无关。

5.4 长上下文"中间遗忘"：关键信息要挪位置

现象：把几万字的资料一次性塞进上下文，模型回答时漏掉了中段的某个数字或前提条件。 原因：注意力在长输入上不均匀，开头和结尾更容易被记住，中间段落的线索被淡化。这是长上下文模型的共性表现，不是某个具体版本的缺陷。 解决：三选一或组合用——能用检索把输入压短，就绝不硬塞全文；必须长上下文时，在系统提示末尾复述一遍最关键的约束；再不行就把材料拆成多路查询，分别提问再汇总。有效性排序是检索优于复述优于加窗口。

5.5 没有评测集就调参，等于拍脑袋优化

现象：每次改完提示词都感觉"变好了"，但上线后指标没动，甚至下滑。 原因：改完只看了几个手工挑的例子，恰好都过了，这是幸存者偏差。手工例子覆盖不了边界输入，随机性掩盖了真实的能力分布。 解决：建一个 30~50 条的固定评测集，覆盖正常、边界、恶意输入三类；每次改动跑一遍并记录通过率；只接受通过率不降的改动。评测集是你摆脱玄学、唯一可依赖的依据。

6. 从"能用"到"精通"：用评分脚本把迭代变成可验证的

最后一层，也是最多人跳过的一层：把"手感"变成"分数"。我给自己定的规矩是，任何改动上线前先跑评测。做法很简单：建一个固定输入列表，每条配上理想输出的关键词或校验规则，写一个几十行的脚本统计通过率。

cases = [ {"prompt": "提取这段合同里的编号", "must_contain": ["HT-"]}, {"prompt": "把'你好'翻译成英文", "must_not_contain": ["你好"]}, # 30~50 条，覆盖正常、边界、恶意输入 ] def run(prompt): # 调用你的封装函数，返回模型输出 ... def check(content, case): if "must_contain" in case: return all(k in content for k in case["must_contain"]) if "must_not_contain" in case: return all(k not in content for k in case["must_not_contain"]) return False passed = sum(check(run(c["prompt"]), c) for c in cases) print(f"pass rate: {passed}/{len(cases)}")

这套脚本的价值不是精确度量质量，而是做回归：你改完温度、改完提示词、换了模型，跑一遍，通过率不降，改动才敢合入。关键词判定对抽取、分类、格式校验类任务足够；开放生成类任务，再用二次评分或人工抽检兜底。

我的教训很直接。早期调参完全凭感觉，某次把 temperature 从 0.3 调到 0.7，手工看五个例子都更自然，满心欢喜上了线，结果线上抽取任务通过率掉了三成，用户投诉才意识到问题。后来把评测集跑起来的第一个月，就挡住了三次类似的"感觉很好、实际更差"的改动。从那以后，"先跑评测再上线"成了我接所有大模型的默认开关。

走到这一步，"精通"就不再是某个玄学境界，而是一套可重复的动作：选对模型，分层写提示词，接好 API 与工具调用，用评测集守住每一次改动。某高校那份资料给的是知识框架，这里给的是落地习惯。顺着这条路走，DeepSeek 对你来说就不是聊天玩具，而是能稳定产出价值的业务组件。希望帮到你。

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