为什么 AI 写的公文，看着像却交不出去

一份材料能不能交出去，常常跟它写得好不好没有关系。它取决于页边距是不是规定的那个数字，取决于目录能不能在 Word 里更新，取决于打印出来的那一刻，红头有没有偏。AI 把「写」这一步的成本压到接近零之后，浮上来的正是这个问题。

交不出去的那一份

把一份写好的材料送到办公室，对方翻了两页，说格式不对，回去重排一遍。你打开文档，看不出问题在哪——段落都在，字号看着正常，目录也排在页面上，只是那个目录点不动，页码和标题对不上。

这种返工在很多办公室里每天都在发生。它不涉及内容，不涉及观点，甚至不涉及文笔。它只涉及一份十多年前定下来的国家标准里写着的那些数字：版心尺寸、页边距、字体、字号、行距、页码位置、文号写法。

退回去的代价往往被低估。一份材料重排一遍，损失的不只是那半小时，还有被切开又接回来的流程、往后挪的发文日期、起草人在别的事情中间重新捡起这件事的注意力。

更麻烦的是，这次退稿几乎没有产生任何新信息。没有人从中学到新东西，大家只是把标准又对了一遍，然后希望下一次不用再对。

返工的面孔其实很固定。目录点不动，页码和标题对不上；在你这台机器上排得好好的，换到对方那里字号和行距变了样；内容一字不差，打印出来红头的位置偏了几毫米。三种毛病都不影响阅读，都可以让一份材料卡在原地。

AI 出现之后，这件事变多了。

过去材料写得慢，格式问题被写的时间盖住了。一份两千字的报告要写一整天，排在末尾那半小时的调版，是顺手做完的事。现在初稿可能十分钟就出来，写作这一步被压缩到几乎为零，格式反而成了整个流程里最长的一段。

所有人都点头的那件事

用过 AI 起草材料的人，大概都经历过同一套流程：让模型写一版，复制进 Word，然后开始手动收拾它。标题层级重排，段前段后重设，缩进重调，页脚重做。收拾完一遍交给同事，同事在 WPS 里打开，发现又不一样了。

这里有一个大多数人点头、却很少被说出口的判断：AI 改变了写作，没有改变交付。

「看着像」和「交得出去」之间的距离，比人们预想的要长。前者是一个感觉，后者是一组可以被逐项检查的条件。这两件事在过去往往绑在一起，因为写材料的人本来就是懂格式的人。

老办公室的人一眼能看出字号不对，看得出文号里的括号该用哪一种，看得出哪一行该顶格、哪一行该退两格。他们的手感替标准兜了底——标准写在纸上，判断长在人身上。

AI 把这两件事拆开了。写的那一半被机器接走，检查的那一半还留在人手上。

还有一层更消耗人的地方。收拾一次格式并不难，难的是下个月再来一次，换一份材料再来一次，换一个人接手再来一次。每一次都要重新判断，每一次的判断标准都略有出入。

写作变便宜之后，浮上来的是交付

一个环节的成本降到接近零，瓶颈就会出现在它的下游。

写作变便宜之后，被暴露出来的是可交付性。这不是公文独有的问题。设计工具普及之后，被挑出来的毛病从「做不出来」变成了「交付给印刷厂之后颜色不对」；建站工具普及之后，被挑出来的毛病从「页面上线了没」变成了「能不能被搜到」。成本往下游压，质量的门槛就往下游移。

公文恰好是这个现象最干净的样本。

写作成本下降还会制造一种错觉：初稿既然是几乎免费拿到的，那么把初稿收拾干净也应该是顺手的事。事实恰好相反。初稿来得越容易，被交付的材料总量就越多，需要逐份检查的工作量反而涨得更快。

专业里的知识大致分三层。第一层是能说出来的，可以写进手册，背下来就能用。第二层是只能示范的，跟着做上几个月才学得会，说不清依据在哪。第三层是可核验的，有量纲、有阈值、能判定合格与不合格。

有人会说，格式的事交给办公室处理就行。办公室的处理能力同样不是无限的。上游产出的材料数量涨上去了，下游的检查环节没有跟着扩容，它就会从一道工序变成整条流程的瓶颈。

公文格式属于第三层。它的每一条都能查、能对、能被判定。

它却长期用第二层的方式传承。

这个错位是所有返工的来源：一套本可以写成规则的知识，被装在了只能靠经验传递的容器里。容器会泄漏——人换了会漏，时间久了会漏，办公室搬了会漏。

