企业官网建设流程全解析

简介：《DeepSeek：从入门到精通》是一份面向人工智能研发人员、工程师与学者的PDF学习资料，聚焦国产开源AGI推理模型DeepSeek-R1的功能应用与优化方法。内容从模型定位、智能对话、文本生成、语义理解、代码生成等场景切入，系统梳理推理模型与非推理模型的差异、快思慢想机制及任务匹配原则，并围绕指令驱动、需求导向、混合模式、启发式提问等提示语策略展开，附有数学证明、创意写作、代码生成等场景的有效提示示例与常见设计陷阱。压缩包仅含1个PDF文件，大小约4.83MB，便于集中阅读与检索。已有218人学习下载，适合希望快速建立DeepSeek使用框架、掌握提示语设计并规避实践误区的开发者与研究者参考。

1. DeepSeek-R1 上手第一课：会提问的人拿到的答案不一样

很多人第一次用 DeepSeek-R1 的体验是分裂的：让它写个排序函数，秒回一段能直接跑的代码；让它“分析一下这个方案”，回来的东西却像会议纪要的扩写版。同一个推理模型，差距不在模型本身，而在你把问题递过去的方式。有一份流传较广的内部讲义把这件事拆得很细——先讲清 DeepSeek 是什么、能干什么，再用大量篇幅讲推理模型和通用模型的差别、提示语设计怎么随任务类型变形。它适合已经能把模型跑起来、但输出质量忽高忽低的人，尤其适合把自然语言处理任务嵌进日常开发流程的工程师。下面按“选型—写提示—落代码—排错”四步，把这份资料整理成一版能照着做的流程。

2. 模型选型：先分清快思与慢想，再决定派谁干活

2.1 一条思维链的代价：推理模型和通用模型差在哪

推理模型和非推理模型的差别，不在于“谁更聪明”，而在于训练目标和输出路径不一样。推理模型在通用大语言模型的基础上，额外用强化学习、神经符号推理这类手段强化了逻辑分析与决策能力，典型代表就是 DeepSeek-R1 这一档的开源推理模型；通用模型则把算力压在语言生成、上下文理解和文本分类上，对“把一件事推到底”没有专门优化。落到使用体感上，推理模型会先在内部展开一条较长的思维链再给结论，通用模型更接近逐 token 的概率预测，张口就来。

代价是实打实的。思维链越长，首字延迟越高、token 消耗越大，账单和等待时间都会涨。所以选型的第一原则不是“哪个新用哪个”，而是先判断这个任务有没有唯一正确答案、需不需要多步推导。有唯一答案且步骤可验证的，交给推理模型；答案开放、评价标准靠人判断的，交给通用模型。这条线划清楚之后，后面提示语怎么写就顺了。

表里最后一行是最容易被忽略的：两代模型对提示语的“胃口”是反的。给推理模型写一堆“请一步步思考”，等于在它已经内化的推理链外面再套一层壳，反而干扰主线；给通用模型只丢一句“证明一下”，它就容易跳过关键步骤直接编结论。这不是玄学，是训练目标决定的。

提示：判断一个任务该给谁，先问自己“这个答案错了能不能一眼看出来”。能一眼看出来的，多半适合推理模型；要靠经验和审美判断的，交给通用模型更划算。

2.2 任务分层：六类活分别派给谁

把常见任务摊开看，选型其实没那么纠结。数学证明和复杂度分析属于典型推理任务，模型必须保持一条自洽的链，中途偏一步结论就废；代码生成和调试同理，语法能跑只是底线，边界条件才是真考验。反过来，营销文案、社交媒体内容、剧本对话这类任务，评价标准是“读起来对不对味”，强行让模型走严密推理，出来的东西会干巴巴。

还有一类夹在中间的：长文本摘要、结构化信息抽取、多语言翻译。这些任务既要准确又要覆盖面，实际做法是先用通用模型跑一版，再用推理模型做一次“结论复核”，把数字、实体、因果关联单独拎出来验一遍。这套组合拳在报告类文本上特别有效，因为摘要出错通常不是语言问题，而是漏读和错配。

我一般会在这张表的基础上再做一次反向检查：如果某个任务我用推理模型跑出来还是不满意，大概率不是模型不行，是我把“约束”和“步骤”混在一起写了。约束是必须保留的（字数、格式、禁用词），步骤是应该删掉的（先做什么再做什么）。

2.3 把选型写成判定函数：一个可抄的路由脚本

手工判断做几次就烦了，尤其是批量跑任务的时候。我的做法是写一个轻量路由函数，先用关键词打分做兜底，再由人工复核边界样本。注意它只是分流器，不负责保证质量，真正的质量还是靠提示语。

