最近经常有人问我一个问题：

律师想搭一套自己的法律 AI，工具到底该怎么选？

ChatGPT、Claude、DeepSeek、Kimi、Gemini、通义、豆包，大家多少都用过。

真到准备搭系统时，Codex、Claude Code、Kimi Code、Dify、扣子、百炼又冒出来。

名字越看越多。

但我觉得，这个问题不能从“哪个工具最好”开始。

要先问另一件事：

你到底想让 AI 参与法律工作的哪一层？

只是读一份合同，和长期整理案件材料，不是一回事。

只是回答一个咨询，和让它在本地工作区里持续生成材料清单、缺口记录、审查草稿和复核记录，也不是一回事。

工具选择真正要解决的，不是买哪一个会员。

而是把不同工具放回各自的位置。

Abstract

律师搭法律 AI，不应该一开始就纠结模型排名或工具榜单。

更稳妥的做法，是先把工具分成五层：

  • Chatbot：处理日常问答和单次任务。
  • 项目空间：把同一事项的文件、说明和对话放在一起。
  • Agent 工作环境：让 AI 在本地或云端工作区里读取文件、修改文件、运行命令、调用工具。
  • Agent 搭建平台：把模型、知识库、流程、插件和外部服务组合成可给团队使用的应用。
  • 模型和 API：提供底层理解和生成能力，可以被 Chatbot、Agent 工作环境或平台调用。

这五层不是谁替代谁。

它们解决的问题不同。

律师真正要做的，是先判断自己的任务处在哪一层，再决定用什么工具，而不是把所有工具都订一遍。

法律 AI 的核心也不是“工具越多越好”。

核心是让材料、任务状态、来源边界、权限边界和人工复核进入同一套工作系统。

1. 先从 Chatbot 开始，而不是先搭系统

如果只是日常问答和单次任务，Chatbot 就够了。

比如：

  • 让 AI 摘要一份已经脱敏的合同。
  • 让 AI 从一段咨询里列出待补充事实。
  • 让 AI 改写一段法律文书表达。
  • 让 AI 帮你整理一个初步问题清单。

ChatGPT、Claude、DeepSeek、Kimi、Gemini、通义、豆包，这些都可以作为日常入口。

这一层的价值，是门槛低。

你可以很快拿一个真实任务测试：模型能不能读懂材料，能不能发现缺失事实，能不能把问题拆开，能不能避免过早下结论。

如果一个律师还没有稳定使用 AI 的习惯，我不建议一开始就搭复杂系统。

先选一个自己用得顺手的 Chatbot，把一个真实任务跑通。

这比研究十个工具更重要。

但 Chatbot 的边界也很明显。

它更适合围绕对话组织工作。

案件一多，材料容易散在不同聊天里；审查口径、输出对象、复核要求、历史版本也需要反复交代。

所以 Chatbot 适合开始，不适合承载整个法律工作系统。

2. 一个事项要持续处理，就进入项目空间

当一个任务不再是一次性问答，而是要持续处理，就可以考虑项目空间。

ChatGPT Projects、Claude Projects 这一类功能，都会把文件、项目说明和对话放在相对独立的空间里。

对律师来说，它更像一个轻量案件或事项工作夹。

你可以把同一事项的材料放在一起，再写清楚：

  • 审查立场。
  • 输出对象。
  • 常用格式。
  • 风险偏好。
  • 已有材料。
  • 不得直接下结论的事项。

这样以后继续讨论时，不必每次重新上传全部文件，也不必每次从头解释背景。

项目空间适合几类场景：

  • 一个合同审查事项需要多轮修改。
  • 一个咨询事项需要持续补充材料。
  • 一个专题研究需要反复问答。
  • 一类固定任务需要保持统一口径。

但它仍然主要解决“文件和对话如何集中”的问题。

它不一定适合处理更复杂的本地文件流转，也不一定能稳定承担版本管理、批量处理、命令执行、Word 导出、系统记录和多工具调用。

