简介这份实用的DeepSeek提示词模板以Word文档形式整理面向金融、医疗、营销、产品、人事等岗位从业者以及希望系统化使用AI工具的职场用户。文档围绕风险控制、投资分析、纠纷解决、临床诊疗、健康管理、新媒体运营、数据分析、危机应对、教育培训、财务管理等十五大常见场景集中了数十套可直接套用的提示词指令框架每个模板均包含输入条件、分析要求与输出格式稍加修改即可生成专业内容。资源为单个docx文件大小42KB轻量易用便于随时查阅、编辑与本地保存。目前已有68人学习下载适合需要快速上手DeepSeek并提升日常工作效率的读者尤其推荐给银行合规、医疗科研、电商运营、产品设计等条线人员作为常用提示词库使用。1. DeepSeek提示词模板从零散复制到可维护的docx资产真正让提示词团队头疼的往往不是模型效果而是同一条提示词在不同人手里跑出完全不同的结果有人少填一个变量有人把换行符弄丢有人把输出格式约束改成了旧版本。DeepSeek提示词模板解决的就是这件事——把每次都要靠记忆和聊天记录抢救的提示词沉淀成一份带变量区、带版本、能直接复制进API调用的docx文档。这篇笔记不会跟你讲怎么写提示词本身而是讲怎么把提示词做成模板模板里放什么字段、用python-docx生成docx、怎么从docx提取后拼装成DeepSeek的messages以及文档制作和调用路上真正会踩的坑。适合正在把DeepSeek接入业务、需要多人协作维护提示词的开发者和应用负责人。2. 模板里装什么五个固定块与场景字段设计模板不是灵感的堆砌而是把提示词的“变”和“不变”拆开。不变的是角色设定、任务描述、输出约束变的是每次要喂进去的项目背景、文本样本、候选标签。把这两类内容混在一段话里让每个人每次自行修改是提示词失控的第一来源。2.1 角色、任务、约束、输入、输出提示词模板的五个固定块我经手的大部分提示词模板最后都收敛成五个固定块角色、任务、约束、输入、输出。角色放在最前面决定模型从哪个视角处理输入任务紧跟角色用一个或两个动词说清楚“做什么”约束排在输入之前控制格式、禁止事项、长度上下限输入是可替换的变量区是模板里唯一允许每次变化的部分输出放在最后用列表或JSON结构定义返回格式。为什么不把约束放在最后长提示词里约束位置靠前模型优先遵循一旦把输入文本插进中间靠近文本的指令会被内容冲淡。数据类模板里常见翻车是把“只输出JSON”写在输入之后模型就会在JSON外面加一串解释输出直接报废。把输出格式类约束放到模板末尾等于给模型一个强收尾信号遵循率比放在中段高很多。另一个设计原则是固定指令必须“可验证”。例如约束里写“不要啰嗦”这是不可验证的模型无法判断自己是否达标改成“输出不超过200字”就变成可对照的硬条件。角色块同样要具体说“你是资深数据分析师”太泛说“你有五年零售行业数据分析经验熟悉促销活动评估口径”才能影响输出取向。模板里每一条固定指令都应当能回答“模型做不到算不算失败”这个问题。2.2 用业务场景反推变量字段三张不同岗位的模板表固定块敲定之后变量字段由场景反推。变量是每次填写时唯一的成本变量越多人填错和漏填的概率越高替换时越容易出错。我一般会把变量控制在五个以内超过五个就重新考虑模板是不是拆细了。以下是三个典型场景的字段划分可以直接抄走改了用场景固定指令区块每次变更的变量代码审查角色设定、任务动词、行号与排序约束、禁止改写代码代码语言、项目背景、代码片段营销文案角色设定、调性描述、禁用词清单、字数上限产品信息、目标人群、发布平台数据标注分类定义、标注流程、歧义处理规则原始文本、候选标签列表以代码审查那条为例固定指令区写的是“你是一名五年以上经验的代码审查工程师。只输出问题清单每条必须带行号按严重程度排序不修改原代码”。变量区则只放“语言/背景/代码”三格。使用时把三格填完再整段复制到DeepSeek对话框或API请求里模型拿到的是一份完整、自洽、不含多余痕迹的提示词。这里已经能看到社区里那些deepseek harness类编排工具的思路它们同样把模板拆成“不可变的任务定义”和“每次注入的输入槽位」你把docx里的正文区对应消息层、变量区对应任务槽位接进去时基本不用改结构。模板的独立性因此很重要——它不该依赖某个特定网页端或特定SDK而是纯文本拼装后谁都能用。3. 用python-docx生成提示词模板文档最小脚本与变量标记规范选docx而不是Markdown理由很实际大多数模板的最终审阅者是业务方他们只认Word。流程通常是技术侧起草、运营补约束、法务或主管加批注docx的修订和批注流能完整走完这套协作而Markdown到这一步就断了。对提取端来说docx同样友好下面会给出从生成到解析的完整脚本。3.1 最小生成脚本字段区与正文区分离用一个python-docx脚本生成模板文档核心是让“变量填写区”和“提示词正文区”在视觉上分离在结构上也能通过标题样式区分。生成时只用两层标题Heading 1 给文档名Heading 2 给区块名正文区全部用普通段落。from docx import Document from docx.shared import Pt FONT_NAME Consolas FONT_SIZE Pt(10.5) def set_mono(run): 统一等宽字体避免复制后引号、空格被Word自动格式化干扰 run.font.name FONT_NAME run.font.size FONT_SIZE def create_prompt_template(filename, title, fields, body_text): doc Document() doc.add_heading(title, level1) # 区块一变量填写区只放字段说明不放提示词正文 doc.add_heading(变量填写区, level2) for label, placeholder in fields.items(): p doc.add_paragraph() run p.add_run(f{label}{placeholder}) run.bold True set_mono(run) # 区块二提示词正文区这一段才是真正会发给模型的文本 doc.add_heading(提示词正文整段复制先填上方变量, level2) for line in body_text.split(\n): p doc.add_paragraph() p.paragraph_format.space_after Pt(0) set_mono(p.add_run(line)) doc.save(filename) print(fgenerated: {filename}) fields { 代码语言: Python, 项目背景: 订单服务, 代码片段: 粘贴在此, } body 你是五年以上经验的代码审查工程师。 任务按顺序检查这段代码输出问题清单。 约束 - 每条问题必须带行号 - 不修改原代码只指出问题 - 按严重程度排序 变量 语言{$lang} 背景{$context} 代码 {$code} create_prompt_template(code_review.docx, 代码审查提示词模板, fields, body)逻辑说明脚本先建变量填写区这里只给人类看字段名加粗方便填写时一目了然再建正文区正文区每一行单独成段落段后间距设为零保证复制时不会夹带Word默认的多余空行。正文区里的{$lang}、{$context}、{$code}是占位符随后由程序或人工替换。参数说明字体统一设为Consolas是因为中文版Word的“自动更正”会在键入时把直引号改成弯引号等宽字体不给这种视觉误判留空间虽然它不能彻底阻止自动更正但能把问题暴露得早一些。标题层级只用两级是为了第4章的解析脚本能靠Heading 2精准定位正文区避免行号写死导致模板一改就崩。3.2 变量标记规范{$var}、【】与等宽字体的约定变量标记是最容易忽略、却最影响复用性的细节。我试过用花括号{}做占位符结果和JSON、Markdown冲突模板里出现三段大括号时连自己都分不清哪个是变量也试过用复制到XML场景会触发转义问题。最后落定的是{$var}左花括号加美元符右花括号收尾正则在后面会写辨识度和机器解析都稳定。人看的标注和机器替换的占位符分开。docx里给业务方看的说明文字用【】例如“【必填】项目背景”真正要被替换的占位符用{$}例如{$context}。一个模板里同时出现这两种标记时规则是【】只出现在变量填写区{$}只出现在正文区两边永远不混用。这样业务方不会误改正文区里的占位符代码替换也不会碰到说明文字。另外docx模板头部建议加一张两行的版本表维护人、修改日期、变更内容。原因很朴素——提示词模板的回归问题本质上是版本问题谁改了一个约束导致线上输出异常没有版本表根本追不回来。这张表不是摆设后面第6章的回归测试会围绕它工作。4. 从docx提取提示词并调用DeepSeek API解析、变量替换与消息轮次模板生成完最终要落进API请求。常见做法是用python-docx按标题定位正文区提取纯文本后做变量替换再拼装为messages数组调用DeepSeek API。这里有两个容易翻车的环节软换行丢失、system消息内容写错。下面按完整路径走一遍。4.1 按Heading定位正文区解析脚本与软换行处理from docx import Document def para_text(para): 读取段落时把Word软换行(w:br)还原为\\n parts [] for run in para.runs: parts.append(run.text) for br in run._element.findall(.//w:br): parts.append(\n) return .join(parts) def extract_body(docx_path, target_heading提示词正文整段复制先填上方变量): doc Document(docx_path) lines [] in_section False for para in doc.paragraphs: is_heading2 para.style.name.startswith(Heading) and para.style.name ! Heading 1 if is_heading2: # 进入目标区块开始收集进入其他区块则停止 in_section (para.text.strip() target_heading) continue if in_section and para.text.strip(): lines.append(para_text(para)) return \n.join(lines) text extract_body(code_review.docx) print(text)逻辑说明脚本不按行号定位而是按Heading 2的内容定位这样业务方在变量填写区里加段落、加说明都不会影响正文区提取。para_text函数单独处理Word软换行——用户用ShiftEnter换行时Word不生成新段落而是把一个w:br标签存在run内部paragraph.text默认忽略它导致解析结果里两行内容粘连必须手动补\n。参数说明target_heading要和生成脚本里的区块名严格一致包括括号和空格否则提取为空。is_heading2判断里排除了Heading 1防止文档标题被当成区块。中文版Word的样式名会是“标题 2”上面这段在纯英文环境没问题中文版需要改成判断“样式名包含‘标题’且不等于‘标题 1’”或者更稳的做法是直接匹配style_id不匹配style.name。4.2 拼装messages并调用APIsystem层的正确写法import re import requests def fill_variables(template_text, variables): 按{$var}替换并检查是否还有未填写的占位符 for key, val in variables.items(): template_text template_text.replace({$ key }, str(val)) missing re.findall(r\{\$(\w)\}, template_text) if missing: raise ValueError(f还有未填写的变量: {missing}) return template_text def call_deepseek(template_text, variables, api_key, base_urlhttps://api.deepseek.com/v1/chat/completions): user_msg fill_variables(template_text, variables) # system只写一句角色定义全部放在user消息里 payload { model: deepseek-chat, messages: [ {role: system, content: 严格按用户消息里的提示词模板执行不要改动任何约束。}, {role: user, content: user_msg} ], temperature: 0.3, max_tokens: 2048, } resp requests.post( base_url, jsonpayload, headers{Authorization: fBearer {api_key}} ) resp.raise_for_status() return resp.json()[choices][0][message][content]逻辑说明system只保留一句“按用户消息模板执行”角色、任务、约束全部放进user消息。原因是DeepSeek对system的遵循权重很高如果system里写了“你是助手”模板里又写了“你是代码审查工程师”模型会倾向先用system身份回应模板里的角色设定就失效了。把模板完整放进user等于全部交给模板控制。参数说明temperature设为0.3比较稳因为模板场景要的是可复现的输出而不是发散创意如果跑回归测试则直接设0。max_tokens按输出体量调整问题清单类2048够用生成报告类要提到4096。base_url按你实际网关调整自建vLLM或接入商的网关地址各不相同。补充一个工具调用场景的注意点如果模板涉及工具调用messages里一旦出现tool_calls字段就必须在本轮立即执行工具并把结果以tool消息返回。常见报错“tool calls need immediate results”就是代码里等模型输出了正文又要继续生成导致工具结果插入时机错了。处理办法是检测到响应里有tool_calls就中断本轮执行完工具再追加一条role为tool的消息继续对话不要让模型一边出正文一边等工具。5. DeepSeek提示词模板避坑智能引号、丢表与约束漂移docx模板这条链路坑大多不在DeepSeek这边而在Word本身。下面是五条有代表性的踩坑记录按发生的频率排序每一条都按现象、原因、解决的顺序写可直接对照排查。5.1 docx自动把直引号变弯引号JSON解析直接报错现象模板正文区里的代码片段明明是英文双引号从Word复制出来发给API后请求直接报JSON解析失败打印出来一看引号变成了“ ”。原因Word“自动更正”默认开启“直引号替换为弯引号”用户粘贴或键入时会把ASCII引号替换成中文全角引号。python-docx生成模板时如果字体设成宋体等中文字体这个替换在视觉上几乎无感知直到机器解析才暴露。解决生成脚本里统一设等宽字体并在提取端做一次兜底替换def normalize_quotes(text): text text.replace(\u201c, ).replace(\u201d, ) text text.replace(\u2018, ).replace(\u2019, ) return text把这段加在fill_variables之前所有从docx来的文本先过一遍。同时建议在Word里手动关闭“自动更正”下的“直引号替换为弯引号”选项双管齐下问题基本绝迹。5.2 ShiftEnter软换行解析后内容粘连现象正文区里明明看着换了两行比如“约束- 带行号 - 不改代码”是两行提出来后变成一行约束逻辑全乱套。原因填写模板的人习惯用ShiftEnter在段落内换行Word记录的是w:br标签而不是新段落paragraph.text不会返回这部分换行信息。解决解析时遍历每个run内部的w:br手动补\n。第4.1节的para_text函数就是干这个的。注意还要处理run._element.findall(.//w:br)查不到的情况——某些版本的python-docx里w命名空间需要显式指定可以在解析前先打印run._element.xml确认。5.3 模板里的表格在提取时被静默丢弃现象正文区放了一张“严重级别对照表”作为约束参照输出时模型只说“请参考级别表”但请求里根本没有表的内容模型只能猜输出自然不合格。原因doc.paragraphs只遍历段落不包含表格。表格内容存在doc.tables里解析脚本只读paragraphs就必然丢表。解决提取时同时遍历doc.tables按行合并单元格文本def extract_tables(doc): table_rows [] for table in doc.tables: for row in table.rows: cells [cell.text.strip() for cell in row.cells] table_rows.append( | .join(cells)) return \n.join(table_rows)然后把返回的表格文本追加到正文区之后。设计建议模板里的表格越短越好超过五行就要考虑是否可以直接写进约束文字里因为表格一旦跨页提取顺序容易乱。5.4 规则越加越多输出反而开始丢约束现象模板迭代到第四版业务方陆续加了“必须带缩进”“不要提竞品”“语气专业”“每条都要给建议”共十条约束结果模型开始漏掉后半段的输出格式要求奇葩的是漏的总是最后几条。原因长提示词中部和后部的指令遵循度逐步衰减这是模型注意力的特性不是DeepSeek独有。约束内部相互覆盖也加剧了这个问题比如“语气专业”和“不要提竞品”其实都在限制表达空间。解决把固定约束压到五条以内语义重叠的合并输出格式要求挪到模板最后一句用“最后检查一遍只输出JSON不要带解释”这种强收尾句式。如果规则实在压不下来考虑拆成两轮第一轮让模型输出候选第二轮用规则过滤效果比堆十条规则好。5.5 Windows里搜不到docx正文现象模板文件发给同事对方在资源管理器搜索框里输入“代码审查”这样的正文关键词什么都搜不到以为文件发错了。原因Windows Search默认只索引docx的文件名和元数据不索引正文内容。即便系统安装了Word iFilter索引选项没有开启“文件内容”搜索时正文仍不参与检索。解决临时办法是让对方用Word内部搜索CtrlF确认内容存在长期办法是给对方目录加入索引并开启内容索引项。最可靠的做法是脚本导出模板时同时生成一份同名.txt或.md存档正文区内容两边一致这样搜索正文永远有结果。6. 模板回归验证与JSON导出把docx当成协作界面来管提示词模板本质上和代码一样会腐化——改了一个约束某类输入的效果可能悄悄劣化却不被发现。所以模板必须配回归测试docx只是给人看的协作界面机器真正消费的应该是导出的JSON。6.1 给模板建一个固定输入的基线为每条模板准备十个固定用例覆盖典型输入和边界输入记录每个用例的通过项。基线表格大致这样用例编号输入要点检查点v1.0v1.1case01正常代码片段行号完整、排序正确通过通过case02空代码片段明确拒绝、不瞎猜通过失败case03极小代码单条问题不重复通过通过跑基线时temperature必须设为0否则随机性会把回归结果搅浑。每次改模板先跑一遍旧版基线再跑新版对比通过率变化。这个动作一次只要几分钟却能拦住九成以上的“改模板改坏输出”。6.2 一键导出JSON让模板进入CIimport json, re def export_template_config(docx_path, output_path): body extract_body(docx_path) variables re.findall(r\{\$(\w)\}, body) config { name: docx_path.replace(.docx, ), body: body, variables: sorted(set(variables)), model: deepseek-chat, temperature: 0.3, } with open(output_path, w, encodingutf-8) as f: json.dump(config, f, ensure_asciiFalse, indent2) export_template_config(code_review.docx, code_review.json)逻辑说明导出脚本把正文区和变量清单固化成一个JSON文件这个文件才是API调用层的输入。改动模板时只有重新导出JSON并跑过基线测试新版本才算生效——防止有人只改了docx忘了同步到线上。参数说明正则\{\$(\w)\}匹配{$lang}这类占位符variables字段用于调用前校验必填项model和temperature同步记录在配置里避免各个调用端自行设定导致行为不一致。我的习惯是模板文件名直接带版本号比如code_review_v1.1.docx导出JSON时版本号写进文件头。这样docx负责给人看JSON负责给机器跑两边靠版本号锚定改起来不会互相覆盖。这个结构跑了几个项目DeepSeek的输出稳定性不再是隔三差五的玄学问题而是可衡量、可回归、可交接的日常工作流。希望帮到你。本文还有配套的精品资源点击获取