我最近开源了一个项目：legal-skills。
GitHub： github.com/pa1nrui1/le…
它不是一个法律问答 bot，也不是一个 prompt collection。
我更愿意把它定义成：
面向中国律师和企业法务的本地 Agent workflow 项目。
它的目标不是让 AI 直接给出法律结论，而是把真实法律工作拆成一个个 workflow 节点，再用 Skill、模板、脚本和质量门串起来。
这篇文章从工程角度拆一下这个项目：
- 为什么要拆成 Skill
- 项目目录如何组织
- 总控路由怎么设计
- 人机权限如何分级
- 本地工作台怎么落地
- 正式交付为什么需要质量门
- 如何快速安装和使用
1. 为什么法律工作适合拆成 Agent Skill
法律工作看起来像文本工作。
但真实做起来，它不只是“写一段话”。
例如用户说：
帮我看看这个合同。
这句话可能对应很多完全不同的任务：
- 快速看明显风险
- 完整审查合同结构
- 按甲方 / 乙方 / 中立立场出具意见
- 生成审查问题清单
- 生成 Word 红线稿
- 提取续约提醒
- 更新合同台账
- 生成正式交付报告
这些任务的输入、权限、输出和风险都不一样。
如果只靠一个 prompt，很容易出现两个问题：
- 模型直接跳到结论，跳过材料读取、来源边界和法规校验。
- 草稿、内部报告、客户交付、法院材料、正式 Word 被混在一起。
所以我选择把法律工作拆成 Skill。
Skill 不是“提示词更长一点”。
它更像一个局部工作流：定义触发条件、输入要求、执行顺序、需要读取的参考文件、输出边界和失败处理。
2. 项目结构
当前仓库大致结构如下：
legal-skills/
├── SKILL.md
├── README.md
├── CHANGELOG.md
├── .codex-plugin/
│ └── plugin.json
└── skills/
└── legal/
├── 法律工作总控/
├── 法律咨询助手/
├── 民事一审诉讼/
├── 刑事辩护总调度/
├── 劳动争议诉讼/
├── 合同审查/
├── 合同起草/
├── 产品法务/
├── 监管合规监测/
├── 法规案例检索/
├── 诉讼文书起草/
├── 法律文书出稿前审查/
└── 法律文书模板与导出/
目前有：
- 58 个
SKILL.md - 267 个
references/文件 - 127 个
templates/文件 - 38 个
scripts/文件 - 多个围绕红线稿、模板克隆、出稿前审查、Word 导出的测试
这几个目录的分工是：
SKILL.md 负责触发条件、任务边界、执行顺序
references/ 负责完整流程、协议、方法论、路由表、边界规则
templates/ 负责文书、报告、清单、申请书等输出结构
scripts/ 负责把部分质量门落成可执行检查
assets/ 负责 profile、manifest、模板注册表等配置
checklists/ 负责风险清单、保密清单、阶段检查清单
这个结构的核心思路是：
入口轻，规则外置；业务拆分，门禁统一。
3. 入口 Skill：china-legal-skills
仓库根目录的 SKILL.md 是公开入口：
---
name: china-legal-skills
description: Chinese legal workflow skills for lawyers, legal counsel, litigation, criminal defense, labor disputes, bankruptcy, contract review, compliance, legal research, and legal document drafting.
---
它只做一件事：
先读取 skills/legal/法律工作总控/SKILL.md
也就是说，真正的主路由不是根目录 SKILL.md，而是 法律工作总控。
这样做的好处是：
- 对外入口保持简单。
- 中文法律工作规则集中在
skills/legal/。 - 后续可以适配 Codex、Claude Code、Qoder、OpenCode、OpenAI Skills 等支持本地 Markdown Skill 的 Agent 工具。
4. 法律工作总控：路由和共享质量门
法律工作总控 是整个项目最关键的部分。
它不是业务 Skill。
它负责所有 legal 子 Skill 的共享规则：
- 语义路由
- 事项隔离
- 文件读取复查
- OCR 存疑处理
- 法规 / 案例校验
- 来源边界
- 正式交付物分类
- 出稿前审查调度
- 本地工作区路径确认
一个典型流程是：
用户任务
-> 法律工作总控
-> 路由到具体业务 Skill
-> 读取材料与来源记录
-> 法规 / 案例校验
-> 业务分析或草稿生成
-> 出稿前审查
-> 文书导出或交付
总控的价值在于：
子 Skill 可以负责专业流程，但不能覆盖共享底线。
比如合同审查、诉讼文书、劳动争议、产品法务都不应该各自发明一套“材料读取”和“来源边界”规则。
这些规则应该统一在总控层。
5. 语义路由：不要让模型临场猜
法律任务经常很模糊。
同一句“这个案子怎么办”，可能是：
- 咨询回复
- 法律分析
- 证据缺口
- 诉讼文书
- 法规案例检索
- 案件管理
- 调解和解
- 结案归档
所以项目里有 routing-map.md，把自然语言任务映射到具体 Skill。
例如：
合同审查、合同审核、批注、修订建议
-> 合同审查
合同起草、生成合同、拟定协议
-> 合同起草
产品上线、功能合规、客户 Logo、客户案例
-> 产品法务
监管动态、新规更新、整改清单
-> 监管合规监测
起诉状、答辩状、代理词、质证意见
-> 诉讼文书起草
正式 Word / docx / 文书导出
-> 法律文书出稿前审查
-> 法律文书模板与导出
这能减少模型“看起来懂，但其实走错流程”的情况。
6. 人机权限分级：L1 到 L4
我在项目里默认用四层权限理解法律 AI：
L1：读取与整理
L2：分析与标记
L3：草稿与执行
L4：确认与正式交付
L1：读取与整理
适合 AI 多做：
- 整理材料清单
- 提取主体、金额、日期、案号
- 摘要合同结构
- 标记 OCR 存疑
- 生成读取复查摘要
L2：分析与标记
AI 可以参与，但要标注来源和边界：
- 合同风险标记
- 证据缺口
- 争议焦点
- 法规检索方向
- 初步请求权分析
- 监管合规缺口
L3：草稿与执行
AI 可以生成中间成果：
- 法律服务建议书草稿
- 起诉状 / 答辩状 / 代理词初稿
- 合同审查意见初稿
redline-plan.json- 语义 HTML
- 图表预览稿
L4：确认与正式交付
必须由人接管：
- 诉讼策略
- 金额、期限、诉请、授权范围
- 审查立场
- 正式引用法规和案例
- 是否对外发送
- 是否作为客户 / 法院 / 团队正式材料
这套分级的意义，是让 AI 能做事，但不能越权。
7. 本地工作台：业务文件区和系统记录区
法律工作不能只靠一次性对话。
需要长期维护：
- 材料
- 版本
- 台账
- 期限
- 来源验证
- 缺口归档
- 交付记录
- 复核记录
所以 legal-skills 设计了本地工作台结构。
简化后大概是：
自定义工作目录/
├── 产品法务/
├── 监管合规/
├── 合同/
├── 劳动合规/
├── 诉讼/
│ ├── 民事/
│ └── 刑事/
└── _系统记录/
├── 当前事项.md
├── 总索引.md
├── 诉讼案件总览.md
└── 案件复盘台账说明.md
业务文件区给人看：
合同/
<客户或项目>/
<合同编号-合同简称>/
01-客户材料/
02-工作版本/
03-交付文件/
04-最终版/
系统记录区给 Agent 和复核使用：
_系统记录/
合同/
合同索引.md
续约提醒总表.md
<客户或项目>/
<合同编号-合同简称>/
合同概览.md
业务摘要.md
来源验证记录.md
审查问题清单.md
综合审核意见.md
版本记录.md
修订历史.md
OCR校正记录.md
OCR文本/
这个结构的目的，是让 Agent 不靠“记忆”理解当前事项。
它应该读取本地工作台里的当前事项、材料清单、来源记录和版本记录。
8. 正式交付质量门
法律工作里，“写完”不等于“完成”。
尤其是正式文书、合同红线稿、客户报告、法院材料。
legal-skills 里有两个关键交付 Skill：
法律文书出稿前审查
法律文书模板与导出
普通 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
-> apply_redline_plan.py
-> 生成真实 w:ins / w:del 修订痕迹和批注
-> qa_redline.py
-> 输出执行日志和 QA 报告
这里的重点不是“能导出 Word”。
重点是正式交付前必须知道：
- 材料是否读取
- 法规是否校验
- 来源边界是否记录
- 用户确认是否存在
- 模板是否匹配
- DOCX 结构是否健康
- 是否只是草稿
9. 项目能覆盖哪些法律工作
当前项目覆盖的主要方向包括：
法律咨询与材料整理
民事诉讼
刑事辩护
劳动争议
破产程序
合同审查与起草
企业劳动合规
产品法务
广告合规
预包装食品标签合规
监管合规监测
法规案例检索
诉讼文书起草
诉讼可视化
正式 Word 文书导出
对律师来说，它可以减少重复的流程管理、材料整理和文书前置工作。
对企业法务来说，它可以沉淀合同、劳动、产品、监管、制度、续约和整改的长期工作台。
对团队来说，它能让复核和交接更清楚：
- 谁读取了材料
- 哪些事实已经确认
- 哪些法规已经校验
- 哪些事项还需要补充
- 哪个版本是草稿
- 哪个版本可以交付
10. 快速安装
方式一：通过 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
方式二：作为普通 skills 目录安装
git clone https://github.com/pa1nrui1/legal-skills.git
mkdir -p ~/.codex/skills
rsync -a legal-skills/skills/legal/ ~/.codex/skills/legal/
方式三：作为 Codex plugin 安装
codex plugin marketplace add pa1nrui1/legal-skills --sparse .codex-plugin --sparse skills
安装后可以这样开始：
法律工作总控 帮我判断这个任务应该走哪个法律工作流。
合同审查 审核这份合同，按风险等级输出修改建议。
产品法务 帮我检查这个产品上线材料的主要合规缺口。
真实业务使用前，建议配置自己的工作区路径、客户台账、身份占位、文书模板、法规检索、OCR 和团队审批权限。
11. 边界
legal-skills 不提供法律意见。
它提供的是 Agent workflow、Skill 规则、文书模板和本地脚本示例。
任何输出都应视为供律师、法务或合格专业人士复核的工作草稿。真实法律事项必须由专业人士基于完整事实、有效授权、现行法律、可核验来源和具体语境作出独立判断。
公开仓库也不应该包含真实客户材料、案卷、API key、商业数据库凭证、本机私有路径或未经授权公开的信息。
这个项目的核心，不是让 AI 站到律师或法务的位置上。
而是把 AI 放进一个有权限、有记录、有复核、有边界的本地工作台。
原文首发： www.panrui.xyz/writing/leg…
项目地址： github.com/pa1nrui1/le…
官网项目页： www.panrui.xyz/projects/le…
