法律工作者用 AI,最容易遇到的不是“模型不会写”。

恰恰相反,模型往往很会写。

它能把一段咨询整理成回复,把合同风险写成清单,把案件材料改成报告,把法律文书写得像那么回事。

真正麻烦的是另一件事:

哪些事情可以交给 AI 先做?

哪些事情只能让 AI 做草稿?

哪些事情必须由律师或企业法务确认之后才能继续?

如果这个边界没有设计好,AI 越能干,风险反而越不容易被看见。

legal-skills 是我为中国法律工作者设计的一套开源 Agent Skills 项目。这里的法律工作者,既包括律师,也包括企业法务、合规人员和需要长期处理法律材料的团队。

它的核心不是让 AI 直接替人完成法律判断,而是把法律工作拆成一个个 workflow 节点,再用工程化方式把这些节点串起来:哪些节点可以自动执行,哪些节点需要复核,哪些节点必须由人确认,哪些节点只能停下来提示风险。

换句话说,它关注的不是“AI 能不能回答法律问题”。

它关注的是“人和 AI 如何一起完成一项法律工作”。

Abstract

legal-skills 是一套面向中国法律工作的本地化 Agent workflow 系统。它以 法律工作总控 为统一入口,把法律咨询、诉讼、刑辩、劳动争议、破产、合同、产品法务、监管合规、法规案例检索和文书交付拆解为可路由、可复核、可接管的 Skill。

这个项目的设计重点有三个:

第一,用工程化思维拆解法律工作,把“一个任务”拆成任务识别、材料读取、来源标注、法规校验、业务分析、草稿生成、出稿审查、正式导出等节点。

第二,做人机权限分级,让 AI 参与低风险和中间过程,把正式判断、授权选择、对外交付和高风险结论保留给律师或企业法务。

第三,构建本地化工作台,把业务文件、系统记录、来源验证、缺口归档、OCR 校正、客户台账和文书模板放在可控的本地工作区,而不是散落在一次性对话里。

在这三点之上,legal-skills 还能覆盖一批真实法律工作:咨询回复、案件材料分析、合同审查与起草、诉讼文书、刑事辩护流程、劳动争议、破产程序、产品法务、广告合规、监管监测、法规案例检索和正式文书导出。

它更像一个可以被律师和企业法务改造的基础工作台,而不是一个封闭产品。

1. 为什么法律 AI 需要人机协同设计

法律工作不是一个单纯的文本生成问题。

它通常同时包含事实、证据、规则、期限、授权、程序、身份、格式和交付对象。

同一句“帮我看看这个合同”,可能包含几种完全不同的任务:

  • 只是快速判断几个明显风险。
  • 需要完整审查合同结构和交易安排。
  • 需要按甲方、乙方或中立立场出具意见。
  • 需要生成可交付的审查报告。
  • 需要输出带真实修订痕迹和批注的 Word 红线稿。
  • 需要把续约、付款、解除、违约等事项写入本地台账。

这些任务看起来都叫“合同审查”,但权限等级完全不同。

让 AI 摘要合同,和让 AI 直接修改合同正文,不是同一类动作。

让 AI 标记风险,和让 AI 代表律师形成正式法律意见,也不是同一类动作。

所以 legal-skills 不把 AI 设计成一个万能回答者。

它更像一个法律工作台里的协作成员:可以读材料、整理结构、提出缺口、生成草稿、执行格式检查,但不能越过权限边界替代最终判断。

2. 如何运用工程化思维

工程化思维的第一步,是不要把“法律工作”看成一个大任务。

要把它拆成节点。

legal-skills 里,一个任务通常不会直接从用户问题跳到最终结论,而是被拆成类似这样的流程:

任务进入
  -> 语义路由
  -> 事项与工作区确认
  -> 材料读取
  -> 关键数据提取与校验
  -> 来源边界记录
  -> 法规/案例校验
  -> 业务 Skill 分析
  -> 工作草稿
  -> 人工复核或用户确认
  -> 出稿前审查
  -> 正式导出或交付

这个流程不是为了增加仪式感。

它解决的是法律工作里最容易失控的几个问题。

2.1 先路由,不急着回答

法律工作总控会先判断任务应该进入哪个 Skill。

