企业官网建设流程全解析

简介：这份资源面向政府机关工作人员、企事业单位文秘及笔杆子从业者，针对公文写作中框架搭建慢、逻辑不清晰、反复修改耗时等痛点，提供笔杆子专用的二十套写作框架与配套DeepSeek指令。内容覆盖领导讲话、总结汇报、问题整改、调研报告、日常文书、方案计划、汇报发言、宣传报道、专项工作及法定文书等类别，每类均给出标准结构与可直接套用的AI指令，如工作部署讲话的“提高认识、明确任务、强化保障”三段式，年度总结的成效、做法、问题、计划四模块，并强调“基础框架+最新政策+本地案例=90分材料”的实用心法。资源包为1个docx文档，大小约16KB，轻量易读，便于随时查阅与复制指令。目前已有149人学习。读者可借此快速搭建规范框架、生成高质量初稿，减少反复打磨的时间成本，并结合本地实际灵活调整，举一反三提升政务文书撰写效率与质量。

1. 公文写作遇上 DeepSeek：多场景框架到底解决什么问题

写材料的人都有个共同体验：同一份通知，换个部门、换个事由，措辞、结构、口径全得重来。政务文书难的不是文采，是"合规 + 准确 + 得体"三件事同时成立。这两年 DeepSeek 在技术社区热度很高，很多人第一反应是拿它写散文、写代码，但真正被低估的场景，是公文写作里的多场景框架设计——也就是把"请示、报告、通知、函、纪要、批复"这些文种，拆成可复用的指令模板，让模型按固定骨架产出初稿，人只做审核和微调。

这篇讲的就是这件事：怎么用 DeepSeek 的指令能力，把政务文书撰写从"每次从零憋"变成"选场景、填要素、出初稿"。适合两类人：一是天天写材料的办公室、宣传、综合岗；二是想给单位搭一套内部写作辅助工具的技术同学。核心不是让 AI 替你签字，而是把重复劳动压到最低，把人的精力留给判断和把关。

2. 拆解公文文种：为什么不能用一个万能指令打天下

2.1 文种差异决定了指令骨架必须分开

很多人上手就写一句"帮我写一份公文"，结果模型给出来的东西四不像：既有请示的"妥否，请批示"，又混着报告的"特此报告"，结尾还带个通知的"请遵照执行"。这不是模型笨，是文种本身的法定结构不同。

政务文书里，每个文种都有相对固定的要素和语气：

看这张表就明白了：请示和报告最大的坑是"一文两用"——报告里夹请求，请示里塞汇报，都是公文大忌。所以指令设计的第一步，不是让模型"写得好看"，而是先锁定文种，再锁定要素。我一般会把文种作为指令的第一个强约束字段，而不是让模型自己猜。

2.2 把文种抽象成"角色 + 要素 + 约束"三段式

落到指令层面，一个可复用的公文指令模板，我习惯拆成三段：

• 角色段：告诉模型它是谁。比如"你是一名有十年经验的政府办公室文字工作者，熟悉《党政机关公文处理工作条例》的格式要求"。
• 要素段：把这份材料必须包含的事实填进去。发文单位、受文单位、事由、依据、具体事项、时限、联系人。
• 约束段：规定文种、字数、语气、禁止项。比如"文种为请示，只写一个请求事项，不得夹带汇报内容，结尾用'妥否，请批示'"。

这三段的好处是：要素段是"填空"，约束段是"护栏"。模型最容易翻车的地方就是护栏没设好，它会自作主张加内容、改语气、混文种。把约束写死，初稿的可用率会明显上升。

2.3 一个最小可跑的指令骨架

下面是我常用的一个请示类指令骨架，可以直接拿去改：

# 公文指令骨架：以"请示"为例 prompt = """ # 角色 你是一名政府办公室文字工作者，熟悉党政机关公文格式规范。 # 任务 根据以下要素，撰写一份"请示"。 # 要素 发文单位：{发文字号单位} 受文单位：{上级单位} 事由：{一句话说明请示什么事} 依据：{政策文件或实际情况} 请求事项：{具体请求批准的内容} 联系人及电话：{姓名} {电话} # 约束 1. 文种必须是"请示"，不得写成报告或通知。 2. 全文只围绕一个请求事项，不得夹带其他汇报内容。 3. 结构：标题 + 主送机关 + 正文（事由、依据、请求事项）+ 结尾"妥否，请批示" + 发文单位 + 日期。 4. 语言庄重简洁，正文控制在 400 字以内。 5. 不得编造未提供的政策文号、数据或人名。 """

