简介：《清华大学第三弹：普通人如何抓住DeepSeek红利》PDF面向普通用户、职场人与学习者，围绕DeepSeek是什么、能做什么以及如何提问展开，帮助读者在工作、学习、生活和社会关系中理解并应用大模型。内容涉及提示词驱动的新生产力、答案鉴别与再创造、智慧赋能的决策力，并结合能力图谱、深度思考过程和项目书撰写等案例，说明从提出问题到形成方案的基本路径。资源包共1个PDF文件，大小约4.47MB，便于直接阅读与检索。已有755人学习，适合希望系统认识DeepSeek、提升自然语言处理与知识推理应用能力的初、中级读者参考。

1. 拆开这份 DeepSeek 手册之前，先说清它能替你省掉哪几个小时

下午三点零五分，某公司的项目负责人接到通知：一份一万字的智能物流园区方案书，四点前必须交，手头只有散乱的会议记录和几份过时模板。这个开场不是段子，是一份高校研究团队编写的 DeepSeek 应用手册里原样给出的案例，用来演示大语言模型在真实工位上的落地路径。这份手册讲清了三个层面的事：DeepSeek 作为推理模型的能力边界、提问的结构化方法，以及写方案、熟悉新东家、回客户、请假四个具体场景的完整操作流程。它面向的是不写代码但每天处理大量文本的职场人，也适合想把流程固化下来的技术同学。真正值钱的地方不是“AI 很强”这类结论，而是一批能直接抄的指令模板和一套按分钟切分的时间预算。

2. 能力图谱怎么读：从大语言模型到四个能落地的工作场景

2.1 推理型模型和普通对话模型，差别落在哪一步

手册对 DeepSeek-R1 的描述很克制：开源的推理模型，后训练阶段大规模使用强化学习技术，在仅有极少标注数据的情况下提升模型推理能力，数学、代码、自然语言推理是它的强项，并且可以免费商用。这几个定语不是宣传语，它们直接决定了你该怎么用它。

普通对话模型的工作方式是“顺着往下写”，它擅长把已有信息组织成通顺文本；推理模型多了一层中间过程，会先把问题拆开、尝试路径、再给结论。落到实际操作上，差异体现在三件事：一是你给它一道需要多步计算的题，比如“占地 500 亩、日均 50 万件包裹，自动化分拣设备该配几台”，普通模型容易直接编一个数字，推理模型会把假设、公式、中间量摆出来，你能看到它在哪一步拐错了弯；二是它可以被要求“先列思路再写正文”，这一步在长文档场景里极其关键；三是它更吃输入质量，材料给得含糊，它会花大量中间步骤去猜，输出反而更啰嗦。

手册里反复提“深度思考模式”，本质就是把这条中间链打开。我在实际使用中的判断标准是：凡是答案需要跨三段以上材料推导、或者需要做数值估算、或者需要判断因果关系的活，就开；凡是纯改写、纯格式转换、纯润色，关掉反而更快更稳，因为推理链会引入不必要的自我发挥。

还有两个容易被忽略的能力点，手册里提到了但很多人扫过去：支持联网搜索，以及支持文件上传并读取各类文件和图片中的文字。前者意味着你不必把行业数据手工粘进对话框，后者意味着你可以直接把行业报告、竞品资料丢进去让它做整合。这两点组合起来，才构成了后面场景 2 里“新人快速熟悉行业”的可行性基础。

2.2 能力图谱不是功能清单，是输入形态的索引

手册列出那张很长的能力图谱时，容易让人误以为是在罗列卖点。我读第二遍才发现，它真正的组织逻辑是按“你手上有什么”来分的：手上是一段文字、是一份文档、是一张图、还是一个需要外部信息才能回答的问题。按这个维度重新切一遍，图谱立刻变得可用。

这张表最右边的列比左边三列更重要。手册在“善用 DeepSeek 的两大关键”里写得很清楚：提出问题、鉴别答案。能力图谱告诉你“能接什么活”，边界列告诉你“接完之后你必须自己补哪一刀”。很多人把 AI 用翻车，不是因为提示词写得差，而是把边界列的事也一并交出去了。

2.3 四个场景拆成输入、处理、输出三段