# 任务路由：按任务描述粗分到推理模型或通用模型 REASONING_HINTS = ("证明", "推导", "复杂度", "根因", "算法", "对比", "为什么", "校验") GENERAL_HINTS = ("文案", "故事", "改写", "翻译", "起标题", "扩写", "口播") def route(task: str, min_score: int = 1) -> str: """返回 'reasoning' 或 'general'，score 相同则默认 general（成本更低）""" r = sum(h in task for h in REASONING_HINTS) g = sum(h in task for h in GENERAL_HINTS) if r >= min_score and r > g: return "reasoning" return "general" # 用法 for t in ["证明这个不等式在 n>2 时成立", "给这款咖啡写三条朋友圈文案"]: print(route(t), t)

逻辑很直白：REASONING_HINTS里放的是“有唯一答案、需要多步”的信号词，GENERAL_HINTS放的是“评价靠人”的信号词，两边各命中一次就按数量多的一方走。min_score是阈值，设成 2 会更保守，适合任务描述普遍很长、关键词容易误命中的场景；设成 1 适合短指令。分数相同时默认走通用模型，因为便宜且快，错了再升级。

实际用下来，这个函数的准确率大概七成，剩下三成靠人工看一眼。真正值得记的是它逼你把“任务到底要什么”写清楚——写不清楚的任务，路由函数也给不出靠谱答案，这本身就是个信号。

3. 提示语设计：四种策略与五种需求的落地写法

3.1 四种策略的边界：指令驱动、需求导向、混合模式、启发式提问

资料里把提示语策略分成四类，我觉得这个划分比“提示词模板大全”实用得多，因为它讲的是“什么时候别管太细”。指令驱动是直接给步骤和格式，适合简单、需要快速执行的任务，优势是结果稳定，风险是把模型的自主优化空间压没了；需求导向是只描述背景和目标，让模型自己规划路径，适合复杂问题，但需求边界必须写清楚，否则它会往你觉得无关的方向跑。

混合模式是日常最常用的：给目标和关键约束，剩下的交给模型。比如“设计一个三日行程，必须包含两个博物馆，总预算控制在一千五以内”，目标、约束都给了，但没规定先去哪后去哪。启发式提问则是用“为什么”“如何”触发模型自解释，适合排查自己的理解盲区，风险是容易跑题，问完得把它拉回来。

有个反直觉的结论值得单独说：对推理模型用角色扮演类提示，效果经常是负的。你让它“扮演一位十九世纪的历史学家”，它会把注意力分到人设维护上，逻辑主线反而松了。角色设定更适合放在通用模型的多轮对话里，或者放在整段对话的最后一轮做风格收敛。

3.2 五种需求的表达公式：决策、分析、创造、验证、执行

把需求分类比把提示语分类更有用，因为用户脑子里想的其实是“我要一个决策”还是“我要一个验证”。决策需求的公式是目标加选项加评估标准，缺了评估标准，模型只能给你一篇“各有优劣”的和稀泥；分析需求是问题加数据加分析方法，方法不给，它就只做表层归类；创造性需求是主题加风格约束加创新方向，只给主题等于让它随机游走。

验证需求最容易被低估。你手里有一个结论，想让它查一遍，正确写法是把结论、验证方法和风险点一起给：结论是什么、数据在哪、按什么标准判断显著性、可能在哪出问题。只写“帮我看看这个结论对不对”，得到的多半是复述。执行需求则是任务加步骤约束加输出格式，这类最适合推理模型，因为它需要的是把步骤做对而不是想出新东西。

实际操作里，这五类经常混着用。一个真实请求往往是“先分析再决策”：先把数据趋势讲清楚，再在两个方案里选一个。这时候拆成两轮比塞进一段更稳，第一轮的输出就是第二轮的上下文。

3.3 三要素模板：把指令、上下文、期望拼成可复用的 prompt

提示语的基本结构就三块：指令说清任务，上下文提供背景，期望定义输出形式和边界。难点不在知道这三块，而在不同模型上配比不一样。推理模型可以只给指令和期望，上下文一句带过；通用模型需要把上下文写厚，还要补上步骤引导。我一般用一个构造函数把差异吃掉，调用方只管填内容。

def build_prompt(task, context, expect, model_type="general", steps=None): """拼装提示语：推理模型走精简分支，通用模型走补偿分支""" if model_type == "reasoning": # 推理模型：只给目标、背景、输出要求，不塞步骤 return f"{task}\n\n背景：{context}\n\n输出要求：{expect}" # 通用模型：显式给步骤，缺什么补什么 default_steps = "1. 说明你的分析思路\n2. 给出结论\n3. 列一条自检项" body = "\n".join(steps) if steps else default_steps return f"{task}\n\n背景：{context}\n\n请按以下步骤作答：\n{body}\n\n输出要求：{expect}" print(build_prompt( task="评估把缓存层从本地换成集中式的影响", context="现有 QPS 约 800，读多写少，团队没有专职运维", expect="给出三条风险和一条上线前的验证动作，不超过 300 字", model_type="reasoning", ))

