合同填了三版全是坑——法律文书智能填空，先排掉那些错误做法
一次失败的重来
一位独立开发者朋友接了个活：给一家小型法律咨询工作室做在线文书模板系统。用户的诉求很朴素——选一份「劳动合同」或「租赁协议」模板，填几个关键信息（甲方乙方、薪资、期限），系统自动生成一份结构完整、条款自洽的文书。
他的第一版做法是：拿一个通用大模型，把整个模板塞进 prompt，让模型「填写并润色」。上线一周，问题集中爆发：
- 模型擅自改动了模板里既定的法律条款措辞，律所审核时被打回；
- 同一个字段，模型一会儿填「人民币 8,000 元」，一会儿填「捌仟元整」，格式完全不统一；
- 有些模板长达几十页，长文本下模型漏填字段，甚至把「乙方」填进了「甲方」的位置；
- 为了效果换了个更强的模型，接口格式、鉴权方式、字段名全要重写，一个下午就耗进去了。
这不是模型不行，是做法错了。下面是复盘后的正确路径。
业务痛点先厘清
法律文书智能填空，难点不在「生成」，而在「约束」：
- 模板不可篡改：条款是律所审定过的，AI 只能填空，不能改写正文；
- 字段有格式规范：金额、日期、期限必须符合法律书写习惯；
- 字段之间有依赖：合同期限、试用期上限、社保条款之间有法定的联动关系；
- 模板种类多：劳动合同、租赁、保密协议、授权委托书，每类规则都不同。
通用生成式「一把梭」的做法天然与这些约束冲突。
正确的架构：模板是骨架，AI 只做填空员
重构后的架构分四层：
┌─────────────────────────────────────┐
│ 模板层：文书模板 + 字段占位符定义 │
│ （{{party_a}} {{salary}} {{term}}） │
├─────────────────────────────────────┤
│ 抽取层：对话式收集用户信息 │
│ （多轮问答，逐个补齐字段） │
├─────────────────────────────────────┤
│ 推理层：AI 只负责字段值的生成与校验 │
│ （结构化输出，不碰模板正文） │
├─────────────────────────────────────┤
│ 渲染层：纯代码做字符串替换 + 规则校验 │
└─────────────────────────────────────┘核心原则一句话：AI 只产出结构化的字段值，模板渲染交给确定性代码。这样律所审定的条款一个字都不会被模型碰，出问题的概率从「每次生成都可能出错」降到「个别字段需要人工确认」。
关键实现步骤
第一步：模板结构化。 把每份文书拆成「固定正文 + 字段清单」。字段清单用 JSON Schema 定义，包含类型、格式、校验规则和字段间约束：
{
"template_id": "labor_contract_v3",
"fields": [
{"name": "salary", "type": "currency", "format": "人民币{amount}元/月"},
{"name": "term_months", "type": "int", "min": 1, "max": 36},
{"name": "probation_months", "type": "int",
"constraint": "term_months<=12 ? probation_months<=1 : probation_months<=6"}
]
}第二步：对话式收集。 不让用户填一张三十项的大表单，而是让 AI 引导式提问——「这份合同的甲方公司全称是？」「员工月薪是多少？」——每轮只问 2-3 个相关字段，缺失信息补齐即停。
第三步：结构化生成 + 双重校验。 要求模型以 JSON 返回字段值，代码层再用规则引擎二次校验（金额格式、试用期上限等）。模型输出只占流程的一小段，出错的爆炸半径被牢牢圈住。
第四步：渲染与留痕。 字符串替换生成终稿，同时输出一份「字段填写说明」，标注哪些值来自用户输入、哪些由 AI 推断（比如根据「工作地点：北京」自动补出「由北京市社会保险经办机构办理」），便于律所快速复核。
为什么统一 AI API 网关能降低维护成本
我朋友在最开始踩的第四个坑——换模型等于重写一遍集成——其实是独立开发者最容易低估的长期成本。接入统一 AI API 网关后，价值体现在三处：
- 协议统一：抽取、对话、校验三个环节可能用不同模型（便宜模型做问答收集，强模型做复杂字段推理），网关把不同厂商的接口归一成同一套调用格式，换模型只改一个 model 参数，不动业务代码；
- 密钥收敛：不需要在多个服务里散落各家的 API Key，密钥轮换、泄露处理都只在一处操作；
- 成本与监控集中：每类文书、每个环节的 token 消耗一目了然，长模板的账单异常能当天发现，而不是月底看账单才知道某个 prompt 写炸了。
对一两个人的小团队来说，这意味着把「适配各家模型接口」这种零价值工作压缩掉，精力全部留给业务规则本身。
收尾
法律文书这个场景，说到底考验的不是提示词技巧，而是对「AI 能做什么、不能做什么」的边界判断：把模板的确定性交给代码，把理解和推理的模糊性交给模型，两者各守其位，产品才能通过律所那道审核关。
如果你正准备动手做类似的 AI 应用，不想在多家模型接口之间反复适配，可以先到 https://api.thistoken.ai/register 注册一个统一网关账号，把模型接入这层一次性理顺，再回来打磨你的字段规则——顺序对了，事情就成了一半。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。