手册给了四个场景，写方案、新人熟悉公司与行业、客户沟通与问题反馈、项目中请假开口。表面看是四个不相干的故事，拆开看是同一种结构：先把散落的信息收敛成输入，再让模型做一次结构化处理，最后人对着输出做取舍。

这个表的价值在于它把“AI 替我干活”拆成了四段责任。中间那列是可以外包的，两边两列不行。手册在场景 1 里有一句提醒写得挺狠：所有 AI 生成的数据加“（示例）”后缀，避免背锅。这句话不是教你免责话术，是提醒你输出里哪些格子是自己签的字。

2.4 选型：哪些活该交出去，哪些必须自己扛

手册后半段有一个判断值得单独拎出来：在 AI 时代，知识获取成本趋近于零，拥有知识不再是核心竞争力，利用提示词创造知识、引领创新、明确方向，才是竞争力所在。这话听起来像口号，落到工位上其实很具体。

它对应的是三种分工。第一种是“知识搬运”，查资料、做摘要、翻译、格式转换、把散乱笔记整理成条目，这类活交出去几乎没有争议，成本下降最明显。第二种是“选择中的再创造”，模型给你五条解法，你挑一条并改成能落地的版本，这一步手册称为批判性思维与逻辑判断，它决定了输出是“AI 味”还是“你的东西”。第三种是“决策”，方案要不要这么报、这个客户能不能承诺交期、这个假怎么请，这类事模型只能提供措辞和备选，拍板的责任无法转移。

我一般按这个顺序判断要不要开对话框：先把任务归类到上面三类中的一类，如果是第一种，直接批量跑；如果是第二种，要求模型给三个以上互斥方案并说明各自代价；如果是第三种，只让它写草稿和反问清单，结论自己下。跳过这一步直接问“帮我写个方案”，得到的东西往往字数很足、每一句都正确、但整篇没有一处是你的判断。

3. 提问模板：把“一次生成想要的东西”拆成五段式结构

3.1 为什么“帮我写个方案”注定拿不到能用的东西

手册在场景 1 里给了很具体的做法：不要一次让模型写一万字，而是分四个阶段，框架、模块填充、软性内容、优化与格式，每个阶段给不同的指令。这个思路背后是一个很朴素的工程判断——模型的单次输出质量和输入约束的密度正相关，和输出长度的要求负相关。

“帮我写个智能物流园区的方案”这句话里，模型需要自己猜的东西至少有七八项：给谁看、什么行业、预算量级、技术深度、要不要政策背书、要不要效益测算、篇幅多少、什么文体。它猜错任何一项，你后面就得返工。而返工的成本远高于一开始把约束写清楚。

手册里那个“强制格式”的技巧我认为是最实用的：要求 AI 输出带编号小标题、分点、表格的内容，粘贴后即显专业感。这不只是视觉技巧，格式约束会倒逼模型把内容分层，减少那种一大段糊在一起的空话。

3.2 五段式骨架：角色与对象、输入材料、约束条件、输出格式、验收标准

我把手册散落在各场景里的指令归纳成一个固定骨架，五个槽位，缺一个就会出问题。这个骨架我用了几十次，改动最小、稳定性最好。

【角色与对象】 你是一名{行业}方向的方案撰写人，读者是{客户方决策层/内部评审/一线执行人员}， 他们最关心的是{成本/工期/合规/效果}。 【输入材料】 以下是已确认的事实，未在此列出的内容一律视为未知： - {会议记录要点} - {已有模板的章节结构} - {硬性指标，如占地 500 亩、日均 50 万件} 【约束条件】 - 篇幅：本小节 {300} 字左右，全文最终 {10000} 字 - 不得编造具体企业名称、具体项目名称、真实人名 - 所有推算出来的数值必须标注“（示例）” - 不确定的地方写成“待确认”，不要自行补全 【输出格式】 - 二级标题用“2.1 功能分区”这种编号 - 技术参数用表格呈现，列名为：设备 / 数量 / 关键参数 / 备注 - 每节结尾用一句话概括本节结论 【验收标准】 - 三个小节之间的口径必须一致，数量与产能要对得上 - 不允许出现“随着……的发展”“为……提供有力支撑”这类空话 - 若某节信息不足，先列出你需要我补充的三个问题，再动笔