比如:

  • 快速咨询,进入 法律咨询助手
  • 民事案件流程,进入 民事一审诉讼
  • 刑事案件阶段判断,进入 刑事辩护总调度
  • 劳动仲裁、一审、二审,进入 劳动争议诉讼
  • 合同审查或起草,进入 合同审查合同起草
  • 产品上线、营销物料、隐私数据,进入 产品法务 或相关合规 Skill。
  • 正式 Word 文书,进入 法律文书出稿前审查法律文书模板与导出

路由的价值在于:同一个自然语言请求,会被放进具体工作场景,而不是靠模型临场发挥。

2.2 先读材料,再做判断

法律工作总控要求,涉及文件、网页、法规、案例或 Wiki 时,必须先完成读取和记录。

读取不是简单总结。

它要回答:

  • 实际读了哪些文件。
  • 覆盖范围是什么。
  • 关键日期、金额、主体、案号、条款、证据是什么。
  • OCR 是否存疑。
  • 哪些材料没读到。
  • 哪些事实还需要用户确认。

这一步把“模型好像看过材料”变成“系统知道自己读了什么”。

2.3 把来源边界做成系统记录

法律输出里最危险的情况,是把不同来源混在一起。

文件原文、用户口述、模型推理、法规检索、案例检索、Wiki 内容、网页搜索结果,它们的可信度和用途都不一样。

legal-skills 会要求在正式输出前形成来源边界记录,区分:

  • 已核验内容。
  • 未核验内容。
  • 材料缺口。
  • 输出边界。
  • 需要律师或法务判断的事项。

这不是免责声明。

这是工作流的一部分。

2.4 让交付进入质量门

很多法律工作真正出问题,不是在“写不出来”,而是在“写完就交付”。

legal-skills 把正式交付拆成更细的链路。

普通 Word 文书大致是:

业务 Skill 生成 draft.html
  -> preflight-meta.json
  -> 法律文书出稿前审查
  -> draft_checked.html
  -> html_to_docx.py
  -> health_check.py

要素式起诉状可能是:

complaint-data.json
  -> fill-plan.json
  -> DOCX 母版克隆填充
  -> 模板克隆质控报告
  -> health_check.py

合同红线稿则会先生成 redline-plan.json,再由脚本在 Word 中生成真实修订痕迹和批注,并输出执行日志和 QA 报告。

工程化的重点不是把流程做复杂。

而是让每个关键动作都有输入、有输出、有记录、有检查。

3. 如何进行权限分级

人机协同的核心,是权限分级。

不是所有节点都应该交给 AI。

我在 legal-skills 里默认把权限分成四层。

L1:读取与整理
L2:分析与标记
L3:草稿与执行
L4:确认与正式交付

L1:读取与整理

这一层适合让 AI 多做。

例如:

  • 整理材料清单。
  • 摘要合同结构。
  • 提取主体、金额、日期、期限、案号。
  • 将聊天记录、合同、判决书、通知、票据等材料按类型归档。
  • 生成读取复查摘要。
  • 标记 OCR 存疑处。

这一层的输出不直接形成法律结论,而是帮助律师或法务更快看清材料。

风险相对可控。

L2:分析与标记

这一层可以让 AI 参与,但必须保留来源和边界。

例如:

  • 标记合同风险。
  • 提出证据缺口。
  • 梳理争议焦点。
  • 列出法规检索方向。
  • 做初步请求权分析。
  • 生成监管合规缺口清单。
  • 识别产品上线或营销文案中的高风险点。

这一层的关键,是不要把 AI 的判断包装成最终结论。

它应该写清楚:基于什么材料,哪些已经核验,哪些只是初步判断,哪些需要进一步检索或人工确认。

L3:草稿与执行

这一层可以让 AI 生成草稿或执行工程动作,但不能直接视为正式成果。

例如:

  • 起草法律服务建议书草稿。
  • 生成起诉状、答辩状、代理词、合同审查意见的初稿。
  • 生成 redline-plan.json
  • 生成语义 HTML。
  • 根据已审查通过的输入导出 Word。
  • 生成图表预览稿或工作稿。

这里的边界是:AI 可以把工作推进到“可复核的草稿”,但不能把草稿自动升级为正式交付。

