故事是这样的。

我最近开源了一个小项目。

名字叫文格。

地址在这里。

github.com/lilialla/legal-document-format-skill

这个东西解决的问题很土。

法律文书里的 Word 模板。

你如果做过正式文书，应该很熟悉这种痛苦。

正文写完以后，真正折磨人的地方来了。

页眉要保留。

页脚要保留。

页码不能乱。

标题字号要对。

正文行距要对。

落款位置要对。

签名区不能被挤到下一页。

中文标点别一会儿全角，一会儿半角。

该用 Times New Roman 的地方就用 Times New Roman。

模板里没有这么写的地方，别自己乱跳。

这些东西听着都很小。

但正式文书里，小问题会直接变成专业感问题。

你把一份文书交出去，对方未必知道你背后用了什么 AI。

他只会看到，这个 Word 文件看着稳，还是看着松。

这就是我做文格的原因。

我一直觉得，法律 AI 真要落地，迟早会遇到 Word。

聊天框里生成一段文字很爽。

Markdown 里整理一份材料也很爽。

但律师真正交出去的，很多时候还是 Word。

律师函是 Word。

合同修订稿是 Word。

仲裁文书是 Word。

法律意见书是 Word。

尽调报告是 Word。

公司内部审批材料，很多也还是 Word。

所以问题就来了。

AI 生成的内容，怎么进入这些既有模板。

怎么让它按团队模板干活。

怎么让它生成完以后自己先查一遍格式。

我想做的，就是这件事。

把 Word 模板变成 Claude Code、Codex 这类 Agent 可以执行的东西。

你把模板给它。

再把任务告诉它。

比如说。

这是我们所里的律师函模板。

请根据这个表格生成 20 份律师函。

收件人、案号、金额、截止日期都在表格里。

页眉、页脚、标题、行距、落款、签名区，都按模板来。

生成后逐份检查格式。

能交的告诉我。

要人工看的也告诉我。

这就是文格想服务的场景。

模板进来。

任务进来。

材料进来。

AI 按模板做事。

然后跑交付前检查。

很多人讲 AI 工作流，会把 prompt 看得很重。

这个当然没问题。

但法律工作里，还有一种东西经常被低估。

模板。

模板里藏着很多真实要求。

页眉里有机构名称。

页脚里有固定格式。

标题样式里有字号。

正文段落里有行距。

签名区的位置，决定文件交出去时看起来是否正式。

编号、分节、页码字段、表格边框，这些东西很少有人逐条写进 prompt。

可它们都是真实要求。

让用户把这些要求全部用自然语言复述一遍，挺没必要的。

模板已经摆在那里。

AI 应该去读它。

但这里还有一个坑。

只把模板文件丢给 AI，再写一段很长的 prompt，效果经常也不稳。

我自己试下来，问题大概出在几个地方。

模型看到的是一个文件。

Word 真正麻烦的地方，却藏在文件结构里。

同一行字，可能被拆成好几个 run。

看起来一样的标题，背后可能引用了不同样式。

页眉页脚、分节符、页码字段、编号、表格边框，很多都藏在 XML 关系里。

你在 prompt 里说一句按模板来，模型未必知道到底要保住哪些东西。

它可能保住了文字。

丢了页眉。

保住了标题内容。

字号跑了。

保住了表格。

边框和段距开始飘。

更麻烦的是，一旦任务变长，prompt 里会同时塞进内容要求、事实材料、格式要求、输出要求、检查要求。

这些要求会互相抢注意力。

模型很容易先把正文写完，然后把格式当成差不多就行。

法律文书最怕这个差不多。

所以这里需要的，其实是一套执行纪律。

AI 要知道什么时候读模板。

什么时候保留包结构。

什么时候只改文本。

什么时候必须渲染成图片看页面。

什么时候发现做不到，就停下来报告。

这就是 Skill 的意义。

它把一段临时 prompt，变成一套稳定的工作规程。

所以文格的定位很简单。

法律文书模板执行 Skill。

