企业官网建设流程全解析

简介：一份专为“笔杆子”打造的公文写作框架与提示词工具包，面向政府机关工作人员、企事业单位文秘及公文从业者，帮助解决多场景政务文书撰写效率低、结构不规范等痛点。资源整合二十套写作框架，覆盖领导讲话、总结汇报、问题整改、调研报告、日常文书、方案计划、汇报发言、宣传报道、专项工作、法定文书十大类；每套框架均附标准结构拆解与DeepSeek专属指令，例如工作部署讲话按“提高认识—明确任务—强化保障”组织，年度工作总结采用“成效—特色—问题—计划”四象限结构，并可直接复制指令生成初稿。资源为单个docx文档，共1个文件，包体约16KB，内容紧凑、便于检索复制。目前已有149人学习。使用时可结合“基础框架+最新政策+本地案例=90分材料”的心法灵活增删模块，快速产出逻辑完整、合乎规范的公文骨架，再借助AI指令填充细节，能明显压缩拟稿与修改时间。

1. 为什么公文写作要先设计“指令框架”，而不是直接问DeepSeek

一线文秘的日常不是没话写，而是文体不对、格式返工、语气拿捏不准。直接打开DeepSeek问“帮我写一份通知”，得到的往往是结构完整但一看就是AI写的四不像——标题层级随意、主送机关缺失、结尾来一句“让我们共同努力”，离直接可用差着三遍修改。问题不在模型能力，在于你给的指令没有把公文场景拆开。所谓多场景公文框架设计，就是把通知、请示、报告、函、纪要这些高频文种各自的行文规则、段落骨架、语气边界和禁用表达，提前写成一组稳定复用的DeepSeek指令模板，再按场景组装调用。我基于这套思路在政务文书撰写里跑通了从“模型初稿”到“改动即交稿”的流程，这篇就把它讲透。适合每天要出多篇公文、被格式和套话反复折磨的办公室文秘，以及给政务系统做智能化辅助的技术人员。

2. 把公文写作规则转译成DeepSeek指令模板：先看清通用提问为什么翻车

2.1 通用Prompt在公文场景下翻车：文种串味、格式裸奔、语气跑偏

用通用Prompt让模型写公文，最常见的结果是三种翻车叠在一起。第一是文种串味：“请示”写成了“报告”，“通知”写成了“函”，因为模型训练语料里这些文种的边界本来就模糊，你不点明，它就按最熟悉的文体自由发挥。第二是格式裸奔：主送机关写不写、正文开头用不用“根据”，标题用不用“关于”，这些格式细节模型不会自动补齐，它会按自己见过的混合样式生成，每次都不一样。这两点直接决定一篇公文能不能被办公室收下、能不能进签发流程。我在实际操作中被退回来最多的理由，不是内容跑偏，而是“格式不对，重弄”。

第三是语气跑偏，这个比格式更难修。公文语气有一套约定俗成的分寸感：对上要谦而不卑，对下要明确而不生硬，平级要商洽而不指令。通用Prompt里你写“请用公文语气”，模型理解的是“正式一点”，于是每段都加个排比句、每个结论都来一句双短语，AI味扑面而来。真实政务写作里往往忌讳这种空转的华丽感，讲究直接、可执行、留余地。这本质上是模型不知道你的语气禁区在哪，你不知道模型会往哪个方向即兴发挥。所以只靠一段话描述需求，翻车是大概率事件。想稳定就得把规则前置，用结构化指令告诉模型每个场景里它该是谁、写什么、怎么写、不写什么。

2.2 DeepSeek指令模板的四层结构：角色、文种、段落、禁则

把一条能稳定出稿的指令拆开看，四层结构基本够了。第一层是角色设定，告诉模型它现在是什么身份。同样的通知，办公室起草和基层单位拟稿，口吻完全不同，角色写清楚，模型的遣词基准就锚定住了。第二层是文种规格，写明是通知、请示还是纪要，以及对应的标题结构、主送机关写法、正文必须包含的要素。这一层是把公文的版式常识显式传给模型，让它别靠自己从语料里猜。第三层是段落骨架，规定这篇文章从开头到结尾依次写哪几块，每块大概什么功能、多长。它解决的是“结构自由发挥导致返工”的核心问题——你不给骨架，模型每次生成的结构都不完全一样，看起来都对，放一起对比就乱了。

