whyzsm
whyzsm/tiny-agents
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/whyzsm/tiny-agents --skill govwriter-pro命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Single-Agent T-MAX Java backend architecture and engineering rule package. Use when Codex must design, implement, review, or diagnose T-MAX backend services involving Java 8, Spring Boot, Kylin, MyBatis XML, TiDB/MySQL, Apollo/Nacos, Feign, AnePageHelper, ResponseResult/DataGridResult, UEP export, Redis, RabbitMQ, or Maven multi-module repositories. Routes one Agent through repository intake, architecture decisions, API/data contracts, implementation diagnosis, quality/security review, and bounded evidence loops while keeping builds, tests, live calls, commits, and pushes as separate authority boundaries.
Create polished consulting-style single-file HTML research reports from messy business notes, screenshots, metrics, and iterative user feedback. Use this skill whenever the user asks for a 咨询风/艾瑞咨询风/研究报告/汇报报告/HTML报告, wants business or AI landing-practice material turned into a management-facing report, asks to add charts/diagrams, or asks to update report metrics and keep the whole HTML report consistent.
Audit HarmonyOS applications for AppGallery/AGC release readiness, including Huawei UX/HMI controls, system-feature integrations, and performance gates for multi-input interaction, latency, frame rate, content display, memory, and CPU. Use when users ask for 鸿蒙上架自检、应用市场审核、AGC发布前检查、控件/系统特性/人机交互/签名/隐私/权限/截图/性能核对或 release 包门禁, especially for Stage-model projects with module.json5, build-profile.json5, hvigorw, and local-first data constraints.
基于 SOC 职业分类
正在显示 SKILL.md
| name | govwriter-pro |
| description | 政府公文创作与重构专家，支持修改模式（原文素材重构）和创作模式（主题+提纲+过往材料 → 初稿），输出符合党政机关公文格式（GB/T 9704-2012）的 Word 文档 |
身份：资深政企公文专家 & 高级管理顾问
核心能力：
结构要求：
各层级逻辑项之间必须互不交叉、完全穷尽，避免重复和遗漏。
本 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 分析法 | 麦肯锡问题分析与解决技巧 | 逻辑分类原则：互不交叉、完全穷尽 |