换句话说，项目空间比聊天框更稳。

但它还不是完整的法律 AI 工作台。

3. AI 要处理文件和流程，就需要 Agent 工作环境

如果你希望 AI 不只是回答，而是持续处理一个工作区，就要进入 Agent 工作环境。

Codex、Claude Code、Kimi Code 这类工具，本来更多面向代码和工程任务。

但它们的工作方式，对法律 AI 很有启发：

  • 可以读取一个工作区里的多个文件。
  • 可以按照长期规则执行任务。
  • 可以生成和修改本地文件。
  • 可以运行命令或调用工具。
  • 可以在一次任务中留下中间产物。
  • 可以让人审查它的修改。

法律工作如果被组织成材料、规则、模板、检查清单和交付文件，其实也需要这种能力。

比如一个案件材料工作区可以这样运行：

收到材料
  -> 识别任务类型
  -> 读取文件
  -> 生成材料清单
  -> 标记缺口
  -> 形成事实时间线
  -> 检索法规和案例
  -> 生成草稿
  -> 出稿前检查
  -> 人工复核
  -> 归档和复盘

如果只在 Chatbot 里完成这些步骤，很容易散。

如果放到 Agent 工作环境里，就可以把每一步变成文件、状态和记录。

这也是我更关注本地工作区的原因。

法律 AI 真正有价值的地方，不是单次回答，而是把材料、状态、来源、复核和交付放在一个可以持续运行的空间里。

4. 给团队使用时，再考虑 Agent 搭建平台

Dify、扣子、阿里云百炼这类平台，适合把模型、知识库、插件、工具和流程组合成一个应用。

它们更适合团队化、产品化或内部系统化的需求。

比如：

  • 律所希望多人使用同一个合同审查入口。
  • 企业法务希望员工通过一个统一入口提交咨询。
  • 团队希望把知识库、表单、审批、提醒和外部服务接在一起。
  • 开发者准备把法律 AI 做成网页、机器人或业务系统。

这类平台的优点，是更容易把流程发布出来。

但它们需要考虑的事情也更多：

  • 谁能访问。
  • 数据保存在哪里。
  • 知识库如何更新。
  • 模型费用如何控制。
  • 插件和 API 是否稳定。
  • 团队成员是否有不同权限。
  • 高风险输出如何进入人工复核。

个人律师刚开始测试需求时，不一定要直接走到这一步。

如果一个流程还没有在自己的真实工作里跑通，过早做成平台应用，很容易把不成熟的流程固化下来。

我的建议是：

先在个人工作区跑通。

再考虑团队平台化。

5. DeepSeek 和 Kimi 应该放在哪里

DeepSeek、Kimi 既可以是普通用户直接使用的 Chatbot，也可以通过 API 成为其他工作环境或 Agent 平台调用的模型。

这里最容易混淆的是模型和产品入口。

模型负责理解和生成内容。

Chatbot 提供直接对话入口。

Agent 工作环境让模型操作文件、命令和工具。

Agent 搭建平台负责把模型、知识库、流程和外部服务组合起来。

所以选择 DeepSeek 或 Kimi，不等于只能在聊天页面里使用。

它们可以作为底层模型能力，被接入其他系统。

但对律师来说，模型只是其中一层。

更关键的是模型周围有没有工作区、来源边界、权限控制、工具调用和人工复核。

没有这些，即使用很强的模型，也可能只是得到一段更顺滑的草稿。

而不是一套更可靠的法律工作流。

6. 可以用四个问题选工具

我建议律师选工具时，先问四个问题。

第一个问题：这是一次性任务，还是以后会反复使用？

一次性合同摘要、文书改写、简单咨询，用 Chatbot 就可以开始。

长期重复的合同审查、案件材料管理、文书交付和企业法务台账，就要考虑项目空间、Agent 工作环境或本地工作区。