第四层是禁则，它往往决定一篇稿子能不能用。我一般会明确写“禁止使用首先、其次、最后、综上所述作为段首语”“禁止出现排比句”“禁用我们相信、让我们共同等空话套话”“不得在请示中使用汇报性语言”。禁则本质上是给模型的生成空间画红线，没有红线，模型是倾向于往“漂亮”方向写的，而政务文书恰恰最先砍的就是“漂亮”。四层指令写好后固定下来，就是你框架里的一个场景模板。注意别把四层塞进一段话里，建议用带标记的分段结构，模型对这种格式的解析成功率明显更高。实际测试里，同样一篇会议通知，拆成结构化指令比一段式提问，格式合规率至少能提高六成。

2.3 一份可直接改用的“通知”指令模板与关键参数调整

我直接放一份能用的通知模板，覆盖了通知类公文最常见的场景：上级部门要召开一次工作推进会议，需要拟发会议通知。复制后用，重点看每个标签下的内容是怎么约束模型的。

角色： 你是某局办公室的资深文秘，有十年公文写作经验，熟悉党政机关公文格式国家标准。 文种： 文种为“通知”，标题使用“关于召开XX会议的通知”结构。 主送机关顶格写在正文前一行，使用“各相关科室：”。 落款处写拟文单位与成文日期，成文日期用“2025年X月X日”格式。 段落骨架： 第一段：目的和依据。用“为深入落实……要求”开头，只写一行，不展开。 第二段：会议基本信息。依次写会议时间、地点、参会人员、会议议题，每一项用“（一）（二）”标注。 第三段：会议要求。写会前准备和纪律要求，分两点即可，每点不超过两行。 结尾：用“特此通知。”收束，不写感谢语、不写期待语。 禁则： 禁止使用“首先、其次、最后、综上所述”段首语。 禁止使用“让我们”“让我们共同”“我们相信”等号召性套话。 禁止输出任何口语化表达和网络词汇。 不出现具体人名、真实手机号，用括号占位符代替。

用的时候有三个参数最值得调。第一个是“段落骨架”里的会议议题数量，议题多的会改成三到四项，模型会按你给的编号自动续排，但你要在骨架里写清楚“议题数量以实际为准，逐项列出”。第二个是“禁则”里的占位符策略，涉及具体数字、人名、日期时，用“X月X日”“各单位”这类占位让模型先出稿，人工填数，这样能避开模型编数据的风险，在请示、报告类文种里尤其重要。第三个是“结尾”的写法，通知类用“特此通知”没问题，但如果是转发性通知，结尾应写明“请认真贯彻执行”，所以要根据每篇通知的实际功能替换结尾句，我在模板里会预留两到三个结尾变体。

这套模板跑出来的初稿，满足“可改”的下限：格式固定、段落稳定、语气平淡。真正让初稿变成能签发的稿子，后续还要靠后处理和人工微调，但至少不需要再从零改结构了。多场景框架的意义就在这里：一个文种沉淀一份模板，多份模板挂在场景编码下，按需调用，而不是每次从头组织语言跟模型对话。

3. 多场景公文框架的拆解：把高频文种做成可路由的场景矩阵

3.1 场景矩阵怎么建：文种、行文方向、篇幅、紧急程度的四个维度

框架里的“多场景”不是把文种列个清单就完事，要真正支撑日常使用，得从四个维度交叉定义每个场景。第一个维度是文种，通知、请示、报告、函、会议纪要、批复这六类基本覆盖基层办公室九成业务，先做这六类，别贪多。第二个维度是行文方向，分为上行文、下行文和平行文。同样是“报告”，向上级报送属于上行文，口吻要偏向陈述与说明；如果是一份向科室反馈情况的“报告”或“函”，则更强调沟通与商洽。我在场景编码里会把文种和行文方向拼在一起，比如TZ-XW表示通知下行，QS-SW表示请示上行，避免同文种不同方向共用一套模板。

