简介《DeepSeek从入门到精通第二版》是清华大学新媒沈阳团队推出的AI应用指南面向希望借助大模型提升办公与创作效率的职场人、教师及内容从业者帮助读者厘清AI工具的能力边界与协作方式。资源为单份PDF文件压缩包约10.21MB下载后可直接阅读、打印或按章节做笔记适合作为案头速查手册。全书围绕人机共生与自然语言处理展开先辨析基础模型V3、深度思考R1与联网搜索三种模式的适用场景再给出RTGO、CO-STAR等提示语框架以及R1的开放性提问要领同时结合文化创意、科学研究、医疗诊断、法律分析、媒体内容生产等场景说明落地路径并列举英伟达NIM、Azure、AWS等平台上的调用与免费体验入口便于横向比较。目前已有3622人学习适合想系统掌握提示语技巧、建立AI协作方法论的初、中级读者查漏补缺。1. 从「会聊天」到「能交付」提示语工程才是分水岭DeepSeek 用久了会发现一个分水岭有人把它当更聪明的搜索框问一句答一句答完就关掉有人把它当一条能出活的生产线同一份需求进去出来的是能直接贴进周报、能直接进评审会的成品。这份由某高校人机协同方向团队整理的《DeepSeek 从入门到精通第二版》职场应用部分想解决的正是这件事——把提示语技巧从玄学变成流程。它没有停在「怎么问更好」这种经验层面而是先把模型切成基础模型 V3 与深度思考 R1 两条通道再用 RTGO、CO-STAR、CAP 三套结构把需求拆成字段最后落到图表生成、PPT 大纲、行业分析这些具体交付物上背后挂的是自然语言处理与人机共生这套方法论。适合已经用过一阵、但产出质量忽高忽低的从业者也适合要给团队定一套提示语规范的技术负责人。2. 三种模式与两类模型通道选错提示语写得再漂亮也白搭拿到手册的人常做的第一件事是翻到模板页抄一个 RTGO 就跑结果在 R1 上跑得很难看于是下结论说模板没用。问题基本不在模板而在通道。V3 和 R1 不是「新版本替换旧版本」的关系它们是两条训练目标不同的产线一条要把你描述清楚的过程稳定复现出来另一条要在你只给方向的时候自己找路。同一句提示语在两条产线上会得到完全不同的东西先把通道选对后面的字段设计才有意义。2.1 用 5R 维度判断该走哪条通道手册里给了一套 5R 对照把两类模型的差异拆成规范性、结果导向、路径灵活性、响应模式、风险特征五个维度。这套拆法的好处是不靠感觉逐条对号就行。V3 是强规范约束操作路径明确流程标准化按规则执行风险低且稳定可控R1 是弱规范约束操作路径开放多路径探索自主决策不确定性高。听着像 R1 更高级实际用起来恰恰相反越是要求「结果可预期」的活越要压在 V3 上。维度V3 基础模型R1 深度思考Regulation 规范性强约束路径明确弱约束路径开放Result 结果导向目标确定性高结果可预期目标开放性高结果多样Route 路径灵活性线性流程标准化网状多路径探索Responsiveness 响应模式被动适配按规则执行主动创新自主决策Risk 风险特征低稳定可控高不确定性大实际判断时我用一句更土的口诀结果能不能提前描述出来。能说清「一份 800 字、三段、每段带一个小标题、语气克制」的走 V3只能说清「帮我把这个方案的薄弱点找出来、往深里挖」的走 R1。前者你在给规格后者你在给方向。硬把规格塞给 R1它会觉得你在限制它输出反而发散把方向丢给 V3它会给你一份看着齐整但经不起追问的东西。注意这张表限定在文本生成任务上。拿它去推多模态或者代码补全的选型结论会偏。2.2 三种模式的分工基础、深度思考、联网检索三种模式的差别不在「强弱」在信息来源和推理深度。基础模型 V3 面向绝大多数通用任务胜在快和稳深度思考 R1 面向复杂推理和深度分析数理逻辑、代码、根因排查这类活它更擅长联网搜索本质是检索增强生成把外部检索结果拼进上下文解决的是知识时效问题。这三者经常被误用成一个开关——「答案不准就开联网」其实联网只解决「新不新」不解决「对不对」。模式解决的问题典型任务主要代价基础模型 V3通用生成、格式稳定文案、改写、摘要、结构化整理复杂推理容易停在表面深度思考 R1多步推理、自我校验方案对比、逻辑排查、算法设计慢输出长偶有过度推理联网搜索知识时效近期动态、价格、版本变更召回不相关时会带偏结论部署形态上手册列了几种入口网页版直接使用、API 调用、以及部分 GPU 厂商推理微服务和主流云平台提供的模型托管部署注册后有免费点数可以先跑通链路。我的建议是先网页版验提示语再 API 做批量化别一上来就写调用代码——提示语没定稿代码跑一万次也只是把错误放大一万倍。下面是接口调用的最小骨架地址和密钥全部走环境变量避免把凭据写进脚本# 端点和密钥放环境变量脚本本身不进版本库 export DS_BASEhttps://your-endpoint/v1 export DS_KEYyour-api-key curl -s $DS_BASE/chat/completions \ -H Authorization: Bearer $DS_KEY \ -H Content-Type: application/json \ -d { model: model-id, messages: [{role: user, content: 把这段会议记录压成三条结论}], temperature: 0.3, max_tokens: 800 }model填 V3 或 R1 对应的模型标识这是整个请求里最容易填错的一个字段填错等于通道选错后面全白搭。temperature控制采样随机性V3 做结构化输出时我会压到 0.2 到 0.3R1 常见做法是放在 0.5 到 0.7但它内部的推理链有自己的采样策略靠调这个参数提升推理质量基本是徒劳。max_tokens要留够R1 的思考过程会吃掉不少额度设太小会出现「想到一半被掐断」的输出看起来像是模型不会答实际是预算不够。2.3 一个可抄的通道判断流程人工判断之外批量场景需要一层初筛。我一般写一个规则函数把任务文本先过一遍关键词输出建议通道和参数再人工确认# 关键词初筛只做第一层最终通道仍由人确认 REASON_HINTS (证明, 推导, 根因, 算法, 复杂度, 方案对比, 排查) FRESH_HINTS (最新, 近期, 价格, 版本, 上个月, 发布) def route_task(task: str) - dict: 输入任务描述返回建议通道、模型与采样参数 need_fresh any(k in task for k in FRESH_HINTS) need_reason any(k in task for k in REASON_HINTS) if need_fresh: # 时效类任务先检索再生成底层仍用 V3 保格式 return {channel: web, model: v3, temperature: 0.2} if need_reason: # 推理类任务交给 R1提示语要同步改成开放式 return {channel: offline, model: r1, temperature: 0.6} # 默认走通用通道 return {channel: offline, model: v3, temperature: 0.4}这段逻辑的价值不在多聪明在于把「先想通道再写提示语」变成肌肉记忆。channel决定要不要开检索model决定提示语的写法风格temperature只影响表达发散度。三个返回字段里前两个错了是方向性错误第三个错了只是手感问题。关键词表要按自己的业务慢慢补别指望一次写全我这里的词表是踩过几次坑之后才稳定下来的。3. 提示语结构RTGO 四字段与 CO-STAR 六字段怎么填结构的作用不是让提示语变长是让缺失的字段暴露出来。写一句「帮我写个活动推文」你脑子里其实有受众、有渠道、有字数、有禁忌词只是没落到纸上模型只能猜。RTGO 和 CO-STAR 干的就是把这些隐性信息逼出来的事。两者不是竞争关系RTGO 偏执行、字段少、适合 V3 上的标准化任务CO-STAR 偏表达控制、字段多、适合需要调性的内容。3.1 RTGO把「过程-结果」写清楚RTGO 四个字段分别是角色、任务、目标、操作要求。角色给模型一个可锚定的专业身份任务写清具体动作和对象目标写期望达成的效果操作要求把字数、结构、风格、要点、格式全部写死。第四个字段是决定成败的地方很多人前三个字段写得漂亮第四个字段空着输出就会在格式上翻车。# Role 角色 你是一位有十年经验的 SaaS 行业内容运营熟悉 B 端决策链路的沟通方式。 # Task 任务 为一场面向中小企业的产品升级线上活动写一篇公众号推文正文。 # Goal 目标 让读到第三段的潜在客户愿意点开报名链接同时不产生夸大宣传的观感。 # Objective 操作要求 - 字数900 至 1100 字 - 结构痛点场景 / 升级点逐条说明 / 迁移成本说明 / 行动指引 - 风格克制不用感叹号不出现颠覆革命性 - 格式Markdown二级标题四个升级点用有序列表 - 必须包含旧版本用户的数据迁移说明四个字段里Goal最容易被写成空话比如「提升转化」这种没法验收的目标。改成「读到第三段愿意点链接」模型就知道前三段要铺什么。Objective里的否定约束比正向约束更管用「不用感叹号」这种明确禁令效果远好于「语言专业一点」。这份模板可以直接抄把里面行业词换掉就能用改的时候优先改Objective那一栏才是真正决定输出能不能直接用。3.2 CO-STAR六个字段里真正起作用的是哪三个CO-STAR 把上下文、目标、风格、语调、受众、回应类型拆成六块来源是一套竞赛级的提示词框架。字段多不代表都要写满实际用下来真正决定质量的是上下文、受众、回应类型这三个风格和语调在中文语境里高度重叠经常被写成「专业又不失活泼」这类没法执行的词。字段决定什么常见误填改法Context 上下文信息底座「背景如下」后面空着给具体数字、时间、对象Objective 目标输出方向「写得好一点」写可验收的结果Style 风格表达形态「专业活泼」指定文体如调研纪要Tone 语调情绪色彩「友好」指定句式如不用反问Audience 受众用词密度「大众」指定角色与认知水平Response 回应结构格式「随便」指定长度与层级我一般会把 Style 和 Tone 合成一行来写省下来的注意力放到 Context 上。上下文这一栏的投入产出比最高同样一篇行业分析给三段真实数据和不给数据输出质量差一个档。受众那一栏也别偷懒「中小企业老板」和「中小企业 IT 负责人」关注的东西完全不同写成「大众」等于没写。3.3 同一需求的两版改写对照拿「写一份竞品分析」举例弱提示和强提示的差距不在字数在可验收性上。项弱提示强提示输入帮我写一份竞品分析三家竞品我方主打交付周期对方主打价格目标无判断我方在哪些客户群能守住结构无结论先行再按客群拆三段格式无表格一页正文不超 600 字结果通用框架需重写可直接进评审会改写动作可以拆成三步走先写目标把「我要什么判断」说清楚再补约束把不能出现的东西列出来最后锁格式把输出结构定死。三步做完再回头看角色设定要不要加——很多时候加了反而稀释重点尤其在 R1 上。这套动作我在团队里推过最明显的收益不是单次输出变好是新人对齐成本降下来了谁写的提示语都能被别人接着改。4. R1 的反直觉用法删掉角色设定为什么反而更准从 V3 迁到 R1 的人第一个不适应是「我以前那套精心设计的提示语在 R1 上像是被无视了」。手册里给了一组反直觉的结论不需要角色设定、不需要思维链提示、不需要结构化提示词、不需要给示例、不需要做太多解释。第一次看到会以为是偷懒实际是模型训练目标变了——外部再塞一套思考流程会和它内部已经展开的推理链打架。4.1 五个「不需要」背后的机制R1 这类推理模型在训练阶段就被强化过「先想再答」它内部会自己拆步骤、自己回退、自己验证。这时候你在提示语里写「让我们一步步思考」等于在一条已经在跑的流水线上再加一道同样的工序轻则输出重复重则提前收敛到一个浅层结论。给示例也是同理示例会把它的搜索空间压到你给的那条路上复杂问题上这个副作用尤其明显。角色设定的问题更微妙「你是一位资深分析师」这类话在 V3 上能明显提升用词密度在 R1 上经常只是让它多写一段自我定位。验证这件事不需要复杂实验同一个问题准备两版提示语一版带角色加思维链一版只留目标和约束各跑五遍看输出长度、结论一致性和错误率。我做过一轮结论是结构化的那版在简单任务上略有优势在需要多步推理的任务上反而更容易漏掉中间环节。所以现在的做法是分场景写文案、做整理继续用完整结构做分析、做排查就只给目标和边界。提示判断标准别只看「读起来顺不顺」要看「结论能不能被追问三轮」。追问两轮就崩的输出说明推理链是断的。4.2 CAP 四层框架给智能体用的提示语骨架当 R1 被当作智能体的核心层来用提示语就不能只有一句话了需要有骨架。手册里给的是 CAP 四层身份定义层放角色、专业背景、交互特征能力矩阵层放技能、功能范围、专业技能边界系统层放约束、决策权限、伦理规范、安全限制、资源约束工作引擎层放输入处理、执行流程、输出规范。四层分别对应核心层、功能执行层、约束层、操作层。边界系统这一层是最容易被跳过、也最容易出事的一层。智能体不像单轮对话它会连续动作没写清「哪些事不能做、拿不准时怎么处理」它就会自己补规则。资源约束也一样单次调用能跑多久、能查几次、能输出多长不写就会失控。4.3 把 CAP 写成可复用模板# 第一层身份定义 identity: role: 数据分析助手 background: 熟悉电商履约链路与指标体系 interaction: 先确认口径再给数不猜字段含义 # 第二层能力矩阵 capability: scope: [指标口径解释, 异常波动归因, 报表结构建议] skills: [拆解漏斗, 对比同环比, 识别辛普森悖论] out_of_scope: [直接改数据库, 预测未来销量] # 第三层边界系统 boundary: must_ask: 口径不明、字段缺失、时间范围未指定 forbidden: 编造数值、用行业均值替代缺失数据 output_limit: 单次结论不超过 500 字 # 第四层工作引擎 engine: input: 先复述问题与口径确认后再执行 flow: 定位指标 - 拆维度 - 给结论 - 标注不确定项 output_format: 结论在前依据在中待确认项在末尾列表这份模板的填充顺序有讲究我一般是先写engine.output_format把最终交付物的样子定下来再往回填boundary最后才写identity。倒着填的好处是每一层都服务于输出不会写成一段自我描述的散文。must_ask这个字段值得单独说它是把「模型不该猜的时候别猜」变成可执行的规则比笼统写「保持严谨」有效得多。字段名可以按团队习惯改但四层的顺序别乱从身份往引擎写会越写越虚从引擎往身份写会越写越实。5. 避坑与排查五条血泪记录每条都能对上号提示语这类东西的坑讲原理没用得看现象。下面五条是我和身边人真实翻过的车按输入侧和输出侧分开每条都按现象、原因、解决三段写能直接拿去对照自己的提示语。5.1 输入侧的三类翻车第一条提示语越写越长输出反而越发散。现象是原来一页能说清的需求写到三页之后模型开始抓不住重点输出里该有的没有、不该有的全有。原因是约束之间互相冲突比如同时要求「详细展开」和「控制在 600 字」又要求「覆盖五个维度」模型只能自己权衡权衡的结果就是每样都沾一点。解决办法是做减法把约束按优先级排序只保留前三重要的其余的移到后续轮次追加。我现在的习惯是单条提示语的硬约束不超过五条超了就拆成两轮。第二条该用 R1 的地方用了 V3推理中途断档。现象是问一个多步归因的问题V3 给了一个看起来完整但经不起追问的答案追问第二轮就开始自相矛盾。原因是这类任务需要多路径探索和自我回退V3 的线性路径走不了。解决是换通道同时把提示语从「过程-结果清晰」改成「目标清晰、结果可以模糊」删掉角色设定和思维链提示。换完如果还是不行说明问题不在模型在你的目标描述本身就没想清楚。第三条联网搜索开着答案里带着过期数据。现象是明明开了检索给出的仍是旧口径。原因是检索召回没覆盖到你问的那个时间点或者问题本身是「怎么理解」而不是「什么时候变的」后者根本不需要检索。解决办法是先判断问题类型时效型问题才开检索且要在提示语里写死时间范围比如「只采用近三个月公开信息找不到就明说找不到」。开检索一定有代价响应变慢、引用可能不相关别把它当默认开关。5.2 输出侧的两类翻车第四条要求输出图表代码或表格结果格式崩了。现象是让它生成一份流程图代码回来的是半截语法加一段解释粘进去就报错。原因是没有给语法约束和层级要求模型会自由发挥。解决是把约束写死必须符合目标语法规范、必须体现二三级层级、代码块里不许夹解释文字、生成后自行校验一遍语法。这四条加上去之后格式崩的概率会明显下降。校验不能靠肉眼我一般会写个小脚本过一遍括号和缩进。第五条PPT 大纲页数不够、层级混乱。现象是要三十页给了十二页而且章节目录和页面内容混在一起。原因是没有定义层级契约模型不知道「第一层是封面和章节页、第二层是页面标题、第三四层是内容要点」。解决是把层级写进提示语并且明确输出顺序先研究资料表再大纲最后关键页图表三块不许混在一起。这个顺序很关键混着输出的时候模型会为了凑结构牺牲内容。现象一句话根因第一动作输出发散约束冲突砍到五条以内推理断档通道选错换 R1 并简化提示数据过期检索滥用或缺时间约束加时间范围限定格式崩缺语法与层级约束写死规范 自校验页数不足缺层级契约定义层级与输出顺序这张表我贴在团队文档首页出问题先对一遍八成能定位到是哪一类。剩下的两成通常是模型版本或者端点配置的问题那属于另一条排查线。6. 图表与大纲自动化把提示语接进文档流水线单次对话调好了下一步是把它接进流水线让图表和文档结构自动出来。这一步的关键不是提示语写得多花是把约束写成可校验的契约。6.1 图表生成的约束写法让模型生成流程图代码四类约束必须写全。语法约束输出必须符合目标图表语法的规范代码块内不得夹解释文字。层级约束必须体现二级、三级等多层级结构不允许把所有节点摊平。类型约束先根据需求选图型再生成流程走流程图、结构关系走结构图、时序交互走时序图选错图型比语法错更难救。校验约束生成后自行检查一遍语法和节点连通性有问题先修再输出。这四条里类型约束最容易被忽略我见过太多把组织结构硬画成流程图的产出语法全对语义全错。6.2 PPT 大纲的层级契约大纲类任务的核心是层级契约。第一层放封面、目录页、章节页标题第二层放每个页面的标题第三层和第四层放页面内容要点。页数要给硬指标比如不少于三十页同时要求内容完整、不缺关键章节。输出顺序固定成三块研究资料摘要表、Markdown 大纲、核心页图表三块分开交付不要混排。混排的后果是模型为了迁就结构砍内容最后页数够了但每页都很空。# 大纲交付前的机械校验挡住页数和层级两类低级错误 import re def check_outline(md: str, min_pages: int 30) - dict: pages len(re.findall(r^###\s, md, flagsre.M)) # 第二层页面标题 chapters len(re.findall(r^##\s, md, flagsre.M)) # 第一层章节 return { pages: pages, chapters: chapters, page_ok: pages min_pages, ratio_ok: chapters 0 and pages / chapters 3, # 每章至少三页 }min_pages按交付要求调ratio_ok用来挡「章节堆得多、每章只有一页」这种虚胖结构。校验只是兜底真正决定质量的是契约写没写清。这套流程我推过几次最有用的一条经验是先把输出格式定死再回头调提示语。有次赶一份材料我跳过了校验脚本直接交结果三十页里有九页是重复内容返工到半夜。从那以后我每次生成大纲都强制走一遍页数和层级校验宁可多花两分钟。希望帮到你。本文还有配套的精品资源点击获取