这五段里，第四段和第五段是最容易被省掉的，也是最能拉开差距的。输出格式决定了你拿到的东西能不能直接粘进文档；验收标准决定了模型会不会自查。尤其是最后那条“先列出你需要我补充的三个问题，再动笔”，它把一次单向生成变成了半轮对话，返工率能降一大截。

提示：约束条件里的“不确定的地方写成待确认”，比事后自己逐句核对省力得多。让模型主动暴露不确定，比让它自信地编一个答案要好。

3.3 用脚本批量跑模板，避免手工复制粘贴走形

单人用对话框就够了，但只要同一个模板要在十几个小节上重复跑，手工复制就会出问题：漏改关键词、改了这处忘了那处、上下文被上一轮对话污染。常见做法是走 OpenAI 兼容接口写个小脚本，把模板参数化。

# batch_prompt.py # 用途：同一套五段式模板，批量套用到多个小节，减少手工复制导致的走形 import json import time from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", # 换成你自己的密钥，不要写进版本库 base_url="https://api.deepseek.com", # 具体地址与可用模型名以开放平台当前文档为准 ) TEMPLATE = """【角色与对象】 你是一名智能物流园区方向的方案撰写人，读者是客户方决策层。 【输入材料】 {section_name}：{facts} 【约束条件】 - 本小节 300 字左右 - 不编造真实企业名、项目名、人名 - 推算数值一律标注“（示例）” - 不确定处写“待确认” 【输出格式】 - 带编号小标题，技术参数用表格 - 结尾一句话概括本节结论 【验收标准】 - 与相邻小节口径一致 - 不出现“随着……的发展”“为……提供支撑”这类空话 """ def build_prompt(section_name: str, facts: str) -> str: return TEMPLATE.format(section_name=section_name, facts=facts) def run_once(prompt: str, temperature: float = 0.6, retries: int = 3) -> str: for i in range(retries): try: resp = client.chat.completions.create( model="deepseek-chat", # 换成平台当前可用的模型名 messages=[ {"role": "system", "content": "你输出中文，严格遵循格式要求，不写客套话。"}, {"role": "user", "content": prompt}, ], temperature=temperature, max_tokens=2000, ) return resp.choices[0].message.content except Exception as e: # 网络抖动或限流，退避重试 if i == retries - 1: raise time.sleep(2 ** i) if __name__ == "__main__": sections = [ {"name": "2.1 功能分区", "facts": "自动化立体仓库、AGV 调度中心、冷链专区"}, {"name": "2.2 作业流程", "facts": "入库、存储、拣选、复核、出库五段"}, {"name": "3.1 技术风险", "facts": "AGV 系统宕机、分拣线堵塞、冷库温控失效"}, ] result = {} for s in sections: result[s["name"]] = run_once(build_prompt(s["name"], s["facts"])) time.sleep(1) # 控制请求频率，别把额度打满 with open("draft.json", "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2)

代码走的是最朴素的一条路：模板字符串 + 循环 + 落盘。几个参数值得说清楚。temperature设 0.6 是个折中值，往低调到 0.3，输出更稳、更贴模板，但句子会僵；往高调到 0.9，措辞活泛，但格式会飘，编号对不齐的概率明显上升。写方案这类需要“稳”的活，我一般压在 0.5 到 0.7。max_tokens卡在 2000 是为了强制分节输出，一次要一万字反而每节都写不深。retries配合指数退避，是因为长文档批量跑的时候，中途因为限流挂掉一次，前面十几节白跑。system消息里放“不写客套话”，比在每段模板里重复写一遍要省事。

还有一处细节：结果存成 JSON 而不是直接拼成 Markdown。中间产物留成结构化的，后面要改哪一节只重跑那一节，不用整体重来。

3.4 文件上传与长文档处理，别把整本书塞进一个对话框

手册提到支持文件上传、能读取各类文件和图片中的文字。场景 2 里给的操作是：上传行业报告、市场分析、竞争对手资料，再查询“电子元器件行业现状”“未来发展趋势”，生成简洁分析报告。这个流程可行，但有两个前提容易被忽略。

一是上传之前先做目录。如果一份八十页的报告直接扔进去问“总结一下”，模型往往只抓住前三页和目录页，后面的细节全丢。我一般先让它输出一份带页码的结构清单，再指定“只看第 3 章和第 5 章，回答以下三个问题”。这一步多花的三十秒，换来的是引用准确率的大幅提升。

