企业官网建设流程全解析

简介：这份由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室出品的103页PDF，面向希望系统掌握DeepSeek、推理模型与通用大模型应用方法的学习者、开发者和内容创作者。它围绕“是什么、能做什么、怎么用、如何从入门到精通”展开，帮助读者建立模型选择、任务拆解与提示语设计的完整认知。压缩包内为1个PDF文件，约5.01MB，单文件结构便于通读与检索。内容覆盖DeepSeek-R1的开源与商用特性、智能对话、文本生成、语义理解、代码生成与调试等场景，并重点比较推理模型与通用模型在数学推导、逻辑分析、创意写作、多轮对话中的优势与局限，还讨论链式思维下的“快速反应”与“慢速思考”差异及提示语策略。已有363人学习，适合希望把AI用得更好、更出彩的读者循序渐进。

1. 103 页的 DeepSeek 课件：卡住大多数人的是「选哪一档」，而非「会不会用」

上周同一个需求，我让两位同事各写一遍提示语：一位把整段需求直接交给推理模型，一位拆成六步交给通用模型。前者给出的方案结构清楚、边界明确，后者的排版更顺眼，但关键结论含糊。差别不在谁更会用人工智能工具，而在有没有先判断任务该交给哪一档模型。这份 103 页的 DeepSeek 材料，来自某高校新媒体研究团队，把内容拆成三块：DeepSeek 是什么、能做什么、怎么从入门到精通。它没有停留在“文本生成”“自然语言处理”这类名词解释上，而是把推理模型与通用模型的分工、提示语的三段结构、五类需求的表达公式，写成了能照着填的模板。做产品、运营、开发、写作的人都能用，尤其是已经把对话工具用成「高级搜索」、想再往前走一步的那批人。

2. 推理模型与通用模型：选型错了，提示语写得再漂亮也白搭

先讲清楚一件事：模型没有「谁更强」这回事，只有「谁更对路」。这份材料在开头就把两类模型的能力边界画了出来，这部分比后面所有提示语技巧都值得反复看，因为选型一旦错了，后面写多少字都是在弥补能力错配。

2.1 快思考与慢思考：两类模型的原理差异与能力边界

通用大模型的底层是概率预测：给定上文，预测下一个最可能的词。它一次前向计算就出结果，响应快、算力成本低，训练目标是「在大量文本里学会语言规律」，所以它在语言生成、上下文理解、文本分类、翻译这类任务上很稳。推理模型的路线不一样，它在给出最终答案之前，先生成一段内部的推理链，把问题拆成若干步再收口，训练时用强化学习去奖励「推得对」的过程。代价是慢、贵；收益是逻辑密度高的任务不容易崩。

材料里有个说法很到位：强弱判断不能一刀切。推理模型只在它训练目标覆盖的领域显著优于通用模型，数学推导、逻辑分析、代码生成、复杂问题拆解这几类是它的主场；一旦进入发散性任务，比如写诗、起名、想十个不同方向的广告语，它反而会掉分，因为它习惯把问题快速收敛成一条推理主线，而创意任务恰恰需要发散。反过来，通用模型遇到需要严格逻辑链的数学证明，很容易跳步，看着像模像样，中间少了一环。

提示：判断模型强弱之前，先判断任务属于「逻辑密度高」还是「多样性高」。这个判断花十秒，能省后面十分钟的返工。

材料把这种分野叫「快思慢想」，源头是链式思维（CoT）的出现——它把大模型劈成了两类：一类靠概率快速反应，一类靠链式推理慢速思考。这个划分不是学术分类，是实操分类：你手上这个任务，到底需要「快而广」还是「慢而准」，答案直接决定你把需求压给谁。

2.2 从任务类型反推模型：五类需求的匹配表

光知道两类模型的差异还不够，落到工位上，你面对的是「帮我降本」「分析这份数据」「设计个方案」这种模糊表述。材料把需求归成五类，每类给了默认模型和提示语侧重，这张表我建议直接抄进团队文档。

这张表里最容易搞反的是「验证需求」。很多人拿到一份报告的结论，直接问模型「这个结论对吗」，通用模型会顺着你的语气给一个肯定答复，因为它擅长的是顺着上下文生成合理文本，不是挑错。正确做法是把结论、原始数据、验证方法一起给，并且明确要求它排查矛盾点——这类活推理模型更靠得住。

