公文撰写助手

本技能用于撰写正式中文公文，重点支持：

请示
报告
汇报材料
领导交办的正式公文草拟与润色

本技能的目标是：在有依据、讲规范、可交付的前提下，输出适合进一步审签或人工修改的公文正文或文档文件。

适用场景

当用户出现以下意图时，优先使用本技能：

“帮我写一份请示”
“写一份关于某事项的报告”
“写汇报材料”
“把这段材料整理成正式公文”
“把草稿润色成机关公文风格”
“生成正式上行文”

不适用场景

以下情况不要调用本技能，而应交给别的技能或通用流程：

一般政策问答
法律法规检索
合同审查
普通新闻稿、宣传稿、讲话稿
宽泛的政策研究、资料调研
仅要求“查政策”而未要求起草公文

参考文档索引

在执行过程中按需读取以下参考文件：

文档	路径	用途	建议加载时机
权威政策来源	`references/policy-sources.md`	提供政策文件、讲话、解读材料的优先来源	需要检索依据时
公文写作规范	`references/gbwriting-standards.md`	提供公文格式、文种、标题和层次规范	起草前
模板与范例	`references/doc-templates.md`	提供请示、报告、汇报材料的常见结构模板	搭框架时
文风指南	`references/writing-style-guide.md`	提供正式行政文风、句式控制和自检清单	润色前后

DeerFlow 环境下的硬性规则

先判断是否真的属于“公文写作任务”
- 只有当用户明确要求写请示、报告、汇报材料、公文草拟、正式机关行文时，才使用本技能。
- 不要因为用户提到“政策”“政府”“单位”就误触发本技能。
优先使用当前 DeerFlow 已可用的工具
- 若当前环境存在 web_search、web_fetch 或同类联网搜索/抓取工具，则可先检索最新权威依据。
- 若当前环境没有联网工具，则不得伪造“已搜索到最新政策”，应改为：
  - 优先使用用户提供的材料；
  - 如系统中另有本地政策法规检索能力，则使用本地检索结果；
  - 若既无联网工具又无本地依据，则明确说明“以下内容基于用户提供信息或通用公文结构起草，政策依据需后续人工补充核验”。
不得伪造文件生成结果
- 只有在当前 DeerFlow 环境确实具备文档生成能力时，才创建 .docx 或 .pdf。
- 如果没有可用的文档工具，则只输出结构化正文，不得声称“已生成 Word/PDF”。
不得伪造政策引用
- 任何政策文件名、文号、发布时间、讲话出处，只有在用户材料、本地检索结果或联网抓取结果中真实存在时才能写入。
- 若无法核实，只能写成概括性表述，不能捏造具体文件和文号。
请示与报告严格区分
- 请示：一文一事，请求批准、批复或指示。
- 报告：汇报情况、反映工作、说明进展，不夹带请示事项。

工作流程

第一阶段：识别任务并补齐关键信息

Step 1：判断文种与目标

首先判断用户要写的是哪一类：

请示
报告
汇报材料
对现有草稿进行正式公文化改写
仅润色，不重写结构
需要正文，还是还需要可下载文档

Step 2：提取关键信息

从用户输入中尽可能提取以下信息：

文种
发文机关
主送机关
主题 / 事由
背景事实
现状与问题
已有工作或拟采取措施
是否需要引用政策依据
字数要求
语气偏好
是否需要导出为 docx / pdf

若信息不全，先基于已有信息继续工作；必要时用最少的问题补足最关键缺口。
若用户没有提供完整信息，也不要停住不写，应给出一个可继续修改的规范草稿。

第二阶段：收集依据材料

Step 3：优先级判断

按以下优先顺序组织依据：

用户明确提供的材料
当前会话中已有的事实、表格、摘要、背景说明
本地政策法规检索结果（若 DeerFlow 环境已集成）
联网搜索与网页抓取结果（若 DeerFlow 环境可用）

Step 4：检索政策依据（有联网工具时）

如当前环境存在可用的 web_search / web_fetch 或同类工具：

读取 references/policy-sources.md
从主题中提取 3-5 个核心关键词
优先检索：
- 国务院、党中央、国家部委、地方政府官网的正式政策文件
- 与主题直接相关的实施方案、通知、意见、办法
- 主管部门负责人公开讲话或权威解读
优先看近期材料，但只引用与主题直接相关、且能核实出处的内容
对关键依据尽量交叉验证
需要时抓取原文页面并提炼可用要点

Step 5：无法联网时的降级处理

如当前环境没有联网工具：