交付是一个社会动作

材料写出来，不是为了放进文件夹。它要流转、要编号、要盖章、要登记、要归档，接收方要按同一套标准检查它。

格式是这套动作的通行证。通行证上名字写错了，内容再对也过不去。

这就是为什么「差几毫米」在别的场景里是瑕疵，在这里是致命的。一份文档在屏幕上看起来没有任何问题，打印出来红头位置偏两毫米，整份材料的身份就模糊了——它到底算不算正式发文，接收的人得自己判断。

标准之所以把每一处都写得那么细，是因为它要消除的正是这种判断。格式的作用是让接收方不需要思考。

当一份材料需要对方思考「这个算不算合规」，它就已经失败了。

这也解释了为什么在正式材料这件事上，人们宁可多花半小时手动调版，也不愿意接受一份「差不多对」的文件。差不多对的材料，风险不在文件本身，而在接收方怎么处理它——是照收，还是退回来。

标准写给谁看

标准有两个读者。一个是对照着检查它的人，一个是流程里那些机械化的环节——打印、装订、扫描、归档。前者需要条款清晰，后者需要格式稳定。两份要求指向同一件事：材料的样子必须是可预期的。

可预期意味着，同样一份内容，不管由谁排版、在什么软件里打开、在哪台机器上打印，出来的结果应该一致。手感做不到这一点。手感能做出一次正确的排版，做不出每一次都正确的排版。

这两者之间的差，就是返工的来源。

公文格式不是审美，是标准

GB/T 9704-2012《党政机关公文格式》是一部现行标准，2025 年 5 月 30 日复审后继续有效。它的适用范围写在标题里——党政机关制发公文，其他机关和单位可以参照执行。

「参照执行」这四个字比看上去更重要。它意味着这套格式的辐射范围早就不止于党政机关。事业单位的请示、国企的通报、学校的正式函件、行业协会的会议纪要，凡是要盖章、要编号、要走登记流程的材料，多数都在参照这部标准排版。

这部标准已经存在十多年，执行它的人一直靠经验。经验可以传，但传得慢，也不保证一致：同一个办公室里的两个人，对「红线下标题应该留多大间距」可能各有各的做法，谁都说得出理由，谁都拿不出条款。经验在下一个人接班的时候，会衰减一次。

标准可以被写成代码。经验不行。

一个把标准写成脚本的项目

GitHub 上有一个项目叫 gongwen-gbt9704-skill，作者是 mizzlelover。仓库以 MIT 协议开源，2026 年 9 月 9 日建仓，用 JavaScript 写成，目前约 538 个 star、117 个 fork。

它的定位说得直白：把中文正式材料整理成符合 GB/T 9704-2012 的可编辑 DOCX，并且保留 Word 和 WPS 里可以更新的目录。

「可编辑」这三个字是关键。AI 输出格式的方式大致有三种：给一张图、给一个 PDF、给一段 Markdown。办公室要的不是这三种，是一份能继续被改、能继续走流程的文档。目录能更新这件事听起来很小，它决定了接手的人要不要从头再来一遍。

项目里最值得看的部分，是它对场景的区分。

普通报告默认走 ordinary，不因为填了机构名称就自动加红头。正式发文必须显式声明 formal。默认行为是「预印红头纸套打」：首面留白，不重绘红色机关标志和红线，因为纸是印好的。只有当使用者明确写出 formal --letterhead digital，脚本才会绘制完整的电子红头。

这种默认值的取向很少见。多数工具的思路是「能加上的都加上」，这个项目的思路是「不确定的就不动」。

红头是正式发文的标志。把它当装饰自动加上去，等于替使用者做了一个他自己都不知道自己做过的决定。一份本来只是内部传阅的报告，因为脚本多画了一个红头，性质就变得可疑了。

同一个思路上，文号要按年份、六角括号、顺序号和「号」字的规则逐项校验，不合规直接拒绝生成，而不是猜一个出来。信函格式里那两条红色双线，一条在 170mm 处上粗下细，一条在下页边 20mm 处上细下粗，底线放在页脚并把页码关掉。命令（令）、纪要、横排表格各自走专用分支，不共用一套版式参数。

「不合规直接拒绝」这个设计值得停一下。遇到不合规的输入，更省事的做法是猜一个最接近的值填进去，让任务看起来完成了。拒绝生成等于承认脚本无法替使用者做这个判断：文号里的年份、括号和顺序号都有出处，凭空补上一个，只是把问题挪到了下游。

