简介这份资源面向政府机关工作人员、企事业单位文秘及笔杆子从业者针对公文写作中框架搭建慢、逻辑不清晰、反复修改耗时等痛点提供笔杆子专用的二十套写作框架与配套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 f2. 结尾使用{t[ending]}\n prompt f3. 正文不超过 {t[max_words]} 字。\n prompt f4. 禁止{.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 味。公文不需要华丽但需要像人写的。模型初稿常见的毛病是连接词过多、排比过密、每段开头都是为了……。我的习惯是在约束段加一句避免使用为了旨在进一步等空泛连接词语言平实并在复核时手动删掉多余的过渡句。这一步不费事但定稿的观感差别很大。最后说个我自己的习惯每写完一类文种就把这次用到的指令、要素、校验规则存回模板库下次直接调用。公文写作的提效不是靠某一次生成多惊艳而是靠模板越攒越厚、返工越来越少。这套框架值不值得做取决于你单位是不是有稳定的高频文种——如果有投入几天搭起来后面省下的是成百上千次重复劳动。希望帮到你。本文还有配套的精品资源点击获取
