我是怎么设计法律skill的

做了大半年法律 AI 工具，我把整套方法论沉淀成了一个 Skill 体系，跑在 Claude Code 上面。

干的就是一件事，把法律工作流拆成一个个 Skill，用自动路由串起来，让 AI 像个有经验的律师助理那样干活，该查证据查证据，该写代理词写代理词，该校格式校格式，每一步都有章法。

但光有 Skill 还不够。Skill 只是能力单元，你还需要一个大脑来调度它们，需要一群干活的手脚来执行，需要一套兜底机制来防止 AI 犯浑，还需要一个进化系统让整套东西越用越好。

这篇文章就把这几层一层一层拆开聊。

一、法律场景的特殊性

先说为什么要专门做一套，通用的方案搬过来不行吗？

不太行。法律工作有几个地方跟别的场景差别很大：

归结下来，法律 AI 要做好四件事：

1. 1. 输出必须标来源，每条事实从哪来的，可信度多高，得写清楚
2. 2. 流程不能跳，材料没校验就别急着梳理事实，事实没理清就别急着写代理词
3. 3. 多个信息源要交叉验证，案卷说的、企查查查到的、法条规定的，得对得上
4. 4. 格式必须严格，代理词、合同、法律意见书，格式错了就不专业

想明白这四件事，后面的设计就顺了。

二、整体架构

五层，从上到下：

┌─────────────────────────────────────────────────────────┐
│  顶层规则（Claude.md）                                    │
│  → 定义角色、调度逻辑、文件结构，整个系统的大脑            │
├─────────────────────────────────────────────────────────┤
│  自动路由 + Skill 体系（40 多个法律 Skill）               │
│  → 用户说自然语言，系统匹配 Skill，每个 Skill 干一件事    │
├─────────────────────────────────────────────────────────┤
│  执行系统（Sub-agents）                                   │
│  → 主 Agent 调度，子 Agent 干活，彼此隔离互不污染          │
├─────────────────────────────────────────────────────────┤
│  Hooks 机制                                              │
│  → 质量兜底，AI 忘了的事 Hooks 替它记着                   │
├─────────────────────────────────────────────────────────┤
│  进化系统                                                │
│  → 反馈收集 → 规则毕业 → Skill 优化 → Skill 创建         │
└─────────────────────────────────────────────────────────┘

底下还有一层贯穿所有环节的「证据级输出标准」，后面单独讲。

文件结构长这样：

.claude/
├── claude.md                    # 顶层规则，系统大脑
├── evolution.md                 # 进化规则
├── settings.json                # Hooks 配置
├── rules/
│   └── auto-trigger.md          # 路由规则
├── skills/
│   ├── litigation-caseflow/     # 诉讼一体化流程
│   ├── contract-review/         # 合同审查
│   ├── risk-scan/               # 风险扫描
│   ├── evidence-locator/        # 证据定位
│   └── ...                      # 40+ 法律 Skill
├── agents/
│   ├── implementer.md           # 执行 Agent
│   ├── reviewer.md              # 审查 Agent
│   ├── feedback-observer.md     # 反馈观察 Agent
│   └── evolution-runner.md      # 进化 Agent
├── feedback/
│   ├── feedback_index.md        # 反馈索引
│   └── ...                      # 具体反馈文件
└── plans/
    └── legal-entrypoints-and-evidence-standard-v1.md

下面一层一层讲。

三、顶层规则

顶层规则就是 claude.md 这个文件，整个系统的大脑。

你可以这么理解，Skill 是一个个器官，Sub-agent 是手和脚，Hooks 是条件反射，但大脑决定了什么时候用哪个器官、派哪只手去干活、条件反射的触发规则是什么。

claude.md 里定义了三件事。

第一，角色。 你是一个法律工作助理，不是通用聊天机器人。这一条看着简单，但它决定了 AI 处理模糊指令时的默认行为。用户说「帮我看看这个」，通用 AI 可能问你看什么，法律助理会直接判断这是一份合同还是一份案卷，然后走对应的 Skill。

第二，工作流触发条件。 什么情况下触发哪个 Skill，什么情况下启动编排链，什么情况下调用 Sub-agent。这块跟后面讲的自动路由是配合的，claude.md 定义大的调度逻辑，auto-trigger.md 定义细粒度的关键词匹配。

