司法AI文书生成的质量防线：从架构设计到分层校验系统实践

1. 先泼一盆冷水：文书翻车，多半不是“模型不行”

做过司法AI这个方向的同行应该都有类似感受：外界一提“AI写判决书”，第一反应就是“模型会不会乱写”。但真正在一线盯过项目的人会告诉你，绝大多数线上翻车，根子都不在生成模型身上，而在架构设计上——模型只是最后那个把错误“写出来”的出口，错误早在输入阶段就埋下了，或者早就该被一道规则闸门拦下却没人拦。

我参与过几个司法辅助文书类项目，最深的体会是：文书质量控制的真正分水岭，不是大模型选得多强、参数量多大，而是你有没有把“不犯错”当成一个系统工程来设计。司法文书的容错空间接近零，但大模型这种生成式系统的容错率天然不为零，这两者之间的矛盾，只能靠架构去弥合。正文里没有细节、没有关键词，那正好，这篇我就纯粹盘一盘自己的架构经验：司法AI做文书生成，到底该在哪些环节设防，才能把错误率压到可用水平。这篇文章是写给架构师、算法负责人、质检团队的，也适合刚入行的同学理解“为什么司法AI不能只靠一个模型”。

先说一个反直觉的结论：与其花大力气追求“模型一次生成完美”，不如设计一套“允许模型犯错，但错误不会流到文书定稿里”的架构。后面的内容全部围绕这句话展开。

2. 我复盘过的三类典型错误：先知道错在哪，才知道防什么

2.1 漏判类错误：模型“忘了”把某项诉讼请求写进判项

最典型的一幕发生在一份借贷纠纷判决书初稿上。当事人的诉讼请求有三项：偿还本金、支付利息、承担律师费。模型生成的“本院认为”部分把律师费是否支持说得很清楚，但到了“判决如下”的主文部分，只写了本金和利息，律师费这一项凭空消失了。这种错误在纯文本生成场景里无人在意，但司法文书里属于实质错误——当事人拿着判决书去执行，发现有一项诉求没被裁判，整个案件可能因此被发回重审。

复盘根因有三层。第一层，输入的起诉状里律师费诉求被其他杂文本淹没，要素抽取模块没有把它识别成独立诉求；第二层，生成提示词里只给了一个笼统的“请根据案件材料生成判决书”，没有强制模型对照“诉讼请求清单”逐项检查；第三层，输出侧没有任何校验规则能判断“三项诉求对应了三项判项”，所以在系统层面无人感知这个错误。

这类错误的共性在于：模型的语义理解能力不到位，不是“不会写”，而是“没注意”。恰恰是这种“没注意”，单靠换更大参数的模型解决不了，必须在架构上把诉讼请求变成生成过程的强约束项。

2.2 信息漂移类错误：名字、金额、日期在长篇文书里互相打架

第二类错误更隐蔽，也更常见。一份合同纠纷判决书初稿里，“某某建设有限公司”在事实查明部分出现了七八次，突然在最后一页的判项里变成了“某某建设有限责任公司”，多出“责任”两个字。同样离谱的还有：正文里写着原告主张违约金按每日万分之五计算，判项里写的却是“按年利率万分之五”；庭审笔录里开庭日期是5月10日，生成的判决书落款却是5月8日。

这种现象我在项目中叫“长文本一致性漂移”。大模型在生成超长文书时，对前文细节的记忆会衰减，尤其当某个名称在原始案卷里本身就存在两种写法、OCR识别结果又不一致时，模型很容易在不同段落里“各信各的”。大家常以为这是模型缺陷，其实任何生成模型都会有这个毛病，区别只在于架构有没有兜底。

钥匙插槽的比喻很贴切：一份判决书里的当事人名称、身份证号、金额、日期，就应该像插槽一样被提前锁定，生成过程中只允许在插槽里取值，不允许模型“自由发挥”。可惜很多早期项目没这么做。

2.3 程序性错误：法条失效、诉讼费算错、审限违反常识