同样容易搞反的是「创造性需求」。有人觉得推理模型「更聪明」，写文案也用它，结果出来一版四平八稳、逻辑通顺但毫无记忆点的稿子。创意任务要的是多样性，通用模型配合明确的风格约束，产出反而更活。

2.3 三步落地：任务打标、小样本试跑、定档写清单

知道原理不等于会用，落地要压缩成能重复执行的步骤。我一般的做法是三步，每步都有明确的产出物。

第一步，任务打标。把团队近两周真实提给 AI 的请求捞出来，每条打两个标签：任务类型（上面五类之一）、逻辑密度（高/中/低）。这一步不用工具，一张表就够，二三十条就能看出规律——通常你会发现，八成请求集中在两三类任务上。

第二步，小样本试跑。每类挑 3 条真实请求，两个模型各跑一遍，按「可直接用 / 需小改 / 重写」三档打分。这里有个细节：打分要看结论对不对，不看排版顺不顺眼。排版是通用模型的天然优势，容易被它带偏判断。

第三步，定档写清单。把试跑结论固化成一句话规则，比如「涉及金额核算与方案对比的，一律走推理档；文案变体、格式转换走通用档」。规则写进团队文档，新人不靠感觉猜。

注意：定档规则不是一次定终身。模型版本迭代很快，同一个任务半年前该走推理档，现在可能通用档就够了。我习惯每季度拿那批试跑样本重跑一遍，看评分有没有位移。

3. 提示语的三段结构：指令、上下文、期望怎么填才不漏

提示语这件事被讲得太玄，其实拆开就三个槽位：你要它干什么、它在什么背景下干、你想要什么形态的结果。这份材料把这三个槽位讲透了，还按模型类型给了两套写法，这部分是整份材料里最能直接抄作业的。

3.1 三个槽位与填写顺序：先给背景，再给任务，最后锁形态

三个槽位的定义不复杂：指令是核心，明确告诉模型执行什么任务；上下文提供背景信息，帮它准确理解；期望明确或隐含地表达你对输出的要求。难的是顺序和详略。

我推荐的填写顺序是：背景与约束 → 任务指令 → 输入材料 → 输出形态 → 判定标准。为什么把背景放前面？因为模型是顺着上文生成的，前文定调，后文才不容易跑偏。很多人习惯把要求堆在最后一句，写到第五行才说「不要用行业黑话」，前面四行已经把风格带跑了。

这张表里最容易被跳过的是「判定标准」。写清楚「如果数据不足以支撑结论，直接说不足，不要给推测」，比任何技巧都管用，它把模型从「必须给出一个答案」的压力里解放出来了。

3.2 推理模型少说，通用模型补课：两套写法的差异

材料里有一句关键原则我完全认同：推理模型提示语更简洁，只需明确任务目标和需求，因为它已经内化了推理逻辑；通用模型需要显式引导推理步骤，否则可能跳过关键逻辑。这不是风格偏好，是能力结构决定的。

对推理模型，强行拆解步骤反而是干扰。你写「先分析 A，再分析 B，然后对比，最后给结论」，等于把它内化的推理链换成你的推理链，它的优势就被抹掉了。对通用模型，你不给步骤，它就按最省力的路径生成，中间环节直接跳过。

# 推理模型写法：只锁目标和边界，过程交给它 任务：为下面的登录流程给出优化方案。 背景：日活 8 万，登录失败率 3.2%，其中 60% 集中在验证码环节。 约束：不改动现有第三方鉴权，不改前端框架。 输出：按「瓶颈定位 / 三种方案 / 各自代价 / 推荐」四段写，不超过 800 字。 如果现有数据不足以定位瓶颈，直接指出缺哪项数据。

# 通用模型写法：把步骤铺开，每一步给输入输出 任务：把下面这段 C 语言代码转成 Python。 步骤： 1. 先列出原代码的输入、输出和边界条件； 2. 逐段翻译，保持时间复杂度不变； 3. 用 numpy 重写数组操作部分； 4. 补三个测试用例，覆盖空输入、超长输入、异常输入。 输出：先给转换后的完整代码，再给测试用例，最后列出你做的三处取舍。

