我把最近整理的两个 AI 工作流 skill 开源了：
- cn-legal-citation-check：中国法条与案例引用核验。
- cn-legal-doc-drafting-review：中国法律文书起草与审查。
仓库地址在这里：yiw62455-bit/cn-legal-codex-claude-skills。
它们不是一个“AI 律师产品”，也不是一套可以代替律师判断的模板库。更准确地说，它们是一组写给 Codex、Claude 等 AI agent 使用的工作流规则：让模型在处理中国法律任务时，先按律师工作的风险顺序走一遍，而不是凭语言流畅度直接给出答案。
为什么先做这两个
AI 写法律内容，最容易迷惑人的地方，不是它写得差，而是它往往写得太顺。
一段诉讼理由、一个法条依据、一份文书结构，表面上看起来有头有尾，语气也像那么回事。但真正危险的错误，经常藏在很小的地方：一个条号过时了，一个司法解释已经被修改了，一个案例编号是编的，一个事实被模型不小心写成了自认，一个利息起算日没有交代清楚。
这些错误在普通文章里也许只是瑕疵，在法律工作里却可能直接影响文书质量、程序利益和律师信誉。
所以我没有先做一个“万能法律助手”，而是先拆出两个最基础、也最容易出事故的环节：
第一，引用必须核验。
第二，文书必须按事实、证据、请求、程序和风险来组织。
这两个环节做好了，AI 才有资格进入更复杂的法律工作。否则它只是把不确定性包装成了很漂亮的文字。
第一个 skill：法条与案例引用核验
cn-legal-citation-check 的核心纪律很简单：凡是要输出具体法条条号、司法解释条文、案例编号，就必须当次核验，不凭记忆写。
这条规则听起来朴素，但对 AI 来说非常关键。
中国法律、司法解释和配套规则经常修正、修订、清理。很多条文的内容没有大变，但条号可能因为版本变化而移动。互联网上又长期留存着大量旧版法条、旧文章、旧裁判文书。模型在训练和生成时，会把不同年份、不同版本的信息混在一起。
于是就会出现一种很隐蔽的错误：内容方向大体对，条号却错了。
这比“完全不会”更危险。因为它会让使用者放松警惕。
这个 skill 的做法，是把引用核验变成一套强制流程：
- 先按条文内容关键词找现行文本，而不是带着记忆中的条号去搜索。
- 确认法律或司法解释的现行版本、施行日期和效力状态。
- 核对条号、款项、内容是否对应。
- 来源冲突时优先看官方文本，必要时再用近期裁判文书交叉验证。
- 核验不到就明说，不静默补一个看似合理的条号。
它适合用在起诉状、答辩状、上诉状、执行申请、法律意见书、律师函、合同条款审查等任务中。只要最终输出里出现具体条号或案例编号，都应该先过这一关。
第二个 skill：法律文书起草与审查
cn-legal-doc-drafting-review 是上层工作流。
它不负责替代法律检索，也不声称自己能自动给出正确结论。它要做的是让 AI 在起草或审查文书时，先遵守几个基本工作纪律：
- 不编造事实、日期、金额、案号、机关名称和当事人信息。
- 区分事实、证据、主张、法律结论和策略。
- 诉讼请求必须具体、可计算、可执行。
- 利息、违约金、经济补偿、诉讼费等金额要有计算式和参数来源。
- 上诉期、答辩期、举证期、申请执行时效、保全期限等期间问题要单独检查。
- 内部分析和文书正文分开，不把“给律师看的风险提示”写进提交给法院或对方的正文里。
- 文书含有法条或案例引用时，必须调用前一个引用核验 skill。
也就是说，它更像一个“文书工作流总控”。
起草新文书时，它会先看文书类型、程序阶段、当事人信息、请求目标、事实时间轴、证据状态，再组织正文。
审查己方文书时，它会优先找致命问题：是否可能不予受理，是否超过期限，诉讼请求是否无法执行，事实是否被误写成自认，证据是否支撑不了主张，金额计算是否缺参数。
分析对方文书时，它会进入攻击模式：找主体、管辖、时效、请求权基础、事实漏洞、证据三性、金额计算和程序瑕疵里的可利用点。
这不是为了让 AI 替律师拍板，而是让它更像一个知道轻重缓急的助理：先把风险点摊开，再由律师决定怎么取舍。
两个 skill 如何配合
这两个 skill 最好一起使用。
可以简单理解为：
cn-legal-doc-drafting-review 负责“文书怎么写、怎么审、怎么拆风险”。
cn-legal-citation-check 负责“文书里的引用能不能站得住”。
前者处理事实、证据、请求、程序和结构；后者处理条号、版本、效力和案例编号。
例如，让 AI 起草一份强制执行申请书时，合理流程不是直接让它吐出定稿，而是：
- 先提取执行依据、申请人、被执行人、申请事项、金额、利息、履行期限等关键事实。
- 再列出内部起草说明：哪些信息缺失，哪些金额需要计算，哪些期限需要确认。
- 然后生成文书正文。
- 最后把正文中的法条和案例引用逐条核验。
- 核验不到的引用，宁可改成描述性表述，也不要硬写具体条号。
这个流程看起来慢一点，但法律工作本来就不应该只追求“快出一稿”。AI 真正有价值的地方，不是让我们跳过专业判断，而是把过去容易靠经验默默完成的检查动作显性化。
如何安装
GitHub 仓库已经放出源码和可下载包：
https://github.com/yiw62455-bit/cn-legal-codex-claude-skills
如果使用 Codex，可以直接复制目录安装。打开终端后，依次执行：
- git clone https://github.com/yiw62455-bit/cn-legal-codex-claude-skills.git
- cd cn-legal-codex-claude-skills
- mkdir -p ~/.codex/skills
- cp -R cn-legal-citation-check ~/.codex/skills/
- cp -R cn-legal-doc-drafting-review ~/.codex/skills/
重启 Codex 后，两个 skill 会出现在可用 skill 列表里。
也可以从仓库的 packages 目录下载 .skill 文件。.skill 文件本质上是压缩包，适合转发、备份和导入。
适合谁用
这两个 skill 主要面向三类人：
第一类，是已经在使用 AI 的律师。
如果你经常让 AI 帮你整理案情、起草文书、审查对方材料、做法律研究，那么最需要的不是更多“万能提示词”，而是给 AI 加上硬约束：什么不能编，什么必须核，什么风险要优先报出来。
第二类，是律师团队里的年轻律师或实习生。
它可以作为一份工作检查清单，帮助新人理解：一份法律文书不是把话写顺就完了，而是要能回到事实、证据、请求、程序和引用来源。
第三类，是对法律科技感兴趣的法律人。
相比做一个封闭产品，我更愿意把这些工作流先开源出来。法律 AI 的真正难点不只是模型能力，而是把专业工作拆成可检查、可复核、可迭代的步骤。
不适合什么场景
它不适合被当成自动出具法律意见的机器。
也不适合在没有人工复核的情况下，直接生成并提交正式法律文件。
更不适合把完整客户案卷、身份证件、银行流水、聊天记录、商业秘密、诉讼策略等敏感材料随手丢进不可信环境。
法律工作天然涉及保密义务、数据安全和职业责任。AI 工具越好用，越要清楚边界在哪里。
所以仓库里也单独写了免责声明：这些 skill 是工作流和质量控制工具，不构成法律意见，不能替代律师基于完整事实、证据和程序阶段作出的专业判断。
我为什么选择开源
原因很简单：这种东西只有在真实使用中才会变好。
法律工作里的很多风险，不是坐在书桌前想出来的，而是在一次次改文书、查条文、算期限、核案号、和法官沟通、被对方抓漏洞之后慢慢长出来的。
如果每个人都把自己的工作流关在本地，进步会很慢。开源至少可以让这些经验被看见、被质疑、被改进。
我也希望它成为一个更具体的讨论起点：法律 AI 不应该只停留在“能不能写诉状”“能不能查案例”这种粗粒度问题上。更值得讨论的是：
- AI 在法律工作中哪些环节可以辅助？
- 哪些环节必须保留人工判断？
- 哪些错误一旦发生就是高风险？
- 如何把律师的专业检查动作写成可复用的工作流？
- 如何让模型承认不确定，而不是用流畅语言掩盖不确定？
这两个 skill 只是一个很小的开始。
但我相信，法律人使用 AI 的关键，不是把判断交出去，而是把判断训练得更清楚。工具越强，越需要我们知道：什么时候让它快，什么时候让它慢；什么时候让它写，什么时候让它查；什么时候听它建议，什么时候必须自己负责。
AI 可以帮我们写得更快。
但法律工作最终靠的，仍然是能够承担后果的判断。