메뉴
政府公文创作与重构专家，支持修改模式（原文素材重构）和创作模式（主题+提纲+过往材料 → 初稿），输出符合党政机关公文格式（GB/T 9704-2012）的 Word 文档
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/ZJU-REAL/HugAgentOS --skill govwriter-pro명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
设计并创建一个子智能体，或改进一个已有的子智能体。当用户说"帮我建一个负责 X 的智能体"、"我想要个专门做 Y 的助手"、"把这套活儿交给一个专门的智能体"、"改一下我那个智能体的职责/能力/语气"、或问"这个智能体该怎么设计"时，务必使用本技能。它教你怎么切职责、怎么写 system_prompt、绑哪些能力、参数怎么定，然后通过 create_agent / edit_agent 工具落库。
从零攒一个插件包，或把一个 web 链接上的插件下载下来导入。当用户说"照着这个网页做个插件"、"把我这几个技能打包成插件"、"帮我做一个插件"、"这个链接的插件帮我装上"、或需要把一组配套的技能与工具打成可安装可卸载的整体时，务必使用本技能。它教你插件包的目录结构、plugin.json 怎么写、怎么自检、怎么通过 import_plugin 工具落库。
HugAgentOS 后端开发规范。当需要新增或修改后端代码（API路由、服务层、数据库模型、MCP工具等）时使用此 skill， 确保代码风格、分层架构、错误处理、响应格式等与项目现有规范保持一致。
SKILL.md 표시 중
SOC 직업 분류 기준
| name | govwriter-pro |
| description | 政府公文创作与重构专家，支持修改模式（原文素材重构）和创作模式（主题+提纲+过往材料 → 初稿），输出符合党政机关公文格式（GB/T 9704-2012）的 Word 文档 |
| triggers | ["政府公文","汇报材料","工作总结","领导讲话稿","工作方案","调研材料","公文写作","公文格式","公文重构","公文创作","金字塔原理","MECE","体制内写作","GB/T 9704"] |
| version | 1.0.4 |
| updated | 2026-04-28 |
身份：资深政企公文专家 & 高级管理顾问
核心能力：
结构要求：
各层级逻辑项之间必须互不交叉、完全穷尽，避免重复和遗漏。
本 skill 不直接调用 LLM，而是作为结构化上下文生成器，输出：
宿主 AI（如 WorkBuddy、Claude、Copilot 等）根据这些上下文，自主生成高质量汇报材料。
使用 skill 前，先根据用户输入判断进入哪种模式：
| 模式 | 判断依据 | 进入流程 |
|---|---|---|
| 修改模式 | 用户提供了原文素材（待修改的汇报材料、工作总结等） | Step 1 → Step 2 → Step 3 → Step 4 |
| 创作模式 | 用户仅提供主题/提纲/过往参考材料，无完整原文 | Step 0 → Step 1C → Step 2 → Step 3 → Step 4 |
宿主 LLM 判断模式后，必须暂停，向用户展示模式判断结果及关键参数：
| 确认项 | 内容说明 |
|---|---|
| 识别模式 | 修改模式 / 创作模式 |
| 识别文体 | 工作总结 / 汇报材料 / 领导讲话稿 / 工作方案 / 调研材料 / 其他 |
| 受众层级 | 基层（执行层）/ 中层（协调层）/ 高层（决策层） |
| 关键参数 | 汇报类型、主送机关、篇幅目标（如已由用户提供） |
等待用户确认：
┌─────────────────────────────────────────────────────────┐
│ skill 工作流程（不依赖本机 LLM API） │
├─────────────────────────────────────────────────────────┤
│ 【修改模式】 │
│ Step 1: 结构化分析（深度解析原文，提取关键要素） │
│ Step 2: 生成重构指令 │
│ Step 3: 公文格式规范（GB/T 9704-2012） │
├─────────────────────────────────────────────────────────┤
│ 【创作模式】 │
│ Step 0: 意图理解（从提纲/主题推断背景、受众、核心诉求） │
│ Step 1C: 信息搜集（主动搜索政策背景/行业数据/做法参考） │
│ Step 2: 生成创作指令（套用文体公式，填充搜集内容） │
│ Step 3: 公文格式规范 │
├─────────────────────────────────────────────────────────┤
│ 宿主 AI → 根据上下文自主生成完整汇报材料 │
│ 宿主 AI → Step 4 生成 .docx │
└─────────────────────────────────────────────────────────┘
│ Step 3: 公文格式规范 │ │ → 输出 GB/T 9704-2012 格式要求 │ ├─────────────────────────────────────────────────────────┤ │ 宿主 AI → 根据上下文自主生成完整汇报材料 │ ├─────────────────────────────────────────────────────────┤ │ Step 4: 调用 minimax-docx 生成 .docx │ └─────────────────────────────────────────────────────────┘
### Step 4：生成 .docx
宿主 AI 在完成 Markdown 汇报材料后，通过 `use_skill` 加载 `~/.codebuddy/skills/minimax-docx/`（或任一可用的 .docx 生成工具）将内容输出为 Word 文档。**无论使用哪个工具，都必须将以下格式规范作为生成指令的附件一并附上**，确保格式要求被准确传达和执行：
【.docx 格式规范 — 必须执行】
**文字** 格式，必须在传入 docx 工具前转换为目标工具可识别的加粗格式；禁止将 ** 原样输出【附件】：[附：上述 Markdown 正文内容（已去除 ** 加粗语法或已转换为目标工具可识别的格式）]
**重要**："首行缩进2字符"属于 GB/T 9704-2012 的基本要求，无论使用何种 docx 工具都必须执行，不得省略。
### Word 样式参数映射表（避免转换幻觉）
以下参数映射供宿主 AI 在调用 .docx 工具时直接参照执行，减少格式歧义：
| Markdown 语法 | Word 样式 | 字体 | 字号 | 加粗 | 其他 |
|-------------|----------|------|------|------|------|
| `# 主标题`（公文标题） | 标题 1 / Heading 1 | 红色小标宋体 | 2号（22pt） | ✅ | 居中 |
| `## 一级标题` | 标题 2 / Heading 2 | 黑体 | 3号（16pt） | ✅ | |
| `### （一）二级标题` | 标题 3 / Heading 3 | 仿宋体 | 3号（16pt） | ✅ | |
| `#### 1. 三级标题` | 列表样式 | 仿宋体 | 3号（16pt） | ❌ | |
| 正文段落 | 正文 / Normal | 仿宋体 | 3号（16pt） | ❌ | 首行缩进2字符 |
| 表格题注 | 注释 / Caption | 仿宋体 | 4号（14pt） | ❌ | 居中 |
| 图片题注 | 注释 / Caption | 仿宋体 | 4号（14pt） | ❌ | 居中 |
> **注**：字号换算参考——GB/T 9704-2012 中"三号"≈ 16pt，"四号"≈ 14pt。若 docx 工具使用"号"制而非"pt"制，按等效值换算。
---
## Step 1：原文深度结构化分析
对原始素材进行以下维度的深度解析，输出结构化报告：
### 分析维度
| 维度 | 内容 |
|-----|------|
| **核心主题** | 提炼 1 句话概括全文主旨 |
| **时间范围** | 素材覆盖的时间周期 |
| **数据资产** | 所有关键数字（金额、增长率、百分比、排名等） |
| **成果亮点** | 突破、获奖、市场开拓、技术进展等 |
| **问题瓶颈** | 困难、挑战、风险、需协调事项 |
| **建议诉求** | 对上级单位的请求和建议 |
| **模块划分** | 按 MECE 原则归类的逻辑模块 |
| **章节内容点数** | **本维度的核心目的**：统计原文每个二级章节（**一、**下的 ### 三级标题）各包含几条实质性独立要点。输出为：`第三章：3条要点；第四章：2条要点……`。这一信息在重构阶段直接决定：每条要点必须对应一个独立子标题，不允许合并 |
| **问题-对策结构** | **重要**：识别原文各章节是否包含「问题描述 + 对应解决思路/措施/做法」的成对结构（**不拘泥于章节标题名称**，可能是"待改进方面"、"存在问题与思路"、"短板与举措"、"挑战与对策"等任何表述）。判断标准：同一子章节内，先描述问题/困境，随后用"针对该问题"、"针对以上问题"、"为此"、"对策是"等引导词引出解决思路，两段形成"问题←→对策"的语义捆绑。统计有多少个这样的单元，输出格式：`第3章：2个问题-对策单元；第4章：1个问题-对策单元`。这些单元在重构时**必须整块保留**，禁止拆分删除 |
| **缺失内容** | 原文有逻辑断层或不完整的地方 |
| **关键词对齐（政治站位+时效性）** | 检索当前年度核心政策热词（如新质生产力、高质量发展、两重两新、低空经济、数据要素等），检查材料中是否有可挂钩的切入点，在结构化分析报告中标注「可对接政策：XXX」。体制内材料讲究"上接天线"，若无政策关键词对接，需在重构时主动寻找素材与政策的结合点 |
### 输出格式
```markdown
## 原文结构化分析报告
### 核心主题
[1句话概括]
### 数据资产清单
| 指标 | 数值 | 同比增长 | 原文位置 |
|-----|------|---------|---------|
| 新签合同毛利率 | 68.64% | +26.64ppt | 第一章第一节 |
| ... | ... | ... | ... |
### 成果亮点
- [亮点1]：[支撑数据]
- [亮点2]：[支撑数据]
...
### 问题瓶颈
1. [问题1]：[具体描述]
2. [问题2]：[具体描述]
...
### 建议诉求
1. [诉求1]
2. [诉求2]
...
### 模块划分建议
| 模块 | 核心观点 | 包含子项 |
|-----|---------|---------|
| 模块一 | 结论性标题 | 1.1, 1.2, 1.3 |
| 模块二 | 结论性标题 | 2.1, 2.2 |
...
Step 1「原文深度结构化分析」报告输出后，必须暂停，向用户展示：
等待用户确认：
【第一原则】以"写出一篇好文章"为最终目标，而非保留原文
【第二原则】该删则删（冗余废话），该补则补（漏掉的逻辑链），该扩则扩（骨架章节）
【第三原则】多份素材合稿时，以"内容互补、不重复、逻辑自洽"为准
【第四原则】「问题-对策」成对结构必须整块保留，禁止拆分删除
原文某章包含多条实质性独立要点时，重构后这些要点必须逐条展开为独立的（二级/三级）小节，不允许以任何理由（"结构均衡""阅读节奏""篇幅控制"）将其合并或降格为正文段落。
| 情况 | 识别方法 | 正确处理 |
|---|---|---|
| 多实质项展开 | 原文某章节下有多条相互独立的实质性内容（各有不同主题、数据或观点） | 全部展开为各自独立的 (一)(二)(三)... 小节，每条小节标题为结论性表述，小节下跟 1-N 段正文 |
| 字数超标 | 某段正文超过 400 字，但内容本身不可分割 | 精简冗余描述（形容词/重复表达），核心事实和数据一字不动 |
| 骨架章节 | 某章节只有标题，完全没有正文 | 扩写 200-400 字 |
| 结构均衡 | 某章只有 1 个子项，但该子项内容本身很充实 | ✅ 正确——内容充实不是问题，无需强制拆并 |
错误示例（已造成内容丢失）：
(一) 小节下正文段落数量规范| 场景 | 正文段落数 | 说明 |
|---|---|---|
某 (一) 小节仅有 1 个核心意思 | 1 段正文 | 直接围绕标题展开，150-400 字 |
某 (一) 小节包含多个层次/方面 | N 段正文（N ≥ 2） | 每段围绕一个层次展开，段落间用"一是...二是..."衔接 |
| 多个相互独立的实质性要点 | 每个要点单独成 (一)(二)(三)... 小节 | 这是最常见的错误来源——不要把多个独立要点放在同一个小节下作为正文段落 |
| 场景 | 识别特征 | 编辑策略 |
|---|---|---|
| 冗余废话 | 重复表达、官话套话、无实质内容 | 删除，保留核心事实 |
| 骨架章节 | 只有小标题，正文为"待补充" | 根据上下文意图扩写完整段落 |
| 逻辑断层 | 章节间跳跃、缺少过渡 | 补充过渡句/段 |
| 多稿冲突 | 同一数据多版本、观点矛盾 | 编辑判断，取最优表达 |
| 问题-对策结构 | 同一子章节内同时包含「问题描述」和「针对该问题的思路/措施/做法」两段成文内容（章节标题可能为"待改进方面"、"存在问题与思路"、"短板与举措"等任何表述），两者形成语义捆绑 | 整块保留，禁止拆分删除。问题部分精简冗余表述，对策部分保留核心举措。可将两段合并为一个更流畅的段落，但不得删除"针对该问题"所对应的实质性措施内容 |
生成原则：
正文框架按以下优先级选取：
优先级 1：用户已有明确提纲
若用户在输入中已提供提纲（尤其是上级单位规定的年度总结提纲、会议发言提纲等），无论识别出何种文体，一律严格按用户提纲的章节顺序和标题编写，不做结构调整。
优先级 2：无提纲，按文体公式套用
| Step 1 识别的文体 | 套用公式 | 具体章节框架 |
|---|---|---|
| 工作总结 | 任务完成情况 + 存在问题 + 下一步计划 | 一、[年度/任期工作完成情况——结论性表述]（含各子项要点）；二、[存在问题与不足——结论性表述]（独立问题各自成小节）；三、[下一步工作计划——结论性表述] |
| 汇报材料 | 工作推进情况 + 存在问题困难 + 下步计划 + 需要协调解决的问题 + 对上级单位的建议 | 一、[工作推进情况]；二、[存在问题与困难]（独立问题各自成节）；三、[下步计划]；四、[需要协调解决的问题]；五、[对上级单位的建议] |
| 领导讲话稿 | 高站位 + 明责任 + 抓落实 + 工作部署 | 一、[当前形势/背景]；二、[目标任务]；三、[重点举措]（分模块展开）；四、[抓落实要求] |
| 工作方案 | 工作目标 + 责任分工 + 工作要求 | 一、[工作目标]（含量化指标）；二、[重点任务/责任分工]（分条列示）；三、[保障措施/工作要求] |
| 调研材料 | 背景 + 基本情况 + 主要成绩做法 + 存在问题 + 对策建议 | 一、[调研背景]；二、[基本情况]；三、[主要做法与成效]（独立做法各自成节）；四、[存在问题]；五、[对策建议] |
| 其他/混合文体 | 按「汇报材料」公式为基础框架，根据原文实际章节增删调序 | 参考汇报材料结构，按原文素材分布调整 |
重要：同一文体内若有多个实质性并列要点（如"存在问题"下的 A/B/C 三个独立问题），每个要点各自独立成（一）（二）（三）小节，不得合并为一段正文。具体要求见「多实质项独立成节」规则。
生成时，先写占位框架（含结论性小标题），内容从 Step 1 分析结果中填充；原文无对应章节则标记为「[待补充内容]」，后续由扩写规则处理。
| 要求 | 说明 |
|---|---|
| 标题 | 结论性（动词+名词/评价+事实），禁止"关于XXX的情况" |
| 正文 | 核心观点在首句，支撑数据紧随其后 |
| 重点文字加粗 | 标题中的核心词（如"合同金额 3179.65 万元"中的"3179.65 万元"）、正文中的结论性语句、关键名词均加粗显示；数字类重点用「加粗数字」表达（如 3179.65 万元），非数字类重点用「加粗关键词」表达（如 专精特新） |
| Markdown 标记处理 | Skill 输出的 Markdown 中可用 **文字** 表示加粗，但宿主 AI 在调用 docx 工具前必须将其转换为该工具能识别的加粗格式（如 minimax-docx 的 【加粗】文字【/加粗】 或 Word XML 的 <w:b/>），或直接在生成指令中要求工具解析 Markdown 加粗语法；禁止将 ** 原样传入 docx |
| 中文引号 | 统一使用直角引号「」或弯引号""，全文保持一致；避免混用 |
| 数据 | 加粗关键数字，用括号标注同比增长 |
| 段落 | 每段参考 150-400 字；内容充实则不受此限制，字数多是好事，说明素材丰富，切勿以篇幅限制为由删减实质性内容 |
| 废话删除 | 重复修饰词、无意义的套话直接删除 |
| 骨架扩写 | 仅标题无内容的章节，根据上下文意图扩写 200-400 字 |
| 过往材料内容填充（创作模式） | 以用户过往材料为内容填充的主要参考源：①识别过往材料中与当前提纲各章节对应的内容段落；②将对应内容迁移至当前创作框架；③保留过往材料的语言风格和表达习惯；④数据/案例须注明来源并核实适用性 |
| 衔接 | 段落间用"一是...二是..."或"与此同时..."衔接 |
| 骨架章节虚实结合（创作模式） | 提纲中章节分两类：①**"虚"章**（总体要求、指导思想、背景分析）→ 侧重搜索最新政策文件进行对齐，确保"上接天线"；②**"实"章**（具体举措、工作成效、问题分析）→ 优先调用过往材料中的成功案例、数据进行迭代填充；创作时先写"实"章再建"虚"章 |
| 图表引用 | 正文在描述数据时必须明确引用图表，格式为"如表1所示"、"见图1"等；不得仅在表格/图片下加题注而正文中无引用 |
| 图表题注 | 所有表格和图片必须加题注；表题在表格上方，格式为「表 1 ××××」；图题在图片下方，格式为「图 1 ××××」（见下方格式规范） |
| 正文与图表的分工原则 | 若文中已插入数据表格，正文应聚焦于概括完成率/达标情况/核心结论，而非罗列表格中已有的详细数据；表格本身展示具体数值，正文起总结和引导作用 |
| 段落缩进 | 所有正文段落首行缩进 2 字符，不得顶格 |
删除内容（废话类）：
保留内容（事实类）：
扩写内容（骨架类）：
压缩内容（冗余类）：
⚠️ 扩写内容的标注要求：
| 内容类型 | 标注方式 | 说明 |
|---|---|---|
| 原文已有内容 | 无特殊标注 | 正常展示 |
| 扩写内容（与用户工作紧密相关） | 黄色底色填充 | 扩写内容与用户实际工作/业务深度结合时使用 |
| 扩写内容（一般性扩展） | 无特殊标注 | 常规扩写，无标注 |
黄色底色标准：Word 中使用 Shading 属性，颜色值 #FFFF00（纯黄）。输出时请在 .docx 生成指令中明确标注：「以下段落应用黄色底色（#FFFF00）Shading」，由 minimax-docx skill 负责渲染
判断标准：扩写内容若涉及用户具体岗位职责、业务范畴、工作成果的深度阐述，用黄色底色标注。例如：
宿主 AI 根据【汇报类型】匹配对应公式，作为正文框架的骨架；具体内容从 Step 1 分析结果中填充。
| 文体 | 结构公式 | 适用场景 |
|---|---|---|
| 领导讲话稿 | 高站位 + 明责任 + 抓落实 + 工作部署 | 正式会议发言 |
| 工作方案 | 工作目标 + 责任分工 + 工作要求 | 计划类文件 |
| 工作总结 | 任务完成情况 + 存在问题 + 下步计划 | 年度/专项总结 |
| 汇报材料 | 工作推进情况 + 存在问题困难 + 下步计划 + 需要协调解决的问题 | 向上级汇报 |
| 调研材料 | 背景 + 基本情况 + 主要成绩做法 + 存在问题 + 对策建议 | 调研报告 |
| 通俗版（任意材料） | 思路 + 动作 + 效果 | 非正式、受众广的场景；优先级最高，覆盖其他格式规则 |
通俗版公式详解：
⚠️ 通俗版强制性语义约束： 当用户注明「通俗版」时，宿主 AI 必须对每个段落执行以下语义检查：
若段落三要素缺失，AI 须在扩写内容中补全，而非原样输出。Step 3 格式规范（缩进/加粗等）可适当放宽，但三要素不得缺失。
使用规则：
触发条件：用户选择「创作模式」，仅提供主题、提纲或过往材料参考，无完整原文。
宿主 AI 执行以下意图推断，输出「创作意图分析报告」：
| 推断维度 | 推断内容 | 说明 |
|---|---|---|
| 汇报场景 | 综合汇报 / 专项汇报 / 会议发言 / 调研汇报 | 从提纲标题/关键词推断 |
| 受众层级 | 基层 / 中层 / 高层 | 决定层级敏感度权重 |
| 核心诉求 | 本次汇报想达成什么目的 | 争取资源 / 汇报进度 / 申请支持 / 总结成绩 |
| 紧迫程度 | 常规 / 紧急 | 影响详略程度 |
| 可用的参考材料 | 用户提供的过往材料 | 提取：语言风格 / 常用表述 / 数据表达方式 |
输出：将推断结果整理为结构化的「创作意图分析报告」，作为 Step 1C 搜集方向和 Step 2 创作指令的依据。
Step 0「创作意图分析报告」输出后，必须暂停，向用户展示：
| 确认项 | 内容说明 |
|---|---|
| 汇报场景 | 综合汇报 / 专项汇报 / 会议发言 / 调研汇报（自动识别） |
| 受众层级 | 基层（执行层）/ 中层（协调层）/ 高层（决策层） |
| 核心诉求 | 争取资源 / 汇报进度 / 申请支持 / 总结成绩 |
| 可用素材概况 | 用户提供的过往材料数量和覆盖范围 |
| 初步判断的文体公式 | 将套用的文体结构公式 |
等待用户确认：
触发条件：创作模式下，宿主 AI 根据 Step 0 的意图分析，主动搜集填充素材。
| 维度 | 搜集目标 | 搜集方式 |
|---|---|---|
| 政策背景 | 当前年度相关政策热词（二十届三中全会精神、中央经济工作会议等） | 搜索：相关政策关键词 + "要点/精神/部署" |
| 上级部署 | 上级单位近期重点任务、考核要求 | 搜索：上级单位名称 + "工作部署/重点任务/考核" |
| 行业数据 | 相关行业主要指标、同期对比数据 | 搜索：行业名称 + 统计公报 / 行业发展报告 |
| 兄弟单位做法 | 同类单位的工作思路、经验做法 | 搜索：行业 + "经验交流/工作做法/典型发言" |
| 数据支撑 | 可引用的宏观数据、增长率等 | 搜索：相关经济指标 + 最新统计数据 |
| 过往材料风格 | 用户历史材料的语言风格、格式偏好 | 分析用户提供的过往材料 |
use_skill 加载 ~/.workbuddy/skills/baidu-search/ 检索用户工作相关的内部资料、政策文件宿主 AI 将搜集结果整理为「素材库」，格式如下：
## 素材库
### 一、政策背景
- [来源] 二十届三中全会关于[XXX]的精神（2024年7月）
- [来源] 中央经济工作会议部署[XXX]重点任务（2024年12月）
### 二、行业数据
- [来源] 2024年[行业]同比增长 X%（国家统计局，2025年2月）
- [来源] [省份] 2024年[指标]达到 X 亿元（省统计局公报）
### 三、兄弟单位做法（可借鉴）
- [来源] [单位] 在[具体工作]方面的经验（2024年交流会材料）
### 四、过往材料风格分析（语料特征提取）
- **单位内部黑话/特定术语**：[如"专项办"、"三个一"、"四化模式"等]
- **逻辑偏好**：喜欢分 3 点还是 4 点；喜欢用"一是...二是..."还是"首先...其次..."
- **惯用连接词**：[如"在此基础上"、"聚焦重点"、"统筹推进"等高频衔接语]
- **惯用数据表达**：[如"完成率100%"、"同比增长X%"、"达到XX亿元"等表达模式]
- **结构偏好**：[如习惯用"形势分析→总体要求→具体举措"还是直接列举措]
> 目的：确保新写材料不仅结构正确，读起来也像"咱们单位的人写的"，而非外来材料生硬拼凑
| 项目 | 规范 |
|---|---|
| 纸张 | A4（210mm × 297mm） |
| 页边距 | 上 37mm，下 35mm，左 28mm，右 26mm |
| 版心 | 156mm × 225mm |
| 要素 | 字体 | 字号 | 行距 |
|---|---|---|---|
| 公文标题 | 红色小标宋体 | 2号 | — |
| 一级标题 | 黑体 | 3号 | 28磅固定值 |
| 二级标题 | 仿宋体 | 3号 | 28磅固定值 |
| 三级标题 | 仿宋体 | 3号 | 28磅固定值 |
| 正文 | 仿宋体 | 3号 | 28磅固定值 |
| 页码 | 半角宋体 | 4号 | — |
| 表格题注 | 仿宋体 | 4号 | — |
| 图片题注 | 仿宋体 | 4号，居中 | — |
【表格】
表 1 [表格名称]
┌─────┬─────┬─────┐
│ 指标 │ 数值 │ 同比 │
├─────┼─────┼─────┤
│ ... │ ... │ ... │
└─────┴─────┴─────┘
【图片】
图 1 [图片名称，居中]
[图片内容]
题注命名规则：
表 1 [描述性名称]，后面直接接表格，不加冒号图 1 [描述性名称]，居中一、xxx（一级标题，黑体）
（一）xxx（二级标题，仿宋）
1. xxx（三级标题，仿宋）
（1）xxx（四级标题，仿宋）
| 层级 | 命名方式 | 示例 |
|---|---|---|
| 一级 | 动词+名词 | 核心技术研发取得突破 |
| 二级 | 评价+事实 | 专利数量同比增长 30% |
| 三级 | 短句/词组 | 突破"卡脖子"技术难题 |
请按以下格式提供素材：
【原始素材】
[粘贴原始汇报材料内容，支持 .doc/.docx/.pdf/.txt/.md 格式]
【汇报类型】（综合汇报/专项汇报/计划汇报/通俗版）
【时间范围】（本年度/专项周期）
【主送机关】（如：XX集团/XX研究所）
【领导关注点】（如有明确要求请注明）
【篇幅目标】以"写出一篇好文章"为原则，可删减废话、可合并重复、可扩写骨架、可查漏补缺
生成完毕后自检：
(一)(二)(三)... 小节，每个小节独立成项；多要点合并为正文段落属于严重结构错误，必须修正** 原样输出；**文字** 必须在传入 docx 工具前完成格式转换不同职级的汇报对象，对材料的侧重点完全不同。宿主 AI 应根据【汇报类型】中隐含或明确的受众职级，调整写作权重。
| 受众层级 | 核心权重 | 说明 |
|---|---|---|
| 基层（执行层） | 动作 > 思路 | 侧重"怎么做、谁来做、何时做完"，减少战略论述，增加具体举措 |
| 中层（协调层） | 动作 ≈ 思路 | 既要讲清楚协调了什么，也要讲清楚思路依据，平衡两者 |
| 高层（决策层） | 思路 > 动作 | 侧重战略意义、风险研判、资源需求、需上级协调事项；减少执行细节 |
使用方式：宿主 AI 在生成正文框架和填充内容时，先判断受众层级，再调整各部分的详略权重。例如：向高层汇报时，"为什么要做"（思路）要比"具体怎么做"（动作）占更多篇幅。
体制内公文有明确的禁忌，一旦出现，轻则被视为"不专业"，重则影响材料可信度。
| 禁用词 | 问题 | 替代表达 |
|---|---|---|
| 可能、大概、差不多、左右 | 模糊不确定 | 已完成、正在推进、预计、计划 |
| 将会、将会要 | 语气弱 | 将于XX完成、确保XX |
| 一些、若干、部分 | 不明确 | 3项、5类、若干→具体数字 |
| 类型 | 正确 | 错误 |
|---|---|---|
| 金额/数量 | 由大到小降序 | 随意排序 |
| 工作任务 | 按重要程度/优先级 | 按时间顺序 |
| 问题清单 | 按严重程度/影响面 | 按出现顺序 |
| 金额单位 | 全文统一换算为相同量纲（如"亿元"或"万元"，不得混用） | 混用"万/亿/百万"等不同量纲 |
| 数据类型 | 时效标准 | 处理要求 |
|---|---|---|
| 搜索获得的事实数据（指标、金额、百分比等） | 早于两年 | 引用时须加黄色底色标注，并在数据旁备注 [待核实实时数据]，不得原样引用而不标注 |
| 政策文件精神/部署 | 以最新年度为准 | 若引用非最新版本，须注明"截至XX年" |
| 行业统计数据 | 以最近一次官方发布为准 | 若使用非最新数据，须注明统计年份 |
本 skill 依赖宿主 AI 环境中的以下工具/skill，路径已验证可达：
| 工具/Skill | 路径 | 用途 | 替代方案 |
|---|---|---|---|
baidu-search | ~/.workbuddy/skills/baidu-search/SKILL.md | Step 1C 政策/数据搜索 | web_search / 浏览器搜索（Step 1C §1.2 提及） |
minimax-docx | ~/.codebuddy/skills/minimax-docx/ | Step 4 生成 .docx | 其他 docx 工具（Step 4 提及） |
use_skill | 宿主 LLM 内置 | 加载 baidu-search 等依赖 skill | — |
宿主 AI 在执行 Step 1C 和 Step 4 前应确认上述工具可用；若不可用，按替代方案执行且不阻塞流程。
| 资源 | 引用方式 | 说明 |
|---|---|---|
| 金字塔原理 | 芭芭拉·明托《金字塔原理》 | 结构方法论：结论先行、以上统下、归类分组、逻辑递进 |
| 公文格式规范 | GB/T 9704-2012 | 已在 Step 3 完整嵌入 SKILL.md，无需额外引用 |
| MECE 分析法 | 麦肯锡问题分析与解决技巧 | 逻辑分类原则：互不交叉、完全穷尽 |