700星开源Skill：按GB/T 9704-2012自动生成公文Word文件

看到标题里 700 星这个数字，我先说一句实话：能把公文格式这个最不起眼、又最折磨人的活儿做成开源项目，还拿到这个关注度，充分说明大家被手动调格式摧残得确实不轻。这段时间我一直在折腾一个开源 Skill，它的核心用途非常简单——你给它一篇公文正文，它按 GB/T 9704-2012《党政机关公文格式》把字体、字号、页边距、行距、页码、版记全部处理好，直接吐出一份符合国标的 Word 文件。你不用打开 Word 逐项去调那 7 个页边距数值，也不用记 2 号小标宋、3 号仿宋、28 磅行距这些零散参数，更不用对着模板一处处数“这个标题字号到底够不够”。这篇文章就把这个项目的原理、部署、实操和避坑经验一次讲透，不管你是办公室写材料的，还是搞 AI Agent 二次开发的，都能拿走直接用的东西。

1. 一段简史：公文排版为什么专门需要一个"Skill"

先说一个朴素的现实：公文格式的规则不算难，但架不住琐碎。琐碎到一定程度，人就容易出错，出错就得返工，返工就要加班。我见过太多同事为了把一个通知的标题字号调对，反复选中文字、切字体、改字号，最后还得拿尺子在屏幕上量页边距——这还是在有模板的情况下。

1.1 那些年被格式逼疯的打工人

绝大多数机关单位、国企和事业单位的公文写作场景，其实是这个套路：先在 WPS 或 Word 里新建一个空白文档，然后打开某份"老文件"作为参考，照着它的格式一边改一边调。这个过程有三个非常典型的坑。

第一，模板本身不一定规范。你手里的老文件可能是多年前的同事手工排的，页边距、行距、页码格式是否完全符合国标，没人验证过。照着错误模板调，结果自然是错上加错。

第二，内容一多，格式就散。写一个几十页的汇报材料时，标题层级、表格、图片、落款混在一起，手动调整的每一项都会牵动整体排版。经常是调完一个三段标题，发现整个页面的行距全乱了，又得退回上一步。

第三，知识只存在于少数人的脑子里。一套完整的国标参数，从纸张尺寸到字号矩阵，再到页码的"一字线"这种细节，没专门学过的人根本不知道。新人接手时，没有标签化的规范文档，全靠口口相传，这种隐性知识一旦断层，只能重新踩坑。

我算过一笔时间账：一份 5 页左右的通知，如果从空白文档开始手动排，光调页面设置、字体字号、标题层级、行距页码，快则 15 分钟，慢则 30 分钟以上。如果这活儿要反复做好几十份，浪费的时间就很可观了。所以当看到这个开源 Skill 出现时，我的第一反应是：这东西切中的痛点太真实了。

1.2 国标到底规定了什么

GB/T 9704-2012《党政机关公文格式》是这份 Skill 的规范基石。这份国标把公文版面的几乎所有视觉元素都做了量化规定，我用表格把最核心的参数列出来：

这里有个容易混淆的地方：公文排版中的"字号"用的是传统中文字号体系，不是 Word 里默认的磅值。3 号字对应 16pt，2 号字对应 22pt，这个换算关系不熟的人经常会搞错。另外，页边距的单位，国标里写的是毫米，但 Word 里更多显示为厘米或磅，这个也需要换算。

这还只是基础部分。一份完整公文的结构组件还包括份号、密级、紧急程度、发文机关标志、发文字号、签发人、红色分隔线、标题、主送机关、正文、附件说明、发文机关署名、成文日期、印章、附注、附件、抄送机关、印发机关和印发日期。每一个组件的字体、字号、位置都有具体规定，这就是为什么纯靠手动排版容易漏项——不是你不认真，是规则确实太多了。

2. 这个 700 星的开源 Skill 是怎么工作的

理解了痛点，再来看方案。这个项目本质上做的事情是：把上面那一整套规则固化成代码逻辑，再通过"Skill"这种形式封装成 AI 可以直接调用的能力。它跟普通 Word 模板的最大区别是，模板只是静态的样式壳子，而这个 Skill 是动态的规则引擎。

2.1 Skill 不是插件，是"操作手册 + 工具包"

先说一个背景：Skill 这个形态，是最近一年多 AI Agent 生态里流行起来的方案。它的思路很简单——把某一类任务的执行知识打包成一个固定目录结构，里面包含一个主指令文件（通常是 SKILL.md）和若干配套脚本、资源文件。AI（比如 Claude、Cursor 这类支持 Skill 的工具）读到这个目录后，就知道"遇到这类任务该按什么流程操作、调用什么脚本、遵守什么规则"。

