公文格式排版技能 (doc-formatter)

> 用它能解决什么：公文/报告排版又乱又慢？选好模板点一下就出合规 docx——目录、页码、标题层级全自动，半小时的活 3 分钟搞定。

定位与示例说明（重要）

本技能定位为标准公文范本 / 演示生成器，不是"给任意机关自动写公文"的通用生成器：

• 内置样本（如河南九天封头、国有资产清查盘活）仅用于演示红头 + 标题 + 署名结构与格式复核流程，正文内容为占位示例，不代表任何真实公文。
• 换单位/换文种时：改 scripts/build_doc.py 顶部常量（ORG_NAME / DOC_TITLE / LEADER_GROUP 等）即可替换红头与标题；正文须由用户按真实公文自写，技能不代编任意机关的正式公文内容。
• 合规责任：正式对外公文请用户自行核对 GB/T 9704-2012 与本单位发文规范；技能只保证"格式结构合规"，不保证"内容合规"。

外部依赖与降级声明

• 外部依赖：本地 Python 环境（python-docx）用于构建 docx；可选 pandoc 用于 Markdown→Word 转换；系统字体（仿宋/楷体/黑体/华文中宋等）由本机提供；复核依赖本机真实安装的字体与 Word 渲染。
• 降级策略：若 pandoc 未安装或目标字体缺失，自动降级为 .txt / .md 输出并明确告知用户，不强行生成错误格式；字体缺失时按内置替换规则（如方正小标宋→华文中宋）处理并标注。
• 权限：所有文件读写均经用户授权；外部工具不可用时明确提示，不静默失败。
  <!--
  起源铭文（不可删除 · 红线 #22）：本技能由人类Nan（笔名"楠波万"）与 AI 协作创作，版权归创作者所有。
  不可变核心：① 本注释块不得焊入 YAML 首行（须在 --- 之后）；② 起源铭文 / 人类最终裁决 / 8 铁则不得被自动修改；③ 任何自动修改须人类确认。版本演进见 evolution-state.json。
  -->

相关技能与路由

• 要问答/抽取文档内容 → 用 doc-qa-pro（外部技能，需另装）（问答优先，不重写）
• 要论文级排版对齐期刊（表格/图片/目录） → 用 academic-docx-toolkit
• 本技能只做格式规范化（样式/编号/标点），不替代问答与重排

触发词（用户原声型）

• 帮我把这份文档排成公文格式
• 这份报告帮我调下排版
• 帮我自动生成目录和页码
• 把我的Word按红头文件格式排
• 这份通知按党政机关格式排版
• 帮我把文档标题层级理清楚
• 帮我排版文档
• 公文排版

> 本技能可独立触发；也可被其他技能/链路调用，独立使用不受限。

概述

对任意 docx 文档按 GB/T 9704-2012 标准进行三步法排版：
1. 提取要求 → 从格式指南生成执行清单（中间需求文件）
2. 逐条应用 → 按清单构建合规 docx
3. 严格复核 → 校验脚本逐条 PASS/FAIL，失败则回到第 2 步

核心原则：字体必须在用户机器上真实存在，verify 必须检查"Word 实际渲染"而非"XML 属性值"。

触发方式

用户提及以下任一场景时激活本 skill：
- "把我的文档排成公文格式"
- "按该文档要求重排另一个文件"
- "合同/通知/实施方案 按党政机关公文格式排版"
- 任何涉及"体制内格式"、"红头文件格式"、"公文排版"的请求

工作流（3 步法）

第 0 步：前置准备

1. 读取格式指南文件（.doc 或 .docx）和需要排版的内容文件
2. 识别格式指南所依据的标准（通常是 GB/T 9704-2012）
3. 关键：检查本机真实安装的中文字体

# 用 PowerShell 检查字体（Win11）
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' | 
  Select-Object * -ExcludeProperty PS* | 
  Select-String '仿宋|楷体|黑体|宋体|小标宋|方正|华文|中宋'