两段模板的差别很直观：第一段只有四行约束，第二段有四个明确步骤。把这两段互换着用，效果会明显打折——推理模型拿到步骤模板会变得机械，通用模型拿到简洁模板会漏掉边界条件。

材料还提了两个误区，都是实操里高频出现的：不要对推理模型使用角色扮演这类启发式提示，可能干扰它的逻辑主线；不要对通用模型过度信任，直接问复杂推理问题，必须分步验证结果。角色扮演对通用模型有效，是因为它擅长顺着设定生成；对推理模型，设定越花，它越容易把注意力放到「演得像不像」上。

3.3 五类需求的表达公式与可抄模板

材料把每类需求都给了公式和示例，这是整份文档里复用率最高的部分。公式本身不复杂：决策需求是「目标 + 选项 + 评估标准」，分析需求是「问题 + 数据 + 分析方法」，创造性需求是「主题 + 风格约束 + 创新方向」，验证需求是「结论 + 验证方法 + 风险点」，执行需求是「任务 + 步骤约束 + 输出格式」。

# 决策类 背景：区域仓配成本连续两季度上涨 11%。 选项：A 自建区域仓（初期投入高，长期单位成本低）；B 第三方合作（按需付费，单价高但灵活）。 要求：按五年总成本建模，列出你用的假设，给出推荐项和触发转向的条件。 如果关键假设缺失，先列出需要我补的数据。

# 分析类 数据：附件是近三年某品类销量明细（字段：月份、区域、渠道、销量、退货量）。 问题：增长趋势与退货率之间是否存在关联，关联是否稳定。 方法：先做趋势分解，再算分区域相关系数，最后指出样本量不足的区段。 输出：结论在前，方法在后，所有数字标出来源字段。

# 验证类 待验证结论：方案 A 的转化率显著优于方案 B。 请做三件事：一是检查两组样本量是否匹配；二是判断显著性检验的选型是否合适；三是列出会让这个结论失效的三种情形。 不要给「基本可信」这类模糊判断，要么指出具体缺陷，要么说明结论成立的前提。

这三段模板可以直接改成自己业务的字段。写的时候有个通用原则：模板里凡是出现「优化」「提升」「更好」这类词，后面必须跟一个可量化的口径，否则模型会按最宽泛的理解去执行，产出一堆正确但没用的建议。

4. 三条落地线：文本、代码、文件，各自的打法不一样

入门到精通的分水岭，不在会不会写提示语，而在能不能把任务拆成可复用的流程。这份材料覆盖的场景很杂，从文章诗歌到代码调试到图片文字识别都有，但按落地方式归类，其实就是三条线，每条线的打开方式不同。

4.1 长文本摘要与改写：先切块、再定锚、最后校验

直接把八十页 PDF 丢进去说「总结全文」，拿到的基本是目录复述，因为模型倾向于抓住标题层级这类显眼结构，而不是内容主干。我一般分三步走。

第一步切块。按章节或按主题切，单块控制在模型能完整读完的体量内。切块不是越细越好，切到「一段一个块」反而丢了上下文，结论会碎。常见做法是按逻辑单元切，比如一份调研报告按「背景 / 方法 / 发现 / 建议」切四块。

第二步定锚。每块给一个明确的抽取任务，并且规定输出结构，比如「这块只抽三类信息：数据结论、方法局限、和上一块的矛盾点」。锚定的作用是压掉模型的发散倾向，你抽什么它给什么。

第三步校验。让模型在做完摘要后，单独列一份「本段没有覆盖到的内容」，这份清单比摘要本身更有价值——它告诉你哪里可能漏了关键信息，尤其是数字和限定条件。

改写比摘要更考验约束。改写要明确三件事：目标读者、允许改动的范围、必须保留的原话。比如把技术文档改成客户能看懂的白话版，要写清「术语可以替换成类比，但指标口径和数字不许动」，否则模型会把「P99 延迟 200ms」改写成「响应很快」，信息就丢了。

4.2 代码生成与调试：把报错当主要输入