逻辑说明：# 角色段锚定专业身份，让模型调用公文语料而不是通用语料；# 要素段用占位符{}把事实和模板分离，方便程序批量填充；# 约束段是防翻车的关键，尤其是第 5 条"不得编造"，能挡掉大部分幻觉文号。

参数说明：{发文字号单位}这类占位符在实际系统里对应表单字段，建议用字典或 JSON 传入，不要用字符串拼接，避免要素错位。字数上限按文种调整，请示一般 300–500 字，报告可以放宽到 1500 字。

3. 多场景框架落地：从单条指令到可复用模板库

3.1 用配置化方式管理不同文种模板

单条指令能救急，但要真正提效，得把文种做成模板库。我的做法是用一份 YAML 或 JSON 配置，把每个文种的骨架、约束、示例都存起来，程序按场景 key 调用。这样新增文种不用改代码，改配置就行。

import json # 文种模板库：每个文种一套骨架 templates = { "qingshi": { "name": "请示", "role": "政府办公室文字工作者，熟悉公文格式规范", "structure": ["标题", "主送机关", "事由", "依据", "请求事项", "结尾", "落款"], "ending": "妥否，请批示。", "max_words": 500, "forbidden": ["夹带汇报内容", "编造政策文号"] }, "tongzhi": { "name": "通知", "role": "政府办公室文字工作者，熟悉公文格式规范", "structure": ["标题", "主送机关", "依据", "事项", "要求", "时限", "落款"], "ending": "请遵照执行。", "max_words": 800, "forbidden": ["语气含糊", "缺少时限"] } } def build_prompt(scene_key, fields): t = templates[scene_key] prompt = f"# 角色\n你是一名{t['role']}。\n\n" prompt += f"# 任务\n撰写一份{t['name']}。\n\n# 要素\n" for k, v in fields.items(): prompt += f"{k}：{v}\n" prompt += f"\n# 约束\n1. 结构依次为：{'、'.join(t['structure'])}。\n" prompt += f"2. 结尾使用：{t['ending']}\n" prompt += f"3. 正文不超过 {t['max_words']} 字。\n" prompt += f"4. 禁止：{'；'.join(t['forbidden'])}。\n" return prompt # 调用示例 fields = { "发文单位": "某市某局", "受文单位": "某市人民政府", "事由": "申请增拨年度专项工作经费", "依据": "根据年度工作计划及实际支出情况", "请求事项": "请求增拨专项经费 XX 万元", "联系人": "张三 138xxxx" } print(build_prompt("qingshi", fields))

逻辑说明：templates字典把文种差异全部数据化，build_prompt负责把配置和事实拼成完整指令。这样做的价值在于——文种知识沉淀在配置里，而不是散落在每个人的提示词里。新人接手时，看配置就知道每个文种要写什么、禁什么。

参数说明：structure列表的顺序就是模型输出的段落顺序，建议严格按公文规范排；max_words是软约束，模型偶尔会超，可在后处理里截断或提示重写；forbidden列表越长，护栏越强，但也会让模型变保守，按实际需要增减。

3.2 要素抽取：让模型先问再写

直接让模型写，最大的问题是要素不全，它会自己脑补。更稳的做法是两段式：第一段让模型检查要素是否齐全，缺什么列出来；第二段再生成正文。这在多场景下特别有用，因为不同文种需要的要素不一样。

# 第一段：要素体检 check_prompt = """ 以下是用户提供的公文要素，请对照"{文种}"的要求，列出缺失的必填项。 只输出缺失项清单，不要写正文。 要素：{fields} """ # 第二段：确认齐全后再生成 # 若缺失项为空，则调用 build_prompt 生成正文

逻辑说明：把"检查"和"生成"拆开，能显著降低幻觉。模型在生成时如果发现要素缺失，往往会用"某单位""有关文件"这类占位词糊弄，而这些占位词在正式公文里是硬伤。先体检，缺什么补什么，再生成，初稿质量会稳很多。

参数说明：{文种}和{fields}同样用占位符传入。体检结果建议做成前端表单的高亮提示，让填表人当场补齐，而不是等生成完再返工。

3.3 输出格式约束：结构化比纯文本更好用

如果这套框架要接入内部系统，建议让模型输出结构化结果，而不是一整段文本。比如用 JSON 返回标题、正文、落款，前端再渲染成公文样式。这样后续做版本对比、字段校验都方便。

# 要求模型输出 JSON format_prompt = """ 请以 JSON 格式输出，字段如下： { "title": "公文标题", "receiver": "主送机关", "body": "正文内容", "ending": "结尾用语", "signer": "发文单位", "date": "成文日期" } 不要输出 JSON 以外的任何内容。 """

