Gongwen Skill

公文全流程处理专家（GB/T 9704）

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

一、执行前路径声明

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

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

环境适配规则：

格式兼容性：工具链基于 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 全流程。

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

Copy code
❌ 路径 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 平台加载使用：

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

1. 读取 gongwen 包顶部的 __version__ 常量，获取本地版本号
2. 告知用户：当前加载 gongwen-skill v{__version__}
3. 版本自检（不能只用本地 git describe——它只读本地可达 tag，未 fetch 时会误判本地即最新；也不能只查单一仓库——网络抖动会导致误判）：

   bashCopy code
   # 首选：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 对比：

     bashCopy code
     git -C "<skill安装目录>" describe --tags --abbrev=0
     

   • 若 skill 目录不在 git 管理下，应告知用户"无法执行版本对比，建议手动检查 GitHub 更新"
   • 版本对比结果若发现本地版本落后于最新 tag，应在执行前警告用户
4. 若权威渠道最新版本 > 本地 __version__，提示用户：

   Copy code
   有更新可用：最新版 {最新版}，当前 {本地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）：

bashCopy code
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 恢复上下文继续

命令速查：

bashCopy code
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 模板名 套用该格式。

路径判断规则

「优化」消歧强制规则： 用户说"优化一下""帮我改改""调整内容"等模糊表述时，Agent 必须先追问：

您是希望改文字内容（润色措辞/调整表述），还是修排版格式（字体/行距/页边距）？

• 改文字内容 + 有文档 → 路径 B
• 改文字内容 + 无文档 → 路径 C
• 修排版格式 → 路径 A

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

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

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

本工具支持五种处理方式：

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

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

Copy code
用户消息
  │
  ├─ 包含"优化/润色/改/调整" + 指定了已有文档
  │   └── 识别为路径 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 需要把交互决策委托给工具时，使用向导：

Copy code
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）：

  jsonCopy code
  {"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 必须先理解再行动，不得机械匹配关键词：

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

2. 充分利用 skill 知识库

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

强制规则：

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

3. 网络政策信息获取

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

获取规则：

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

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

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

协同规则：

• 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 绝对禁止编造的信息类别

9.2 处理规则

9.3 唯一例外（合法来源）

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

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

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

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

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

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

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

路径 B 的绝对禁令：

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

路径 A 的产物标准：

• 输出干净文档，无任何 diff 标记、无修改说明、无颜色标记、无 AI 声明
• 仅含格式修复后的正文内容

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

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

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

示例对比：

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

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

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

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

实操规范：

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

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

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

规则说明：

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

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

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

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

评分处理规则：

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

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

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

三、要素分层体系

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

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

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

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

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

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

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

常见模糊意见映射表：

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

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

5.1 审稿角色设置

5.2 角色职责详解

①撰稿人（初稿责任人｜第一责任人）

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

②业务审核人（业务处室 / 部门负责人）

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

③文字校对岗（文稿编审 / 综合岗，可搭配 gongwen-skill 工具）

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

④综合核稿人（综合办 / 专班综合负责人）

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

⑤签发领导（最终审定人）

• 审定文稿核心观点、重大工作安排
• 确认是否同意对外报送、印发
• 作出终审修改意见，确认定稿

5.3 两套审稿方案

5.4 配套关键机制

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

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

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

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

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

汇报格式：

Copy code
📋 合规自检报告
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 产出无标记成品，不保留修改痕迹

完整流程

bashCopy code
# 三步走
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步：验证

检查结果分级

可选增强

bashCopy code
# 注入版头版记页码
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）

命令

bashCopy code
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 的区别

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 误判）。以下参数可控制：

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

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

🧭 向导式交互

🏗️ 生成与模板

🔍 解析与检查

🔧 修复与优化

📄 版式注入

🧰 特殊工具

🩺 诊断与修复

⚙️ 规则管理

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

路径 B：内容优化

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

⚠️ 执行前检查清单（必须逐项确认，缺一不可）：

• □ 用户有现成文档需要优化文字内容
• □ 已确认用户要改的是文字措辞（而非排版格式）
• □ 已确认内容优化方向（background/context/perspective）
• □ 已告知用户：路径 B 产出红色标注+删除线+楷体说明的对比版
• □ 用户确认内容后自动转路径 A 修格式，无需额外询问

完整流程

Copy code
第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 优化文本时的参考约束。

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

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

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

修订内容 格式：

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

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

reference 字段引用规范（严禁虚构）：

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

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

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

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

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

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

Copy code
第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 变更日志供后续参考

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

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

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

Agent 实施规则：

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

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

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

批注模式（--comment-mode）

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

bashCopy code
python -m gongwen optimize-content 原文.docx --changes changes.json --apply --comment-mode

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

修订追踪（--tracked-change）

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

bashCopy code
python -m gongwen optimize-content 原文.docx --changes changes.json --apply --tracked-change

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

完整审校（full-review）

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

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

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

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

bashCopy code
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）

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

bashCopy code
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 按用户需求选用：

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

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

bashCopy code
# 完整版（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 与 P2 冲突时 P0 优先。例如用户说"语言通俗"但公文类型规范要求"庄重严谨"→ 以用户"语言通俗"为准，可在style字段标注"简洁明快（用户指定）"。

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

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

严禁：

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

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

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

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"部分写作规范——具体规范说明。

完整示例：

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

修改原则：

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

路径 B / 多轮优化规则

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

Copy code
第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 的映射规则：

合成规则：

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

示例如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

规则一：优先级裁决

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

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

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

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

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

规则三：同段不拆分原则

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

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

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

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

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

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

风格组合典型场景速查

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

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

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

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

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

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

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

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

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

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

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

产出要求：每个 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 字段，列出：

  jsonCopy code
  "_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 交付产品前，必须逐项审计以下五点并汇报结果：

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

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

bashCopy code
# 自动命名：{原文档名}+{内容风格}+{日期}+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生成，仅供参考） 灰色小字

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

bashCopy code
# 覆盖默认声明
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 在写草稿前必须按以下优先级确认关键事实信息：

搜索执行规则：

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

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

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

交互原则：

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

第一步：编写生成 Markdown 草稿

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

表格与附件处理规则：

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

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

Copy code
正文末尾
（空一行）
附件：[编号.]附件名称                          ← 仿宋_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 ./桌签/ 生成每人一份独立桌签
• 若用户无名单但有具体人数 → 提示用户给出人员姓名清单
• 若用户既无名单也不知参会人员 → 跳过桌签生成，不追问
• 仅询问一次，用户明确说"不需要"后不再重复追问

桌签模板由工具内置模板（engine/templates/table_sign.dotx）自动生成，无需外部模板文件。 生成时以名单输入文件或标准输入传递人员姓名（每行一人），支持 --combined 合并为一个多页文档。

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

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

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

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

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

bashCopy code
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 国标格式（版头、版记、页码、字体、字号、行距等）。这一步是纯格式处理，不改文字内容。

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

第五步：验证产物并交付

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

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

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

是否需要进入公文审稿流转流程？可生成审稿流转单，由对应角色逐级审核把关。

• 完整版（5角色）：撰稿人→业务审核→文字校对→综合核稿→领导签发（适用红头法定公文）
• 精简版（3角色）：撰稿人→业务+文字复合审核→综合负责人终审（适用内部材料）

若用户确认，Agent 执行：

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

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

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

bashCopy code
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 第一步"分支）：

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

核心设计思路：

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

路径 C / 公文类型选择

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

路径 C / 段落结构模板

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

C1. 通知

C1a. 事项通知

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

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

导语标准句式：

Copy code
为[目的/依据]，根据[政策依据/文件名称]，现就[事项]通知如下：

正文骨架：

Copy code
一、[总体要求/背景意义]
[简要说明事项的重要性和必要性，1-2句]

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

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

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

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

落款格式：

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

C1b. 会议通知

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

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

导语标准句式：

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

正文骨架：

Copy code
一、会议时间
[年]年[月]月[日]日（星期[X]）[上/下]午[X]时[安排说明]

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

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

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

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

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

落款格式：同 C1a。

C1c. 任免通知

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

主送：[主送机关]：

导语标准句式：

Copy code
经[决定机关/会议名称]研究决定：

正文骨架：

Copy code
[姓名]同志任[职务名称]（[职级]）；
免去[姓名]同志的[原职务]；

[如多人，依次列出]

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

落款格式：同 C1a。

C2. 请示

C2a. 事项请示

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

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

导语标准句式：

Copy code
为[目的/背景]，现就[事项]请示如下：

正文骨架：

Copy code
一、请示事项
[简明说明需要批准的具體事项]

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

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

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

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

结尾规范用语：

Copy code
妥否，请批示。

或：

Copy code
以上请示如无不妥，请转发[XXX]执行。

落款格式：

Copy code
                                   [请示机关全称]
                                   二〇二六年七月二十六日

C2b. 经费请示

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

主送：同 C2a。

导语标准句式：

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

正文骨架：

Copy code
一、项目概况
[项目名称、实施单位、项目周期、总体目标]

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

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

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

结尾规范用语：同 C2a。

C3. 报告

C3a. 工作报告

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

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

导语标准句式：

Copy code
根据[依据/通知要求]，现将[工作名称]有关情况报告如下：

正文骨架：

Copy code
一、工作进展情况
[整体概述，1-2句]

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

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

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

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

落款格式：

Copy code
                                   [报告机关全称]
                                   二〇二六年七月二十六日

C3b. 情况报告

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

主送：同 C3a。

导语标准句式：

Copy code
[时间]，[地点]发生[事件描述]。现将有关情况报告如下：

正文骨架：

Copy code
一、基本情况
[事件发生时间、地点、涉及人员/单位、当前状态等客观事实]

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

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

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

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

C4. 函

C4a. 商洽函

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

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

导语标准句式：

Copy code
为[目的/背景]，现就[事项]有关事宜函告如下，请予协助为盼。

正文骨架：

Copy code
一、[事项背景/事由]
[简要说明来函原因和需要对方配合的事项]

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

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

结尾规范用语：

Copy code
此函。

或：

Copy code
盼复。此函。

落款格式：

Copy code
                                   [发函机关全称]
                                   二〇二六年七月二十六日

C4b. 询问函

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

主送：同 C4a。

导语标准句式：

Copy code
[来函背景说明]。现就以下事项函询，请予答复为盼。

正文骨架：

Copy code
一、[询问事项一]
[具体问题描述，注意措辞不预设答案]

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

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

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

C4c. 答复函

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

主送：同 C4a。

导语标准句式：

Copy code
贵单位《关于[原函标题]的函》（[原发文号]）收悉。经研究，现就有关问题函复如下：

正文骨架：

Copy code
一、关于[问题一]
[答复意见]

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

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

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

C5. 纪要（会议纪要）

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

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

导语标准句式：

Copy code
[时间]，[主持人姓名+职务]在[地点]主持召开[会议名称]。[参会人员名单]。现将会议有关情况纪要如下：

正文骨架：

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

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

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

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

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

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

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

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

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

主送：委党组：

导语标准句式：

Copy code
根据会议安排，现将……汇报如下。

正文骨架：

Copy code
一、[工作背景/总体情况]
[简要说明背景、任务来源]

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

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

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

关键格式特征（区别于其他文种）：

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

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

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

导语标准句式（主持词）：

Copy code
同志们：
现在开会。
今天召开[会议名称]，主要任务是[会议目的/任务]。

正文骨架（讲话稿）：

Copy code
同志们：

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

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

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

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

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

谢谢大家！

主持词典型结构：

Copy code
一、宣布开会
[宣布会议开始，介绍会议背景和目的]

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

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

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

五、宣布散会

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

图一：会议前半段（开场 → 汇报 → 引入讲话）

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

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

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

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

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

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

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

图二：会议后半段（贯彻落实 → 总结号召）

Copy code
八、三点强调

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

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

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

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

散会。

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

Copy code
同志们：
现在开会。

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

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

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

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

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

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

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

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

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

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

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

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

散会。

常见句式库：

格式特征：

讲话稿（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. 调研函 / 征求意见函（高频文种）

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

正文骨架：

Copy code
[主送单位]：

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

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

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

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

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

落款格式：

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

联系人/电话格式（函件特有）：

Copy code
（联系人：[姓名]；联系电话：[电话号码]）

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

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

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

标准结构：

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

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

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

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

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

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

四种议题式样：

格式特征：

常见用语：

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

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

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

完整结构：

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

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

[主送单位]：

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

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

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

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

四、会议议程
（一）[议程一]：[内容说明，约X分钟]
（二）[议程二]：[内容说明，约X分钟]
（三）[议程三]：[内容说明，约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 直接调用

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

bashCopy code
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 对话流程示例

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

附录三：常见问题与排错

附录四：使用红线

• 不伪造、冒用真实机关正式发文；生成物仅为草稿，正式发文须走审核流程
• 不编造政策依据、数据、结论、人事信息（领导姓名/机构全称/职务/文号/人物姓名）；缺失信息用 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。