政务大模型落地难？从文档校对这个刚需切进去

这两年政务大模型的新闻不少见：签约、共建、上线仪式，照片里大屏放着智能问答演示。可你回头问科室里写材料的人，大模型到底帮你干了什么，十有八九会愣一下——演示归演示，手头的稿子还是一个字一个字抠出来的。

做信息化这些年，我慢慢有个判断：政务大模型落地难，难在大家习惯从"平台"切入，先建底座再找场景，结果场景永远在找的路上。真正在科室里跑起来的应用，几乎都是从一件具体的活切进去的。今天想说的这个切口，是文档校对。

疑问一：为什么不直接用通用的 AI 对话框？

也能用，但机关材料的场景很具体：稿子在 WPS 里，格式是公文格式，改法应该是"在原文上圈出来"，而不是"在聊天窗口里给你一段重写的"。来回复制粘贴，一是容易贴错版本，二是改没改、改了哪，不留痕。公文讲程序、讲留痕，对话框这个形态天然不合适。

还有一层：把材料贴到外部网页，本身就有数据出域的风险。敏感不敏感先不论，制度上就过不去。

疑问二：为什么说校对是刚需？

三个理由。第一，它天天有。收文要核，发文要校，上报材料要审，一年到头不断线，不存在"用不上"的空窗期。第二，它有相对明确的对错。错别字、序号层级、数字前后不一致，这些不需要审美判断，机器干正合适，干得好不好一眼能验。第三，它风险可控。批注是建议，采不采纳人来定，不会一上来就把 AI 推到需要担责任的位置上。

落地这件事，第一站选在哪里，比跑多快重要。选一个天天有、对错明确、风险可控的活当切口，用起来才可持续。

疑问三：一套什么样的工具能接住这个刚需？

以我们在用的察元AI文档助手为例说说形态。它是跑在 WPS 文字里的加载项，加一个装在本机的 MCP 文档服务，服务只监听 127.0.0.1 这个本机回环地址，不对外。模型层不绑定任何厂商，Ollama、LM Studio、Xinference 这类本地推理端点都能接，配好了就是一个 token 都不出网的纯离线用法；要并行配云端供应商也可以，选择权在使用者手里。

加载项里内置的助手有 29 个，校对之外，生成摘要、提取行动项、术语统一这些材料岗高频活都有现成的；科室里用 Claude Code、Cursor 这类智能体的年轻人，还可以通过 MCP 协议直连文档服务，把核对动作编排起来跑。

拿一份要上报的情况说明举例。稿子定稿前，选中全文，让校对助手先跑 dryRun——只出问题清单，不动正文。清单按类型归拢：错别字几个、标点几处、术语前后不统一的几组。确认后再把问题转成批注写回文档，每个问题钉在原处，交给起草科室自己认领。

发文频率高的单位，终检时用这条提示词一步到位：

帮我做发布前终检：错别字、标点、数字前后一致性、表格与正文是否一致；全部用批注输出；最后给我一份问题分级摘要（严重/一般/建议）

这条是我用得最多的一条。批注加分级的组合，拿去给领导过目也说得清楚：严重几条、一般几条、建议几条，一目了然。

疑问四：安全这条红线怎么守？

这是政务场景的第一问，答案分两层。网络层，本机服务只监听回环地址，模型可以是纯本地的，材料不出这台电脑，这是拓扑上保证的。内容层，加载项里有保密检查助手，能对密级标识、涉军涉装标识、联系方式、商业秘密等给出分级风险提示；需要对外脱密的材料，可以先预览脱密效果、不写盘，确认后再正式处理。

适合谁用？我的观察是：收发文频率高的办公室、要报材料的业务科室、搞试点的信息部门，都是第一批用户。

疑问五：哪些活还是要人来？

边界也要说清楚。涉密事项的处理、密级的判定，该走的流程一步不能少，工具不能替代人工定密；政策口径的把握、表述分寸的拿捏，AI 给的是参考，签字的人心里要有数。校对能交给机器，把关不能。

政务大模型这个盘子最后能做多大，我说不好。但从校对这一件事切进去，让写材料的人先尝到"稿子不用自己盯三遍"的甜头，后面的事，反而好谈了。