法律AI全流程立案系统设计与实现：从材料识别到文书生成

1. 为什么要做AI线上全流程立案传统线上立案的三大痛点先说个背景。我们团队花了整整三个月时间把吾律AI线上全流程立案服务从立项推到了正式上线。这不是一个简单的把表单搬到网页上的项目。立项之前团队成员里有做过六年诉讼律师的同事也有专门做法务系统的技术负责人大家刚坐在一起时聊的第一句话就是现在网上立案到底难在哪答案比想象中集中。归纳下来是三座大山。1.1 材料之乱起诉状总差那么几行有过线上立案经验的朋友应该懂这种感觉。你以为自己把材料都准备好了结果系统弹出来起诉状缺少诉讼请求证据材料未按顺序排列原告身份信息不完整然后你回到本地改文件、重新盖章、重新扫描、再次上传。最难受的是这些问题往往不是在提交前被发现的而是提交后审核环节退回来时才告诉你。为什么会这样因为每家法院的立案系统对材料格式的要求在细节上并不一样。有的要求PDF有的要求JPG有的要求起诉状里必须写明确切案由有的只要求事实与理由部分落到某一级案由即可。当事人或者年轻律师第一次操作时很容易漏掉某个不起眼的字段。这个问题的本质是立案材料不是内容对就行而是结构和字段都对齐才行。传统方式下这些校验依赖人工逐项核对效率低且容易漏。1.2 流程之繁表单、传证、补正来回奔波的循环线上立案的完整流程比很多人想象的复杂。第一步是实名认证一般是手机号加人脸识别第二步是填写立案申请包括当事人信息、代理人信息、管辖法院、案由、标的额第三步是上传起诉状和证据材料第四步是提交后等待审核如果审核不通过还要根据补正意见修改后再次提交审核通过后涉及诉讼费的要在线缴费然后等案号生成。每一步之间都有关联。比如当事人信息填写错误可能导致后续诉讼费计算不对管辖法院选择不当可能导致立案申请直接被退回证据材料超过规定大小又会被系统拒绝。传统方式下这些都是用户自己摸索完全没有智能引导。1.3 效率之痛立案前端其实是在做翻译工作我们后来复盘时发现一个扎心的真相老实讲当事人自己填表已经是比较顺的情况了。更常见的是线下立案大厅的工作人员每天都在帮当事人做同一件事——把口语化的表述翻译成法院认可的规范化表述。比如当事人说他欠我钱不还立案材料的案由应该写民间借贷纠纷诉讼请求应该写判令被告偿还借款本金XX元及利息以XX为基数自XX起按XX计算至实际清偿之日止事实与理由部分要把借条、银行转账、催收记录对应到相应时间线上。这个翻译工作很耗时而且对非专业人士几乎不友好。这是我决定推动立项的核心原因。AI在立案环节的价值不只是把材料识别出来而是把当事人的真实意图转化为法院系统能够理解和处理的标准化信息。这才叫全流程。2. 全流程立案到底拆成几步产品设计的思路立项之后产品团队做了一件事把网上立案从用户视角和业务视角各拆了一遍。这一步很关键如果不拆后面做出来的东西一定是个四不像。2.1 用户视角从打开页面到拿到案号的完整链路我们画了一条完整链路。从用户打开小程序或网页算起一共十个节点注册登录与实名认证选择案件类型民事、行政、执行等填写当事人基础信息原告、被告、代理人选择管辖法院选择案由填写诉讼请求与标的额上传起诉状与证据材料系统校验与自动补全在线确认文书并手写签名提交、缴费、跟踪审核进度这十个节点里传统系统只做到了提供入口和结果反馈中间六个节点全靠用户自己理解。AI全流程改造的核心就是把2到8这七个节点尽量自动化、智能化让用户只需要做最终确认而不是从零填写。2.2 业务视角AI到底介入了哪些环节从业务端看AI介入可以分成四层。第一层是识别层。包括OCR识别上传的起诉状、证据材料、身份证明文件提取关键字段。这一层解决的是材料是什么的问题。第二层是理解层。把识别出来的非结构化文本转换成结构化的立案要素。比如从起诉状里提取原被告名称、案由、诉讼请求、事实与理由要点、金额、日期等。这一层解决的是材料在说什么的问题。第三层是校验层。把理解出来的要素和法院系统要求的格式做比对自动检查缺失项和冲突项。比如被告地址缺失、诉讼请求金额和证据金额不一致、管辖法院选择与被告住所地不符等。这一层解决的是材料对不对的问题。第四层是生成层。根据校验后的要素自动生成符合格式要求的起诉状文本、立案申请表单摘要、证据清单等。这一层解决的是材料怎么呈现的问题。这四层全部走通才算真正的全流程AI。市面上很多产品其实只做到了第一层甚至只做了OCR识别后面全靠模板套那离全流程还差得很远。2.3 边界视角AI不做什么是人来兜底这里必须提一个边界问题。AI可以做识别和校验但绝不能做决定。一个具体的例子AI识别出某个案件可能涉及虚假诉讼风险、或者证据矛盾明显系统不会直接判定案件有问题而是会给出风险提示转人工审核。我们在设计时就明确了一个原则AI是辅助不是裁判。立案审核的最终决定权永远在人。系统的定位是智能助手帮用户把材料准备得更完整、更规范把法官和审核人员从重复劳动里解放出来但绝不替代司法判断。这个边界不仅是产品伦理问题更是合规底线。后面所有技术方案的取舍都是围绕这个原则展开的。3. 核心实现细节我把最容易翻车的三个模块讲透技术实现方面这次最值得展开讲的是三个模块。不是因为它们用了多前沿的模型而是因为这三个模块在真实业务场景里反复踩坑最后是靠着把规则和模型结合才跑通的。3.1 材料识别模块OCR之外还得有要素修复第一版OCR方案我们用的是开源模型加自定义模型微调。做了大概两周后发现一个问题单一OCR模型识别率看起来很漂亮但在真实材料面前完全不够用。举几个真实遇到的案例。当事人上传的起诉状里手写了欠款人张某OCR识别出来变成了欠款人张某强——多了一个字。更麻烦的是有些材料是折叠过的A4纸扫描后折痕处文字变形识别结果里插入了乱码。还有身份证号里的0和O、手写金额里的1和7真实场景里根本不能用模型自信度来信任。所以我们在OCR之后加了一层要素修复模块。这层模块做的事是如果识别出的字段是金额就校验格式和范围如果是日期就校验合法性如果是身份证号就校验校验位如果是当事人名称就和起诉状里的其他位置比对一致。不一致的地方不直接改而是标记为待确认项在用户确认页面上高亮显示。这个修复层非常值得做。我自己的经验是OCR只负责把字符读出来要素修复负责把读取结果救回来。二者单独拆开效果都一般合在一起才能应付真实材料。3.2 案由与管辖匹配引擎规则优先模型兜底案由选择是网上立案里最让普通用户头疼的环节之一。法院的案由体系有四百多个四级案由光合同纠纷下面就有几十个子类非专业人士根本选不准。我们的做法是建了一张事实要素到案由的映射规则表。用户描述了借钱不还系统通过关键词触发规则锁定民间借贷纠纷用户描述了买东西不给钱规则引擎锁定买卖合同纠纷。同时如果用户的描述无法精确匹配任何一个案由模型会给出五个候选案由按置信度排序放到界面上由用户自己决定。管辖法院的匹配比案由复杂。首先它不是规则能完全覆盖的因为涉及被告住所地、合同履行地、不动产所在地等多个连接点还有专属管辖、协议管辖的排除规则。我们把这些规则全部沉淀成了可配置的规则引擎同时接入了最新版的地图地点解析服务把当事人填写的地址解析出省份、城市、区县再和法院对应关系做匹配。这里特别提一个细节。曾有用户把被告住所地写成北京市朝阳区建国路88号地址解析出来是正确区县但是我们在管辖校验时发现他选的是北京市东城区人民法院。系统直接弹窗提示被告住所地位于朝阳区根据一般地域管辖规则本案应由朝阳区人民法院管辖请确认是否修改。这个提示至少为当事人省掉了一次驳回。3.3 文书生成与复核机制套模板只是最后一步自动生成起诉状是很多人对AI立案最直观的期待。但实际做的时候我们发现文本生成在立案场景里最大的坑不是写不出来而是写出来之后没人敢直接提交。我们的实现路径是三层。第一层是原文引用系统会原样引用当事人在表单里填写的诉讼请求和事实描述不做任何润色避免AI自作主张修改当事人的意思。第二层是缺失补全如果当事人上传的材料里有相关内容但表单里没填系统会用材料中的原文自动补齐对应字段并明确标注该内容由系统根据您上传的材料提取请确认。第三层是格式规范案件类型、管辖法院、当事人信息、案由代码等结构化字段按照法院要求格式化输出到文书里。也就是说AI生成的起诉状里每一段内容你都能找到它到底是从哪来的是用户自己填的还是系统从材料里提取的都有标记。这个设计在内部评审时被法务同事反复确认过最终确认是合规可控的。复核机制上我们做了双轨确认用户在提交前必须逐项浏览要素确认页对系统提取的当事人、金额、日期、案由逐项确认。确认之后还要进行一次手写签名签名数据做了哈希处理存证保证不可篡改。这一步不只是为了体验更是为了在源头上减少我根本没看过这份起诉状的扯皮空间。注意AI生成内容必须可溯源这是法律科技产品的基本功。无法溯源的内容在立案场景里宁可不用。4. 上线后真实跑了一百单数据与踩坑记录上线不是终点是开始。正式上线两周后我们统计了首批一百个测试单的真实数据。有不少惊喜也有不少打脸的地方。4.1 端到端平均耗时从40分钟降到8分钟我们拿传统线上立案的数据做了同期对比。传统方式下用户从开始填写到完成提交平均耗时大约40分钟如果有材料被退回补正平均完整周期会拉到两到三天。而通过吾律AI全流程从注册登录到完成提交首批一百单的平均端到端耗时是8分钟其中最快的一单只用了3分20秒。这个差距主要来自两个环节。一是材料上传后系统自动完成了要素提取和表单填充用户省掉了大段的打字时间二是校验前置用户不用等审核人员来退件而是提交前就被系统拦住了明显错误。同时首批一百单里一次性提交通过率做到了62%。剩下38%里有一半是用户自己确认环节里主动改动了内容另一半是法院审核时提出了补充材料要求。这个数字远没有到好看的程度但和传统方式下首次提交通过率普遍只有三到四成相比进步已经是实打实的了。4.2 驳回率与补正率AI没有抹平的隐性成本数据里最值得反思的是AI并没有完全解决材料不全的问题。很多用户手头只有一张借条没有转账记录也没有对方的身份证号这种情况下不管AI再怎么引导和填充立案审核依然是过不去的。这暴露了一个产品设计上需要坦诚面对的点AI能优化流程但无法凭空创造当事人本就不掌握的材料。我们在产品里加了一个材料预检报告功能在上传阶段就提示用户您未上传转账记录借款类纠纷建议补充该材料否则有较高补正风险。这个报告不会阻断提交但会提前让用户做好准备大幅减少了被驳回后才知道缺什么的挫败感。另一个隐性成本是过度提取。有用户在证据里有一份无关的银行流水系统把流水里的大额金额当成了诉讼标的额结果生成的诉讼请求金额比实际高出一大截。后来我们加了来源段落引用和金额上下文校验凡是提取出的金额都要在原文中标注所在的证据名称和具体页码供用户核对。4.3 数据隐私与安全这个环节我们做了三件事法律数据是高敏数据这个没人能回避。围绕用户上传的起诉状、身份证、证据材料我们从上线第一天就做了三件事。第一全链路加密。上传、传输、存储、展示全部走国密算法加密明文数据不落盘。数据库层面做了字段级加密即使内部人员导出数据看到的也是密文。第二最小化使用。AI识别和要素提取全部在隔离的推理服务里完成任务结束后模型不保留用户原文。训练数据全部来源于脱敏后的公开裁判文书不拿用户上传材料做任何模型训练。第三访问审计。所有能触达原始材料的人员每一次打开、下载、导出的行为都有操作日志日志本身不能被修改。上线后第三周我们还做过一次内部模拟审计效果是达标的。这里也提醒做同类产品的团队不要低估安全合规在项目评审里的分量。如果不在一开始就把数据边界讲清楚后期补的成本非常高。5. 常见问题速查与运维建议上线三个月后我们汇总了用户反馈和后台工单这里直接把最高频的六个问题整理成速查表都是真实遇到过的场景。5.1 用户最常问的六个问题问题原因解决方案上传的起诉状总是提示内容解析失败图片模糊或文件格式不规范调整为PDF或高清JPG分辨率建议不低于300dpiAI提取的被告名字少了一个字OCR对生僻字、手写体识别不准系统已提供待确认项标记务必在确认页逐项核对身份证号码末尾有X系统老是提示错误部分扫描件把X识别成乘号或0修复模块会检测身份证校验位提示用户手动修正选了被告所在地法院仍提示管辖异常合同里有约定管辖条款优先于法定管辖系统会理解上传合同的协议管辖条款并给出提示证据文件太大了传不上去单文件大小限制建议拆分成多个PDF或压缩图片后再上传文书签名时手写签名总是失败手写轨迹特征不稳定系统支持签名笔迹存档连续三次失败可转人工核验这些问题的共同点是大多不是AI识别完全错了而是识别结果需要人来确认。所以如果你也想做类似产品请务必把确认页做得足够清楚让用户愿意核对、容易核对。5.2 上线三个月后运维团队的四条建议第一条OCR和要素修复模型的灰度节奏要慢。我们吃过一次亏升级了一版模型后整体准确率表面上提升了但某个特定字体的身份证识别率反而下降导致那两天补正量激增。后来改了策略模型升级先走10%流量灰度观察三天再全量。第二条用户画像比想象中更杂。不仅有精通手机的年轻人还有六十多岁帮子女立案的老人。界面不能默认用户什么都知道关键按钮要可以用最朴素的语言描述例如点这里上传而不要写导入材料。第三条与法院审核口径的联动要及时。每个法院对材料格式的理解会有细微差异我们会定期收集同地区法院的退件理由把高频补正理由更新到系统规则库中。这个动作不能只做一次要持续维护。第四条线上服务要有人工出口。AI跑得再顺也一定有人面对面沟通的需求。我们保留了在线人工客服和电话专线不追求所有环节全部自动化。有些用户打进来纯粹就是问一句我传得对不对有这样的出口比单纯写说明文档管用得多。6. 给想入局法律AI的人经验与后话最后说点个人体会。做法律AI产品技术难度反而不是最大的门槛真正的门槛在于对业务边界的认知。你越懂立案流程越知道哪些环节适合AI提效哪些环节必须留给人。就像我们团队里那位做过六年诉讼律师的同事说的AI能把材料翻译成规范语言但当事人为什么要起诉、起诉背后想要什么这个判断永远要有人来做。就我个人的实际观察目前线上全流程立案最受益的场景有三类一是批量案件比如物业合同纠纷、信用卡纠纷当事人拿到一批同样的模板文件AI能成套提取和填充二是标准化程度高的单案比如民间借贷要素明确、材料相对简单三是不熟悉法律术语的新手用户AI的引导式提问大大降低了他们的心理门槛。而复杂案件例如知识产权、工程纠纷、对证据形式要求极高的场景目前系统更多是辅助梳理材料还不能做到全自动处理。如果你也在做类似方向我的建议是先从某一个具体案由切入做深做透再横向扩展。我们第一个完整跑通的案由就是民间借贷纠纷因为它的要素边界清晰、材料类型相对固定、用户量大。跑通这一个案由之后其他案由的扩展就是往规则引擎里持续加规则的事了。这次上线只是一个节点。我后续准备在合规基础上继续沉淀案由体系把劳动争议、交通事故、买卖合同等高频案由逐步接进来。也希望更多做法律科技的朋友一起来交流这个领域足够大不是一家能吃下的。