律所数字化不是装个OA就行：一套案件协同+智能文书系统到底怎么搭？（技术架构全解析）

律所数字化的一大半预算，花在了没人用的系统上

这几年跟不少律所的管理合伙人聊过，发现一个扎心的规律：越贵的系统，闲置率越高。花三五十万上了套所谓"全功能律所管理系统"，半年后律师们还是用微信传文件、Excel记工时、Word改合同版本。不是律师排斥数字化，是市面上的系统压根没解决他们真正的痛点。

问题出在哪？绝大多数律所管理系统本质上就是个OA审批流+文档库的缝合怪，律师最需要的三件事——案件协同、文书自动生成、知识复用——一个都没做好。

前段时间帮一家40人规模的精品律所做了一套案子，从选型到上线用了6周，第二个月活跃度就冲到了87%。核心架构说穿了不值钱，但踩过的坑值得分享出来。

这套系统的技术架构长什么样

我们最终落地的方案是 微服务+事件驱动 的架构，前后端分离，数据库用了混合存储策略。整体拓扑大概是这样：

                    ┌─────────────────────┐
                    │   Nginx / 负载均衡   │
                    └────────┬────────────┘
                             │
                    ┌────────▼────────────┐
                    │  API Gateway (Kong)  │
                    └────────┬────────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────▼────────┐ ┌──▼───┐ ┌────────▼────────┐
     │  案件服务( Node )│ │文书服务│ │ 知识库服务       │
     └────────┬────────┘ └──┬───┘ └────────┬────────┘
              │              │              │
              ▼              ▼              ▼
     ┌──────────────────────────────────────────┐
     │        消息队列 RabbitMQ                  │
     └────────┬──────────┬──────────┬───────────┘
              │          │          │
     ┌────────▼──┐ ┌─────▼────┐ ┌──▼──────────┐
     │PostgreSQL │ │  Redis   │ │Elasticsearch │
     │  (主库)   │ │  (缓存)  │ │  (全文检索)  │
     └───────────┘ └──────────┘ └─────────────┘

每个微服务控制在2000行核心逻辑以内，用 Node.js + TypeScript 写，部署在2台4C8G的云服务器上。为什么选Node.js而不是Java？ 因为律所系统的并发量不大（峰值也就几十人同时在线），Node.js的IO密集型优势在这里够用，而且迭代速度快——律师的需求变更极其频繁，今天要加个字段，明天要改个审批流，Node.js热重载的开发体验比Java快一个数量级。

案件协同模块：最容易被低估的技术难点

大多数律所系统把案件管理做成了"给案件建个文件夹"，这基本等于没用。真正好用的案件协同，核心在于时间轴+上下文关联。

时间轴设计

每个案件有一个独立的事件流（Event Sourcing），所有操作——立案、分配律师、提交文件、修改deadline、发送账单——都作为不可变事件追加写入。这样做有三个好处：

1. 审计日志天然完整：谁在什么时候干了什么，一查一个准，不用专门写审计表
2. 回滚方便：事件流可以重建任意时间点的案件快照
3. 律师体验好：打开案件页面就能看到完整的时间线，不用在各个模块之间切来切去

事件的数据结构我们设计成这样（简化版）：

interface CaseEvent {
  eventId: string;
  caseId: string;
  eventType: 'ASSIGN' | 'DOC_UPLOAD' | 'DEADLINE_CHANGE' | 'BILL_SENT' | 'NOTE_ADDED';
  actor: string;        // 操作人
  timestamp: number;    // 时间戳
  payload: Record<string, any>;
  previousState?: any;
}

踩坑提醒：事件表的数据量增长比预期的快。一个活跃案件半年就能产生上千条事件，查询时如果做全表扫描，页面加载能卡到3秒以上。必须要对caseId+timestamp建联合索引，并且对超过一年的历史事件做冷热分离——把老事件归档到ClickHouse或者直接存JSON文件。

上下文关联

律师看一个案件时，经常需要同时参考相关法条、历史判例、同类案件的收费标准。我们做了个轻量级知识图谱——不是那种高大上的图数据库，就是在PostgreSQL里用一张case_relations表存关联关系：

CREATE TABLE case_relations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  source_id VARCHAR(64) NOT NULL,
  source_type VARCHAR(32) NOT NULL,
  target_id VARCHAR(64) NOT NULL,
  target_type VARCHAR(32) NOT NULL,
  relation_type VARCHAR(32) NOT NULL DEFAULT 'REFERENCE',
  weight FLOAT DEFAULT 1.0,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_relations_source ON case_relations(source_id, source_type);
CREATE INDEX idx_relations_target ON case_relations(target_id, target_type);

配合Elasticsearch做全文检索，律师输入关键词就能看到关联的案件、合同模板、法条更新。实测效果：律师查找同类案件的时间从平均15分钟缩短到不到1分钟。