它面向 Claude Code、Codex，或者兼容 Skill 的本地 Agent。

用户给模板。

用户说需求。

Agent 读模板，生成候选文书，批量处理，跑检查，给报告。

如果模板已经有固定字段，当然可以走确定性脚本。

比如 `{{CASE_NO}}`、`{{CLAIMANT}}` 这种。

这个路径很稳。

复制模板包结构。

替换明确字段。

检查 OpenXML 结构有没有漂。

但普通用户用起来，不应该先被模板字段拦住。

正常入口应该始终是给模板，讲需求。

这个项目现在做了几件事。

第一，给 Agent 一套路由规则。

它要先判断任务类型。

只清理文字，就走文本清理。

普通 Word 排版，就走普通排版。

用户给 DOCX 模板，就走模板执行。

用户要求渲染、分页、视觉检查，就走视觉校验。

这一步很重要。

法律 AI 最怕任务入口混掉。

明明用户只是想清理标点，结果模型开始重写内容。

明明用户给了模板，结果模型从空白 Word 重新生成。

明明只是格式定稿，结果模型顺手改了事实和请求。

这都很危险。

第二，给交付前检查做门禁。

现在文格会检查文本标点、DOCX 结构、页眉页脚、页码字段、标题字体字号、标点字体、渲染页这些东西。

完整发布版要求装 LibreOffice 和 Poppler。

原因也很简单。

Word 里看起来结构没坏，还不够。

最终要转成 PDF，再渲染成图片，看它页面层面有没有明显问题。

页码错了。

签名区跑了。

页面数量不对。

这些东西都要在交付前暴露出来。

第三，保留一个很保守的确定性模式。

如果团队已经维护了字段化模板，可以直接用脚本生成。

这个模式适合批量、稳定、长期复用的模板。

律师函。

催告函。

固定格式报告。

标准附件。

这类东西就很适合。

当然，文格现在还早。

我不会说它已经能吃掉任意复杂 Word 模板。

Word 这玩意，比很多人想象得阴。

一个看起来正常的文档，里面可能有一堆 run。

一个标题可能拆成好几个文本节点。

页码可能是字段，也可能已经变成普通文字。

表格里可能套表格。

分节符可能藏在完全想不到的位置。

内容控件、编号、样式继承、字体回退，随便一个都能让自动化工具整懵。

所以文格现在强调一件事。

能执行的执行。

能检查的检查。

能证明的证明。

证明不了的地方，直接报告给人。

这点我觉得很法律。

不懂的东西，先别改。

没有依据的内容，先别补。

无法确认的格式，先列出来。

这套纪律放到 AI 文书生成里，一样适用。

我现在越来越觉得，法律 AI 真正要落地，不能只停留在会写。

会写只是第一步。

更麻烦的是进入工作现场。

工作现场里有模板。

有材料。

有表格。

有历史版本。

有机构格式。

有某个老师口头说的，这个落款别动。

这些东西一起构成任务。

AI 只读 prompt，就像一个刚入职的实习生。

你得把所有事情掰碎喂给它。

AI 能读模板，才开始有点像真的进了办公室。

它开始知道这间办公室怎么写文件。

这就是文格想做的事。

让 AI 读模板。

让 AI 按模板做事。

让 AI 把做不到的地方说出来。

让脚本把能检查的东西拦住。

让律师把必须判断的东西拿回来。

现在仓库是公开的。

测试 65 个。

release smoke 10 步通过。

示例材料只用 synthetic 数据。

没有真实案件。

没有客户材料。

没有私有模板。

如果你也在做法律 AI 工作流，尤其是已经开始让 Claude Code 或 Codex 处理真实文书格式，可以翻一下这个项目。

不一定直接拿去用。

但这里面有一个思路，我觉得值得认真对待。

模板也是指令。

法律 AI 不能只会听 prompt。

它还得看得懂一份 Word 模板背后的工作秩序。

项目地址。

github.com/lilialla/legal-document-format-skill

大概就是这样