第二个问题：AI 是否需要直接处理文件？

如果只是复制一段文字进去，Chatbot 足够。

如果需要 AI 持续读取文件夹、生成清单、保存中间结果、修改文档，就要关注工作区和文件操作能力。

第三个问题：是否需要连接其他工具？

法律 AI 很难只靠一个模型完成全部工作。

法规核验、OCR、录音转写、企业信息查询、Word 导出、日程提醒、案件台账，都可能需要外部工具。

平台是否支持 API、MCP、插件、脚本或其他连接方式，会直接影响后续扩展。

第四个问题：材料放在哪里，谁能看到？

这是法律人不能跳过的问题。

涉及客户材料、案件材料、合同文本、商业信息和个人信息时，必须单独核对数据保存方式、团队权限、部署位置、隐私条款和脱敏机制。

仅仅看到“支持本地部署”或“企业版”，不能直接等同于已经满足律师的保密要求。

工具能不能用，要放在具体材料、具体权限和具体交付场景里判断。

7. 我的选择顺序

如果刚开始，我会这样选。

第一阶段，先选一个熟悉的 Chatbot。

目标不是搭系统，而是确认真实任务是否适合 AI 参与。

比如拿一份已经脱敏的合同，看它能不能识别主体、期限、付款、违约、解除和待补充事实。

第二阶段，把反复出现的任务放进项目空间或本地工作区。

当你发现同一套要求已经反复使用，材料也开始变多，就不要再靠聊天记录管理工作。

这时应该把审查口径、材料清单、来源边界、草稿、复核记录和交付文件放进固定目录。

第三阶段，进入 Agent 工作环境。

当你需要 AI 读取多个文件、生成中间产物、运行命令、导出文档、调用工具，就可以使用 Codex、Claude Code、Kimi Code 这类 Agent 工作环境。

第四阶段，再考虑平台化。

如果流程已经稳定，且需要多人使用，再考虑 Dify、扣子、百炼等 Agent 搭建平台。

这样做的好处是，每一步都有真实需求支撑。

缺什么能力，再补什么工具。

而不是一开始就把所有工具都订一遍。

8. 和我的项目是什么关系

我维护的几个项目，正好对应不同层级。

legal-skills 处理法律任务怎么被拆成 Skill。

它关注的是咨询、合同、诉讼、刑辩、劳动争议、检索和文书交付这些具体任务如何进入可路由、可复核、可接管的流程。

项目页：

https://www.panrui.xyz/projects/legal-skills/

enterprise-legal-ops 处理本地工作台怎么组织。

它更关注合同、制度、证照、权限、提醒事项和本地问库，适合思考“AI 应该在哪些文件和台账里工作”。

项目页：

https://www.panrui.xyz/projects/enterprise-legal-ops/

法律 Wiki 处理知识来源层。

法律 AI 不能只靠模型记忆。它需要可追溯、可更新、可复核的知识底座，用来承载法规、司法解释、争议点、证据审查提示和人工复核提醒。

入口：

https://www.panrui.xyz/wiki/

这些项目不是在回答“买哪个工具”。

它们回答的是另一个问题：

法律工作怎样被组织成 AI 可以参与、但人仍然能够检查和接管的系统。

9. 资料说明

本文写作时参考了以下官方资料。AI 产品更新很快，具体功能、套餐、数据政策、模型列表和部署方式，应以实际使用时的官方页面为准。

结语

律师搭法律 AI，真正难的不是追一个模型排名。

而是判断自己到底需要哪一层工具。

单次任务，用 Chatbot。

持续事项，用项目空间。

文件和流程，用 Agent 工作环境。

团队应用，再考虑 Agent 搭建平台。

模型和 API，则是底层能力，不等于完整工作系统。

法律 AI 的核心不是把工具堆起来。

而是让材料、来源、权限、复核和交付进入同一套可运行、可检查、可接管的工作流。