第三，文件结构约定。 所有 Skill 放哪、Agent 配置放哪、反馈文件放哪、中间产出物放哪，全在这里写死。AI 不需要猜，读一遍 claude.md 就知道整个项目的地图。

坦率的讲，这个文件我改了不下二十遍。一开始写了几百行，恨不得把所有规则都塞进去。后来发现不行，太长了 AI 记不住，关键规则反而被淹没。现在的版本精简到只留调度逻辑，具体的执行规则下沉到每个 Skill 里面去。

这块有一个反直觉的认知，做 AI 产品的时候，产品的第一受众不是人，是 AI。claude.md 写得好不好，不是看人读起来通不通顺，是看 AI 读完以后能不能准确执行。指令的清晰度比可读性重要。

四、自动路由

法律用户不是程序员，你不能指望一个律师记住 40 多个 Skill 的名字。

他们说话是这样的：

"帮我理一遍这个案子的事实"
"这份合同帮我审一下"
"查查这家公司有没有涉诉"

所以我做了一张路由表，把自然语言映射到 Skill 上：

用户输入                          自动触发
─────────────────────────────────────────────────
"新案子" / "新接了个案子"  →  litigation-caseflow
"事实梳理" / "理一遍事实"  →  litigation-fact-sheet
"证据在哪一页"             →  evidence-locator
"审一下这份合同"           →  contract-review
"查查这家公司"             →  risk-scan
"转 Word"                  →  md2word
"写代理词"                 →  litigation-brief-writing

完整的路由表有 7 个大类、50 多条规则：

路由这块有三个设计上的取舍：

匹配到了就直接干，别反问。 如果每次都问「你是想用 litigation-fact-sheet 这个 skill 吗？」，体验就碎了。路由表存在的意义就是省掉这一步。

设 6 个高层入口，收敛选择。 40 多个 Skill 不能全暴露出来。用户说一个模糊的需求，先走高层入口，再由入口 Skill 决定往下调谁。有点像医院挂号，你不用知道该去哪个科室，分诊台帮你判断。

支持一句话触发整条链。 用户说「新接了一个案子，帮我从头到尾处理一下」，触发的不是单个 Skill，而是一整条编排链，后面会讲到。

五、Skill 体系

六大类

法律 Skill 分成六大类：

设计上的几个讲究

一个 Skill 只做一件事。 不要搞一个大而全的 "litigation" Skill 把立案、事实梳理、证据定位、写代理词全塞进去。拆开来：

litigation-preflight     → 只做材料校验
litigation-fact-sheet    → 只做事实梳理
evidence-locator         → 只做证据定位
litigation-brief-writing → 只做代理词撰写

拆开的好处很实际：每个 Skill 能单独测试，能灵活组合，出了问题一眼就能看出是哪个环节。

每个 Skill 都有明确的输入输出。 需要什么进来（案卷文件？事实底稿？），产出什么出去（Markdown？Word？），输出质量标准是什么（要标证据来源吗？要精确到页码吗？），这三个问题必须回答清楚。

Skill 之间靠文件通信，不靠内存传递。 上一个 Skill 产出一个 md 文件，下一个 Skill 读这个文件开始干活：

litigation-preflight 产出 → preflight_report.md
                              ↓
case-files-to-md-fast 读取 → md_output/（一批 Markdown 文件）
                              ↓
litigation-fact-sheet 读取 → fact_sheet.md
                              ↓
evidence-locator 读取 → evidence_map.md（带页码的证据索引）

为什么这样做？因为法律案件的处理可能跨好几天。用文件做中间状态，随时可以从中间某一步接着来，不用从头跑。

Skill 怎么对上真实的办案流程

做 Skill 拆分之前，我先把一个诉讼案件从接案到结案的完整流程拉了一遍。大的律所一般都有标准化的办案 SOP，四十来步，我归成 6 个阶段：

阶段一 立案准备    信息采集 → 利益冲突检索 → 预立案 → 组建团队 → 评估委员会 → 发送联系函
阶段二 案件评估    案件评估 → 初步意见 → 客户会谈 → 前期工作计划 → 提交呈报文件
阶段三 材料与研究  资料收集 → 核对录入 → 案情摘要 → 案件图表 → 法规检索 → 案例检索 → 阶段汇报
阶段四 文书与模拟庭 客户深入沟通 → 撰写法律文件 → 证据准备 → 所内讨论 → 模拟法庭 → 复盘 → 庭审策略
阶段五 正式庭审    提交材料 → 庭审提纲 → 参加庭审 → 庭后复盘 → 提交代理意见 → 工作报告 → 沟通法官
阶段六 结案归档    裁判文书归档 → 交付卷宗 → 案例撰写 → 知识管理 → 办案总结