代码这块，材料列了代码生成、错误分析与修复建议、性能优化提示、API 文档生成、代码库解释与示例生成几类。实际用下来，最高频也最值钱的是「错误分析」——不是让它从零写代码，而是把一段真实的报错喂进去。

喂报错有个前提：报错得先裁。生产环境的堆栈动辄几百行，框架内部帧占了大半，全贴进去模型会把注意力放在无关的调用层级上。我写了个小工具做这件事，每次调模型之前先跑一遍。

# err_trim.py # 作用：把长堆栈裁成模型能读懂的最小片段，避免无关帧干扰判断 import re def trim_traceback(raw: str, keep_frames: int = 3) -> str: lines = raw.strip().splitlines() # 1. 只保留最后一段 Traceback：多线程/异步场景下前面常混有无关报错 idx = max((i for i, l in enumerate(lines) if l.startswith("Traceback")), default=0) tail = lines[idx:] # 2. 只保留最后 keep_frames 个调用栈帧：前面的多为框架内部帧，定位价值低 frames = [l for l in tail if l.strip().startswith('File "')] drop = set(frames[:-keep_frames]) if len(frames) > keep_frames else set() kept = [l for l in tail if l not in drop] # 3. 异常类型与消息行必须保留，否则模型只能靠猜 return "\n".join(kept).strip()

这段代码三个动作对应三个判断。第一处取最后一段 Traceback，是因为异步或线程池场景下日志里会串进多条堆栈，取错一段等于给模型看别人的错误。第二处keep_frames参数控制保留几帧，默认 3 帧，业务代码一般两层调用就到底了，留太多反而稀释信息；如果你的报错出在深层递归里，把这个值调大。第三处保留异常行是硬要求，把KeyError: 'user_id'这种关键线索裁掉，模型只能泛泛地说「检查字典键」。

裁完再配一段固定的提问模板，效果比随手问稳定得多：

# 调试提问模板 环境：Python 3.10，依赖版本见下方 requirements 片段。 操作：执行批量导入脚本，处理到第 1200 条记录时报错。 报错：（粘贴裁剪后的堆栈） 已排查：确认源文件该字段非空，确认编码为 utf-8。 请按顺序回答：一、最可能的三个原因，按可能性排序；二、每个原因对应的验证方法，要能直接执行；三、如果三种都不成立，下一步该收集什么信息。 不要直接给修复代码，先给定位路径。

最后一句是关键。很多人一上来就要「给我修复后的完整代码」，模型会给一版看起来能跑的，但你不知道它改了什么，下次同样的错还会犯。先要定位路径，再要修复方案，中间自己验证一次，才是可积累的经验。

4.3 文件上传、OCR 与联网检索：能用，但别指望它替你核对

这类工具支持上传文件、读取图片中的文字，也支持联网检索。这三项能力的边界得先摸清楚，不然容易在关键场合翻车。

扫描件识别这一项，我踩过最实在的坑是表格串行：三列的数据被读成一列，数字和单位错位，模型后续分析全建立在错位数据上，输出还挺像回事。所以凡是扫描件里的表格，我现在的做法是先让人眼过一遍关键数字，再让模型做结构化整理，顺序不能反。

联网检索也一样。它能帮你快速拿到「近期有哪些相关讨论」这类线索，但来源是否可靠、数据口径是否一致，得你自己判断。让模型把检索到的信息按「来源类型 / 发布时间 / 可核实程度」列成表，比让它直接下结论有用得多。

5. 避坑与排查：五条踩过的坑，每条都能对上号

这部分是整份材料里没有、但实际用起来最费钱的地方。下面五条按「现象 → 原因 → 解决」写，都是我在真实任务里翻过的车。

5.1 输入侧的三类坑：模型没变笨，是你喂错了

坑一：把推理模型当角色扮演用。现象：给推理模型写「你是一位有二十年经验的架构师，请用你的专业视角分析……」，输出变得又长又空，全是行业套话。 原因：推理模型的内化推理链被角色设定挤占了注意力，它开始优先满足「演得像专家」，而不是「把问题推对」。 解决：删掉角色设定，直接给问题、约束、输出结构。需要专业视角，就在约束里写「按架构评审的关注点组织：可用性、成本、演进路径」，不用演。