放在公文场景里，这个 Skill 的目录结构大致是：

skill-root/ ├── SKILL.md # 主指令：告诉 AI 如何识别输入、调用脚本、校验结果 ├── assets/ # 静态资源：字体说明、国标参数表、示例公文模板 └── scripts/ ├── generate_docx.py # 核心生成脚本：用 python-docx 操作 Word 文档 ├── validate.py # 校验脚本：检查生成的文件是否满足国标参数 └── utils.py # 工具函数：单位换算、文本清理等

我建议你把 Skill 理解成一个"老师傅代代相传的操作手册 + 一套现成的工具"。普通模板是"我帮你把样式定好，你往里填内容就行"；而 Skill 是"我不仅把样式定好，还教会 AI 怎么根据内容类型自动选择样式，并现场生成 Word 文件"。它的核心能力有两个：一是把非结构化的文字内容识别成公文结构，二是把结构映射成符合国标的 Word 元素。

2.2 一次完整的生成链路

我实际跑通了一次完整流程后，对整个链路有了直观感受。整个工作流大致分四步：

**第一步：输入解析。**你只需要给 AI 一段文字，比如通知正文、会议纪要、请示材料。AI 会先判断这段文字里哪些是标题、哪些是正文、哪些是主送机关、哪些是落款。这个判断过程依赖大模型的语义理解能力，也就是通过 SKILL.md 里的指令引导 AI 来做结构化标注。

**第二步：格式映射。**AI 根据识别出的结构类型，去 SKILL.md 和 assets 里的国标参数表查对应的样式。这个环节非常依赖参数的完整性和准确性。比如识别出"这是第一个一级标题"，就查询到"3 号黑体、顶格排布"，然后把信息传给脚本。

**第三步：脚本生成。**generate_docx.py 拿到结构和样式映射后，逐段在 Word 文档中创建段落，设置字体、字号、颜色、对齐方式、行距、段前段后距离。python-docx 这个库对 Word 文档的控制力很强，能做到逐磅精调。这一步是纯代码执行，不依赖 AI，速度快且结果稳定。

**第四步：校验输出。**生成完后，skill 里还有一个反向校验的逻辑，检查事由、成文日期、页码是不是齐全，页边距是不是精确落在规定范围内。如果发现偏差，会给出提醒甚至直接自动修正。

这四步听起来不复杂，但每一步都藏着一些细节问题。比如 Word 里的"磅"和国标里的"毫米"怎么换算，比如中文字体的设置为啥不能只设东亚洲字体、还要同步设置西文字体，比如页码里的"一字线"到底是一段横线还是两个短横线。这些都是实操中才会遇到的问题，后面我会在避坑章节展开。

3. 国标公文格式核心参数拆解

之前给的表格只是列了参数，这节我把几个高频出错的细节展开讲，也算是这份 Skill 解决的核心技术难题。

3.1 页面三件套：纸张、页边距、版心

公文的物理载体是 A4 纸，这个大家都知道。但很多人忽略了版心这个概念。版心就是除去页边距后，一页纸中间实际能排文字的区域。按国标计算，A4 纸宽度 210mm，减去左 28mm、右 26mm，版心宽度是 156mm；高度 297mm，减去上 37mm、下 35mm，版心高度是 225mm。

这个 156mm × 225mm 的版心区域，才是公文的"有效面积"。手动排版时，如果你只改了页边距而忘了检查版心内的实际行数和字数，就可能出现"版心内每行文字超过 28 字"或"每页超过 22 行"的违规情况。国标规定：一般每面排 22 行，每行排 28 个字，并且要求"为准确计算版面，可将版心宽度除以 28 个字宽，版心高度除以 22 行行高"。

这个说法本身有点绕，我给一个更直白的实操经验：在 Word 里把正文设置为 3 号仿宋、固定值 28 磅行距后，每行大概能排 28 个汉字，每页大约 22 行。如果你的正文段落首行缩进两字符（也就是缩进 2 个字宽），那么每行实际有效文字在 26 字左右，这个细节 Skill 生成时会自动帮你处理，让整篇文档的版式呈现出"行行确当、列列均匀"的稳定感。

3.2 字体字号矩阵

公文标题使用 2 号小标宋体，正文使用 3 号仿宋体，这是整套格式里最广为人知的规则。但实际执行时比这复杂得多——标题、一级标题、二级标题、三级标题、四级标题用的字体各不相同。

下面是实际公文排版中常用的标题与字体对应关系：