第三类错误属于“电脑应该算对但人没算对”的范畴。比如引用了一份已经废止的司法解释；比如诉讼费金额按比例计算时搞错了分段基数；再比如简易程序案件在判决书里却写着“组成合议庭”。这类错误的诡异之处在于，它们完全不需要模型具备多高智能，纯规则计算就能发现，但很多项目默认“模型应该会”，结果没人校验，反而成为上线后最先爆发的问题。

诉讼费计算尤其典型。一个300万的合同纠纷，案件受理费按比例计算，有人按500万去算，判决书金额就会跟法院系统自动计算的金额对不上。法官复核时也许能发现，但如果在辅助生成阶段就被规则引擎拦住，连让法官费眼的机会都没有。这类错误的存在说明一个问题：任何“模型应该会”的假设，在司法场景里都是不合格的架构设计。

3. 分层质量闸门：把“不犯错”从口号变成架构能力

3.1 第一道闸门：输入侧案卷结构化清洗

我始终认为，文书质量控制的起点根本不在生成模型，而在输入侧的“案卷结构化”。案卷材料里有什么，很多东西在进系统之前就乱掉了：OCR把“贰拾万元”识别成“贰拾万无”，起诉状和证据清单里的公司名称不一致，庭审笔录里当事人的陈述和诉状主张存在出入。

所以项目里必须有一个独立的预处理层，把起诉状、答辩状、证据清单、庭审笔录先做要素抽取和交叉验证。具体操作分三步：第一步，抽取关键要素，包括当事人信息、诉讼请求清单、事实与理由摘要、争议焦点；第二步，对跨文档要素做一致性对齐，比如起诉状里的原告名称和判决书拟稿里的原告名称必须完全一致，不一致的以营业执照或身份证明文件为准并自动纠正；第三步，生成一份“结构化案件摘要卡”，这个摘要卡会成为后续所有生成环节的唯一事实来源。

这一步做扎实之后，很多下游错误根本不会发生。我曾经做过一次统计，某次迭代里输入侧清洗修掉了接近一半的实体不一致错误，而模型一个参数都没动，线上错误率就明显下降。

3.2 第二道闸门：生成策略采用“骨架填充”而非“整篇自由写”

在模型生成阶段，架构上最值得花力气的地方是生成策略的取舍。早期项目里我们走过“让模型端到端直接生成整份判决书”的路线，效果怎么说呢，读起来很像回事，但细看处处是雷。后来改成“骨架填充分层生成”，错误率肉眼可见地降了一个量级。

具体做法是：先用结构化案件摘要卡里的要素，按判决书的标准结构生成“文书骨架”。这个骨架里每一个段落，都提前标注好哪些内容是“变量插槽”，哪些内容是“自由说理区”。例如事实查明部分是相对固定的叙述框架，模型要做的是把摘要卡里的要素按顺序填充进去；本院认为部分属于说理区，模型可以自由发挥，但涉及到对证据采信、争议焦点认定时，必须显式引用争议焦点清单中的编号。

这种做法有三个好处。第一，可校验——因为骨架结构是预设的，每一段是什么角色一目了然，规则引擎可以精确检查“判项数量是否等于诉求数量”；第二，可追溯——每个判项都有对应的要素来源，法官复核时点一下就能看到这个结论是从哪份材料里来的；第三，可局部替换——某一段写得不好，单独重新生成那一小段就行，不需要把整份文书推倒重来。用工程上的话说，就是我们把不可控的自由度压缩到了最小范围。

3.3 第三道闸门：规则引擎与一致性校验，专治低级错误

在骨架生成之后，必须经过一道“不讲情面”的规则引擎校验。我一直跟团队强调：规则引擎不是可选项，它是司法AI文书的最后一道机械防线。模型是概率系统，规则引擎是确定系统，用确定系统去卡概率系统的输出，这个组合才让人放心。

规则引擎里必须包含四类检查：