坑二：上下文塞太满。现象：把三份历史文档、五段聊天记录全贴进去，模型的回答开始抓错重点，问你「关于第二部分提到的 X……」，而你根本没提过 X。 原因：材料越长，关键约束在上下文中的权重越被稀释，模型对「当前这一条要求」的敏感度下降。 解决：只留和当前任务直接相关的材料，其余用一句话概括。判断标准很简单：这段材料删掉之后，任务还能不能完成？能，就删。

坑三：期望写在最后一段。现象：前面写了三百字背景，末尾补一句「输出成表格」，结果给的是散文。 原因：模型按顺序生成，前文定调后，末尾的格式要求容易被当成补充说明而非硬约束。 解决：把输出形态提到指令之后立刻写，或者单独成段用「输出要求：」开头。格式要求越靠前，遵守率越高。

5.2 输出侧的两类坑：看起来对的答案最危险

坑四：拿通用模型直接问需要严格逻辑链的问题。现象：让它算一笔分润，给出一个数字，小数点后两位，看着很专业，你按它复算一遍对不上。 原因：通用模型做的是概率预测，数字是「看起来最可能的数字」，不是算出来的。 解决：涉及金额、比例、多步核算的，要么走推理档，要么在提示语里强制它写出每一步中间结果，并且要求「最后单独列一行复算校验」。凡是复算校验缺失的输出，一律不用。

坑五：把模型的自信当结论可靠。现象：一份结论明确的验证报告，语气笃定，条理清楚，交上去被业务方一句「这个数据源上个月就换口径了」打回。 原因：模型对自身的知识边界没有可靠感知，缺信息时倾向于补全而不是承认缺失。 解决：在提示语里显式给一条出口——「若信息不足以支撑结论，先列出需要补充的信息，不要给出推测性结论」。另外养成习惯：凡是要往外发的结论，先让模型自己列三条「这个结论可能错在哪」。

注意：这五条坑有个共同点——问题的根源大多在输入侧，不在模型侧。遇到输出不对，先回头检查提示语里少了哪个槽位，比换模型有效得多。

6. 进阶：把 103 页压成一张自己的提示语清单

材料里的模板很多，但真正的门槛是建立一套自己的复用机制。我现在的做法是维护一张提示语清单，字段固定：编号、适用任务、默认模型档位、模板正文、回归样本、上次验证日期。模板正文就是前面那种代码块，回归样本是三条真实请求加期望要点，上次验证日期用来提醒自己什么时候该重跑。

模板多了以后，靠人肉跑回归不现实，我写了个小脚本把清单里的样本批量跑一遍，只输出和上次结果的差异点，人工只看差异。

# prompt_regress.py # 用途：批量重跑提示语清单里的回归样本，只打印与上次不一致的条目 import json, hashlib def fingerprint(text: str) -> str: # 归一化后取指纹：去掉空白差异，避免排版变化被误判为结果变化 return hashlib.md5("".join(text.split()).encode()).hexdigest() def run(call_fn, cases, last_record): # call_fn 由使用者注入，负责真正调用模型；本脚本不绑定任何具体服务 diffs = [] for c in cases: out = call_fn(c["prompt"]) fp = fingerprint(out) if last_record.get(c["id"]) != fp: diffs.append({"id": c["id"], "output": out, "fp": fp}) return diffs if __name__ == "__main__": with open("cases.json", encoding="utf-8") as f: cases = json.load(f) with open("last.json", encoding="utf-8") as f: last = json.load(f) for d in run(lambda p: p, cases, last): # 占位实现，接入时替换 print(d["id"], d["fp"])

fingerprint做归一化是关键，不然模型输出多一个空格就被判成变化，误报会把你的信任耗光。call_fn用注入的方式传进来，是为了让脚本和具体服务解耦，换环境不用改脚本。最后一行的占位实现提醒你：这份脚本本身不产生任何调用，接入时替换成自己的调用逻辑。

从那次把扫描件表格直接喂进去、拿到一份错位数据做的分析报告之后，我每次用这类工具处理带数字的材料，都强制走一遍「人眼核对关键数字 → 模型做结构化 → 再核对」的三步。慢是慢了点，但比返工便宜。希望帮到你。

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