企业官网建设流程全解析

简介：这份实用的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, level=1) # 区块一：变量填写区，只放字段说明，不放提示词正文 doc.add_heading('变量填写区', level=2) 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('提示词正文（整段复制，先填上方变量）', level=2) 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(f'generated: {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软换行——用户用Shift+Enter换行时，Word不生成新段落，而是把一个w:br标签存在run内部，paragraph.text默认忽略它，导致解析结果里两行内容粘连，必须手动补\n。

参数说明：target_heading要和生成脚本里的区块名严格一致，包括括号和空格，否则提取为空。is_heading2判断里排除了Heading 1，防止文档标题被当成区块。中文版Word的样式名会是“标题 2”，上面这段在纯英文环境没问题，中文版需要改成判断“样式名包含‘标题’且不等于‘标题 1’”，或者更稳的做法是直接匹配style_id，不匹配style.name。

4.2 拼装messages并调用API：system层的正确写法

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_url='https://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, json=payload, headers={'Authorization': f'Bearer {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 Shift+Enter软换行，解析后内容粘连

现象：正文区里明明看着换了两行，比如“约束：- 带行号 - 不改代码”是两行，提出来后变成一行，约束逻辑全乱套。

原因：填写模板的人习惯用Shift+Enter在段落内换行，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内部搜索（Ctrl+F）确认内容存在；长期办法是给对方目录加入索引并开启内容索引项。最可靠的做法是脚本导出模板时，同时生成一份同名.txt或.md存档，正文区内容两边一致，这样搜索正文永远有结果。

6. 模板回归验证与JSON导出：把docx当成协作界面来管

提示词模板本质上和代码一样会腐化——改了一个约束，某类输入的效果可能悄悄劣化却不被发现。所以模板必须配回归测试，docx只是给人看的协作界面，机器真正消费的应该是导出的JSON。

6.1 给模板建一个固定输入的基线

为每条模板准备十个固定用例，覆盖典型输入和边界输入，记录每个用例的通过项。基线表格大致这样：

跑基线时temperature必须设为0，否则随机性会把回归结果搅浑。每次改模板，先跑一遍旧版基线，再跑新版，对比通过率变化。这个动作一次只要几分钟，却能拦住九成以上的“改模板改坏输出”。

6.2 一键导出JSON，让模板进入CI

import 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', encoding='utf-8') as f: json.dump(config, f, ensure_ascii=False, indent=2) 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的输出稳定性不再是隔三差五的玄学问题，而是可衡量、可回归、可交接的日常工作流。希望帮到你。

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