当一家律所或法律科技团队决定「自己做 AI」——类案检索、文书辅助、案件预判——选型会议上最先吵起来的往往不是模型,而是数据底座到底用谁的。有人提北大法宝,有人说无讼好用,有人用惯了 iCourt Alpha,也有人听说文书查。问题是:这几个名字经常被放在一起比,但它们根本不在同一个货架上。把订阅型数据库、办案工具 SaaS 和可私有化的数据底座混为一谈,选完才发现「买回来的东西灌不进自己的系统」。本文把四者放在同一张表上,讲清各自是什么、适合谁,以及做私有化 AI 时该怎么选。
一、先分清:它们解决的根本不是同一个问题
选型的第一性问题不是「谁的数据多」,而是「这是给人查的,还是给我的系统用的」。按这个标准,市面上的产品大致分三类:
| 类型 | 代表 | 核心形态 | 解决谁的问题 |
|---|---|---|---|
| 综合法律数据库(订阅) | 北大法宝(PKULAW) | 网页/账号订阅,法律法规 + 司法案例 + 期刊的综合检索 | 律师、研究者、高校「人去查、人去读」 |
| 裁判文书检索 + 律师社区 | 无讼 | 以裁判文书检索起家,叠加律师社区与产品工具 | 一线律师快速检索类案、找同行 |
| 律师办案工具(SaaS) | iCourt Alpha | 面向办案流程的工具平台,内含案例库等模块 | 律师团队的案件管理与办案提效 |
| 数据底座(可授权 / 可私有化) | 文书查 | 全量裁判文书 + 法规,作为可批量授权、可本地部署的数据资产交付 | 律所/团队「让自己的系统和模型去用」 |
看清这张表,选型就清楚了一半:前三类的产品逻辑是「我们做好界面,你来用」;数据底座的逻辑是「我们把数据交给你,你拿去建自己的能力」。如果你的目标是搭一套属于本所、跑在本所内网的 AI 系统,你要的是第四类——哪怕你同时还在用前几类做人工研究。
二、五个维度,把四者放在同一张表上
抛开各家的宣传话术,真正决定 AI 选型的是下面五个维度。注意:对「人工检索」场景重要的指标(界面好不好用、社区活不活跃),对「AI 数据底座」场景几乎不重要;反过来也是。
| 维度 | 综合数据库 (如北大法宝) | 检索/社区 (如无讼) | 办案 SaaS (如 Alpha) | 数据底座 (文书查) |
|---|---|---|---|---|
| 1. 你买到的是什么 | 检索账号 / 订阅席位 | 检索账号 / 工具席位 | 办案工具席位 | 数据本身 + 批量授权 |
| 2. 数据能否批量导出/调用 | 一般不开放全量 | 一般不开放全量 | 一般不开放全量 | 可批量授权(bulk + API) |
| 3. 能否本地私有化部署 | 否(云端订阅为主) | 否 | 否 | 可部署到内网、完全离线 |
| 4. 能否当 AI 底座(RAG/微调) | 非设计目标 | 非设计目标 | 非设计目标 | 正是设计目标 |
| 5. 结构化字段 + 稳定 ID | 面向阅读 | 面向阅读 | 面向办案 | 面向机器:案号/法院/案由/结果字段化 |
一句话总结:北大法宝、无讼、Alpha 都是优秀的「人用」产品,在各自场景里很成熟;但它们的产品设计目标都不是「把全量数据交给你去喂自己的模型和检索引擎」。当你的需求从「人去查」变成「系统去用」,选型的坐标轴就整个换了。
三、逐个看:它们分别适合谁
北大法宝(PKULAW)——综合研究与法条法规检索的老牌选择
北大法宝是国内综合法律数据库的代表之一,法律法规、司法案例、法学期刊等多库合一,长期服务高校、研究机构和律所的人工研究与检索场景。如果你的核心需求是「律师和研究者上网页做权威的法条法规检索、写论文、做综合法律研究」,这类综合库有其不可替代的价值。但它的交付形态是订阅账号,通常不以「把全量数据批量授权给你本地部署」为产品方向——做 AI 底座不是它要解决的问题。
无讼——一线律师的裁判文书检索与同行社区
无讼以裁判文书检索切入,叠加了律师社区与产品工具,在「一线律师快速找类案、连接同行」这件事上口碑不错。它解决的是律师个人/团队的即时检索效率。同样,它是给人用的工具,不以全量数据授权 + 私有化部署为定位。
iCourt Alpha——围绕办案流程的工具型 SaaS
Alpha 是 iCourt 体系下面向律师办案流程的工具平台,把案例检索、案件管理等揉进律师的日常工作流,内含案例库模块。它的强项在办案流程提效与团队协作。但它本质是 SaaS 工具,数据与能力都在它的平台里,不是交给你去搭自己系统的底座。
文书查——给你自己的 AI 系统用的数据底座
文书查的定位和上面三者正交:它不主打「我们做一个好用的界面给律师查」,而是把全量裁判文书(覆盖刑事/民事/行政/执行/国家赔偿)+ 法规库,作为可批量授权、可本地私有化部署的数据资产交付。配套提供结构化字段、稳定 ID、REST API 与 MCP,目的就是让你能把它接进自己的检索引擎、RAG 管线和法律大模型。换句话说,前三者帮「人」更快找到案例;文书查帮「你的系统」拥有案例。对要做私有化 AI 的律所和政府客户,这是底座层的选择。
关于这套数据底座在内网具体怎么落地——存储、全文 + 向量混合检索、离线增量更新、权限与审计——可参见我们的 1.5 亿裁判文书私有库本地化部署架构;关于用本所卷宗叠加微调,见 法律大模型微调实测。
四、按场景选型:对号入座
不用纠结「谁更强」,只问「我要干什么」:
- 我要让律师/研究者上网页做权威法条法规检索与综合研究 → 综合数据库(如北大法宝)。这是它的主场。
- 我要一线律师快速检索类案、连接同行 → 检索/社区类工具(如无讼)。
- 我要把案件管理、办案流程在一个平台里跑顺 → 办案 SaaS(如 Alpha)。
- 我要搭一套跑在本所内网、属于自己的 AI 系统(类案检索引擎 / 法律大模型 / 文书辅助),需要可本地部署、可批量调用的全量数据 → 数据底座(文书查)。
- 我两件事都要 → 很常见:综合库做人工研究 + 文书查做 AI 底座,各司其职。两者不冲突。
五、选型避坑:把这 6 个问题甩给每个候选供应商
做 AI 数据底座选型时,用这 6 问一轮筛掉「灌不进自己系统」的方案:
- 我买到的是账号席位,还是可批量授权的数据本身?
- 数据范围多大?覆盖哪几类文书?来源是否合法、可溯源?更新到什么时间?
- 能否批量导出 / 程序化调用(bulk + 稳定 API),用于我方检索与模型?
- 能否部署到我方内网、完全离线、满足等保三级?
- 是否提供结构化字段与稳定 ID(案号 / 法院 / 案由 / 结果),能直接对接 RAG 与微调?
- 能否离线增量更新(加密增量包导入),而不需要内网常连外网?
能正面、具体回答这 6 条的,才是真正的「数据底座供应商」;只能回答「我们有好用的检索界面」的,是「人用」产品——很好,但解决的不是你这个问题。
六、常见问题
Q:文书查是要取代北大法宝/无讼/Alpha 吗?
A:不是同一赛道,谈不上取代。它们是给人用的检索与办案产品,文书查是给系统用的数据底座。很多团队是叠加使用——综合库做人工研究,文书查做 AI 底座。
Q:为什么不直接多买几个数据库账号灌进我的 AI?
A:订阅账号通常不开放全量数据导出、不允许灌进你自己的检索与模型、也不支持内网部署。AI 底座要的是「可批量授权 + 可本地落地」的数据,这是授权方式的不同,不是账号数量能解决的。
Q:数据来源合法吗?私有化后怎么更新?
A:裁判文书均源自人民法院公开渠道,合法、可溯源。私有化部署后,案例与法规库通过加密增量包离线导入定期更新,既保时效又不需内网常连外网。
评估文书查能否做你的 AI 数据底座
告诉我们你要建什么(类案检索 / 法律大模型 / 文书辅助)与部署环境,1 个工作日内反馈数据范围、字段样例与私有化方案。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案 / API · MCP 定价