数值一致性检查是重中之重。整个文书里只要出现金额，规则引擎就要建立一个“金额图谱”：起诉状里主张多少，证据里认定多少，判项里支持多少，诉讼费计算依据是多少。所有金额必须在这个图谱中找到合理的对应关系，任何一处对不上就拦截并警告。诉讼费计算这类有明确计算逻辑的字段，规则引擎直接内置计算公式做独立验算，不允许依赖模型输出。

这一层闸门还有一个容易被忽略的价值：它能把法官复核时的注意力从“逐字通读”解放出来，变成“只看被规则引擎标出的疑点”。复核体验完全不同，这是架构对人效的隐性贡献。

3.4 第四道闸门：人机复核界面，让审查者“十几分钟看完一份文书”

很多人有个误区，觉得AI生成文书之后，交给法官从头到尾通读一遍就行。但一份判决书少说三千字，多则上万字，人的注意力天然会随着阅读时长衰减。更好的设计是，把复核界面做成“差异导向”的——让法官只处理需要人判断的东西。

我们项目的复核界面有三个核心设计。第一，全文差异高亮：对比AI生成的文书初稿和系统提取的案件要素，凡是判项内容、当事人名称、金额数字，都自动标记来源；法官点到某个判项，左侧直接出现对应的诉讼请求原文和证据材料位置。第二，风险提示聚合：把规则引擎发现的疑点统一列在一个侧边栏，按严重程度排序，法官逐一处理疑点，处理完就等于完成了大部分复核。第三，一键定位到出处：任何一句话，法官都可以看到它是从庭审笔录、起诉状还是证据清单里来的，不需要自己翻卷。

这套界面的设计逻辑是把“审查”从通读变成“验收”，从让法官自己找错变成工具主动告诉法官哪里可能需要看。实测下来，复核一份常规判决书初稿的时间，从半小时到一小时降到了十分钟到二十分钟。质量控制的最后一公里，永远是人和机器配合着走完的。

4. 对抗式评测集：如何证明这套体系“真的变好了”

4.1 我为什么坚持不用真实案卷直接做评测

很多团队在验证文书生成质量时，习惯性想到“找一批真实案卷来测”。这个想法在司法场景里有三个大坑：第一是数据合规问题，真实案卷涉及当事人隐私和案件保密，未经脱敏处理不能随便用来跑模型；第二是样本偏差问题，某个法院手里能拿到的案卷就那么几类案由，测来测去都是同类文书，发现不了跨类型问题；第三是“脏数据”干扰问题，真实案卷里本身就有瑕疵，无法区分错误是系统生成的还是原始材料里的。

所以我坚持的做法是：构建一套完全虚构的对抗式评测集。案件当事人、金额、日期、地址全部由程序批量生成，每个案件都是模拟案卷，再人为往里面注入特定类型的错误。这样既没有合规压力，又可以精确控制变量，知道每个测试案例在考系统哪个能力。

4.2 评测集的三层设计，分别拦不同级别的错

我们的评测集在设计上分成三个层次，每一层盯一类能力。

第一层是“基础写作正确性”。这一层主要测文书结构、语句通顺度、法律术语规范度，样本量最大，用来快速发现模型生成质量的整体回退。第二层是“法律要素完整性”。每个测试案例都提前标注了必须覆盖的诉讼请求、争议焦点、证据采信结论，分值计算时直接看要素覆盖率，这一层专门防漏判类错误。第三层是“对抗性错误诱导”。这一层最花心思，也是真正决定系统上限的测试。

对抗样本的设计要贴近真实世界的“魔幻输入”。比如：在案卷里让两个当事人同名同姓；故意把原告公司名称写成“某某建设有限公司”，在另一份证据里又写成“某某建设责任有限公司”；把诉讼请求金额在起诉状里写大写“壹佰万元”，证据清单里写阿拉伯数字“100,000元”；把法条序号整体后挪一位，让模型引用一个不存在的“第X条”。系统要在这些诱导下依然产出正确文书，才算真正扛打。这些样本能有效暴露“模型只是读起来像人写，但内部没有真正理解一致性要求”的问题。

