Gongwen Format skill

国标排版（gongwen-format）

把公文正文排成符合 GB/T 9704-2012《党政机关公文格式》的 docx，检查、修复已有 docx 格式，把 gongwen-review 的核稿意见写成 Word 批注。参数一律来自 references/_shared/rules/gbt9704.md。

适用范围

• 适用：
  • 正文（.txt、.md 或粘贴文字）排成 docx：红头（文件格式）、信函、纪要、命令（令）、白头（无版头的公文）、材料（总结、讲话稿等，只有标题和正文）、简报（报头、各篇、报尾）；另有联合行文版头、附件另面、预印红头纸套打（第二步第 10 款）。
  • 检查已有 docx 是否符合国标，输出 P0/P1/P2 问题清单；轻度问题修复页面、字体字号、行距、缩进、页码，结构问题抽取全文后重排。
  • 把“核稿意见.json”写成 Word 批注；指导用户在 WPS、Word 中手动设置。
  • 行业包起草的专用文书，排版也归本 skill。
• 不适用：
  • 起草法定公文转 gongwen-draft，讲话稿转 gongwen-speech，总结、汇报等转 gongwen-report，其他按文种转对应起草 skill；装有行业包时，行业专用文书交对应行业包。只起标题、搭提纲转 gongwen-title。
  • 压缩篇幅、改写内容，转 gongwen-polish；去 AI 腔，转 gongwen-humanize；去免责、对冲、态度不明，转 gongwen-direct。
  • 查错别字、提法、标点数字、行文规则等内容问题，转 gongwen-review；本 skill 只把 review 的结论写成批注，不自己核稿。
  • 用户要求排版时顺便改文字的，说明不改内容，建议先改完再排。
• 转交方式：能调用其他 skill 的环境直接调用；未安装或网页环境的，按 output-format.md 第四部分转交（交接卡、新开对话粘贴说明、安装命令）。

开工检查

1. 保密：按 references/_shared/guardrails.md 第一条执行。材料或版式信息有密级标识（绝密、机密、秘密、★）或“内部资料”“工作秘密”等字样时立即停止，建议在内网自行运行脚本。
   • 有 Python 时，先运行 python scripts/secret_check.py <文件> 检查保密标识（含页眉页脚），命中即停。
2. 单位画像：先读 .gongwen/单位画像.md（没有则查 ~/.gongwen/单位画像.md），取发文机关标志、发文字号格式、红头或白头、党政代字、单位规定字体、写作角色和默认模式；都没有时按 roles.md 第九节“无画像降级”，版式按第二步第2款先排，末尾问一句要红头、白头还是材料；画像没红头设置的，按第二步第3款说明。
3. 运行环境：能执行命令时先运行 python -c "import docx; print(docx.__version__)"；报错或低于 1.2.0 时提示 pip install -U python-docx；不能安装的，走“没有 Python 环境时”。
4. 首轮交付：材料在手直接排版交付，不先问版式细节。不改内容、不补内容：原稿没有的要素一律不写进文档（不补版记、不插【待补】），只在报告和回复中列出，由用户决定；用户明确要求“缺的要素留出位置”才加 --placeholders 写占位。提问不超过 3 个，放回复末尾（roles.md 第十节）。
5. 【起草说明】之后的内容不排版，脚本读到这行自动停止。
6. 交接卡：用户粘贴了交接卡的，按卡上的单位画像、模式、任务和已确认事项开工，已有的不再问。

工作流程

第一步　判断任务，选脚本

用户要什么	用哪个脚本
把正文排成 Word、套红头、出信函、纪要或简报	scripts/build_docx.py，随后自动检查
看看这个 docx 格式对不对	scripts/check_docx.py
这个 docx 格式乱了，帮我改	先 check_docx.py 判路线（第四步）：轻度问题 fix_docx.py，结构问题 extract_docx.py 抽取后 build_docx.py 重排
用户说“内容别动”“一个字都别改”“只调格式”	build、fix 都加 --keep-text（第四步第 5 款）
把核稿意见写进文档	先把送审稿 build 成 docx，再 scripts/annotate_docx.py；终稿不加批注（第五步）
我自己在 WPS 里改，告诉我怎么设	不用脚本，按 references/manual-setup.md 给步骤
想先看看排出来的样子	本机有 LibreOffice 且标准字体齐全时用 scripts/preview_docx.py 转图片
想知道本机标准字体装齐没有、缺的怎么装	scripts/gw_fonts.py

