用 AI 做法律工作的人，很容易从聊天框开始。

把合同拖进去。

把聊天记录贴进去。

把客户的问题复制进去。

然后问一句：

帮我分析一下。

这当然能用。

但用一段时间之后，问题会慢慢出现。

上一次确认过的审查口径，新会话不知道。

上一次读过哪些材料，自己也很难回溯。

模型生成了一段分析，但里面哪些来自材料，哪些来自推断，哪些还没有核验，不容易分清。

草稿改过几版，最后交付的是哪一版，也容易散在不同文件夹和聊天记录里。

所以我现在越来越觉得，法律人使用 AI，真正重要的不是多收藏几个 prompt。

而是先搭一个本地优先的 AI 工作区。

这不是一个隐私洁癖问题。

这是一个工作流问题。

Abstract

法律人的 AI 工作区应该本地优先。

这里的本地优先，不是说所有事情都只能离线完成，也不是排斥云服务和大模型 API。

它指的是：法律工作的核心材料、任务状态、来源边界、复核记录、交付草稿和经验沉淀，应该优先保存在自己可控的目录结构里，而不是只存在一次性聊天框、平台历史记录或零散网盘中。

这样做的价值有四个：

第一，材料可追溯。系统知道自己读过什么，也知道什么没读到。

第二，状态可延续。一个任务不会因为换了会话就从头开始。

第三，权限可分级。AI 可以读取、整理、标记和生成草稿，但正式判断和对外交付仍然由人确认。

第四，经验可沉淀。一次踩过的坑，下次可以变成规则、模板或 preflight 检查项。

我维护的 enterprise-legal-ops、legal-skills、法律 Wiki 和 agent-content-workspace，其实都是围绕这个方向展开的：把法律知识、业务材料、Agent Skill、内容表达和人工复核机制放回一个可运行、可复盘、可改造的工作区。

1. 为什么聊天框不够

聊天框适合快速提问。

但法律工作不是单次问答。

一项真实法律任务，通常会经历很多中间状态：

收到问题
  -> 确认任务类型
  -> 收集材料
  -> 读取材料
  -> 标记缺口
  -> 检索规则
  -> 形成初步分析
  -> 生成工作草稿
  -> 人工复核
  -> 修改草稿
  -> 出稿前检查
  -> 正式交付
  -> 归档和复盘

聊天框最大的问题，是它很难稳定承载这些状态。

它可以记住一段对话。

但它不天然知道：

  • 哪些文件是原始材料；
  • 哪些内容是 AI 摘要；
  • 哪些事实已经确认；
  • 哪些事实只是用户口述；
  • 哪些规则已经核验；
  • 哪些内容只是模型推断；
  • 哪个版本是草稿；
  • 哪个版本经过人工复核；
  • 哪个版本最终对外交付；
  • 哪些经验下次还要继续使用。

这些问题如果不被显式记录，就会变成隐形风险。

法律工作里，隐形风险比显性的错误更麻烦。

因为它常常看起来像是已经完成了。

2. 本地优先不是不用云，而是把主控权放回自己手里

本地优先容易被误解成“所有东西都不能上云”。

我不是这个意思。

大模型服务、云端协作、在线检索、知识库同步，都有它们的价值。

但法律工作有一个前提：材料、状态和交付边界不能完全依附在某个平台的界面里。

如果一个任务只存在聊天记录里，它就很难被审计。

如果一个文件只存在某次上传里，它就很难被复用。

如果一个结论只存在模型输出里，它就很难区分来源。

所以本地优先真正强调的是：

核心材料在本地有归档
任务状态在本地有记录
来源边界在本地有文件
草稿和终稿在本地分开
复核意见在本地留痕
经验规则在本地沉淀

云服务可以参与。

但工作区要能回到自己手里。

3. 一个法律 AI 工作区应该有什么

我会把一个最小可用的法律 AI 工作区拆成六层。

materials/      原始材料
workspace/      任务状态
sources/        来源边界
drafts/         工作草稿
review/         复核记录
delivery/       交付文件
learning/       经验沉淀