逻辑说明：结构化输出把"排版"和"内容"解耦，模型只管填字段，样式交给模板。这在多场景批量生成时优势明显——同一套渲染逻辑能适配所有文种。

参数说明：DeepSeek 支持 JSON 输出模式时优先开启，能减少解析失败；若模型偶尔多输出解释文字，可在后处理里用正则截取第一个{到最后一个}。

4. 避坑与排查：公文场景下最容易翻车的 5 个地方

4.1 现象：模型把请示写成报告，结尾还带"特此报告"

原因：指令里没锁死文种，或者要素段里混入了汇报性内容，模型顺着内容选了报告骨架。 解决：在约束段第一条就写死文种，并明确"不得夹带汇报内容"；要素段只放请求相关事实，汇报材料另起一份报告指令。

4.2 现象：生成的政策文号、数据、人名是编的

原因：模型在要素不全时会自动补全，这是语言模型的默认行为，不是它"不听话"。 解决：约束段加"不得编造未提供的政策文号、数据、人名"；同时用 3.2 的两段式先做要素体检，缺项不生成。生成后建议加一道正则校验，扫描"〔〕""号"等文号特征，人工复核。

4.3 现象：语气忽高忽低，一会儿"请"一会儿"必须"

原因：不同文种语气不同，但指令里没规定语气基调，模型按内容自由发挥。 解决：在模板配置里加tone字段，请示用"谦恭"，通知用"明确"，函用"平等客气"，并在约束段显式写出。语气是公文的"面子"，比内容更容易被挑毛病。

4.4 现象：正文超长，把简单通知写成两千字

原因：模型倾向于"充分表达"，没有字数硬约束时会扩写。 解决：max_words必须设，且在约束段写明"正文不超过 X 字"；生成后统计字数，超限则触发重写或截断。公文讲究简洁，超长本身就是质量问题。

4.5 现象：同一份材料多次生成，结构每次都不一样

原因：指令里结构描述太模糊，模型每次自由组织段落。 解决：把structure写成有序列表，约束段明确"结构依次为……"，让段落顺序固定。稳定性来自约束的确定性，不是来自模型的自觉。

5. 进阶技巧：用"要素回填 + 人工复核"把初稿变成定稿

框架跑通之后，真正决定效率的不是生成速度，而是从初稿到定稿的返工量。我踩过的坑是：一开始追求"一键成文"，结果生成十份有八份要大改，反而更累。后来改成"要素回填 + 人工复核"的流程，效率才真正起来。

具体做法是三步。第一步，把常用文种的高频要素做成表单，填表即回填，减少自由输入带来的歧义。第二步，生成后不直接给人看，先跑一遍自动校验：字数是否超限、结尾用语是否匹配文种、是否出现"某单位""有关文件"这类占位词、是否含未提供的文号。校验不通过就自动重写一次，通过再交人。第三步，人工只做三件事——核事实、调口径、定语气，不再从零组织语言。

# 生成后自动校验 def validate(text, template): issues = [] if len(text) > template["max_words"]: issues.append("字数超限") if template["ending"] not in text: issues.append("结尾用语缺失") for word in ["某单位", "有关文件", "相关部门"]: if word in text: issues.append(f"占位词：{word}") return issues # 有问题则带问题重写 if issues: retry_prompt = build_prompt(scene_key, fields) + f"\n上次生成存在以下问题，请修正：{'；'.join(issues)}"

逻辑说明：validate把可自动判断的质量项前置，避免人去看明显不合格的稿子；retry_prompt把问题回传给模型，让它针对性修正，比重新生成更省 token。这套机制在多场景批量处理时尤其值钱。

参数说明：占位词列表按单位习惯维护，不同系统里"某单位"可能换成"XX 部门"；重写次数建议限制在 1–2 次，超过就交人工，避免无限循环。

还有一个容易被忽略的点：去 AI 味。公文不需要华丽，但需要"像人写的"。模型初稿常见的毛病是连接词过多、排比过密、每段开头都是"为了……"。我的习惯是在约束段加一句"避免使用'为了''旨在''进一步'等空泛连接词，语言平实"，并在复核时手动删掉多余的过渡句。这一步不费事，但定稿的观感差别很大。

最后说个我自己的习惯：每写完一类文种，就把这次用到的指令、要素、校验规则存回模板库，下次直接调用。公文写作的提效不是靠某一次生成多惊艳，而是靠模板越攒越厚、返工越来越少。这套框架值不值得做，取决于你单位是不是有稳定的高频文种——如果有，投入几天搭起来，后面省下的是成百上千次重复劳动。希望帮到你。

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