• 公文大标题：2 号小标宋体，居中排布，回行时要做到词意完整、排列对称。
• 一级标题（一、二、三）：3 号黑体，单独成行，行末不加标点。
• 二级标题（（一）（二）（三））：3 号楷体，单独成行，行末不加标点。
• 三级标题（1. 2. 3.）：3 号仿宋加粗，可以单独成行，也可以与正文连排。
• 四级标题（（1）（2）（3））：3 号仿宋，一般不单独成行，跟在正文段首。
• 正文：3 号仿宋。

这里我要特别提醒一个坑：很多人在 Word 里设置中文字体时，只改了"字体"下拉框里的中文字体，但没动"西文字体"。Word 的默认西文字体是 Calibri 或 Times New Roman，当正文里出现半角数字、英文缩写时，西文字体跟中文字体不一致，整段文字会显得很突兀。Skill 在生成时会把东亚洲字体和西文字体统一处理，避免这个拼接感。

还有一个隐藏问题是"小标宋"字体。仿宋、黑体、楷体都是系统自带或 Office 自带的，但小标宋体（尤其方正小标宋）在很多电脑上根本没有。这个 Skill 的文档里通常会给出字体安装建议，这一步跑不掉，否则生成的 Word 在自己电脑上打开是好的，发给别人一看字体就乱套。

3.3 容易被忽略的细节：页码、分隔线、版记

页码是公文格式里最容易被低估的部分。国标规定，页码用 4 号半角宋体阿拉伯数字，数字左右各放一条一字线，例如"— 1 —"，单页码居右空一字，双页码居左空一字。这里的难点在于"奇偶页不同"——奇数页页码靠右，偶数页页码靠左，而且页码要放在版心外下边缘。在 Word 里手动设置奇偶页不同的页脚、再去调整页码的左右位置，操作路径非常绕，很多人弄到一半就放弃了。

再说红色分隔线。版头部分（发文机关标志、发文字号等）与主体部分之间有一条红色横线，线宽通常是与版心等宽，高度约为 0.35mm。这条线在手动排版时一般是用"下边框线"或一条水平线来模拟，但线的颜色、粗细、位置很难精确，Skill 生成时直接以固定尺寸画入，这就保证了印刷效果的统一。

最后是版记。版记部分包括抄送机关、印发机关和印发日期，位于文件末页底部，用两条水平线隔开。版记的字体通常用 4 号仿宋体，但很多人因为不知道这个规定，直接沿用了正文的 3 号仿宋，整个末页的比例一下就失调了。

4. 实操：把这个 Skill 装进你的工具链

这节我们做点正经事：把项目部署起来，真正生成一份公文。我分别讲本地部署、接入 Claude、用 Cursor 兜底这三条路径。

4.1 本地部署三步走

第一步：准备环境。这个项目依赖 Python 环境和 python-docx 库。建议用 Python 3.9 以上版本，然后安装依赖：

git clone <项目仓库地址> cd <项目目录> pip install python-docx

装完后确认一下版本，python-docx 的版本最好在 0.8.10 以上，老版本对"固定值行距"的支持有些小 bug，新版本里修掉了。

第二步：检查字体。前面说过，小标宋字体不是系统自带。你可以在系统的字体目录里查一下有没有"方正小标宋简体"或类似名称。如果没有，安装一套。这里有一个实操细节：安装字体后，如果 Word 或 python-docx 已经打开，需要重启进程才能识别新字体，别装完就急着跑脚本发现"怎么还是找不到字体"。

第三步：弄明白入口。这个 Skill 的调用通常有两种方式：如果你只想快速生成，可以直接运行生成脚本，传入你的文本文件路径；如果想让 AI 帮你处理结构识别，就先把 Skill 目录挂到你的 AI 工具里。我测试时是先用脚本生成了一个小样本，确认字体和页边距正常，再接入 AI 流程的。

4.2 在 Claude 中接入 Skill

目前这个 Skill 最常见的载体是 Claude，因为 Claude 的桌面版和 API 版都支持读取 Skill 目录。接入方法不复杂：

1. 把 Skill 目录放到 Claude 能访问的路径，比如~/skills/gongwen-format。
2. 写一段简短的提示词，告诉 Claude："你有一个公文排版 Skill，放在 xxx 路径，当你收到公文草稿时自动调用它。"
3. 然后把你的文字内容直接发过去，让它执行。

这里有一点值得说：接入之后，Claude 并不是每次都主动去读 Skill 目录，它需要被提示一下。所以我习惯在开头提示词里明确说明"先读取 SKILL.md，严格按它的规则处理"，这样能显著提高执行的稳定性。

