简介这份资源面向政府机关、企事业单位文秘人员及各类笔杆子围绕公文写作提供二十套标准框架和对应的DeepSeek指令。内容按领导讲话、总结汇报、问题整改、调研报告、日常文书、方案计划、汇报发言、宣传报道、专项工作、法定文书等类别组织每套框架均细化到章节结构便于快速搭出规范初稿。资料为1个docx文档大小约16KB适合在写作时对照调用。目前已吸引149人学习使用。资源强调“基础框架最新政策本地案例90分材料”的用法并结合AI指令帮助生成高质量初稿减少反复修改时间。用户可根据实际场景灵活增删框架内容举一反三地适配不同文种是提升政务文书撰写效率与质量的实用工具。1. 从“会写”到“能用”DeepSeek指令在公文场景为什么必须成框架直接拿 DeepSeek 写公文的人多半体会过同一种落差让它“写一份关于开展安全检查的通知”它确实能写但产出是“像通知的作文”——文种混用、主送机关缺失、结尾用语不规范、事项表述含糊。问题不在模型能力而在指令没有按公文的规则建模。公文写作有固定的文种体系、版式规范和语体要求恰好是能写进指令的显式规则。这篇要讲的是一套可复现的 DeepSeek 指令设计方法把角色、任务、输出约束拆成分层结构把通知、请示、报告等高频场景映射成参数化模板再用低温度参数、few-shot 样例和两轮生成把输出压到“可直接排版”的程度。适合机关文秘、办公室文字岗也适合做政务文书系统的开发者。2. DeepSeek指令框架的三层结构角色、任务、输出约束分开写2.1 指令分层为什么不能把全部要求塞进一条提示词很多人的第一版指令长这样“你是公文专家帮我写一份关于 XX 的通知要求规范、正式、条理清晰。”这版指令不是没提要求而是所有要求挤在同一层模型分不清“你是谁”“要写什么”“输出长什么样”三类信息。要素一多模型会自己权衡优先级结果就是三次生成三个风格谁也不敢直接用。我一般把指令拆成三层正好对应 DeepSeek 接口的 messages 结构层级放置位置承担职责内容示例系统层system 消息定义角色、全局语言规范、格式标准你是资深公文写作专家精通公文格式规范任务层user 消息存放本次文种与写作要素文种通知事由部署季度安全检查输出层system 消息尾部约束返回结构与禁用内容只输出正文不输出解释性文字分层的实际收益在维护性。系统层写一次长期复用任务层每次只改要素多人共用一套系统层时生成结果的一致性明显好于各写各的提示词。输出层看似只是几句话但“不输出解释”这一条能省掉大量人工删改——默认情况下模型总爱在正文前后加“以下是为您生成的……”之类的话放在纯文本输出链路里就是每次都要手动清理的垃圾内容。2.2 角色设定与温度参数让模型进入公文状态系统层的角色不能只写“你是公文专家”。要写清楚你熟悉的规范范围和判断标准我通常这样写# 角色 你是资深公文写作专家熟悉公文处理相关规定精通 GB/T 9704-2012《党政机关公文格式》。 判断标准文种准确、结构完整、用语庄重、表述无歧义。 # 语言规范 - 使用规范书面语不使用口语、网络用语、营销化表达 - 动词优先使用书面词撰写、部署、落实、核查 - 不出现“我们觉得”“挺好的”等主观化表述注意这段全部是正向表述不是“不要什么”。模型对正向约束的跟随比否定约束稳定得多。与其写“不要用口语”不如给出书面语的替换示例让模型有具体的参考锚点而不是自己去猜什么叫口语。与之配套的是生成参数。调用 DeepSeek API 生成公文temperature 建议设在 0.1 到 0.3。通用对话的默认值偏创造力写公文时低温度能让输出更贴近训练分布里的“标准公文”代价是创造性下降这在公文场景不是缺点。max_tokens 按文种预估通知 800 到 1500报告可以放到 2000 以上防止生成到一半被截断落款日期都没出来。2.3 一份可以直接抄走的系统提示词模板把三层合成一份完整的 system 提示词我一般这样组织你是资深公文写作专家熟悉公文处理相关规定精通 GB/T 9704-2012《党政机关公文格式》。 本次任务依据用户提供的要素撰写一篇{文种}公文。 要求 1. 标题按“发文机关事由文种”拟定缺要素时用【待补充】标出。 2. 正文结构随文种调整通知按“目的依据、具体事项、执行要求”展开。 3. 主送机关顶格书写正文结束后附发文机关署名与成文日期。 4. 全文使用规范书面语禁用口语、网络词、营销化表达。 5. 用户素材中没有的信息用【待核实】标出不得编造。 6. 只输出公文正文不输出任何解释、说明或备注。第 5 条是政务场景的关键。模型有很强的“补全”倾向素材里没提的文件名、数据、人名它都可能一本正经地造出来必须在指令里显式禁止否则事实核查阶段会非常痛苦。第 6 条保证输出能直接复制进 Word。这里的{文种}就是下一章要讲的场景参数模板本身不需要为每种文种单独维护一套这就是“框架”和“提示词合集”的区别。3. 多场景映射把高频文种变成参数化DeepSeek指令模板3.1 通知、请示、报告三类高频公文的结构差异多场景框架的第一步不是给每个文种写一条提示词而是把文种间的结构差异表格化让模型按骨架写。以三个最高频的文种为例文种正文骨架结尾惯用语生成侧重点高频错误通知目的依据→具体事项→执行要求特此通知事项可执行、时限明确写成通告或通报请示缘由→请示事项→请求妥否请批示一文一事、理由充分夹带报告内容报告情况→分析→结论建议特此报告陈述客观、不夹带请示结尾误用“请批示”请示和报告是最容易被模型搞混的一对。区别不在格式而在功能请示需要上级批复报告不需要批复。这个判断必须显式写进指令模型自己推断不出来。我一般把差异固化在模板里“请示结尾用‘妥否请批示’报告结尾用‘特此报告’两者不得混用。”这句话放在系统层比每次在任务层里重复声明更可靠。3.2 场景参数化一份指令模板跑多个文种框架的核心是参数化。把文种、发文机关、主送机关、事由、内容要点、时限要求做成占位符模型每次只换要素不换规则。任务层消息长这样# 写作要素 文种{doc_type} 发文机关{org} 主送机关{recipient} 事由{subject} 内容要点{points} 时限要求{deadline} # 本轮特别约束 当文种为请示时必须遵循一文一事结尾用“妥否请批示”。 当文种为报告时结尾不得出现请示用语用“特此报告”。 当文种为通知时事项部分必须包含责任单位与完成时限。这份模板的好处是新增文种时不用新写提示词只需在“本轮特别约束”里补一条该文种的关键规则。框架里支持的场景数量取决于你定义了骨架的表格行数而不是提示词条数。我见过把十五种公文文种各写一条长提示词的方案维护到第三周就想放弃了——改一个用语规范要同步改十五条。3.3 DeepSeek API调用最小可运行的生成代码DeepSeek 对外接口兼容 OpenAI 的消息格式最小可运行代码如下import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com, ) # 系统提示词见 2.3 节模板整段粘贴 system_prompt 你是资深公文写作专家熟悉公文处理相关规定…… 此处粘贴 2.3 节的完整系统提示词模板 def build_task(doc_type: str, elements: dict) - str: return f# 写作要素 文种{doc_type} 发文机关{elements[org]} 主送机关{elements[recipient]} 事由{elements[subject]} 内容要点{elements[points]} 时限要求{elements.get(deadline, 未明确)} def generate_doc(doc_type: str, elements: dict) - str: resp client.chat.completions.create( modeldeepseek-chat, # 通用对话模型以官方文档当前值为准 messages[ {role: system, content: system_prompt}, {role: user, content: build_task(doc_type, elements)}, ], temperature0.2, # 压低温度避免口语化发散 max_tokens2048, ) return resp.choices[0].message.content这段代码把指令框架里的要素硬编码成了 Python 字典实际系统里可以从表单或数据库读取。base_url 指向 DeepSeek 官方 APIapi_key 从环境变量读取避免写死在代码里。temperature 与 max_tokens 的取值逻辑在 2.2 节讲过这里沿用。注意DeepSeek API 的模型名与接口地址以官方文档为准示例中的 deepseek-chat 是当前通用对话模型的默认值接入前先确认。如果单位有数据管控要求可以考虑本地部署模型指令框架本身与部署方式解耦——系统层和任务层完全不用改只换 base_url 和内网模型服务地址。非技术同事也有条路DeepSeek 官方对话界面支持自定义指令把系统提示词粘进去任务层要素每次手填效果与调 API 一致这套框架的价值正在于此指令与载体无关。4. 让DeepSeek输出合规公文版式约束、术语正负清单与三遍校验4.1 版式规则写进指令标题、主送机关、落款一次成型公文的版式有明确标准GB/T 9704 规定了标题、主送机关、正文、落款的排列方式。模型输出的是纯文本管不到 Word 里的字体字号但内容结构是可以约束的。我把以下几条写进系统层# 结构约束 - 标题发文机关事由文种单独成行 - 主送机关顶格书写末尾加全角冒号 - 正文一级事项用“一、二、三”二级用“一二” - 落款发文机关署名与成文日期分行日期用阿拉伯数字 - 附件正文后另起一行标注附件名称与份数这几个规则能让生成结果结构化后续无论接 Word 模板还是 HTML 渲染都不需要人手动去拆段落。另一个常见做法是要求模型用 Markdown 标题层级返回方便程序解析正文段落但注意最终落 Word 时要把 Markdown 符号去掉看你的产出链路选一种别混着用。4.2 术语正负清单一份可执行的公文词汇表语体是靠词汇撑起来的。模型对“书面语”的理解比较泛给它一份正负清单比反复强调“要正式”有效得多# 禁用表达出现即替换 口语词搞定、弄、挺、蛮、差不多 网络化套话赋能、抓手、复盘非必要不使用 主观表述我们认为、我觉得、挺好的 无指代模糊词有关方面、相关部门须写明具体对象 # 推荐表达 安排部署、持续推进、严格落实、核查核实、明确要求、限期整改否定清单不能单用。模型对纯禁止列表的遵守不稳定必须配正向替换词否则它会绕开一个违禁词再换上另一个同样不得体的词。更稳的做法是顺手给一句范文片段放进系统层让模型照着语体模仿——这正是下一章 few-shot 的思路。提示正负清单里每个词都要给出可执行的替代项只写“禁止口语”不写“换什么”等于没写。4.3 生成后的三遍校验结构、事实、格式指令写得再好输出也要过校验。我一般做三遍第一遍查结构看文种骨架是否完整用脚本对关键词做初筛RULES { 通知: {required: [特此通知, 请遵照执行], forbidden: []}, 请示: {required: [妥否请批示], forbidden: [特此报告]}, 报告: {required: [特此报告], forbidden: [请批示]}, } def check_structure(text: str, doc_type: str) - list[str]: rule RULES[doc_type] problems [] for kw in rule[required]: # 必备结尾语缺失即报错 if kw not in text: problems.append(f缺少结尾惯用语{kw}) for kw in rule[forbidden]: # 出现跨文种用语即报错 if kw in text: problems.append(f出现禁用用语{kw}) return problemsRULES 字典把每个文种的必备词和违禁词列在一起check_structure 遍历比对后返回问题列表。这是轻量初筛不是质量保证。第二遍查事实人名、地名、数据、文件名必须和素材一一对应这一步只能人来做模型在指令约束下会用【待核实】标出未知项但凡是它自行脑补的内容必须在这一遍揪出来。第三遍查格式标题、主送机关、落款的位置和标点直接套单位的 Word 模板样式检查速度最快。5. 进阶用 Few-shot 与两轮生成把公文质量再提一档5.1 Few-shot样例一条好的示例胜过十条规则当指令约束接近上限时质量不再来自更多规则而来自样例。few-shot 的原理是让模型模仿样例的语体和结构比抽象规则更直接。我通常在 messages 里插入一组问答对messages.append({role: user, content: 文种通知事由开展年度档案自查……}) messages.append({role: assistant, content: SAMPLE_OUTPUT})样例要选结构完整、用语规范的成稿最好是从你们单位已发出的公文中脱敏改写。样例最多放两个多了会稀释当前任务要素的权重还拉长上下文、抬高成本。错误示例慎用模型可能连错误一起学不如在规则里用文字指出错误类型。5.2 两轮生成法先定骨架再填正文长文种比如报告一次生成的常见问题是“写着写着跑偏”——前半段还按素材走后半段开始泛化。我一般拆两轮第一轮指令请基于素材列出写作骨架包含一级、二级标题与每部分要点不展开正文。 第二轮指令请严格按上述骨架展开为完整公文小标题保持不变正文保持书面语规范。第一轮的骨架输出会留在对话上下文里第二轮相当于让模型对着自己画的提纲扩写。骨架固定了内容漂移基本被掐断也方便人先审骨架再放行正文——骨架不对正文再漂亮也是返工。5.3 三组对照实验验证框架是否真的有效框架有没有用用对照实验说话。选一个真实的写作任务分别用三组指令跑对照组指令内容预期结果A一句话“写一份关于开展安全培训的通知”结构松散文种特征弱B只加角色设定与语言规范语体改善但骨架不稳定C完整框架三层指令场景参数结构约束few-shot骨架稳定可直接排版对照时重点看三个指标文种骨架是否完整、请示报告是否混用、是否出现编造信息。C 组如果还有问题先查温度是否偏高、样例是否与当前任务差异过大再看系统层里有没有与任务层矛盾的条目——矛盾指令是输出不稳的常见源头。把这套对照固化下来每次调整系统层后拿同一道题回归一次指令框架的每一次改动就都有数据支撑了。本文还有配套的精品资源点击获取 DeepSeek指令框架：让公文写作从“能写”到“能用”的Prompt设计方法
简介这份资源面向政府机关、企事业单位文秘人员及各类笔杆子围绕公文写作提供二十套标准框架和对应的DeepSeek指令。内容按领导讲话、总结汇报、问题整改、调研报告、日常文书、方案计划、汇报发言、宣传报道、专项工作、法定文书等类别组织每套框架均细化到章节结构便于快速搭出规范初稿。资料为1个docx文档大小约16KB适合在写作时对照调用。目前已吸引149人学习使用。资源强调“基础框架最新政策本地案例90分材料”的用法并结合AI指令帮助生成高质量初稿减少反复修改时间。用户可根据实际场景灵活增删框架内容举一反三地适配不同文种是提升政务文书撰写效率与质量的实用工具。1. 从“会写”到“能用”DeepSeek指令在公文场景为什么必须成框架直接拿 DeepSeek 写公文的人多半体会过同一种落差让它“写一份关于开展安全检查的通知”它确实能写但产出是“像通知的作文”——文种混用、主送机关缺失、结尾用语不规范、事项表述含糊。问题不在模型能力而在指令没有按公文的规则建模。公文写作有固定的文种体系、版式规范和语体要求恰好是能写进指令的显式规则。这篇要讲的是一套可复现的 DeepSeek 指令设计方法把角色、任务、输出约束拆成分层结构把通知、请示、报告等高频场景映射成参数化模板再用低温度参数、few-shot 样例和两轮生成把输出压到“可直接排版”的程度。适合机关文秘、办公室文字岗也适合做政务文书系统的开发者。2. DeepSeek指令框架的三层结构角色、任务、输出约束分开写2.1 指令分层为什么不能把全部要求塞进一条提示词很多人的第一版指令长这样“你是公文专家帮我写一份关于 XX 的通知要求规范、正式、条理清晰。”这版指令不是没提要求而是所有要求挤在同一层模型分不清“你是谁”“要写什么”“输出长什么样”三类信息。要素一多模型会自己权衡优先级结果就是三次生成三个风格谁也不敢直接用。我一般把指令拆成三层正好对应 DeepSeek 接口的 messages 结构层级放置位置承担职责内容示例系统层system 消息定义角色、全局语言规范、格式标准你是资深公文写作专家精通公文格式规范任务层user 消息存放本次文种与写作要素文种通知事由部署季度安全检查输出层system 消息尾部约束返回结构与禁用内容只输出正文不输出解释性文字分层的实际收益在维护性。系统层写一次长期复用任务层每次只改要素多人共用一套系统层时生成结果的一致性明显好于各写各的提示词。输出层看似只是几句话但“不输出解释”这一条能省掉大量人工删改——默认情况下模型总爱在正文前后加“以下是为您生成的……”之类的话放在纯文本输出链路里就是每次都要手动清理的垃圾内容。2.2 角色设定与温度参数让模型进入公文状态系统层的角色不能只写“你是公文专家”。要写清楚你熟悉的规范范围和判断标准我通常这样写# 角色 你是资深公文写作专家熟悉公文处理相关规定精通 GB/T 9704-2012《党政机关公文格式》。 判断标准文种准确、结构完整、用语庄重、表述无歧义。 # 语言规范 - 使用规范书面语不使用口语、网络用语、营销化表达 - 动词优先使用书面词撰写、部署、落实、核查 - 不出现“我们觉得”“挺好的”等主观化表述注意这段全部是正向表述不是“不要什么”。模型对正向约束的跟随比否定约束稳定得多。与其写“不要用口语”不如给出书面语的替换示例让模型有具体的参考锚点而不是自己去猜什么叫口语。与之配套的是生成参数。调用 DeepSeek API 生成公文temperature 建议设在 0.1 到 0.3。通用对话的默认值偏创造力写公文时低温度能让输出更贴近训练分布里的“标准公文”代价是创造性下降这在公文场景不是缺点。max_tokens 按文种预估通知 800 到 1500报告可以放到 2000 以上防止生成到一半被截断落款日期都没出来。2.3 一份可以直接抄走的系统提示词模板把三层合成一份完整的 system 提示词我一般这样组织你是资深公文写作专家熟悉公文处理相关规定精通 GB/T 9704-2012《党政机关公文格式》。 本次任务依据用户提供的要素撰写一篇{文种}公文。 要求 1. 标题按“发文机关事由文种”拟定缺要素时用【待补充】标出。 2. 正文结构随文种调整通知按“目的依据、具体事项、执行要求”展开。 3. 主送机关顶格书写正文结束后附发文机关署名与成文日期。 4. 全文使用规范书面语禁用口语、网络词、营销化表达。 5. 用户素材中没有的信息用【待核实】标出不得编造。 6. 只输出公文正文不输出任何解释、说明或备注。第 5 条是政务场景的关键。模型有很强的“补全”倾向素材里没提的文件名、数据、人名它都可能一本正经地造出来必须在指令里显式禁止否则事实核查阶段会非常痛苦。第 6 条保证输出能直接复制进 Word。这里的{文种}就是下一章要讲的场景参数模板本身不需要为每种文种单独维护一套这就是“框架”和“提示词合集”的区别。3. 多场景映射把高频文种变成参数化DeepSeek指令模板3.1 通知、请示、报告三类高频公文的结构差异多场景框架的第一步不是给每个文种写一条提示词而是把文种间的结构差异表格化让模型按骨架写。以三个最高频的文种为例文种正文骨架结尾惯用语生成侧重点高频错误通知目的依据→具体事项→执行要求特此通知事项可执行、时限明确写成通告或通报请示缘由→请示事项→请求妥否请批示一文一事、理由充分夹带报告内容报告情况→分析→结论建议特此报告陈述客观、不夹带请示结尾误用“请批示”请示和报告是最容易被模型搞混的一对。区别不在格式而在功能请示需要上级批复报告不需要批复。这个判断必须显式写进指令模型自己推断不出来。我一般把差异固化在模板里“请示结尾用‘妥否请批示’报告结尾用‘特此报告’两者不得混用。”这句话放在系统层比每次在任务层里重复声明更可靠。3.2 场景参数化一份指令模板跑多个文种框架的核心是参数化。把文种、发文机关、主送机关、事由、内容要点、时限要求做成占位符模型每次只换要素不换规则。任务层消息长这样# 写作要素 文种{doc_type} 发文机关{org} 主送机关{recipient} 事由{subject} 内容要点{points} 时限要求{deadline} # 本轮特别约束 当文种为请示时必须遵循一文一事结尾用“妥否请批示”。 当文种为报告时结尾不得出现请示用语用“特此报告”。 当文种为通知时事项部分必须包含责任单位与完成时限。这份模板的好处是新增文种时不用新写提示词只需在“本轮特别约束”里补一条该文种的关键规则。框架里支持的场景数量取决于你定义了骨架的表格行数而不是提示词条数。我见过把十五种公文文种各写一条长提示词的方案维护到第三周就想放弃了——改一个用语规范要同步改十五条。3.3 DeepSeek API调用最小可运行的生成代码DeepSeek 对外接口兼容 OpenAI 的消息格式最小可运行代码如下import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com, ) # 系统提示词见 2.3 节模板整段粘贴 system_prompt 你是资深公文写作专家熟悉公文处理相关规定…… 此处粘贴 2.3 节的完整系统提示词模板 def build_task(doc_type: str, elements: dict) - str: return f# 写作要素 文种{doc_type} 发文机关{elements[org]} 主送机关{elements[recipient]} 事由{elements[subject]} 内容要点{elements[points]} 时限要求{elements.get(deadline, 未明确)} def generate_doc(doc_type: str, elements: dict) - str: resp client.chat.completions.create( modeldeepseek-chat, # 通用对话模型以官方文档当前值为准 messages[ {role: system, content: system_prompt}, {role: user, content: build_task(doc_type, elements)}, ], temperature0.2, # 压低温度避免口语化发散 max_tokens2048, ) return resp.choices[0].message.content这段代码把指令框架里的要素硬编码成了 Python 字典实际系统里可以从表单或数据库读取。base_url 指向 DeepSeek 官方 APIapi_key 从环境变量读取避免写死在代码里。temperature 与 max_tokens 的取值逻辑在 2.2 节讲过这里沿用。注意DeepSeek API 的模型名与接口地址以官方文档为准示例中的 deepseek-chat 是当前通用对话模型的默认值接入前先确认。如果单位有数据管控要求可以考虑本地部署模型指令框架本身与部署方式解耦——系统层和任务层完全不用改只换 base_url 和内网模型服务地址。非技术同事也有条路DeepSeek 官方对话界面支持自定义指令把系统提示词粘进去任务层要素每次手填效果与调 API 一致这套框架的价值正在于此指令与载体无关。4. 让DeepSeek输出合规公文版式约束、术语正负清单与三遍校验4.1 版式规则写进指令标题、主送机关、落款一次成型公文的版式有明确标准GB/T 9704 规定了标题、主送机关、正文、落款的排列方式。模型输出的是纯文本管不到 Word 里的字体字号但内容结构是可以约束的。我把以下几条写进系统层# 结构约束 - 标题发文机关事由文种单独成行 - 主送机关顶格书写末尾加全角冒号 - 正文一级事项用“一、二、三”二级用“一二” - 落款发文机关署名与成文日期分行日期用阿拉伯数字 - 附件正文后另起一行标注附件名称与份数这几个规则能让生成结果结构化后续无论接 Word 模板还是 HTML 渲染都不需要人手动去拆段落。另一个常见做法是要求模型用 Markdown 标题层级返回方便程序解析正文段落但注意最终落 Word 时要把 Markdown 符号去掉看你的产出链路选一种别混着用。4.2 术语正负清单一份可执行的公文词汇表语体是靠词汇撑起来的。模型对“书面语”的理解比较泛给它一份正负清单比反复强调“要正式”有效得多# 禁用表达出现即替换 口语词搞定、弄、挺、蛮、差不多 网络化套话赋能、抓手、复盘非必要不使用 主观表述我们认为、我觉得、挺好的 无指代模糊词有关方面、相关部门须写明具体对象 # 推荐表达 安排部署、持续推进、严格落实、核查核实、明确要求、限期整改否定清单不能单用。模型对纯禁止列表的遵守不稳定必须配正向替换词否则它会绕开一个违禁词再换上另一个同样不得体的词。更稳的做法是顺手给一句范文片段放进系统层让模型照着语体模仿——这正是下一章 few-shot 的思路。提示正负清单里每个词都要给出可执行的替代项只写“禁止口语”不写“换什么”等于没写。4.3 生成后的三遍校验结构、事实、格式指令写得再好输出也要过校验。我一般做三遍第一遍查结构看文种骨架是否完整用脚本对关键词做初筛RULES { 通知: {required: [特此通知, 请遵照执行], forbidden: []}, 请示: {required: [妥否请批示], forbidden: [特此报告]}, 报告: {required: [特此报告], forbidden: [请批示]}, } def check_structure(text: str, doc_type: str) - list[str]: rule RULES[doc_type] problems [] for kw in rule[required]: # 必备结尾语缺失即报错 if kw not in text: problems.append(f缺少结尾惯用语{kw}) for kw in rule[forbidden]: # 出现跨文种用语即报错 if kw in text: problems.append(f出现禁用用语{kw}) return problemsRULES 字典把每个文种的必备词和违禁词列在一起check_structure 遍历比对后返回问题列表。这是轻量初筛不是质量保证。第二遍查事实人名、地名、数据、文件名必须和素材一一对应这一步只能人来做模型在指令约束下会用【待核实】标出未知项但凡是它自行脑补的内容必须在这一遍揪出来。第三遍查格式标题、主送机关、落款的位置和标点直接套单位的 Word 模板样式检查速度最快。5. 进阶用 Few-shot 与两轮生成把公文质量再提一档5.1 Few-shot样例一条好的示例胜过十条规则当指令约束接近上限时质量不再来自更多规则而来自样例。few-shot 的原理是让模型模仿样例的语体和结构比抽象规则更直接。我通常在 messages 里插入一组问答对messages.append({role: user, content: 文种通知事由开展年度档案自查……}) messages.append({role: assistant, content: SAMPLE_OUTPUT})样例要选结构完整、用语规范的成稿最好是从你们单位已发出的公文中脱敏改写。样例最多放两个多了会稀释当前任务要素的权重还拉长上下文、抬高成本。错误示例慎用模型可能连错误一起学不如在规则里用文字指出错误类型。5.2 两轮生成法先定骨架再填正文长文种比如报告一次生成的常见问题是“写着写着跑偏”——前半段还按素材走后半段开始泛化。我一般拆两轮第一轮指令请基于素材列出写作骨架包含一级、二级标题与每部分要点不展开正文。 第二轮指令请严格按上述骨架展开为完整公文小标题保持不变正文保持书面语规范。第一轮的骨架输出会留在对话上下文里第二轮相当于让模型对着自己画的提纲扩写。骨架固定了内容漂移基本被掐断也方便人先审骨架再放行正文——骨架不对正文再漂亮也是返工。5.3 三组对照实验验证框架是否真的有效框架有没有用用对照实验说话。选一个真实的写作任务分别用三组指令跑对照组指令内容预期结果A一句话“写一份关于开展安全培训的通知”结构松散文种特征弱B只加角色设定与语言规范语体改善但骨架不稳定C完整框架三层指令场景参数结构约束few-shot骨架稳定可直接排版对照时重点看三个指标文种骨架是否完整、请示报告是否混用、是否出现编造信息。C 组如果还有问题先查温度是否偏高、样例是否与当前任务差异过大再看系统层里有没有与任务层矛盾的条目——矛盾指令是输出不稳的常见源头。把这套对照固化下来每次调整系统层后拿同一道题回归一次指令框架的每一次改动就都有数据支撑了。本文还有配套的精品资源点击获取