4. 字体选择规则（Win11 环境）：
   - 方正小标宋简体 → 大部分 Win11 未预装 → 改为 华文中宋（最接近的可用宋体标题字）
   - 仿宋_GB2312 → 老编码，Win11 受限 → 改为 仿宋（Unicode 版）
   - 楷体_GB2312 → 同上 → 改为 楷体
   - 黑体 / 宋体 → Win11 预装，可直接用
   - 不要只用 registry 或 font 文件夹确认，用程序把字体名 list 出来确认

第 1 步：提取格式要求 → 生成执行清单

1. 从格式指南中逐条提取以下维度（6 大类）：

2. 每项标注适用性：【适用】/【不适用】/【条件适用】

3. 保存为 格式执行清单.md

4. 关键：清单必须与原始格式指南逐条对照审计（类似 checklist_audit.py 的逻辑），确保无遗漏或措辞偏差。发现遗漏立即补入清单，即使该条【不适用】也要记录。

第 2 步：按清单逐条构建 docx

1. 使用 python-docx 逐条应用，关键规则：

2a. 字体设置（防假通过的核心）

# ✅ 正确：用原生 API
r.font.size = Pt(16)

# ❌ 错误：不要手动写 <w:rFonts> 到 rPr 以外的地方

# ❌ 错误：不要用 OxmlElement 手写 w:ind（python-docx 保存时会覆盖）

2b. 首行缩进（v1 的坑）

# ✅ 正确：用原生 API
p.paragraph_format.first_line_indent = Pt(32)  # 2字符 × 16pt

# ❌ 错误：不要手写 w:ind 的 OxmlElement — python-docx 保存时会覆盖

2c. 红头与分隔线

• 红头：标题居中，eastAsia 用 华文中宋，color 用 FF0000
• 分隔线：用 <w:pBdr><w:bottom w:val="single" w:sz="8" w:color="FF0000"/></w:pBdr>
• 注意：必须写在 红头段落之后、标题段落之前 的那个空段落上

2d. 正文层级字体

2e. 行距

p.paragraph_format.line_spacing_rule = WD_LINE_SPACING.EXACTLY
p.paragraph_format.line_spacing = Pt(28)  # 560 twips

2f. 署名与日期（不用印章型公文）

• 署名：right_indent = Pt(32)（右空二字）
• 日期：right_indent = Pt(64)（右空四字）
• 日期格式：2026年7月7日（阿拉伯数字，无"零"无空格）

2g. 附件的处理

• 附件说明（正文后）：左缩进 32pt，附件：1. 名称（名称后无标点）
• 附件另面：在"附件"标签前加 <w:br w:type="page"/>
• 附件标签：黑体、顶格
• 附件标题：居中

2h. 日期文字清洁

import re
def clean_dates(t):
    t = re.sub(r'(\d)\s+(年|月|日)', r'\1\2', t)
    t = re.sub(r'）\s+（', r'）（', t)
    return t

# 每个 add_para 调用都先 clean_dates(text)

2i. 页码（奇偶页不同）

• 启用 evenAndOddHeaders
• 单页(默认)页脚：居右 — N —
• 双页页脚：居左 — N —
• 字体：宋体 14pt，用 w:fldSimple 加 PAGE 域
• 注意：偶数页脚的实现见参考脚本 scripts/build_doc.py

第 3 步：严格复核

1. 回读生成的 docx，逐条校验 所有【适用】项
2. 校验脚本必须检查"Word 实际渲染"而非"XML 属性值"：

3. 所有项通过后才算完成，有一项 FAIL 就回到第 2 步
4. 保存 复核报告.txt 作为证据

脚本说明

scripts/doc_style.py — 共享常量

字体名、字号、颜色的统一常量定义。build 和 verify 都 import 它，杜绝"检查 A、文件里是 B"的错位。

