企业官网建设流程全解析

做了几年司法领域的AI应用架构，有个感受特别深：文书生成这类任务，上线前大家最担心的是模型不够聪明，上线后挨骂最多的反而是它太“聪明”——会一本正经地编出一个不存在的案号、引用一段已经废止的法条、把当事人身份信息写错。这种错误跟“生成速度快不快”“语句通不通顺”没关系，它属于质量问题，会直接触碰司法文书的严肃性。今天想聊的，就是我们架构师在设计和落地司法AI文书生成系统时，如何从架构层面把错误率压下去、把质量兜住。

这篇内容不是某个现成产品的使用教程，而是我在项目里实际验证过的工程思路：如何通过分层校验、结构化约束、人机协同、全链路追溯，把大模型的不确定性锁在笼子里。适合正在做法律科技、政务文书、金融合规报告这类“严肃文本生成”方向的朋友参考。你可以直接拿去对照自己的系统设计，逐条检查哪些防线还没建。

1. 先搞清楚危险都在哪：文书生成的典型错误分类

大多数架构设计失败，不是方案不够高级，而是“没定义清楚错误长什么样”就开始动手。我习惯把司法文书生成的错误分成三类：幻觉类、规范类、一致性类。这三类错误性质完全不同，对应的防御手段也完全不同。

1.1 幻觉类错误：模型“一本正经地胡说八道”

幻觉是大模型天生的毛病。在司法场景里，它表现得非常具体：编造一个看起来合法的案号、给当事人分配一个现实中不存在的地址、引用一段根本不在法条库里的条文、把一个侵权事实写成违约事实。这类错误的可怕之处在于“语法完全正确、语气非常专业”，普通人根本看不出来。

我做过一个内部统计：在没有约束的纯自由生成模式下，500份测试文书里，约有12%包含至少一处幻觉类错误，其中案号和法条引用占了大头。这个比例在演示环境里大家还能接受，一旦上到真实业务线，任何一份文书出错都可能引发严重后果。所以架构设计的第一原则就是：永远不要让模型直接从空气里生成关键事实字段。

1.2 规范类错误：格式、称谓、日期、数字的“小问题”

这类错误看起来很不起眼，但在司法文书里非常致命。比如法院名称的规范写法不对、审判员和法官助理称谓混淆、日期格式不统一（“二〇二四年”和“2024年”混用）、金额的中文大写数字和小写数字对不上。裁判文书有严格的制作规范，格式乱、不统一，直接影响公文的严肃性和权威性。

规范类错误用大模型本身很难根除，因为模型是按概率生成token的，它不理解“这个位置必须长成什么样”。格式问题恰恰是确定性最高的部分——应该用模板和规则去卡，而不是靠模型“自觉”。

1.3 一致性类错误：前后矛盾、与事实脱节

还有一种错误最隐蔽：文书前后表述不一致。比如事实部分写的是原告主张赔偿5万元，判项部分却写成了5千元；证据列表里有一份鉴定意见，正文的说理部分却完全没有引用；裁判依据引用的是新修订的某部法律，但说理时还在用已经废止的旧条文表述。

这种错误往往不是模型单次生成造成的，而是“要素抽取-生成-格式化”链条中某个环节丢失了信息。架构角度来说，本质上是输入和数据流设计出了问题，得靠结构化字段的强约束和前后一致性校验来解决。

我用一张表总结这三类错误的特征。后面所有架构设计都围绕这张表展开：

2. 架构设计的总体思路：别把宝全押在模型上

很多团队做文书生成，一开始的思路就是“选一个大模型，把案件事实丢进去，让它写”。结果通常是：demo惊艳、试点拉胯、上线翻车。原因很简单——大模型本质是一个概率系统，它可以在你有上下文约束时表现很好，但只要你放松约束，它就自由发挥。

2.1 质量不应该是模型单点责任

我做这套系统时，给自己定了一个很朴素的原则：模型负责“写得好不好”，架构负责“写得对不对”。

“对不对”指的是事实要素准确、引用准确、格式规范、逻辑前后一致。这些不应该是模型的义务，而是整个系统通过约束机制强制的。换句话说，架构师要做的不是找一个大到足够聪明的模型，而是设计一套让“再普通的模型也犯不了大错”的防御体系。这个思路我在后续多个项目中反复验证过，比单纯追新模型版本要稳定得多。

2.2 分层防线：四道关卡

我把质量保障拆成四道关卡，每道关卡只解决一类问题：