scripts/gw_*.py 是公共模块，不单独运行（gw_fonts.py 除外）；用法可加 --help 查看。

第二步　整理版式信息（生成 docx 时）

1. 按 meta-fields.md 整理“版式信息.json”，放正文同目录。
2. 版式按顺序定：用户本轮指定 → 单位画像 → 文种默认（函用信函；纪要有纪要版头的用纪要格式；其他法定公文用白头；总结、讲话稿等用材料版式；工作、专题、会议简报用简报版式）。
3. 按文种默认排白头的，写一句：“如需红头，请提供：发文机关标志、发文字号；请示、报告另提供签发人姓名。”教学模式附依据 7.2.4～7.2.6；一般不用红头的单位（如社区）不写。
4. 发文机关标志、代字从画像取；党委发文和行政发文分开，不能混用。
5. 用户要求把应发红头的正式文件改成白头或便笺、以减少发文数量的，按 references/_shared/guardrails.md 第六条第 3 款说明不可，仍按正式文件排。
6. 发文字号序号、成文日期、签发人、印发日期只用用户给的，缺的不写（留占位模式才写“代字〔年份〕【待补：序号】号”“【待补：具体日期】”），不编号码、不以当天日期充当成文日期、不推算“周五”“月底”等相对时间。
7. 本单位制度与国标不一致的写法，按本单位制度排，检查加 --allow（第六步第3款）。
8. 用户没提供版式信息时可不写 JSON，脚本自动识别标题、主送机关、附件说明、署名和成文日期。
9. 简报：无国家标准格式，以下为常见做法，以单位往期样式为准。报头、各篇、报尾按 references/manual-setup.md 第十四部分，字段见 meta-fields.md；简报名称、期号、编印单位、印发日期缺的不写，报送范围、印数没给的不排。篇目标题认不带句末标点的短行，请用户核对。
10. v1.1 版式（参数、用法、条款见 layouts.md；“实践值”非标准原文）：命令（令）写 "版式": "命令" 及令号、签发人职务；附件另面在落款后用“【附件1】标题”行引出；联合行文的发文机关标志写成数组，主办机关在前；套打加 --overprint；上行文红头的发文字号居左空一字，与最后一个签发人同行。

第三步　生成 docx

python scripts/build_docx.py <正文文件> --meta <版式信息.json> -o 公文/<YYYYMMDD>-<简短标题>/成稿.docx [--layout 红头] [--allow DOCX-050]

1. 用户粘贴正文的，先存为 公文/<YYYYMMDD>-<简短标题>/正文.txt（已存在加 -v2），再运行脚本。
2. 成稿一律用 -o 写到上述目录（日期取当天），不得省略（输出规范第2条）。
3. 读脚本报告：
   • “识别结果”：标题、主送、附件、署名、日期是否认对；认错的，在版式信息写明字段后重新生成。一级标题与正文同段的，脚本按正文排，告知用户拆成独占一行后重排，不自行改字。
   • “缺失要素”：原稿没有、未写入的要素，逐条转告（留占位模式为“待补事项”）。
   • “字体”：本机是否装齐标准字体；缺失或无法检测时，报告开头有“字体缺失”区块（第 4 款）。
   • “回读检查”：P0、P1 清单。
