法律 AI 不该从聊天窗口开始，而要从案件工作台开始

一个商事诉讼案件可能包含合同、聊天记录、财务凭证和证据文件，总页数动辄上千页。律师需要先整理材料、梳理人物关系和事实关系，再把当事人的口语描述转换成法律语言，寻找请求权基础，最后形成诉讼策略和各种文书。

过去，法律数据库解决“查”，文档系统解决“存”，一些问答工具解决“生成”。但真实案件会持续数月甚至一年，材料和争议点不断变化。律师每次重新进入案件，都要重新恢复上下文。

这个案例的关键判断是：法律 AI 不应该先做一个更聪明的聊天窗口，而应该先建立一个能持续承载案件的工作台。只有案件上下文、证据关系、法律依据和过程记录都在同一个空间里，AI 才可能成为持续协作的伙伴。

落地场景：让 AI 进入律师完整的办案流程#

服务对象是处理商事合同纠纷、公司股权争议等复杂案件的诉讼律师团队。一个案件从理解客户需求开始，经过材料阅读、事实梳理、法律检索、策略设计，最后形成面向客户、法院或其他专业人员的交付物。

真正的瓶颈不在律师是否具备专业判断，而在大量案头信息处理：

• 一个典型案件的材料整理可能耗费 3 到 5 个工作日；
• 涉及十几个当事人的案件，人物关系梳理可能需要两三天；
• 当事人的日常口语需要被提炼为具有法律意义的要件事实；
• 案件持续时间长，新证据和争议点出现后，律师必须不断维护对案件的完整认知。

因此，场景不是“回答一个法律问题”，而是让 AI 进入案件全流程，承担信息整理、摘要、关系梳理、初步检索和文书准备，让律师把时间放回客户沟通、策略判断和最终专业责任。

落地难点：法律知识之外，还有专业思维和案件上下文#

律师的隐性经验不能直接复制#

法律行业的关键不只是知道哪条法条，还包括什么事实值得关注、如何把口语转换成法律语言、哪些依据真正匹配、证据之间如何形成逻辑关系。这些是律师多年实践形成的隐性经验。

如果只把法律条文接入模型，系统最多成为一个问答工具，无法按照律师处理案件的方式组织信息。

一次对话装不下一个长期案件#

项目最初设计成智能对话框，律师登录后直接向 AI 提问。但现场很快暴露出问题：律师每次提问前都需要重新描述案件背景，而一个案件的信息量巨大，这反而增加了使用负担。

诉讼案件更像一个长期项目，需要持续承载材料、过程记录和变化中的信息。产品形态如果仍然只是一次性聊天，案件上下文就会在一次次对话之间断裂。

用户习惯会把新产品拉回聊天框#

律师一开始进入产品，也会习惯性寻找输入框，问“我应该在哪里输入问题”。但如果 AI 已经理解案件背景，用户就不应该每次重复描述。

这要求产品在不强行教育用户的同时，引导他先建案、上传材料，并让价值尽快可见。用户看到系统自动生成案件概要和人物关系图，才会理解为什么案件工作台比一个空白聊天框更适合长期协作。

如何落地：从现场观察到案件工作台的四步#

第一步，进入律师现场，理解真正要交付什么#

项目启动后，FDE持续观察律师从早上打开电脑开始的一整套工作：如何接收客户邮件、翻阅纸质案卷、在多个系统之间切换、参加案件讨论会，以及合伙人如何从聊天记录判断当事人的真实意思表示。

每一步都要追问：需要什么输入，产出什么交付物，最后给谁看，什么结果才算真正可用。AI 不能只生成一段“看起来专业”的文字，它要产生律师能够继续处理、交付给客户或提交给法院的结果。

第二步，把案件拆成可协作的标准模块#

团队没有推翻律师原来的工作方式，而是在原流程中寻找 AI 可以嵌入的位置：案件概要、当事人关系、证据关系、事实梳理、法律语言转换、依据检索和交付文书准备。