1. 输入层：从案件材料里稳定抽取结构化要素，建好“事实底座”。
2. 生成层：用模板加检索增强约束模型的输出空间，把自由写作限制在“规范骨架”里。
3. 校验层：用规则引擎和知识库把输出的关键字段、法条、格式全部扫一遍。
4. 复核层：用置信度分级把低置信度内容送回给人类复核，同时记录全链路日志。

这个思路和软件工程里的防御式编程完全一致：每一层都假设上一层会出错，并做好兜底。这样即使某个环节出了问题，最终到用户手里的文书也还是可控的。

2.3 人机协同：人工复核不是机械操作

有一个必须想清楚的点：司法文书的特殊性决定了人工复核不可能被完全替代。但人工复核不等于“让法官在AI生成的草稿上从头改一遍”。好的做法是让系统把低置信度的地方用高亮标出来，把可疑的案号、引用、金额单独拉出来让复核人确认。人的精力是稀缺资源，系统应该把人的注意力引导到最可能有错的地方。

同样，复核人的确认结果要回灌到系统中，形成闭环优化。这一点在架构设计里容易被忽略——没有反馈闭环，系统只是“看起来在用AI”，实际上质量一直没有提升。

3. 核心模块的具体实现：每一层的工程细节

这一部分我尽量按实际落地时踩过的坑来讲。每层具体怎么做，有哪些参数、哪些取舍，都会说明背后的原因。

3.1 输入侧：要素抽取与结构化

文书生成的前提是“要素齐整”。我通常先让系统从起诉状、判决书原文、证据清单里抽取固定字段，定义成一个JSON结构，例如：

{ "case_id": "（2024）某法院民初1234号", "court_name": "某市中级人民法院", "plaintiff": {"name": "张三", "type": "自然人", "address": "某省某市某路1号"}, "defendant": {"name": "某科技公司", "type": "法人", "address": "某省某市某园区"}, "claims": ["判令被告支付货款人民币500万元", "判令被告承担本案诉讼费用"], "evidence": [{"name": "采购合同", "type": "书证", "key_points": "双方约定付款期限"}], "legal_basis": [{"statute_id": "CL001234", "name": "合同编相关条文"}], "hearing_date": "2024-06-18" }

要素抽取有两种主流做法：一种是传统的序列标注模型，速度稳定，但遇到长文本和多义表达时容易漏；另一种是直接用大模型加结构化输出约束抽取。我更推荐后者，因为输出协议能把结果限制成合法JSON，准确率整体更高。

抽取完成之后，需要做一次“字段完整性校验”——必填字段缺失时，直接返回人工补全，而不是带着缺失数据往下走。这一步很关键：宁可让流程慢一点，也不能让文书在关键字段缺失的情况下生成。我在实际项目里遇到过一个典型问题：被告是法人时，统一社会信用代码经常缺失，如果不卡住，后续生成的文书就会出现“被告基本信息不完整”的低级错误，复核阶段还要全部退回重来，反而更慢。

3.2 生成侧：模板约束加检索增强

司法文书的正文虽然看起来自由，但它有很强的结构约定。比如判决书正文一般包括：当事人信息、诉辩意见、经审理查明的事实、本院认为（说理）、判决主文、审判人员署名、日期等。这些部分是固定的骨架，不该让模型自由发挥。

我的做法是：把文书模板做成“带变量的结构化模板”，变量由要素抽取阶段的结果回填；只有“本院认为”这种需要语义推理的段落，才交给大模型生成。这样既保证了文书格式规范，又保留了AI在说理上的能力。

说理部分为了防止引用错误法条，我把它做成检索增强流程：把现行有效的法律条文、司法解释切段后放入向量库，生成时先检索相关法条，再把命中的法条原文拼进上下文，同时要求模型只能引用检索结果中的法条，并且输出时附上法条ID。后续校验阶段会拿着这个ID去法条库核对，保证引用闭环。

这里有一个容易忽略的坑：如果检索时不过滤法条的时效性，很容易把已经废止的条文也检索出来。所以向量库最好支持按生效日期、废止日期做条件过滤。比如生成一份2024年的判决书，检索到的法条必须是2024年时仍然有效的版本。时间过滤看似小细节，实际能拦下一大批“引用过时法条”的错误。

3.3 校验侧：规则引擎设计

规则引擎是质量保障的核心。不要一听“规则引擎”就觉得技术含量低，恰恰因为规则是确定的，它才能对抗模型的不确定性。我把校验拆成多个独立的校验器，每一个只做一件事，然后串成管道。比较重要的校验器有这么几类：

