44秒读完诉状：n8n+LexSelect打造法律文书自动化流水线

法律文书处理的隐形成本

一份诉状落到律所手上，往往意味着一连串重复而繁琐的工作。来自自动化服务商 Praxisflow 的 Javier 在演示中举了个典型例子：一份 15 页的诉状，必须有人先通读全文，手动提取当事人、诉讼请求、每一项指控，然后再在系统里建立案件（matter）。这项工作看似简单，却极度耗时，且容易出错——律师和律师助理的大量工时被消耗在"把文档变成结构化数据"这件事上。

Praxisflow 展示的方案核心是一个基于 n8n 工作流、搭配 LexSelect 的自动化流水线。LexSelect 是一款专门读取法律文档、并将其转化为结构化数据的工具。整条流水线的目标很直接：把一份原始诉状，在约一分钟内变成"可直接开工"的案件记录。

四步流水线：从上传到建档

整个工作流被拆解为四个清晰的环节。第一步，诉状进入系统——律师或律师助理只需上传文件，或像演示中那样粘贴一个文档链接，这是人工唯一需要做的操作。第二步，LexSelect 像人一样逐页阅读 PDF，识别标题、段落编号、每一项指控（count）以及"诉讼请求"（prayer for relief），并为每一个片段标记它所在的页码。

第三步，AI 接手处理。值得关注的一个设计是，AI 并不通读全文，而是"只阅读重要的部分"——大约只占文档的一半。这既降低了调用成本，也提升了速度。第四步，案件被自动创建并写入数据库。

这种"分工"思路很有意思：LexSelect 负责把非结构化文档解析成带页码的结构化片段，AI 则在此基础上做语义层面的信息抽取。前者保证了可定位性，后者保证了理解力。

n8n 是一款开源的工作流自动化平台，类似于 Zapier 或 Make（原 Integromat），但支持自托管部署，允许企业将数据留存在自己的服务器上。它通过可视化节点连接各类服务——文件存储、AI 模型、数据库、邮件等——将原本需要手动衔接的多个步骤串联成一条无需人工干预的流水线。在法律场景中，自托管能力尤为重要，因为涉及当事人信息的诉状文件往往受到保密义务约束，律所通常不希望原始文档经过第三方云端处理。n8n 的这一特性使得合规性与自动化效率可以同时兼顾。

可验证性：每个结论都能追溯到原文

这个工作流最值得称道的，不是速度，而是对"可验证"的执着。AI 在提取每一条细节时，都必须"证明自己的工作"——为每个结论给出页码和原文中的确切词句。随后系统会做一轮核对：逐条拿提取出的引用与文档比对，如果某段引文在对应页码上找不到，这一条就不通过。

演示结果展示在 Airtable 中：一条新建的案件记录，已标记为"ready"，包含当事人、法院、案号、每一项指控、诉讼请求、是否要求陪审团审判，外加一段简短摘要。每一行都附有自己的页码，全部 16 处引用均通过核对。同时，承办律师会收到一封邮件摘要，列出所有引用出处，便于在几秒内核查任意一条信息。

在 AI 普遍存在"幻觉"问题的背景下，这种"引用必须落在原文页上才算数"的硬性校验机制，对法律这类高风险场景尤为关键。它把 AI 从一个"可能编造答案的黑盒"变成了一个"每句话都能回溯的助手"。

大语言模型（LLM）的"幻觉"（hallucination）问题，指模型在生成文本时可能输出听起来合理但实际上并不存在于原始资料中的内容——包括捏造的引用、错误的日期或虚构的法条条文。这在通用场景下可能只是质量瑕疵，但在法律文书处理中则可能直接导致错漏诉讼请求、误判当事人，乃至引发专业责任风险。正因如此，业界对"RAG + 引用锚定"（Retrieval-Augmented Generation with citation grounding）的方案需求强烈——即要求 AI 的每个输出都必须能定位到原文的具体段落，而非凭空生成。本文介绍的页码核对机制，正是这一思路在生产环境中的具体落地实现。

不确定时交给人：失败案例的处理

演示还特意展示了一个"没通过"的场景——另一份长达 30 页的诉状。其中一项指控的标题无法与文档内容核对一致。系统没有选择"猜"，而是直接把这条案件标记为需要人工复核，并把具体原因就地标注出来。

这一设计体现了负责任的自动化思路：当置信度不足时，流水线主动把决策权交还给人，而不是输出一个看似完整、实则可能错误的结果。对律所而言，这意味着自动化不是用来替代专业判断，而是把人力从机械抽取中解放出来，集中到真正需要判断的边界情况上。

对法律科技自动化的启示

这套由 n8n 编排、LexSelect 解析、AI 抽取构成的组合，给法律及其他专业文档密集型行业提供了一个可借鉴的范式。Javier 指出，如果律所每天花费大量时间把文档变成案件、把合同变成清单、把文书变成截止日期，这正是可以被自动化的工作类型。

核心经验可以归纳为三点：用专门工具做文档结构化解析而非让 LLM 硬读整篇；强制 AI 输出可追溯的引用并做机械化校验；在不确定时触发人工复核。这三条组合在一起，才让"44 秒处理一份诉状"从一个噱头变成一个真正可信赖的生产工具。

当然，作为服务商的产品演示，内容更多聚焦于顺利路径下的效果，对解析复杂格式文档的准确率上限、不同诉状结构的适配性等问题着墨不多，实际落地效果仍需在更多真实案例中验证。但其在"可验证性"与"人机协作边界"上的设计思路，值得所有做专业领域 AI 自动化的团队参考。

文档密集型行业的自动化挑战，在于非结构化文本与下游系统所需结构化数据之间存在天然鸿沟。传统的基于规则的解析（如正则表达式、模板匹配）对格式高度一致的文档效果尚可，但面对不同法院、不同律所产出的诉状时，格式差异极大，规则维护成本极高。LLM 的出现让语义级别的信息抽取成为可能，但单纯依赖 LLM 端到端处理长文档又面临上下文窗口限制、成本高企和幻觉风险。LexSelect 所代表的"预解析层"思路——先用专用工具将文档切分为带坐标的结构化片段，再将小块喂给 LLM——是目前在准确率、成本、速度三者之间寻求平衡的主流工程实践之一，也被称为"分块检索增强"（chunk-level RAG）架构。