四十来步里面，不是每步都适合让 AI 干。开模拟法庭、参加庭审、跟法官沟通，这些天然是人的事。但有些步骤 AI 能帮上大忙，甚至比人快几十倍。

我逐步标注完之后，12 个 Skill 就是这么来的：

看完这张表你会发现，AI 覆盖最密的是阶段三和阶段四，材料整理和文书撰写。这两个阶段工作量最大、重复性最强，也是律师最头疼的体力活。阶段一和阶段五覆盖有限，因为涉及人际沟通和当庭判断。

阶段六有意思。知识管理和办案总结这两步，大多数所的做法是要求律师手动写总结归档，现实中经常被跳过或者敷衍了事。但在我的系统里，进化系统天然就在做这件事，每次使用中的反馈和纠正都会被自动沉淀，下个类似案件直接受益。这反倒是 AI 比人做得更靠谱的环节。

12 个 Skill 按办案节奏排列：

准备阶段（对应阶段二、三）
├── litigation-preflight        材料齐全性校验
├── case-files-to-md-fast       案卷批量转 Markdown
└── litigation-fact-sheet       事实底稿 + 争议矩阵

庭审准备阶段（对应阶段四、五）
├── evidence-locator            证据定位（精确到页码）
├── litigation-outline          庭审准备提纲
├── litigation-outline-review   庭审准备提纲复查
├── hearing-outline-sync        质证提纲和庭审准备对齐
└── hearing-strategy            庭审质证策略

文书阶段（对应阶段四、五）
├── litigation-brief-framework       代理词框架拆分
├── litigation-brief-content-workflow 代理词内容生成
├── litigation-brief-writing         代理词合稿
└── litigation-brief-format-finalizer 格式定稿

辅助（贯穿全程）
├── background-memo             商业背景备忘
└── risk-scan                   外部风险扫描

这 12 个一开始没有这么多。最早只有 3 个，事实梳理、庭审准备、代理词，能勉强跑通一个案子就行。后来用着用着，发现某些环节总是要手动拆，就把它们独立成了新的 Skill。这个过程本身就是进化系统在起作用，后面会展开讲。

合同审查

合同审查是最高频的场景，做了一个入口进来、按类型和立场自动分流的设计：

"审一下这份合同"                     → contract-review（通用模式）
"帮我审这份采购合同，我是供方"       → contract-review + 供方立场补充规则
"起草一份技术服务合同"               → contract-gen
"对比一下这两版合同"                 → contract-version-compare

输出也分层：先标风险（高/中/低），再给修改建议，最后附谈判策略（哪些能让，哪些不能让）。

六、执行系统

Skill 定义了「做什么」，但「谁来做」也得设计。

我用了 4 个 Sub-agent，各管各的：

这四个角色里，最容易被忽略的是 Feedback Observer。它不干任何具体的活，就是在旁边听着。用户纠正了一个事实、改了一个引文、吐槽了一句格式不对，它就默默写进 feedback 文件夹。这些反馈是进化系统的原料，没有它，后面整个进化链条就转不起来。

Sub-agent 隔离，这个特别重要

每个任务都起一个全新的 Sub-agent 实例，不复用、不继承上下文。

任务 A（事实梳理） → [新实例 1] → fact_sheet.md
任务 B（证据定位） → [新实例 2] → evidence_map.md
任务 C（写代理词） → [新实例 3] → brief_draft.md

为什么？因为法律场景里，前一个任务的错误假设如果带到下一个任务，后果很严重。

举个例子。事实梳理的时候，AI 可能对某个时间节点产生了一个错误理解。如果这个 Agent 带着这个错误记忆去写代理词，它会基于错误的事实构建论证，而且你很难发现，因为它写得逻辑自洽，言之有理，就是事实基础是歪的。

隔离之后，写代理词的 Agent 从零开始读 fact_sheet.md，拿到的是经过人工审核的中间文件，而不是前一个 Agent 脑子里的记忆。这就是为什么 Skill 之间靠文件通信，每一步都产出中间文件，文件本身就是一道防火墙。