4. 缺字体（严格模式，不降级）：文件中一律写入标准字体名（脚本无降级开关），严禁改用或建议任何替代字体（仿宋、楷体、华文中宋、宋体加粗等都不行）。报告出现“字体缺失”或“无法检测”区块时，回复开头先醒目告知缺哪些字体；在本机用 Word/WPS 打开会被自动换字体显示，不是正式效果，不能据此核对版式或打印；再逐款转告报告中的获取途径和安装方法（或运行 python scripts/gw_fonts.py），请用户自行下载安装后重新打开核对。检测的是运行脚本的电脑，用户在别的电脑打开的，请在那台核对。方正小标宋简体是商业字体，需单位授权；本工具不提供、不打包字体。
5. 单位规定字体：画像记有“单位规定字体”，或用户明确说明本单位制度规定了字体时，各脚本加 --unit-fonts "仿宋=方正仿宋_GBK"（build 的版式信息可写 "unit_fonts": {"仿宋": "方正仿宋_GBK"}，命令行优先）。严格模式不变：没装同样报“字体缺失”并引导安装（向单位信息中心或办公室索取），不回退；报告写明“按单位规定使用 X（国标为 Y）”。用户只是没装字体想换的，不得用该参数。

第四步　修复已有 docx

先运行 python scripts/check_docx.py <原文件.docx> --json 判路线，再动手：

1. 版头（发文机关标志、发文字号、签发人、红线，DOCX-055、056、160～162）、版记（DOCX-163）、附件另面（DOCX-13x）、标题、落款有缺失或错误的，走抽取—重排：

   python scripts/extract_docx.py <原文件.docx> [--layout 红头]
   python scripts/build_docx.py <正文-原名.txt> --meta <版式信息-原名.json> -o <成稿.docx> [--keep-text]
   

   抽取不改文字，识别不出的要素不写（列入缺失要素）；应排红头的加 --layout 红头；识别要素见 layouts.md 第八部分。
2. 只有页面、字体、行距、缩进、页码的轻度问题用 python scripts/fix_docx.py <原文件.docx> [-o <输出.docx>] [--layout 白头] [--seal 是|否] [--allow DOCX-050]：按段落文字识别角色（check-items.md 第二节），输出“原名-修复.docx”和修复报告，原文件不动。不重建版头、版记、附件；清除原页眉、页脚中的旧页码和杂项并重设页脚页码；1.、1.1、（1）等非标准序号按层级套用标题字体，序号文字不改，报告建议改为标准序号。
3. 两条路线交付前都要回读（build、fix 已自动运行 check_docx），回复如实报告仍存在的问题，不得声称“已按国标做好”而成品不符；缺字体按第三步第 4 款在回复开头提示。识别有误的，用 --layout 指定。
4. 发文字号括号、日期虚位这类要改文字才能消除的问题，脚本不改，列入报告；逐条向用户确认后在 Word 中改，或改正文后重新生成。
5. 用户说“内容别动”“一个字都别改”“只调格式”等时，build_docx.py、fix_docx.py 都必须加 --keep-text：空格、标点、数字、写法一个字不动（不补冒号、不加括号，保留空格缩进），文字类问题只在报告“文字类问题”中列出，由用户决定；保存前双向、按顺序比对输入与文档全文（多字、少字、乱序、重复都中止），通过才报告“文字核对”；未核对不得声称“已逐字核对”。

第五步　写入核稿批注

python scripts/annotate_docx.py <送审稿.docx> <核稿意见.json> [--author gongwen-review]

1. 批注加在由送审稿排出的 docx 上（JSON 的 source_file 指明哪份）：先用 build_docx.py 按成稿相同的版式信息把送审稿排成 docx（默认输出“送审稿.docx”），再运行上面的命令。按意见改过的终稿不加批注，excerpt 多已改掉，定位不到。
2. 核稿意见.json 由 gongwen-review 输出（source_file 和 issues，每条含 level、gate、category、excerpt、message、suggestion、basis），excerpt 是原文中逐字一致的连续片段，脚本靠它定位。check_docx.py 的 --json 输出也可直接写成批注。
3. 脚本按 excerpt 定位，输出“原名-批注.docx”和批注报告；“未定位”的条目逐条告知原因，请用户手工处理。
4. 只写批注，不改正文，不写修订。