通过持续梳理，项目形成了 7 个标准模块和相应的法律思维框架，把重复但高价值的工作转成可以被系统持续执行的流程节点。

第三步，让大模型和专业系统各自负责擅长的部分#

大模型负责自然语言理解、文本摘要和初步法律推理，从非结构化材料中提取关键信息，理解律师用自然语言表达的复杂需求。

专业系统负责案件知识图谱、法律条文结构化检索和判例精确匹配，保证法律引用的准确性和可追溯性。律师则负责最终判断、策略选择和专业责任。三者通过统一的案件工作空间连接，用户看到的是一体化协作，而不是多个孤立工具。

第四步，从聊天入口改成案件工作台#

产品把入口从空白聊天框调整成案件工作台：律师先上传材料，系统构建案件知识图谱，AI 在完整理解上下文后再与律师交互。

这样，律师只需要用自己的专业语言提出具体要求，比如分析下一步诉讼策略、整理证据清单或形成客户报告，不需要学习复杂的提示词，也不需要反复重述案件背景。所有分析结果、策略建议和文书草稿都沉淀在案件空间里，形成可追溯的工作记录。

落地成果：律师从信息处理者回到决策者#

一个涉及 14 个被告的案件中，过去单个被告的请求权基础分析需要 2 到 3 小时，全部整理完成需要 2 到 3 天；使用 AI 后，律师把材料交给系统，一个晚上就完成了原本需要几天的工作。

另一个案例中，律师临时接案，距离开庭只有 3 天，材料超过 100 万字。AI 辅助下，律师在一天内完成案件整体梳理、人物关系、法律关系和案件脉络分析，并进一步制定开庭策略；案例资料称材料整理效率相比纯人工提升约 70%。

变化前	落地后的变化
律师人工通读、标注和归类大量材料	AI 先完成案件概要与关系梳理
法律数据库和文档系统各自解决单点问题	案件上下文、知识图谱与交互集中在工作台
律师大量时间消耗在执行和检索	律师把更多精力投入客户沟通与策略判断
资深律师的思考方式难以复制	专业框架被沉淀为可复用的流程模块

表层成果是效率提升，更深层的变化是专业角色重新分配：AI 处理大量信息，律师保留最终判断和责任。优秀律师的工作方法也不再只能存在于个人经验中，而开始成为团队可以复用的辅助能力。

这个案例给 FDE 的四个提醒#

第一，先用业务语言定义问题，再讨论模型能力。如果从“我有什么模型”开始，最后很容易做成法律知识问答，而不是改变律师工作方式的系统。

第二，行业专家不是验收对象，而是共同设计者。律师如何思考、如何判断证据、如何决定交付标准，必须进入系统设计过程。

第三，长期项目需要长期上下文。对话框适合一次性问题，案件工作台才适合材料持续增加、观点不断修正的复杂工作。

第四，落地细节比模型能力更接近真实价值。用户是否愿意使用、结果能否直接交付、引用能否追溯、专业责任由谁承担，这些问题决定 AI 能否进入法律业务。

来源与边界#

• 原始资料：Datawhale《FDE案例100.pdf》，案例三“从案头工作到智能协作：FDE用AI优化诉讼律师的案件处理能力”，案例访谈正文位于 PDF 第 26–33 页。
• 案例事实：材料整理可能耗费 3–5 个工作日；复杂案件人物关系梳理可能需要两三天；一个 14 被告案件从数天缩短到一晚；超过 100 万字的临期开庭材料在一天内完成整体梳理；案例称材料整理效率提升约 70%；项目形成 7 个标准模块。
• 结果边界：上述效率数字来自案例访谈，没有提供统一样本量、受控对照或完整的法律结果质量评估，不能直接推导案件胜诉率或通用生产力提升。
• 产品化解读：关于案件工作台、知识图谱、专业系统与律师责任边界的总结，是基于案例内容的产品化分析，不代表所有法律业务都适合相同架构。