二是把“多源信息融合”当成归并而不是创作。几份报告口径不一致时，正确做法是让它列出分歧点，比如“A 报告给出 12% 增速，B 报告给出 8%，差异可能来自统计口径”，而不是让它自己取个中间值。这个习惯在客户沟通场景里尤其重要，因为你要发出去的那句话，是要担责任的。

4. 一万字方案书的四阶段流水线：五三二十分法怎么排

4.1 为什么必须先堆框架再填内容

手册在场景 1 里给的策略是“框架复制 + 模块填充 + 数据嫁接”，四阶段的时间预算是 5 分钟、20 分钟、20 分钟、10 分钟。这个顺序不是随便排的。

先从模型角度看：一次性要求输出一万字，模型的注意力会被稀释，前面几节写得细，后面几节开始套话，最后变成同义反复。而分四阶段，每个阶段的输出目标都是几千字以内，密度能维持住。再从人的角度看：如果你先看到的是细节，很难判断整体结构对不对；先看到骨架，五分钟就能决定“这个框架能不能交差”，不行就重来，沉没成本极低。

我在实际使用中把第一阶段的目标定得更死：只要求到二级标题，不要任何正文。手册里说的“暴力生成框架”，野蛮的地方就在这——框架阶段不追求准确，追求覆盖度，宁可多列几节，后面再删。

4.2 四个阶段分别该怎么下指令

第一阶段，五分钟，目标是三千字的框架，实际产出是一份目录。指令要短，给的信息要硬。

我要写一份智能物流园区项目方案书，客户方决策层阅读，总篇幅一万字。 现有材料：{粘贴会议记录}。 请输出三级目录，一级 4 章，每章 3 到 4 节，每节用一句话说明这节要解决什么问题。 不要写正文。

第二阶段，二十分钟，目标是六千字的模块填充。这一阶段的技巧手册讲得很明确：针对每个小节单独提问，并且对同类章节使用相同指令模板，仅替换关键词。比如 3.1、3.2、3.3 三节都是风险分析，模板一字不改，只把“AGV 系统宕机”换成“分拣线堵塞”“冷库温控失效”。这么做的好处是行文节奏统一，评审看下来不会觉得是拼凑的。

第三阶段，二十分钟，目标是一千字的软性内容。这里说的软性内容，手册点得很实在：政策背书、风险评估、效益测算。这三块是方案书里“虚但必需”的部分。指令要给公式和假设，不要给结论。

假设园区人工成本减少 30%，分拣错误率下降 25%，日均处理 50 万件。 请用公式推算建成后三年的降本增效收益，列出每年的假设参数和计算过程， 结果保留两位小数并标注“（示例）”。

第四阶段，十分钟，优化与格式。手册给的三个动作是统一话术、生成图表、最终润色。统一话术那句指令可以写成：“将以下段落改写成政府报告风格，加入‘数字化转型’‘双碳战略’等关键词：{粘贴原文}”。最终润色那句更值得记：“检查以下方案书逻辑漏洞，列出 3 个可能被客户质疑的点，并给出应对答案。”这条其实已经在做鉴别答案的事了，只是放在了交付前。

4.3 数据嫁接与“示例”标注，让虚构值不背锅

手册里“数据嫁接”那段话很容易被误读。原文的意思是：若缺乏具体数据，直接让模型生成合理虚构值，并标注“示例”规避风险。注意这里的两个限定，合理、标注。

“合理”意味着它得服从内部一致性。比如你让模型假设园区占地 500 亩、日均 50 万件，然后计算自动化分拣设备配置数量，那设备台数、分拣线速度、人员编制这几个数之间必须能对上。如果你分别在不同对话里问这三个数，很可能得到互相矛盾的结果，粘到一起就成了硬伤。

“标注”则是把责任边界画出来。我一般要求所有推算值统一后缀，并且在方案开头加一句“文中标注（示例）的数据为测算假设，实际以现场勘察为准”。这句话不是免责声明，它让评审知道哪些是可以讨论的、哪些是已经确认的。

