做了几年司法领域的AI应用，我最大的体会是：这个领域最难的不是让模型“写出”文书，而是让模型“写对”文书。
前阵子跟一个做法律科技的朋友聊，他说自己团队辛辛苦苦训练了一个模型，生成的起诉状看起来像模像样，结果法务顾问一看，引用了一条已经废止的司法解释，整份文书直接作废。这个案例我太熟悉了。司法AI系统里，文书生成是最能体现“AI替代人力”价值的功能，但也是风险最集中的功能——它输出的是要承担法律后果的正式文本，一个标点符号错位、一个法条引用失效、一个事实描述偏差，都可能直接影响案件的走向。
所以今天想跟各位架构师同行聊聊，在司法AI系统的文书生成模块里，我是怎么做质量控制的。这不是一篇学术论文，就是一个踩坑无数后总结的实操复盘，希望对你正在做的系统有点参考价值。
1. 先说清楚：AI写司法文书，到底会犯哪些错？
要想控制错误，第一步是定义清楚“错误”到底是什么。我跑过很多次评审会，发现大家不在一个频道上——业务方说的“错误”和算法团队理解的“错误”经常不是一回事。如果不把这个概念统一，后面所有的质控设计都是空中楼阁。
1.1 按性质分：逻辑错误、事实错误、形式错误
我把AI生成文书的错误分成三大类，这三类的重要性是递减的，但对系统设计的约束却完全不同。
逻辑错误是最致命的。比如一份判决书的“本院认为”部分，模型可能在说理过程中前后矛盾，前一段认定被告存在过错，后一段又说被告无责。这类错误通常来自模型在长文本生成时的“幻觉”和“立场漂移”，在生成动辄几千字的判决书时尤其常见。
事实错误是次致命的。模型把当事人姓名写错、把诉讼请求金额算错、把证据名称写漏。这类错误通常来自对输入起诉材料的解析偏差，或者是在大段文本生成过程中的信息遗忘。
形式错误是最常见的。比如法律文书的字号、排版不符合规范，法条条号格式错乱，“第X条”应为“第X款”但写成了“第X项”。这类错误不会颠倒黑白，但直接影响文书的严肃性和退回率。
有意思的是，这三类错误的优先级跟大多数人的直觉相反。做产品的人最容易关注“事实错误”，因为一眼就能看出问题；但真正决定系统生死的其实是“逻辑错误”，因为它最难被发现，等发现时往往已经在流程后端了。
1.2 按位置分：出错的可能比你想象的多
如果按错误在生成链路中出现的位置来分，可以分成三层：
- 输入侧错误：原始材料解析阶段，OCR识别错误、文档结构理解偏差、关键信息漏提。这类错误像“源头污染”，后面再怎么清洗都很难完全纠回。
- 生成侧错误：模型生成过程中的遣词造句、逻辑推理、法条匹配偏差。这类错误是大模型本身的“原生缺陷”。
- 输出侧错误：格式化渲染、审批流转、版本管理环节的错误，比如模板套用错、版本不一致、签章位置错误。
这三层错误，架构上要分别治理。不能指望一个“万能校验层”解决所有问题，因为它们的产生机制完全不同，纠错手段也完全不同。输入侧错误要靠“多重抽取+人工确认”，生成侧错误要靠“模型设计+参数约束”，输出侧错误要靠“模板预检+流程卡点”。
1.3 典型错误案例：不看图不知道错得有多离谱
我在测试阶段遇到过几个堪称经典的案例，拿出来给你看看：
- 指代混乱：案件里有两个以上当事人，模型在叙述中先用了“原告”，到了后面变成“被告”，再后面又变成“第三人”，指代链条完全混乱。大模型在长上下文中，对角色扮演的稳定性远没有人想象得那么好。
- 法条幻觉：模型为了“凑说理”，虚构了一条其实不存在的规定。注意，它不是引用错了，是创造了一条规定。我见过把“最高人民法院关于审理网络借贷纠纷案件若干问题的规定”这种根本不存在的东西正儿八经地写进文书的情形。
- 金额计算错误：当事人主张的利息计算截止日期、利率标准、本金基数和判决结果之间，数字前后不一致。模型对数学计算的可靠性，没有ChatGPT演示时那么好看。
- 事实混淆：原告起诉和被告反诉的事实穿插在一起，模型张冠李戴，把被告的事实放到原告名下。
这些案例说明一个核心问题：司法文书生成的质量控制，本质上是对大模型不可靠性的对抗工程。对抗的手段，绝对不是单一策略，而是一整套体系。这是我从一开始就坚持的架构思路。
2. 质量控制体系的总体架构：三层拦截，多层校验
我设计的司法文书生成质量控制体系，核心思路可以总结成一句话：不信任任何单一环节，把监控和校验做成一条链。
2.1 分层设计：从源头到出口全程设卡
整个系统按流水线分成三层防御：
第一层，输入侧质量门禁。在原始材料进入大模型之前，系统先做一轮结构化解析。起诉状、合同证据、身份信息等材料，先经过一个独立的“要素抽取器”，把时间、地点、主体、行为、结果、金额、证据清单等关键要素抽出来，转成一个语义明确的事实要素表。这份要素表就像数据库里的约束规则，后续模型生成的内容，必须基于这张表，而不是面对一整摞散乱文档自由发挥。
为什么要做这一步？因为大模型的原生输入限制和注意力瓶颈决定了，给它一万字的杂糅材料，它只能选择性“看见”一部分。但你给它一张整理好的要素表，它就像拿到了“命题作文”的提纲，跑题和漏点的概率大幅下降。
第二层，生成链路状态机监控。把文书生成过程拆成多个阶段：立案信息生成、事实认定、法律适用、说理推导、判项生成、格式渲染。每个阶段不是独立跑完就完事，而是要通过一个统一的“状态机”来串联。前一个阶段的输出，会成为下一个阶段的“约束条件”。比如事实认定阶段的输出，要在法律适用阶段作为“事实前提”参与推理，而不是说理阶段自己重新编一套事实。
第三层，输出侧多重校验。文书生成完毕不是终点，要通过三道自动校验关卡：规则校验、模型交叉验证、知识库一致性比对。只有三道关卡全部通过，文书才能进入人工复核队列，否则直接打回重写。
这么设计的原因很简单——单点校验永远不可靠。纯粹靠规则，覆盖不了变幻莫测的自然语言；纯粹靠模型，又会陷入“自己检查自己”的死循环；必须让不同机制互相制衡，才能逼近“可信输出”这个目标。
2.2 核心原则：宁可错杀，不可放过
司法AI和普通AI产品最大的区别，在于容错率极低。通用AI客服答错一个问题，用户最多吐槽一句“AI真蠢”；司法AI文书里错一个当事人名字，轻则被退回补正，重则引发程序性错误，甚至可能导致案件被再审。
所以我的质量控制体系把原则定得很死：宁可错杀，不可放过。所有自动校验环节，一律采用“疑错从有”的标准。只要某个句子找不到对应的事实支撑，或者某条法条找不到知识库原文比对，就标记为“存疑”，不允许进入定稿流程。这种策略会带来一定比例的误杀（后面评测部分细讲），但误杀的成本远低于漏网之鱼的成本。
2.3 关于“人工复核环节”在什么位置
需要特别说一下，人工复核环节在整个体系里的位置，不是“可选”，而是“必选”，但位置要放对。我见过很多设计，把人工复核放在最后一道关口，让人工从头到尾通读全文——这是最无效的复核方式，因为法官或律师根本没有精力逐字读一份动辄几千字的AI文书，而且人在疲劳状态下注意力衰减，关键错误反而会被无视。
我的设计是把人工复核拆到几个关键生成阶段之间。比如事实要素抽取后，先由办案人员人工核对“事实要素表”是否与卷宗一致；确认无误后，再允许模型继续生成正文；正文生成后，人工只复核“高亮存疑区”，而不是通读全文。
这样的好处是，人工的工作量从“通读几千字”降到“核对几个要素”“审阅几个高亮点”，效率大幅提升，质量也更有保障。这边跑半年下来，业务侧人员的满意度提升非常大，核心就是把人力从“低价值通读”里解放出来，放到“高价值把关”上。
3. 核心细节解析与实操要点
光有框架还不够，真正拉开质量差距的是细节。这节我挑几个实操中反复验证过的关键点，分享给各位。
3.1 法条引用校验的实现逻辑
法条引用错误，是司法AI最容易挨骂的地方。我见过有系统引用一条与案件毫无关系的法条，结果文书被对方律师挑出来，当场给法官留下极坏的印象。
我的实现方案是这样拆的：
第一步：法条规范化解析。在知识库里，每一条法条都按“法律名称→章→节→条→款→项”的层级，拆成结构化的“法条树”。生成阶段的模型输出，必须通过一个“法条探测器”，把文中所有引用法条的地方，先提取成结构化表达式。比如“根据《中华人民共和国合同法》第九十四条第二款”，会被解析成“法律名称=合同法，条号=94，款号=2”。
第二步：知识库强校验。解析出来的结构化法条，直接与法律知识库中的当前有效版本比对。这里有几个坑要注意：
- 时效性：必须校验该法条在当前时间点是否有效，有没有被废止或修改。这类校验不能靠人工维护，要靠一个法条变更监控服务，定期同步法律法规数据库。
- 有效性：必须校验条文序号是否真实存在。比如《某法》总共只有八十条，模型引用了“第九十九条”，直接拦截。
- 适配性：必须校验该法条是否可能适用于本案的事实类型。比如一个纯粹的合同纠纷，模型引用了刑法条文，哪怕条文真实存在，也要高亮存疑。
第三步：引用上下文一致性比对。这条容易被忽略，但特别重要——模型引用了法条A，但对法条A的描述性概括，必须从知识库里提取原文摘要，与模型生成的说理内容做语义相似度对比。如果模型说“该条规定了不可抗力免责”，而知识库里该条根本没有这个意思，说明模型在曲解法条，要标记存疑。
这一套下来，法条引用错误基本被卡死在签发前。我从上线以来，法条引用错误率从千分级降到了接近零。
3.2 事实要素抽取与指代消解
前面说过，事实要素表是生成的前提。这表的构建质量，直接决定生成质量。我踩过的最大坑，是多主体场景下的指代消解。
案件里经常有原告、被告、第三人、代理人等多方角色，模型生成时很容易搞混。我的做法是，在事实要素表阶段，就强制建立“角色-实体”绑定关系。每个角色绑定一个唯一标识，比如“P1=原告张某某，D1=被告李某某，T1=第三人王某某”。模型生成的正文里，所有提及当事人的地方，底层都用这个标识来做约束，不允许直接生成模糊的人称代词。
实现上，我用了两阶段策略。第一阶段是候选生成：让模型在生成每个句子时，先输出“主实体编号”作为该句的“主角”。第二阶段是指代映射：如果句子里的“原告”想指代一个改了名的公司，或者指代前后换了表述方式，系统就根据实体链做对齐。这听着抽象，跑起来效果很显著——指代错误率从十几个点降到了一两个点以内。
3.3 长文本生成的“漂移”控制
判决书这类文书动辄两三千字以上，大模型在长文本生成时，一个老大难问题是“语义漂移”——前文认定的结论，后文不知不觉就偏离了。
我的对策是用分段约束生成替代端到端LongText生成。具体来说，把整份文书的生成拆成若干段，每段都给一个“片段大纲”，大纲里明确写清楚：这一段要支持的结论是什么、依赖的前文事实编号是什么、需要引用的法条是哪几条。
模型生成每一段时，都强制“基于给定的结论和理由来展开”，而不是自由开放地写。这样虽然损失了一些“文采上的连贯性”，但换来的逻辑一致性高出了几个量级。对司法文书来说，逻辑价值远大于文采价值。
把分段约束生成做扎实之后，原来的前段说“被告有责”后段说“被告无责”这类的漂移，基本上就成了历史。
3.4 知识库的隔离与版本管理
司法文书生成系统的知识库，不能简单地把所有法律法规堆进一个向量数据库就完事。我按“用途”和“来源”做了四层隔离：
- 原始法规库：收录有效的法律法规原文，这一层是纯官方文本，不掺杂任何解释。
- 规范释义库：收录权威法学著作、司法解释、指导案例中的规范化说法，这部分用于模型理解，但不直接作为引用来源。
- 判例摘要库：从公开裁判文书中脱敏后提炼的裁判规则摘要，用于模型学习“类似案件怎么判”的倾向。
- 文书模板库：各类法律文书的标准结构和必备要件清单，用于控制文书的格式规范，比如起诉状应该有哪些部分、判决书必须包含哪些要件。
四层库分开存、分开检索、分开打标签。模型生成时，若引用“法规库”的原文，必须与库里完全比对；若引用“释义库”的内容，必须标注“源自推荐阅读材料，非原条文”。这样哪怕模型理解上有偏差，至少不会在正式引用环节把“注意”当“法条”。
版本管理上也踩过坑。曾经出现过一种情况：同一份文书，生成时引用的法条与复核时法条已经失效了。所以我在系统里引入“知识库版本快照”——每次生成时，锁定当时的知识库版本，复核时不是拿最新版跟你比，而是拿“生成时的快照”跟你比。你要是拿最新版来比，永远追不上法规更新的节奏，还容易误判生成质量。
4. 实操过程与核心环节实现
这部分我按一个完整的项目落地流程来走，各位可以当成一份操作手册来看。假设你现在要从零搭建一个司法文书生成系统，这四步是你的必经之路。
4.1 第一步：先建评测集，再谈调模型
很多人一上来就调模型参数，大忌。司法领域的AI不是靠堆数据的，而是靠评测指标的精准定义。我强烈建议，在写第一行生成代码之前，先建评测集。
评测集分成两类：
- 回归评测集：从已生效的裁判文书中，脱敏后人工摘选出200-500份高质量样例，覆盖常见案由。每一份都标注“标准答案版文书”。这个集合的用途是，每次迭代模型或调整规则后，都跑一遍，看有没有把正确的东西改错（防止回归）。
- 对抗评测集：人工构造一批容易诱发模型错误的“坏案例”，比如多主体案件、金额极其复杂的金融贷款案、证据含有大量矛盾陈述的案件等。这些案例专门用来打击模型幻觉和逻辑混乱。
我管“回归评测集”叫守门员，管“对抗评测集”叫照妖镜。两者缺一不可。只有回归集，你会被照妖镜打回原形；只有对抗集，你无法确认真实场景的稳定性。
评测集建好之后，定义三个关键指标：
- 文书可用率：一份文书直接达到签发标准、不需要人工重写的比例。目标要达到90%以上。
- 存疑检出率：系统自动标记出的可疑区域，是否覆盖了真实存在的所有错误区域。理想状态是100%覆盖，即所有可能的错误点都被高亮。
- 误杀率：系统标记存疑但其实正确的比例。这个指标直接影响业务方的信任度，太高了大家会骂“这个系统老是不靠谱”。
这三个指标要进行权衡。把误杀率压低到最小，可能放过了漏网之鱼；把存疑检出率拉到100%，误杀率又会冲高。我的实践目标是：存疑检出率100%，误杀率控制在20%以内。也就是说，人工复核100个高亮点，里面80个确实是问题，20个是系统过度敏感。这个比例业务方可以接受，因为他们真正怕的是“该查的没查”。
4.2 第二步：生成链路的工程化落地
链路我前面讲了状态机，这里讲具体实现。
阶段一，案件要素解析。接入OCR和文档解析服务，将起诉状、证据材料、身份信息等转换为结构化文本，再经过要素抽取器抽取为事实要素表。
阶段二，法律适用预判。模型拿到结构化的案件要素表后，先做一次“案由类型分类+法律适用候选集生成”。这一步决定了后面生成时“围绕哪些法条来写”。
阶段三，正文分段生成。按文书结构（如判决书的“当事人信息—法院查明—本院认为—判决结果”结构），逐段生成。
阶段四，判决辅助校验。针对“判决结果”部分，系统额外挂一个“计算器模块”，专门复核金额、期间、利息等数字逻辑。这部分不要靠模型心算，要用规则化的计算引擎。
阶段五，全文汇聚与格式化。各段生成完毕后，汇聚成完整文书，做排版和格式渲染，同时生成一份“质量报告”，列出所有存疑区。
我用一个状态机把这些阶段串起来：
解析中 -> 解析完成 -> 法条匹配中 -> 法条匹配完成 -> 生成中 -> 生成完成 -> 校验中 -> 校验通过 | | | v | 存疑，返回重写 v 复审中 -> 人工复核标记 -> 定稿签发每一个状态迁移，都要记录操作日志、模型版本、参数快照，以及迁移原因。这样在回溯任意一份文书时，能完整还原生成与审核的全过程。这是审计追踪的硬要求，也是质量分析的数据基础。
4.3 第三步：人工复核工作台的交互设计
人工复核不只是一个“给业务方看的界面”，它本身就是一个质控工具。我的设计原则是：让复核人员不用通读全文，只做“警察验证”。
工作台的核心功能有三块：
- 问题高亮区：把系统标记的所有存疑点，按严重程度排列在一个“待复核列表”里，每一条都要标注可信度。复核人员只需逐条确认“是”或“否”，判定为“是”的点会被系统自动记录并进入修正队列。
- 证据溯源区：每个生成结论的旁边，都有一块“证据面板”，展示该结论依赖的事实要素编号、检索到的法条原文、相关的判例摘要。复核人员点一下，就能看到该结论的“推理链路”，而不是看AI“给出一个结果然后自己去猜为什么”。
- 一键修订区：复核人员确认错误后，可以直接在工作台里改写。系统记录修改前后的差异，这些差异反馈会进入数据闭环，作为后续模型微调和规则迭代的训练素材。
这套设计上线后，人工复核的平均耗时从原来的每份文书30分钟，下降到约5-8分钟。最直接的价值是，业务方不再觉得“AI是来添乱的”，而是真的觉得“AI帮我把好查的都查完了，我只管最关键的”。
4.4 第四步：知识库建设的坑与细节
知识库的构建，不是跑个爬虫抓一轮法规就行。我遇到并解决过的几个坑，值得单列出来：
坑一：只存法规原文，不存“条款间关系”。很多知识库只做法规条文入库，但条文之间有大量的相互引用、转引、适用关系。比如“本法第X条规定的处理措施，依照某规定执行”。如果不建模这种关系链，模型生成时会断章取义。我的做法是额外建一个“条款关系图谱”，每个条款的元数据里记录它引用的其他条款编号和关系类型。
坑二：不同位阶的法规混在一起，不分优先级。法律、行政法规、地方性法规、司法解释，效力层级不同，适用优先级完全不同。模型如果拿地方性法规去解释上位法概念，那写出来的质量会很差。我在知识库里为每条法规打上“效力位阶”标签，生成时按位阶做过滤和排序。
坑三：版本过期无人通知。法规更新是个常态事件。系统上线小半年后，某天突然发现裁判文书网的判例开始大量引用新法，但我们的知识库还在用旧版。解决办法是接一个“法规变更订阅服务”，定时比对法律数据库，发生变更时自动更新知识库并生成变更日志，这个变更日志会回写到所有引用了旧版法条的未定稿文书，提示复核人员重新审核。
5. 评测、红队测试与迭代闭环
质量控制不是一个上线就完事的静态工程，它是一个持续博弈的动态过程。这章节我将分享一套“自我攻击”的评测机制，也算是对前文评测集设计的延伸。
5.1 红队测试：主动构造错误样本
“红队测试”是从安全领域引入的做法，在司法AI里特别适用。我们内部有一个长期运行的“攻击小组”，职责是专门设计能骗过系统的输入案例。
红队测试的重点攻击面有：
- 事实矛盾：卷宗材料本身前后矛盾，系统是否有能力识别并阻断？
- 多主体搅浑：设计多个当事人、多个公司实体之间股权穿透、代持等复杂关系，看系统会不会把主体搞混。
- 法条擦边：找一个行为同时可能触犯多个法条，看系统在法条选择上会不会过度依赖某一条，而漏了更适配的。
- 金额陷阱：故意把本金、利率、天数等要素设计成容易让模型直接算错的形式，比如“按月计息，不满一个月的按日计息”，看计算引擎能否正确处理。
红队测试的结果直接反馈到两个地方，一个是模型微调的样本池，另一个是规则引擎的规则集。一旦红队发现了一个新漏洞，就立即补规则，并且把漏洞样本加入对抗评测集，防止回归。
5.2 置信度度量与阈值控制
所有校验环节，最终都要量化成一个“置信度分数”，供后端决策。我给每个校验模块设置独立阈值：
- 法条引用校验：低于95分直接打回；
- 语义相似度校验（判断生成内容是否基于事实要素）：低于85分打回；
- 金额计算校验：任何一位数字不匹配直接打回，没有模糊区间；
- 知识库关联校验：低于90分标记为待人工复核。
这些阈值不是拍脑袋定的，而是从历史评测集里跑出来的。我用训练集做了一轮网格搜索，选择在“存疑检出率不低于95%”的前提下，尽量降“误杀率”的最优阈值组合。这里给个建议：阈值一旦定好，要写进配置中心，而不是写死在代码里。因为你上线之后会发现，不同地区、不同案由的案件，对“宽松”和“严格”的需求不一样，可配置比造轮子重要。
5.3 数据闭环：每次复核都是一次训练
系统上线后，最重要的迭代素材来自人工复核反馈。每一条被人工修订的文书，都会生成一条“差异记录”，记录了模型原本的输出和人工修改后的版本。
这些差异记录自动聚合成几类特征：
- 哪些高频错误点，模型一直没有学会？
- 哪些规则过于严苛，经常误伤正确内容？
- 哪些生成模板存在结构性缺陷？
每个季度，我用差异记录训练一轮模型微调，并且更新规则库。半年下来，存疑检出率稳定在98%以上，误杀率从最初的近40%压到了20%以内，可用率也从70%出头提到了接近90%。
这里要提醒一下：数据闭环里最怕“脏数据”。如果复核人员自己的工作做得粗糙，误标了一堆本来正确的点为“错误”，模型会被越训越偏。所以我要求复核工作台里，每个“错误确认”操作，必须至少关联一个“具体错误类型”，不能简单点“是”了事。这样后续训练的数据质量就有保障。
6. 常见问题与排查技巧实录
最后这部分，我把踩过的一系列坑整理成速查表。这些点不是教科书上能抄到的，全是真金白银的教训。遇到类似问题，直接对着查就行。
6.1 五类高频问题的定位与处置
问题一：生成结果“看起来都对，一深究全错”。
排查思路：先看“事实要素表”构建对不对。通常这种问题，八成是要素抽取阶段丢信息了。比如一个金融借款案，利息计算标准没抽出来，模型就只能自由发挥，产出的内容全是“套路话”，表面通顺，深究不对。处置方案：优先优化要素抽取器的字段覆盖率，把不平衡的字段加权重。
问题二：同一个案件，生成两份文书，内容打架。
排查思路：先查是不是知识库版本不一致。如果两次生成发生在知识库更新前后，很可能一次用了旧法条，一次用了新法条。我的经验是强制生成时打“知识库快照编号”，两份文书各留各的版本号，问题就透明化了。
问题三：模型“过度自信”，生成结果里没有存疑点，但人工复核一查一堆错。
排查思路：这就是置信度度量没做好。解决办法不是去调模型，而是把校验规则的阈值调严。如果连“该法条是否适用于本案”这种高置信度判断，模型都给出了低置信度的答案，说明校验模块的“输出校准”做坏了，建议改用Softmax温度缩放或独立训练一个校验分类器。
问题四：人工复核效率还是低，感觉没省多少事。
排查思路：先看复核工作台是否做到了“问题高亮+证据溯源+一键修订”三件套。如果一个复核人员还要从裁判文书里自己翻找事实依据，那效率必然低。另一个坑是“存疑点排布太分散”，复核人员来回跳转，心智负担巨大。按严重程度和文书结构排序，而不是按生成顺序展示，能让复核体验好很多。
问题五：系统上线后，外部反馈回来了一个“低级错误”。
排查思路：一级响应是马上走“错误重放”流程。用保留的模型版本、知识库快照、输入数据，重新生成一遍，定位错误到底在哪一环产生。是输入解析、生成、校验还是人工复核环节漏掉的？定位后，所有同类审核中的文书立即做一次“回溯复检”。
6.2 我的几点独家经验
最后分享几条压箱底的经验，这几个点是我花了很长时间，吃了不少亏才悟出来的。
第一，不要让生成模型自己校验自己。大模型在判断“自己错没错”这件事上，天然有盲区——它检查自己的输出时，使用的判断逻辑跟生成逻辑是同构的，也就是说，它犯的错在它自己眼里是“合理的”。所以我的校验模块，一律使用完全独立的一套规则引擎和另一个轻量模型，生成和校验在模型层面就是隔离的。
第二，尽量晚定型，尽量早拦截。“晚定型”意思是，在条件允许的情况下，不要在模型层面把结果定死。比如金额计算，生成模型给出计算公式和参数，最终结果让规则计算引擎去算，模型只负责文字表述，这样数字部分的可控性高很多。“早拦截”就是前面说的，把错误发现机制前移到输入侧，而不是等生成完了再纠错。
第三，没有完美的AI，只有防得住架构。做这个领域的人，有时会陷入“算法焦虑”，总觉得模型不够强、不够聪明。但实际上，业务方并不需要一个“什么都能判断”的超级AI，他们需要的是一个“知道自己在什么情况下会犯错，且能抵御这些错误”的可靠系统。这种可靠，更多地取决于你的工程架构，而不是模型的参数规模。我见过用参数规模较小的模型、但因为工程控制做得到位，整体质量比大模型裸奔好得多的案例——质量控制的价值，就在这一行字里。
如果看完这篇，你正准备动手做类似的系统，我的建议是先别急着写代码。找三五份真实的已生效裁判文书，先在脑子里走一遍“如果让AI生成这份文书，会发生什么错误”，把错误清单写下来，再倒推你的架构设计。这个准备工作，比我后面讲的任何技术细节都重要。