第六步　交付前检查

1. 运行 python scripts/check_docx.py <成稿.docx> --json（build、fix 已自动运行的看报告）。
2. P0 为 0 才能交付。否则：格式类问题改版式信息或用 fix_docx.py 修好后重查；文字类问题（发文字号、成文日期写法）向用户确认后改正文重排。
3. 例外：画像或用户说明本单位制度规定了与国标不同的写法的，回读和自检加 --allow DOCX-050，命中项降为 P2、注明“按本单位制度保留”；交付说明逐条写明差异和检查项号。有单位规定字体的同样加 --unit-fonts。
4. P1 逐条告知。正文残留的【待补】【待核实】排版照做，报 P2（DOCX-080）单独计数并提醒补齐，不替补；文档中有【起草说明】报 P1（DOCX-082），交付前删去其及之后的内容；残留 Markdown 表格行报 P1（DOCX-100），用 build_docx.py 重新生成。其余 P2 汇总一句。
5. 有条件时目检：运行 python scripts/preview_docx.py <成稿.docx>（需 LibreOffice）逐页看图，核对版头红线、层次标题是否落页末、附件页、版记位置，并读“版面核对”（落款与正文末段是否同页、首页留白）。回复中的处理结果（如“落款与正文同页”）以 check_docx 和渲染结果为准，没核对到的不写。无 LibreOffice 时只提示；缺任一标准字体时拒绝渲染（退出码 3），先装字体；以打印核对为准。

没有 Python 环境时

网页版大模型、内网无 Python 的电脑，或用户不愿安装时，按文字流程完成：

1. 逐行判断正文中的标题、主送机关、各级层次标题、表格、附件说明、署名、成文日期、附注、版记。
2. 规则：首行以“关于”开头或以文种结尾的是标题；标题后以冒号结尾的是主送机关；“一、”“（一）”“1.”“（1）”开头的是一至四级标题，二至四级标题与正文同段时，第一个句号及以前是标题；“附件：”开头的是附件说明；末尾的单位名称行和日期行是署名和成文日期，日期下一行的括号行是附注。
3. 输出“本文排版清单”，逐项写明：选用版式；各要素原文（层次标题列出各级几处）及其字体、字号、对齐、缩进；署名和日期按盖章与否的排法和缩进字数；版头、版记要填的内容，缺的只列出、不写。
4. 清单后附 references/manual-setup.md 中用得上的步骤（页面设置、正文样式、文档网格、页码、字体准备与安装必附；红头、信函、纪要、版记、表格按版式和正文附）。
5. 注明“未运行脚本检查，请按手动设置清单第十三部分打印核对”。
6. 排版一般是路线最后一站，写“路线已完成”；还有下一站的，按 output-format.md 第四部分输出交接卡。

输出规范

1. 正文排版遵守 output-format.md，输入是按它写的纯文本。
2. 交付文件放在 公文/<YYYYMMDD>-<简短标题>/，同名加 -v2、-v3，不覆盖。默认文件名：输入“正文.txt”输出“成稿.docx”；输入“正文-××.txt”输出“成稿-××.docx”；其他输入输出“<输入文件名>.docx”（不与终稿重名）。批注版由送审稿排出，名为“送审稿-批注.docx”一类。
3. 对话中的交付说明：缺字体或无法检测字体时，字体缺失提示放最前（第三步第4款）；其后依次写：文件位置；版式和是否按盖章排；识别结果（请用户核对）；待补事项；检查结论（P0、P1 条数，每条一行写问题和条款号，转译模式按“角色适配”）；相关的已知限制。没有内容的省略，不复述全文。
4. 默认不改动任何文字（逐字保真），例外：去掉段首缩进空格；Markdown 表格转 Word 表格（去掉竖线和加粗记号，文字不变）；抄送数组连成一句加句号。以下格式性文字问题默认只在报告中提示，不自动修正：主送机关末尾补全角冒号、附注加圆括号、日期写法转换（如 2026-10-16 → 2026年10月16日）；用户可加 --auto-fix-text 开启自动修正。加引号的提法、做法名称原样保留。其他文字问题只报告，不动手；用户要求内容别动的，一律不做（第四步第 5 款）。