第三个维度是篇幅档位。我把公文分成三档：简版三百字以内，用于日常事务性通知；标准版六百到八百字，用于常规请示与报告；扩展版一千字以上，用于年度总结、专项报告。篇幅档位直接决定段落骨架里每个模块的字数约束，模型对“写多少字”的感知很模糊，你不给它档位，它会把一篇简版通知拉到一千字。第四个维度是紧急程度，它影响生成时是否附加“即日执行、请于X月X日前反馈”这类时限性字段，以及是否跳过寒暄铺垫直接开篇。我在场景描述里加了一个is_urgent布尔参数，为真时指令会插入一行“开头直接进入事项，不做背景铺垫”。这四个维度交叉后，一个六文种加四维度的矩阵大约能拆出二十几个常用场景，够日常使用。

用表格把这套矩阵落下来，方便对照修改：

注意场景编码不等于指令模板本身，它是一把索引钥匙。框架运行的第一步是识别用户输入对应哪个场景，第二步是加载该场景下配置好的指令模板。场景矩阵的核心价值，是把“写一篇公文”这个模糊需求，转成“在矩阵里查一次表、取一组参数”的确定性操作。有了它，后面接代码实现、接模板管理，才有清晰的抓手。

3.2 框架的数据结构：用JSON把“场景-指令-输出模板”钉在一起

多场景如果靠零散的文本来管理，早晚会乱，我一般用JSON把场景和指令钉在一起。每个场景是一个独立的JSON节点，里面装场景编码、场景名称、适用的指令模板路径、输出格式要求、占位符说明和自检项。这样做的直接好处是：场景配置和调用代码分离，改模板不需要动代码，加新场景只需要新增一个JSON节点。

下面这个JSON结构就是我在框架里实际使用的场景配置模板，字段不多，但每一个都直接对应运行时行为。

{ "scenario_id": "TZ-XW-S", "scenario_name": "下行通知-标准版", "doc_type": "通知", "direction": "下行", "template_ref": "templates/notice_standard.txt", "output_spec": { "title_format": "关于……的通知", "body_paragraphs": ["目的依据", "基本信息", "工作要求", "结尾"], "closing": "特此通知。" }, "placeholder_fields": ["会议时间", "会议地点", "参会人员", "议题列表"], "self_check": ["标题含文种", "主送机关顶格", "无口语词", "时限字段完整"] }

scenario_id是运行时路由用的主键，建议用文种加方向加档位拼，保证唯一。template_ref指向该场景的指令模板文件，文件里装的就是第二章那种四层结构的纯文本指令。输出规格output_spec定义了这个场景的固定版式，模型生成后，程序可以按这个规格做一次结构校验，检查标题格式对不对、结尾是不是“特此通知”。占位符列表placeholder_fields是给人工填数用的，凡是模型不该编的内容全部列入这个数组，生成后程序可以扫描输出，凡是占位尚未补全的字段统一高亮提示。最后的self_check是模型自检清单，DeepSeek生成完正文之后，再发一次轻量请求，让它按清单逐项检查自己的输出，把不合规项挑出来修改。这套数据结构跑起来之后，新增一个文种场景的边际成本就降到了十几分钟。

3.3 场景路由：先让模型自己判文种，再加载对应指令

有了场景矩阵和JSON配置，还差一步：用户给出一段需求描述，怎么确定它对应哪个场景。最稳的做法不是用规则硬匹配关键词，而是先让模型做一次文种判定。实际中很少有人会准确说出“我要一份下行通知”，更多人说的是“下周三有个会，通知一下各科室”，你需要让模型从这里推断出文种和方向。

我通常在调用主指令之前，先发一段轻量的路由指令，让模型输出一个JSON：

