案例 03 · 诉讼律师协作

文字由原PDF提取，阅读顺序和表格请以原页为准。

法律数据库（如北大法宝、威科先行）可以查询法条和判例，文档管理系统帮助律师归
档文件，也有一些早期的法律问答工具尝试辅助生成简单文本。
但这些工具解决的只是“查”和“生成”两个单点动作。真实案件是持续变化的，律师需
要反复回到同一个案件，补充分析、更新判断。传统法律数据库的设计逻辑是一次性查
询，这与律师的实际工作节奏完全脱节。
过去的标准工作方式是这样的：律师收到案件材料后，人工阅读和整理；把自然语言描
述转换成法律专业语言；通过法律数据库寻找相关依据；结合自身经验形成判断；最后
输出报告、诉讼材料或策略建议。整个过程大量依赖律师个人的大脑和经验。
过去十年，律所也尝试过引入更多数字化工具，但落地效果普遍不理想。
原因有两个：第一，每个工具只解决一个单点问题，律师需要在五六个系统之间切换，
案件上下文被割裂，无法形成连贯的工作流；第二，这些工具的使用门槛与律师自然的
工作方式存在断层，律师需要学习特定的检索语法或操作逻辑，增加了额外负担。
最终，大部分工具沦为查法条的辅助手段，未能真正融入案件处理的完整流程。
传统方案的根本缺陷，是缺少一个能够同时理解技术和业务现场的角色，把律师真正需
要的能力翻译成可落地的系统。
Q3：后来你使用AI解决这个问题的整体思路和关键步骤是什么？
第一步，是进入业务现场理解用户。
项目启动后，我没有直接设计功能，而是先进入了律师的真实工作环境。我们对律所诉
讼团队的观察是一直持续进行的，因为诉讼是一件很复杂的事情，我们会从现场带回已
经脱敏的各类资料回来研究。另外也会跟合伙人律师进行深度访谈调研，这样的调研频
率非常高，我们从调研中知道他们想要什么，想在哪些地方省时间，哪些地方即使省了
时间他们也不放心。这对我们的系统设计会很有指导意义，哪些留给人来决策，哪些让
26/243