它不需要一开始就很复杂。

但每一层都要有明确职责。

materials：原始材料

materials/ 放原始文件。

比如：

  • 合同；
  • 补充协议；
  • 聊天记录；
  • 付款凭证；
  • 通知函；
  • 判决书；
  • 公司制度；
  • 员工资料；
  • 证照文件；
  • 章程和授权文件。

这一层的原则是：尽量不直接修改原始材料。

AI 可以读取，可以摘要，可以提取字段。

但原始材料本身应当保持可回溯。

workspace：任务状态

workspace/ 记录这个任务当前处在什么阶段。

例如：

task-brief.md
material-checklist.md
missing-info.md
timeline.md
issue-list.md
current-status.md

这些文件看起来很朴素。

但它们解决的是一个很真实的问题：

今天做到哪一步，明天还能接上。

换一个 AI 会话，也还能接上。

换一个人复核，也能知道前面发生过什么。

sources：来源边界

sources/ 是法律 AI 工作区里最重要的一层。

它负责记录：

哪些事实来自原始材料
哪些事实来自用户口述
哪些规则来自法规检索
哪些内容来自法律 Wiki
哪些内容还没有核验
哪些只是初步推断

没有来源边界，模型很容易把“看起来合理”的东西写成“已经确认”的事实。

法律工作不能只看文字是否顺。

还要看每一个判断能不能回到材料和规则。

drafts：工作草稿

drafts/ 放 AI 参与生成的工作草稿。

比如：

  • 合同审查清单；
  • 法律咨询回复草稿；
  • 起诉状初稿；
  • 代理词草稿；
  • 制度审查意见；
  • 风险提示清单；
  • 客户沟通稿。

这一层必须明确：

草稿不是正式交付。

AI 可以帮助生成草稿，但草稿要进入复核流程。

review：复核记录

review/ 放人工复核和出稿前检查记录。

比如：

source-check.md
legal-basis-check.md
privacy-check.md
delivery-preflight.md
human-review-notes.md

很多法律工作真正出问题，不是在“写不出来”。

而是在“写完就发出去”。

复核记录的作用，是让正式交付前多一道停顿。

delivery：交付文件

delivery/ 放最终对外版本。

它应该和草稿分开。

比如：

delivery/
  contract-review-final.docx
  consultation-reply-final.md
  complaint-final.docx
  client-memo-final.pdf

这样做有一个好处：

你永远知道哪个版本是工作稿，哪个版本是最终稿。

learning：经验沉淀

learning/ 记录这次任务留下的经验。

比如：

  • 哪类事实最容易漏；
  • 哪类材料下次要提前索要；
  • 哪类表达不适合对外；
  • 哪个法规引用需要特别核验；
  • 哪个模板需要修改；
  • 哪个 Skill 的规则要补充。

复盘不是情绪总结。

它是下一次工作的输入。

4. 这和我的几个开源项目是什么关系

我现在维护的几个项目，其实都在回答同一个问题：

法律人的 AI 工作区到底应该怎么组织。

enterprise-legal-ops 更关注企业法务和长期法律事务管理。

项目地址：

https://github.com/pa1nrui1/enterprise-legal-ops

官网项目页：

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

它处理的是合同、制度、证照、公章、章程权限、股东出资、提醒事项和本地问库。

这些内容最怕散。

散在网盘里，AI 不知道哪个是当前版本。

散在聊天记录里，后续很难接续。

散在个人记忆里，换人就断。

所以 enterprise-legal-ops 的核心是把资料、状态、权限和提醒沉淀成一个本地优先的 Legal Ops 工作台。

legal-skills 更关注具体法律任务怎么执行。

项目地址：

https://github.com/pa1nrui1/legal-skills

官网项目页：

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

它把法律咨询、合同审查、诉讼、刑辩、劳动争议、法规案例检索和文书交付拆成可路由、可复核、可接管的 Skill。