判断用户请求对应的公文场景。 用户请求：{用户输入} 从以下场景中选择最合适的一个，只输出JSON： {"scenario_id": "TZ-XW-S", "confidence": 0.95, "reason": "用户提到开会通知各科室，符合下行通知场景"} 要求： 1. 只能使用给定场景列表中的ID 2. 如果无法判断，confidence填0.5以下，scenario_id填"UNKNOWN" 3. 不输出任何解释文字

这一步跑完后，程序拿返回的scenario_id去JSON配置库里查场景，加载对应的指令模板，再发动一次完整生成请求。不要省掉这个路由步骤直接把用户输入拼进主指令，那样模型会在“写通知”和“写请示”之间摇摆，用路由把场景锁死，后续的指令模板才能稳定生效。置信度低于阈值时，我的做法是返回一句“请补充行文对象和事项”，让用户把需求描述完整，而不是硬猜一个场景硬写。实际使用中，这个路由层把误判率压到了个位数，是框架整体稳定性的关键一环。

4. 把框架跑起来：调用DeepSeek的最小实现与输出后处理

4.1 用Python把场景模板串进DeepSeek API请求

场景模板配好后，下一步就是用程序把它串起来。最简的做法是用Python调用DeepSeek的API，把“路由结果”和“场景模板”拼成最终的messages请求。这里我把完整的调用脚本贴出来，代码不多，但每一步都有讲究。

import requests import json def load_scenario(scenario_id): # 从配置文件里读出场景节点 with open("scenarios.json", encoding="utf-8") as f: scenarios = json.load(f) for s in scenarios: if s["scenario_id"] == scenario_id: return s raise ValueError("场景不存在: " + scenario_id) def load_template(template_path): # 读取该场景对应的四层指令模板文件 with open(template_path, encoding="utf-8") as f: return f.read() def call_deepseek(system_prompt, user_input): url = "https://api.deepseek.com/v1/chat/completions" headers = { "Authorization": "Bearer 你的API密钥", # 换成自己的密钥 "Content-Type": "application/json" } payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ], "temperature": 0.3, # 公文场景用低温，防止模型自由发挥 "max_tokens": 2000 } resp = requests.post(url, headers=headers, json=payload) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] def generate_document(scenario_id, user_input): sc = load_scenario(scenario_id) template = load_template(sc["template_ref"]) # 把场景四层指令作为system prompt，用户输入作为具体事项 full_prompt = template + "\n\n本次具体要求：\n" + user_input draft = call_deepseek(full_prompt, "请按要求生成公文全文。") return draft

代码逻辑不复杂，但有两个参数值得单独说。第一个是temperature，公文生成我固定在0.2到0.4之间，超过0.5模型就会开始自己发挥，出现“我们坚信”“务必高度重视”这类多余表达；低于0.2又会让语言过于干瘪，连基础的衔接都丢。第二个是max_tokens，官方的上下文窗口虽大，单次输出过长时模型会出现重复段落的毛病，我按篇幅档位设2000到4000，宁可分段生成再拼接，也不一次拉满。system prompt的位置也很关键，我把四层指令模板放在system位置，把用户输入放在user位置，两个字段分离，模型对指令的执行力明显强于全部塞进一段用户消息里的做法。

这套最小实现跑通后，你就能把框架从手工复制粘贴提为半自动生成。更进一步，可以把路由判定也接入同一段脚本——先用3.3节的路由指令请求一次，拿到scenario_id，再调用generate_document。这样用户输入一句话，程序自动判场景、自动套模板、自动出初稿，整个链路是通的。

4.2 输出后处理：把AI文本规整成公文版式的三种做法

模型输出的是纯文本，离正式公文版式还差一步。最常见的处理方式有三种，按工作量从小到大说。第一种是把模型输出的markdown格式转成Word：模型会自动给标题加“#”、给段落加编号，你可以用pandoc一条命令把markdown转成docx，再套用单位的红头模板。这种做法适合对版式要求不高、仅用于内部流转的场景，胜在快，缺点是转出来的样式和你单位标准的仿宋、黑体、字号规范大概率对不上。第二种是程序化规整：用Python把模型输出按段落切分，识别标题行、正文行、落款行，然后统一写入一个预置好样式的docx模板。这种能解决字体字号问题，代码量在百行左右，适合有开发能力的团队。