我实测的效果是：给一段 800 字的会议纪要草稿，Claude 通过 Skill 生成了完整的 Word 文件，全程大约 40 秒。文档打开后，我核对了页边距、字体、行距、页码，全部符合国标参数。这个速度跟手动排版完全不是一个数量级。

4.3 用 Cursor 或命令行兜底

如果说你平时用的不是 Claude，而是 Cursor 或者其他编程类 AI 工具，也有办法。Cursor 本身支持读取仓库内的规则文件，你可以把 SKILL.md 放进项目根目录，然后在对话中直接要求它按规则生成，让 Cursor 调用项目里的 generate_docx.py 脚本。

还有一种更直接的兜底方案：完全不依赖 AI，就用手动方式调用生成脚本。比如你写了一个纯文本的公文草稿，markdown 格式也行，直接执行：

python scripts/generate_docx.py input.txt -o output.docx

脚本会按默认规则把 input.txt 里的内容逐段识别、生成符合国标的 docx。对于一条比较有规律的内容，这种命令行方式其实是最高效的，因为完全避开了 AI 的上下文限制、输出延迟和可能理解偏差。我的习惯是第一稿让 AI 处理，遇到复杂文件时直接切换到脚本直出，双保险。

5. 实现原理：从文字到 docx 的每一步

这节我们来拆解生成脚本的内部逻辑，我会从"如何识别结构"和"如何设置格式"两个维度来讲，配合一段简化版的代码示意，帮你看懂它到底做了什么。

5.1 模板脚本的分工

整体思路是"识别与渲染分离"。也就是说，AI 只负责把文字内容理解成结构化的"节点清单"，而脚本只负责把节点渲染成符合格式的 Word 元素。这种分工有个很大的好处：每一环出问题都能定位到具体环节，调试起来轻松。

我简化后的节点清单大概长这样：

[ {"type": "title", "text": "关于印发《年度工作总结》的通知"}, {"type": "main_send", "text": "各科室、各直属单位："}, {"type": "paragraph", "text": "现将《年度工作总结》印发给你们，请结合实际认真贯彻执行。"}, {"type": "level1_title", "text": "一、总体要求"}, {"type": "paragraph", "text": "坚持稳中求进工作总基调，完整、准确、全面贯彻新发展理念。"}, {"type": "signature", "text": "某单位办公室", "align": "right"}, {"type": "date", "text": "2026年5月20日", "align": "right"} ]

AI 把原始文本整理成这种结构后，生成脚本就变成了一个"无脑遍历"的过程。它根据每个节点的 type，去样式表里找到对应的格式定义，然后创建段落。这样做一方面保证了格式的一致性，另一方面也让后续修改变得简单——想改所有一级标题的字号？只需要改样式表里一处。

5.2 结构识别与样式映射

结构识别是整个流程的智能核心。AI 需要从一段没有标注格式的文本中判断"哪些是标题、哪些是正文、哪些是主送机关"，这依赖的是大模型的语义理解能力，而不是传统的关键词匹配。举个例子，像"各科室、各直属单位："这种以冒号结尾且带称呼特点的短句，AI 能自动归入主送机关而不是正文段落。

一旦结构标注完成，样式映射就变成了纯查表逻辑。脚本里通常维护一个样式字典，类似于：