4.3 回归分数卡：每次发版都要重新过一遍

评测集建好之后，最重要的事情是固定成“回归测试”，每版模型、每次规则引擎调整，都必须全量跑一遍，然后产出一张分数卡。这张分数卡是质量控制体系里最容易理解也最容易忽略的部分——没有它，所有优化都说不清是好是坏。

我们的分数卡大致长这样：

这张表的核心价值是让所有人看到“错误被拦住的比例”——规则引擎只要触发，文书就不会带错流出，所以拦截率几乎都是100%；但检出率告诉我们还有多少错误连规则引擎都没发现，这才是后续迭代的方向。对抗性诱导的检出率通常最低，这说明系统面对刻意设计的错误时仍有盲区，不能因为分数卡好看就掉以轻心。每次发版对比分数卡，升了可以上线，降了必须回滚，这是铁律。

5. 出错之后的处理闭环：错误上报、根因归类、修复回归

5.1 让一线复核者把纠错行为变成数据

再好的架构也做不到零错误。真正拉开团队差距的，是出错之后有没有一套闭环机制把错误变成改进弹药。我见过太多项目，法官在复核界面手动改了错别字、改了金额、改了法条序号，改完点一下保存，这事就结束了——但那个修改动作本身，是整个系统最宝贵的数据，被白白扔掉了。

正确的做法是在复核界面集成“纠错记录”功能。复核者每改一处内容，系统自动记录三样东西：改前的文本、改后的文本、修改位置所在的文书段落类型。再配合一个可选的原因标签，比如“金额错误”“名称不一致”“法条引用错误”“表述不当”。复核者只需要点一下下拉框，不需要额外付出任何工作量。这些数据攒上一个季度，就是一份精准到字段级别的错误热力图——告诉你系统的错误集中在哪类段落、哪类要素、哪类案由，比任何算法团队的猜测都准确。

5.2 根因归类：“四个盒子”判断法

拿到错误数据之后，我们习惯先做根因归类，再谈修复。每个线上错误都可以问自己四个问题：这个错误是生成模型造成的，还是输入侧信息就是错的？是规则引擎没覆盖到，还是规则本身有问题？是知识库里的法条数据过期，还是抽取模块把案卷信息抽错了？是单次偶发抖动，还是系统性错误？

对应“四个盒子”就是：模型层问题、规则层问题、知识库问题、输入链路问题。归类方式不同，修复手段天差地别。模型层问题要调提示词、换生成策略、做局部微调；规则层问题要补充校验规则；知识库问题要更新法条数据；输入链路问题要修OCR后处理或要素抽取逻辑。用这四个盒子做第一轮分类，大部分错误在五分钟内就能定位到责任模块，后续再深入分析具体根因就有了明确入口。

5.3 小步修复与回归验证：修错不能引入新错

很多人以为修复一个线上错误就是立刻改代码、重新发版。放到别的系统里也许可以，司法AI文书的修复必须走“小步验证”的路子。首先，任何修复行为（新规则、提示词调整、知识库更新）都先落到测试环境，在对抗式评测集上跑一遍回归，确认这个修复没有破坏其他检测项。举个例子，为了拦截“名称漏字”加了一条“全文字符串比较”规则，结果把一段正常的“简称转全称”也误拦了，这就是修复引入的新错误，必须在回归阶段发现。

其次，修复应该尽可能收敛在局部。模型某段说理不够好，优先尝试优化该段的生成提示词或局部重写策略，而不是重新训练整个模型；规则引擎某类漏检，优先增加一条检测规则，而不是重写规则架构。局部改动，影响面小，回归风险也小，这对一个低容错场景的系统来说至关重要。

最后，每个错误修复之后，要把这个错误本身变成长久的测试样本。我项目里有一条铁律：任何线上错误，确认根因并修复后，必须把出错案例脱敏后加入对抗式评测集，命名成“回归防退化案例XX”。这样做的目的是确保同一个坑永远不会以同样的方式踩第二次——模型换代、规则重构、知识库大版本更新时，这些历史错误会自动出现在回归清单里。三个月下来，评测集自然长成一棵覆盖全面、扎根真实错误经验的“错误数据库”。