如果说本地工作区回答“材料和状态放在哪里”，那么 legal-skills 回答“任务应该怎么走”。

法律 Wiki：知识来源层

法律 Wiki 是知识底座。

入口：

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

它不是法律意见库。

它负责把法条、司法解释、争议点、证据审查提示和人工复核提醒整理成结构化知识。

本地工作区里的 sources/ 层，可以把法律 Wiki 作为来源之一，但不能把 Wiki 内容直接等同于个案结论。

规则需要回到具体事实。

事实需要回到具体材料。

agent-content-workspace：公开表达层

agent-content-workspace 处理的是另一类工作：法律人的公开表达和个人 GEO。

项目地址：

https://github.com/pa1nrui1/agent-content-workspace

官网项目页：

https://www.panrui.xyz/projects/agent-content-workspace/

它和法律业务看起来不同，但底层逻辑一样：

先把定位、内容主线、平台规则、文风、隐私边界和复盘机制放进工作区，再让 AI 参与选题、草稿、平台改写和发布检查。

法律人做内容，也需要本地优先。

因为公开表达同样有来源、隐私、事实核验和长期主线。

5. 可以从一个最小目录开始

不需要一开始搭很大的系统。

如果今天就要开始，我建议从这个目录开始：

case-workspace/
  README.md
  materials/
  workspace/
    task-brief.md
    material-checklist.md
    missing-info.md
  sources/
    source-boundary.md
    legal-basis-check.md
  drafts/
  review/
    preflight.md
    human-review-notes.md
  delivery/
  learning/
    notes.md

README.md 只需要回答几个问题：

这个工作区处理什么任务？
材料范围是什么？
哪些内容不能公开？
AI 可以做哪些动作？
哪些动作必须人工确认？
正式交付文件放在哪里？

source-boundary.md 可以很简单：

# Source Boundary

## 已读取材料

- 

## 已确认事实

- 

## 用户口述但未核验

- 

## 模型推断

- 

## 待补充材料

- 

## 待核验规则

- 

## 不得对外交付的内容

-

这个模板不复杂。

但只要坚持使用，就能明显减少“看起来完成了”的错觉。

6. 本地优先的三个常见误区

误区一：目录越复杂越专业

不是。

目录结构的价值不在于看起来完整，而在于它能不能帮助你稳定完成任务。

如果一个目录长期不用，就应该删掉。

如果一个文件每次都会用，就应该放到更显眼的位置。

本地工作区不是档案馆。

它是工作台。

误区二：所有信息都要塞给 AI

也不是。

本地优先的好处，不是把所有材料一次性塞进上下文。

而是让 AI 能按需读取。

永远要看的规则，放在入口文件。

可能要查的内容，放在子目录。

原始材料保留在材料层。

这和 Harness Engineering 里的上下文分层是同一个逻辑。

上下文不是越大越好。

上下文要能被组织。

误区三：有了工作区就可以放心交给 AI

更不是。

工作区只是让 AI 的参与变得可控。

它不能代替专业判断。

正式法律意见、对外文件、诉讼策略、重大商业选择、用印签署、解除处理、客户沟通边界，都必须由律师、企业法务或相关负责人确认。

本地优先不是为了让人退出流程。

它是为了让人更容易接管流程。

7. 我的判断

法律人使用 AI 的路径，大概会经历三个阶段。

第一阶段，是 prompt。

让 AI 回答得更好。

第二阶段，是 Skill。

让 AI 按固定流程做一类任务。

第三阶段，是工作区。

让材料、状态、来源、复核、交付和复盘长期留在一个可控系统里。

我现在更关心第三阶段。

因为法律工作不是只要“这一次写得不错”。

它需要下一次还能接上。

换一个任务还能复用。

换一个人还能看懂。

出了问题还能追溯。

这就是为什么我认为，法律人的 AI 工作区应该本地优先。

不是为了把 AI 关起来。

而是为了让 AI 真正进入一套可复核、可接管、可长期运转的法律工作系统。