FONT_XBS = "华文中宋"    # 小标宋（红头/标题）
FONT_FS = "仿宋"          # 正文
FONT_HEI = "黑体"         # 一级
FONT_KAI = "楷体"         # 二级
FONT_SONG = "宋体"        # 页码
RED = "FF0000"
PT3 = 16  # 三号
PT2 = 22  # 二号
PT1 = 42  # 初号
PT4 = 14  # 四号

scripts/build_doc.py — 构建参考

完整的公文 docx 构建脚本。使用前需将内容文本写入对应 add_para() 调用。

scripts/verify_doc.py — 复核参考

35 项全覆盖校验脚本。使用前需将 PATH 改为目标文件路径。

scripts/checklist_audit.py — 清单自检

检查执行清单是否覆盖了格式指南中的所有规则点。指南文本需先提取为 format_guide_raw.txt。

references/格式执行清单.md — 格式要求清单

GB/T 9704-2012 所有条款的完整汇总，每条标注适用性。

references/报告排版指南.md — 普通报告 / 总结排版（标题层级 + 自动目录）

红头公文之外，"自动生成目录 / 标题层级 / 报告模板"类请求的处理指南：两套版式选型、标题样式映射、TOC 域生成、复核点。配套 scripts/build_report.py。

已知陷阱（必须记住）

1. 字体假通过：不要只查 font name，一定要验证字体在本机存在。Win11 大概率缺方正小标宋简体。
2. 缩进假通过：python-docx 中手写 w:ind 的 OxmlElement 会被内部缓存覆盖。必须用 pf.first_line_indent = Pt(N) 原生 API。
3. verify 的自洽性陷阱：verify 脚本默认检查"你实现的值"，而非"标准规定的值"——署名右空二字的值、日期右空四字的值、行距的值，都要从标准原文算出来，不能从自己的代码里读。
4. 日期空格：源文档可能把"2026年7月7日"写成"2026 年 7 月 7 日"。自动清理，不要原样照搬。
5. 内容保密：skill 中包含的内容文本（如人员名单）是示例，实际使用时需替换。不要写入保密信息。
6. WPS 格式兼容：.doc 文件可能是 WPS 格式的 OLE2，antiword 读不了。直接写 olefile + Word 二进制解析器提取文本，见第 0 步的备用方法。

自我蒸馏（本技能独立运行，母体不介入）

• L1 静默记：每次被调用后，在本文件 ## 使用记录 下追加一行（任务/反馈/来源），不主动打扰用户。
• L2 周期蒸馏：累计 5 次使用后，归纳 learned 列表中的稳定偏好，回写本技能 SKILL.md 的相关小节。
• L3 建议修补：发现明确错误或被纠正时，直接修正 SKILL.md 对应步骤，并记一笔到 learned。
• 铁则：蒸馏只改本技能自身文件，绝不反向写入元技能或其他技能；母体（skill-maker-pro）只赋权、不介入。

不可变核心（8 铁则 · R6 补齐）

1. 起源铭文不可删除：文档头部 <!-- 起源铭文 --> 注释块永久保留，标记创作者与版权。
2. 人类最终裁决：涉及修改、发布、对外承诺的动作，须由人类确认后方可执行。
3. 不可修改核心：上述红线与进化阶声明不得被任何自动流程静默修改。
4. 功能完整性优先：自动化改造不得破坏既有功能路径。
5. 版本可追溯：每次变更写入 evolution-state.json（若存在）。
6. 错误可回滚：批量修改前须有本地快照。
7. 范围明确：仅处理本职域，跨域请求须路由至对应技能。
8. 透明可审计：关键决策留痕，便于复盘。

进化阶声明（R6 补齐 · E0–E3）

• E0（初始发布）：技能首次发布版本。
• E1（功能修补）：修复 bug、补充边缘场景，非破坏性。
• E2（能力增强）：新增工具/集成，非破坏性。
• E3（架构重构）：破坏性变更，须人类确认 + 版本 bump + 迁移说明。