还有一个实际的好处，上下文不膨胀。法律案件材料动辄几十万字，如果让一个 Agent 从头干到尾，上下文窗口早就爆了。拆成多个隔离的 Agent，每个只需要装载当前任务相关的文件，上下文干干净净。

七、编排链

编排链就是把多个 Skill 按顺序串起来，用户触发一次，系统自动往下跑。

法律场景的流程是刚性的，你不能跳过事实梳理直接写代理词，也不能跳过材料校验直接做证据定位。编排链就是把这个顺序固化下来。

几条主要的链：

诉讼案件完整处理：

用户："新接了一个案子"
        ↓
litigation-caseflow（总控）
        ↓
litigation-preflight         → 材料齐全性校验
        ↓
case-files-to-md-fast        → 案卷批量转 Markdown
        ↓
litigation-fact-sheet        → 事实底稿 + 争议矩阵
        ↓
litigation-outline           → 庭审准备提纲

代理词流水线：

用户："开始写代理词"
        ↓
litigation-brief-framework   → 拆模块
        ↓
litigation-brief-content-workflow → 按模块生成内容
        ↓
litigation-brief-writing     → 合稿
        ↓
litigation-outline-review    → 事实复核
        ↓
litigation-brief-format-finalizer → 格式定稿

合同审查全流程：

用户："帮我审一下这份合同"
        ↓
contract-review-calibrator   → 校准合同类型（可选）
        ↓
contract-review              → 主审查
        ↓
md2word                      → 输出 Word 格式报告

编排链有几个设计上的考虑。

每一步都产出中间文件。 preflight_report.md、fact_sheet.md、outline.md……每一步都有产出物，用户可以随时停下来检查、修改，改完了再继续。法律工作不能搞黑箱，中间过程必须可查。

总控 Skill 只负责调度。 比如 litigation-caseflow，它自己不写代理词也不梳理事实，它只管判断当前到哪一步了、下一步该调谁、输出合不合格。

天然支持断点续接。 法律案件处理可能跨好几天。今天做完材料校验和案卷转换，明天打开新的 Session 说「继续处理这个案子」，系统看到中间文件已经存在，直接从事实梳理那一步接着来。这就是用文件通信的好处，文件本身就是断点。

八、Hooks 机制

这一层解决的问题很具体，光靠自然语言让 AI 自己记住该做什么，不靠谱。

你在 Skill 里写「每次输出法律文书前，必须检查所有事实是否标注了证据来源」，AI 前几次会照做。但对话一长、上下文一挤，它就忘了。不是它故意的，是注意力资源有限，指令被淹没了。

Hooks 就是兜底用的。不管 AI 记不记得，到了那个节点，Hook 自动触发，强制执行。

我配了四个核心 Hook：

这里面最有用的是法律审查门禁。

法律文书出门之前必须过三层审查，这件事你用自然语言说十遍 AI 也可能跳过。但配了 Hook 之后就变成了硬约束，系统层面拦住，AI 想跳也跳不过去。

自然语言指令（可能被遗忘）
        ↓
Hook 兜底（机械执行，不存在遗忘）
        ↓
确保每次都走完该走的流程

反馈信号检测也值得说一下。很多时候用户纠正 AI 的时候，语气是很随意的，比如「不是这个时间，应该是3月15号」「这个引文引错了」。如果没有 Hook 在听，这些纠正就随着对话流走了，下次还会犯同样的错。有了反馈信号检测，每一次纠正都会被写进 feedback 文件夹，变成进化系统的养料。

我自己的感受是，Hooks 是整套系统里性价比最高的部分。写起来很简单，就是几行配置，但它解决的是 AI 最根本的可靠性问题。

九、证据级输出标准

法律 AI 最怕什么？写出来的东西格式漂亮、逻辑通顺，但事实是编的，法条引错了，证据在案卷里根本找不到。看着像那么回事，一核实全是假的。

所以我做了一套输出标准，凡是涉及事实、法律引用、企业信息的内容，都必须标来源、标可信度。

五级标签：

实际输出长这样：

1. 原告与被告于 2023 年 6 月 1 日签订《技术服务合同》
   [verified | 证据 C-1 第 3 页，双方均无异议]

2. 合同约定服务期限为 12 个月，服务费总额为人民币 120 万元
   [case_file_claim | 证据 C-1 第 5 页第 2.1 条]

3. 被告于 2024 年 1 月起停止支付服务费
   [case_file_claim | 原告起诉状第 4 段；
    被告答辩状未就此作出回应]