把规则写进脚本还会带来一个副作用：规则的边界变清楚了。标准覆盖到的地方交给脚本，覆盖不到的地方仍然由人判断。一份材料该不该公开、用通知还是用请示、发给谁，这些不是排版问题。工具不越界，人需要判断的地方反而更明确。

差别都在这几毫米里。而这些毫米是可以被量出来的。

两个脚本，一个生成，一个检查

这个项目跟「用提示词让模型排版」最实质的区别，是它带了两个脚本。

node scripts/generate_gongwen_docx.mjs --input tests/fixture.md --output /tmp/gongwen.docx --format ordinary --title "公文格式回归测试"

node scripts/verify_gongwen_docx.mjs --input /tmp/gongwen.docx --profile ordinary

第一个负责生成，第二个负责核验。第二条命令读的是已经生成出来的文件，它检查的是这份 DOCX 实际是什么样，而不是它应该是什么样。

提示词能告诉模型「字号应该多大」。脚本能告诉你「这次生成的字号到底是不是那么大」。前者是意图，后者是证据。一份材料要交出去，凭的是后者。

生成和检查分成两步，还有一个不那么显眼的好处：错误会在文件离开你的机器之前暴露。检查跑在本地，发现问题的时候，没有人已经收到了那份材料。

验证的成本和返工的成本不在一个量级。跑一次检查是一条命令的事，退一次稿是一整天的事。这笔账在一个季度里会被算很多遍。

这也解释了这个项目为什么把测试用例写成了 fixture。排版需要回归——改了一处间距，不能让另一处悄悄坏掉。规则越多，这种连锁反应越难靠肉眼发现。

提示词排版差在哪

让通用模型直接产出一份 DOCX，它大概率能读能写，却保不住格式。标题层级、段前段后、缩进、页脚，都要重排一遍。

项目作者把原因记录在了 README 里，那段话说得比任何评测都直白：「WPS 和 Office Word 看着能互相打开，字体命名却不总在同一套规则里。有的环境认中文字体名，有的认英文名。一个文件在电脑上排得好好的，换个环境，字号、行距和换行都有可能变样。」他的结尾只有一句：总有一处露馅。

这句话说的是排版，指向的是所有把规则留在提示词里的做法。提示词约束的是模型的意图，不是文件的字节。模型可以非常努力地想按格式来，输出仍然可能在某个它看不见的环节上偏离——因为没有任何一步会把结果读回来核对。

手工调版是另一种局限。它把规则锁在个人的手感里，换个人接班、换台机器、换一套办公软件，同一份材料就要重来一遍。

两条路都通向同一个结果：文件的正确性依赖于当时当地，而不是依赖于规则本身。

有些红线，写在了功能说明之前

打开这个项目的 README，最先出现的不是它能做什么，而是一段提醒：本 Skill 用于文件转换与公文排版，不会替你判断文件是否可以公开。请勿把企业内部、涉密、敏感、受限或明确禁止对外的文件，上传到未获授权的在线模型、第三方服务或公共仓库。

一段安全提醒被放在所有功能说明之前，这个顺序本身就是一种判断。

排版 skill 要读的是文件内容。而公文类文件里，恰好集中了一个单位最不适合外流的东西：机构名称、人事安排、财务数字、尚未公开的决定。

项目的建议很具体——已经在本地或企业内网部署了大模型的单位，应该把这个 skill 装在自己的内网环境里跑。工具本身不改变数据边界，装在哪里才决定数据边界。

一套规则，八个平台

这个 skill 可以安装到八个平台：Codex、Claude Code、OpenCode、Trae Code、Kimi、TraeWork、WorkBuddy、ZCode。八个平台读的是同一份规则文件。

这件事的意义在于，格式标准第一次跟工具解绑了。同一套规则可以在不同的编辑器、不同的模型背后跑出同一份结果。写规则的人不必关心谁来执行，用规则的人也不必担心换了工具以后结果变了。

跨平台安装听起来只是适配工作，它其实回答了一个更根本的问题：规则到底属于谁。如果规则长在某个软件里，换软件就等于重新学一遍；规则长在文件里，软件只是执行它的手。

对使用者来说，这意味着一件事不用学两遍。今天在 Codex 里跑，明天换到另一个编辑器，格式的判断依据没有变，输出的文件也没有变。工具的竞争留在工具体内，规则本身保持不动。