L4:确认与正式交付

这一层必须由人接管。

包括:

  • 是否采用某个诉讼策略。
  • 是否确认金额、期限、诉请、授权范围和审查立场。
  • 是否引用某条法规或某个案例作为正式依据。
  • 是否把报告、文书、红线稿或图表作为客户/法院/团队正式材料。
  • 是否写入系统记录、日历、云文档或其他外部系统。
  • 是否对外发送。

legal-skills 的很多门禁,都是围绕 L4 设计的。

比如,正式 .docx 必须先过出稿前审查;修订稿必须保留原件、另存红线稿并通过结构检查;涉及法规时不得用模型记忆替代核验;当前事项不匹配时不得在临时目录里生成正式交付。

权限分级的目的,不是削弱 AI。

而是让 AI 在正确的层级发挥作用。

4. 如何构建本地化工作台

法律工作者不能只靠一个聊天窗口处理长期事项。

因为真实工作里会有持续变化的材料、版本、台账、期限、复核记录、交付文件和系统记录。

legal-skills 的本地化工作台设计,核心是把业务文件和系统记录分开。

【自定义工作目录】/
├── 产品法务/
├── 监管合规/
├── 合同/
├── 劳动合规/
├── 诉讼/
│   ├── 民事/
│   └── 刑事/
└── _系统记录/
    ├── 当前事项.md
    ├── 总索引.md
    ├── 诉讼案件总览.md
    └── 案件复盘台账说明.md

这个结构有三个用处。

4.1 业务文件区给人看

业务文件区放用户可见、便于查找和交付的内容。

例如合同事项下可以有:

合同/
  <客户或项目>/
    <合同编号-合同简称>/
      01-客户材料/
      02-工作版本/
      03-交付文件/
      04-最终版/

民事诉讼事项下可以有:

诉讼/
  民事/
    <客户或委托人>/
      <案件简称或案号>/
        01-客户材料/
        02-证据材料/
        03-法律分析/
        04-诉讼文书/
        05-庭审材料/
        06-法院文书/
        07-交付文件/
        08-归档/

企业法务场景里,也可以按劳动合规、产品法务、监管合规长期维护。

这让律师和企业法务不必每次重新解释“文件放在哪里、哪个是最终版、哪个是客户材料”。

4.2 系统记录区给 Agent 和复核使用

系统记录区不放正式交付文件。

它放的是工作过程:

  • 当前事项。
  • 材料清单。
  • 来源验证记录。
  • 读取复查摘要。
  • OCR 校正记录。
  • 缺口归档。
  • 事实时间线。
  • 程序时间线。
  • 期限台账。
  • 版本记录。
  • 工作笔记。

这部分内容很适合 Agent 读取,因为它不是对外展示的成果,而是协作过程中的上下文。

它解决的是一个长期问题:AI 不应该靠记忆理解当前案件或当前合同,而应该读取本地工作台里的记录。

4.3 本地化意味着可替换和可控

不同律师、法务团队和企业的工作方式不一样。

有的团队以合同为中心。 有的团队以诉讼案件为中心。 有的团队以企业客户长期合规档案为中心。 有的团队需要接入法规数据库、OCR、云文档、日历或内部审批。

所以 legal-skills 不把本地路径、客户台账、真实材料、凭证和身份信息写死在公开仓库里。

它保留配置边界,让使用者在自己的机器、自己的团队规范、自己的权限体系里改造。

这也是我认为法律 AI 更适合从本地工作台开始的原因。

法律工作有太多材料、版本和权限边界。把这些东西全部放进一次性对话里,系统很难稳定;把它们组织成本地工作区,Agent 才有可读取、可追踪、可复核的上下文。

5. 这个项目能做哪些工作

legal-skills 不是围绕某一个单点功能设计的。

它更像一组面向中国法律工作场景的 workflow 模块。

5.1 咨询与案件材料整理

它可以帮助律师或法务把零散信息先整理成可处理的工作输入。

例如:

  • 处理客户咨询,先输出聚焦追问和初步风险提示。
  • 制作案件沟通记录。
  • 读取合同、判决书、通知、聊天记录、票据、图片、表格等材料。
  • 提取主体、金额、日期、案号、期限、证据和争议焦点。
  • 形成读取复查摘要和材料缺口清单。