6. 架构师必须有的边界感：哪些错误能防，哪些只能防一半

6.1 事实认定类错误：系统只能提示风险，不能替人拍板

司法文书的裁判本质是“基于事实认定和法律适用的价值判断”。有些错误属于客观性错误，比如金额抄错、法条序号写错、名称多字少字，这类错误规则引擎和一致性校验完全可以兜住。但还有一类涉及主观认定的问题——争议焦点该采信哪份证据、合同效力该怎么认定、赔偿比例定多少合理——这些不是“错”，而是“判断”。架构师必须清醒：系统绝不能用生硬规则让模型在这些判断点上给出“唯一答案”，更不能替法官作决定。

我们的做法是让系统在这类内容上“示证但不认定”。模型可以生成一个倾向性的说理初稿，但必须在旁边以注释形式列出支撑材料、相反证据、相关法条，并且明确标注“本部分为建议表述，需要法官确认”。这一设计既发挥了大模型起草说理的效率优势，又把最终裁量权交回给司法人员，也正是目前行业内普遍认同的人机分工边界。

6.2 说理质量：追求要素完备，但不追求模板化

另一个容易被忽略的边界是“质量”和“模板化”之间的平衡。早期版本为了控制错误率，我一度把说理部分也压成高度模板化的填空式生成，结果是错误率确实降下来了，但文书质量下降得离谱——每份判决书的说理都干巴巴像填空，法官不好用、当事人看不懂。后来发现，质量控制的目的不是让文书千篇一律，而是让该对的地方决不出错，该个性化说理的地方保持一定的表达空间。

现在我们的生成策略是“要素强约束，表达弱控制”。法律要件、判项结构、金额日期这些必须严格规范的内容，用骨架和插槽死死锁住；裁判说理、证据评价、争议焦点论述这些需要语言表达的部分，只要求覆盖必备要素，不限制句式表达和论证风格。这样即使模型改动说理写法，规则引擎的校验项也仍然全部通过，错误率不掉，说理质量反而更好。质量控制如果牺牲了文书的可用性，那本身就是一种失败。

6.3 上线策略：先辅助后自动，先简单后复杂

最后聊边界感，必须落到上线策略上。司法AI系统跟普通互联网产品最大的区别是：普通产品上线后效果不好可以随时下架，司法文书一旦生成并流出，后果是难以挽回的。所以我们的上线路径始终坚持两条原则。

第一条原则是“先辅助后自动”。最初版本系统只做“材料要素提取+文书初稿辅助生成”，所有内容一律标注为草稿，必须经法官全文确认后才能使用。在架构上设计一个“确认前不可出系统”的硬开关——草稿状态下的文书无法导出、无法盖章、无法打印，只有复核者在系统内完成确认操作，文书状态才会变为正式。这个硬开关虽然简单，却是在技术上守住“人对结果负责”的关键设计。

第二条原则是“先简单案由后复杂案件”。第一波只挑事实关系清晰、争议焦点标准化的合同纠纷和民间借贷案由，这类案件写作规则明确，模型容易学，规则引擎容易覆盖，上线风险极低。跑通一个案由的完整闭环，积攒足够多的纠错数据和评测样本，再逐步扩展到劳动争议、婚姻家事、交通事故等更复杂的案由。贪多求快，一上来就想全案由覆盖，往往是质量控制体系崩溃的最主要原因。

在我自己这些年的项目经验里，真正让司法AI文书系统从“能用”到“好用”的，恰恰不是某个模型突然变强，而是这些边界和闸门一层层补齐的过程。质量控制没有终点，每一次线上错误都是一个补丁的起点，对抗式评测集是见证，纠错数据是燃料，分层闸门是防线——把这套体系日拱一卒地做扎实，司法AI的质量底线才能真正立住。