# 一致性自检：把同一份方案里出现的数值抽出来，检查关键口径是否打架 import re text = open("draft.md", encoding="utf-8").read() # 抓“数字 + 单位”的组合，单位表按你的行业补充 pattern = r"(\d+(?:\.\d+)?)\s*(台|条|亩|万件|万元|人|平方米)" hits = re.findall(pattern, text) from collections import Counter counter = Counter(unit for _, unit in hits) print("各单位出现次数：", dict(counter)) # 人工核对重点：同一单位下的数值是否在合理区间，是否存在前后矛盾 for num, unit in hits: if unit in ("台", "条") and float(num) > 200: print(f"疑似异常大值：{num}{unit}，建议回查上下文")

这段脚本不做智能判断，只做一件事：把散落在万字文档里的数值捞出来摆在一起，让你一眼看到“2.1 节写 30 台、4.2 节写 80 台”这种事故。参数上，单位表要按你的行业补，物流场景加“台、条、亩、万件”，土建场景就得加“平方米、立方米、层”。阈值 200 是我随手定的经验值，超过它大概率是单位写错或者多打了个零。

4.4 格式控制：表格、编号、三线表这几招什么时候用

手册提到把设备配置表转换成 LaTeX 三线表，插入后自动增加方案厚度。这个技巧成立的前提是你的文档工具支持 LaTeX 渲染，如果不支持，转成普通三线表更实际。格式这件事的判断标准只有一条：读者能不能在三十秒内找到他要的数字。

带编号的小标题解决的是“可引用”问题，评审说“第 3.2 节那个风险应对再补一条”，你得能立刻定位。表格解决的是“可比”问题，设备型号、数量、参数三列并排，比三段文字描述清楚得多。分点列表解决的是“可数”问题，五条风险就是五条，不会看成三条。

至于“标题字体放大、段落间距调宽”这类膨胀页数的做法，我的看法是：如果评审只看厚度，它有用；如果评审真读内容，它会显得心虚。手册自己也写了“若有时间，再精雕细琢”，说明作者知道这是权宜之计。我一般把格式时间压到最后五分钟，前面一律用纯文本加编号，不折腾样式。

4.5 时间预算被打乱时的降级方案

真实工位上很少正好有一小时。手册的四阶段是按 5、20、20、10 排的，如果只剩二十分钟，我的降级顺序是：砍第三阶段，保第一和第二阶段；再砍就只做第一阶段加两节核心内容，其余小节留标题和一句占位说明。留标题这件事听着敷衍，实际上比写一半强——评审看到完整目录，会认为结构清晰，缺的部分可以补；看到写到一半戛然而止，会认为你失控了。

5. 避坑与排查：五条踩过才知道的记录

5.1 现象：字数够了，但整篇读下来没有一处是你的判断

现象很典型：一万字交上去了，每一段都通顺，但通读一遍发现所有结论都是“要重视”“要加强”“要完善”，没有一个数字是你确认过的，没有一个取舍是你做的。

原因几乎总是同一个：把第一阶段到第四阶段一口气跑完，中间没有做选择。模型给的是概率最高的表达，概率最高意味着最安全、最没有信息量。手册里“选择中的再创造”那段话，说的就是这件事——面对 AI 提供的多种解法，人要通过选择最优答案实现解决方案的创新性再生。跳过选择，等于把再创造那一步也交出去了。

解决办法是强制插入一个动作：在每个小节的输出后面，追加一句“这一节我不同意的是哪一条，我要换成什么”。哪怕只改一句，整节的性质就变了。我现在跑批量脚本时，会在结果 JSON 里给每节留一个my_edit字段，写不写都行，但字段必须在，逼自己看一眼。

5.2 现象：同一段提示词，上午能用，下午输出的结构全乱

现象是格式突然不听话了：说好要表格，给了三段散文；说好二级标题带编号，给了一堆加粗短语。

原因通常有两个。一是上下文污染——同一个对话框里前面聊了别的任务，模型把之前的口径带进来了。长对话里这个问题特别明显，跑到第七八节时输出风格会和第一节明显不同。二是提示词过长导致后半段约束被稀释，尤其是五段式模板里“验收标准”放在最后，容易被忽略。

解决办法两条：一是每个小节开新会话，或者用脚本每次只发 system 加一条 user，不带历史；二是把最关键的格式约束在开头和结尾各写一次，重复不浪费字数。我在模板里把“表格列名为：设备 / 数量 / 关键参数 / 备注”这种硬约束放在最前面，实测比放在后面稳定得多。