这类工作适合放在权限分级的 L1 和 L2。

它的价值不是替人判断,而是让法律工作者更快掌握材料全貌。

5.2 民事诉讼、刑事辩护和劳动争议

法律工作经常不是一次性回答,而是按阶段推进。

legal-skills 里有面向民事一审、刑事辩护、劳动争议的流程型 Skill。

它可以辅助:

  • 判断案件当前阶段和下一步工作。
  • 整理立案、庭前、庭审、庭后、调解、结案归档等节点。
  • 在刑事案件中按侦查、审查起诉、一审、二审、未成年人、死刑案件、特殊程序等场景分流。
  • 在劳动争议中处理仲裁程序、证据体系、劳动关系认定、经济补偿、加班费、双倍工资等事项。
  • 维护程序时间线、期限台账、传票通知和案件简报。

这类能力对律师的意义,是减少重复流程管理成本。

对企业法务的意义,是让争议案件和日常合规档案可以互相衔接。

5.3 合同审查、合同起草和交易支持

合同是最适合做人机协同的法律工作之一。

因为它既有大量可结构化内容,也有必须由人判断的商业立场。

legal-skills 可以支持:

  • 读取合同结构和关键条款。
  • 确认审查立场:甲方、乙方或中立。
  • 输出风险等级、修改建议和需确认问题。
  • 生成审查问题清单。
  • 在用户需要时生成 redline-plan.json
  • 通过脚本生成带真实修订痕迹和批注的 Word 红线稿。
  • 做红线 QA,检查修订、批注、关系文件和执行日志。
  • 支持合同起草、模板选择、多轮修订、最终版确认和续约提醒。

这里的人机分工很清楚:

AI 负责读、拆、标、生成和执行部分格式化动作。

律师或法务负责确认立场、判断交易风险、决定条款让步、确认最终文本。

5.4 企业法务、产品法务和监管合规

企业法务的工作不是一个案件结束就归档。

它更像一个长期维护的内部系统。

legal-skills 可以用于:

  • 员工手册、规章制度、劳动合同、薪酬工时和考勤制度的合规检查。
  • 公司端辞退、调岗、降薪、处罚、员工投诉等争议前风险预判。
  • 产品上线前的 PRD、页面流程、用户协议、隐私政策、帮助中心和营销材料审查。
  • 客户 Logo、客户案例、产品卖点、广告素材等对外材料合规初筛。
  • 金融、医疗、教育、AI、平台、电商、直播、未成年人、数据权限等高合规场景的风险分流。
  • 监管动态、新规更新、客户合规缺口、整改清单和政策制度修改建议。

这类场景里,AI 的价值不是替企业法务拍板。

它更适合做信息归集、材料读取、缺口标记、版本记录和出稿前检查。

企业法务最后需要的不是一段回答。

它需要一个能长期维护的 legal ops workspace。

5.5 法规案例检索、文书交付和格式质控

法律服务很大一部分工作,最终会落到可交付成果。

legal-skills 可以支持:

  • 法规、案例、裁判规则、类案汇编和检索报告。
  • 起诉状、答辩状、代理词、质证意见、保全申请等诉讼文书。
  • 诉讼可视化图表、法律关系图、时间轴、争点树和证据链图谱。
  • 法律服务建议书、咨询报告、非诉方案、沟通报告。
  • 正式 Word 文书导出。
  • 要素式起诉状 DOCX 母版克隆填充。
  • 出稿前审查、结构检查和导出健康检查。

这部分能力会直接影响服务交付质量。

因为法律工作者不只需要“内容正确”,还需要“过程可查、格式可交付、版本可追踪”。

6. 它如何为法律工作者提供更好的服务

这里的“更好的服务”,不是指 AI 替律师或法务作出最终判断。

而是把服务过程做得更稳定。

6.1 更快进入工作状态

很多法律任务的第一步不是写结论,而是把材料整理清楚。

legal-skills 可以先帮助完成材料清单、关键字段提取、事实时间线、程序时间线和缺口提示。

这让律师或法务不必每次从一堆文件里重新定位重点。

6.2 更少遗漏关键节点

诉讼、劳动、合同、产品法务和监管合规都有大量流程节点。

