DeepSeek 这几个月的热度不用我再吹一遍了。作为目前少有的同时兼顾开源权重、API 低价和推理能力的大模型它已经成了个人开发者和中小团队落地 AI 的首选。但热点归热点真正上手之后你会发现大多数人不是卡在“不会用”而是卡在“不知道拿它干什么、怎么把它塞进现有工作流”。这篇内容我按实际落地经验来写核心是 7 大高频场景的拆解配 50 个能直接抄走的提示词工程实例。另外会覆盖 API 接入、IDE 工具链、企业微信集成、本地部署和常见坑位排查。适合正在评估 DeepSeek 的技术负责人、独立开发者和想用 AI 提效的运营/产品同学。我不能保证每个提示词都万能但至少能让你少走我踩过的弯路。1. 落地的第一个问题为什么选 DeepSeek它的能力边界在哪1.1 便宜、开源、能自己部署这三件事同时占住的模型不多选 DeepSeek 当主力模型核心原因是“低成本试错”。API 价格比同级别闭源模型便宜一个数量级而且开源权重意味着你可以下载到本地跑在自己的机器上。这对两类人特别友好一类是预算敏感的个人开发者另一类是对数据隐私有硬性要求的企业用户。但便宜不代表无脑冲。DeepSeek 的能力分布和 ChatGPT/Claude 不太一样它强在逻辑推理、代码生成、长文本理解和中文表达在创意写作、复杂情感理解、闲聊调性这类的任务上偏理性、偏结构化。也就是说你拿它写 SQL、做分析、处理文档体感会很好你拿它写煽情文案、扮演情绪价值拉满的陪聊角色效果就一般。做选型时我建议按“任务类型”分而不是按“模型名气”分。推理类、代码类、数据类任务优先考虑 DeepSeek 系列情感表达和品牌向的内容生成可以继续用闭源模型或做混合调用。把 DeepSeek 定位成“逻辑型打工人”它的价值会立刻放大。1.2 为什么是这 7 个场景而不是更多我整理这 7 个场景之前先翻了一圈自己过去几个月的使用记录又问了身边十几个把 DeepSeek 接进业务的朋友最后筛出重复出现频率最高、复现成本最低、收益最明显的几类办公写作与文本生产编程开发与代码质量提升企业知识库与检索增强问答智能客服与业务系统集成结构化数据提取与自动化流程本地私有化部署与数据安全场景多工具编排与智能体这 7 类基本覆盖了“内容生成、代码辅助、知识管理、对话服务、数据加工、私有化、自动化”这七条主线。你不需要一次全上选一个离你当前业务最近的场景切入跑通一个闭环比铺开七条线结果全部半途而废要强得多。1.3 一个容易被忽略的选型维度上下文长度与工具调用能力除了模型名和价格落地时一定要看“上下文长度”和“工具调用function calling”这两项。DeepSeek 的上下文窗口足够支撑长文档分析但要特别注意上下文越长单次请求的延迟和成本都会上涨而且工具调用的稳定性非常依赖运行框架的版本。后面我会反复提到一个真实错误messages tool calls need immediate results。很多人在跑智能体的时候遇到这个报错其实根因往往不是模型不会调用工具而是框架层要求工具结果必须在同一轮立即返回一旦你打断或延迟了返回整个对话链就断了。这些都是你真正部署之后才会撞到的东西所以提前理解“模型能力 运行框架 最终体验”这个公式很重要。2. 七大场景逐个拆解从需求到方案的完整路径2.1 文本生产与日常办公最容易被低估的高频场景办公文本是最典型的高频低难度场景适合第一个跑通。包括会议纪要、周报月报、邮件润色、PPT 大纲、短视频脚本、对外文档改写、跨语言翻译本地化等。这个场景的核心收益不是“生成”而是“把非结构化的信息变成结构化内容”。实操上我建议用一个固定流程先给模型原始材料再给它输出模板最后给一条禁止规则。比如会议纪要直接把语音转写的凌乱文本丢给它要求输出包含“结论、待办、负责人、时间节点”的表格。这样做的好处是模型不是凭空写而是在整理准确率会高很多。这个场景对应的提示词实例很多我在第 3 部分放了 10 个直接可用的模板覆盖了从周报生成到多语言翻译的常见需求。重点是复制后把占位符替换成真实信息千万不要拿空模板直接问模型它不会猜到你想要什么格式。2.2 编程开发单元测试、重构、Debug、SQL 生成全流程写代码是我个人使用 DeepSeek 最频繁的场景。它的代码生成能力强而且特别适合做“解释代码”和“写单元测试”这两件事。看一段老项目代码看不懂直接把代码丢给它让它逐段解释并标出可疑点要给一个函数补测试把函数签名和逻辑给它它能稳定产出测试用例。不过这里有个心法不要让模型直接写全部业务代码而是让它“补缺口”。你用自然语言描述你要实现什么、输入输出是什么、边界条件有哪些让它产出可落地的函数。它给出代码后你再跑一遍测试把报错信息回喂给它。这个“写-跑-报错-修”的循环比一次性让它写完整模块要靠谱得多。Debug 类任务最有效的提示词是“我提供报错堆栈 相关代码你告诉我最可能的根因并按可能性排序”。千万别一开始就让它“修复一切”毫无约束的修复通常会引入新问题。2.3 企业知识库与检索增强RAG 的提示词设计是关键知识库问答是大家问得最多的落地场景。流程一般是先把公司文档切块、向量化用户提问后检索相关片段再把这些片段连同问题一起发给大模型生成答案。很多人以为向量检索做得好答案就靠谱实际上提示词设计同样致命。我踩过的坑是检索回来的片段可能互斥或过时而模型默认会强行综合所有材料给出一个看似平滑但实际错误的答案。所以知识库场景的提示词必须加三个约束第一只基于提供的上下文回答第二材料里找不到答案时明确说“资料库中无相关信息”不能编造第三当多个片段冲突时指出冲突并列出依据而不是自己挑一个“看起来合理”的。这里的提示词实例我放在第 3 部分的 3.3 小节同时在第 4 部分解释了它和普通提示词工程的差异。知识库场景本质上是“上下文工程”而非简单提示词需要你对塞进上下文的内容有绝对控制权。2.4 智能客服与业务集成企业微信、公众号都能接把 DeepSeek 接入企业微信或微信公众号是很多团队真正产生业务价值的第一个场景。整体架构不复杂用户发送消息到企业微信应用你的后端服务接收回调、解析内容调用 DeepSeek API 生成回复再通过微信接口把消息发回去。但这里有一个新手必踩的坑企业微信被动回复消息有超时限制而大模型 API 的响应经常超过这个时间。如果你用同步方式用户会看到“服务异常”实际上是你超时了。我的建议是改成异步流程收到用户消息后先立刻返回一个“收到”然后把消息放入队列由后台任务调用模型再用客服消息接口主动推送结果。这个改造能让体验顺畅非常多。另外客服场景的提示词要注意“组织纪律性”明确允许说什么、不允许说什么、不确定怎么处理。比如退货政策只能引用文档里的原文不能替公司承诺赔偿方案遇到情绪激烈用户要转人工而不是讲大道理。这些规则写进 system prompt配合第 4 章的方法基本能挡住 80% 的乱说话问题。2.5 数据提取与自动化流程让模型当结构化数据转换器这个场景很多人没意识到它其实是投产比最高的场景之一。合同字段提取、聊天记录待办整理、日志根因抽取、PDF 表格转 Markdown、JSON 格式化输出等本质都是“非结构化数据到结构化数据的转换”。模型在这里不是内容生成器而是转换器准确率要求高容错率却可以做到很高。我在实践中总结的经验是这类任务一定要求模型输出固定 schema并开启 JSON 输出模式。如果你直接让它“把这段合同的关键信息提取出来”它可能给你一段散文解析麻烦又容易错。正确的做法是在提示词里给出目标 JSON 结构甚至给一个样例让它严格按样例输出。这个场景里“示例比指令更有效”也是我在第 4 章要讲到的 few-shot 技巧。给一个带标注的样例模型能更快理解你要的边界比如“日期统一转成 YYYY-MM-DD金额统一去掉货币符号”这种细节直接决定下游代码解析的稳定性。2.6 本地私有化部署隐私优先场景的现实方案本地部署的核心诉求不是省钱而是数据不出内网。银行、医疗、法律以及很多制造企业都卡在这一条上。DeepSeek 的开源权重让本地部署成为可能常见路线有两条一条是 Ollama一条是 vLLM各有适用边界。Ollama 适合快速验证和低 GPU 压力的部署几行命令就能拉起一个本地服务vLLM 适合高并发、大上下文、生产级服务吞吐量明显更好。个人尝鲜或小团队内部用 Ollama 完全够面向公司级并发 API 才需要 vLLM。边缘设备比如 Jetson Orin 也可以跑量化后的模型适合产线巡检、边缘问答这类场景。本地部署的提示词设计和 API 场景其实没本质区别但我会额外强调一条本地模型通常参数量更小指令遵循能力弱一些提示词要写得更直白、短句为主少用委婉表达。你不能期望 7B 模型完美执行“请你稍微考虑一下用户的体验感受然后以一种不那么正式的方式回复”它会被这种绕弯指令绕晕的。2.7 多工具编排与智能体从单次问答到闭环自动化最后这个场景是当前最热门也最容易翻车的赛道。所谓编排是把“大模型 工具 上下文 Agent 循环”组合成一个能自动完成多步任务的系统比如让 AI 自己查资料、写文档、调用浏览器、操作页面。社区里常说的“harness”就是这个运行框架你装好 harness、绑定 skill、接好模型就能跑一个多智能体流程。但我要提醒一句多智能体编排目前还很“脆”。模型偶尔会状态错乱工具调用结果不返回或者 Agent 陷入死循环自己出不来。我见过最典型的问题就是 messages tool calls need immediate results这个错误在快速迭代的框架版本里尤其常见。所以我的落地原则是先做单 Agent 的固定流程跑稳了再去碰多 Agent 协作能用 prompt 约束解决的流程不用复杂框架解决。第 6 部分我会给排查这个错误的完整思路。简单说先检查框架是不是太老再检查是否并行触发了多次工具调用而框架不允许最后看每个 tool_call 的结果有没有紧跟对应 id 返回。把这三点过一遍基本能解决九成问题。3. 50 个提示词工程实例按场景分类直接抄3.1 办公写作与文本生产类实例 01-10这一组是最高频的日常模板。核心用法是把带【】的占位符替换成真实内容模板本身不需要调整太多。如果生成结果不稳定优先检查是不是原始材料给得不够。注意区分“润色”和“重写”润色是保留原意改表达重写是允许改结构换风格提示词里一定写清楚。实例01会议纪要整理请把以下会议原始记录整理为结构化纪要包含【参会人、讨论主题、关键结论、待办事项负责人截止时间】。只整理原文出现的信息不要脑补补充。原文内容如下——实例02周报生成我本周完成了以下事项——。请生成一份周报分为【工作进展、数据结果、问题与风险、下周计划】四段语气务实不要夸大成果每段不超过 60 字。实例03邮件润色请把下面这段草稿改写为一封正式商务邮件。要求语气礼貌但不过度客套主题明确逻辑清晰无论你需要什么补充信息都不要编造。草稿如下——实例04去AI味改写下面这段文字有比较明显的 AI 生成痕迹请改写得更像人类写作。要求保留核心信息增加自然的语气词与不规则句式减少排比和总结句不改变意思。原文——实例05短视频脚本生成请为我生成一个约 60 秒的短视频口播脚本主题是【如何用大模型整理会议纪要】。结构前 5 秒抛出痛点30 秒讲具体步骤最后 15 秒给结论与引导。口播语言口语化不提专业术语不解释。实例06PPT 大纲生成请把以下主题扩写为一份 12 页 PPT 大纲【XX 产品季度复盘】。每一页写清页面标题和要点列表3-5 个逻辑从现状到问题到解决方案到下一步计划推进。实例07工作总结提炼以下是我这个季度的零散工作记录——。请提炼成一份季度总结归纳出亮点、不足、改进措施三个部分。使用具体数字时以我提供的记录为准不要自行估算。实例08思维导图大纲请把下面这段资料整理成思维导图的树状结构用 Markdown 的层级列表输出最多三级——实例09多语言翻译本地化将下面这段中文翻译成英文。要求不要逐字直译按英语商务表达习惯做本地化专业术语保持准确遇到不确定的术语用【】标记出来。待翻译内容——实例10竞品分析框架请根据我提供的竞品信息输出一个结构化竞品分析维度包括【产品定位、目标用户、核心功能、定价策略、优劣势】。信息不足的维度标注“待补充”不要编造。竞品信息如下——3.2 编程开发类实例 11-20编程类提示词最重要的一点是“给全上下文”。光丢一个空函数让它实现功能它只能猜需求。写清楚输入输出、边界条件和你要的技术栈效果会天差地别。另一个心得是 Debug 类提示词要限制答案范围让它先分析再动手不要直接给修改代码。实例11单元测试生成请为下面这个函数生成 pytest 单元测试。要求覆盖正常输入、边界条件、异常输入三类用例测试函数命名用 test_ 开头不要修改源函数。函数代码如下——实例12代码逐段解释请逐段解释下面这段代码的作用重点说明输入输出、数据结构变化和可能的性能瓶颈。语言使用中文每段解释不超过三句话。代码——实例13报错定位分析这是我的报错堆栈和相关代码。请先列出 3 个最可能的根因按可能性从高到低排序然后说明每个根因的判定依据。先不要给修复代码。报错—— 代码——实例14代码重构建议请对下面这段代码做重构分析。指出可读性、性能、可维护性三个维度的问题并给出重构方案。要求保留原有功能不引入新的依赖。代码——实例15SQL 查询生成以下是数据库表结构——。请写一条 SQL 完成需求——。要求使用标准 SQL 语法考虑 NULL 值处理避免全表扫描的写法若可优化请说明。实例16正则表达式生成请生成一条正则表达式用于匹配【邮箱地址/手机号/特定格式编号】并解释每个部分的含义。测试用例包括一个合法样例、一个非法样例。实例17算法实现请用 Python 实现以下需求【对给定二叉树做中序遍历返回节点值列表】。要求提供递归和非递归两种解法注明时间复杂度和空间复杂度并写两个测试例子。实例18代码审查请审查下面这段代码按【严重问题、潜在隐患、风格建议】三类输出。每一条都要指出具体行号和修改建议。代码——实例19接口文档生成下面是后端接口代码——。请生成一份接口文档包含接口地址、请求方法、请求参数类型必填说明、响应示例、错误码。格式用 Markdown 表格。实例20日志分析脚本请写一个 Python 脚本分析下面这段日志样例粘贴统计每个错误码出现的次数、时间分布并输出异常模式的 TOP3。脚本要能直接跑只依赖标准库。3.3 企业知识库与检索问答类实例 21-28知识库场景最大的干扰是“模型太爱脑补”。下面的模板统一加了“未提及就是不知道”的约束这是 RAG 落地的保命条款。另外如果你的向量检索结果不稳定不要把全部资料一次性塞进提示词先做一次粗筛再让模型精读效果和成本都会好很多。实例21RAG 知识库问答请仅根据以下检索资料回答用户问题。如果资料中没有相关信息请明确回复“资料库中未找到相关信息”不要结合你自己的常识作答。资料—— 问题——实例22文档摘要生成这段文档约 5000 字请生成一个 200 字以内的摘要。要求覆盖核心结论和数据指标保留原文表述的数字与专有名词不加入个人观点。文档——实例23术语表生成请从下面文档中提取专业术语每个术语给出简洁定义定义必须基于文档内容。按出现频率排序输出 Markdown 表格术语 | 定义 | 首次出现页码。文档——实例24企业内部制度解读请根据提供的内部制度文档回答员工问题。回答时先引述制度原文关键句再做白话解释。制度未覆盖的场景请说明“制度未覆盖请咨询对应负责人”。制度—— 问题——实例25多资料综合报告以下是【材料1、材料2、材料3】。请综合这些资料生成一份报告章节包含共同结论、差异点对比、证据缺口。材料之间的冲突必须明确指出不能自行调和。实例26FAQ 构建请根据下面这份操作手册生成一份 FAQ 列表覆盖新手最容易困惑的 10 个问题。每个问题给出直接答案引用手册原文注明章节位置。手册——实例27会议决策追踪以下是连续三次会议的纪要和待办清单。请输出一份“决策追踪表”包含之前定的决策、当前状态、是否出现变更、遗留事项。状态不明的条目标记“待确认”。纪要——实例28技能培训问答生成请基于这份培训课件生成 10 道测试题覆盖核心知识点。题型要求5 道单选、5 道情景判断题。每道题附答案和解析解析要引用课件原文。课件——3.4 智能客服与业务对话类实例 29-36客服场景的提示词讲究“尺度”。既要阻止模型越权承诺也要让它有温度。我给组内定过一个规矩所有涉及金钱、时效、法律风险的表述模型只能引用话术库原文。下面的模板都内含这个规则你可以根据自己的业务调整。实例29客服开场白你是一位电商客服。用户进线后先用一句话表示欢迎并询问需要什么帮助。要求语气自然不超过 20 个字不要主动推荐商品。开头示例“您好有什么可以帮您”实例30情绪安抚话术用户因物流延迟不满情绪激动。请先表达理解与歉意再说明当前可采取的查询措施最后引导提供订单号。禁止推卸责任禁止使用“这是规定”这类冷硬表达。实例31退换货流程问答请基于以下退换货政策文档回答用户问题——。回答要求先直接给结论再说满足条件最后列操作步骤。如果用户的商品情况不在政策范围内明确说无法办理并建议人工介入。实例32投诉升级判定判断以下用户消息是否需要转人工涉及金额纠纷、人身攻击、反复追问三次以上、提出投诉工单。输出格式转人工 / 不转人工 理由一句话。实例33多轮对话状态跟踪你是客服助手。已知用户当前诉求是【退款 200 元】上一轮你已经询问了订单号。现在用户回复了——。请提取订单号并判断下一步动作确认信息 / 查询政策 / 转人工。实例34快捷回复生成请把以下客服回复缩写成 30 字以内的快捷话术保留关键信息语气友好【回复原文】——实例35用户意图分类对下面这条用户消息做意图分类只能是以下类型之一咨询、投诉、退换货、物流查询、售前、闲聊。输出格式只返回分类名。消息——实例36转人工判断与交接摘要请根据对话记录判断是否转人工。若转人工输出一段 50 字以内的交接摘要包含用户核心诉求、已完成动作、下一步建议。对话记录——3.5 数据提取与结构化处理类实例 37-42结构化数据提取的精髓是“给 schema 比给描述有用”。你用自然语言描述一百遍“提取金额”不如直接给它一个 JSON 样例。这可能不是一个“纯提示词”技巧而是提示词与输出约束的组合但这恰恰是工程落地中最关键的一环。实例37合同关键字段提取请从以下合同中提取字段合同编号、签约日期、双方主体、合同金额、付款节点、违约条款。输出 JSON日期统一为 YYYY-MM-DD金额转为数字并保留两位小数。未出现的字段不输出值为 null。合同原文——实例38聊天记录待办提取请从以下聊天记录中提取所有待办事项输出 JSON 列表字段task待办内容、owner负责人找不到时返回 null、deadline时间点原文有就填没有则 null。聊天记录——实例39JSON 格式化输出请把下面这段非结构化文本转成 JSON要求所有 key 使用英文小写下划线命名value 使用中文。如果文本包含多个对象用数组输出。文本——实例40表格转 Markdown请把这张图片表格里的数据完整转成 markdown 表格。要求保留表头和各列顺序单元格内容不做翻译合并单元格用空单元格表示数字保留原格式。实例41日志根因抽取以下是一组应用日志。请分析并输出 JSON字段包括error_key报错类型、possible_cause可能根因、impact影响范围、suggestion修复建议。每条报错输出一个对象。日志——实例42实体识别与关系抽取请从下面文本中抽取所有组织、人物、产品、地点实体并输出实体关系三元组subject, relation, object。输出 JSONrelation 用动词短语描述。文本——3.6 本地部署与安全合规场景类实例 43-46本地部署场景的提示词没那么多花活重点是“数据不出域”和“模型能力降级应对”。小参数量模型对长指令的理解能力有限所以这类模板都偏短、偏直接。实例43本地模型部署文档生成请生成一份把 DeepSeek 模型部署到离线服务器上的操作文档步骤包含环境检查、依赖安装、模型文件导入、服务启动、接口自测。假定服务器不能访问外网所有命令只使用离线包。实例44敏感信息脱敏请把下面文本中的手机号、身份证号、银行卡号、邮箱替换为【已脱敏】其他内容原样保留。输出时保持段落结构不另外解释。文本——实例45内网知识问答离线版以下是内部资料——。请回答——。规则只依据内部资料回答资料没提到就不能说回答用词通俗避免堆砌术语。如果你不知道直接说不知道。实例46边缘设备模型效果评估请根据以下测试样本对本地部署的小模型生成效果做评估从【指令遵循、格式正确性、回答完整性】三个维度打分。每个样本输出分数和一句话评价。测试样本——3.7 智能体与多工具编排类实例 47-50智能体场景的提示词其实主要喂给“调度层”而不是喂给“生成层”。你的目标是让 Agent 在“要不要调用工具、调用哪个工具、拿到结果后怎么继续”这些节点上做对决策。所以实例 47-50 偏决策与控制。实例47工具调用意图识别根据用户消息判断是否需要调用工具。选项search搜索网页、read_doc读取文档、code执行代码计算、none直接回答。输出 JSON{tool: xxx, reason: 一句话理由}。用户消息——实例48多步骤任务规划器请把以下任务拆解为最多 5 步执行计划。每步需要标明依赖项、输入、输出。将【可以用代码完成】的步骤打上标记。任务——实例49Agent 运行日志总结与下一步建议以下是 Agent 最近一轮的运行日志——。请总结已完成动作、当前状态、失败原因如有、下一步建议。不要修改日志中的事实。实例50浏览器自动化动作转步骤请把下面的自然语言指令转换为浏览器自动化步骤列表每一步用 {动作: click/input/wait/extract, 目标: 元素定位或文本描述, 参数: 输入内容} 的格式输出。指令——4. 提示词工程、上下文工程、System Prompt、Skill/Agent到底怎么区分4.1 提示词工程核心是“一次问答里的指令设计”很多人把提示词工程理解成“把话说得好听一点”其实它是一整套约束问题空间的方法。一个标准的提示词长这样角色、目标、背景、约束、输出格式。五个要素里约束和输出格式是绝大多数人最容易漏掉的。你问模型“帮我写个文案”它只能猜你想要的语气、长度和结构。你改成“你是面向中小企业销售的资深文案目标是把这款软件的优势讲清楚篇幅 200 字三段式痛点-方案-行动号召禁止夸张用语”输出质量会立刻上去。这不是玄学是你在帮模型缩小搜索空间。我在 50 个实例里反复用了两种结构一种是“原文 任务 格式”适合整理类任务另一种是“角色 目标 禁止项”适合生成类任务。两种对应不同的任务类型别混用。整理类任务的核心是忠实生成类任务的核心是风格和边界。4.2 上下文工程比提示词更高一层的东西上下文工程说的是模型生成前你往上下文窗口里放什么。包括 system prompt、few-shot 示例、检索回来的资料、历史对话、工具定义。提示词只是其中的“指令”部分所以严格来说上下文工程是提示词工程的上位概念。最典型的例子就是 RAG。你在知识库场景里写的那句“只依据以下资料回答”本身是提示词但真正决定回答质量的是你塞进去的那几段资料。资料检索得好不好、排序对不对、冲突有没有被识别这些已经超出了“怎么写提示词”的范畴属于上下文工程。实操建议每次接项目前先列一个问题清单——这条对话的上下文里有哪几类信息哪部分是必须保留的哪部分可能会误导模型模型需要什么样的输出格式才方便下游代码解析把这些问题过一遍比反复调提示词有效十倍。4.3 System Prompt 与 Skill/Agent 的区别制度、技能书和干活的人我用一个类比System Prompt 是公司的规章制度它规定了你“是什么角色、能做什么、不能做什么”Skill 是岗位技能手册封装了完成某类任务的指令、示例和调用流程Agent 是那个拿着制度手册和技能手册去干活的人它决定当下该翻哪本手册、用哪个工具。实际工程里三者是分层配合的。System Prompt 保持稳定通常只改版本不改内容Skill 按任务拆分你可以有“SQL 生成 skill”“会议纪要 skill”“竞品分析 skill”每个 skill 内部自带提示词和工具调用说明Agent 是个运行时循环它根据用户输入选择调用哪个 skill。别把这三层混在一个提示词里写。我见过有人把几十条规则全部塞进 system prompt结果模型无所适从每条规则都遵守得很勉强。正确的做法是全局规则放 system prompt具体操作放 skill 层决策逻辑放 agent 层。越底层越短越上层越具体。4.4 一个通用模板三段式结构从哪里都能套无论接什么场景我推荐一套兜底的提示词模板【角色与任务】你是一个【角色】负责【任务说明】。 【上下文与材料】以下是背景材料——。 【约束与输出】输出格式为【格式】要求【关键约束】禁止【负面约束】。为什么三段式有效因为它把“你是谁、你要干嘛、你的边界在哪”分开了。模型对角色理解越清晰对任务边界越明确输出就越可控。你写提示词遇到不知道怎么改的时候就往这三个框里补内容比东一句西一句地加限制强。5. 集成实操从 API 到 IDE、企业微信、本地部署5.1 API 调用OpenAI 兼容接口的快速接入DeepSeek 的 API 兼容 OpenAI 格式这意味着你几乎可以替换所有已经接好 OpenAI SDK 的代码。官方接口地址是公开基础地址模型名以官方文档当前发布为准别拿新闻里的代号直接填这是最容易出低级错误的地方。from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个严谨的助手}, {role: user, content: 用一句话解释什么是上下文工程}, ], temperature0.7, ) print(resp.choices[0].message.content)几个注意点不要在前面的路径里多加一层写错会 404流式输出时记得处理增量内容如果要做工具调用先检查你用的 SDK 版本的 tool 参数格式。如果你是在代码生成工具里配 DeepSeek把 base_url 指向同一个接口通常选适配 OpenAI 兼容的选项就行。5.2 接入 VSCode 与 Codex开发环境里最顺的一条路目前主流的做法是用 Continue 或 Cline 这类 VSCode 插件在模型配置里选择自定义 OpenAI 兼容接口填入 DeepSeek 的 base_url 和模型名。配好之后选中代码就可以让它解释、补测试、做审查体验接近 ChatGPT 的代码辅助。往 Codex 或其他 CLI 工具里接入也是同一套思路找到配置文件把模型 provider 改成自定义 OpenAI 兼容地址指向 DeepSeek API。要注意的是 CLI 工具对工具调用的协议版本要求比较高如果你用的是旧版的框架很容易碰到第 6 节说的 messages tool calls need immediate results。这类问题通常升级到较新版本就能解决。这里补一个我自己常用的配置检查清单确认模型名是否在官方文档列表内确认请求是否走 HTTPS确认代理设置不会拦截大模型接口确认本地插件没有重复配置多个 provider 导致请求串线。5.3 企业微信/微信公众号接入5 秒超时是第一个要绕着走的坑接入企业微信的核心步骤是创建自建应用获取 CorpID 和 Secret配置接收消息的 URL做签名校验收到用户消息后调 API回复消息。公众号的思路类似但多了永久素材、客服接口一类的东西整体架构一致都是回调 大模型 API 主动推送。最大的坑在被动回复超时限制上。用户发一条消息微信要求你 5 秒内回复而大模型接口通常 2-7 秒不等高峰期更慢。你为了等模型结果直接超时。解决方案就一个把“回复”和“处理”拆开。收到消息后立即接住返回空串或“收到”后台异步处理调用模型拿到结果后用客服消息接口主动推送。用户体验上的代价是“打字中”的状态会不太自然但至少不会报服务异常。安全上也要上心接收回调的 URL 一定要验签微信回调地址暴露在外网很容易被扫描刷量。建议加一层白名单 IP 校验再限制单个用户的消息频率否则月底账单会很刺激。5.4 本地部署Ollama 与 vLLM 两条路怎么选快速验证用 Ollama生产服务用 vLLM这是最省事的判断标准。Ollama 的特点是零配置、一条命令启动、自带 API适合个人电脑和边缘盒子vLLM 的优势是吞吐和并发控制适合多人同时调用。# Ollama 快速启动 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b# vLLM 部署示例模型名以实际仓库名为准 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B --max-model-len 8192硬件上7B 量化模型大约需要 6-8GB 显存13B 以上建议 16GB 起步。如果你的机器是 Jetson Orin 这类边缘设备记得先设置好功耗模式再加载模型。很多人部署完发现速度慢不是模型问题是功率模式跑在低功耗档。本地小模型的指令遵循能力弱于大 API 模型前面 3.6 的提示词模板就是按这个现状设计的。5.5 工具调用与自动化编排的落地注意点工具调用是把大模型变成“执行者”的开关。你要允许模型在某些情况下调用外部工具并定义好每个工具的输入输出 schema。常见错误是工具定义写得过于复杂或者 tool_call 结果返回的格式和框架要求对不上。我的建议是先做最小集只定义一个工具跑通再扩。比如第一步只允许“搜索文档库”第二步加“执行 SQL”第三步再加“浏览器操作”。每一步都验证工具调用的返回是否被正确解析。所有自动化的稳定性不是靠模型而是靠你对输入输出的严格校验。“harness”这类编排框架可以帮你管理上下文、工具和 Agent 循环但框架越重出问题的面就越广。新手阶段优先用最简单的实现一个循环一次调用一个工具拿到结果再进入下一轮。复杂编排在这条稳定链路上逐渐加功能而不是一开始就上全家桶。6. 常见问题与排查实录6.1 工具调用错误messages tool calls need immediate results这个报错我在多个 Agent 项目里遇到过也帮同事排查过好多次。先说结论它通常不是模型的问题是运行框架的问题。触发条件一般是 Agent 发出了多次工具调用请求而框架要求每个 tool_call 的结果必须在下一条 assistant 消息中立即返回一旦中途插入其他内容或结果没有对应上 tool_call_id会话就直接中断。排查路径按顺序走第一升级运行框架到较新版本旧版对并行工具调用的支持很残缺第二如果框架支持配置关闭并行工具调用强制串行执行第三检查工具函数的返回值是否被正确映射到每个 tool_call 的 id 上。多数情况下走到第三步就能找到病根。6.2 扩展加载失败request extension preparation failed这类报错常见于 IDE 插件场景比如 VSCode 里装了 Continue 或 Cline 后启动时报 preparation failed。原因通常是扩展本身损坏、缓存冲突、网络代理拦截了插件市场或模型接口。排查顺序先重装扩展再清缓存重启最后检查网络代理配置。如果你公司有全局代理记得把模型接口域名加进白名单。6.3 输出格式不稳定JSON 解析频繁失败模型输出的 JSON 偶尔被截断或者多了语言解释是提示词工程里最让人头疼的问题。三条对策第一开启 JSON 模式很多 API 支持 response_format 参数第二降低 temperature 到 0 附近温度越高格式漂移越严重第三在提示词里明确“只输出 JSON不要任何解释性文字”并给一个 schema 样例。这三条一起用格式稳定性会大幅提升。6.4 本地部署速度慢、显存不足本地部署最经常碰到的是“模型能跑但很慢”和“显存直接爆”。如果是后者优先换更小参数的量化版本如果是前者检查是不是没有启用 GPU 推理或者上下文长度设置得不合理。max-model-len设得过大显存和计算量都会成倍上涨。边缘设备上还要注意功耗模式不要默认低功耗跑。6.5 成本失控免费额度用完后的账单提醒我一直建议接一个简单的用量统计记录每天的请求数、输入 token、输出 token在系统里做个简单看板。大模型 API 是后付费不看用量很容易月底收到惊吓。另外缓存和提示词压缩也很关键公共 system prompt 尽量走缓存长文档检索先做摘要再送模型这些都能显著省 token。我把高频问题整理成一张速查表方便你遇到问题时快速定位问题现象常见原因排查/解决方案messages tool calls need immediate results并行工具调用返回顺序被打断或结果未紧跟 tool_call_id升级框架、关闭并行调用、检查结果映射request extension preparation failed插件损坏、缓存冲突、代理拦截重装插件、清缓存重启、代理加白名单JSON 输出频繁解析失败温度过高、输出被截断、模型加了解释文字开启 JSON 模式、调低温度、提示词只给 JSON本地部署极慢未启用 GPU、上下文过长、功耗低检查推理设备、压缩 max-model-len、调功耗模式API 返回 401/402Key 错误、余额不足核对 key、检查余额、确认接口地址7. 实操心得与再扩展最后分享几个我自己的体会。第一DeepSeek 这类开源模型的能力成长很快但落地能不能成更多取决于流程设计和数据准备而不是模型本身。别把时间花在反复调一行提示词上先把输入输出和异常路径定义清楚模型自然好使。第二先从一个业务闭环开始。你可以先做一个“给会议纪要生成待办清单”的小工具跑通全链路再扩大比一上来就搞什么全家桶智能体成熟得多。第三提示词库要定期维护。我一开始写的那批提示词用了三个月后回看发现很多约束可以删掉很多格式要求已经过时。模型版本在迭代你的提示词也应该跟着迭代。建议每换一个模型版本就跑一遍你手上最核心的 10 个提示词对比输出质量差太多的及时调整。还有一个小技巧把常用的提示词模板抽成函数或者存成文档模板用变量填充业务参数。这样既能统一格式又方便团队其他人复用。一个人会写提示词不算什么一群人能稳定产出高质量结果才算是真正的落地。如果要继续扩展下一步可以做两件事一是把 7 个场景逐个做深比如客服场景接入自动转人工工单系统编程场景联动 CI 流程二是开始积累你自己的 few-shot 示例集这是门槛最低、收益最稳的模型优化方式。等你积累到 100 条高质量样本的时候你大概已经比绝大多数团队更懂怎么用好 DeepSeek 了。