• 案号校验：正则匹配“（20XX）某法院民初XXXX号”等格式，同时与库里已有案号比对，防止编造。
• 日期校验：所有日期必须转成统一格式（YYYY-MM-DD），并检查逻辑顺序，比如判决日期必须晚于立案日期。
• 金额校验：提取所有金额小写数字和中文大写数字，做双向转换比对，防止出现“500万元”和“伍佰圆”这种对不上的情况。
• 法条校验：根据法条ID查库，确认该法条在生成时点有效，且不在废止列表中。
• 人称一致性校验：同一当事人在全文中的称谓必须统一，比如“原告”不能时而变成“申请人”，免得读者一头雾水。

规则引擎能做到什么程度？我在一个模拟的法院智能文书项目里做过统计：单纯靠规则引擎，能够拦截掉大约70%的规范类和幻觉类错误。剩下的30%才需要靠更重的手段去兜底。所以规则引擎的性价比极高，架构上优先做。

3.4 输出侧：置信度分级与人工复核

输出侧最容易被忽略。很多系统生成完就结束了，其实输出侧有两个关键功能。

一是置信度标记。我通常让生成模块在关键字段旁额外输出一个confidence字段。怎么算？简单方式是这样：要素回填部分置信度几乎为1；法条引用部分如果由检索命中，置信度可以设为0.95；自由生成的说理部分，则由一个独立的“语义一致性检查模型”打分。最终根据置信度把文书分成三档：高置信度直接出稿、中置信度进入快速复核、低置信度必须退回人工重新撰写。这个档位划分直接决定了人力投入的多少。

二是一致性校验模型。我实际用的是双模型投票：对低置信度的段落，用两个不同架构的模型分别生成，然后做相似度和要点对齐比对，差异过大的段落自动标记为“存疑”。双模型虽然成本翻倍，但只在低置信度段落上启用，整体成本可控。

注意：自动修正和人工复核要分开。能确定是错的（比如日期格式不一致）可以自动修正；不能确定的（比如案号可疑）必须交给人工确认。自动修正做得太激进，会让系统替人做了不该做的决定，这一点后面还会展开说。

4. 实操落地：从一个简单流程看完整链路

理论知识讲完了，我按实际项目落地的方式，把整个流程串一遍，方便你直接照搬。

4.1 端到端流程

流程大概是这样的：

1. 材料上传：用户上传起诉状PDF、证据扫描件，系统先做OCR和文本抽取。
2. 要素抽取：大模型将文本转成结构化JSON，缺失字段直接标红。
3. 模板匹配：根据案由（合同纠纷、侵权、劳动争议等）自动匹配文书模板。
4. 骨架回填：把要素写入模板，生成“骨架稿”。
5. 说理生成：对“本院认为”部分，先做法条检索，再生成说理段。
6. 规则校验：全字段扫描，所有错误、存疑点统一汇总。
7. 自动修正：对能确定的错误（比如格式问题）自动修正；对不确定的（比如案号可疑）标记人工复核。
8. 人工复核：复核人打开界面，只看高亮标记的存疑点，确认或修改后定稿。
9. 日志入库：把每次生成用的要素、模板版本、模型版本、提示词版本、校验结果全部写入审计日志。

关键在于第6、7步：校验和修正要能区分“确定错误”和“疑似错误”，并且分开处理。确定错误直接改，疑似错误必须让人看，不要自动改。这个原则我吃了好几次亏才总结出来。

4.2 关键参数与工程细节

几个工程细节值得单独说。

第一，固定随机种子。在配置中心里设置seed，同一个模板加同一份要素，生成结果必须可重复。如果两次生成内容完全不一样，说明系统不稳定，这个问题要在上线前暴露出来，而不是上线后被投诉后才发现。

第二，结构化输出协议。无论用哪个模型底座，生成侧都强制走结构化输出协议，确保输出是合法JSON。这一步不要只靠提示词，要配合输出约束能力，不然模型一旦多输出一个逗号，下游解析就会崩。

第三，模板版本化。文书模板不是一次性写好就完的，法院规范会调整。我把模板做成版本化配置，每次生成都记录使用的模板版本，这样后续排查问题时能知道“这一版文书是用哪版模板生成的”。

第四，法条库版本化。法条的更新对系统的正确性影响极大。我把法条库的快照也做成版本化，保证文书的生成时间点“看到”的法条版本是确定的、可追溯的。这样即使后来法条废改了，也能还原当时的生成逻辑。

第五，幂等生成。对同一个案件多次生成，如果只是求一个“最合理的稿子”，可以保留第一次的结果。但如果要做“生成-校验-修正”闭环，那每次修正后的重生成都必须基于修正前的结果，避免模型在修正过程中引入新错误。