task只写动作和对象，不要夹带步骤；context是模型判断的依据，宁可多写两句业务背景，也别让它猜；expect必须包含长度和格式，这是最省事的质量杠杆。model_type决定走哪条分支，steps只在通用模型分支生效，传了会覆盖默认三步。

我踩过的一个坑是：expect里写“详细一点”，模型会给你八百字废话；写“不超过 300 字，每条风险后面跟一个可观测指标”，输出立刻收敛。长度约束不是为了省 token，是逼模型做取舍。

4. 接进工作流：代码任务、长文本与批量调用

4.1 代码生成与调试：把“能跑”写进提示里

代码任务是推理模型的主场，但提示语写歪了照样翻车。有效的写法是把输入、输出、约束三件事说死：输入是什么类型、输出要什么格式、时间复杂度或依赖库有什么限制。别写“写个排序”，要写“用 Python 实现快速排序，输入是整数列表，输出新列表，不修改原列表，加注释说明分区逻辑”。后面这串约束看着啰嗦，其实每一条都对应一类常见错误。

调试场景反过来，要给的是错误信息和上下文，不是“帮我看看哪里错了”。我的习惯是把报错栈、相关函数、已经试过的改法一次性贴进去，然后要求它先复述问题再给方案。复述这一步很关键，模型理解偏了你在复述阶段就能发现，不用等它写完一版错的代码。