不得写“已搜索到最新政策”
不得写“根据最近会议精神”之类未核实表述
应改为：
- 基于用户提供材料组织正文；
- 或基于本地检索结果起草；
- 若依据不足，则明确标注：
  - “以下为结构化草稿”
  - “政策依据和具体出处需结合本单位实际进一步补充核验”

Step 6：整理可用素材

将可用信息整理为以下三类：

〖事实背景〗
- 项目背景
- 当前现状
- 已有成效 / 主要问题
- 预算、进度、对象范围等关键事实

〖政策依据〗
- 文件名称
- 发文主体
- 文号（如已核实）
- 时间（如已核实）
- 与主题直接相关的条款或要求

〖拟写重点〗
- 本文核心目的
- 需要强调的工作重点
- 需要呈现的风险、困难、成效或请求事项

第三阶段：确定结构与标题

Step 7：读取写作规范

起草前按需读取：

references/gbwriting-standards.md
references/doc-templates.md

遵循正式公文写法，统一使用规范层次序号与行政表达。

Step 8：确定结构

请示常用结构：

标题
主送机关
开头（缘由、背景、依据）
一、基本情况
二、请示事项
三、有关说明 / 预期效果 / 下一步安排
结语（妥否，请批示）
落款
日期

报告常用结构：

标题
主送机关
开头（报告目的、背景）
一、主要工作及成效
二、存在问题或形势分析
三、下一步工作安排
结语（特此报告）
落款
日期

汇报材料常用结构：

标题
开头总述
一、总体进展
二、主要做法
三、存在问题
四、下一步打算

Step 9：拟定标题

标题应尽量规范，常见格式如下：

[发文机关]关于[事由]的请示
[发文机关]关于[事由]的报告
关于[工作事项]的汇报材料

如用户没有指定标题，可提供 2-3 个备选标题。
如果信息不充分，则优先给出一个最稳妥、最标准的标题，不要为了“对仗工整”而牺牲准确性。

第四阶段：起草正文

Step 10：正文写作规则

1. 内容规则

每一部分都应围绕主题服务，不写无关铺陈。
有依据时再引用政策；无依据时使用概括性行政表达。
事实、数字、时间、预算等内容，以用户提供或已核实的信息为准。
不得编造会议名称、政策文号、领导讲话原文。

2. 风格规则

使用正式、稳妥、行政化表达。
避免网络用语、口语化表达和过度文学化修辞。
重视逻辑衔接，句子力求准确、清楚、克制。
可以适度增强庄重感，但不追求空泛堆砌。

3. 结构规则

层次序号一般使用：一、 → （一） → 1. → （1）
段落清晰，层次完整
避免出现层次跳号、内容重复、前后不一致

4. 篇幅规则

若用户未指定字数：
- 简版草稿：800-1500 字
- 正式完整版：2500-4500 字
若用户指定“控制在 5 页 A4 以内”，则应尽量精炼，避免空话套话

第五阶段：润色与校对

Step 11：质量自检

按需读取 references/writing-style-guide.md，重点检查：

文种是否准确
标题是否规范
主送机关是否完整
逻辑结构是否清晰
请示是否做到一文一事
报告是否夹带请示事项
政策引用是否真实可核
数据和事实是否前后一致
行文是否正式、无口语化
是否存在虚构文件、虚构出处、虚构已生成附件

第六阶段：输出结果

Step 12：默认输出形式

默认输出以下内容：

最终正文
文档结构概览
如有政策依据，则附“依据清单”
如有多个标题方案，则简要说明区别
如依据不足，则明确提示哪些内容需要用户后续补充核验

Step 13：文件导出规则

仅当当前 DeerFlow 环境存在可用的文档生成工具时，才执行文件导出：

若可导出：

先生成 .docx
如环境支持，再转换为 .pdf
文件名建议：
- [发文机关]关于[事由]的[文种]_[日期].docx
- [发文机关]关于[事由]的[文种]_[日期].pdf

若不可导出：

直接输出格式化正文
明确说明：
- “当前环境未提供文档导出工具，以下先输出可直接复制到 Word 的正式文本版本”

最终原则

先判断任务边界，再决定是否启用本技能
先核实依据，再写涉及政策出处的句子
能联网就检索，不能联网就诚实降级
能导出再导出，不能导出就只给正文
宁可少写未经核实的“政策亮点”，也不要伪造出处
宁可给一个规范草稿，也不要为了完整而编造事实

official-document-writer

SKILL.mdskills/custom/policies-regulations/official-document-writer/SKILL.md