DeepSeek提示语工程：V3/R1选型与三大框架落地

简介：《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 上。

实际判断时我用一句更土的口诀：结果能不能提前描述出来。能说清「一份 800 字、三段、每段带一个小标题、语气克制」的，走 V3；只能说清「帮我把这个方案的薄弱点找出来、往深里挖」的，走 R1。前者你在给规格，后者你在给方向。硬把规格塞给 R1，它会觉得你在限制它，输出反而发散；把方向丢给 V3，它会给你一份看着齐整但经不起追问的东西。

注意：这张表限定在文本生成任务上。拿它去推多模态或者代码补全的选型，结论会偏。

2.2 三种模式的分工：基础、深度思考、联网检索

三种模式的差别不在「强弱」，在信息来源和推理深度。基础模型 V3 面向绝大多数通用任务，胜在快和稳；深度思考 R1 面向复杂推理和深度分析，数理逻辑、代码、根因排查这类活它更擅长；联网搜索本质是检索增强生成，把外部检索结果拼进上下文，解决的是知识时效问题。这三者经常被误用成一个开关——「答案不准就开联网」，其实联网只解决「新不新」，不解决「对不对」。

部署形态上，手册列了几种入口：网页版直接使用、API 调用、以及部分 GPU 厂商推理微服务和主流云平台提供的模型托管部署，注册后有免费点数可以先跑通链路。我的建议是先网页版验提示语，再 API 做批量化，别一上来就写调用代码——提示语没定稿，代码跑一万次也只是把错误放大一万倍。下面是接口调用的最小骨架，地址和密钥全部走环境变量，避免把凭据写进脚本：

# 端点和密钥放环境变量，脚本本身不进版本库 export DS_BASE="https://<your-endpoint>/v1" export DS_KEY="<your-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.3，R1 常见做法是放在 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 把上下文、目标、风格、语调、受众、回应类型拆成六块，来源是一套竞赛级的提示词框架。字段多不代表都要写满，实际用下来，真正决定质量的是上下文、受众、回应类型这三个；风格和语调在中文语境里高度重叠，经常被写成「专业又不失活泼」这类没法执行的词。

我一般会把 Style 和 Tone 合成一行来写，省下来的注意力放到 Context 上。上下文这一栏的投入产出比最高：同样一篇行业分析，给三段真实数据和不给数据，输出质量差一个档。受众那一栏也别偷懒，「中小企业老板」和「中小企业 IT 负责人」关注的东西完全不同，写成「大众」等于没写。

3.3 同一需求的两版改写对照

拿「写一份竞品分析」举例，弱提示和强提示的差距不在字数，在可验收性上。

改写动作可以拆成三步走：先写目标，把「我要什么判断」说清楚；再补约束，把不能出现的东西列出来；最后锁格式，把输出结构定死。三步做完再回头看角色设定要不要加——很多时候加了反而稀释重点，尤其在 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 大纲页数不够、层级混乱。现象是要三十页，给了十二页，而且章节目录和页面内容混在一起。原因是没有定义层级契约，模型不知道「第一层是封面和章节页、第二层是页面标题、第三四层是内容要点」。解决是把层级写进提示语，并且明确输出顺序：先研究资料表，再大纲，最后关键页图表，三块不许混在一起。这个顺序很关键，混着输出的时候模型会为了凑结构牺牲内容。

这张表我贴在团队文档首页，出问题先对一遍，八成能定位到是哪一类。剩下的两成通常是模型版本或者端点配置的问题，那属于另一条排查线。

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, flags=re.M)) # 第二层=页面标题 chapters = len(re.findall(r"^##\s", md, flags=re.M)) # 第一层=章节 return { "pages": pages, "chapters": chapters, "page_ok": pages >= min_pages, "ratio_ok": chapters > 0 and pages / chapters >= 3, # 每章至少三页 }

min_pages按交付要求调，ratio_ok用来挡「章节堆得多、每章只有一页」这种虚胖结构。校验只是兜底，真正决定质量的是契约写没写清。

这套流程我推过几次，最有用的一条经验是：先把输出格式定死，再回头调提示语。有次赶一份材料，我跳过了校验脚本直接交，结果三十页里有九页是重复内容，返工到半夜。从那以后我每次生成大纲都强制走一遍页数和层级校验，宁可多花两分钟。希望帮到你。

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