5. 常见问题与排查技巧实录

把我在项目里真实遇到、也最容易被新手忽略的几类问题梳理一下。

5.1 模型总是编案号怎么办

案号幻觉是司法文书生成里最典型的问题。我的处理方式是“案号不从生成器里来，从数据库里来”：案号要么来自上游案件管理系统，要么由规则引擎根据规则生成，绝不交给模型自由输出。如果模型输出的正文里出现了案号，必须正则提取后与数据库比对，比对不上的直接标记为存疑。这是在架构上就把它卡死，而不是靠提示词“请别编造案号”。

5.2 法条引用旧版本

法条引用错版本的问题，根源在于模型知识的时效性滞后。模型训练完之后，知识的“截止时间”就固定了，后续法条更新它不知道。我们的方案是强制检索增强：生成说理段之前，必须先从当前有效法条库检索，并且把检索命中结果拼进上下文。同时在校验阶段用法条库元数据里的生效日期和废止日期做过滤。只要有一环不满足，这整段说理就会被打回重写。

5.3 输入太长导致关键信息丢失

大模型上下文窗口再大，处理几百页的案卷材料也扛不住。我遇到的实际问题是：长文档被截断后，当事人信息或证据信息会丢，但生成的文书依然很流畅，完全看不出缺失。这种“流畅的错”最难防。

解决办法是“先摘要、后填充”：先把原始材料按段落做摘要，把摘要压缩成要素字段；生成时只使用要素字段，不直接灌原始材料。一句话：把上下文从“原材料”变成“精炼后的结构化数据”，信息密度高很多，模型也不容易丢信息。

5.4 生成结果不稳定、同一案件每次出来不一样

先排查是不是随机参数没固定，常见是temperature和seed没设置。其次是模板变量取值不规范，比如上游传过来的日期格式一会是“2024年6月18日”一会是“2024/06/18”，模型就会跟着乱。解决方法是上游数据入库前强制统一格式，下游生成时只认一种格式。别小看这种数据规范问题，它引起的“不稳定”占了相当大比例。

5.5 校验器误报太多，复核人烦了

规则引擎如果设置得太严格，会把合法文书也拦下来，导致复核人大量处理无效告警，整体效率反而下降。这个问题的核心是“校验器的精准率要优先于召回率”。我一般会给校验器分等级：红色告警必须人工看，黄色告警仅做提示。经过一段时间的反馈数据，再逐步调整各类规则的比例。

下面用一张表把上面的排查技巧汇总一下，可以直接当速查表用：

6. 工具与模型选型的一些经验

最后聊几句选型。文书生成方向，底层模型我倾向于不追求“最强”，而是追求“可控”。所谓可控，指的是：

• 支持结构化输出约束，能在生成阶段就限定JSON格式；
• 有良好的指令遵循能力，能在几个示例的引导下不跑偏；
• 部署形态灵活，能在私有化环境跑。司法数据不能出域是硬约束，所以我对纯云服务天然排斥。

检索增强部分，我用的向量库要能支持过滤条件，比如按法条生效日期过滤，不然检索出来的法条可能是失效的。这一点很关键，很多团队栽在“检索出了法条，但没过滤版本”。

模型评估上，我建议自建一个“司法文书评测集”，不要只靠通用基准测试。评测集里要有意识地加入“错误诱导”样本，比如故意在材料里放一些相似案由、容易混淆的法律概念，看模型会不会被带偏。选型时拿评测集跑一遍，效果一目了然。

我自己的经验是：宁可选择“约束能力强但说理稍弱”的模型，也不选“文章写得好但经常不听指令”的模型。因为在文书生成这个场景，说理可以靠检索材料、引用权威文书来增强，但“不听指令”导致的错误是架构难以兜底的。

写到这里，我再做一次偏个人视角的收尾：做司法AI文书生成，架构师一定不要沉浸在“模型能力论”里。模型是资源，架构才是质量的上限。我一直用的方法是把质量控制拆成一道道可独立测试的闸门，每一道闸门都要有明确的输入输出和通过标准。宁可前期多花时间在规则引擎、模板化、数据标准化这些“不性感”的工作上，也不要在模型调优上孤注一掷。

如果你也在做严肃文本生成类系统，先把“正确”的边界画清楚，再把“智能”放进去，这个顺序千万不能反。最后分享一个小技巧：上线初期，每次生成后可以加一道“复核人评价”环节，让复核人给每个存疑点打“命中/误报”标签，这些数据攒下来，就是优化规则引擎和模型提示词最宝贵的弹药。