第三种是我最常用的做法，做“半结构化输出约束”。在指令模板里加一段输出格式要求，让模型按固定标记输出各个板块，例如用“TITLE”“BODY”“ATTACHMENT”作为板块分隔符，程序拿到输出后按标记切块，再分别填入单位现有的公文模板占位符。这个做法的好处是不需要解析自然语言，切块是确定性的，版式一致性远强于让模型自由排版。我实际用的代码核心就一行解析逻辑：

# 按标记切分模型输出，标题、正文、落款分别存入对应变量 segments = re.split(r"__(TITLE|BODY|ATTACHMENT)__", raw_output)

注意在指令模板里写清每个标记的出现顺序和次数，模型只要有一次漏标，程序侧就抛异常提醒重生成，而不是拿残稿硬填。这种“宁可失败重来也不猜测”的策略，保证了进入版式的每一篇稿子结构都是完整的。如果需要单位标准红头，把docx模板的样式文件固定好，程序只替换文字内容，版式永远是统一的。

4.3 不写代码的落地法：表格管理场景，指令模板作为知识库粘贴

并不是每个办公室都有会写代码的人，很多政务场景落地这类框架，走的其实是另一条路径：用表格管理场景矩阵，把指令模板存成固定文本，每次用到时复制粘贴。这个方法看着原始，实际在团队协作里反而更容易推行。操作步骤是：建一张Excel场景表，六行对应六个文种，每一列写清楚该场景下的指令模板内容、输出格式要求、禁则清单；使用时对照表格复制对应场景的指令，粘贴到DeepSeek对话框，再输入具体需求。

我见过不少办公室就是靠这套方式跑起来的，一两个月后，每个文种的指令模板都被打磨过好几轮，表格从一个“样板”变成了单位自己的“知识库”，新人来了照着表粘贴就能出基本能用的初稿。这个方案的缺点是路由靠人肉判断、模板更新靠手工同步，但优点是零开发成本、任何人可维护。所以我不建议一上来就写代码，先用表格把模板和场景跑熟，确认哪些场景真正高频、哪些模板参数真正有效，再考虑用4.1节的代码把流程串成半自动。框架的核心价值不体现在调用方式上，而体现在“模板沉淀”这件事本身。

5. 公文框架设计避坑与常见问题排查：五个真实翻车场景

5.1 AI味重：模型一开口就是“首先、其次、综上所述”

现象：生成的公文开头永远是“首先，我们要深刻认识到……”，段尾必带“综上所述”，通篇排比句，看着很“正式”，但文秘一看就摇头。原因：模型训练语料里充斥着大量网上的模板范文，这些文章本身AI味就重，模型生成时天然趋向“看起来像好文章”的表达。既然公文的真实标准是“功能直接”，这些华丽表达就成了最大绊脚石。解决：把禁则清单写进指令模板，且越具体越有效。“禁止使用首先、其次、最后、综上所述”比“请用简练公文语气”管用得多。另外在温度参数上做配合，temperature调低到0.3，模型会更忠实于指令里的禁则约束，生成时绕开花哨表达的倾向会明显变强。我把禁则放在指令模板的最后一层，模型对尾部的注意力相对更高，执行效果比放在开头好不少。

5.2 格式反复错：标题层级和文种格式像“抽盲盒”

现象：同一套指令连跑十次，有的输出标题带书名号，有的不带；有的主送机关顶格，有的缩进；落款日期的格式也每次都不一样。原因：模型对“格式”的理解是概率性的，不是规则性的，指令里写“主送机关顶格”，它可能照做一次，下次又按自己见过的其他样式走。这属于生成的不稳定性，不是哪次写错了的问题。解决：不要靠指令里的描述去约束格式，靠后处理。用4.2节的标记切块方案，让模型只输出纯内容，标题、主送机关、落款在程序侧按场景配置里的output_spec统一拼装。凡是模型容易漂移的地方，就把它从生成环节挪到拼接环节，让程序做确定性的事，模型只做内容生成这一件事。这招落地后，格式返工基本清零。

