法律文书模板智能填空 - 我踩过的三种错法，和最后跑通的那条路
给独立开发者和小团队写一篇实话实说的场景复盘。
先说我做砸的三个版本
去年接了个活：帮一家做法律科技的初创团队做「合同模板智能填空」——用户上传一份劳动合同或租赁合同模板，系统自动识别需要填写的空位（甲方名称、金额、日期、违约条款参数），再根据用户对话输入的信息逐项填充。
听起来简单，我第一版直接上了「全文丢给大模型」的方案：把整份合同塞进 prompt，让模型找出所有占位符并返回填充结果。
结果三个坑接连出现：
坑一：模板超过上下文就崩。 一份四十页的股权协议，模型开始「截断式幻觉」，凭空编造条款。更糟的是它会把合同里本来就有的「例如：某某公司」当成待填空位。
坑二：结构化输出不稳定。 我让模型返回 JSON，今天返回带 markdown 代码块，明天键名大小写不一致，后天干脆在 JSON 前面加一段「好的，以下是结果」。下游解析代码天天打补丁。
坑三：每家模型 API 各写一套适配。 起初用 OpenAI，后来发现国产模型对中文合同语料更好，又接了两家。三套 SDK、三种鉴权、三种错误码、三份限流逻辑——团队只有两个后端，维护成本直接失控。
正确路径：把「填空」拆成三段流水线
回头看，失败根因是用生成式思路解决结构化任务。正确做法是把问题拆开：
第一段：占位符抽取（规则优先）
├─ 正则匹配 {{...}}、____、【】等显式占位符
└─ 仅对无标记的隐式空位调用小参数模型做 NER 抽取
第二段：信息收集（对话式，状态机驱动）
├─ 维护字段清单与填充状态表
├─ 每轮只问缺失字段，支持"一次性粘贴全部信息"的兜底解析
└─ 模型仅负责"从用户自然语言中提取字段值"，单字段小请求
第三段：填充与校验
├─ 用模板引擎做字符串替换，AI 不碰最终文档
├─ 金额、日期、证号走正则校验，校验失败回问
└─ 输出前跑一遍 diff 比对，确保未填区域零改动关键原则一句话：让 AI 做理解和提取，让代码做替换和落盘。 模型每次请求只处理一个字段或一小段上下文，幻觉空间被压到最小；JSON 输出只出现在「单字段提取」这个小场景里，用 function calling / JSON mode 强约束，解析层一套代码写完就不再动。
为什么统一 API 网关省下大半维护成本
第三段的架构定了之后，模型选型反而变成高频操作——不同字段类型适合不同模型：占位符抽取用轻量模型，复杂条款语义匹配用大参数模型，还有夜间批量处理历史模板的任务要蹭低价算力窗口。
如果每家模型都直连原厂 API，意味着：
- 鉴权、重试、限流逻辑 ×N 份重复实现，每家错误码格式还不一样；
- 换模型 = 改代码，而模型性价比排序几乎每月都在变；
- 账单分散在多家后台，成本归因靠手工拉表格。
接入统一 AI API 网关后，这些问题被一次性消解：所有请求走同一个 OpenAI 兼容端点，换模型只是改一个模型名参数；网关层统一处理重试、降级和多密钥轮换；账单和用量统计天然聚合，哪个功能烧了多少 token 一眼可见。对我们这种两人小团队，等于把「模型运维」这件事从代码库里删掉了——两后端终于能专心打磨字段抽取的准确率，而不是当 SDK 修理工。
落地效果与几点提醒
重构后的版本，占位符识别准确率靠规则兜底做到接近百分之百，隐式空位抽取的漏检率也降到可接受范围；最直观的变化是客服反馈里「填错位置」类工单基本消失。
三点提醒：
- 法律场景必须保留人工确认环节，AI 填完后强制用户逐项核对，页面高亮所有 AI 填充位——这既是合规要求，也是免责设计；
- 敏感信息脱敏后再进模型，身份证号、银行账号在发送前做掩码，返回后本地还原；
- 给每个字段类型建立小测试集，几十条标注样例就能在换模型时快速回归，避免「换了个便宜的，质量悄悄掉了」。
如果你也在做类似的 AI 文档应用，与其在多家模型 API 之间来回迁移代码，不如从第一天就走统一网关。注册入口在这里：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。