智能文书模块：律师最想要的"一键生成"

律所最大的时间黑洞是什么？写文书。一份起诉状、代理词或者法律意见书，资深律师也要花4-6小时，其中大量时间是复制粘贴和格式调整。

我们的文书引擎做了一件很务实的事：模板引擎+变量填充+条款推荐，三层架构，不堆AI概念。

第一层：模板引擎

基于Handlebars做了一套律所专用的模板语法。律师先在系统里建好文书模板，用{{clientName}}、{{caseNumber}}、{{courtName}}这些占位符标出需要填充的位置：

**起诉状**

原告：{{plaintiffName}}，住所地：{{plaintiffAddress}}
被告：{{defendantName}}，住所地：{{defendantAddress}}

诉讼请求：
{{#each claims}}
{{addOne @index}}、{{this}}
{{/each}}

事实与理由：
{{factAndReason}}

模板建好后，系统自动从案件信息中提取变量完成填充。80%的常规文书可以在5分钟内生成初稿。

第二层：文本变量自动映射

这是最花功夫的模块。案件信息散落在不同地方——当事人信息在客户表里、案由在case表里、历次沟通记录在事件流里。我们写了个变量解析器，能根据模板中的变量名自动定位数据源：

class VariableResolver {
  private sources: Map<string, DataSource> = new Map();

  constructor(caseData: CaseData) {
    this.sources.set('case', new CaseDataSource(caseData));
    this.sources.set('client', new ClientDataSource(caseData.clientId));
    this.sources.set('firm', new FirmDataSource());
    this.sources.set('statute', new StatuteDataSource());
  }

  resolve(variableName: string): any {
    const [source, ...keys] = variableName.split('.');
    const ds = this.sources.get(source);
    if (!ds) throw new Error('Unknown source: ' + source);
    return ds.get(keys.join('.'));
  }
}

第三层：条款推荐（用不用AI取决于预算）

我们做了一版带LLM的条款推荐——根据案由和案件事实，从历史文书中检索最相关的条款模板。其实这东西用embedding向量检索+规则过滤就够了，不需要上大模型推理。用sentence-transformers把条款文本转成384维向量，存在PostgreSQL的pgvector扩展里，检索延迟控制在50ms以内。

如果预算有限，跳过LLM这层也没关系。 纯规则匹配的条款推荐（按案由+标的额+法院层级三级筛选），准确率也有70%以上，够用了。

选型避坑：几个让你少花冤枉钱的关键决策

1. 别上来就买SaaS年费制系统

律所的数据敏感性极高，案件信息、客户资料、合同内容都是核心机密。SaaS系统数据存在供应商服务器上，合规风险太大。建议用开源自建+私有化部署。我们的技术栈全开源，零license费用：

2. 权限模型要支持"案件隔离"

大所里不同团队之间不能互相看对方的案件，但合伙人需要跨案件看汇总数据。我们用了RBAC+数据级权限的双层模型：RBAC控制"能访问哪个功能"，数据权限控制"能看到哪些案件"。数据权限的过滤直接在SQL层完成，避免前端过滤的安全漏洞。

3. 文书版本管理别用Git

有团队试过用Git管合同版本，律师学不会。最终方案是：每保存一次自动生成版本快照，版本列表按时间倒排，支持"谁在什么时间改了什么字段"的细粒度对比。后端实现就是一张doc_versions表，存完整JSON快照，600字的合同一个版本也就2KB，存一万个版本才20MB，完全够用。

上线后效果怎么样

40人的精品律所，上线8周后：

• 文书起草效率：常规合同/起诉状从平均4小时缩到40分钟
• 案件状态同步：不再需要每周开会口头通报，打开系统一看就知道
• 知识复用率：律师检索使用历史文书模板的次数从每周3次涨到47次
• 服务器成本：2台4C8G服务器，月成本不到1500元

这套系统的全部核心代码量大约1.2万行，从零到交付，两个后端加一个前端，6周搞定。不是因为它有多牛，是因为没用那些花里胡哨的"企业级框架"，选对了技术栈，效率自然就上来了。

说几句实在话

律所数字化这件事，技术上完全没有门槛。真正的难点在于：你是不是真的理解律师的工作流。市面上绝大多数律所系统是给"管理者"做的，不是给"干活的人"做的。如果一套系统的第一用户不是办案律师，它注定被闲置。

如果你也在考虑律所相关 软件外包服务，或者想换掉现在那套不好用的系统，欢迎来 智岳科技 聊聊。我们不推销标准化产品，会根据你的律所规模和业务特点，客观评估是定制开发还是开源改造更划算——毕竟有些律所的情况，调整一下现有的工作流就够用了，不需要花冤枉钱重新造轮子。更多 行业动态 和 AI项目定制案例 也可以参考我们的官网。