人忙的时候,很容易漏掉期限、授权、审查立场、材料缺口、格式要求和来源核验。

legal-skills 把这些节点写进 workflow,让 Agent 在合适的地方提醒、阻断或退回补充。

6.3 更容易复核和交接

好的法律服务不能只看最后一份文档。

还要能看见过程:

  • 材料从哪里来。
  • 哪些事实已经确认。
  • 哪些法规已经校验。
  • 哪些风险只是初步判断。
  • 哪些事项需要客户或内部负责人确认。
  • 哪个版本是草稿,哪个版本是交付稿。

本地工作台和系统记录区的意义,就在这里。

它让复核和交接不再完全依赖口头说明或聊天记录。

6.4 更适合长期客户和团队服务

律师和企业法务都不是只处理一次性问题。

长期客户会有合同、争议、劳动、产品、监管、制度和历史版本。

企业内部也会有很多跨部门协作和审批节点。

legal-skills 的本地化结构,让这些信息可以持续沉淀,而不是每次开一个新对话重新开始。

6.5 更清楚地划定责任边界

法律服务里,边界本身就是质量。

AI 做了什么,人确认了什么,哪些内容未核验,哪些结论不能直接对外使用,都应该被明确记录。

这对律师是执业风险控制。

对企业法务是内部合规管理。

对团队协作是交付质量控制。

7. 如何简单安装

如果你使用支持本地 Markdown Skill 的 Agent 工具,可以先用最简单的方式安装入口 Skill。

方式一:通过 Skills CLI 安装

npx skills add https://github.com/pa1nrui1/legal-skills -l
npx skills add https://github.com/pa1nrui1/legal-skills --skill china-legal-skills

china-legal-skills 是公开入口 Skill。它会要求 Agent 先读取 skills/legal/法律工作总控/SKILL.md,把总控作为主路由和共享质量门,再进入具体中文子 Skill。

安装后,可以从这类指令开始:

法律工作总控 帮我判断这个任务应该走哪个法律工作流。
合同审查 审核这份合同,按风险等级输出修改建议。
产品法务 帮我检查这个产品上线材料的主要合规缺口。

方式二:作为普通 skills 目录安装

git clone https://github.com/pa1nrui1/legal-skills.git
mkdir -p ~/.codex/skills
rsync -a legal-skills/skills/legal/ ~/.codex/skills/legal/

这种方式更适合想本地查看、修改或逐步定制 Skill 的用户。

方式三:作为 Codex plugin 安装

codex plugin marketplace add pa1nrui1/legal-skills --sparse .codex-plugin --sparse skills

真实业务使用前,建议先配置自己的工作区路径、客户台账、身份占位、文书模板、法规检索、OCR 和团队审批权限。

不要把真实客户材料、案卷、API key、商业数据库凭证或本机私有路径提交到公开仓库。

8. 这个项目适合谁

legal-skills 更适合已经在真实工作中使用 AI 的法律工作者。

包括:

  • 律师个人或小团队。
  • 企业法务和合规团队。
  • 需要处理合同、诉讼、劳动、产品、监管材料的人。
  • 想把 AI 放进工作流,而不是只拿来问答的人。
  • 需要本地化、可审查、可改造工作台的人。

如果你只是偶尔让 AI 解释一个概念,它会显得太重。

如果你每天都在处理材料、合同、文书、合规问题、客户沟通和交付版本,它的价值会更明显。

9. 边界

legal-skills 不提供法律意见。

它提供的是 Agent workflow、Skill 规则、文书模板和本地脚本示例。

任何输出都应视为供律师、法务或合格专业人士复核的工作草稿。真实法律事项必须由专业人士基于完整事实、有效授权、现行法律、可核验来源和具体语境作出独立判断。

这个项目也不应该包含真实客户材料、案卷、API key、商业数据库凭证、本机私有路径或未经授权公开的信息。

它能做的是把法律工作里原本隐性的步骤显性化:谁来读材料,谁来确认事实,谁来核验规则,谁来判断风险,谁来决定交付。

这才是人机协同的关键。

不是让 AI 站到律师或法务的位置上。

而是让 AI 进入一个有权限、有记录、有复核、有边界的工作台。