公文排版别再手抠：GB/T 9704至2012 的开源 Skill 真能省事吗

先说结论

公文排版这件事，90% 的痛点不在写，而在调字号、行距、页边距和版心。mizzlelover/gongwen-gbt9704-skill 这个项目把 GB/T 9704至2012《党政机关公文格式》的关键参数固化成一个 Claude Code Skill，输入 Markdown 就能吐出符合规范的 DOCX。一周拿下 503 颗星，靠的不是花哨演示，是真有人天天在改红头文件。

如果你一年里要交几份通知、报告、请示，又不想每次都从模板里一行行抠格式，这个 Skill 值得放进工具箱。但它解决的是“排版”这一段，不是“写公文”这一段，边界要清楚。

真正的问题

GB/T 9704至2012 看起来就是一串数字：三号仿宋、行距固定值 28 磅、版心 156mm×225mm、上 37mm、下 35mm、左 28mm、右 26mm。背下来不难，难的是每次从 Word 空白文档里把这些数字一个个塞回去，再保证标题层级、序号、页码、表头全没漏。

更烦的是不同单位有自己的“微调”：有的要求正文用仿宋 GB2312，有的坚持用方正仿宋简体；有的页码用宋体半角居中，有的要加四号半方括号。手抠这些差异，抠到第二份就会想骂人。

开源社区对这类“琐碎但高频”的需求一直有热情。过去要靠 VBA 宏或在线转换站，现在有开发者把它做成 Claude Code 能直接调用的 Skill，本质上是把“标准 + 排版经验”封装成可复用的工作流。这个项目之所以一周能冲到 503 颗星，是因为它踩中了“机关、事业单位、国企文秘、辅导员”这群沉默但庞大的用户。

怎么做更省力

这个 Skill 的使用链路很短：把写好的 Markdown 喂给 Claude Code，调用 Skill，它会按 GB/T 9704至2012 生成一份结构合规的 DOCX。主要语言是 JavaScript，意味着它是脚本级别的，跨平台跑得动，Windows、macOS、Linux 都能用，不用装 Office 也能预览。

省力的关键在于三件事。

第一，公文层级自动对齐。一级标题、二级标题、序号、落款，这些在 Markdown 里用 # 和列表就能表达，Skill 会按标准字号映射，省掉你来回点样式的十几下。

第二，版心和页边距一次到位。手动设置版心最容易错，Skill 把标准值写死，出错概率大幅下降。

第三，可编辑 DOCX 而非 PDF。生成的是 .docx，领导要在上面划红笔、加批注、合并段落，随时能改，不存在“生成完还要重新排一遍”的二次返工。

如果你的稿件来源是 Markdown 草稿或AI生成稿，可以先把内容丢进 Markdown 智能编辑器 里整理结构和标题层级，再喂给 Skill，整条链路就顺了。

哪些坑要避开

再好的 Skill 也不是万能的。

红头、版头、文号这些不属于 GB/T 9704至2012 强约束的部分，每个单位都有自家模板。Skill 处理的是“正文格式”，红头那一块还得你手动套用本单位的 Word 模板，或者后期合并。

字体本地化要确认。生成 DOCX 时如果系统里没装方正仿宋简体，可能回退到仿宋或宋体，最终效果会差一口气。提交前在打印预览里扫一眼字号行距，比什么都管用。

跨平台排版有细微漂移。同一份 DOCX 在 WPS、Office 2019、Office 365 里打开，行距和字距可能差零点几毫米。重要文件建议固定一台机器、一套 Office 版本出稿。

最后，公文内容本身要不要交给AI写，这是另一个话题。Skill 只管排版，不管事实口径和政治表述，该自己把关的别甩锅。

现在就能动手

打开终端，克隆仓库 mizzlelover/gongwen-gbt9704-skill，按 README 配置 Claude Code 的 Skill 路径。把一份现成的通知或报告 Markdown 丢进去跑一遍，对照 GB/T 9704至2012 自查字号、行距、版心三项。跑通后，把单位自己的红头模板和它生成的正文做一次合并，存成本部门的标准模板，下次直接套。

如果手头没有 Markdown 草稿，先用 Markdown 智能编辑器 把 Word 内容转成结构化文本，再走 Skill 链路，效率最高。