---
name: gongwen-skill
description: 公文全流程处理工具。支持 .docx 公文按 GB/T 9704 国家标准做格式检查（check）、自动修复（optimize）、行内内容修订（optimize-content，红色标注+删除线+修改说明）、模板生成（template）、样式学习（style-learn，从标准文档学习排版样式生成自定义模板）、Markdown 转公文（md2docx），以及版头/版记/页码注入。覆盖通知/请示/报告/函/会议纪要等 24 类公文。完全自包含，克隆即用，无需数据库或后端服务。
whenToUse: 当用户需要处理中文公文（.docx格式）时，包括格式检查、自动修复、内容润色、模板生成、样式学习（从标准文档学习排版样式生成自定义模板）、Markdown转公文、版头版记注入等场景。适用于通知/请示/报告/函/会议纪要/新闻稿/讲话稿等24种公文类型。
user-invocable: true
metadata:
  author: Jose AI
  repo: https://github.com/linhut/gongwen-skill
  license: MIT
  python: ">=3.10"
  dsh_version: compatible
  doc_types: 24
  standard: GB/T 9704-2012
---

<!--
  (c) 2026 Jose AI (https://www.linhut.cn)
  https://github.com/linhut/gongwen-skill
  Licensed under the MIT License. See the LICENSE file for details.
-->

# 公文文档格式化 Skill（GB/T 9704）

---

## ⚠️ 硬门控（Agent 必须遵守，不可跳过）

### 一、执行前路径声明

**在任何操作之前，Agent 必须先声明以下内容，不得跳过：**

```
■ 当前调用环境：[CLI / workbuddy / cloudcode / dsh / dialogue-only / 其他（请注明）]
■ 用户需求判定：[路径 A 格式修复 / 路径 B 内容优化 / 路径 C 生成公文 / 其他（请注明）]
■ 判定依据：[用户原话或内容摘要]
```

**环境适配规则**：

| 环境 | 能力 | 行为要求 |
|------|------|---------|
| **CLI 直接调用** | 可执行命令、读写文件 | 必须执行完整命令（`python -m gongwen check/optimize/optimize-content`），展示命令和输出 |
| **workbuddy / cloudcode** | 加载 SKILL.md 注册为 skill，可执行命令 | 加载 skill 后直接调用 CLI 命令，按 SKILL.md 指引执行路径路由和禁令 |
| **dsh** | 加载 SKILL.md + cordis 插件，可执行命令、有 Web UI | 加载 skill 后调用 CLI 命令，或通过 DSH 插件 API 调用；配置面板可调整排版参数 |
| **dialogue-only** | 纯对话，**不能执行命令** | 不应直接执行命令，应引导用户手动操作；同时可读取项目内的文字性资源库（`prompts/style-prompts.md`、`prompts/usage-prompts.md`、`rules/official/*.yaml`、`SKILL.md` 等）作为公文写作指导的知识库，在对话中提供用词用语、写作规范、风格指引等专业建议；参考 README.md 中的「纯对话 LLM 使用指引」

> **格式兼容性**：工具链基于 OOXML（`.docx`），**不支持旧版 `.doc`（OLE2/WPS 二进制格式）**。用户提供 `.doc` 文件时，Agent 应先用 WPS/Word「另存为 .docx」；本机装有 WPS 时可用 COM 转换：`KWPS.Application` → `Documents.Open(src)` → `SaveAs(dst, 12)`（WPS 枚举 12 = OOXML），再走 `check/optimize/optimize-content` 全流程。

### 二、聚合禁令（违反任一条即为不合格执行）

```
❌ 路径 B（内容优化）严禁自写 Python 脚本操作 docx——必须使用 optimize-content 命令
❌ 路径 B 严禁只交付干净版不交付差异对比版——差异对比版是唯一交付物
❌ 严禁连续多次执行 optimize-content 而不穿插 optimize——多轮优化必须先走路径 A 生成中间稿
❌ 严禁凭空编造 reference（如"公文'主持词'写作规范"）——引用必须真实可查
❌ 严禁静默失败——命令出错必须向用户报告错误信息和排查过程
❌ 严禁未读取参考文件声称"已阅读"——扫描件 PDF 应尝试 OCR 或告知用户
❌ 严禁编造领导姓名、机构名称、职务、人物姓名——所有人事信息必须来源明确或用 XXX 占位
```

### 三、模板保留策略（当用户提供 .docx 模板时）

- **必须严格保留模板的格式约定**：文档样式、字体、页面布局（边距/页面大小/方向）、页眉页脚、分节结构和表格样式
- **不得引入模板中不存在的结构或版式**，不得静默偏离模板
- 若用户需求与模板约束冲突，先说明具体冲突并获得用户明确同意，再做结构性变更

### 四、依赖降级策略（依赖缺失时的强制处理顺序）

当必需依赖缺失或不可用时，Agent **必须**按以下顺序处理：

1. **先尝试安装**：`pip install -r requirements.txt`（或按 requirements.txt 补充安装缺失包）
2. **再使用降级模式**：若安装失败或工具仍不可用，运行指定的降级命令：
   | 缺失依赖 | 主用命令 | 降级命令 |
   |---------|---------|---------|
   | python-docx | `pip install python-docx` | 不可降级（核心依赖），需修复安装环境 |
   | pydantic | `pip install pydantic` | 不可降级（模型定义依赖） |
   | pyyaml | `pip install pyyaml` | `python -m gongwen` 内置 YAML 解析兜底（rules 加载） |
   | lxml | `pip install lxml` | 不可降级（OOXML/批注/修订注入核心） |
   | LibreOffice（文档转图片） | `soffice --headless --convert-to pdf` | `python engine/docx_to_image.py <docx> --outdir <dir>`（docx2pdf/PyMuPDF 降级） |
   | kdocs-cli（可选云协作） | `kdocs-cli --help` | 回退纯本地流程，不影响 gongwen 功能 |
3. **不得自创降级方案**：严禁自行替换工具、使用替代流程或自创降级方案，除非上述两步均已尝试且确实无法满足任务需求

### 五、环境说明

本 Skill 通过多种方式被 AI 平台加载使用：

| 方式 | 说明 |
|------|------|
| **本地 CLI** | 克隆仓库 → `pip install -r requirements.txt` → `python -m gongwen <命令>` |
| **WorkBuddy / CloudCode 类** | 将仓库路径加入 skills 目录，加载 SKILL.md 后注册为 skill，Agent 可直接调用 CLI 命令 |
| **DeepSeek Harness (DSH)** | 通过 npm 包或 skill 目录加载，支持 cordis 插件体系（Web UI 配置面板 + API 路由） |
| **纯对话 LLM** | 无法执行代码的 AI 平台（如豆包、Kimi、ChatGPT 网页版），应引导用户手动操作，详见 README.md 使用指引 |

### 六、版本自检（Agent 必须在技能加载后执行）

1. 读取 `gongwen` 包顶部的 `__version__` 常量，获取本地版本号
2. 告知用户：`当前加载 gongwen-skill v{__version__}`
3. **版本自检**（不能只用本地 `git describe`——它只读本地可达 tag，未 fetch 时会误判本地即最新；也不能只查单一仓库——网络抖动会导致误判）：
   ```bash
   # 首选：CLI 内置自检命令（PyPI pip 包权威判定 + GitHub 备用渠道，自动比对本地版本）
   python -m gongwen check-update

   # 手动回退：PyPI 权威（pip 包发布源）
   python -c "import urllib.request,json;print(json.loads(urllib.request.urlopen('https://pypi.org/pypi/gongwen-skill/json',timeout=10).read())['info']['version']))"
   ```
   - **PyPI 为权威判定渠道**（pip 包核心分发，pip install -U 即从 PyPI 拉取）；PyPI 不可达时回退 GitHub tag（备用渠道，git 用户/CI 触发源）
   - GitCode/AtomGit 与 GitHub 同源 tag，仅在 GitHub 不可达时作国内拉取镜像提示（不参与版本判定）
   - GitHub 不可达且触发 DNS 诊断时（系统解析为保留/Fake-IP 段），`check-update --json` 会输出 `dns_diagnosis` 字段（含 `hosts_suggestions`），如实向用户转述排查建议即可
   - 若全部渠道均不可用（无 git/无网络），**必须明确告知用户"版本自检因无法访问远程而跳过"**，不得静默假设本地即最新
3.5. **本地 git tag 对比**（P6，Agent 执行版本确认时补充）：
   - 优先对 skill 安装目录执行 git tag 对比：
     ```bash
     git -C "<skill安装目录>" describe --tags --abbrev=0
     ```
   - 若 skill 目录不在 git 管理下，应告知用户"无法执行版本对比，建议手动检查 GitHub 更新"
   - 版本对比结果若发现本地版本落后于最新 tag，应在执行前**警告用户**
4. 若权威渠道最新版本 > 本地 `__version__`，提示用户：
   ```
   有更新可用：最新版 {最新版}，当前 {本地version}
   安装形态自动检测（pip 包 / git 目录），按形态给出精准更新命令：
     pip 包安装：pip install --upgrade gongwen-skill
     git 目录安装：cd <gongwen-skill目录> && git pull && git fetch --tags
   拉取地址：
     PyPI（权威）：https://pypi.org/project/gongwen-skill/
     GitHub（备用）：https://github.com/linhut/gongwen-skill
     GitCode / AtomGit（国内镜像）：https://gitcode.com/linhut/gongwen-skill / https://atomgit.com/linhut/gongwen-skill
   ```

### 七、会话交接（长任务收尾必须遵守）

**目的**：跨会话上下文传递。当会话结束（上下文溢出/超时/人为中断/用户说"下次继续"）时，新会话的 Agent 必须能**无需用户复述**即可继续任务。

**收尾时（满足任一条件 → 结束前必须写交接文档）**：
- 本轮会话处理了 3 个以上公文文件
- 执行了多轮 check / optimize / optimize-content 迭代
- 用户明确表示"下次继续""先到这里""收尾"
- 会话上下文即将耗尽或已发生压缩

交接文档写入：`~/.gongwen-skill/handoffs/{YYYY-MM-DD}_{简短描述}.json`
（位于 `APP_DATA_DIR`，`git pull` 更新 skill **不会覆盖**；与 `user_rules/` 同属用户持久化目录）

**写入方式（Agent 用 Python 调用，禁止手写 JSON 字符串到 PowerShell）**：

```bash
python -c "
import sys; sys.path.insert(0, '<skill目录>/engine')
from handoff import write_handoff
write_handoff(
    session_id='简短任务描述',                    # 如 '民宗委会议材料优化'
    handoff_type='long_task',                    # long_task / batch / interrupted
    context={'what_we_are_doing': '我们在做什么', 'doc_type': '公文类型',
             'input_file': '输入文件', 'working_directory': '工作目录'},
    completed=[{'item': '已完成事项', 'evidence': '验证依据/产出文件'}],
    blocked_on=[{'issue': '卡住的问题', 'severity': 'P2', 'detail': '详情'}],
    next_steps=[{'action': '下一步', 'status': 'pending'}],
    pitfalls=[{'lesson': '踩过的坑，不要再踩', 'reference': '来源/修复编号'}],
    related_files=[{'path': '文件绝对路径', 'role': '角色说明'}],
    agent_hint='写给新 Agent 的一句话引导',
)
"
```

**新会话开始时（强制检查）**：
1. 先执行 `python -m gongwen handoff --list` 查看是否有未完成任务
2. 若有，读取最新一条：`python -m gongwen handoff --latest --summary`（Markdown 摘要）
3. 向用户确认："检测到上次未完成的交接文档《{session_id}》，是否继续该任务？"
4. 用户确认后，按 `context` / `completed` / `blocked_on` / `next_steps` / `pitfalls` 恢复上下文继续

**命令速查**：
```bash
python -m gongwen handoff --list             # 列出所有交接文档
python -m gongwen handoff --latest           # 最新交接文档（JSON）
python -m gongwen handoff --latest --summary # 最新交接文档（Markdown 摘要）
```

**注意事项**：
- 交接文档是**任务级**上下文（做了什么/卡在哪/下一步），与 `user_rules/`（格式知识模板）、TeleAgent 长期记忆（用户偏好）互补，不冲突
- 完成后可在交接文档中标记对应 `next_steps` 为 done，或新建交接文档记录新任务；任务彻底完结后可删除旧交接文档
- **禁止**使用 PowerShell 写交接文档（编码/转义不可靠，同 OOXML 编辑规范）

---

---

## 顶层路由：三点式入口

### 这个 Skill 做四件事

- **路径 A - 格式修复**：用户有文档，只需排版标准化（GB/T 9704），不改文字内容
- **路径 B - 内容优化**：用户有文档，需要润色文字并生成修订对比版（原稿 vs 优化稿，红色标注修改处）
- **路径 C - 生成公文**：用户没有文档，根据背景和要求从零生成新的公文。四步流程：编写 Markdown 草稿 → md2docx 转换 → 引用路径 A optimize 套国标格式 → check 验证交付；也可用 `gongwen draft 草稿.md -o 成品.docx -t 类型` 一条命令完成（含自动格式修复 + 验证）。
- **路径 D - 一键格式修复**（`fix-common` 新增）：用户有文档，只需快速规范化常见格式问题（段落类型修正/编号拆分/首句加粗/加粗范围修复），一步到位，输出不含 AI 声明段的干净文档。与路径 A 的区别：不依赖规则引擎、不追加 AI 声明段，适合对"干净中间稿"做最终格式规范化。
- **路径 E - 样式学习**（`style-learn` 新增）：用户提供一份**标准文档**（如本单位定稿的红头公文/排版规范的样例），要求"学习排版样式""按这个格式生成模板""做成模板以后都用这个格式"。Agent 应调用 `style-learn` 解析文档的字体/字号/字间距/行距/缩进/页边距，生成命名自定义模板（注册到 user_rules），后续所有文档可用 `optimize -t 模板名` 套用该格式。

### 路径判断规则

| 用户行为 | 关键提示词 | → 路径 |
|----------|------------|--------|
| 上传/指定了文档 | "排版"/"格式"/"红头"/"标准化"/"套红头"/"版式" | **A** |
| 上传/指定了文档 | "润色"/"改写"/"对比"/"修改"/"改一下"/"措辞" | **B** |
| 上传/指定了文档 + 明确要改内容 | "优化"/"调一下"（需先追问消歧） | **B** |
| 没有文档 | "写一份"/"生成"/"起草"/"帮我写" + 公文类型 | **C** |
| 上传/指定了文档 + 只要格式规范化 | "规范一下"/"整理格式"/"格式不对"/"一键修复" | **D**（fix-common） |
| 上传标准文档 | "学习排版"/"做成模板"/"按这个格式"/"学这个样式"/"提取格式" | **E**（style-learn） |

**「优化」消歧强制规则**：
用户说"优化一下""帮我改改""调整内容"等模糊表述时，Agent **必须先追问**：
> 您是希望**改文字内容**（润色措辞/调整表述），还是**修排版格式**（字体/行距/页边距）？
- 改文字内容 + 有文档 → 路径 B
- 改文字内容 + 无文档 → 路径 C
- 修排版格式 → 路径 A

**严禁未经追问直接选择默认路径。**

### 路径选择决策树（Agent 加载 Skill 后必须执行）

**前置步骤（不可跳过）**：Agent 必须先向用户介绍四条路径的能力范围，使用以下简洁模板：

> 本工具支持五种处理方式：
> - **格式优化**（路径 A）：不改文字，只修排版——字体/字号/页边距/行距/缩进按国标标准化，输出干净成品
> - **内容优化**（路径 B）：润色文字表达，生成带红色标注+删除线的对比版，每段附修改说明
> - **生成公文**（路径 C）：从零生成新的公文，四步流程：草稿→转换→套格式→验证
> - **一键格式修复**（路径 D）：快速规范化常见格式问题（段落类型/编号拆分/首句加粗/加粗范围），一步到位，输出不含 AI 声明段的干净文档
> - **样式学习**（路径 E）：上传一份标准文档，自动学习其排版样式（字体/字号/字间距/行距/页边距），生成命名模板，后续所有文档可用 `optimize -t 模板名` 套用该格式

介绍完毕后再按以下决策树判断路径：

```
用户消息
  │
  ├─ 包含"优化/润色/改/调整" + 指定了已有文档
  │   └── 识别为路径 B（内容优化）
  │       ├── 必须使用 optimize-content 命令
  │       ├── 必须产出差异对比文档
  │       └── 严禁自写脚本操作 docx
  │
  ├─ 包含"排版/格式/红头/标准化" + 指定了已有文档
  │   └── 识别为路径 A（格式修复）
  │       └── 必须使用 check → optimize → check
  │
  ├─ 包含"规范一下/整理格式/格式不对/一键修复" + 指定了已有文档（只需快速规范化）
  │   └── 识别为路径 D（一键格式修复）
  │       └── 必须使用 fix-common 命令（不含 AI 声明段）
  │
  ├─ 包含"生成/写/起草" + 未指定已有文档
  │   └── 识别为路径 C（生成公文）
  │       └── 必须走 md2docx → [bold-first] → optimize → check（或 `draft 草稿.md -o 成品.docx -t 类型` 一步到位）
  │
  └─ 不确定
      └── 必须追问用户：是改格式还是改内容？不得猜测路径直接执行
```

**关键规则**：
- 一旦判定为路径 B，**严禁**使用 python-docx 自写脚本修改文档
- 如果 optimize-content 因文本匹配失败，必须：
  1. 检查 `original_text` 是否与 `para.text` 完全一致（包括空格、标点）
  2. 参考 warning 中的诊断信息（文本长度、相似度、差异字符）定位问题
  3. 如仍失败，向用户报告并寻求指导，不得切换到自写脚本

---

## 用户交互指引（Agent 必须遵守）

> **终端用户也可直接运行 `python -m gongwen wizard`**：交互式向导以菜单方式完成同样的 A/B/C/D/E 路径选择与逐步确认（详见下文「向导式交互」小节）。Agent 读到本条时，若用户表示「不熟悉命令/不想记参数」，应主动引导其使用向导，而非逐字念命令行参数。

### 第一步：确认路径（必须，严禁跳过）

用通俗语言问用户走哪条路，**不允许跳过**。向导模式与对话模式共用同一套路径：

> 这个工具支持四种处理方式：
> - **A. 格式优化**：不改文字，只修排版（字体/字号/页边距/行距/缩进），按国标标准化
> - **B. 内容优化**：润色文字表达，生成带标记的对比文档——保持原文档排版样式，修改处红色高亮或删除线、每段附修改说明
> - **C. 生成模板**：直接生成一份空白公文模板，按国标设好版式
> - **D. 一键格式修复**（fix-common）：快速规范化常见格式问题（段落类型/编号拆分/首句加粗），输出不含 AI 声明段的干净文档

若用户说「帮我优化一下」，必须追问是改格式还是改内容。

### 第二步：告知输出物

执行前明确说会生成什么文件、包含什么标记。向导模式会在执行前展示将运行的完整命令。

### 第三步：执行后验证

执行完告诉用户：改了几处、标记是否到位、格式是否合规。

---

### 向导式交互（`wizard` 命令）

当用户**不熟悉命令行**、希望**逐步确认后再执行**，或 Agent 需要**把交互决策委托给工具**时，使用向导：

```
python -m gongwen wizard                        # 终端交互：菜单选 A/B/C/D/E → 逐项填参 → 预览确认 → 执行
python -m gongwen wizard --answers 答案.json     # Agent 非交互：跳过提问直接执行
python -m gongwen wizard --answers 答案.json --dry-run  # 只打印将执行的命令，不真正执行
```

- **路径菜单**：A 格式优化（`optimize`）｜B 内容优化（`optimize-content`）｜C 生成模板（`template`）｜D 一键格式修复（`fix-common`）｜E 样式学习（`style-learn`）
- **交互流程**：选择路径 → 收集参数（公文类型支持 序号 / id / 中文名，如 `1`、`notice`、`通知`）→ A/B/D 先预览再 y/n 确认 → 执行；C 无修改风险直接执行
- **`--answers` JSON 扁平结构**（Agent 场景，顶层带 `path`）：
  ```json
  {"path": "A", "input": "原文.docx", "doc_type": "notice", "output": "成品.docx", "apply": true}
  ```
  - 字段缺失：非交互模式直接报错并列出缺失项（不静默、不进交互菜单）
  - 不写 `apply` 时 A/B/D **仅预览不执行**（安全默认）；`apply: true` 跳过确认直接执行
  - 非交互执行机制：`subprocess` 调用 `sys.executable -m gongwen <子命令>`，输出流式透传，Agent 可直接解析子命令原始输出
- **`--dry-run`**：只打印将执行的命令；A/B 会同时打印「预览」与「执行」两条命令，便于 Agent 预演与调试

---

## 执行标准总则（所有路径共享）

### Agent 行为准则

#### 1. 理解用户真实需求

用户通常给出简短或模糊的描述，Agent **必须先理解再行动**，不得机械匹配关键词：

| 用户说 | 实际需求 | Agent 应做 |
|--------|---------|-----------|
| "帮我改一下这份通知" | 不确定要改格式还是改内容 | 追问"是调整排版格式还是润色文字内容？" |
| "这个发文好像不太对" | 可能有格式问题或内容问题 | 先 check 展示问题清单，再问用户是否修复 |
| "按上级文件要求调整" | 用户有政策依据但未提供 | 追问具体文件名或文号，或用 web 搜索相关政策 |
| "弄漂亮一点" | 希望格式规范 | 解释 GB/T 9704 标准是唯一合规格式 |

**原则**：不确定时 **先确认路径**（A/B/C/D/E，向导模式同），再用 **具体示例引导用户选择**，不猜测。

#### 2. 充分利用 skill 知识库

本 skill 内置的知识资源，Agent 应主动利用：

| 知识资源 | 位置 | 用途 |
|----------|------|------|
| GB/T 9704 格式标准 | `rules/official/_common.yaml` | 字体/字号/页边距/行距权威依据 |
| 22 种公文类型规范 | `rules/official/*.yaml` + SKILL.md 附录 | 每种公文的检查规则和写作规范 |
| 6 套公文语言风格 | `prompts/style-prompts.md` | 庄重严谨/平实简洁/宏观概括/请示商洽/法规条文/讲话稿 |
| 公文段落骨架模板 | SKILL.md 路径 C | 10 种公文类型的标准结构 |
| 五角色审稿机制 | SKILL.md | 分层把关、人机协同的审稿流程 |
| 九种段落类型优化清单 | SKILL.md 路径 B | 开头/依据/事项/要求等段落的专项检查 |
| 自定义样式模板 | `~/.gongwen-skill/user_rules/*.yaml` | `style-learn` 从标准文档学习的命名模板，**存储于仓库之外，git pull 更新 skill 不会丢失** |

**强制规则**：
- 生成公文时必须引用 `style-prompts.md` 中的风格定义，不得自创风格
- 格式标准以 `_common.yaml` 中的 GB/T 9704 参数为准
- 审稿意见使用五角色机制中的角色定义和规范表述

#### 3. 网络政策信息获取

公文写作常需要引用最新的政策法规、标准文件。Agent 应利用 web 工具获取权威信息：

| 场景 | 应执行的操作 |
|------|------------|
| 用户提到某政策文件但未提供文号 | 用 `web_search` 搜索"文件名称 + 文号/发布机关" |
| 引用 GB/T 国家标准 | 确认标准最新版本号（如 GB/T 9704-2012 是否还有更新） |
| 涉及特定行业术语/规范 | 搜索行业主管部门官网的最新规范 |
| 引用领导人讲话/会议精神 | 标注信息来源，使用 `web_fetch` 确认真实原文 |

**获取规则**：
- 网络获取的信息必须标注来源（URL + 发布时间）
- 优先使用 `.gov.cn` 或官方媒体来源
- 无法确认的信息用 `[待确认]` 标注，不凭空编造
- 引用政策文件时应注明文号和发布日期

#### 4. kdocs 云文档协同（可选增强，结合 kdocs-skill）

当环境中同时安装了 **kdocs-skill**（金山文档 CLI Skill，提供 `kdocs-cli`）时，gongwen-skill 可与云文档联动，弥补本地处理的短板：

| 场景 | kdocs 命令/服务 | 与 gongwen 的衔接 |
|------|----------------|------------------|
| **扫描件 PDF 读取** | `kdocs-cli pdf inspect` / `pdf convert` | 用户提供扫描件 PDF 时，先用 kdocs 提取文字 → 保存为 .docx/.md → gongwen 正常处理 |
| **云端文档读取** | `kdocs-cli drive search-files` / `read_file` | 用户给金山云文档链接时，先下载/导出为本地 .docx → gongwen parse/check/optimize |
| **产物云保存** | `kdocs-cli drive create_file_with_content` / `upload_file` | gongwen 生成的公文成品上传到金山云文档，获取分享链接给用户 |
| **公文转 PDF** | `kdocs-cli pdf convert` | 成品 .docx 转 PDF 用于分发归档 |
| **网页剪藏素材** | `kdocs-cli` workflows/web-scrape | 抓取网页内容作为公文引用的素材来源 |

**协同规则**：
- kdocs-skill 是**可选增强**，未安装时不影响 gongwen 任何本地功能
- 使用 kdocs 前先确认 `kdocs-cli` 可用（`kdocs-cli --help`），不可用则回退为纯本地流程
- kdocs 的 Token 认证遵循 kdocs-skill 自身规范（`kdocs-cli auth`），gongwen 不涉及
- 云端读取的文档必须先落盘为本地 .docx 再进入 gongwen 管线，**不直接跨进程传对象**
- 云端保存成功后必须向用户展示可访问链接

### 强制规则（MUST FOLLOW — 违反即为不合格执行）

以下规则具有最高优先级，Agent 在任何情况下**不得违反**：

#### 规则 1：路径 B 必须使用 optimize-content 命令
- 内容优化任务**必须**使用 `python -m gongwen optimize-content` 命令
- **严禁**自写 Python 脚本直接操作 docx 文件替换段落文本
- **严禁**使用 python-docx 库的 `add_run`/`clear` 方法手动修改段落
- 如果 `optimize-content` 报错或匹配失败，必须排查原因并重试，不得静默切换到自写脚本

#### 规则 2：路径 B 必须产出差异对比文档
- 每次 `optimize-content` 执行必须生成差异对比文档（红色标注+删除线+修改说明）
- 差异对比文档是路径 B 的**唯一交付物**，不得只交付干净版
- 干净版需用户确认差异对比版后，通过路径 A 生成

#### 规则 3：每次任务必须加载 Skill
- 即便是延续上一轮任务，也必须重新调用 Skill 工具加载最新版本
- 加载后必须执行版本自检，确认当前版本号并告知用户

#### 规则 4：处理流程必须可追溯
- 每次执行 skill 命令后，必须在回复中记录：调用了哪个命令、参数是什么、输出文件路径
- 不得省略 skill 命令调用记录，不得只报告最终结果

#### 规则 5：Agent 协作模式（V1/V4）
- **Agent 环境中优先用 `--output-tasks` / `--input-tasks` 协作，不依赖 `GONGWEN_LLM_API`**：
  1. `python -m gongwen optimize-content 文档.docx --changes changes.json --output-tasks tasks.json --apply --mode tracked -t news`
     → Skill 输出待核验实体 + 风格增强请求到 tasks.json，同时生成基础版文档（内容修订+结构/焦点检查批注）
  2. Agent 用自身 LLM+搜索能力处理 tasks.json（核验人事信息、生成风格建议），输出 tasks_result.json
  3. `python -m gongwen optimize-content 文档.docx --changes changes.json --input-tasks tasks_result.json --apply --mode tracked -t news`
     → Skill 读入回填结果（事实核验修正 status=error+auto_fix / 风格建议），合并到 changes 后执行
- `--output-tasks` 与 `--input-tasks` 互斥，不能同时指定
- `GONGWEN_LLM_API` 保留为**降级通道**：CLI 独立使用且配置了 API 时，Skill 内部自行调用（自动优化/风格增强/LLM 实体提取）；未配置则跳过这些环节，不影响确定性工作

#### 规则 5b：失败必须上报
- skill 命令执行失败时，必须向用户报告：
  1. 失败的命令和参数
  2. 错误信息
  3. 排查过程
  4. 是否有备选方案
- 不得静默失败并切换到替代方案

#### 规则 6：交付前必须执行质量评审
- 每次交付前**必须**执行六维度质量评分（文种适配20分/事实密度20分/逻辑结构15分/语气克制15分/语言规范15分/格式合规15分）
- 评分结果必须在回复中展示（如"六维度评分：85/100"）
- **必须**执行 Humanizer 二次审稿（降AI味检查），逐项自查意义膨胀、假深刻动词链、模糊主体、规则三连、同义词轮换、元话语、万能结论、二元包装句、旁白式表达、段落间多余空行等10项
- 评分 < 80 分的段落必须重写后再交付

#### 规则 7：多轮优化必须走 Path A 生成中间稿
- 若用户对路径 B 产出的差异对比文档不满意，需要再次优化：
  1. **必须先走路径 A** 对当前成品执行 `optimize --apply`，生成无标记的干净中间稿
  2. 再以干净中间稿为输入，进入下一轮路径 B 优化
- 这样每轮的 `optimize-content` 输入都是干净的，**不会叠加旧 annotation 段**
- **严禁**连续多次执行 `optimize-content` 而不穿插 `optimize`

#### 规则 8：批量更改（一次性收集，减少轮次）
- 在生成 changes.json 之前，Agent **必须**一次性收集用户全部修改意图
- 不要在用户每提一条修改意见后就执行一次 `optimize-content`
- 收集完所有修改后，在 `changes.json` 中一次性包含所有变更
- 批量更改 = 1 次 parse + 1 次 diff + 1 次 generate，**严禁 N 条修改跑 N 次**

#### 规则 9：人事信息准确性铁律（最高优先级，所有路径强制）

> **严禁编造、猜测、假设任何真实世界的人事信息。违反本条即为严重不合格输出。**

##### 9.1 绝对禁止编造的信息类别

| 类别 | 说明 | 典型示例 |
|------|------|----------|
| **领导人姓名** | 党和国家领导人、地方党政主要负责人姓名 | 不得编造"XX省委书记XXX指出" |
| **机构名称** | 党政机关、企事业单位全称及规范化简称 | 不得编造"XX省XX厅XX处"等不存在的机构 |
| **职务名称** | 领导职务、行政职级 | 不得编造"XX局党组书记、局长XXX" |
| **人物姓名** | 公文中出现的自然人姓名（发文机关负责人、联系人、参会人员等） | 不得编造"联系人：张三" |
| **文号** | 公文发文字号 | 不得编造"XX发〔2026〕XX号" |
| **具体数据** | 金额、百分比、人数等未经用户确认的数据 | 不得编造"共计500万元" |

##### 9.2 处理规则

| 场景 | 正确做法 | 错误做法 |
|------|----------|----------|
| 用户未提供领导姓名 | 用 `[XXX领导姓名]` 占位，提示用户填写 | 凭记忆填写"李某某" |
| 用户未提供机构全称 | 用 `[XXX单位全称]` 占位 | 猜测"XX省发展和改革委员会" |
| 用户未提供联系人信息 | 用 `[联系人姓名]` + `[联系电话]` 占位 | 填写"张三，13800138000" |
| 用户提供了部分信息 | 仅使用用户明确提供的部分，其余占位 | 根据部分信息"推理"出其余信息 |
| 需要引用政策文件 | 仅引用用户提供或搜索确认的文号 | 编造"根据国发〔2026〕XX号文件" |
| 用户说"按常规写" | 追问具体人事信息，不得按"常规"假设 | 假设"常规"的机构名称和领导姓名 |

##### 9.3 唯一例外（合法来源）

以下情况才可以使用真实人事信息：

| 来源 | 条件 | 要求 |
|------|------|------|
| **用户明确提供** | 用户原话中包含该信息 | 直接使用，无需额外标注 |
| **ai_search 搜索确认** | 官方公开信息（.gov.cn 或权威媒体） | 标注来源 URL 和发布时间 |
| **参考文件直接提取** | 用户提供的参考文件中明确记载 | 标注来源段落 |

> **判定标准**：凡是需要"推理""猜测""按常识""按惯例"得出的人事信息，一律禁止直接填写，必须用 `[XXX]` 占位。

##### 9.4 违规自检（所有路径交付前必须执行）

Agent 在交付任何路径产物前，必须扫描全文并自检：

| # | 检查项 | 不合格处理 |
|---|--------|------------|
| 1 | 文档中是否包含用户未提供的领导姓名？ | 替换为 `[XXX领导姓名]` |
| 2 | 文档中是否包含用户未提供的机构全称/简称？ | 替换为 `[XXX单位全称]` |
| 3 | 文档中是否包含用户未提供的人物姓名（联系人、参会人员等）？ | 替换为 `[姓名]` |
| 4 | 文档中是否包含用户未提供或未经搜索确认的文号？ | 替换为 `[XXXX]XX号` |
| 5 | 文档中是否包含用户未提供且未经搜索确认的数据（金额、百分比等）？ | 替换为 `[XXX]` |

> **发现违规时**：必须在交付前修正，并在回复中明确告知用户"发现 N 处编造/未确认的人事信息，已替换为占位符，请您确认补充"。

### 路径产物特征与隔离铁律（最高优先级）

三条路径的产出物有本质区别，**严禁混淆或叠加**。Agent 在任何情况下不得在一个路径的产物中混入另一个路径的特征。

| 路径 | 产物 | diff 标记 | 修改说明 | 颜色标记 | 产出文件命名 |
|------|------|-----------|----------|----------|--------------|
| **A**（格式修复） | 干净成品 | 无 | 无 | 无 | `修订版+{原文档名}+日期+版本号.docx` |
| **B**（内容优化） | 行内修订文档 | 有（红删+红增） | 每段附楷体说明 | 有（#FF0000 红色） | `{原文档名}+{风格}+日期+版本号.docx` |
| **C**（生成公文） | 新公文文档 | 无 | 无 | 无 | `修订版+{公文类型}+日期+版本号.docx` |

**路径 B 的绝对禁令**：
- ❌ 严禁在 `optimize-content` 之后调用 `optimize`——`optimize` 会覆盖 annotation 段的字体/字号/颜色，破坏修订标记
- ❌ 严禁在路径 B 产物中生成无标记「成品版」替代修订版作为交付物
- ✅ 路径 B 的唯一交付物是行内修订文档（红色标注 + 删除线 + 楷体修改说明）
- ✅ 用户确认修订版无误后，可走路径 A 对修订版做格式修复得到无标记成品（此为独立操作，非路径 B 的一部分）

**路径 A 的产物标准**：
- 输出干净文档，无任何 diff 标记、无修改说明、无颜色标记、无 AI 声明
- 仅含格式修复后的正文内容

### 所有路径通用格式基准（GB/T 9704 + 实务规范）

| 元素 | 字体 | 字号 | 对齐/缩进 | 说明 |
|------|------|:----:|-----------|------|
| **公文标题** | 方正小标宋简体 | 22pt（二号） | 居中 | ⚠️ 非宋体，非黑体 |
| **一级标题**（一、二、三） | 黑体 | 16pt（三号） | 顶格，两端对齐 | 国标黑体 |
| **二级标题**（（一）（二）） | 楷体_GB2312 / 华文楷体 | 16pt（三号） | 首行缩进2字符 | 议题材料中常用华文楷体 |
| **三级标题**（1. 2.） | 仿宋_GB2312 **加粗** | 16pt（三号） | 首行缩进2字符 | |
| **四级标题**（（1）（2）） | 仿宋_GB2312 | 16pt（三号） | 首行缩进2字符 | |
| **正文** | 仿宋_GB2312 | 16pt（三号） | 首行缩进2字符，两端对齐 | 主送/称谓也用此字体 |
| **一是/二是/三是等内容** | 楷体_GB2312 **加粗** | 16pt（三号） | 首行缩进2字符 | 汇报材料/议题材料高频写法，预留给核心结论 |
| **汇报单位/落款** | 华文楷体 | 16pt（三号） | 居中 | 位于标题与正文之间 / 正文末尾 |
| **日期** | 仿宋_GB2312 | 16pt（三号） | 右对齐，右空四字 | |
| **会议材料题头** | 楷体_GB2312 **加粗** | 16pt（三号） | 左对齐 | `[单位]党组20XX年第X次会议材料议题之X` |
| **西文/数字** | Times New Roman | 与所在位置中文字号一致 | — | 仅用于阿拉伯数字和英文字母，不影响中文字体。字号与所在位置的中文字体一致（正文字号为16pt即三号） |
| **页边距** | — | — | 上2.8cm / 下2.8cm / 左2.7cm / 右2.7cm | A4纸，版心156×225mm |
| **行距** | — | — | 33磅固定值 | 每面22行，每行28字 |

### 段首短句加粗 vs 独立小标题（高频易混淆，必读）

汇报材料、调研报告、工作小结中，两种格式很容易混淆，但用途和格式完全不同：

| 对比项 | ① 独立小标题 | ② 段首短句加粗（领句） |
|--------|-------------|---------------------|
| **位置** | 独立成行，上下有空行 | 嵌在段落开头，不换行 |
| **末尾标点** | 不写句号 | 使用句号（不是逗号） |
| **格式** | 黑体 / 楷体，加粗或不加粗均可 | 仿宋_GB2312 **加粗**，后面接正文 |
| **作用** | 划分章节结构 | 把本段核心结论前置，方便快速抓取重点 |
| **适用范围** | 所有文种 | 汇报稿、调研报告、讲话稿、简报大量使用；极正式上行请示/通知正文较少使用 |

**示例对比**：

```
❌ 错误写法（小标题和领句混用）：
（一）加快平台迭代完善
加快平台迭代完善。紧扣运动会赛时运行需求，持续优化平台功能模块。

✅ 正确写法（二选一，全篇统一）：

写法A — 独立小标题（章节式）：
（一）加快平台迭代完善
　　紧扣运动会赛时运行需求，持续优化平台功能模块，完成系统压力测试、安全测评与实操演练。

写法B — 段首加粗领句（汇报式）：
加快平台迭代完善。紧扣运动会赛时运行需求，持续优化平台功能模块，完成系统压力测试、安全测评与实操演练。
```

**实操规范**：
- 领句尽量控制在 **15 字以内**，简洁动宾短语
- 末尾统一使用**句号**，不要逗号
- 全篇格式统一：**要么全部用小标题，要么全部用领句，不可一段加粗一段不加**
- **禁止大面积整段加粗**，只加粗开头主旨短句
- GB/T 9704 国标没有强制规定这种加粗格式，属于**机关通行排版惯例**

### 文件命名规范（全部路径通用）

输出文件名必须包含风格/类型标识、日期和版本号，让用户一眼区分产物类型和版本：

| 路径 | 命名格式 | 示例 |
|------|----------|------|
| A（格式修复） | `修订版+{原文档名}+日期+版本号.docx` | `修订版+关于XX的通知+2026-07-25+v1.docx` |
| B（内容优化） | `{原文档名}+内容风格+日期+版本号.docx` | `关于XX的通知+庄重严谨+2026-07-25+v1.docx` |
| C（生成公文） | `修订版+{公文类型}-模板+日期+版本号.docx` | `修订版+通知-模板+2026-07-25+v1.docx` |

规则说明：
- 原文档名不含扩展名
- 日期格式：YYYY-MM-DD（执行当天）
- 版本号从 v1 起始，同一文档同一天多次生成则递增（v2 / v3）
- 内容风格：从 修订内容 的 `style` 字段提取，多个段落取出现最多的标签
- 不允许使用无信息量命名（如 `成品.docx`、`v5.docx`）

---

## 质量评审与持续优化框架（所有路径通用）

**以下框架适用于全部三条路径。每条路径的每轮输出在交付前都必须经过质量评审。**

### 一、六维度质量评分（每轮交付前自检）

| 维度 | 分值 | 检查内容 |
|------|:----:|---------|
| **文种适配** | 20 | 文种选得对不对（请示不是报告、函不是通知）、结构准不准、结语是否匹配 |
| **事实密度** | 20 | 有人物、动作、机制、数据或案例，不空泛（不出现"等"收尾的无内容项） |
| **逻辑结构** | 15 | 段落功能明确（开头/依据/事项/要求），推进自然，不机械排比 |
| **语气克制** | 15 | 判断强度与证据匹配（"取得明显成效"须有数据支撑，"重大突破"须有权威认定） |
| **语言规范** | 15 | 术语准确，无 AI 味表达（二元包装句/万能结论/元话语/规则三连） |
| **格式合规** | 15 | GB/T 9704 行距/字体/缩进/层级序号/附件说明 |

**评分处理规则**：
- 90 分以上 → 可直接输出
- 80-89 分 → 局部压缩套话并增强具体性
- 70-79 分 → 重写问题段落
- 70 分以下 → 按文种结构整体重构

### 二、Humanizer 二次审稿（降 AI 味检查清单）

每次生成后逐项自查，**以下列出一处修一处**：

| 问题类型 | 典型表现 | 修正方向 |
|----------|---------|---------|
| **意义膨胀** | 普通事项写成"重要里程碑""充分彰显""重大突破" | 改为具体任务、结果或依据 |
| **假深刻动词链** | "推动、促进、助力、强化、彰显"连续堆砌 | 保留一个主动作，补对象和流程 |
| **模糊主体** | "相关部门""有关方面"无责任对象 | 写清来源、责任单位或反馈渠道 |
| **规则三连** | 所有段落强行三点并列，内容实际凑数 | 按实际任务数量分条，不强凑三点 |
| **同义词轮换** | 避免重复而把同一主体反复换称呼（市局→我局→主管单位） | 重复最准确的主体名称 |
| **元话语** | "下面从三个方面展开""接下来我们来看" | 删除，直接进入正文 |
| **万能结论** | "谱写新篇章""再上新台阶""作出更大贡献" | 回到责任、时限、报送和下一步 |
| **二元包装句** | "不仅…更…""既是…也是…""既…又…"多组嵌套 | 只保留必要的一层，其余拆为陈述 |
| **旁白式表达** | "值得注意的是""需要强调的是""毋庸置疑" | 直接陈述事实，删除引导框 |
| **段落间多余空行** | 每段之间均插入空行，结构转换处与非转换处无差别 | 删除非结构转换处的空行。保留标题与正文之间、落款前的结构空行，删除正文连续段落之间的多余空行 |

### 三、要素分层体系

每类公文的结构要素按如下优先级分层，**不得无脑堆砌**：

| 层级 | 说明 | 示例（通知） |
|------|------|-------------|
| **①必备** | 缺失即不合格 | 主送机关、事项、要求、时限 |
| **②常见** | 通常应有，视情况或可省略 | 依据、联系人、抄送 |
| **③条件项** | 仅在特定条件下出现 | 附件说明、经费预算、保密提示 |
| **④单位样式** | 本单位特有的模板格式 | 红头样式、发文编号格式、审核栏 |
| **⑤自定义** | 用户额外要求的补充要素 | 背景材料链接、术语解释 |

### 四、持续优化需求适配（处理人为审核意见）

用户对生成内容进行人为审核后，往往给出简短、模糊的修改意见（如"理顺一下内容""这段有点乱""感觉不对""再调调"）。应按下述流程处理：

```
用户意见
   ↓
第1步：意见分类
  ├─ "理顺内容/理顺逻辑/这段有点乱"
  │   → 结构问题：检查段落功能是否明确、论点论据是否脱节、是否有跳跃
  ├─ "太啰嗦/再精简/太长了"
  │   → 冗余问题：检查套话、重复表达、三元包装、可省略的修饰语
  ├─ "力度不够/太软了/再强硬点"
  │   → 语气问题：检查措辞强度、缺少"须""应""不得"等强制动词
  ├─ "感觉不对/再改改"
  │   → 综合问题：先检查文种→再检查事实→再检查结构→再检查语气
  └─ 具体意见（直接指出某处问题）
      → 针对该处精准修改，不改无关内容

第2步：精准定位
  - 用户说全段"太乱" → 问"是这一整段方向不对，还是内部顺序有问题？"
  - 用户说"再调调" → 追问"具体哪部分不满意？（开头/中间/结尾/语气/篇幅）"
  - 有上下文关联时，确认修改范围不波及已确认的其他段落

第3步：实施修改（走对应路径）
  ├─ 结构问题 → 回到路径 C 第一步：重写 Markdown 草稿，确认后再生成
  ├─ 内容优化 → 走路径 B：optimize-content 做行内修订（红色标注变更）
  ├─ 语气/措辞调整 → 走路径 B：optimize-content，提供具体的 background/context/perspective
  └─ 格式问题 → 走路径 A：optimize，不做内容修改

第4步：验证交付
  - 展示修改前后对比（变更摘要）
  - 标注与路径 B 时，明确哪些文字被改、修改理由
  - 问"是否还有需要调整的地方？"（最多 3 轮迭代后建议定稿）
```

**常见模糊意见映射表**：

| 用户原话 | 实际含义 | 应走路径 | 操作要点 |
|----------|---------|---------|---------|
| "理顺一下内容" | 逻辑不连贯、段间跳跃 | 路径 C 重写 | 先出提纲确认，再逐段生成 |
| "这段有点乱" | 段落内论据顺序不当 | 路径 B optimize-content | 在该段后附【修改说明】说明重组理由 |
| "太啰嗦了" | 套话/重复/空泛 | 路径 B optimize-content | 逐句压缩，标注删除内容 |
| "再改改" | 不满意但说不清问题 | 综合 | 先追问具体方向，不做盲目修改 |
| "力度不够" | 缺少强制性动词 | 路径 B optimize-content | 补充"须""应""不得"，收紧措辞 |
| "差不多，再微调" | 大方向OK，局部优化 | 路径 B optimize-content | 只改具体指出的段落，不动其他 |

### 五、五角色审稿机制（分层把关 / 人机协同）

> **核心设计思路**：分层把关、权责清晰、人机协同、闭环留痕，杜绝一人包干、错漏无人兜底的局面。

#### 5.1 审稿角色设置

| 角色 | 责任主体 | 审稿侧重点 | 硬性要求 |
|------|---------|-----------|---------|
| **①撰稿人**（第一责任人） | 起草人 | 业务事实准确、数据来源可靠、逻辑通顺、覆盖完整 | 未经自审不得流转下一环节 |
| **②业务审核人** | 处室/部门负责人 | 业务口径、事实真实、权责分工、工作可行性 | 对业务表述和分工边界负责 |
| **③文字校对岗** | 综合岗（可配合 gongwen-skill） | 错别字/标点/语病、序号规范、术语统一、格式合规 | 先运行 skill 自动化预检，再人工复核 |
| **④综合核稿人** | 综合办/专班负责人 | 政策口径、全局逻辑、风险排查、行文基调 | 重大表述和敏感措辞必须审核 |
| **⑤签发领导**（终审定稿人） | 分管领导 | 核心观点确认、重大工作安排、是否同意印发/报送 | 签字或线上确认定稿 |

#### 5.2 角色职责详解

**①撰稿人（初稿责任人｜第一责任人）**
- 根据工作要求起草文稿，保证内容贴合业务事实、数据准确、逻辑通顺
- 完成自审自查：基础错别字、语病、事实错误、上下文冲突
- 对照写作提纲，核查是否完整覆盖全部工作要点
- 输出初稿，附带写作说明、数据来源，提交审稿流程

**②业务审核人（业务处室 / 部门负责人）**
- 审核文稿内业务表述、分工边界、项目信息、需求内容、数据真实性
- 核查职责划分、工作安排是否符合现行工作机制
- 修正业务口径偏差，确认业务目标和工作举措具备可行性

**③文字校对岗（文稿编审 / 综合岗，可搭配 gongwen-skill 工具）**
- **文字校对**：错别字、标点、语病、口语化表述、语句歧义
- **公文规范校对**：序号规范（一、（一）1.（1））、专有名词统一、格式合规
- **排版格式校验**：红头法定公文执行 GB/T 9704，汇报/方案材料执行单位统一排版惯例
- **人机协同**：先用 gongwen-skill 自动化扫描格式和用语问题，再人工复核

**④综合核稿人（综合办 / 专班综合负责人）**
- 对标上级政策，核查文稿站位、提法是否合规
- 统筹跨部门表述，避免说法冲突
- 审核文稿结构和层次逻辑，重大表述和敏感措辞风险排查
- 把控文稿篇幅和行文基调，判断是否符合呈报场景

**⑤签发领导（最终审定人）**
- 审定文稿核心观点、重大工作安排
- 确认是否同意对外报送、印发
- 作出终审修改意见，确认定稿

#### 5.3 两套审稿方案

| 方案 | 角色数 | 流程 | 适用场景 |
|------|:------:|------|---------|
| **A（完整版）** | 5 | 撰稿人→业务审核→文字校对→综合核稿→领导签发 | 正式对外发文、红头公文、重大课题汇报 |
| **B（精简版）** | 3 | 撰稿人（自审）→业务+文字复合审核→综合负责人终审 | 内部交流材料、阶段性工作汇报 |

#### 5.4 配套关键机制

- **修改留痕机制**：统一使用修订模式，所有修改标注修改人和修改原因；禁止直接覆盖原文
- **意见闭环机制**：每轮审稿意见必须逐条反馈——采纳/不采纳（写明理由），无反馈不得流转下一环节
- **分级审稿规则**：红头法定公文（请示、函、通知）走完整版流程；内部汇报、实施方案可走精简版
- **工具嵌入机制**：所有文稿提交文字校对环节前，强制先用 gongwen-skill 执行自动化预检（格式校验、用语规范扫描）
- **差错追责机制**：低级文字错误由文字校对岗兜底；业务事实/分工错误由业务审核人负责；重大政策表述问题由综合核稿把关

#### 5.5 流转示例（贴合课题汇报文稿场景）

```
撰稿人撰写课题汇报初稿
  → 信息技术部负责人（业务审核：核对项目、职责内容）
  → 综合岗文字校对（gongwen-skill 预检 + 人工润色、格式规范）
  → 筹委会综合专班核稿
  → 分管领导终审签发
```

---

### 合规自检清单（交付前必须执行）

Agent 在交付任何文档前，必须逐项检查并在回复中汇报：

| # | 检查项 | 合格标准 |
|---|--------|----------|
| 1 | Skill 加载 | 是否调用了 Skill 工具？版本号是多少？ |
| 2 | 路径判定 | 根据用户需求判定为哪条路径？判定依据是什么？ |
| 3 | 命令调用 | 实际调用了哪些 skill 命令？列出完整命令行 |
| 4 | 是否绕过 | 是否使用了自写脚本替代 skill 命令？如有，说明原因 |
| 5 | 交付物 | 产出了哪些文件？是否符合该路径的产物规范？ |
| 6 | 质量验证 | 是否运行了 check 命令？结果如何？ |

汇报格式：

```
📋 合规自检报告
Skill 版本: 填写当前版本号（运行 python -m gongwen --version）
路径判定: B（内容优化）
依据: 用户说"优化第二章节"且指定了已有文档
命令调用: 1. python -m gongwen optimize-content input.docx --changes changes.json --apply
是否绕过: 否
交付物: 关于XX的通知+庄重严谨+2026-07-29+v1.docx（差异对比版）
质量验证: check 通过，剩余 6 项已知误报
```

---

## 路径 A：格式修复

**不改内容，只修排版。** 输出无标记的成品文档。

> ⚠️ **执行前检查清单（必须逐项确认，缺一不可）：**
> - □ 用户有现成 .docx 文档
> - □ 用户仅需修排版格式，不改文字内容
> - □ 已确认文档类型（-t 参数）
> - □ 已告知用户：路径 A 产出无标记成品，**不保留修改痕迹**

### 完整流程

```bash
# 三步走
python -m gongwen check 文件.docx -t <类型>         # 第1步：检查问题（只读）
python -m gongwen optimize 文件.docx -o 成品.docx -t <类型> -y  # 第2步：修复（-y 跳过确认）
python -m gongwen check 成品.docx -t <类型> --json    # 第3步：验证
```

### 检查结果分级

| 级别 | 含义 | 处理 |
|------|------|------|
| P0 | 必须修复（字体/字号/页边距不符国标） | `optimize` 自动修 |
| P1 | 建议修复（缩进/对齐问题） | `optimize` 自动修 |
| P2 | 可选修复（多余空行等） | `optimize` 自动修 |

### 可选增强

```bash
# 注入版头版记页码
python -m gongwen optimize 文件.docx -o 成品.docx --layout 版式.json

# 单独补版式要素
python -m gongwen header 文件.docx --org-name 单位全称 --doc-number "发文编号"
python -m gongwen footer 文件.docx --cc 抄送单位 --printer 印发单位 --print-date 印发日期
python -m gongwen pagenum 文件.docx --alignment center
```

---

## 路径 D：一键格式修复（fix-common）

**快速规范化常见格式问题，一步到位。** 使用 `fix-common` 命令，输出**不含 AI 声明段**的干净文档。

> ⚠️ **执行前检查清单（必须逐项确认，缺一不可）：**
> - □ 用户有现成 .docx 文档
> - □ 用户只需快速规范常见格式问题（段落类型/编号拆分/首句加粗/加粗范围）
> - □ 已告知用户：路径 D 产出不含 AI 声明段的干净文档
> - □ 若文档可能含修订标记（tracked changes），路径 D 会自动接受全部修订（P3）

### 命令

```bash
python -m gongwen fix-common 文件.docx -o 成品.docx
```

7 步修复流程（内部自动执行）：
1. **解析文档**
2. **清理路径B标记**（修改说明段落/删除线标记）
3. **段落类型检测与格式修正**：称呼段左对齐无缩进、导语/过渡段不加粗、会议日期段居中 18pt、署名段居中 18pt（P4/P5/P8）
4. **编号段落自动拆分**：同一段内"一是…二是…三是…"拆分为独立段落（P6）
5. **首句加粗（段落类型感知）**：仅编号正文/普通正文加粗，称呼/导语/过渡/署名/会议日期不加粗（P2）
6. **加粗范围修复**（fix_bold_range）
7. **生成文档**（no_ai_declaration=True，不含 AI 声明段）

### 与路径 A 的区别

| 维度 | 路径 A（optimize） | 路径 D（fix-common） |
|------|-------------------|---------------------|
| 修复引擎 | 规则引擎（check_rules/fix_rules） | modifier 独立修复逻辑 |
| AI 声明段 | 默认追加 | 不追加 |
| 适用场景 | 完整格式合规（含页边距/字体检查） | 快速规范化常见问题 |

### OOXML 编辑规范（P7，所有路径强制）

- **严禁使用 PowerShell 操作 docx 的 XML**（`System.IO.Compression` / `[xml]` 解析等不可靠，P7 已证实）
- 所有 .docx 的解析/修改/生成**必须走 Python 代码路径**（`engine/core/document/*` 或 `python -m gongwen` 子命令）
- 需编辑 OOXML 层时使用 Python `python-docx` + `lxml`（项目内 `engine/core/document/generator.py` 的 `_accept_all_revisions` 即为参考实现）
- 违反此规范的操作视为不合格执行

### AI 声明段控制

默认所有生成文档末尾会追加 AI 声明段（"（内容由GongWen-skill-AI生成，仅供参考）"，楷体 9pt 居中，pStyle=Annotation 避免 check 误判）。以下参数可控制：

| 命令 | 参数 | 效果 |
|------|------|------|
| `md2docx` | `--no-ai-declaration` | 生成的文档不追加 AI 声明段 |
| `optimize` | `--remove-ai-declaration` | 修复输出的文档不追加 AI 声明段 |
| `fix-common` | （内置） | 固定不追加 AI 声明段 |

---

## 附录：全部命令速查（29 个，按用途分组）

> Agent 遇到用户需求时，先在此表定位对应命令；命令用法不明确时运行 `python -m gongwen <命令> --help` 查看完整参数。

### 🧭 向导式交互

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `wizard` | 交互式路径引导（A/B/C/D/E）+ 一键执行；Agent 用 `--answers` 非交互 / `--dry-run` 只打印命令 | `python -m gongwen wizard` |

### 🏗️ 生成与模板

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `list-types` | 列出 25 种支持的公文类型 | `python -m gongwen list-types` |
| `template` | 按类型生成 GB/T 9704 空白模板 | `python -m gongwen template notice -o 通知.docx` |
| `generate` | 从 DocumentModel JSON 生成 .docx | `python -m gongwen generate 模型.json -o 公文.docx` |
| `md2docx` | Markdown 草稿 → 格式化公文（初稿） | `python -m gongwen md2docx 草稿.md -o 公文.docx -t notice` |
| `draft` | Markdown 草稿 → 国标成品 + 验证（路径 C 四步合一） | `python -m gongwen draft 草稿.md -o 成品.docx -t notice` |
| `style-learn` | 从标准文档学习排版样式生成模板 | `python -m gongwen style-learn 标准.docx -n 模板名` |
| `style-list` | 列出已学习的自定义样式模板 | `python -m gongwen style-list` |

### 🔍 解析与检查

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `parse` | .docx → 结构化 DocumentModel JSON | `python -m gongwen parse 公文.docx` |
| `check` | 按国标检查格式（只读，分级 P0/P1/P2） | `python -m gongwen check 公文.docx -t notice` |
| `audit` | 审计文档：检查删除线/加粗/AI 声明等痕迹 | `python -m gongwen audit 公文.docx` |

### 🔧 修复与优化

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `optimize` | 检查+修复+生成（默认预览，--apply 执行；`--verify` 单命令闭环自动复查输出、P0 存在时退出码非 0；`--json` 结构化输出） | `python -m gongwen optimize 公文.docx -o 成品.docx --apply --verify` |
| `fix-common` | 一键修复常见格式问题（路径 D） | `python -m gongwen fix-common 公文.docx -o 成品.docx` |
| `optimize-content` | 内容优化：修订+批注对比版（路径 B；`--precheck` 预检 changes 与原文一致性、`--preset quick/full/review` 参数收敛） | `python -m gongwen optimize-content 原文.docx --changes 修订.json --apply --preset full` |
| `full-review` | 完整审校：格式修复→内容优化→批注，一条命令 | `python -m gongwen full-review 公文.docx -o 成品.docx` |
| `bold-first` | 正文段落首句加粗（公文规范） | `python -m gongwen bold-first 公文.docx -o 成品.docx` |

### 📄 版式注入

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `header` | 注入版头：机关标志+发文字号+签发人+红色反线 | `python -m gongwen header 公文.docx --org-name "XX单位"` |
| `footer` | 注入版记：抄送+印发机关+印发日期+分隔线 | `python -m gongwen footer 公文.docx --cc "各单位"` |
| `pagenum` | 注入 Word PAGE 域动态页码 | `python -m gongwen pagenum 公文.docx --alignment right` |

### 🧰 特殊工具

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `table-signs` | 从名单批量生成会议桌签 | `python -m gongwen table-signs 名单.txt -o 桌签.docx` |
| `review` | 生成公文审稿流转单（五/三角色） | `python -m gongwen review report -o 审稿单.docx` |
| `handoff` | 跨会话交接（长任务收尾必写） | `python -m gongwen handoff --write` |
| `check-update` | 版本自检（PyPI pip 包权威 + GitHub 备用，自动检测安装形态；GitHub 不可达时 DNS 诊断） | `python -m gongwen check-update` |
| `font` | 公文标准字体管理（安装/检查/列出；下载失败时自动安全 DNS 直连兜底） | `python -m gongwen font install` |

### 🩺 诊断与修复

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `doctor` | 全面诊断：检查 Python 版本/依赖/版本一致性/字体/DSH 文件/代码风格/网络 DNS 等 | `python -m gongwen doctor` |
| `doctor --json` | JSON 结构化输出（便于 Agent 解析） | `python -m gongwen doctor --json` |
| `doctor --offline` | 跳过网络/DNS 诊断（离线模式） | `python -m gongwen doctor --offline` |
| `repair` | 修复常见问题：安装缺失依赖/字体/同步 SKILL.md 副本 | `python -m gongwen repair` |

### ⚙️ 规则管理

| 命令 | 用途 | 最小用法 |
|------|------|---------|
| `rule-export` | 导出合并后的规则 YAML | `python -m gongwen rule-export -o 规则.yaml` |
| `rule-list` | 列出三层规则（官方/单位/用户） | `python -m gongwen rule-list` |
| `rule-import` | 导入/保存自定义规则 YAML | `python -m gongwen rule-import 规则.yaml` |

若文档中已存在 AI 声明段，`generate_docx` 会先**去重**（保留最后一段）再统一格式；未传上述参数时默认行为不变（保留 AI 声明段），向后兼容。

---

## 路径 B：内容优化

**润色文字，保留格式。** 使用 `optimize-content` 命令做行内修订，输出带红色标注+删除线的修改文档。

> ⚠️ **执行前检查清单（必须逐项确认，缺一不可）：**
> - □ 用户有现成文档需要优化文字内容
> - □ 已确认用户要改的是**文字措辞**（而非排版格式）
> - □ 已确认内容优化方向（background/context/perspective）
> - □ 已告知用户：路径 B 产出**红色标注+删除线+楷体说明**的对比版
> - □ 用户确认内容后自动转路径 A 修格式，**无需额外询问**

### 完整流程

```
第0步：确认背景/语境/角度（提供 background/context/perspective）
第0.5步：文本匹配预检（必须执行，严禁跳过）
      **必须**先用 python-docx 逐段读取文档实际文本，将每段的
      para.text 写入临时对照表，然后逐条验证 changes.json 中的
      original_text 与此对照表完全一致（包括空格、标点、全半角）。
      只有验证通过后的 JSON 才能传给 optimize-content。
      特别注意：经过 bold-first 处理的段落可能被拆分 run，
      但 para.text 仍是完整文本，应直接使用 para.text 的值。
      严禁凭记忆或脑记直接写 original_text。

      **JSON 生成规范**（P5，避免 PowerShell 编码问题）：
      - 必须使用 Python `json.dump()` 直接写出 JSON 文件，禁止在 PowerShell 中内嵌含特殊字符的字符串
      - 推荐方式：
        ```python
        import json, pathlib
        pathlib.Path("changes.json").write_text(json.dumps(changes, ensure_ascii=False, indent=2), encoding="utf-8")
        ```
      - 生成后必须删除 optimized_text == original_text 的零修改条目（skill 端也会预检过滤，但应源头避免）
      - 每条 change 必须含 paragraph_index(int)/original_text/optimized_text/reason 四个必填字段

      **背景与视角**（P1/P2）：确认背景后**必须**将背景信息以 `--background` 传入
      （背景描述写入 `.temp/background.txt` 后传文件路径），并**必须**传入
      `--perspective "..."`（优化视角/风格方向，如"务实客观，数据驱动，避免主观评价和万能结论"）

第1步：LLM 逐段分析 → 确认修订后的文本内容
第2步：python -m gongwen optimize-content 原文.docx -o 修订版.docx -f 修订后.md --background ".temp/background.txt" --perspective "..."
      → 行内修订文档（自动继承原文档格式 + 红色标注 + 删除线 + 楷体修改说明）

第3步：产出验证（P3，强制步骤，严禁跳过）
      **必须**对产出文件执行格式合规验证：
      ```bash
      python -m gongwen check "产出文件.docx" -t <doc_type> --json
      ```
      - check 含 ERROR 级别问题 → 交付时向用户报告
      - check 含 WARNING 级别问题 → 交付时附注提醒
```

**路径 B 到此结束。** 行内修订文档即为最终交付物。

用户确认优化内容后，即代表同意进入**路径 A** 做格式合规修复，Agent 直接执行 `check → optimize → check` 生成无标记成品文档，**无需额外询问**。

---

### 路径 B / 第0步：读取原文档格式

在生成 修订内容 前，读取原文档的格式属性，作为 LLM 优化文本时的参考约束。

```python
import docx
doc = docx.Document("原文档.docx")
# 读取：每段字体/字号/行距/缩进/对齐方式
# 读取：页边距
```

这些数据仅供 LLM 参考，`optimize-content` 内部会自动从原文档继承格式，Agent 无需手动传递。

---

### 路径 B / 第1步：变更 JSON 格式

`修订内容` 格式：

```json
{
  "changes": [
    {
      "paragraph_index": 5,
      "original_text": "原段落文字",
      "optimized_text": "经审稿合成后的最终文字",
      "reason": "【撰稿人自审】事实准确，建议精简过渡句；【业务审核】业务口径无误；【文字校对】'抓紧'→'尽快'",
      "style": "庄重严谨",
      "reference": "《党政机关公文处理工作条例》第三章: 公文用语应准确、简洁、庄重、规范"
    }
  ]
}
```

**字段分工（各司其职，不可混同）**：

| 字段 | 职责 | 示例 |
|------|------|------|
| `optimized_text` | **五位审稿角色意见合成后的最终可用内容**，直接用于替换原文生成对比文档 | 见上方示例 |
| `reason` | **各审稿角色的修改意见**，用【角色名】标注来源 | 【撰稿人自审】事实准确，建议精简过渡句；【文字校对】'抓紧'→'尽快' |
| `style` | **行文风格定性标签**，一个段落一个标签即可 | 庄重严谨 / 简洁明快 / 条理清晰 |
| `reference` | **公文写作规范依据**，先定位段落类型再引用该类文段写作规范 | 公文"汇报导语"部分写作规范——开头点明事由与依据，属地全称不可省略 |

> **reference 字段引用规范（严禁虚构）**：
> - 引用内容**必须**是真实可查证的标准或文件（GB/T 9704、《党政机关公文处理工作条例》、`style-prompts.md` 中的风格定义等）
> - **严禁**使用"公文'主持词'写作规范""公文'讲话稿'写作规范"等不存在的标准名称
> - 无法引用具体标准时，可标注为"机关通行惯例"或"公文实务规范"，不得编造标准名称

> **注意**：`optimized_text` 是五角色审稿意见全部合成后的 **唯一最终版本**。`reason` 字段**必须**包含全部五个审稿角色的意见，即使某角色对该段落无修改建议，也应标注"【业务审核】无意见"或"【综合核稿】通过"，**不得省略任一角色**（除非使用了精简版3角色方案）。

---

### 路径 B / 对话审稿模式（LiveEdit：一次解析，多次优化，一次生成）

**核心设计**：审稿是一个完整机制流程，不应每段打断用户。Agent 一次性完成全文审稿分析，生成所有优化建议的汇总清单，交给用户一次性确认。

**适用场景**：用户希望完整走审稿流程优化文档，但不想反复文件 I/O，且不希望每段都被询问。

**核心流程**：只解析一次 → 内存中累积五角色审稿意见 → 一次性输出来源对比汇总 → 用户一次性确认 → 最后一次性生成成品。

```
第1步：Agent 执行 python 代码——parse_docx 原文，创建 LiveEditSession
第2步：LLM 对全文逐段执行五角色审稿分析，生成完整 changes 清单（内存中）
第3步：Agent 在对话中展示「审稿汇总报告」——列出所有段落的原文→优化对比
第4步：用户一次性确认：「同意全部修改」或「驳回/修改某条」
第5步：用户确认无更多优化后，调用 session.finalize_both("关于XX的通知", style="庄重严谨", version=1)
      → 自动生成两份文档（遵循 SKILL.md 文件命名规范）：
        - 干净版（路径 A 规则）：`修订版+关于XX的通知+2026-07-29+v1.docx`
        - 差异对比版（路径 B 规则）：`关于XX的通知+庄重严谨+2026-07-29+v1.docx`
      → 同时保存 .changes.json 变更日志供后续参考
```

**对话审稿示例（完整汇总输出，用户一次性确认）：**

```
Agent: 📋 审稿汇总报告
       ═══════════════════════════════════════
       原文：关于召开2026年网络安全工作会议的通知（30段）
       类型：notice
       审稿方案：完整版（5角色）
       ───────────────────────────────────────
       ✅ 段落 1：「主送机关」
          【撰稿人自审】事实准确，无需修改
          
       ✅ 段落 5：「会议时间」
          【业务审核】建议补充会议时长
          原文：2026年8月15日上午9时
          优化：2026年8月15日上午9时，会期半天
          
       ✅ 段落 12：「参会人员」
          【文字校对】"信息中心"→"信息技术部"，统一全文称谓
          
       ✅ 段落 28：「落款」
          【综合核稿】落款单位应使用全称
          原文：局办公室
          优化：XX省民族宗教事务委员会办公室
          
       ═══════════════════════════════════════
       共 6 处修改建议。是否全部同意？[Y / n（逐条讨论）]
```

**对话审稿与文件模式的对比：**

| 对比项 | optimize-content（文件模式） | LiveEdit（对话模式） |
|--------|---------------------------|---------------------|
| 输入 | changes.json 文件 | LLM 逐段分析，内存中积累 |
| 解析次数 | 每次修改都 parse → generate | 一次 parse，多次编辑，一次 generate |
| 用户确认 | 一次性确认全部变更 | 一次性确认「审稿汇总报告」|
| 审稿呈现 | reason 字段写在 JSON 中 | 在对话中以审稿汇总报告呈现 |
| 适用场景 | 一次性批量优化 | 完整审稿流程优化 |

**Agent 实施规则：**

1. 确定用户要走审稿流程后，构造 `LiveEditSession` 并进入 `with` 块
2. **不逐段询问用户**，而是完成全部审稿分析后，输出一份完整的「审稿汇总报告」
3. 汇总报告按段落列出：原文、优化文本、审稿意见（含角色名）
4. 询问用户是否全部同意。若用户有异议，再针对具体段落讨论
5. 用户确认后调用 `session.finalize("成品.docx")` 输出
6. 将生成的 `.changes.json` 路径告知用户，供后续参考

### 路径 B / 增强命令（新增）

路径 B 提供两种增强输出模式，Agent 应根据用户需求选用：

#### 批注模式（--comment-mode）

将优化建议以 **Word 原生批注** 写入，用户在 Word 中可通过「审阅 → 接受/拒绝」逐条处理，而非行内标记：

```bash
python -m gongwen optimize-content 原文.docx --changes changes.json --apply --comment-mode
```

- 批注按字符范围锚定（可精确定位到被修改文字）
- 五角色审稿时，批注作者名区分五种角色，可按审阅者筛选
- 兼容：不加 `--comment-mode` 时保持原行内标记模式

#### 修订追踪（--tracked-change）

将修改以 Word 原生修订标记（`<w:ins>`/`<w:del>`）写入，用户可在「审阅 → 修订」面板逐条接受/拒绝：

```bash
python -m gongwen optimize-content 原文.docx --changes changes.json --apply --tracked-change
```

- 修订 ID 全局唯一、RSID 无冲突
- 保留原 run 字体格式，修订不损毁排版

#### 完整审校（full-review）

一条命令完成「格式修复（路径 A）→ 内容优化（路径 B）→ 批注输出」：

```bash
python -m gongwen full-review 原文.docx --changes changes.json -o 审校版.docx
```

#### 样式学习（style-learn / style-list）

上传标准文档，学习其排版样式（含字间距等细微属性），生成自定义命名模板：

```bash
python -m gongwen style-learn 单位定稿红头.docx -n 民委红头规范   # 学习并注册模板
python -m gongwen style-list                                     # 列出已学习模板
python -m gongwen optimize 文档.docx -t 民委红头规范 --apply      # 套用模板
```

模板存储于 `~/.gongwen-skill/user_rules/`（仓库之外），**git pull 更新 skill 不会丢失**。

#### 文档审计（audit）

对文档处理链进行系统级审计，输出问题清单（含严重级别与位置）：

```bash
python -m gongwen audit 原文.docx -t notice
```

- **检查维度**（与实现一致）：格式合规（删除线 val=false 伏笔、bold-first 整段加粗误判、AI 声明残留、修订标记残留）+ 结构统计（段落/run 数）
- 输出 P0（阻断）/P1（重要）/P2（次要）分级问题列表
- **与 `check` 的区别**：audit 检查文档处理链痕迹（删除线/加粗/修订残留等过程产物问题），check 检查版面格式合规；五维度内容审稿由路径 B 审稿机制承担

#### 三种输出模式对照（路径 B）

路径 B 的 `optimize-content` 支持四种交付模式，Agent 按用户需求选用：

| 模式 | 参数 | 交付物 | 用户操作 |
|------|------|--------|---------|
| **行内标记**（默认） | （无） | 灰色删除线 + 红色新增 + 楷体修改说明 | 直接查看，人工誊改 |
| **批注模式** | `--comment-mode` | Word 原生批注（字符级锚定，可精确到被修改文字） | 「审阅→接受/拒绝」逐条处理 |
| **修订追踪** | `--tracked-change` | Word 原生修订标记（`<w:ins>`/`<w:del>`，保留原格式） | 「审阅→修订」面板逐条接受/拒绝 |
| **修订+批注**（推荐） | `--mode tracked` | `<w:ins>`/`<w:del>` 修订标记 + 修改说明批注（reason/style/reference 写入 comments.xml，按审阅者区分） | 「审阅」面板逐条接受/拒绝 + 查看批注理由 + 按审阅者筛选 |

> **D5 说明**：批注模式为字符级锚定——start/end 边界均精确拆分到 run 内部，Word 中选中批注文本时高亮范围与被修改文字完全一致。

#### 修订+批注模式使用（--mode tracked）

```bash
# 完整版（5 角色审稿，默认）
python -m gongwen optimize-content 原文.docx --changes changes.json --mode tracked --apply

# 精简版（3 角色）
python -m gongwen optimize-content 原文.docx --changes changes.json --mode tracked --reviewers 3 --apply

# 带事实核验（--background 背景资料，对存疑人事信息追加核验批注）
python -m gongwen optimize-content 原文.docx --changes changes.json --mode tracked \
  --background "背景资料1.pdf" --background "资料2.docx" --apply
```

- 修订标记与批注共享同一编辑语义，Word 识别为同一次修改
- 支持背景资料格式：.docx / .pdf / .md / .txt / URL
- 存疑/未核验实体自动生成 `【事实核验⚠️】` 批注 + `.fact_check.json` 核验报告
- 执行分步回显：`[1/6] 加载变更 → [2/6] 匹配预检 → [3/6] 修订注入 → [4/6] 批注写入 → [5/6] 事实核验 → [6/6] 生成文档`
- 回显控制：`--quiet` 仅输出最终结果；`--verbose` 输出每个 run 匹配细节

---

### 路径 B / 上下文感知原则（三步思考法和内容保留审查之前必须先执行）

> **在进入内容保留审查和三步思考法之前，LLM 必须先完成上下文感知分析。该阶段不产生 修订内容，仅为后续优化提供全局参照。**

#### 1. 全文通读两遍制

- **第一遍 · 整体理解**：通读全文，建立以下五个维度的全局认知——
  - **文档类型**：通知 / 报告 / 请示 / 函 / 纪要等（对照 22 种类型）
  - **核心论题**：全文主旨是什么？要解决什么问题或汇报什么事项？
  - **组织结构**：段落层级关系（总→分 / 背景→问题→措施 / 事由→依据→请示事项）、各段功能定位
  - **关键数据分布**：哪些段落包含金额、日期、文号、百分比、人名、地名等关键信息？在脑中形成"数据地图"
  - **逻辑链条**：前因→后果、问题→措施、依据→请示 是否闭合

- **第二遍 · 带上下文逐段分析**：在生成 修订内容 时，始终带着第一遍的全局认知进行——
  - 修改某段时，同时扫描该段与前段、后段的逻辑衔接是否仍然通顺
  - 引用某术语、地名、文号时，确认与全文其他部分保持一致
  - 精简某段时，确认信息点未被后文重复覆盖（避免去重遗漏）

#### 2. 背景来源优先级

| 优先级 | 背景来源 | 说明 |
|--------|----------|------|
| **P0** | 用户输入提示 | 用户明确提供的背景信息（如"这是向省厅汇报的材料，重点突出经费使用情况""受众是乡镇基层干部，语言要通俗"）→ 最高优先级，覆盖所有其他背景推断 |
| **P1** | 原文档全文推断 | 无用户提示时，从原文中提取：文档目的（标题+首段）、受众（抬头/落款/行文语气）、核心论点（各级标题+首尾段） |
| **P2** | 公文类型默认规范 | 当上述两层均无明确信息时，按公文类型（通知/报告/请示等）的通用写作规范推断受众和语气 |

**注意**：P0 与 P2 冲突时 P0 优先。例如用户说"语言通俗"但公文类型规范要求"庄重严谨"→ 以用户"语言通俗"为准，可在`style`字段标注"简洁明快（用户指定）"。

#### 2a. 参考文件处理规范（参考文件读取失败时的应对）

当用户提供的参考文件（PDF/图片等）无法直接读取文本时，Agent **必须**按以下优先级处理：

| 优先级 | 处理方式 | 说明 |
|--------|----------|------|
| **P0** | OCR 识别 | 扫描件 PDF / 图片文件应尝试 OCR 工具提取文字（如 pytesseract + pdf2image）。如环境有对应库则必须使用 |
| **P1** | 告知用户并提供文字版 | 若 OCR 不可用或识别率过低，**必须**告知用户"该文件为扫描件，无法自动提取关键信息"，请用户提供文字版本 |
| **P2** | 标注为"未读取到参考文件" | 用户无法提供文字版时，在回复中标注"（参考文件为扫描件，内容未读取）"，不得凭空编造参考文件中的信息 |

**严禁**：
- 未成功读取参考文件内容，就声称"已阅读参考文件"
- 在 `reference` 字段中引用"参考文件显示"等无法验证的信息

#### 3. 跨段一致性检查（必检项）

在生成完整 修订内容 后、写入磁盘前，LLM 必须逐项检查：

| # | 检查项 | 检查方法 | 不合格处理 |
|---|--------|----------|------------|
| 1 | **术语统一** | 搜索全文同一概念是否出现多个称谓（如"协同创新中心"vs"联合创新中心"、"我省"vs"湖南省"） | 统一为首次出现时的正式称谓，在 reason 中注明"术语统一" |
| 2 | **数据一致** | 同一数据指标在全文中是否出现冲突（如第3页"300万元"第10页"500万元"、同一日期前后不一致） | 以首次出现的数值为准（除非明显笔误），在 reason 中注明"数据一致性修正" |
| 3 | **标题正文对应** | 各级标题的覆盖范围是否与正文内容匹配（标题说"三大措施"正文只列两条、标题说"问题与建议"正文只写了建议） | 修正标题措辞使其与正文内容匹配，或标注缺失内容用`XXX`占位 |
| 4 | **逻辑闭环** | 上文提出的问题/任务，下文是否有对应的解决措施/完成情况（不能前文"存在三个突出问题"，后文只回应了两个） | 在缺失处标注`（此处应补充 XXX 相关内容）`并写入 reason |
| 5 | **层级对等** | 同级标题是否语法结构一致（如都是动宾短语、或都是名词短语） | 统一为最常见的结构形式 |

#### 4. 背景驱动扩展约束

合理扩展必须基于上下文推断，遵守以下边界：

- ✅ **可扩展**：前文提到"获省级立项"，后文可合理扩展"该项目已通过省级评审，获得省科技厅立项支持"
- ✅ **可扩展**：前文详述问题成因，后文措施段可补充"针对上述问题，重点从以下方面突破"
- ❌ **不可扩展**：前文"获省级立项" → 后文凭空添加"获国家级立项"
- ❌ **不可扩展**：原文无任何经费数据 → 扩展出具体金额
- ❌ **不可扩展**：原文未提及某政策 → 扩展引用该政策文号

扩展必须严格基于原文已出现的信息进行合理推演，不得从文档整体语境之外引入新信息。

---

### 路径 B / 内容保留优先原则（铁律，上下文感知之后、三步思考法之前必须过审）

> **在完成上下文感知分析后、进入三步思考法之前，LLM 必须逐段过审以下红线。违反任一条即为不合格输出。**

1. **关键信息绝对不可删除**：严禁删除包含以下类型信息的整段或整句——
   - 关键里程碑（日期 + 事件，如"2025年3月与省科技厅汇报"）
   - 领导协调 / 汇报记录（如"向国家民委文宣司汇报"）
   - 资金 / 经费 / 项目预算数据（含具体金额或来源）
   - 政策依据引用（含文号、政策名称）
   - 省情 / 背景分析段落（提供论证基础的信息段）
   - **人事信息**（领导姓名、机构全称、职务、文号等——此类信息在原文中存在则必须保留，但严禁在原文基础上编造或扩展，新增人事信息一律用 `[XXX]` 占位，遵循强制规则第 9 条）

2. **去重必须逐句对比，不可凭「主题相似」判重**：当判断某段与另一段「重复」时——
   - ✅ 必须逐句对比，确认**每一句**都在另一段中有**完全相同**（非相似）的对应内容，才能整段删除
   - ❌ 仅主题相似但表述不同（角度、细节、举例不同）→ **不得**删除
   - ❌ 两段内容各有独特信息点 → **不得**以「合并」为由删掉其中任一段的信息

3. **精简段落必须保留全部关键信息要素**：精简时保留 who / what / when / where / why / how，仅删除真正的冗余修饰词（如多余的"的""了""进行"），不可砍掉信息点。

4. **删除操作必须在 reason 中透明说明**：每项涉及删除的操作（整句删除、整段删除），reason 中必须写明——
   - 删除了什么（引用原文关键句）
   - 为什么它确实是冗余的（指出与哪一段哪一句完全重复，或指出该信息在上下文中已由何处覆盖）
   - 禁止使用「与上文重复」等模糊描述，必须具体到对应的段落和句子

### 路径 B / 内容合理扩展原则（补充原则，保留优先于扩展）

> **保留优先，扩展为辅。以下扩展权限仅在不违反「内容保留优先原则」的前提下生效。**

1. **允许扩展的场景**：
   - **逻辑跳跃**：原文句子之间因果/递进关系不清晰时，补充过渡句使行文更连贯
   - **论据不足**：原文提出观点但支撑论述薄弱时，基于上下文合理推演，补充论证语句
   - **数据罗列缺乏总结**：原文列举数据后缺乏归纳时，增加一句总结性表述
   - **段落衔接生硬**：两段之间缺少承上启下的引导句时，增加过渡衔接句

2. **扩展边界（硬约束）**：
   - 不得虚构人物、事件、数据、日期、文号、政策名称
   - 不得添加与原文立场相悖的观点或改变原文结论
   - 扩展内容必须在 `修订内容` 的 `reason` 字段中标注「此为补充内容」，并说明补充理由
   - 单段扩展量不超过原段落字数的 30%（以 `original_text` 字数为基准）

3. **与「内容保留优先原则」的关系**：
   - 保留优先原则的 4 条红线（关键信息不可删除 / 去重必须逐句对比 / 精简必须保留全部要素 / 删除必须在 reason 中透明说明）始终优先
   - 当保留原则与扩展原则冲突时（如精简段落后仍有空间扩展），优先满足保留原则的全部约束，再考虑扩展

---

### 路径 B / 三步思考法（生成 reason/style/reference，LLM 每段必须执行）

> **第1步 · 段落类型定位**：这段文字在公文中是什么类型/处于什么位置？
> 示例："开头惯用语段"、"问题分析段"、"工作部署段"、"收尾总结段"、"过渡衔接句"

> **第2步 · 写作规范查阅**：针对该类段落，公文写作规范要求什么？
> 示例："汇报导语应庄重简洁、点明事由与依据"、"问题分析应聚焦现状不足、避免与建议混同"、"部署应具体可操作"

> **第3步 · 逐处对比判断**：逐一对比原文与修订文的差异，将每处修改用「原文」→「修订」格式输出到 `reason`；**必须**从第2步的规范判断中提炼风格标签填入 `style`（**必填项**，从风格词典中选取，不可留空）；将写作规范来源写入 `reference`；如需扩展（补充过渡句、论证语句、总结归纳、衔接引导句），在 `reason` 中标注「此为补充内容」并说明理由

**`reference` 引用原则**：必须引用真实、可查证的公文写作规范，不可凭空编造；格式为：`公文"XX"部分写作规范——具体规范说明`。

**完整示例**：

```json
{
  "paragraph_index": 0,
  "original_text": "紧扣省委省政府关于推动经济高质量发展的决策部署，落实相关工作要求，研究有关情况，现就有关事项汇报如下：",
  "optimized_text": "深入贯彻省委、省政府关于推动经济高质量发展的决策部署，全面落实相关工作，研究进展情况，现就有关事项汇报如下：",
  "reason": "「紧扣」→「深入贯彻」更符合公文庄重语体；「省委省政府」→「省委、省政府」保持格式规范；「落实」→「全面落实」增强力度；补充「湖南省」全称保持一致性；「研究有关情况」→「研究进展情况」更精准",
  "style": "庄重严谨",
  "reference": "公文"汇报导语"部分写作规范——开头点明事由与依据，属地全称不可省略，动词力度与公文庄重语体匹配"
}
```

**修改原则**：
- 每段修改点控制在 5 处以内
- 优先级：笔误 > 语病 > 措辞润色 > 结构优化
- **必须先执行三步思考法再动笔修改**：判类型 → 查规范 → 出修改意见
- 不编造数据、不替换事实信息、缺失用 XXX 占位
- 优化后文字必须能独立成段，保持原段落信息完整

---

### 路径 B / 多轮优化规则

路径 B 的 `optimize-content` 支持多轮迭代。每轮以用户上一轮已确认的 `optimized_text` 为新的 `original_text`，仅新轮次的变更生成红色标注+删除线，上一轮已确认内容视作"原文"，不再标记。

```
第1轮：
  original_text: "推动赛事组织提质增效"
  optimized_text: "全面提升赛事组织的智能化水平和运行效率"
  用户确认 ✅ → 以此版为新 baseline

第2轮：
  original_text: "全面提升赛事组织的智能化水平和运行效率"  ← 第1轮确认版
  optimized_text: "全方位推动赛事组织的智能化转型与效能提升"
  用户确认 ✅ → 以此版为新 baseline

第N轮：
  以此类推，每轮仅标注本轮变更
  标记始终干净、可追溯、无叠影
```

**关键规则**：
- 每轮 `changes` 中的 `reason` 只写本轮修改差异，不重复历史修改记录
- `optimized_text` 为各角色审稿意见全部合成后的唯一最终版本
- 单文档累计迭代不超过 5 轮，超限后建议定稿

---

### 路径 B / 审稿机制嵌入（审稿意见 → 修订内容）

路径 B 在生成 `changes` JSON 时直接嵌入五角色审稿机制。每个角色对每段的修改意见汇总为 `reason` 字段中的分项标注，`optimized_text` 为全部意见合成后的最终版本。

**审稿产出 → revisions 的映射规则**：

| 审稿角色 | 产出形式 | 在 `changes` 中的映射 |
|---------|---------|---------------------|
| ①撰稿人自审 | 业务事实修正、数据核验 | `reason` 中标注 `【撰稿人】` 及其修正内容 |
| ②业务审核人 | 业务口径、分工边界审核 | `reason` 中标注 `【业务审核】` 及审核结论 |
| ③文字校对岗 | 错别字/语病/用语规范修正 | `reason` 中标注 `【文字校对】` 及修改依据 |
| ④综合核稿人 | 政策口径、敏感措辞排查 | `reason` 中标注 `【综合核稿】` 及复核结论 |
| ⑤签发领导 | 终审确认意见 | `optimized_text` 中体现终审修改，`reason` 标注 `【终审】` |

**合成规则**：
- `optimized_text` = 撰稿人原文 → 经业务审核 → 经文字校对 → 经综合核稿 → 经领导终审 后的文本
- `reason` = 合并各角色对该段的判断依据，角色间用分号分隔
- 若某角色对该段无意见，`reason` 中不出现该角色的标注，`optimized_text` 不做变更

**示例如下**：

```json
{
  "changes": [
    {
      "paragraph_index": 5,
      "original_text": "请各单位在收到通知后认真组织学习，按时报告落实情况。",
      "optimized_text": "请各单位在收到通知后认真组织学习，并于2026年8月15日前书面上报贯彻落实情况。",
      "reason": "【撰稿人】补充上报截止时间，使要求明确可执行；【业务审核】确认口径：书面报告；【文字校对】「报告」→「上报」更符合下行文用语规范；【综合核稿】无意见；【终审】同意。",
      "style": "庄重严谨",
      "reference": "公文通知写作规范——事项段应包含"时限+方式+反馈对象"三要素"
    }
  ]
}
```

**精简版审稿方案（3角色）的映射**：

```
撰稿人（自审）→ 业务+文字复合审核 → 综合负责人终审
    ↓              ↓                     ↓
 reason标注     reason标注              optimized_text体现
【撰稿人】    【复合审核】             【终审】标注
```

### 路径 B / 风格词典（8 种风格，style 字段取值范围）

**⚠️ `style` 字段必填规则**：每个 change 对象的 `style` 字段为**必填项**，不可留空或省略。必须从以下风格词典中选取最匹配的一项填入。每种风格含六维度详细指引，LLM 应参照对应维度的句式特征/用词偏好/结构要求执行优化。

#### 1. 庄重严谨（优先级 1）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中长句为主（20-40 字），多用主动语态、第三人称；少用"的"字长定语，一句一个核心动作 |
| **用词偏好** | ✓ 常用：贯彻/落实/部署/推进/强化/深化/统筹/协调；✗ 禁用：口语词（搞/弄/抓一抓）、程度副词堆砌（非常/特别/极其） |
| **结构要求** | 总分总结构：首段点明事由依据 → 中段并列展开措施/要求 → 末段收束总结 |
| **语气调性** | 正式度 10/10，权威感强，不卑不亢，体现发文机关的公信力 |
| **典型句式** | ①"为深入贯彻落实…，现就有关事项通知如下：" ②"各地区、各部门要高度重视，切实抓好…" ③"坚持…与…相结合，统筹推进…" ④"按照…的部署要求，扎实推进…" |
| **反面示例** | ①"大家要把这个事情搞起来"（口语化） ②"非常非常重视这项工作"（副词堆砌） ③"大概可能完成了一半左右"（模糊表述） |

#### 2. 简洁精炼（优先级 2）

| 维度 | 说明 |
|------|------|
| **句式特征** | 短句为主（10-20 字），一段不超过 4 句，善用分号并列 |
| **用词偏好** | ✓ 常用：单字动词（抓/促/推/保），去冗余修饰；✗ 禁用："的""了""进行""加以"等填充词，"进一步""持续""不断"等虚化副词堆叠 |
| **结构要求** | 并列式展开（要点→要点→要点→总结），每段首句揭示核心，末句不做多余收束 |
| **语气调性** | 正式度 8/10，直击要点，节奏明快，不拖泥带水 |
| **典型句式** | ①"一是…二是…三是…" ②"重点抓好以下工作："后接短要点 ③"做到：目标明、任务清、措施实" ④"突出…，聚焦…，狠抓…" |
| **反面示例** | ①"对于这个问题，我们进行了深入的研究和分析"（"进行了"冗余） ②"希望能够进一步持续不断地加强和改进"（虚化副词堆叠） |

#### 3. 庄重得体（优先级 3）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中长句为主（15-35 字），多用敬语式祈使句（"请""恳请""敬请"），避免命令式 |
| **用词偏好** | ✓ 常用：谨/恳请/敬悉/承蒙/惠予/赐复；✗ 禁用：命令式动词（必须/应立即/要求）、居高临下措辞 |
| **结构要求** | 三段式：敬启语 → 事项说明 → 恳请语，每层之间自然过渡，不突兀 |
| **语气调性** | 正式度 9/10，亲和度 7/10，体现尊重和谦逊，保持平等沟通姿态 |
| **典型句式** | ①"贵单位来函收悉，现就…函复如下：" ②"谨定于…，敬请莅临指导" ③"恳请贵单位在…方面给予支持为盼" ④"如有不妥，敬请指正" |
| **反面示例** | ①"你们必须在本周五前回复"（命令式） ②"收到你们的信了，答复如下"（过于随意） ③"希望你们配合"（缺乏敬意） |

#### 4. 务实汇报（优先级 4）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中等句长（15-30 字），大量使用主谓宾陈述句，数据与结论紧密关联 |
| **用词偏好** | ✓ 常用：完成/实现/达到/增长至/同比/占比/超额；✗ 禁用：空泛形容词堆砌（"极大的""空前的""历史性的"无数据支撑时） |
| **结构要求** | 背景→做法→成效→数据→不足→下步，每部分有明确的数据锚点 |
| **语气调性** | 正式度 8/10，客观务实，数据驱动，避免空话套话 |
| **典型句式** | ①"全年完成…，同比增长 X%，超额完成年度目标" ②"主要做法：一是…二是…三是…" ③"存在的主要问题：…" ④"下一步将重点做好以下工作：" |
| **反面示例** | ①"取得了极大的成功，获得了空前的反响"（无数据支撑） ②"各项工作都有很大提升"（笼统空泛） |

#### 5. 请示恳切（优先级 5）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中等句长（15-30 字），多用"恳请""祈请""敬请"引导的祈使句，陈述理由用因果复句 |
| **用词偏好** | ✓ 常用：恳请/祈请/妥否/当否/呈请/报请/为盼；✗ 禁用："应该""理应""理所当然"等预设同意前提的词 |
| **结构要求** | 事由→依据→理由（必要性+可行性+预期效果）→请示事项→恳请语，理由部分不少于整体 50% |
| **语气调性** | 正式度 9/10，态度恳切，有理有据，不卑不亢 |
| **典型句式** | ①"为…，现就…事项呈请如下：" ②"鉴于…，亟需…，故恳请…" ③"以上请示妥否，请批示" ④"如无不妥，请转发…执行" |
| **反面示例** | ①"这个事应该批，理由很充分"（口语化+预设同意） ②"我们觉得需要这笔钱"（缺乏正式事由和依据） |

#### 6. 动员激励（优先级 6）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中长句为主（20-35 字），多用排比句、递进句营造气势，善用"要""必须""务必"增强力度 |
| **用词偏好** | ✓ 常用：奋力/全力/着力/攻坚/冲刺/确保/坚决/开创；✗ 禁用：消极/犹豫措辞（"争取""尽量""可能"）、长句拖沓 |
| **结构要求** | 目标定向→任务分解→责任压实→号召动员，层层递进，末尾以排比句收束 |
| **语气调性** | 正式度 8/10，鼓动性 10/10，节奏感强，富有感染力 |
| **典型句式** | ①"让我们…，为…而努力奋斗！" ②"要拿出…的决心，…的力度，…的措施" ③"确保…，坚决…，全力…" ④"以…的优异成绩，向…交出满意答卷" |
| **反面示例** | ①"希望能努力争取完成"（缺乏决心） ②"差不多应该可以了"（消极模糊） |

#### 7. 总结回顾（优先级 7）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中等句长（15-30 字），多用过去时态陈述句，善用"回顾""总结""盘点"等引导词 |
| **用词偏好** | ✓ 常用：回顾/总结/积累/提炼/梳理/取得/迈出；✗ 禁用：与回顾性质冲突的未来承诺（"将""计划""打算"过多使用） |
| **结构要求** | 总述→分类回顾（工作领域维度）→亮点提炼→经验教训→展望，各类回顾权重均衡 |
| **语气调性** | 正式度 8/10，客观平和，夹叙夹议，避免过度渲染成绩 |
| **典型句式** | ①"回顾过去一年，…取得了显著成效" ②"主要呈现以下特点：一是…二是…" ③"在肯定成绩的同时，我们也清醒地认识到…" ④"这些成绩的取得，得益于…" |
| **反面示例** | ①"我们干得特别好，特别棒"（过于主观渲染） ②"一切都很好，没有不足"（回避问题） ③"虽然有点小问题但没关系"（轻描淡写） |

#### 8. 逻辑严密（优先级 8）

| 维度 | 说明 |
|------|------|
| **句式特征** | 中长句为主（18-35 字），多用因果复句、条件复句（"由于…因此…""若…则…"），关联词明确 |
| **用词偏好** | ✓ 常用：由此可见/综上所述/究其原因/归根结底/据此/基于/鉴于；✗ 禁用：跳跃式表述（无关联词直接切换话题）、模糊笼统的归因 |
| **结构要求** | 前提→分析→推导→结论，每一步有明确逻辑标记（首先/其次/因此/综上），段落间环环相扣 |
| **语气调性** | 正式度 9/10，理性缜密，层层递进，说服力强 |
| **典型句式** | ①"究其原因，主要有以下三个方面：" ②"基于上述分析，可以得出以下结论：" ③"若不…，则…，因此必须…" ④"由此可见，…与…之间存在显著关联" |
| **反面示例** | ①"这个问题很严重，所以要加强"（跳跃推导，缺少中间环节） ②"总之各方面都挺好的"（无逻辑总结） ③"因为时间紧，所以没完成"（单一归因） |

> **使用说明**：上述六维度按优先级排列，LLM 优化时应优先满足前 4 维度（句式特征→用词偏好→结构要求→语气调性），典型句式为参考模板、反面示例为红线禁区。

---

### 路径 B / 风格组合与叠加规则

> **当用户在同一句需求中指定多个风格时（如"严谨正式+简洁精炼""逻辑严密+务实汇报"），或段落特征需要融合两个风格时，按以下规则组合。**

#### 规则一：优先级裁决

当两种风格在某维度上冲突时，**序号靠前的风格为主导风格**，其在该维度的设定优先：

```
主导风格优先级（序号靠前 > 序号靠后）：
庄重严谨(1) > 简洁精炼(2) > 庄重得体(3) > 务实汇报(4) > 请示恳切(5) > 动员激励(6) > 总结回顾(7) > 逻辑严密(8)
```

**示例**：用户指定"庄重严谨 + 简洁精炼"→ 句式以庄重严谨的中长句为主，但融入简洁精炼的去冗余原则。

#### 规则二：按维度合并（默认策略）

对于不冲突的维度，取各风格的并集或最佳实践：

| 维度 | 合并策略 | 示例（庄重严谨 + 简洁精炼） |
|------|----------|---------------------------|
| **句式特征** | 主导风格决定句长范围，辅助风格优化结构 | 中长句（庄重严谨），但删除冗余修饰词（简洁精炼） |
| **用词偏好** | 取并集，冲突时主导风格优先 | 庄重严谨词汇库 + 简洁精炼的简练原则 |
| **结构要求** | 主导风格决定宏观结构，辅助风格优化微观组织 | 总分总（庄重严谨），但每段不超过 4 句（简洁精炼） |
| **语气调性** | 主导风格决定语气基调，辅助风格微调 | 正式度 10 → 9（庄重严谨基调 + 简洁精炼的直接感） |
| **禁止项** | 取所有风格的禁止项并集 | 禁止口语词 + 禁止填充词 |

#### 规则三：同段不拆分原则

**一个段落只分配一个 `style` 标签。** 即使该段同时体现多种风格特征，也只选取**该段最主要功能**对应的风格。多功能段落的风格判定优先级：

```
段落功能 → 风格标签：
请求类内容（请示/请求批准） → 请示恳切
部署类内容（命令/安排/要求） → 庄重严谨
汇报类内容（数据/进度/成果） → 务实汇报
分析类内容（原因/影响/推导） → 逻辑严密
号召类内容（动员/鼓劲/总结） → 动员激励 / 总结回顾
```

#### 规则四：全文档风格一致性

同一份 修订内容 中，所有段落的 `style` 标签应呈现**主风格+辅助风格**的分布模式：

- **主风格**（占 ≥ 60% 的段落）：由文档类型和用户需求决定的统一风格
- **辅助风格**（占 ≤ 40% 的段落）：根据各段功能不同灵活选取

**示例**：一份"工作报告"走务实汇报风格优化，其中部署段可标"庄重严谨"，问题分析段可标"逻辑严密"，总结段可标"总结回顾"——但 70% 以上的段落应统一标"务实汇报"。

#### 风格组合典型场景速查

| 用户需求 | 主导风格 | 辅助风格 | 适用场景 |
|----------|----------|----------|----------|
| "正式一点，别太啰嗦" | 庄重严谨 | 简洁精炼 | 通知、决定 |
| "向领导汇报，要有数据支撑" | 务实汇报 | 逻辑严密 | 工作报告、总结 |
| "写给兄弟单位，要有礼貌" | 庄重得体 | 简洁精炼 | 函、请示 |
| "动员部署，要有力度" | 动员激励 | 庄重严谨 | 工作部署、方案 |
| "年度总结，客观全面" | 总结回顾 | 务实汇报 | 年度总结、述职报告 |

---

### 路径 B / 段落类型优化检查清单（修订内容 生成后必须逐段过审）

> **LLM 在生成 修订内容 后、写入磁盘前，必须按以下 9 种段落类型逐段审查。每段至少在 修订内容 中附录该类型的检查结果（可在 `reference` 字段末尾追加）。**

#### 1. 标题（4 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 1.1 | **序号体系规范** | 是否使用规范的公文序号层级（一、(一) 1. (1) ①），无跳层、无倒序 | 修正为规范序号，在 reason 中注明 |
| 1.2 | **标题概括性** | 标题是否准确覆盖正文全部要点，无遗漏、无过度泛化 | 调整措辞使标题与正文内容匹配 |
| 1.3 | **同级标题结构对仗** | 同级标题语法结构是否一致（全为动宾短语 / 全为名词短语） | 统一为最常见结构 |
| 1.4 | **文种标识准确** | 公文标题是否含正确的文种名称（"关于...的通知/报告/请示"） | 修正文种，确保与 `-t` 参数一致 |

#### 2. 主送机关（4 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 2.1 | **全称/规范化简称** | 主送机关是否使用全称或法定规范化简称，无口语化简称 | 替换为规范全称 |
| 2.2 | **排序规则** | 多主送机关是否按党→政→军→群顺序排列，同级按惯例 | 调整顺序 |
| 2.3 | **格式位置** | 主送机关是否顶格、是否在标题之下正文之上独立一行 | 修正位置 |
| 2.4 | **标点准确** | 多主送机关之间用顿号，最后一个用冒号；单机关直接用冒号 | 修正标点 |

#### 3. 汇报导语段（7 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 3.1 | **惯用语规范** | 是否使用"为...现将...汇报如下"标准格式，无自创惯用语 | 替换为标准惯用语 |
| 3.2 | **背景紧扣上级部署** | 事由是否与上级文件/会议精神对齐，引用准确的文号或会议名称 | 补充或修正引文 |
| 3.3 | **主体定位准确** | 发文主体自称是否一致（我委/我局/我办），无混用 | 统一为规范自称 |
| 3.4 | **事项全称准确** | 首次提及的事项是否使用全称，后续使用规范简称 | 补充全称 |
| 3.5 | **过渡衔接自然** | 事由与汇报内容之间的过渡是否通顺，"如下："后是否直接接正文 | 调整衔接措辞 |
| 3.6 | **语气得体** | 向领导/上级汇报的语气是否庄重不卑不亢，不口语化 | 替换非正式表达 |
| 3.7 | **冗余检查** | 是否与标题或第一段正文内容重复（导语应概述而非复述） | 精简冗余措辞 |

#### 4. 正文/成绩汇报段（8 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 4.1 | **时序逻辑** | 工作按时间推进（年初→年中→年底）或按任务线排列，无混乱 | 调整段落顺序 |
| 4.2 | **数据支撑具体** | 关键指标后有具体数字（避免"大幅增长"而无数字） | 补充数据或标注 `XXX` |
| 4.3 | **主谓完整** | 每句主谓宾完整，无歧义指代（避免"这项工作""相关方面"） | 补全主语或明确指代 |
| 4.4 | **成果归属明确** | 多部门协作时明确牵头与配合单位，责任归属清晰 | 补充归属 |
| 4.5 | **措辞分寸得当** | 成绩用词不夸大（"显著""重大"需有数据支撑），不贬低其他单位 | 调低形容词程度 |
| 4.6 | **层次递进分明** | 成绩段落有总分/递进结构，非简单罗列 | 增加引导句和总结句 |
| 4.7 | **术语前后统一** | 全文同一概念使用同一术语，不混用 | 统一术语 |
| 4.8 | **动词力度恰当** | 动词是否与成绩分量匹配（"完成"→"圆满完成"需有依据） | 调整动词力度 |

#### 5. 问题分析段（7 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 5.1 | **逻辑链完整** | 问题→原因→影响是否形成完整因果链，不跳跃 | 补充缺失环节 |
| 5.2 | **例证支撑** | 每个问题有无宏观概述+具体例证（至少各一），不空谈 | 补充具体案例或数据 |
| 5.3 | **严重程度措辞恰当** | "突出问题/亟待解决/需引起重视"等措辞是否与事实匹配 | 调整严重程度措辞 |
| 5.4 | **客观不回避** | 是否涉及主观因素而不只归咎客观，态度坦诚 | 补充主观因素分析 |
| 5.5 | **与成绩段对应** | 成绩段中提到的领域，问题段是否也有所覆盖 | 确保覆盖一致性 |
| 5.6 | **篇幅比例合理** | 问题段篇幅与成绩段比例是否合理（通常不超成绩段 50%） | 精简或标注扩展 |
| 5.7 | **结论具建设性** | 问题分析后是否有方向性指引句 | 补充引导句 |

#### 6. 建议/请示段（7 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 6.1 | **建议具体可操作** | 每条建议是否可量化/可执行，不含"进一步""着力"等空话堆砌 | 拆分为具体行动项 |
| 6.2 | **提请对象明确** | 是否明确"恳请XX部门/XX领导"审批/协调/支持 | 补充提请对象 |
| 6.3 | **一文一事** | 请示是否只涉及一个事项，无多个不相关请示混编 | 拆分或合并同类 |
| 6.4 | **理由充分** | 请示事项是否说明必要性、可行性、预期效果三层理由 | 补充不足的理由层次 |
| 6.5 | **附件引用完整** | 正文引用的附件是否全部列出，编号与附件说明一致 | 补充遗漏附件 |
| 6.6 | **语气合规** | 请示用"妥否，请批示"/"请审批"，报告用"请审阅" | 修正结尾语 |
| 6.7 | **建议按优先级排列** | 多条建议是否按重要性/紧迫度从高到低排列 | 调整排序 |

#### 7. 结尾规范语（4 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 7.1 | **文种匹配** | 报告→"特此报告"；请示→"妥否，请批示"；函→"特此函告"；批复→"此复" | 替换为规范用语 |
| 7.2 | **位置独立成段** | 结尾语是否顶格或空两格独立成段，不接在正文末句后 | 独立成段 |
| 7.3 | **无多余修饰** | 结尾语前不加"以上""现""特此"以外的多余修饰词 | 删除多余修饰 |
| 7.4 | **不重复使用** | 全文仅保留一处结尾规范语，不在正文中间误用 | 删除多余的结尾语 |

#### 8. 落款/署名段（5 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 8.1 | **单位全称规范** | 署名是否使用发文机关全称或法定规范化简称 | 替换为规范全称 |
| 8.2 | **日期用汉字** | 成文日期是否使用汉字数字（如"二〇二六年七月二十六日"），非阿拉伯数字 | 转换为汉字数字 |
| 8.3 | **右对齐** | 署名和日期是否右对齐，右空约四字 | 调整对齐 |
| 8.4 | **印章位置预留** | 日期上方是否预留了印章位置（通常空一行），署名是否在印章下方居中 | 调整空行 |
| 8.5 | **多单位署名排序** | 联合发文是否按主办机关→协办机关顺序排列，印章不交叉 | 调整排序 |

#### 9. 附件说明（4 项检查维度）

| # | 检查项 | 评判标准 | 不合格处理 |
|---|--------|----------|------------|
| 9.1 | **名称与正文一致** | 附件名称是否与正文中引用的名称完全一致，一字不差 | 统一名称 |
| 9.2 | **序号与顺序对应** | 附件序号（1. 2. 3.）是否与正文引用顺序一致 | 调整序号 |
| 9.3 | **格式标注** | 附件名称后是否标注文件格式（如"（PDF）""（Excel）"），可选但建议 | 建议补充 |
| 9.4 | **"附件："前空一行** | 正文末尾与"附件："之间是否空一行（按 GB/T 9704 格式规范） | 补充空行 |

> **产出要求**：每个 change 对象的 `reference` 字段末尾需追加对应段落类型的审查结论，格式为 `[段落类型: XX] 检查项 N/N 通过，X项需修正：具体项`。例如：`[段落类型: 汇报导语段] 检查项 6/7 通过，1项需修正：惯用语"汇报一下"→"汇报如下"`。

---

### 路径 B / 去重操作完整性检查（修订内容 生成后必须执行）

> 对于标记为「去重 / 与上文重复 / 合并同类」的删除类 change 对象，LLM 必须在生成完整 修订内容 后执行以下自检：

- **成对删除检查**：如果某段（段落 A）被标记删除且 reason 中写了「与段落 X 重复」，则必须同步检查段落 X 是否也被标记为删除或合并。去重必须成对完成——不能只删一段而留另一段。
- **残留检查**：遍历所有 change 对象，若 `optimized_text` 与另一段的 `original_text` 或 `optimized_text` 存在大段（≥20字）完全相同的内容，且其中之一已被标记删除 → 另一段必须同步处理（删除或合并），否则去重未完成。
- **声称完成检查**：修订内容 中任何 reason 字段若出现「去重」「合并重复」「删除重复段」等表述，必须在 修订内容 末尾追加一个 `_dedup_audit` 字段，列出：
  ```json
  "_dedup_audit": {
    "deleted_paragraphs": [3, 7],
    "retained_counterpart": 3,
    "verified_pairs": [[3, 3], [7, 3]]
  }
  ```
  - `deleted_paragraphs`：被删除的段落索引列表
  - `retained_counterpart`：保留的对应段落索引（若多段合并到一个则取主段）
  - `verified_pairs`：每对去重关系的原文段索引配对（[已删除的, 保留的]）
  - 此字段仅供 Agent 审计，不会影响 `optimize-content` 运行

### 路径 B / 强制审计清单（路径 B 完成后必查）

Agent 在路径 B 交付产品前，必须逐项审计以下五点并汇报结果：

| # | 审计项 | 评判标准 |
|---|--------|----------|
| 1 | 交互流程 | 三步确认走了吗？用户选的是格式还是内容？ |
| 2 | 文件命名 | 路径 B 是否按 `{原文档名}+内容风格+日期+版本号.docx` 命名？路径 A/C 是否按 `修订版+...` 命名？ |
| 3 | 内容准确性 | diff 标记数量与 修订内容 一致？误标记未修改文字？ |
| 4 | 优化说明质量 | 每段说明是三段式还是「大幅优化措辞」？ |
| 5 | 格式继承 | 对比文档字体/字号/行距与原文档一致？无 optimize 混入？ |

审计结果用表格呈现，每项标记 ✅ / ⚠️ / ❌。

---

### 路径 B / 第2步：生成差异对比文档

```bash
# 自动命名：{原文档名}+{内容风格}+{日期}+v1.docx（如 工作报告+庄重严谨+20260725+v1.docx）
python -m gongwen optimize-content 原文档.docx --changes 修订内容

# 也可显式指定输出文件名
python -m gongwen optimize-content 原文档.docx -o 对比文档.docx --changes 修订内容
```

**标记规则**：
- 原文被修改/删除：灰色（#999999）+ 删除线
- 新增/修改后：红色（#E00000）高亮
- 未改动：黑色正常格式
- 每段末尾：楷体_GB2312 五号（10.5pt）灰色 `【修改说明】xxx 【风格】xxx 【依据】xxx`
- 文档末尾：自动追加 `（内容由GongWen-skill-AI生成，仅供参考）` 灰色小字

**自定义声明文字**（可选）：

```bash
# 覆盖默认声明
python -m gongwen optimize-content 原文.docx --changes 修订内容 --disclaimer "（本稿经GongWen-skill-AI辅助生成，请人工复核）"

# 不使用声明
python -m gongwen optimize-content 原文.docx --changes 修订内容 --disclaimer ""
```

### 路径 B / 如需格式修复：走路径 A

用户确认对比版内容无误后，如需对差异对比文档做格式合规修复，Agent 必须明确告知用户这是**切换到路径 A**，不再是路径 B 的一部分。确认后执行路径 A 的 `check → optimize → check` 流程。

### 路径 B / 表格和图片处理

当原文档包含表格或图片时：

- **表格**：`optimize-content` 在生成差异文档时会自动保留表格在原位置，不参与 diff 标注；表格内的段落不会被内容优化处理
- **图片**：`_replace_paragraph_content` 自动保留含图片（w:drawing / w:pict）的 run，不参与 diff
- **定位**：表格和图片均通过 `insert_after_index` 机制保持在原文档中的相对位置

若需要对表格内容做优化，建议先将表格数据提取为文本，走路径 B 优化后再手动回填。

### 路径 B / 格式继承原则

**只改文字，不改格式。** 差异对比文档必须完整继承原文档的字体、字号、行距、缩进、对齐、页边距。

`optimize-content` 内部自动从原文档段落读取格式并继承。Agent **不可**在路径 B 前后跑 `optimize`（格式修复），会覆盖原文档格式。

**引擎级保护**：`_select_paragraphs` 中 `target="all"` 已排除 `role='annotation'` 的段落；`fix_bold_range` / `bold_first_sentence_of_body` 也排除 `annotation`。Agent 侧的责任是确保不走 `optimize` 落盘路径。

### 路径 B / 从零生成（无原文档，走路径 B 时）

当用户走路径 B 但没有原文档时（极少见，通常是路径 C），按以下流程：

1. 确认公文类型（report / notice / request 等 22 种之一）
2. `md2docx` 生成初稿（必须指定 `-t`）
3. `optimize` 套 GB/T 9704 规范格式
4. 最终交付经过标准化后的文档

---

## 路径 C：生成公文

**没有现有文档，根据背景和要求从零生成新公文。** 输出符合 GB/T 9704 格式标准的全新公文文档。

> ⚠️ **执行前检查清单（必须逐项确认，缺一不可）：**
> - □ 用户没有现成文档，需要从零生成
> - □ 已完成第0步搜索确认关键事实（时间/地点/人名/数据）
> - □ 已确认公文类型和核心信息
> - □ 已使用段落模板写 Markdown 草稿
> - □ 已告知用户：路径 C 产物仅为草稿，正式发文须走审核流程
> - □ 会议类文档须同步询问是否需要生成桌签

### 完整流程（五步）

**第〇步：收集背景信息（必须执行，严禁跳过）**

路径 C 是从零生成公文，Agent 在写草稿前必须按以下优先级确认关键事实信息：

| 优先级 | 来源 | 说明 |
|--------|------|------|
| **P0** | 用户明确提供的背景 | 用户说的时间、地点、数据、人名 → 最高优先级，直接使用 |
| **P1** | Agent 主动搜索确认 | 时效性信息（举办时间、政策文件、最新数据等）→ **必须搜索确认，不得凭记忆编造** |
| **P2** | 公文类型通用规范 | 文种格式、常用句式、标准结构 → 使用下方段落模板 |

**搜索执行规则**：
- 涉及具体时间、地点、人名、政策文号 → 必须走 P1 搜索确认
- 搜索不到的关键信息用 `XXX` 占位，不得编造
- 已完成搜索确认后，向用户报告关键信息来源
- **人事信息铁律（路径 C 专用）**：生成公文涉及领导人姓名、机构全称、职务、联系人、文号等信息时，严格遵循强制规则第 9 条（人事信息准确性铁律）。未经用户明确提供或 `ai_search` 搜索确认的信息，一律用 `[XXX]` 占位，不得凭经验或推理填写。路径 C 第〇步向用户收集信息时，必须主动询问发文机关全称、主送机关全称、关键人物姓名和职务。

同时向用户确认以下信息：

- **公文类型**（通知/请示/报告/函/纪要等，不确定时参考下方类型选择表）
- **发文单位**（本单位全称）
- **主送机关**
- **核心事项**（具体什么事情）
- **关键信息**（时间、地点、数据、人名等）
- **背景材料**（如有，请用户提供）
- **风格偏好**（可选，默认"务实汇报"）

交互原则：

- 如果用户已提供全部信息，直接跳过进入第一步
- 如果有信息缺失，以简洁的方式逐项询问用户补充
- **不要一次性列出所有问题轰炸用户，可分批询问**（先问类型和发文单位，再问核心事项和关键信息）
- 如果用户明确表示无法提供或不想提供某项关键信息（如具体日期、人名、数据等），不强行追问，直接用"XX"或"XXX"占位，生成模板后再提醒用户确认替换

**第一步：编写生成 Markdown 草稿**

LLM 根据用户背景和要求，参考下方段落结构模板和惯用语库，编写完整的公文 Markdown 草稿。使用 `[]` 占位符标记待用户确认的信息（如日期、具体数据等）。

**表格与附件处理规则**：
- `md2docx` 自动将 Markdown 表格转换为 Word 表格（使用 `|` 管道符语法），表格样式继承 GB/T 9704 正文格式
- **附件（如报名表、回执等）应直接嵌入同一文档末尾**，而非生成为单独文件。草稿中在"附件说明"下方用 Markdown 表格写出即可
- 附件页的标题用 `# 附件：` 一级标题，与正文部分的标题层级区分
- 表格中的空行用 `| | | |` 保持行结构，行数可根据需要增减

**附件说明排版要求**（参考定稿文件和 GB/T 9704）：

```
正文末尾
（空一行）
附件：[编号.]附件名称                          ← 仿宋_GB2312 16pt，左空二字
                                              ← 附件名称末尾不加标点
                                              （空一行）
                                  落款单位
                                  日期
```

- 附件说明位于正文下空一行，左空二字
- 多个附件用阿拉伯数字分行列出：`附件：1.附件名称一` 下一行 `2.附件名称二`
- 附件名称后不加句号等标点
- 附件说明与落款之间保留空行
- 附件本身的正文格式：附件标题用方正小标宋简体 22pt 居中，正文仿宋_GB2312 16pt
- 如附件为表格（如报名表），直接在同一文档末尾用 Markdown 表格生成即可，不要生成单独文件
- 附件页与正文页必须用**分页符**隔开，不得连续排版。草稿中在正文末尾（落款之后）与"# 附件："标题之间保留 `---` 标记分页
- 附件表格若列数较多或内容较宽，可考虑将页面方向调整为横向（Landscape），在`---` 处标注 `[横向]` 或 `[landscape]`

> **操作提示**：Agent 在编写 Markdown 草稿时，务必在正文落款后、附件标题前保留一行 `---` 作为分页标记。

**附件生成规则（强制遵守）**：
- **会议类文档**（会议方案、会议通知、纪要等）：凡涉及需要参会单位报名或反馈参会人员信息的，**必须在文档末尾一键生成参会人员报名表**（含序号、单位名称、姓名、职务、联系电话、备注等列），不得遗漏
- **非会议类文档**（请示、报告、函等）：视情况判断是否需要附件。如正文引用"详见附件"或在有关事项中提到"附报名表""附统计表""附征求意见表"等，必须同步生成附表
- **多个附件**：如有多个附件，均嵌入同一文档末尾，用 `# 附件1：` `# 附件2：` 分级标题区分，每个附件前加分页符 `---`

**桌签同步生成规则（会议类文档专用）**：
处理**会议通知、纪要、会议方案、会议议题材料**等涉及**参会人员/列席人员**的文档时，Agent **必须**在完成主文档后主动询问用户：
> 是否需要同步生成会议桌签？可用名单通过 `python -m gongwen table-signs` 批量生成（A5横版、黑体130pt、双面打印）。

具体执行规则：
- 若用户有参会人员名单（或用户能在文档中提供）→ 直接执行 `python -m gongwen table-signs 名单.txt -o ./桌签/` 生成每人一份独立桌签
- 若用户无名单但有具体人数 → 提示用户给出人员姓名清单
- 若用户既无名单也不知参会人员 → 跳过桌签生成，不追问
- **仅询问一次**，用户明确说"不需要"后不再重复追问

> 桌签模板参考：`F:\省民宗委\收集\定稿学习\不确定是否可用的模板\桌签.dotx`
> 生成时以名单输入文件或标准输入传递人员姓名（每行一人），支持 `--combined` 合并为一个多页文档。

**第二步：md2docx 转换（管线内步骤）**

执行 `python -m gongwen md2docx 草稿.md -t <类型>`，输出为管线内临时文件（如 `_temp_draft.docx`），**不单独作为产物交付**。

```bash
python -m gongwen md2docx 草稿.md -o _temp_draft.docx -t <类型> --signer 落款单位 --date 日期
```

**第三步（可选）：正文段落首句加粗**

若需要按公文规范将正文段落的首句加粗，在 optimize 之前执行 `bold-first`：

```bash
python -m gongwen bold-first _temp_draft.docx -o _temp_draft.docx
```

> **注意**：`bold-first` 必须在 `optimize` 之前执行，以便 optimize 内的 `fix_bold_range` 规则能正确处理边界情况。若先 optimize 再 bold-first，会导致整段加粗问题。

**第四步：调用路径 A 的 optimize 套国标格式生成成品**

对第二步/第三步的临时文件执行 `python -m gongwen optimize _temp_draft.docx -t <类型>`，套用 GB/T 9704 国标格式（版头、版记、页码、字体、字号、行距等）。这一步是纯格式处理，不改文字内容。

```bash
python -m gongwen optimize _temp_draft.docx -o 成品.docx -t <类型>
```

**第五步：验证产物并交付**

执行 `python -m gongwen check 成品.docx -t <类型> --json` 进行格式合规检查。向用户报告格式合规情况和最终产物路径，提醒用户确认 `[]` 占位符处的内容。

**审稿流转（路径 C 交付附加流程）**：

交付后，Agent **必须**主动询问用户：

> 是否需要进入公文审稿流转流程？可生成审稿流转单，由对应角色逐级审核把关。
> - **完整版**（5角色）：撰稿人→业务审核→文字校对→综合核稿→领导签发（适用红头法定公文）
> - **精简版**（3角色）：撰稿人→业务+文字复合审核→综合负责人终审（适用内部材料）

若用户确认，Agent 执行：

```bash
# 完整版（默认）
python -m gongwen review 通知 -o 审稿流转单-通知.docx --title "关于XXX的通知"

# 精简版
python -m gongwen review 请示 --scheme compact -o 审稿流转单-请示.docx --title "关于XXX的请示"
```

生成后的审稿流转单包含：审稿角色表格（含意见栏/签名栏）、流转记录表、使用说明。用户打印后即可随文稿实物流转。**仅询问一次**，用户明确说"不需要"后不再重复追问。

```bash
python -m gongwen check 成品.docx -t <类型> --json
```

第二步至第四步使用同一 `-t` 类型。

> **推荐做法**：Agent 先根据用户需求在对话中生成 Markdown 草稿（使用下方段落模板），再走上述四步流程生成格式化成品并验证合规；需要一步到位时可直接 `python -m gongwen draft 草稿.md -o 成品.docx -t <类型>`（自动完成格式修复 + check 验证，P0 存在时退出码非 0）。

### 路径 C / 交付后的用户修改处理

路径 C 生成并交付后，根据用户反馈的不同类型分两种情况处理：

#### 情况一：内容不满意（措辞/结构/逻辑/语气）

> 用户说"改个措辞""润色一下""太啰嗦了""理顺内容""整体不太满意""逻辑不顺"
> → **统一走路径 B `optimize-content`**
>
> 路径 B 能处理从措辞润色到段落重组的全部内容修改需求。结构调整通过 `--background` 和 `--context` 参数传达重组意图，LLM 逐段生成最终文本，产物保留红色标注+删除线+修改说明。
>
> 用户确认优化内容后，即代表同意进入路径 A 做格式合规修复，Agent 直接执行 `check → optimize → check` 生成无标记成品文档，**无需额外询问**。

#### 情况二：格式不满意/不涉及内容

> 用户说"字体不对""行距有问题" → **走路径 A `optimize`**
> 仅修排版不改文字。

#### 定稿

> 用户确认内容与格式均无异议 → 进入五角色审稿机制（附流程图）
> 红头法定公文走完整版5角色，内部材料走精简版3角色。

---

**决策流程**（无"回 C 第一步"分支）：

```
路径 C 产出成品
    │
    ▼
用户反馈
    ├─ 内容不满意（措辞/结构/逻辑/语气）
    │   → 统一走路径 B optimize-content
    │     （三步思考法 + 修订内容 JSON）
    │   → 交付红色标注+删除线+楷体说明 对比版
    │   → 用户确认内容 ✅
    │     → 自动转路径 A：check → optimize → check
    │     → 交付无标记成品文档
    │
    ├─ 格式不满意（字体/行距/页边距）
    │   → 路径 A optimize
    │   → 交付无标记成品文档
    │
    └─ 满意/定稿
        → 五角色审稿机制
```

**核心设计思路**：
> 内容修改统一由路径 B 承载，所有修改痕迹可视、可追溯、可理解。用户确认内容后自动衔接路径 A 处理格式，无需二次确认。
> 结构与措辞不再分立——B 的三步思考法和 `background/context/perspective` 完全覆盖结构调整需求。

---

### 路径 C / 公文类型选择

不确定类型先 `python -m gongwen list-types`。用户描述模糊时，按以下映射引导：

| 用户意图 | 推荐类型 | `-t` 值 |
|----------|----------|---------|
| 告知事项、部署工作、传达政策 | 通知 | `notice` |
| 向上级请求指示/批准（人/钱/事） | 请示 | `request` |
| 向上级汇报工作/反映情况 | 报告 | `report` |
| 不隶属机关之间商洽/问答 | 函 | `letter` |
| 记载会议情况和议定事项 | 纪要 | `minutes` |
| 对重要事项做决策 | 决定 | `decision` |
| 表彰/批评/传达重要精神 | 通报 | `bulletin` |
| 公布应遵守或周知的事项 | 通告 | `announcement` |
| 答复下级请示事项 | 批复 | `reply` |
| 提出见解和处理办法 | 意见 | `opinion` |
| 年度/季度/专项工作总结 | 总结 | `summary` |
| 工作计划/实施方案 | 方案/计划 | `work_plan` |

---

### 路径 C / 段落结构模板

以下为常用公文类型的标准段落骨架。Agent 应按骨架生成 Markdown 草稿，用 `[ ]` 标注待填项，引导用户提供必要信息。

---

#### C1. 通知

##### C1a. 事项通知

**标题格式**：`关于[事项]的通知`

**主送**：`[主送机关全称/规范化简称]：`

**导语标准句式**：
```
为[目的/依据]，根据[政策依据/文件名称]，现就[事项]通知如下：
```

**正文骨架**：
```
一、[总体要求/背景意义]
[简要说明事项的重要性和必要性，1-2句]

二、[具体内容一]
[详细说明第一项具体安排或要求]

三、[具体内容二]
[详细说明第二项具体安排或要求]

四、[保障措施/工作要求]
[组织保障、督促检查、时间节点等]
```

**结尾规范用语**：`特此通知。` 或直接以正文最后一条结束（不加结尾语）。

**落款格式**：
```
                                   [发文机关全称]
                                   二〇二六年七月二十六日
```

##### C1b. 会议通知

**标题格式**：`关于召开[会议名称]的通知`

**主送**：`[参会单位/人员]：`

**导语标准句式**：
```
为[会议目的]，经[批准机关/领导]同意，定于[日期]召开[会议名称]。现将有关事项通知如下：
```

**正文骨架**：
```
一、会议时间
[年]年[月]月[日]日（星期[X]）[上/下]午[X]时[安排说明]

二、会议地点
[详细地址、楼层、会议室名称]

三、参会人员
[列出参会单位、职务要求、人数]

四、会议议程
（一）[议程一]
（二）[议程二]
（三）[议程三]

五、有关事项
（一）请各单位于[日期]前将参会人员名单报[报送单位/联系方式]。
（二）参会人员请提前[时间]入场，遵守会场纪律。
（三）[其他注意事项，如着装、材料准备等]
```

**结尾规范用语**：`特此通知。`

**落款格式**：同 C1a。

##### C1c. 任免通知

**标题格式**：`关于[姓名]等[人数]名同志任免职的通知` 或 `关于[姓名]同志任职的通知`

**主送**：`[主送机关]：`

**导语标准句式**：
```
经[决定机关/会议名称]研究决定：
```

**正文骨架**：
```
[姓名]同志任[职务名称]（[职级]）；
免去[姓名]同志的[原职务]；

[如多人，依次列出]
```

**结尾规范用语**：`特此通知。`

**落款格式**：同 C1a。

---

#### C2. 请示

##### C2a. 事项请示

**标题格式**：`关于[事项]的请示`

**主送**：`[上级机关全称]：`

**导语标准句式**：
```
为[目的/背景]，现就[事项]请示如下：
```

**正文骨架**：
```
一、请示事项
[简明说明需要批准的具體事项]

二、事由和依据
（一）[必要性说明]
[阐述为什么要做这件事，政策依据、上级要求、现实需要等]

（二）[可行性分析]
[已具备的条件、前期准备工作、风险评估等]

（三）[预期效果]
[预期达成的目标、产生的效益等]

三、具体方案
[方案要点，涉及人/财/物/时间/地点等关键要素]
```

**结尾规范用语**：
```
妥否，请批示。
```
或：
```
以上请示如无不妥，请转发[XXX]执行。
```

**落款格式**：
```
                                   [请示机关全称]
                                   二〇二六年七月二十六日
```

##### C2b. 经费请示

**标题格式**：`关于申请[项目/事项名称]经费的请示`

**主送**：同 C2a。

**导语标准句式**：
```
为[目的]，根据[依据]，特申请[项目名称]经费[金额]万元（大写：人民币[大写金额]元整）。现将有关情况请示如下：
```

**正文骨架**：
```
一、项目概况
[项目名称、实施单位、项目周期、总体目标]

二、经费需求及测算依据
（一）经费总需求：[金额]万元
（二）经费明细：
    1. [科目一]：[金额]万元，用于[用途]
    2. [科目二]：[金额]万元，用于[用途]
    3. [科目三]：[金额]万元，用于[用途]
（三）测算依据：[列出定价标准、市场询价、历史同类项目等]

三、预期效益
[经济效益/社会效益/工作效益]

四、资金筹措情况
[自筹/其他来源情况说明]
```

**结尾规范用语**：同 C2a。

---

#### C3. 报告

##### C3a. 工作报告

**标题格式**：`关于[工作名称/时间段]工作情况的报告`

**主送**：`[上级机关全称]：`

**导语标准句式**：
```
根据[依据/通知要求]，现将[工作名称]有关情况报告如下：
```

**正文骨架**：
```
一、工作进展情况
[整体概述，1-2句]

二、主要做法及成效
（一）[做法一]：[成效和数据]
（二）[做法二]：[成效和数据]
（三）[做法三]：[成效和数据]

三、存在的主要问题
（一）[问题一]
（二）[问题二]

四、下一步工作计划
（一）[计划一]
（二）[计划二]
（三）[计划三]
```

**结尾规范用语**：`特此报告。`

**落款格式**：
```
                                   [报告机关全称]
                                   二〇二六年七月二十六日
```

##### C3b. 情况报告

**标题格式**：`关于[事件/情况]的报告`

**主送**：同 C3a。

**导语标准句式**：
```
[时间]，[地点]发生[事件描述]。现将有关情况报告如下：
```

**正文骨架**：
```
一、基本情况
[事件发生时间、地点、涉及人员/单位、当前状态等客观事实]

二、已采取的措施
（一）[措施一]
（二）[措施二]
（三）[措施三]

三、原因分析
（一）[直接原因]
（二）[间接原因/深层问题]

四、下一步工作建议
（一）[建议一]
（二）[建议二]
```

**结尾规范用语**：`特此报告。`

---

#### C4. 函

##### C4a. 商洽函

**标题格式**：`关于[商洽事项]的函`

**主送**：`[主送机关全称]：`

**导语标准句式**：
```
为[目的/背景]，现就[事项]有关事宜函告如下，请予协助为盼。
```

**正文骨架**：
```
一、[事项背景/事由]
[简要说明来函原因和需要对方配合的事项]

二、[具体内容]
[商洽事项的具体安排、时间节点、分工要求]

三、[联系方式/后续安排]
[联系人、联系电话、反馈截止时间等]
```

**结尾规范用语**：
```
此函。
```
或：
```
盼复。此函。
```

**落款格式**：
```
                                   [发函机关全称]
                                   二〇二六年七月二十六日
```

##### C4b. 询问函

**标题格式**：`关于[询问事项]的函`

**主送**：同 C4a。

**导语标准句式**：
```
[来函背景说明]。现就以下事项函询，请予答复为盼。
```

**正文骨架**：
```
一、[询问事项一]
[具体问题描述，注意措辞不预设答案]

二、[询问事项二]
[具体问题描述]

三、[答复要求]
[请于[日期]前以书面形式函复，联系人：[姓名]，联系电话：[电话]]
```

**结尾规范用语**：`恳请函复。此函。`

##### C4c. 答复函

**标题格式**：`关于[答复事项]的复函`

**主送**：同 C4a。

**导语标准句式**：
```
贵单位《关于[原函标题]的函》（[原发文号]）收悉。经研究，现就有关问题函复如下：
```

**正文骨架**：
```
一、关于[问题一]
[答复意见]

二、关于[问题二]
[答复意见]

三、关于[问题三]
[答复意见]
```

**结尾规范用语**：`此复。` 或 `特此函复。`

---

#### C5. 纪要（会议纪要）

**标题格式**：`[会议名称]会议纪要` 或 `关于[会议议题]的会议纪要`

**主送**：会议纪要一般无主送机关（可不写），或以"发送："形式列出。

**导语标准句式**：
```
[时间]，[主持人姓名+职务]在[地点]主持召开[会议名称]。[参会人员名单]。现将会议有关情况纪要如下：
```

**正文骨架**：
```
一、[议题一]
[讨论情况概述]
议定事项：
（一）[议定事项一]
（二）[议定事项二]

二、[议题二]
[讨论情况概述]
议定事项：
（一）[议定事项一]
（二）[议定事项二]

三、会议要求
[后续工作安排、责任分工、完成时限]
```

**结尾规范用语**：会议纪要一般不加结尾语。可选：`以上纪要，请各单位遵照执行。`

**落款格式**：会议纪要一般不加落款单位和日期（已在导语中写明时间信息）。如需落款，格式同其他文种。

---

#### C6. 党组会议汇报材料（高频文种）

**标题格式**：`关于……工作进展情况及下一步工作建议的汇报`

**题头（第一行）**：`[单位名称]党组202X年第X次会议材料议题之X`（Times New Roman，题头用）

**汇报单位**：华文楷体，居中（位于标题和正文之间）

**主送**：`委党组：`

**导语标准句式**：
```
根据会议安排，现将……汇报如下。
```

**正文骨架**：
```
一、[工作背景/总体情况]
[简要说明背景、任务来源]

二、[主要工作进展情况]
（一）[进展一]
（二）[进展二]
（三）[进展三]

三、存在的主要问题
（一）[问题一]
（二）[问题二]

四、下一步工作建议
（一）[建议一]
（二）[建议二]
```

**关键格式特征**（区别于其他文种）：
| 元素 | 字体 | 字号 | 对齐 |
|------|------|------|------|
| 题头 | Times New Roman | 16pt | 左对齐（固定内容） |
| 标题 | 方正小标宋简体 | 22pt | 居中 |
| 汇报单位 | 华文楷体 | 16pt | 居中 |
| 主送 | 仿宋_GB2312 | 16pt | 顶格 |
| 一级标题 | 黑体 | 16pt | 顶格（一、二、三） |
| 二级标题 | 楷体_GB2312 | 16pt | 首行缩进2字（（一）（二）） |
| 正文 | 仿宋_GB2312 | 16pt | 首行缩进2字，两端对齐 |
| 落款单位 | 华文楷体 | 16pt | 居中 |
| 日期 | 仿宋_GB2312 | 16pt | 右对齐 |

**结尾规范用语**：汇报材料一般不加结尾语，或：`以上汇报，请审阅。`

---

#### C7. 讲话稿 / 主持词（高频文种）

**标题格式**：`[会议名称]主持词` 或 `在[会议名称]上的讲话`

**导语标准句式**（主持词）：
```
同志们：
现在开会。
今天召开[会议名称]，主要任务是[会议目的/任务]。
```

**正文骨架**（讲话稿）：
```
同志们：

今天我们召开[会议名称]，主要任务是[概括会议目的]。下面，我讲几点意见。

一、[总体要求/提高认识]
（一）……[分析形势、强调重要性]
（二）……[统一思想、提高认识]

二、[重点任务/工作部署]
（一）[任务一]
（二）[任务二]
（三）[任务三]

三、[组织保障/工作要求]
（一）[要求一]
（二）[要求二]
（三）[要求三]

同志们，[总结号召，鼓舞士气]。

谢谢大家！
```

**主持词典型结构**：
```
一、宣布开会
[宣布会议开始，介绍会议背景和目的]

二、介绍参会人员
[介绍出席领导、参会单位及人员]

三、会议议程
[按议程逐项主持]

四、总结讲话
[对会议进行简要总结，提出贯彻落实要求]

五、宣布散会
```

> **参考样例**：机关单位工作会议主持词完整模板（可直接套用，替换 `[xxx]` 占位内容）

图一：会议前半段（开场 → 汇报 → 引入讲话）
```
一、宣布开会
同志们：
现在开会。
今天召开[会议名称]，主要任务是：学习贯彻上级关于[主题]的决策部署和工作要求，
回顾总结[时间段]工作，分析当前形势和存在的问题，统筹安排下一阶段重点任务。

二、介绍参会人员
出席今天会议的有：[出席领导职务+姓名]，机关全体人员、各单位主要负责同志等。

三、会议议程
今天的会议共有两项议程：
  第一项：请各部门汇报[主题]工作；
  第二项：请[领导职务+姓名]作重要讲话。

四、汇报环节（过渡语 · 循环使用）
"首先，请[部门一]汇报工作。"
"下面，请[部门二]汇报工作。"
"现在，请[部门三]汇报工作。"

五、汇报点评
刚才，[X个]部门分别汇报了[主题]工作。
总的来看，大家的汇报客观准确——成绩说得透、问题找得准、思路理得清。
回顾过去[时间段]，各项工作取得了明显成效，值得肯定；
分析存在的问题，大家的认识是深刻的、分析是透彻的；
下一步的谋划，目标明确、思路清晰、措施有力。
希望大家相互借鉴、取长补短，把好的做法坚持下去，把存在的问题解决到位。

六、引入领导讲话
本次会议的核心要义，集中体现在[领导职务+姓名]的重要讲话中。
下面，让我们以热烈的掌声，请[领导职务+姓名]作重要讲话。
（[领导讲话]）

七、贯彻落实讲话
刚才，[领导职务+姓名]围绕[主题]，从三个层面作了深刻阐述和全面部署，
站位高远、思想深刻、要求具体，具有很强的指导性和针对性，
大家要认真学习领会，结合实际抓好贯彻落实。
```

图二：会议后半段（贯彻落实 → 总结号召）
```
八、三点强调

  第一，迅速传达，推动会议精神落地见效。
  会后，各部门要立即组织传达学习本次会议精神，特别是[领导职务+姓名]的重要讲话，
  把思想和行动统一到会议的部署要求上来，确保会议精神传达到位、理解到位。

  第二，把握重点，聚焦关键任务落地见效。
  对照会议确定的目标任务，逐项分解、逐项落实。
  要聚焦[核心任务一]、[核心任务二]等重点工作，制定时间表、路线图，
  确保各项任务按时保质完成。

  第三，压实责任，强化组织保障落地见效。
  各部门主要负责同志要亲自抓、负总责，分管领导要具体抓、抓到位。
  建立健全工作台账，实行周调度、月通报，确保各项工作有序推进。

九、总结号召
同志们，做好[主题]工作，任务艰巨、责任重大。
让我们坚定信心、锐意进取，发扬实干精神，
推动各项工作取得新成效，为[总体目标]作出新的更大贡献！

散会。
```

> **参考样例**：年度工作部署会主持词（三段式结构：开场 → 议程推进 → 总结贯彻）

```
同志们：
现在开会。

今天召开[会议名称]，主要任务是：深入学习贯彻[上级精神]，回顾总结[时间段]工作，
分析当前形势，安排部署[年度/下一阶段]重点任务，
动员全体干部职工统一思想、凝聚共识、真抓实干，
推动[主题]工作再上新台阶。

出席今天会议的有：[出席领导]，机关全体干部职工，各单位主要负责同志。

今天的会议共有[X]项议程。

首先，请[部门/领导]部署[任务一]。
（[发言]）

下面，请[部门/领导]部署[任务二]。
（[发言]）

现在，进行最后一项议程，请[主要领导职务+姓名]作重要讲话。
（[领导讲话]）

刚才，[领导姓名]从[X]个方面系统总结了[时间段]工作，
站位高远、要求明确，总结全面、分析深刻、部署具体，
具有很强的指导性和可操作性，大家要认真学习领会，抓好贯彻落实。

下面，就贯彻落实本次会议精神，我提三点意见：

第一，迅速传达，在统一思想中凝聚合力。
会后各部门要立即组织传达学习本次会议精神，特别是[领导姓名]的重要讲话，
把思想和行动统一到会议决策部署上来，确保会议精神传达到每一个干部职工。

第二，分解任务，在压实责任中推动落实。
对照会议确定的目标任务，逐项分解、逐项落实。
要结合本部门实际，制定时间表、路线图，明确责任人，
实行挂图作战、销号管理，确保各项任务落地见效。

第三，真抓实干，在攻坚克难中开创新局。
[年度/下一阶段]工作任务重、要求高，各部门要发扬钉钉子精神，
一项一项抓推进、一件一件抓落实。
领导干部要带头深入一线、靠前指挥，推动各项工作落到实处、取得实效。

同志们，做好[主题]工作，责任重大、使命光荣。
让我们进一步统一思想、明确目标、凝聚共识，
以更加坚定的信心、更加有力的举措、更加务实的作风，
推动[主题]工作取得新的更大成效！

散会。
```

**常见句式库**：
| 场景 | 常用句式 |
|------|---------|
| 宣布开会 | `现在开会。` / `同志们，现在开始开会。` |
| 介绍议程 | `今天的会议共有[X]项议程：` |
| 请人发言 | `下面，请[姓名/单位]发言。` / `下面，进行会议第[X]项议程：` |
| 总结 | `刚才，[姓名/单位]从[X]个方面……讲得都很好。` / `会议至此圆满结束。` |
| 宣布散会 | `散会。` |

**格式特征**：

| 元素 | 字体 | 字号 | 对齐 | 说明 |
|------|------|:----:|------|------|
| 标题 | 方正小标宋简体 | 24pt（比公文标题略大） | 居中 | 主持词/讲话稿主标题 |
| 主持人信息 | 楷体_GB2312 | 18pt | 居中 | "主持人：[姓名]" 或 "[职务+姓名]" 单独一行 |
| 时间 | 楷体_GB2312 | 18pt | 居中 | "2026年7月X日" 单独一行 |
| 称谓（同志们） | 仿宋_GB2312 | 18pt | 两端对齐 | 顶格书写 |
| 正文 | 仿宋_GB2312 | 18pt | 两端对齐，首行缩进2字符 | |
| 讲话要点标题 | 黑体 | 18pt | 首行缩进2字 | 一、二、三 等层次标题 |
| 议程导引 | 仿宋_GB2312 | 18pt | 两端对齐 | "首先""下面""现在"等过渡语 |

> **讲话稿（speech）与主持词（host_speech）格式差异**（以筹委会最终版定稿为准）：
> - 页边距：讲话稿用国标默认（上3.7/下3.5/左2.8/右2.6cm）；主持词与普通公文一致（上2.8/下2.8/左2.7/右2.7cm）。
> - 署名/日期行距：讲话稿 35pt；主持词 30pt（均楷体_GB2312 18pt 居中）。
> - 正文：均为仿宋_GB2312 18pt 不加粗、行距 30pt exact、首行缩进 2 字；主持词议程引导句可局部加粗。
> - 一级标题（一、…）黑体 18pt；二级标题（第一…/一是…）楷体_GB2312 18pt，均为行距 30pt、首行缩进 2 字。

---

#### C8. 调研函 / 征求意见函（高频文种）

**标题格式**：`关于征求[事项]意见的函`

**正文骨架**：
```
[主送单位]：

为[目的]，根据[依据]，现将[事项]印发你们，请结合实际提出修改意见，并于[日期]前书面反馈至[反馈单位]。

附件：1.[附件名称一]
      2.[附件名称二]
```

**常见变体（"致函"格式）**：

抬头用发文机关全称红头（方正小标宋简体 48-51pt，居中），次行发文字号，再行标题。

**结尾规范用语**：`此函，请予支持为盼。` / `恳请函复。`

**落款格式**：
```
                                   [发文机关全称]
                                   二〇二六年七月二十六日
```

**联系人/电话格式**（函件特有）：
```
（联系人：[姓名]；联系电话：[电话号码]）
```

---

#### C9. 会议议题材料（高频文种）

> **与会议通知的区别**：会议通知是发出去召集参会、需反馈人员名单的正式发文；会议议题材料是根据已收到的参会名单拟定的开会用材料，放在桌上供参会人使用。通知走发文流程（红头、文号），议题材料走会务流程（题头、议题编号）。

**题头（固定格式）**：`[单位名称]党组202X年第X次会议材料议题之X`（Times New Roman 16pt，左对齐）

**标准结构**：

```
[单位名称]党组202X年第X次会议材料议题之X          ← 题头，Times New Roman 16pt

关于……工作进展情况及下一步工作建议的                ← 方正小标宋简体 22pt 居中
汇  报                                               ← 两行标题，同上
XX处                                                 ← 华文楷体 16pt 居中

根据会议安排，现将……汇报如下。                       ← 正文仿宋 16pt

一、……工作进展情况                                    ← 一级标题 黑体 16pt
（一）……                                              ← 二级标题 楷体 16pt
（二）……

二、存在的主要问题
（一）……
（二）……

三、下一步工作建议
（一）……
（二）……
```

**四种议题式样**：

| 式样 | 适用场景 | 正文结构 |
|------|---------|---------|
| 式样1 | 传达会议精神 | 会议概况 → 主要精神（会议认为/指出/强调/要求）→ 贯彻落实建议 |
| 式样2 | 贯彻文件精神 | 文件概况 → 主要内容 → 贯彻落实建议 |
| 式样3 | 审议文件方案 | 起草背景 → 主要内容 → 征求意见情况 → 需要说明的事项 → 请求事项 |
| 式样4 | 汇报工作进展 | 工作概况 → 进展情况 → 存在问题 → 下一步建议 |

**格式特征**：

| 元素 | 字体 | 字号 | 对齐 |
|------|------|:----:|------|
| 题头 | Times New Roman | 16pt | 左对齐 |
| 标题 | 方正小标宋简体 | 22pt | 居中 |
| 汇报单位 | 华文楷体 | 16pt | 居中 |
| 一级标题（一、二、三） | 黑体 | 16pt | 两端对齐 |
| 二级标题（（一）（二）） | 楷体_GB2312 | 16pt | 首行缩进2字符 |
| 正文 | 仿宋_GB2312 | 16pt | 首行缩进2字符，两端对齐 |
| 西文/数字 | Times New Roman | 16pt | — |

**常见用语**：

| 场景 | 常用句式 |
|------|---------|
| 导语 | `根据会议安排，现将……汇报如下。` |
| 传达会议精神 | `X月X日，……会议在……召开。会议认为……会议指出……会议强调……会议要求……` |
| 审议文件 | `现将《……（送审稿）》起草情况汇报如下。` / `提请会议审议《……》。` |
| 汇报进展 | `现将……工作有关情况汇报如下。` / `一是…… 二是……` |
| 请求 | `提请会议审议。会后，我们将根据会议精神进一步修改完善。` |

---

#### C10. 会议方案（以函发出）

> **与会议通知的关系**：会议方案是包含会议通知的方案性文件，通常以函的形式发往相关单位。通知是"请你来参会"，方案是"会议安排如下"——方案更完整，含时间、地点、议程、参会单位、任务分工、保障措施等。方案以函的形式发出，主送相关单位。

**发文形式**：以函发出，需发文字号、红头（方正小标宋简体 48-51pt）

**完整结构**：

```
发文机关红头                                     ← 方正小标宋简体 48pt 居中
发文字号                                         ← Times New Roman 16pt

关于召开[会议名称]会议方案                        ← 方正小标宋简体 22pt 居中

[主送单位]：

为[目的]，根据[依据]，经[批准机关]同意，现定于[时间]召开[会议名称]会议，并制定如下方案。

一、会议时间
[年]年[月]月[日]日（星期[X]）[上/下]午[X]时，会期[X]天

二、会议地点
[详细地址、会议室名称]

三、参会人员
（一）[单位/人员类别一]：[人数]人
（二）[单位/人员类别二]：[人数]人
（三）[单位/人员类别三]：[人数]人
（共约[X]人）

四、会议议程
（一）[议程一]：[内容说明，约X分钟]
（二）[议程二]：[内容说明，约X分钟]
（三）[议程三]：[内容说明，约X分钟]
（四）[研讨/交流]
（五）[总结讲话]

五、有关事项
（一）请各单位于[日期]前将参会人员名单报[报送单位]。
（二）参会人员请提前[X]分钟入场。
（三）[其他事项]

六、组织保障
（一）[责任分工]
（二）[后勤保障]
（三）[安全预案]

附件：[相关材料清单]

                                   [发文机关全称]
                                   二〇二六年七月二十八日
```

**格式特征**：

| 元素 | 字体 | 字号 | 对齐 |
|------|------|:----:|------|
| 红头（发文机关） | 方正小标宋简体 | 48-51pt | 居中 |
| 发文字号 | Times New Roman | 16pt | — |
| 标题 | 方正小标宋简体 | 22pt | 居中 |
| 主送单位 | 仿宋_GB2312 | 16pt | 顶格 |
| 一级标题（一、二、三） | 黑体 | 16pt | 顶格 |
| 正文 | 仿宋_GB2312 | 16pt | 首行缩进2字符 |
| 落款/日期 | 仿宋_GB2312 | 16pt | 右对齐 |

**常见用语**：

| 场景 | 常用句式 |
|------|---------|
| 导语 | `为…，根据…，经…同意，现定于…召开…会议，并制定如下方案。` |
| 议程表述 | `（一）[议程]：[内容说明，约X分钟]` |
| 参会人数 | `共约[X]人` |
| 回执要求 | `请各单位于[日期]前将参会人员名单报[报送单位]` |
| 结尾 | `此函，请予支持为盼。` |

各类公文的常用开头和结尾标准句式速查：

| 文种 | 常用开头 | 常用结尾 |
|------|----------|----------|
| 通知 | 为…，根据…，现就…通知如下： | 特此通知。 |
| 请示 | 为…，现就…请示如下： | 妥否，请批示。/ 请审批。 |
| 报告 | 根据…，现将…报告如下： | 特此报告。 |
| 函（去函） | 为…，现就…函告如下： | 此函。/ 盼复。 |
| 函（复函） | 贵单位《…》（文号）收悉。…函复如下： | 此复。/ 特此函复。 |
| 批复 | 你单位《…》（文号）收悉。经研究，批复如下： | 此复。 |
| 纪要 | [时间] [主持人]在[地点]主持召开… | （一般无结尾） |
| 通报 | 为…，现将…通报如下： | 特此通报。 |
| 决定 | 根据…，决定如下： | 本决定自发布之日起施行。 |
| 意见 | 为…，现提出如下意见： | （一般无固定结尾） |

### 路径 C / 风格选择

生成公文时同样适用路径 B 的 8 种风格词典。Agent 应根据公文类型和用户要求选择匹配风格：

| 公文场景 | 推荐风格 | 依据 | 常用句式/用语特征 |
|----------|----------|------|-----------------|
| 向下级部署工作的通知 | 庄重严谨 + 简洁精炼 | 权威简洁 | `为…，根据…，现就…通知如下：` |
| 向上级的工作报告 | 务实汇报 + 逻辑严密 | 数据驱动，条理清晰 | `根据…，现将…报告如下：` / `特此报告。` |
| 向平级单位的函 | 庄重得体 | 尊重谦逊 | `此函，请予支持为盼。` / `恳请函复。` |
| 请示 | 请示恳切 | 有理有据 | `妥否，请批示。` / `以上请示如无不妥，请转发…` |
| 动员部署 | 动员激励 + 庄重严谨 | 鼓动力与权威感 | `同志们，…下面，我讲几点意见。` |
| **党组会汇报** | 务实汇报 + 庄重严谨 | 事实+数据+问题+建议 | `根据会议安排，现将…汇报如下。` / `以上汇报，请审阅。` |
| **讲话稿/主持词** | 庄重得体 + 动员激励 | 口语化与正式表达结合 | `同志们，现在开会。` / `下面，我就…讲几点意见。` / `散会。` |
| **调研函/征求意见函** | 庄重得体 | 平行文，平等协商 | `为…，现将…印发你们，请提出修改意见。` / `此函。` |
| 年度总结 | 总结回顾 + 务实汇报 | 客观全面 | `现将…总结如下。` / `特此总结。` |

---

## 附录一：25 种公文类型（`-t` 参数）
|--------|--------|--------|--------|
| `notice` | 通知 | `request` | 请示 |
| `report` | 报告 | `letter` | 函 |
| `meeting` | 会议纪要 | `minutes` | 纪要 |
| `decision` | 决定 | `announcement` | 通告 |
| `notice_public` | 公告 | `command` | 命令 |
| `bulletin` | 通报 | `bill` | 议案 |
| `reply` | 批复 | `instruction` | 指示 |
| `regulation` | 制度 | `communique` | 公报 |
| `opinion` | 意见 | `summary` | 总结 |
| `work_plan` | 方案/计划 | `table_sign` | 桌签 |
| `technical_proposal` | 技术方案 | `resolution` | 决议 |
| `speech` | **讲话稿** | `news` | **新闻稿/简报** |
| `host_speech` | **主持词** | | |

> **news（新闻稿/简报）特殊规则**（提质方案 v2.1 问题一）：标题为**事件陈述式**（≤35 字，含时间/地点/事件三要素，不做精简），非法定公文"事由+文种式"（≤20 字）。标题支持两种模式：专题会议式（`{部门/工作}+{会议类型}+在{地点}+召开`）与常规会议式（`{机构}+{部门}+第{序次}次+{会议类型}+召开`）。不检查主送机关/落款/附件说明等法定要素；必检：人名/职务/机构名准确性、时间一致性、逻辑闭环（听取→指出→强调→要求）、稿源/编辑信息。

不确定类型先 `python -m gongwen list-types`。

---

## 附录二：跨平台调用说明

本 Skill 支持两种调用方式，在 CLI 和 AI 对话（如豆包 / Marvis / Coze）中均可用。

### 方式一：CLI 直接调用

适用于本地命令行或脚本自动化：

```bash
python -m gongwen optimize 文件.docx -o 成品.docx -t report
python -m gongwen optimize-content 文件.docx --changes 修订内容
```

### 方式二：Agent 对话调用，无执行权限

适用于 AI 对话助手（豆包、Marvis 等），Agent 应：

1. 先走「用户交互指引」三步确认路径
2. 用 `shell_executor` 执行 CLI 命令（路径 A/C）或按路径 B 流程逐步处理
3. 路径 B 时：先用 python-docx 读格式 → LLM 分析 → 写 修订内容 → 调 `optimize-content` → 告知用户产物路径
4. 执行后验证产物并展示关键指标（修复数、变更数、格式问题）

### 路径 B 对话流程示例

```
用户: 帮我优化这个公文的表达
Agent: [先确认是格式优化还是内容优化]
用户: 内容优化
Agent: [读取原文档格式 → LLM 分析生成 修订内容 → 执行 optimize-content]
Agent: 已生成对比版，共 6 处变更，字体/行距均继承原文档。
      文件路径：C:\...\关于XX的通知+庄重严谨+2026-07-25+v1.docx
      文档末尾已标注 AI 生成声明。
Agent: 是否需要对此对比文档走格式优化，生成排版合规的无标记成品？
用户: 要 / 不用
      → "要" → 独立执行路径 A，生成 `修订版+关于XX的通知+2026-07-25+v1.docx`
      → "不用" → 流程结束
```

---

## 附录三：常见问题与排错

| 问题 | 原因 | 解决 |
|------|------|------|
| 对比文档字体/行距与原文档不一致 | `get_effective_font` 回退到了 ASCII 字体 | 检查 `parser_format.py` 的 `_safe_pt2` 和行距解析 |
| 删除线不生效 | `RunFormat` 缺少 `strikethrough` 字段或 pipeline 未传递 | 确保 models.py → generator.py → optimizer.py 三处都处理了 strikethrough |
| 修订内容 JSON 解析失败 | 中文引号/特殊字符未正确转义 | 用 `json.dump` 写入，确保 `ensure_ascii=False` |
| 对比文档末尾无声明 | CLI 传了 `--disclaimer ""` 或 None 覆盖默认值 | 不传 `--disclaimer` 即使用默认声明 |

---

## 附录四：使用红线

- 不伪造、冒用真实机关正式发文；生成物仅为草稿，正式发文须走审核流程
- 不编造政策依据、数据、结论、人事信息（领导姓名/机构全称/职务/文号/人物姓名）；缺失信息用 `XXX` 占位
- 涉密材料先脱敏再处理
- 内容优化必须逐段标注修改说明和依据，不允许无痕覆盖

---

## 附录五：项目仓库

- **父项目**（桌面应用 + 完整引擎）：https://github.com/linhut/document-ai-assistant
- **本 Skill**（精简 CLI 版）：嵌入在 `document-skills/gongwen-skill/` 目录
- 引擎核心目录：`engine/core/document/`（parser / generator / modifier / models / font_utils）

**版权**：(c) 2026 Jose AI（https://www.linhut.cn），MIT 许可证。完整命令与架构见 `REFERENCE.md`。