4. 截至起诉日，被告尚欠服务费人民币 60 万元
   [model_inference | 基于合同约定(C-1)与已付款凭证(C-5~C-8)计算]

好处很直接，律师一眼就能判断哪些事实有充分支撑、哪些需要进一步核实；标了 model_inference 的内容会被重点审查；也不用翻回案卷去找「这句话依据在哪」。

十、进化系统

前面提了好几次「进化」，这里展开讲。

进化系统是整套体系里我觉得最有意思的部分。它解决的是一个根本性问题，你不可能一开始就把所有规则都想到。第一版 Skill 一定是粗糙的，关键是它能不能自己变好。

四层，一层一层往上走：

┌──────────────────────────────────────────────────────┐
│                       进化系统                         │
├──────────────────────────────────────────────────────┤
│                                                      │
│  第 1 层：反馈收集                                    │
│    用户纠正了一个事实 → Feedback Observer 静默记录     │
│                          ↓                            │
│  第 2 层：规则毕业                                    │
│    同一类反馈出现 ≥3 次 → 升级为 Skill 里的正式规则   │
│                          ↓                            │
│  第 3 层：Skill 优化                                  │
│    某个 Skill 反馈评分持续偏低 → 提议优化该 Skill     │
│                          ↓                            │
│  第 4 层：Skill 创建                                  │
│    反复出现的操作模式但无 Skill 覆盖 → 提议创建新的   │
│                                                      │
└──────────────────────────────────────────────────────┘

举个真实的例子。

我一开始写的 litigation-brief-writing 这个 Skill，没有规定证据引用的格式。结果 AI 有时候写「见证据C-1」，有时候写「参见申请人提交的第一组证据」，有时候干脆不写出处。我每次都要手动改。

改了两三次之后，Evolution Runner 扫描到 feedback 文件夹里有 3 条同类反馈，全是关于「证据引用格式不统一」的。它就生成了一条进化建议，提议在 litigation-brief-writing 这个 Skill 里加一条正式规则，规定证据引用必须用「证据 [编号] 第 [X] 页」的格式。

我确认了，规则就写进去了。从那以后再也没犯过这个错。

这就是「规则毕业」，一条反馈出现三次，从 feedback 文件夹毕业，变成 Skill 里的正式规则。

再举一个 Skill 创建的例子。诉讼全流程最早只有 3 个 Skill，没有 evidence-locator。每次写代理词的时候，我都要手动告诉 AI「这个事实在案卷第几页」。反复几次之后，Evolution Runner 发现了这个模式，提议创建一个专门做证据定位的 Skill。我一看，确实需要，就建了。

进化系统有几个设计上的克制：

无感记录。 记录和扫描都在后台完成，用户感知不到。不会每纠正一次就弹出来问你「要不要记录这个反馈」。

轻提示。 只有生成了具体的进化建议时才告诉用户，不会没事找事。

需确认。 每条建议都需要用户确认才执行。它不会自己偷偷改规则，毕竟法律场景，规则改错了后果很严重。

跨 Session 延续。 反馈文件存在磁盘上，不随对话窗口消失。今天记的反馈，下周开新 Session 的时候 Evolution Runner 还能扫到。

系统越用越好。第一个月可能 60 分，第三个月能到 85 分。这个进步不靠某一次大升级，靠的是日常使用中一点点积累的微调。

十一、外部数据接入

法律工作不能只看案卷。这家公司还在经营吗？有没有被列入失信名单？这个法条现在还有效吗？有没有新的司法解释？同类案件法院怎么判的？

这些都要查。我通过 MCP（Model Context Protocol）接了几个外部数据源：

比如用户说「查查这家公司有没有问题」，risk-scan 会自动走一遍，调企查查拿工商信息和股东关系，查被执行、失信、限高、行政处罚，再看关联公司有没有风险，最后汇总成一份报告，每条信息标上 platform_found。

开庭前先扫一遍对方当事人的外部风险，能提前发现不少问题。

十二、跑一遍完整流程

来看一个实际场景，接了一个技术服务合同纠纷的案子，我方当事人是原告，说被告欠了 60 万服务费。

用户说：「新接了个案子，案卷文件在 /cases/2024-tech-service/ 下面」

系统路由到 litigation-caseflow，开始往下跑。

第一步，材料校验：