import os from openai import OpenAI client = OpenAI( api_key=os.environ["API_KEY"], base_url=os.environ["BASE_URL"], # 填控制台给的兼容端点 ) def review(code: str) -> str: resp = client.chat.completions.create( model=os.environ["MODEL_NAME"], # 推理模型与通用模型的模型名不同，从控制台取 messages=[ {"role": "system", "content": "你是代码审查员。先复述这段代码在做什么，再列问题，最后给改法。"}, {"role": "user", "content": f"代码如下：\n{code}\n\n关注点：边界条件、异常路径、复杂度。"}, ], ) return resp.choices[0].message.content print(review("def avg(xs):\n return sum(xs) / len(xs)"))

参数上，model从环境变量读，避免把模型名写死在代码里；system里那句“先复述”是刻意加的，它对推理模型尤其管用，能把跑偏的概率压下去。温度这类采样参数我一般先不设，跑通了再按需调；部分推理模型对采样参数不敏感甚至忽略，设了没效果别以为是接口坏了。

注意：base_url和模型名以你所用服务方的控制台为准，不同渠道的命名和可用参数不一样，照抄别人的配置是最常见的“跑不通”原因。

4.2 长文本摘要与结构化输出：用 schema 锁住格式

长文本摘要最容易出的问题是“漏”和“飘”：漏掉后半部分内容，或者把原文数字改写成约数。解决办法不是让它“仔细读”，而是给它结构：先列章节清单，再逐节压成一句话，最后合并。结构化输出同理，要在提示里给出字段名、类型、取值范围，而不是只说“输出 JSON”。

import json REQUIRED = {"title", "summary", "keywords", "risk"} def parse_payload(raw: str) -> dict: """去掉代码围栏和寒暄，再校验字段是否齐全""" text = raw.strip() if text.startswith("```"): text = text.split("\n", 1)[1] # 丢掉首行围栏 text = text.rsplit("```", 1)[0] # 丢掉尾部围栏 data = json.loads(text) missing = REQUIRED - data.keys() if missing: raise ValueError(f"缺字段: {missing}") if not isinstance(data["keywords"], list): raise TypeError("keywords 必须是数组") return data

这个函数做三件事：剥掉模型爱加的代码围栏、校验必需字段、校验字段类型。REQUIRED就是你的 schema 下限，字段名要跟提示里写的完全一致，大小写都别松。校验失败不要直接抛给用户，重试一次并把报错原文塞回提示，通常第二次就对了。

提示侧对应的写法是给一个空模板，让模型往里填，而不是让它自由发挥。模板里每个字段后面用括号标类型和长度，比如“summary（字符串，不超过 120 字）”，比事后校验省事一半。

4.3 批量调用与结果落盘：一个最小可用的脚本框架

单次对话调通了，接下来就是批量。批量脚本的坑集中在两个地方：一个请求失败带崩整批，以及跑太快触发限流。所以框架里必须有两样东西——每条任务独立捕获异常，以及一个可控的间隔。

import json, time from pathlib import Path IN, OUT = Path("tasks.jsonl"), Path("results.jsonl") def run_one(prompt: str) -> str: """单条调用，真实项目里这里是上面 review() 那类函数""" ... with IN.open(encoding="utf-8") as fin, OUT.open("w", encoding="utf-8") as fout: for line in fin: item = json.loads(line) try: ans = run_one(item["prompt"]) except Exception as e: ans = f"__ERROR__ {type(e).__name__}: {e}" # 错误也落盘，方便事后筛 fout.write(json.dumps({"id": item["id"], "answer": ans}, ensure_ascii=False) + "\n") time.sleep(1) # 控速，避免触发限流

输入用 JSONL 而不是一个大 JSON，好处是可以流式读、断点续跑。错误不抛出而是写进结果文件，前缀__ERROR__方便事后过滤重跑。time.sleep(1)是保守值，任务量大就降到 0.3 并配合重试；如果服务方有并发配额，改成线程池比调 sleep 更划算。结果文件不要覆盖写，按日期分文件名，出问题能回溯。

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

5.1 提示语层的三个坑

第一个坑是给推理模型加“请一步步思考”。现象是输出变长、条理反而散了，有时候还会把已经算对的中间结果改错。原因是这类模型的推理链在训练阶段就内化了，外部再塞分步指令，等于在它自己的链外面又套一层，两个节奏对不上。解决办法很干脆：删掉所有步骤引导，只留任务目标、背景和输出格式，让它自己决定走几步。

第二个坑是对通用模型直接问复杂推理。现象是结论看着像模像样，过程全是编的，数字对不上原文。原因是没有 CoT 补偿，通用模型倾向于用最省力的路径凑一个答案。解决方法是显式要求分步，最好再给一个示例，把“先算什么、再算什么”的骨架搭出来，让它往里填。

第三个坑是给推理模型加角色扮演。现象是它进入人设之后开始跑题，专业问题回答得像散文。原因是角色设定占用了注意力，逻辑主线被稀释。我的处理是把角色放到通用模型那一侧，或者放到多轮对话的最后一轮只做风格收敛，绝不在第一轮就套人设。

5.2 输出与工程层的两个坑

第四个坑是长文本摘要只写“总结一下”。现象是前半段还行，后半段明显敷衍，关键数字被改写成约数。原因是没有结构约束也没有长度约束，模型会选择性地读。解决办法是给章节清单、给每节字数上限、要求引用原文短句作为证据，三件一起上，漏读率会明显下降。

第五个坑是拿到“JSON”直接json.loads。现象是抛JSONDecodeError，报错位置在第 1 行第 1 列。原因是模型习惯在外面包代码围栏、前后加一句“好的，以下是结果”。解决办法是先剥围栏再解析，解析失败时把报错原文回传重试一次，同时用字段校验兜底。这一套做完，批量任务的失败率能从两位数掉到个位数。

提示：这五条里，前三条属于“提示语和模型特性不匹配”，后两条属于“输出没做防御”。排查时先定位属于哪一类，比逐条试错快得多。

6. 进阶：把一次问答固化成可复用的自检回路

单次对话调好了不算本事，能稳定复现才算。我后来固定了一套“三段自检”的用法，成本不高但很稳。第一段是让模型在给结论之前先列验证路径：如果这个结论成立，应该能观察到什么、哪些数据能反驳它。第二段是把同一任务同时丢给推理模型和通用模型，只看两份输出的差异点，差异往往就是风险的藏身处。第三段是记录，把任务类型、所用模型、关键提示语、失败原因写进一张对照表，攒到二三十条之后选型基本不用再猜。

这张表不需要多复杂，四列就够：

真正让这套流程跑起来的，是“差异点复核”这个动作。同一个问题，两份答案如果结论一致，基本可以放心；如果结论相反，多半是某个前提没交代清楚，回去补上下文比继续追问有效。我也试过让模型自己给自己打分，效果一般，它对自身错误的识别率不如对别人的。所以复核这件事最好换个模型来做，或者干脆人工看一眼关键数字。

有个细节值得单独拎出来：给推理模型的提示语里，最好留一句“如果信息不足，直接说缺什么，不要猜”。这句话能挡掉相当一部分幻觉，因为它给了模型一个比“编一个”更省力的出口。同理，验证类任务里加一句“列出你能确认和不能确认的部分”，输出会诚实得多。

从那以后，我每次把新任务接进流程之前，都强制走一遍“选型—写提示—跑两条样本—记一条失败”——哪怕只是一句话的小任务。这套习惯不高级，但它把“这次运气好”变成了“下次也能跑”。希望帮到你。

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