5.3 指令太长就“丢设定”：多场景混在一个指令里互相串味

现象：把通知、请示、报告、函的模板全拼进一个大指令里，生成通知时，标题却带了“请示”的用词风格，结尾混入“妥否，请批示”。原因：模型处理超长指令时，注意力会分散，离尾部近的设定执行得好，靠前的内容容易被忽略；且多个文种的约束互相干扰，同一处内容既被“请示不得用汇报语言”约束，又被“通知要明确部署要求”约束，模型就容易取一个折中，两边都不像。解决：单场景单指令，运行时再拼接。不要让模型同时处理多套文种规则，加载哪一个场景就只送哪一套模板。这个已经写进框架的设计原则里，不要再贪方便把所有模板合并成一个大知识库文件塞进上下文。分模板文件管理，按场景编码加载，是保持指令不串味的前提。

5.4 模型对“数据”过敏：请示里的数字都对不上

现象：一份请示里，项目总金额写了480万，分项明细的金额加起来只有420万；会议时间在标题里是“9月20日”，正文第二段成了“9月21日”。原因：模型不擅长做长文本内的数字一致性校验，它生成时按概率逐词预测，没有“回看前文、检查数字总览与分项合计是否相等”的能力；你让它在生成时顺带算数，属于难为它。解决：占位符策略。指令模板里凡是涉及金额、日期、人数、文号等信息，一律用“〔具体金额〕”“〔具体日期〕”占位，生成后再由人工填数。我为此在框架里加了一道专门的数字自检流程：模型输出完成后，程序扫描所有数字，把同一数字出现的所有位置聚合并列出，人工一眼就能看出不一致。数字准确性这种硬伤，宁可信任人，也别信模型。

5.5 数据安全：敏感政务材料能不能直接传公网模型

现象：单位内部对于“涉密文件不得传输至互联网”有明确要求，但一线人员为了图快，直接把内部数据贴进公网对话模型，存在明显的风险隐患。原因：公网模型的请求要经过第三方服务，敏感信息一旦发出，脱离本单位控制，这个风险甚至比生成质量翻车更致命。解决：先分类再决定路径。不涉密、可公开的一般性事务文稿，走公网API或网页端没有问题；涉密或内部敏感材料，坚决不传公网，改走私有化部署的本地模型。用vLLM或Ollama部署一套本地DeepSeek，把框架的API地址从公网切到内网地址，其余代码逻辑不变。“占位符策略”在这里也能帮上忙：凡是敏感字段用占位符替掉，让模型只处理非敏感结构，最后人工填回真值。框架要从设计上支持这套弹性切换，而不是只有一个公网调用路径。

6. 公文框架跑通之后的进阶：批量生成、自检清单与人工闭环

框架稳定运行后，真正拉开效率差距的是三件事：批量、自检、闭环。批量不是说一次让模型生成十篇不同公文，而是把同场景、同模板、不同事项的多篇稿件串起来跑——比如周一上午要发五个通知、三份函，程序循环加载同一个场景模板，替换用户输入里的会议名称、时间、地点，一次性产出八篇初稿。我通常会在批量脚本里加一个分段停顿，每生成三篇休息几秒，避开API限频，也方便中途看结果。

自检是质量兜底的关键一步。我习惯让DeepSeek在生成完正文后，针对场景配置里的self_check清单再做一轮自查，输出“已满足/未满足”的逐项判定，发现问题再回炉修改。实测这轮自检大约能筛掉八成的格式和口径问题，剩下的是人工复核的活儿。人工闭环则更依赖流程——每次改稿后，把改动点记录下来，定期回填到指令模板的禁则或骨架里。这篇文章开头说的“改动即交稿”，靠的就是这个反复循环：模型写，人改，改法回流，模型再写。随着框架跑得越久，模板越贴这个单位的实际文风，改稿量会肉眼可见地下降。我个人最大的教训是别跳过闭环这一步，模板攒了三个月不更新，它就会慢慢退化成最初的通用水平。希望这个思路和踩坑记录能帮到你。

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