已找到文件：
[x] 起诉状
[x] 答辩状
[x] 证据 C-1～C-12（原告证据）
[x] 证据 R-1～R-5（被告证据）
[ ] 反诉状（未提交）
[x] 授权委托书

结论：核心材料齐全，可以开始处理。

第二步，案卷转 Markdown：

md_output/
├── 起诉状.md
├── 答辩状.md
├── C-1_技术服务合同.md
├── C-2_付款凭证.md
├── ...
└── R-5_验收报告.md

第三步，事实梳理，产出争议矩阵：

第四步，生成庭审准备提纲， 针对每个争议焦点列出质证要点和发问要点。

中间任何一步用户都可以停下来改。比如说「事实底稿里漏了一个争议焦点，关于服务验收标准的约定」，AI 更新 fact_sheet.md，后续 Skill 基于改过的文件继续。同时 Feedback Observer 会悄悄记一笔，「用户补充了遗漏的争议焦点」。下次再处理类似的技术服务合同纠纷，事实梳理 Skill 就会多留意验收标准这个常见争议点。

十三、几点产品层面的想法

先编排再开发

这块有一个我觉得还挺重要的认知转变。

传统做法是先想清楚要做什么产品，然后设计、开发、测试、上线。Skill 体系的做法反过来，先用 Skill 和编排链把流程跑通，跑通了再考虑要不要做成产品。

为什么可以这样？因为编排成本极低。一个 Skill 就是一个 Markdown 文件，写错了改掉就行，几分钟的事。不像写代码，写错了要 debug 半天。先用 Skill 验证想法，确认这条路走得通，再投入开发资源，方向不会错。

反过来说，如果一个法律工作流用 Skill 都编排不通，做成产品大概率也不行。Skill 编排本身就是最廉价的产品验证。

界面是容器，技能包是产品

传统法律 AI 产品喜欢做「系统」，合同审查系统、诉讼文书辅助系统、法律研究系统，每个独立开发独立维护。想加一个新的业务类型？重新设计界面、重新开发功能。

我的做法反过来，把能力拆到最小单元，按需组合。

┌─────────────────────────────────────────┐
│           同一个底座（Claude Code）       │
├─────────────────────────────────────────┤
│                                         │
│  加载诉讼技能包   → 诉讼助理            │
│  加载合同技能包   → 合同审查助理        │
│  加载尽调技能包   → 尽职调查助理        │
│  加载研究技能包   → 法律研究助理        │
│                                         │
└─────────────────────────────────────────┘

底座不变，技能包决定它是什么。界面只是一个容器，容器不限制功能，功能也不被界面绑死。加载一套新技能包，比重新开发一个产品成本低太多了。

两层受众

这套系统面向两拨人，做法完全不同。

给法律人用的那一面，用户不需要知道什么是 Skill、Agent、MCP，说人话就行，系统自己去路由。输出必须符合法律专业标准。

给 AI 执行的那一面，Skill 文件是给 AI 看的，写法要让 AI 能准确理解和执行，指令清晰度比人类可读性重要。

这个认知挺重要的。越来越多的工具产品开始 CLI 化，AI 不需要漂亮的按钮，它需要的是清晰的接口和指令。做 AI 产品的时候，第一个要问的不是「用户好不好用」，而是「AI 能不能用」。什么时候需要界面？当你发现某个环节必须让人介入的时候。界面是被需求推出来的，不是预设的。

先跑通再打磨

我的实际开发节奏：

第 1 周：3 个 Skill（事实梳理 + 庭审准备 + 代理词）
        → 能跑通一个案子的基本流程

第 2 周：补 5 个（材料校验 + OCR + 证据定位 + 合同审查 + 风险扫描）
        → 覆盖更多场景

第 3 周：加编排链 + 自动路由 + Hooks
        → 用户不用记 Skill 名字了，流程也有兜底了

第 N 周：进化系统开始自动沉淀新 Skill

每个 Skill 一开始都很粗糙，可能就是一段 prompt 加几条规则。用着用着，反馈推着它往前走。先跑通，再打磨。

十四、总结

整套法律 Skill 体系，拎出来看就是这么几件事：

一句话说完，把法律工作流里那些靠经验传承的隐性知识，变成可编排、可验证、可进化的 Skill。

这套东西不是做完就放那不动的，它会长。

具体 Skill 怎么写、Hooks 怎么配、进化规则怎么定，后面可以单独展开聊。BUYUN FADIA