目录能更新这件事也是同一类细节。可更新的目录依赖文档内部的样式层级，而样式名在不同语言环境的办公软件里并不通用。样式对不上，目录就成了一段死掉的文字——它看起来像目录，点下去没有反应。

2.0 版本的更新做了一件很笨但很必要的事：重新核验红头场景、首页预留、红线下标题间距、Word 与 WPS 的标题样式、目录引用、特殊格式和跨平台安装，然后完成了 18 份 DOCX、37 个 PNG 页面和版头坐标的量测。

量测的意思是，这些数字是从实际输出的页面上量出来的，不是照着标准文本抄进代码的。抄标准很容易，标准不会告诉你 WPS 渲染出来的那一行会不会多出两毫米。

作者的缘起也简单。他最早注意到 Skill 这个概念，是 Claude Code 推出它的时候。后来真正拿它去干活，才发现 Word 能读能转，但在意的格式留不住。事业单位和国企的正式材料更严，差几毫米、少一个页码规则，就很难往下走。

于是他把这套规则写成了可以反复运行的脚本。

同一作者还有一个配套项目 CEB，把已经验证过的 CEB 文件转换成 PDF、Markdown 和 TXT。两个 skill 连起来是一条完整的链路：读取、整理、交付。

当隐性能力变成可安装的规则

这个项目真正的价值不在公文。

它示范了一件事：把专业里的手工活变成可安装、可检查、可复制的规则。任何一个存在硬标准、却长期靠经验执行的领域，都可以走同一条路——财会凭证的装订与编号，法律文书的固定格式，实验记录的必填项，工程图纸的标注规范。

代码世界里发生过一次同样的事。在格式化工具普及之前，缩进用几个空格、大括号换不换行，是代码评审里最容易吵架的话题。这些争论消耗的时间很多，产生的价值很少。后来格式化工具出现，风格变成一条可以运行的规则，争论自动消失。

这套做法的另一个效果是组织的记忆变长了。经验会随着人离开而消失，规则不会。三个月后回来的人、三年后接手的人，面对的是同一份可执行的判断，而不是一段靠口述复述的回忆。

规则还有一个容易被忽略的性质：它必须写得足够具体才能运行。含糊的规则跑不起来，跑不起来就会被改到具体为止。把经验逼成代码的过程，本身就是一次把知识说清楚的过程。

能被检查的规则，也意味着责任可以追溯。一份材料不合格，问题出在规则还是出在输入，是可以查出来的。留在手感里的环节做不到这一点——除了那个人的记忆，没有任何地方记录过判断的依据。

规则被写成代码之后，知识就不再依附于某个人。能被安装，意味着一个新人不用跟着三个月的老同事才能上手；能被检查，意味着错误在交付之前就会被拦下；能被复制，意味着换一台机器、换一个平台，结果不会变样。

这也许解释了为什么这样一个看起来很窄的项目会有几百个人 star 它。人们 star 的不只是公文排版，而是一种做法：把说不清的手感，变成说得清的规则。

同样的假设也出现在另一件看上去不相关的事情上。当机器开始读你的文件、看你的官网、判断一家公司值不值得信任，那些过去靠人情和经验传递的东西，也要变成机器能读懂的、可核验的规则。「策思路 C456」（c456.com）在做的另一件事——让中小品牌被 AI 找到——放在这个脉络里看，逻辑是一致的。能不能被找到，能不能被信任，取决于你有没有把该写清楚的东西写清楚。

现在可以做的事

如果你的工作里存在一个「差一点就交不出去」的验收环节，那么它应该被写成脚本，而不是留在某个人的手感里。

判断的依据可以很简单：这件事下一次还会不会再错，错的时候会不会有人在旁边指出来。两个答案都是否，它靠的是手感；两个答案都是是，它就欠一条规则。

能被量出来的东西，不该交给记忆。手感应该用在标准覆盖不到的地方——那里才是它真正值钱的位置。

来源

• 项目仓库：https://github.com/mizzlelover/gongwen-gbt9704-skill
• 配套项目 CEB：https://github.com/mizzlelover/CEB
• GB/T 9704-2012《党政机关公文格式》：https://std.samr.gov.cn/gb/search/gbDetailed?id=lOIe27f77QU%3D&mode=p

本文由「策思路 C456」（c456.com）团队撰稿。