简介：围绕DeepSeek在职场中的落地应用，这份PDF文档从提示语设计延伸到多场景实践与智能体协作，面向具备一定技术基础的研发人员、工程师、设计师、产品经理及关注人机协同的管理者，帮助读者理解大模型能力边界，并把提示工程转化为可复用的工作方法。内容重点梳理DeepSeek三大部署模式及V3、R1两类模型的差异：V3偏向高效便捷的通用任务，R1更适合复杂推理与深度分析；同时结合RTGO、CO-STAR提示框架，给出演示文稿大纲生成、图表设计、海报制作、数据分析与沟通协作等场景示例，并讨论对话助手、推理者、智能体等角色在人机协同中的分工。包内共1个PDF文件，压缩包约9.78MB，便于集中查阅和按章节学习。已有508人学习，适合需要快速建立方法框架、对照场景案例提升AI应用效率的职场读者。
1. 应用前的准备：通道与提示
上周有人把四十页季度复盘材料甩过来，问能不能让 DeepSeek 直接生成一份能用的 PPT 大纲。第一版输出是把原文按段落缩了一遍，页数够了，逻辑却散。问题不在模型，在开口方式——同一份材料，换成带角色、目标、受众、输出格式的提示语，结果立刻可用。
这份资源串起的正是这一整条工作链路：从提示语技巧入手，先分清基础模型、深度思考、联网搜索三个通道各自适合什么任务，再用 RTGO、CO-STAR 把需求整理成规格书，最后用 CAP 四层结构把一次性对话固化成可复用的智能体。
它适合每天要交东西的人：运营、产品、分析师、技术方案岗，不一定写代码，但得把 AI 放进真实交付流程。下面按我拆这套东西的顺序写：先选通道，再写提示，再做减法，最后封成智能体。
2. 先选通道再写提示语：V3、R1 与联网搜索的分流判据
十个人里有八个是把任务直接丢给最强的那个模型，然后抱怨「一会儿好用一会儿不好用」。模型本身没有变，是任务形状和通道不匹配。这套资源里最有价值的部分，是把两个模型拆成五个可量化的维度来对照，而不是笼统说「R1 更聪明」。
2.1 用五个维度给任务定型
对照维度直接决定了提示语怎么写。规范性强的任务，操作路径必须明确到每一步；结果导向开放的任务，路径本身就是探索出来的。这两类任务拿同一套提示模板去套，必然一边浪费一边翻车。
| 维度 | 基础模型 V3 | 深度思考 R1 |
|---|---|---|
| 规范约束 Regulation | 强，操作路径明确 | 弱，操作路径开放 |
| 结果导向 Result | 确定性高，结果可预期 | 开放性高，结果多样 |
| 路径灵活 Route | 线性，流程标准化 | 网状，多路径探索 |
| 响应模式 Responsiveness | 被动适配，按规则执行 | 主动创新，自主决策 |
| 风险特征 Risk | 低，稳定可控 | 高，不确定性大 |
我一般拿三个问题去判定：结果能不能提前描述出来、路径是不是唯一、错了的代价大不大。三个都偏「是」，走 V3；三个都偏「否」，走 R1。举个具体的：把一段会议纪要整理成待办列表，结果形态固定、路径唯一、错了改一下就行，V3 就够；让它判断这份季度数据里哪条业务线的下滑是结构性的，结果长什么样事先说不清，路径也得靠它自己找，那就该上 R1。
真实的翻车往往出在反过来用：拿 R1 去做格式固定的字段抽取，它会自作主张补充你没要的分析，字段还经常飘；拿 V3 去做归因推理，它会给你一段读起来很顺但经不起追问的结论。判定做在前面，能省掉后面一半的返工。
# route_task.py —— 按任务形态选通道，避免全场景都走推理模型 import os from openai import OpenAI client = OpenAI( api_key=os.environ["DS_API_KEY"], base_url=os.environ["DS_BASE_URL"], # 接入点由环境变量注入，换供应商不用改代码 timeout=180, max_retries=2, ) # channel 三选一：v3 通用 / r1 推理 / 联网检索在上面叠加 PROFILE = { "ppt_outline": {"channel": "v3", "temperature": 0.6, "search": False}, "field_extract": {"channel": "v3", "temperature": 0.0, "search": False}, "root_cause": {"channel": "r1", "temperature": None, "search": False}, "market_scan": {"channel": "v3", "temperature": 0.3, "search": True}, } def run(task_type: str, prompt: str) -> str: cfg = PROFILE[task_type] kwargs = { "model": cfg["channel"], # 实际模型标识以接入方文档为准 "messages": [{"role": "user", "content": prompt}], "max_tokens": 4096, } if cfg["temperature"] is not None: # 推理通道不吃采样参数，传了也基本无效 kwargs["temperature"] = cfg["temperature"] resp = client.chat.completions.create(**kwargs) return resp.choices[0].message.content这段代码干的事只有一件：把「选模型」从人的临时判断变成一张表。PROFILE是任务到通道的映射，新增场景加一行即可，不用改调用逻辑。temperature设成None表示该通道不传采样参数——推理模型的思考链是确定性的搜索过程，调温度对它几乎不起作用，强行传值只会让你误以为是参数在生效。max_tokens给 4096 是个经验值，推理通道的思考过程单独返回，正文能用的额度要按剩余空间估，设太小会出现「想完了但没写完」的截断。max_retries=2和timeout=180是给长任务留的余量，推理类请求的超时阈值要比通用对话宽一倍以上。
2.2 联网搜索什么时候必须打开
联网检索这一层的本质是 RAG：先把外部信息捞回来，拼进上下文，再让模型基于这份上下文生成。它在职场场景里的价值主要在于补时效和补私有信息，例如本周刚发的内部周报、刚落地的行业规范、竞品这周调过的报价，并不体现在写一篇行业综述上。
一个反直觉的坑：开了联网，不等于这次回答真的检索了。模型会自己判断要不要调用检索，如果它觉得参数化知识够用，就直接答了，你看到的还是一年半前的结论。稳妥的做法是在提示里把动作写死，并且要求标注信息时间。
先检索再回答，不要凭已有知识直接给结论。 每条关键信息后面用括号标注来源日期，格式为（2025-03）。 检索不到的内容直接写「未检索到」，不要补全。 最后单列一段「信息时效说明」，写清哪些结论依赖旧数据。这套约束的作用是把「检索」从模型的自由裁量变成流程步骤。最后一行的时效说明尤其关键，它逼模型把自己的知识边界摊开，你一眼就能看出哪几句该人工核。常见的坑是检索回来的内容是二手转载，同一个数据在三四个站点上抄来抄去，看着来源很多其实只有一个出处，这时候要让它把原始出处单独标出来。
2.3 接入路径与参数怎么配
接入这件事没有想象中复杂，市面上的路径大致分三类。一类是云端托管的模型服务，注册后拿 key 直接调，全量模型和蒸馏版都能选；一类是各家云厂商的模型市场，需要开账号、建订阅，好处是能把参数和配额管起来；还有一类是推理加速平台，只挂了 70B 的蒸馏版本，速度确实快，但复杂推理的稳定性会打折扣。
我的建议是：主链路用全量模型的托管服务，做质量基线；批量的、对延迟敏感的预处理任务，比如长文档分段打标签，可以走加速平台的蒸馏版，把成本压下来。别拿蒸馏版去做归因分析和方案评审，那个差距在长链推理上非常明显。
参数上真正需要调的只有三个。temperature在结构化任务里压到 0 到 0.3，别指望它「更有创意」，字段抽取要的是稳定复现；创意类文案可以放到 0.7 以上，但行业术语的准确性会同步下降，得靠术语表约束回来。max_tokens按输出物估，PPT 大纲这种动辄三四十页的结构化输出，给到 8192 才勉强够。stream在交互式产品里建议打开，长任务不流式的话，前端会干等半分钟。
3. RTGO 与 CO-STAR：把需求写成人能验收的规格书
提示语写不好的根本原因，多数时候是需求本身没说清，并非措辞不够花哨。这两套框架解决的是同一个问题：把「帮我写个方案」这种没法验收的话，翻译成有角色、有目标、有交付形态的规格书。
3.1 RTGO 四段式与一个反例
RTGO 拆成四段：角色、目标、任务、操作要求。前三段定方向，第四段定验收标准。真正拉开差距的是第四段——字数、段落结构、用词风格、内容要点、输出格式，这些才是你能拿去判断「行不行」的尺子。
反例长这样：「你是一个资深数据分析师，帮我写一份关于某产品季度表现的复盘报告。」正例是：「你是有八年经验的 SaaS 行业分析师。目标是通过这份复盘让管理层在周五会上决定下季度预算往哪条线倾斜。任务是基于以下三张表写一份季度复盘。操作要求：正文不超过 1200 字，分现状、归因、建议三段，归因部分必须引用表里的具体数字，建议部分给三个选项并标注各自的风险，输出 Markdown，不要用二级以下标题。」
差别不在文采，在可验收性。反例你拿到输出只能说「感觉不太对」，正例你能逐条打勾。
# prompt_spec.py —— 把需求压成可校验的规格对象 from dataclasses import dataclass, field @dataclass class RTGO: role: str goal: str task: str objective: dict = field(default_factory=dict) # 字数/结构/风格/格式 def render(self) -> str: miss = [k for k in ("role", "goal", "task") if not getattr(self, k).strip()] if miss: raise ValueError(f"缺少必填段: {miss}") blocks = [f"# 角色\n{self.role}", f"# 目标\n{self.goal}", f"# 任务\n{self.task}"] if self.objective: spec = "\n".join(f"- {k}：{v}" for k, v in self.objective.items()) blocks.append(f"# 操作要求\n{spec}") return "\n\n".join(blocks)render()先做必填校验再拼串，这一步看着多余，实际能挡掉大量「跑到最后发现漏了目标段」的返工。objective用字典存，是为了让每个约束项都有名字，后面做 A/B 时可以单独替换某一项，比如只改「字数」看输出怎么变，其余保持不变，变量才是可控的。字段顺序按「角色—目标—任务—要求」排，和人的阅读顺序一致，模型对前置的角色信息利用率也更高。
3.2 CO-STAR 六要素补的是受众与语调
RTGO 够用，但它缺两个东西：给谁看、什么口气。CO-STAR 把这六件事摊开——上下文、目标、风格、语调、受众、回应类型。多出来的这三项，恰恰是职场交付物最容易翻车的地方。
同一份竞品分析，给管理层看要结论前置、每段不超过三行、少用限定词；给执行团队看要带操作步骤和责任人；给外部客户看要删掉内部代号和未公开数据。这些差异不是靠「专业一点」这种话能传达的，得在提示里明确写「受众是没看过原始数据的业务负责人，他们只关心要不要投人」。
风格和语调这两项要分开写。「风格」指的是文体，比如研究报告体、口播稿体、邮件体；「语调」指的是情绪浓度，比如克制、中性、略带锋芒。我见过最常见的失败是把两者混成一句「写得专业一点」，结果输出要么像说明书，要么像广告。
回应类型决定输出形态：要一份表格、一段 Markdown、一个能直接粘进文档的纯文本，还是分三段的对话式答复。这一项漏了，后面所有格式问题都得靠手工修。
3.3 选型判据与两套框架的拼接
判据很简单：交付物是「一份能直接用的东西」，用 CO-STAR，因为受众和形态决定成败；交付物是「一次判断或一次分析」，用 RTGO，因为验收标准是结论能不能站住。
两者也不是二选一。实操里我常用 RTGO 打底，把 CO-STAR 的受众、语调、回应类型塞进「操作要求」段，等于在四段式外面套了一层交付规范。这样既保留了 RTGO 的简洁，又不会漏掉「给谁看」这个致命信息。
需要提醒的是，框架本身不提升模型能力，它提升的是你的表达精度。同一件事写三遍模板但内容空泛，输出照样是水的。模板的价值在于让你每次写提示时都被迫回答那几个问题：目标是什么、给谁看、怎么算完成。回答不上来，说明需求还没想清楚，这时候换什么框架都没用。
4. R1 的减法提示法：五个不需要与它的失效边界
刚上手推理模型的人，最容易犯的错是「把给通用模型的那套全搬过来」。角色设定、思维链提示、结构化模板、三五个示例、再加一大段解释——这套组合拳砸在推理模型上，输出经常比裸问还差。
4.1 为什么角色设定和思维链提示会反噬
推理模型内部已经跑了一遍长链推理，你再在外面套一层「让我们一步步思考」，等于让它在一个已经规划好的推理路径外面，再模拟一遍「假装思考」的过程。表现出来就是开头一段复述题目，中间反复确认，最后结论反而被前面的铺垫带偏。
角色设定的问题更微妙。给通用模型设角色，是为了把输出拉到某个专业语域；推理模型的推理过程本身就会自动收敛到任务的领域语域，额外的人设反而变成干扰项，尤其当人设和任务领域不匹配时——你让它扮演「资深营销专家」去算一道留存率的口径问题，它会往营销话术上靠。
示例是第三个雷。给两三个示例，通用模型会学到格式；推理模型会学到解法，然后把这个解法硬套到新问题上。任务稍有变化，它还在用示例里的那条路径，你看着格式对了，结论错了。
资源里给的那份「五个不需要」清单——不需要角色设定、不需要思维链提示、不需要结构化提示词、不需要给示例、不需要做太多解释——本质是同一件事：别用外挂的脚手架去干扰它内建的推理。
4.2 目标写死、结果放宽的具体写法
减法的核心不是少写，是把笔墨从「怎么想」挪到「要什么」。目标、约束、验收标准要写得比通用模型更死，至于路径和中间步骤，一个字都别管。
| 项目 | 加法写法（适合 V3） | 减法写法（适合 R1） |
|---|---|---|
| 角色 | 你是资深数据分析师 | 省略 |
| 过程 | 请按「先清洗、再对比、后归因」三步分析 | 省略 |
| 目标 | 分析这份数据 | 判断三条业务线里哪条的下滑是结构性的，给出判断依据 |
| 约束 | 输出三段 | 结论先行，每个判断后面附上支撑它的具体数字，反例也要写 |
| 结果形态 | 800 字左右 | 不限字数，说清楚为准 |
右边这一列看着「不专业」，但它把决策空间还给了模型。你在约束里写「反例也要写」，是在逼它做自我反驳，这个动作比任何「请仔细思考」的提示都有效。
有个细节值得单说：结果放宽不等于不设边界。对推理模型，我一般会给两类硬约束——输出格式（要不要 Markdown、要不要表格）和信息纪律（不许编数字、拿不准就标注）。这两类约束不会干扰推理路径，反而能减少它在格式和信息真实性上的自由发挥。
4.3 减法失效的三个边界与回退方案
减法不是万能药。有三类任务，该加的结构还得加回去。
第一类是严格结构化输出。要它吐一个固定 schema 的 JSON，减法写法下它经常在前后加一段解释，或者把某个字段拆成两个。这时候要么换回通用模型做抽取，要么在提示里把 schema 用代码块给死，再加一句「只输出 JSON，不要任何前后缀」。
第二类是文风强约束。品牌口播稿、法务条款、对外公告，这类文本的语感不能靠模型自由发挥，得给示例、给禁用词表、给句式模板。
第三类是多轮一致性。同一批物料要出二十条，风格必须统一，这时候得先让它自己产出一份风格约定，再把这份约定作为固定上下文带进每一轮。
# ab_probe.py —— 同一任务跑加法/减法两版提示，看哪版更稳 import json, statistics def parse_ok(text: str) -> bool: s = text.strip() if s.startswith("```"): # 去掉模型习惯加的围栏 s = s.split("\n", 1)[-1].rsplit("```", 1)[0] try: json.loads(s) return True except Exception: return False def probe(prompt: str, task_type: str = "field_extract", n: int = 3) -> dict: outs = [run(task_type, prompt) for _ in range(n)] return { "avg_len": round(statistics.mean(len(o) for o in outs)), "json_ok": sum(parse_ok(o) for o in outs) / n, "samples": outs[0][:200], }probe()每次跑三遍取平均，是因为单次输出有随机性，一次好坏说明不了什么。avg_len看的是啰嗦程度，减法版本如果长度反而暴涨，通常说明它在反复自我确认，得回去检查提示里是不是还残留着过程指令。json_ok是解析成功率，这个指标最能反映格式稳定性，低于 0.8 就别指望下游程序能接。samples只截前 200 字符，用来快速判断有没有加多余的前后缀，不用把整段输出打出来。
回退顺序我一般是这样：先试「减法 + 硬格式约束」，不行就换通用模型做结构化部分，再不行才上示例。示例是最后手段，因为它一旦进入上下文，后面所有轮次都会被它锚住。
5. 避坑排查：五条血泪记录与对应处置
这一章全是踩过的坑，按现象、原因、处置三段写。有些看着像模型问题，其实是调用方式的问题。
5.1 输出格式与提示词层面的三个坑
坑一：推理模型输出的 JSON 带围栏，下游解析直接崩。现象是本地测着好好的，一上批量任务就有百分之二三十的解析失败，报错位置全在json.loads那一行。原因是推理模型倾向于在结构化输出外面包一层 Markdown 代码围栏，甚至在前后补一句「以下是结果」。处置很简单，加一个清洗函数，先剥围栏再解析，同时把json_ok打进监控；如果清洗后仍然失败，退回通用模型做这一步，别在提示里反复加「不要加围栏」——它对这类否定式指令的遵守率有限。
坑二：提示词越写越长，效果越来越差。现象是提示从三百字涨到两千字，输出反而更平庸，还经常漏掉其中两三条要求。原因是长提示里的约束互相稀释，模型注意力被均匀分配，尾部的要求优先级最低。处置是把提示拆成「目标 + 硬约束」两段，硬约束不超过五条，超出的部分挪到后置的校验环节——先出稿，再用程序或第二轮调用逐条检查，比一股脑塞进去靠谱。
坑三：给推理模型设了人设，输出开始跑偏。现象是加了「你是资深品牌策划」之后，本来该做数据归因的任务，输出里全是品牌调性的话术。原因是人设把领域语域拽偏了，推理路径跟着偏。处置是删掉人设，把领域信息写进任务描述本身，比如「这批数据来自品牌投放，需要判断哪类素材的转化在下滑」，信息给到，语域自然就对了。
5.2 参数与上下文层面的两个坑
坑四：把温度调高想让它「更有想法」，结果术语乱飞。现象是创意文案确实活泼了，但行业术语开始出现近义替换，比如把固定口径的指标名换成同义词。原因是采样温度升高后，低频词的采样概率上升，专业术语恰好是低频词。处置是分层处理：术语密集的段落压到 0.2 以下，纯创意段落单独一轮生成，最后用术语表做一次替换校正。
坑五：长文档塞进上下文，中段信息像被吃掉。现象是喂了一份六十页的材料，问它第五章的数据，它答得含糊，问开头和结尾的部分却很准。原因是长上下文存在中段衰减，位置越靠中间的内容被利用率越低。处置是结构性前置：把关键数据、结论、需要它重点处理的部分放在提示开头，原始材料附在后面；材料超过一定长度就先分段摘要，再把摘要和关键原文一起给。我一般会在提示末尾再加一句「回答前先列出你引用到的原文片段位置」，这句话能显著降低它凭印象编造的概率。
还有一条不算坑但值得记：同一份提示在不同接入点上的表现会有差异，尤其是蒸馏版和全量版之间。所以任何要上生产线的提示，都得在目标接入点上重跑一遍probe()，别拿本地效果当验收标准。
6. 把角色卡做成智能体：CAP 四层结构和一个校验闭环
一次性对话和可复用智能体的差别，就在有没有把「角色」写成一份可交付的配置。CAP 四层结构是这件事的落地形态：身份定义、能力矩阵、边界系统、工作引擎。身份说清它是谁，能力矩阵列它能干什么，边界系统划死它不能干什么，工作引擎规定它按什么顺序干。
拿生成图表这件事举例，四层可以压成一张字典，用代码渲染成系统提示，比手写一大段话好维护得多。
# agent_card.py —— 角色卡即配置，改行为不改提示词正文 CARD = { "identity": "图表代码生成器，把流程或架构描述转成可直接渲染的图表代码", "capability": ["熟悉流程图、时序图、状态图的语法", "能把描述拆到二三级节点"], "boundary": ["只输出代码，不写解释", "节点总数不超过 30", "不臆造描述里没有的模块"], "engine": ["确认图表类型", "收集流程描述", "设计层级", "输出代码", "自检语法"], } def render_card(card: dict) -> str: parts = [f"# 身份\n{card['identity']}"] for key, title in (("capability", "能力"), ("boundary", "边界"), ("engine", "工作流程")): parts.append(f"# {title}\n" + "\n".join(f"- {x}" for x in card[key])) return "\n\n".join(parts) def check_output(text: str) -> bool: head = text.strip().splitlines()[0] if text.strip() else "" return head.split()[0] in {"flowchart", "graph", "sequenceDiagram", "stateDiagram"}CARD把四层拆成四个键，好处是每一条都能单独改、单独测。boundary里的「节点总数不超过 30」是个硬阈值，超了以后图表在文档里根本看不清，宁可让它拆成两张。render_card()只是拼串，但它保证了每次调用的系统提示完全一致，不会因为手抖漏掉某条边界。check_output()只看首行第一个词，这个判断很粗，但能挡住绝大多数「先解释一段再给代码」的情况；真要严检，再加一步统计节点数和括号配对。
上线前我固定跑三件套：拿同一个需求连跑五次，看输出结构是否稳定；拿一个描述不清的需求跑一次，看它是追问还是硬编；再拿一个超范围的需求跑一次，看边界有没有生效。三件套跑完还稳的卡，我才敢放进流程里给别人用。从那以后，我每次新增一张角色卡都会强制走一遍这三步，哪怕需求再急也不跳——跳过的那次，往往就是后面花两天排查的那次。希望帮到你。
本文还有配套的精品资源，点击获取
