简介一份面向DeepSeek等大语言模型的实用提示词模板合集以单个docx文档形式呈现适合金融、法律、医疗、营销、教育、人力资源等领域从业者以及需要借助AI快速完成分析、写作、策划和管理的用户。内容按十五大应用场景组织内置30余套可直接套用的提示词框架从商业银行监管合规自查、合同审查优化到蒙特卡洛模拟、Pre-IPO尽调清单从临床危急重症排查、糖尿病用药方案对比到文献综述、慢病数字健康管理从账号定位与人设打造、爆款选题与脚本优化到效果归因模型、舆情处理SOP再延伸至课程设计、品牌营销、产品需求分析、招聘规划、预算控制等。多数模板采用“角色任务变量输出要求”的结构附带明确的输出格式、评分维度或注意事项可以结合自身需求微调后直接交给DeepSeek执行降低Prompt撰写门槛。文件大小仅42KB共1个docx文件打开即可浏览、编辑和复制。目前已有68人学习下载适合希望系统化使用提示词、减少无效沟通、提升AI输出质量的专业人士。1. 为什么一份 DeepSeek 提示词模板文档值得你花时间整理DeepSeek 提示词模板我一直习惯用 .docx 来存而不是随手记在聊天框里。原因是同一个任务用“帮我分析一下这个日志”和“清洗日志、提取报错行、按等级输出 JSON”问出来效果差距肉眼可见。如果你正在接 DeepSeek API、在本地部署模型或者团队里有人要批量产出内容一份固定的提示词模板文档能省掉大量来回试错的时间。这篇笔记就讲清楚怎么设计、怎么落成 .docx、哪些参数要留、哪些坑必须绕开。它不是什么魔法词而是一份可以每天照着替换变量、发给模型就能稳定拿到结果的“工作协议”。2. DeepSeek 提示词和通用提示词不是一回事先搞清三个关键差异网上能搜到大量万能提示词、爆款 Prompt但直接拿来套 DeepSeek效果往往时好时坏。DeepSeek 系列模型在指令遵循、推理风格和输出格式上的表现跟 ChatGPT、Claude 那些闭源模型不完全一样。做模板之前先要把三个差异认清否则后面每一步都在靠运气。2.1 指令遵循 vs 角色扮演DeepSeek 更吃结构化指令DeepSeek 对“你是一位资深工程师请帮我……”这类角色扮演式开头经常回你一大段客气话然后才开始干活。角色扮演会消耗前面有限的注意力却不一定带来更好的答案。更稳的写法是直接给指令要做什么、输入在哪、输出长什么样。【任务】清洗用户输入的日志文本提取所有报错行并分类。 【输入】用户粘贴的原始日志 【输出】JSON 数组每个元素包含 error_type 和 line_text逻辑上DeepSeek 对齐时强化的是“指令完成度”而不是“角色人设还原度”。你把人设写得再细也不如把“输出 JSON 数组”写清楚来得有效。做模板时我的习惯是保留一行极简角色描述比如“你是一个日志分析助手”把省出来的空间全留给任务、约束和格式。参数说明这里的“输出 JSON 数组”属于格式锚点DeepSeek 通常能严格遵循。如果你写“请用友好的语气回复”它会自由发挥。模板里凡是带引号、带括号、带具体字段名的格式描述命中率都远高于形容词描述。2.2 上下文窗口与格式锚点.docx 模板里必须留的字段DeepSeek 不同模型、不同接入方式的上下文窗口差异很大从几十 K 到上百 K 不等。窗口大不代表你可以把模板写得很长。模板越长真正关键的约束越容易被淹没。我在 .docx 模板里固定保留以下字段让每个使用模板的人一眼就能找到变量位置{ model: deepseek-chat, messages: [ { role: system, content: 你是文本清洗助手。只输出指定格式不做额外解释。 }, { role: user, content: 任务{task}\n输入{input_text}\n约束{constraints}\n输出格式{output_format} } ], temperature: 0.3, max_tokens: 2048 }这里的 messages 结构就是 DeepSeek API 的调用方式。系统消息放恒定规则用户消息放每次变化的变量。模板文档里应该让每个变量占一行并写上“替换说明”。比如“输入把待清洗的日志粘贴到这里不要改动原文格式”。这样即使没看过代码的人也能把 .docx 当作填表工具用。2.3 温度、top_p 与 max_tokens模板里要不要写参数很多人把“温度 0.3”写进提示词正文这是没用的。模型不会读取这句话温度是 API 请求里单独传的参数。但模板文档里必须给参数留位置否则团队里有人随手把 temperature 调到 1.5输出质量立刻崩盘。参数建议范围适用场景temperature0.20.5结构化输出、代码、JSON 解析temperature0.61.0内容创作、头脑风暴、改写top_p0.80.9一般保留默认不需要频繁调max_tokens5124096按任务长度设置防止空转presence_penalty00.3避免重复内容时使用frequency_penalty00.3长文本生成时降低重复模板文档里最好放一张这样的参数表并且在每行后面写明“这个参数控制什么”。对新手来说参数表比一百句忠告都有效。注意DeepSeek 的 api 调用里 temperature 和 top_p 会同时影响采样。两者都调高输出会更随机都调低输出会更稳定。做验收脚本时我固定用 temperature 0.2、top_p 0.85先跑稳定再考虑放开。3. 从零搭建一套可复用的 DeepSeek 提示词模板字段设计与写作顺序很多人在 Word 里建一个空文档把从各处抄来的提示词往里面堆。结果模板越来越长变量越埋越深最后根本没法复用。这一章给出我实际用的字段骨架和写作顺序直接照搬即可。3.1 最小模板骨架任务、输入、约束、输出格式四段式四段式是我用过性价比最高的结构没有之一。它不追求华丽只追求让 DeepSeek 每次都读到同样的信息顺序。顺序不能乱任务在最前输入随后约束在输入之后输出格式压轴。【任务】把用户输入的合同条款整理成风险清单。 【输入】 {contract_text} 【约束】 - 只输出风险项不做其他分析。 - 每条风险用一句话说清触发条件。 - 不得新增原文没有的条款。 【输出格式】 | 风险等级 | 条款位置 | 风险描述 |任务写在最前面是因为模型对开头内容的注意力最强。输入放第二让它知道要处理的对象是什么。约束紧接着输入避免模型在读完大段原始文本后忘了规则。输出格式放最后是因为它更像“交付标准”放到尾部不会挤压任务信息。参数说明{contract_text} 是必须替换的变量不是让模型自己去猜。写模板时变量名最好带下划线或说明性前缀比如 {source_doc}、{raw_log}。变量在 .docx 里用浅灰色底纹标记传到 API 前替换成真实内容。如果你用 Word 的批注功能可以在变量旁写“本字段由程序自动填充手工填写无效”减少人工误操作。3.2 用条件变体处理不同角色R1 / API / Web 三套切换DeepSeek 不是一个模型而是一组接入方式。DeepSeek-R1 这类推理模型擅长数学和逻辑链deepseek-chat 在通用指令上更听话通过 API 接进业务系统时又需要结构化的输入输出。一套模板硬扛所有场景不现实。常见做法是维护三套变体共用同一个四段式骨架只改任务描述和输出格式。R1 变体任务 推理要求 输出推理过程摘要 API 变体任务 JSON 输出 禁止多余解释 Web 变体任务 对话风格 允许补充追问以“代码审查”为例。用 R1 做时模板里加一句“逐步分析先列出问题再给修改建议”用 API 做时改成“只输出 JSON字段为 line_number、severity、suggestion”用 Web 版对话时改成“先给结论再问我是否需要展开”。我在 .docx 里会用不同颜色的标题区分这三种变体但内容不重复维护。每个变体只写差异段落其他字段引用公共部分。这样改一处公共规则三套变体同步生效不会出现改完 API 模板忘了改 R1 模板的情况。3.3 模板里嵌入示例与反例提升稳定性的两个惯用技巧DeepSeek 对“empty prompt”很敏感但对 few-shot 示例相当受用。模板里放 1 到 2 组输入输出对比写十句“请严格遵守”都有效。示例要放在约束和输出格式之间或者紧跟输出格式不要放在最前面。【示例】 输入用户说“你们的网又断了” 输出网络故障相关投诉记录一条严重等级中影响范围家庭宽带反例同样有用但写法要小心。直接写“不要输出这样的内容”模型有时反而照着做了。更好的写法是给替代方案把“不要输出解释”改成“如果出现解释性文字请你删掉后只保留结果”。反例区块在 .docx 里用红色字或删除线标注方便阅读也方便后面做自动化校验时识别。注意示例不要贪多。两个高质量示例足够给五个示例会挤占上下文窗口。示例与真实输入的格式尽量一致字段名相同模型才能把格式迁移过去。4. 把模板装进 .docx用 Word 结构管理提示词版本的实操模板最终要给人用。.docx 的好处不只是好看它能用标题、表格、批注、修订把一份提示词变成团队文档。这一章给出一套可以直接照做的 Word 结构以及一个用 Python 自动生成模板文件的脚本。4.1 为什么要用 .docx 而不是 .md版本、批注与协作的取舍Markdown 适合存代码库但非技术同事打开 .md 往往不知道往哪儿填。纯 txt 没有格式变量和约束混在一起。在线协作文档在浏览器里用着方便但要导出成可复制粘贴的文本时格式经常乱。.docx 是绝大多数办公场景的通用格式支持修订、批注、密码保护还能用标题导航。格式协作是否友好变量标记是否清晰自动化生成难度.txt低容易覆盖低低.md中需代码工具中中.docx高支持批注修订高中在线文档高但导出格式易乱中低我做模板管理时代码仓库里存一份 .md 作为源头每周用手动或脚本方式同步导出 .docx 给业务同事填写。这样开发人员能看 diff业务人员能用 Word两头不耽误。如果你只有一个人用.docx 也值得因为 Word 的大纲视图会把“任务、输入、约束、输出格式”列成清晰的层级比记事本舒服得多。4.2 用 Python-docx 自动生成提示词模板文件最小脚本手动维护多套 .docx 会越改越乱。我一般会把模板结构写成 python-docx 脚本改结构只改代码再重新生成文档。下面这个脚本生成一份带标题、段落和参数表的完整模板。from docx import Document from docx.shared import Pt, RGBColor from docx.enum.text import WD_ALIGN_PARAGRAPH doc Document() # 一级标题 doc.add_heading(DeepSeek 提示词模板日志清洗, level1) # 任务段落 doc.add_heading(任务, level2) doc.add_paragraph(清洗用户输入的日志文本提取报错行并分类。) # 输入变量段落使用浅色字提示替换 p doc.add_paragraph() p.add_run(输入{raw_log}).font.color.rgb RGBColor(0x2E, 0x74, 0xB5) # 约束列表 doc.add_heading(约束, level2) doc.add_paragraph(只输出 JSON 数组不输出其他内容。, styleList Bullet) doc.add_paragraph(每条报错记录包含 error_type、line_text、level 三个字段。, styleList Bullet) # 输出格式表格 doc.add_heading(输出格式, level2) table doc.add_table(rows2, cols2) table.cell(0, 0).text 字段 table.cell(0, 1).text 说明 table.cell(1, 0).text error_type table.cell(1, 1).text 错误类型如 network/timeout doc.add_heading(参数, level2) doc.add_paragraph(temperature: 0.2max_tokens: 2048) doc.save(deepseek_prompt_log_cleaner.docx)逻辑说明add_heading 的 level 参数决定 Word 大纲级别level1 是文档主标题level2 是各区块标题。add_run 用来设置单段内文字颜色变量 {raw_log} 用蓝色标识是“待填充”避免误发。add_table 用于输出格式字段说明比堆文字更清楚。参数说明字体颜色 RGBColor(0x2E, 0x74, 0xB5) 是 Word 默认的超链接蓝用它标记变量别人一眼知道这里要改。styleList Bullet 是 python-docx 内置列表样式不用手动编号。save 时文件名按“deepseek_prompt_用途.docx”的规则方便后续脚本批量处理。4.3 样式约定标题、表格与“不要求模型做的事”区块生成 .docx 只是第一步更关键的是全团队用同一套样式约定。没有样式的模板每个人都按自己习惯改最后版本对不上。元素样式说明一级标题黑体 16pt模板名称二级标题黑体 14pt任务/输入/约束/输出格式变量蓝色文字必须替换再调用示例浅灰底纹不要修改直接照抄反例红色文字用于提醒模型不这样做参数区表格与提示词正文分离这里特别说一下“反例”区块。Word 里用红色文字或删除线标记但在真正传给 DeepSeek 前要把这些标记清理干净否则模型会看到“不要”字样。清理方式有两种一种是复制粘贴时选“只保留文本”另一种是在发送脚本里用 replace 把红色文字相关的标记替换成正常文本。后者更可靠。我还会在 .docx 末尾放一个“变更记录”小节包含日期、修改人、改动内容。没有变更记录的模板过两周就没人敢动。Word 的批注功能适合讨论但最终合入正式版本时要把批注解决完避免残留。5. DeepSeek 提示词模板落地避坑5 个高频翻车现场模板做得越熟练踩坑越多但很多坑是可以提前避开的。这一章列出的 5 个问题都是我实际见过或者踩过的每条按“现象 → 原因 → 解决”写清楚方便你直接对照排查。5.1 提示词里写了“不要”模型反而照做现象模板里写“不要输出多余解释”结果 DeepSeek 每次都先输出一段解释再说“好的下面是结果”。写“不要提到价格”它反而强调“我们不讨论价格”。原因模型对否定指令的遵循率比对肯定指令低尤其是“不要做”这种抽象约束。解决把否定句改成正面指令。“不要输出多余解释”改成“只输出 JSON 数组”“不要提到价格”改成“所有回复中禁止出现数字只写‘面议’”。正面指令越具体越不容易翻车。5.2 模板变量被当成字面内容传给 API现象模板里写{raw_log}发送请求后模型收到的是字面量{raw_log}而不是真实日志。原因替换代码没跑或者模板中花括号与 JSON 格式解析冲突。解决发送前统一用唯一的占位符比如[[RAW_LOG]]不要用单个花括号包裹。content template.format( raw_loglog_text[:2000] ) if [[ in content: raise ValueError(模板变量未替换完成禁止发送)逻辑说明format 会把模板里的{raw_log}替换成真实值检测[[是为了拦住模板里残留的其他占位符。参数说明log_text[:2000]是截断长度避免模板太长这个值按实际上下文窗口调不是越大越好。5.3 .docx 里的花引号与全角标点导致解析偏差现象从 Word 里复制提示词到 Python 代码或 API 调试工具中error_type变成了带弯度的引号JSON 解析直接报错。即使不报错模型也可能把全角冒号当成中文内容处理输出格式失真。原因Word 自动更正会把直引号转成花引号。解决发送前做一次标点清理。import unicodedata def clean_punctuation(s: str) - str: s s.replace(\u201c, ).replace(\u201d, ) s s.replace(\u2018, ).replace(\u2019, ) s s.replace(, :).replace(, ,).replace(, ().replace(, )) return unicodedata.normalize(NFKC, s).strip()逻辑说明\u201c和\u201d是花引号的 Unicode 编码全角标点也手动替换。normalize 会把全角字符统一折叠成半角。参数说明这条函数只做标点处理不改正文内容如果你要保留中文标点在输出中就不要对所有字段做这步只对模板变量区域做即可。5.4 长模板超出上下文窗口后尾部指令失效现象模板前面写了任务和约束最后一行写“输出必须是 JSON”结果模型输出的是大段解释文字。原因上下文过长时模型对尾部信息的注意力下降尤其是指令位于长文本末尾的情况。解决把核心输出格式要求提前到任务段之后而不是放在模板最后。【任务】清洗日志。 【输出格式】JSON 数组字段为 error_type、line_text。 【输入】{raw_log} 【约束】略注意输入放在中段约束放后段这样长日志出现时末尾的约束丢失风险依然存在。更稳的做法是把易失效的约束浓缩成一句话在任务段后重复一遍。比如“任何情况下只输出 JSON”。重复会占用少量上下文但换来的稳定性值得。5.5 多人协作时模板版本混乱改错字段现象A 同事在模板里把“输入”改成“原文”B 同事沿用旧模板调用结果模型把“原文”当成新任务。原因没有版本约束每个人都在本地副本上改。解决在 .docx 头部写明版本号和修改日期并且用脚本校验关键字段是否存在。required_fields [任务, 输入, 约束, 输出格式] for field in required_fields: if field not in doc_text: raise ValueError(f模板缺少关键字段: {field})逻辑说明这段脚本把 Word 里所有文本读出来逐一核对四个字段名缺任一个就拒绝发版。参数说明required_fields 的顺序不重要但字段名必须和模板里的标题一字不差所以模板标题尽量避免口语化变体。6. 让模板自己说话给提示词做回归验证与参数固化模板写完后先别急着投入使用。我的习惯是给每个模板配一份回归脚本同一组输入跑 10 次统计成功率。这步看起来费时但能省下后面大量肉眼对比的功夫。6.1 用同一模板跑 10 次统计输出稳定性import os from openai import OpenAI def run_stability(prompt_content, n10, temperature0.2): client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) results [] for _ in range(n): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是模板执行器。}, {role: user, content: prompt_content} ], temperaturetemperature, max_tokens2048 ) results.append(resp.choices[0].message.content) return results # 校验 JSON 输出成功率 import json ok 0 for r in run_stability(把下面文本转为 JSON{...}): try: json.loads(r) ok 1 except Exception: pass print(fJSON 输出成功率: {ok}/10)逻辑说明这个脚本把模板内容作为 user 消息发送连续跑 10 次用 json.loads 判断输出是否可解析。参数说明base_url 必须指向 DeepSeek API 端点api_key 从环境变量读取不要写死在代码里。temperature 设 0.2 是为了压低随机性如果你想测试上线后的随机波动可以把它调回文档参数表中的实际值。6.2 把“有效模板”固化成团队资产命名、版本与验收标准回归验证通过后模板才真正进入可用状态。我建议团队这样命名和存档deepseek_prompt_用途_vmajor.minor_日期.docx例如deepseek_prompt_log_cleaner_v1.2_20250610.docx。每个模板对应一张验收表记录三项是否通过 10 次 JSON 解析、是否保持固定输出字段、是否有人工抽检通过记录。验收表可以放在 .docx 末页也可以用单独表格管理。模板名必填变量温度max_tokens验收指标负责人日志清洗{raw_log}0.22048JSON 成功率 100%后端组合同风险{contract_text}0.34096字段完整率 ≥90%法务组内容改写{article_text}0.81024人工满意度 ≥80%运营组表格的价值在于把“感觉还行”变成可量化的标准。模板里的变量不是摆设每次上线前都要按表格逐项核对。最后说一个我的习惯最早我也把提示词当玄学觉得调得好是运气调不好就是模型问题。直到连续三次翻车才开始给每个模板配验收脚本、写变更记录、保留回归结果。现在回头看模板本质上是配置不是文案。配置就要有版本、有测试、有回滚手段。希望这篇笔记能让你少走这些弯路也希望你的模板第一次跑出来就是稳定可用的。本文还有配套的精品资源点击获取