自检清单

• 已按保密红线检查，未处理涉密内容。
• 版式与画像、文种一致；党委、行政标志和代字未混用；排白头的，已说明改红头要补的要素。
• 发文字号、日期、签发人、印发机关都来自用户或画像，缺的未写进文档（无【待补】、无补出的版记）并已在回复列出；相对时间未推算成具体日期。
• 识别结果已逐项核对，认错的已用版式信息纠正。
• check_docx.py 结果 P0 为 0；按本单位制度保留的项已加 --allow 并在交付说明写明差异。
• 缺字体或无法检测时，已在回复开头告知并附获取、安装方法，未建议替代字体；原文件未覆盖。
• 正文与输入逐字一致：默认只有输出规范第4条列的例外，补冒号、加括号、日期转换仅在 --auto-fix-text 时执行；没有重复行；要求“内容别动”的，已加 --keep-text 且“文字核对”通过；回复如实报告成品仍有的问题。

有 Python 时运行 python scripts/check_docx.py <文件.docx> --strict（保留项加 --allow，见第六步第3款）；不能运行脚本时，按 references/manual-setup.md 第十三部分人工核对，写明“未运行机检”。

已知限制

1. 版记、版头位置误差、签章预留、标题分行、落款留白等限制见 layouts.md 第七节；印发前打印核对。
2. 缺标准字体的处理见第三步第4款；仿宋_GB2312 缺生僻字时，该字需单独换字体并打印核对。
3. 正文表格只支持简单管道表格，fix_docx.py 不调整已有表格；批注按 excerpt 定位。
4. 段落角色靠文字模式识别，非常规标题或编号可能认错，须看识别结果。

角色适配

• 教学模式：每次交付附“这次用到的国标要素”3～5 条，写清条款号和 Word、WPS 默认设置哪里不符国标；用户自己操作时按 references/manual-setup.md 带着做。
• 高效模式：不展开讲解，直接出 docx；只报告识别存疑项、待补事项和 P0、P1（每条一行写问题和条款号）；多份材料汇总一张表。
• 转译模式：接受直接粘贴的文字或 Word 文件，不要求先整理格式；交付时附在 WPS、Word 打开、套用格式和另存的步骤，检查结论用业务人员听得懂的话写。默认不写条款号；有 P0、P1 时才在句末括注一处。
• 审稿模式：只运行 check_docx.py，输出一页纸格式问题清单（P0 在前，每条写位置、问题、依据、改法），不改文件；用户说“帮我改”再运行 fix_docx.py。
• 严谨模式：另查党组织名称是否用全称、版头和代字是否与发文主体一致、署名与标志是否一致；对外发布的材料提醒确认附注。

参考资料

文件	何时读取
references/manual-setup.md	没有 Python 环境，或用户自己在 WPS、Word 中设置
references/meta-fields.md	整理版式信息.json；取画像的标志和代字；医院、高校、国企红头差异
references/check-items.md	解读检查结果、修复报告、批注报告；识别规则
references/layouts.md	命令（令）、附件另面、联合行文、预印红头纸套打、上行文发文字号、--keep-text 的参数、用法和条款依据
references/_shared/rules/gbt9704.md	需要条款原意、数值依据时；字体名称和缺字体规则读第九节
references/_shared/rules/gbt15834.md、references/_shared/rules/gbt15835.md	用户问到序号标点、日期数字写法时
references/_shared/profiles/units/	对应单位类型的“发文体系”“版式差异”
references/_shared/profiles/roles.md	确定角色模式；首轮交付（第十节）
references/_shared/style/output-format.md	输入正文的写法；转交和交接卡（第四部分）
references/_shared/guardrails.md	每次开工前
assets/gbt9704_params.json	修改排版参数时（须与 gbt9704.md 一致）