5.3 现象：表格粘进文档工具后全乱，列宽错位、换行丢失

现象是从对话框复制表格，粘到文档里变成一堆竖线，或者列数对不上。

原因是纯文本表格依赖等宽字体和管道符对齐，一旦渲染环境不同就散架。手册里提到转 LaTeX 三线表，本质是在换一种更结构化的表达。

解决办法分场景：交付给正式文档，让模型输出 Markdown 表格，粘进支持 Markdown 的编辑器再转格式；只要给人看，直接让它输出“用中文顿号分隔的三行清单”，反而不容易乱。我现在的习惯是：四列以内用 Markdown 表，超过四列改成“字段：值”的纵向列表，可读性更好，也不怕错位。

5.4 现象：上传了 PDF，模型说读不到，或者读出来的内容和原文对不上

现象有两种：一种直接报错或说无法访问文件；另一种更麻烦，它能总结，但总结的内容在原文里找不到。

原因上，前者多半是文件太大、页数太多，或者扫描件没有文字层，只有图片；后者多半是跨页表格、双栏排版、页眉页脚干扰，导致抽取出来的文字顺序错乱。手册说支持读取各类文件及图片中的文字，但“读取”和“读懂”是两件事。

解决办法：先在本地确认这份文件能选中文字，选不中的先做 OCR；页数超过几十页的，拆成单章上传，每次只问这一章；遇到双栏排版的报告，让它先复述前三段的原文，验证抽取顺序对不对。这一步验证花不了一分钟，能挡掉后面大量的“它说得挺像但原文没有”的尴尬。

5.5 现象：让它算设备数量，前后两次结果差一倍

现象是同一组假设，问两遍得到两个数字，而且都给不出完整过程。

原因是这类问题需要多步推导，如果提示词里没要求展示中间量，模型会直接给结论，而结论是采样出来的，自然不稳定。另外温度设得太高也会放大这种波动。

解决办法：一是把假设全部显式写进提示词，占地多少、日均多少、单机产能多少，一项不落；二是要求“先列公式，再代入数值，最后给结果，保留两位小数”；三是把温度压到 0.3 以下；四是同一个问题跑两遍，两遍结果不一致的地方，就是你需要自己拿计算器核的地方。这套流程跑下来，数字未必绝对正确，但你能说清它是怎么来的，被追问时不至于哑口。

5.6 排查的通用顺序，别一上来就改提示词

遇到输出不对，我一般按这个顺序过一遍，比直接重写提示词省时间：先看输入材料是否完整、有没有互相矛盾的事实；再看格式约束是否写在开头；再看是不是在同一个长对话里跑了多个任务；最后才怀疑提示词本身。绝大多数翻车发生在第一和第三项，跟措辞关系不大。

6. 从“能生成”到“敢交付”：三道检查和一个交叉验证的小技巧

手册把“鉴别答案”和“提出问题”并列成两大关键，这个并列关系值得琢磨。提问决定了你能拿到什么，鉴别决定了你能用上什么。前一道关卡做得好，后一道关卡的负担就轻；前一道偷懒，后一道就得逐句核对，等于白用。

我现在的习惯是交付前过三道检查，做成一张固定表，逐项打勾，不打完不发。

三道里最容易漏的是第三道。长文档跑到后面，模型会把前面某次对话里的行业词带进来，读起来不突兀，但评审一眼就能看出这段是从别处抄的。

再补一个交叉验证的小技巧：凡是关键结论，让它用相反的角度再论证一遍。比如你写“三年内可降本 30%”，就再发一条“请论证这个园区三年内降本达不到 30% 的三个理由”。两次输出放在一起看，如果反方理由明显更扎实，那段正面的效益测算就该往回调。这个动作花两分钟，比事后被客户问住强。

血泪经验是有一回赶一份材料，第四阶段润色完直接发了，第二天对方回了句“第 4.2 节的设备数量和附件表格对不上”。从那以后我每次交付前都强制走一遍数值抽取和交叉复核，哪怕只剩十分钟也要跑。这套流程不复杂，难的是在赶时间的时候还愿意做。希望帮到你。

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