STYLES = { "title": { "font": "方正小标宋简体", "size": Pt(22), "bold": False, "alignment": CENTER, "space_before": Pt(0), "space_after": Pt(28), }, "level1_title": { "font": "黑体", "size": Pt(16), "bold": False, "alignment": LEFT, "space_before": Pt(14), "space_after": Pt(14), }, # ... }

这里有个关键参数：行距。正文段落在公文里一般用固定值 28 磅，这个设置用 python-docx 实现时，需要同时设定 line_spacing_rule 为 WD_LINE_SPACING.EXACTLY，并把 line_spacing 设为 Pt(28)。只设数值不设规则的话，Word 可能把它理解成单倍行距的倍数，而不是固定磅值。这个坑我在自己写脚本时踩过，确认了 python-docx 的 API 语义后才绕开。

5.3 关键代码与参数逻辑

我用一个简化片段来演示核心逻辑，完整代码仓库里都有，这里只讲思想和关键命令：

from docx import Document from docx.enum.text import WD_LINE_SPACING, WD_ALIGN_PARAGRAPH from docx.shared import Pt, Mm def set_page_format(doc): section = doc.sections[0] section.page_width = Mm(210) section.page_height = Mm(297) section.top_margin = Mm(37) section.bottom_margin = Mm(35) section.left_margin = Mm(28) section.right_margin = Mm(26) def add_paragraph(doc, text, style): p = doc.add_paragraph() run = p.add_run(text) run.font.name = style["font"] run._element.rPr.rFonts.set( qn("w:eastAsia"), style["font"] ) run.font.size = style["size"] run.font.bold = style["bold"] p.alignment = style["alignment"] p.paragraph_format.line_spacing_rule = WD_LINE_SPACING.EXACTLY p.paragraph_format.line_spacing = Pt(28) return p

这里有两处最值得关注。

第一个是run._element.rPr.rFonts.set(qn("w:eastAsia"), style["font"])。这行代码手动设置了 Word 文档底层 XML 里的w:eastAsia字体属性。如果缺少这一步，python-docx 只设置了西文字体名，中文字体在 Word 里不会生效。这种"底层 XML 直接操作"的做法，是熟练使用 python-docx 的关键。

第二个是section.page_width = Mm(210)这类设置。python-docx 的 Mm 类会帮你把毫米转成英制单位（EMU），避免手动换算的精度丢失。你可能注意到，Word 里显示的是"厘米"，但代码里用的是"毫米"，这里面有一个单位精度的细节：设置 28mm 左边距时，不推荐直接写Cm(2.8)，因为Cm类底层换算为 EMU 时可能产生微小误差。虽然实际打印差异几乎察觉不到，但既然做国标输出，还是用毫米更严谨。

6. 常见问题与避坑记录

到这里，项目大部分价值已经讲完了。最后我把自己实操过程中遇到的各种问题整理成一个速查表，外加几个容易忽视的坑，供你排查时对照。

6.1 问题排查速查表

这里的核心排查逻辑是：先分清问题发生在"识别环节"还是"渲染环节"。如果标题层级识别错了，问题在 AI 语义理解；如果字体、行距设置错了，问题在脚本。用这个思路定位，基本不会跑偏。

6.2 踩坑经验：字体、单位、编号

我踩过的第一个人坑是字体。当时生成的 docx 在自己电脑上看一切正常，发到另一个同事电脑上打开，仿宋全部变成了宋体。排查后发现是对方机器上没装仿宋体，Word 自动做了字体替换。这个问题没法完全靠代码解决，所以在提交给外部单位之前，最好先确认接收方有对应字体，或者干脆用 PDF 输出打印版。这是公文流转里一个非常实际的流通性问题。

第二个坑和单位有关。python-docx 里设置段前段后距离时，如果使用Pt设置磅值，跟国标里的"毫米"或者"字"的概念不是一一对应的。比如国标要求"标题段前一般空一行"，这个"一行"在脚本里通常被近似成 28 磅或 16 磅，具体取决于上下文。Skill 的作者一般会把这些换算关系写进注释，但如果你自己改脚本，很容易忘记这个换算是近似值。我建议不要轻易动这些近似值，因为它们是经过多份公文验证过的稳定结果。

第三个坑是编号。AI 在识别多级标题时，偶尔会把"（一）"和"（1）"的层级搞混。尤其是当原文里没有严格遵循编号体系时，AI 的推断就更不可靠。我的处理办法是：输入给 AI 的文本本身尽量把标题层级标清楚，比如用 markdown 的标题符号直接标注。原文越规范，AI 的识别越准确，这个规律屡试不爽。

6.3 让输出更稳的小技巧

最后分享三个让整个流程更稳定的小技巧。

第一，建立一套自己的输入规范。虽然 Skill 可以处理纯文本，但在输入时用简单的 markdown 语法（#表示标题、##表示一级标题等）能明显提高 AI 的结构识别准确率。这就好比给 AI 一个路标，它能少走很多弯路。

第二，生成后至少做一次抽查。虽然有校验脚本兜底，但我仍然建议你抽查文件名和落款日期的正确性。AI 在处理成文日期时，偶尔会直接把当天的日期写上，而不是你原文里的日期。这种事没有任何技术能完美解决，只能靠人眼确认。

第三，把整个 Skill 接入你的日常写作流。我现在的做法是：写材料时不再同时开着"格式参考文件"和"正在打的文档"，而是直接在对话里把内容丢给 Skill，让它生成初稿，我再基于初稿做内容层面的修改。排版这件事从脑力劳动中剥离后，整个人写材料的节奏完全不一样了——脑子里只需要专注内容，格式的问题交给规则和执行，这大概就是这类工具最让人舒服的地方。

根据我这段时间的实操体会，这个 700 星的项目真正的价值不在于"700 星"这个数字，而在于它把一套看似简单、实则繁琐的格式规范做成了可复用、可验证的工具。如果你也经常被公文格式折腾，我的建议是别再手动调了，花半小时把这个 Skill 部署起来，后面省下的时间会远超投入。小到一次通知，大到一份汇报材料，它都能给你一个稳定的起点。