把《民法典》做成AI skill：book-to-skill实操拆解与避坑指南-北京尧图网络

1. 从一条热搜说起为什么“把《民法典》做成skill”能引爆技术圈第一次在GitHub上刷到有人把《民法典》拆成AI skill的时候我的反应和大多数人一样——这玩意儿到底是个噱头还是真能跑起来毕竟法律文本动辄十几万字条文之间还有大量交叉引用、但书、例外条款把它塞进一个对话式AI的上下文里听起来就像把一头大象装进冰箱。但仔细看完那个仓库的结构之后我承认这个思路确实有点东西。所谓skill在当下AI agent的语境里并不是什么玄乎的概念。你可以把它理解成给AI装的一个“技能包”一段结构化的指令、一组可调用的工具描述、加上必要的知识切片打包成一个AI能识别、能按需加载的模块。它和传统的“把文档丢给模型做RAG”最大的区别在于skill强调的是行为编排——不只是让AI“知道”某条法律而是让它“知道在什么场景下该查哪一条、该怎么组织回答、该提醒用户注意什么”。这个项目之所以被叫做“天才”核心在于它做了一件很多人想做但没做利索的事把一部体系庞大、逻辑严密、容错率极低的法律文本转化成了一套AI可以稳定调用的结构化技能。这背后涉及的问题非常具体——条文怎么切、切完之后怎么建索引、用户问一个模糊的生活场景时怎么映射到具体法条、模型胡编条文怎么防。这些问题做过法律类AI应用的人应该都踩过坑。我写这篇东西不是要复述那个仓库的README而是想从一个实际动手做过类似项目的人的角度把“book-to-skill”这条链路拆开讲清楚。适合谁看如果你正在琢磨怎么把一本厚书、一套规范、一份内部手册变成AI能用的skill或者你单纯好奇豆包、GitHub上那些skill插件到底是怎么运转的那这篇应该能给你一些能直接抄的作业。如果你只是想找个AI帮你查法条那看完你也会明白为什么有些AI答法律问题靠谱有些纯属胡说八道。2. 拆解核心思路book-to-skill到底在解决什么问题2.1 为什么不能直接把《民法典》全文喂给AI很多人第一反应是现在模型上下文都上百万token了直接把《民法典》全文贴进去不就完了我实测过这条路结论是能跑但不好用。原因有三个而且每一个都很致命。第一注意力稀释。当上下文里塞了十几万字的法条你问“楼上漏水把我家天花板泡了怎么办”模型确实能看到相邻关系那几条但它同时也会看到合同编、侵权编、物权编里大量语义相近的表述。上下文越长模型对关键条文的“聚焦能力”越弱回答里经常混进不相干的条款。这不是模型不行是信息密度的问题。第二条文之间的引用关系会丢。民法典里大量条文写着“依照本法第X条的规定”“适用第X章的规定”这些交叉引用在纯文本拼接里是断的。模型看到“依照前条规定”的时候如果前条不在它的注意力焦点里它就会自己编一个“前条”出来。这是法律类AI最危险的幻觉来源。第三无法控制回答结构。法律咨询不是简单问答一个好的回答应该包含结论、依据条文、适用条件、例外情形、操作建议。你把全文丢进去模型每次输出的结构都不一样有时候只给结论不给依据有时候把但书漏掉这在法律场景里是不能接受的。所以book-to-skill的核心价值就出来了它不是让AI“读完整本书”而是把书拆成可检索、可组合、可验证的技能单元让AI在需要的时候精准调用而不是一次性吞下去。2.2 skill的本质给AI装一个“行为剧本”我习惯把skill理解成三层结构。最底层是知识切片也就是把原始文本按语义单元切开每一片都带完整的元数据来源、章节、条文号、生效时间。中间层是调用逻辑定义什么类型的用户输入触发什么切片以及多个切片之间怎么组合。最上层是输出模板规定回答的结构、语气、必须包含的要素。拿《民法典》举例。知识切片不是简单按“第X条”切因为很多条文是一整段但包含多个独立规则。我的做法是按“规则单元”切一条里如果有“原则例外但书”就拆成三个切片但保留同一个条文号作为父级索引。这样用户问“租房押金能不能退”系统能精准命中“租赁合同”章节里关于押金的那几个规则单元而不是把整个租赁合同章都拉出来。调用逻辑这块最关键是场景到法条的映射表。用户不会说“我要查第七百一十六条”他会说“房东把我赶出来了押金还不退”。你需要一个中间层把生活语言翻译成法律概念再映射到条文。这个映射表可以手工建也可以用模型做few-shot分类但一定要有不能指望模型每次自己现场推理。输出模板则是保证稳定性的关键。我一般会强制要求回答包含四个部分结论先行、法条依据、适用条件说明、行动建议。如果涉及例外情形必须单独列出。这个模板写进skill的指令里模型每次输出都会遵循不会今天一个格式明天一个格式。2.3 为什么选skill而不是微调或纯RAG这里要解释一个选型问题。做法律AI常见路线有三条微调一个法律模型、搭一套RAG检索、或者做skill。我三条路都试过说说各自的坑。微调的问题在于更新成本。法律会修订司法解释会出新你微调一次模型下次条文变了就得重新训。而且微调容易让模型“记住”旧条文新旧混着答很难排查。RAG的问题在于检索精度和编排能力。纯RAG能帮你找到相关条文但它不管你怎么组织回答也不管条文之间的引用关系模型拿到检索结果之后还是自由发挥。skill的好处是知识、逻辑、输出三者分离。知识切片可以独立更新调用逻辑可以独立调整输出模板可以独立优化。条文修订了你只需要替换对应的切片不用动模型也不用动编排逻辑。而且skill天然适合多AI协作——同一个skill包豆包能调其他支持agent skill的框架也能调不绑定特定平台。提示如果你要做的是高频更新的领域知识法律、医疗指南、公司制度skill的维护成本远低于微调和纯RAG。但如果你要做的是风格模仿类任务微调可能更合适。3. 核心细节解析把《民法典》切成skill的实操要点3.1 文本预处理从PDF到结构化切片拿到《民法典》全文之后第一步不是急着切而是做结构化解析。官方文本通常是PDF或者网页直接复制出来会带大量格式噪音——页眉页脚、换行错位、条文号粘连。我的处理流程是这样的先用脚本把全文按“第X条”做粗切得到一个条文列表。然后对每一条做二次解析识别里面的款项一、二、三、但书但是、除……外、引用依照本法第X条。这一步我用的是正则加规则因为法律文本的格式非常规整正则的准确率比模型还高。解析完之后每一条会变成一个JSON对象包含这些字段条文号、所属编章、原文、款项列表、但书列表、引用列表、关键词标签。关键词标签可以手工打也可以用TF-IDF自动提取我建议两者结合——自动提取做初筛手工修正高频查询相关的标签。这里有个细节很多人会忽略条文号的排序问题。民法典的条文号是连续的但编章结构是嵌套的。如果你只按条文号建索引用户问“合同编里关于违约的规定”你得遍历整个合同编。我的做法是建两级索引一级按编章二级按条文号。查询时先定位编章再在编章内做语义检索速度快很多。3.2 切片粒度切太细和切太粗都是坑切片粒度是book-to-skill里最需要反复调参的地方。切太细一个规则被拆成好几片模型调用时容易漏切太粗一片里塞了好几个规则模型回答时容易混。我的经验是按“可独立适用的规则”切。什么叫可独立适用就是这一片拿出来能单独回答一个“什么情况下适用什么后果”的问题。比如“承租人经出租人同意可以转租”是一个独立规则“未经同意转租的出租人可以解除合同”是另一个独立规则。这两条虽然在同一条里但适用条件不同应该切成两片。但书和例外要单独切并且打上“例外”标签。因为用户问一般情况时你不需要把例外也塞进去但用户问“有没有例外”时你要能精准调出例外切片。这个标签体系是skill能不能做细的关键。还有一个技巧给每个切片加一个“适用场景”描述。这个描述不是法条原文而是用大白话写的一句话比如“租房时房东突然要卖房租客能不能继续住”。这个描述是给检索层用的用户输入和这个描述做语义匹配比直接匹配法条原文准确率高得多。3.3 引用关系的处理别让模型自己猜“前条”前面说过民法典里大量条文互相引用。如果切片的时候不处理这些引用模型回答时就会自己编。我的处理方式是把引用关系显式化。具体做法是在解析阶段就把每条里的“依照本法第X条”“适用第X章”提取出来存成一个引用图。当模型调用某一条时skill的调用逻辑会自动把被引用的条文也拉进来作为“关联依据”一起提供给模型。这样模型不需要自己推理“前条是什么”它直接看到完整的引用链。这个引用图还有一个用处检测循环引用和断链。如果A引用BB引用CC又引用A说明解析有问题需要人工检查。如果A引用了一个不存在的条文号说明原文解析错了。这些检查在构建阶段做一遍能避免上线后大量幻觉。注意引用关系不要全部展开。如果一条引用链有五六层全部拉进来会让上下文爆炸。我的做法是只展开一层直接引用间接引用用摘要形式提供并标注“详见第X条”。3.4 输出模板的设计让回答像律师写的法律类skill的输出模板我建议参考律师写法律意见书的结构。不是要写得那么正式而是要有那个逻辑层次。我的模板是这样的第一段给结论一句话说清楚“能还是不能”“该不该”“怎么办”。第二段给法律依据列出直接相关的条文号加原文摘录。第三段给适用条件说明这个结论在什么前提下成立。第四段给例外和风险列出但书和可能影响结论的因素。第五段给行动建议告诉用户下一步可以做什么。这个模板写进skill的指令里并且用few-shot示例强化。我一般会放三到五个示例覆盖“有明确结论”“结论取决于条件”“法律没有明确规定”三种情况。示例不用多但质量要高每个示例都要体现模板的完整结构。还有一个细节条文引用格式要统一。我要求模型引用条文时必须写成“《民法典》第X条”不能只写“第X条”也不能写“根据相关法律规定”。这个格式约束看起来小但对可信度影响很大。用户看到具体条文号才会觉得这个回答有依据。4. 实操过程从零搭建一个法律skill的完整链路4.1 环境准备与工具选型动手之前先把工具链定下来。我的配置是这样的文本解析用Python加正则切片存储用JSON文件加SQLite做索引语义检索用本地embedding模型不想依赖外部API的话bge-small-zh就够用skill编排用YAML定义调用逻辑测试用一组手工标注的问答对。为什么用SQLite而不是向量数据库因为法律条文的检索量不大民法典加司法解释也就几千个切片SQLite加FAISS索引完全够用而且部署简单不依赖外部服务。如果你要做的是整个法律体系那再考虑上专业的向量库。embedding模型的选择上我试过几个中文模型bge-small-zh在法条检索上的表现已经不错而且模型小、跑得快。如果你有GPU可以用更大的模型但对这个场景提升有限。关键是检索策略不是模型大小。skill的编排文件我用YAML写因为可读性好改起来方便。一个skill定义大概长这样名称、描述、触发条件、知识库路径、调用逻辑、输出模板、示例。这个文件就是skill的“说明书”AI agent读了这个文件就知道怎么用这个skill。4.2 条文解析与切片生成的具体步骤第一步把民法典全文保存成纯文本按“第X条”做初步分割。这里要注意条文号有中文数字和阿拉伯数字混用的情况统一转成阿拉伯数字再做分割。第二步对每一条做结构化解析。我用的是正则加状态机遇到“第X条”开始新条文遇到“一二”识别为款项遇到“但是”“除……外”识别为但书遇到“依照本法第X条”识别为引用。解析结果存成JSON。第三步按规则单元做二次切片。一条如果只有一个规则就保持原样如果有多个规则按“适用条件法律后果”的边界切开。切的时候保留父条文号方便回溯。第四步给每个切片生成“适用场景”描述。这一步可以用模型辅助给模型看切片原文让它用大白话写一句“什么情况下会用到这条”。生成之后人工过一遍修正明显不对的。第五步建索引。把切片原文、适用场景描述、关键词标签分别做embedding存进FAISS。查询时三路召回加权合并。第六步写调用逻辑。定义用户输入怎么映射到切片先做意图分类是问结论、问依据、还是问例外再根据意图决定召回哪些切片最后按输出模板组织回答。4.3 调用逻辑的编排与参数计算调用逻辑里最关键的是召回数量和相似度阈值这两个参数。召回太多上下文里塞满不相关条文模型容易分心召回太少可能漏掉关键依据。我的经验值是初次召回8到12个切片相似度阈值设在0.65左右。这个阈值是根据测试集调的低于0.65的基本都是噪音高于0.65的通常相关。但法律场景有个特殊性有些条文原文和用户问法差异很大但语义上相关。比如用户问“被狗咬了”条文写的是“饲养动物损害责任”。这种靠纯语义相似度可能召不回来需要靠“适用场景”描述来补。所以我的做法是双路召回一路用条文原文做embedding一路用适用场景描述做embedding两路结果合并去重。实测下来双路比单路的召回率高15%左右。还有一个参数是引用展开深度。前面说过只展开一层但有些场景需要展开两层。我的做法是默认一层如果模型在回答时标注“需要进一步依据”再触发二层展开。这个动态展开的逻辑写在skill的调用脚本里。4.4 测试与迭代怎么判断skill好不好用测试集我建了大概200个问答对覆盖民法典各编的常见问题。每个问答对包含用户问法用大白话、期望命中的条文号、期望的回答结构。测试的时候看三个指标条文命中率期望条文有没有被召回、回答完整率模板的五个部分有没有都覆盖、幻觉率有没有编造条文号或条文内容。第一轮测试下来条文命中率大概75%主要漏在语义差异大的场景。加了适用场景描述召回之后提到88%。幻觉率一开始有8%主要是引用展开时模型自己补了不存在的条文把引用展开逻辑改成显式提供之后降到2%以下。回答完整率是最容易提升的把输出模板写得更明确、加更多few-shot示例就行。但要注意模板太死板会让回答显得机械我后来在模板里加了“根据问题复杂度可适当调整段落顺序”的说明让模型有一点灵活空间。提示测试集一定要包含“法律没有明确规定”的问题。这类问题最能检验skill的诚实度。好的skill应该明确说“现行法律对此没有直接规定”而不是硬编一个条文出来。5. 常见问题与排查技巧实录5.1 模型编造条文号怎么办这是法律类skill最高频的问题。模型编条文号通常有三个原因一是召回时没召回到正确条文模型只能编二是引用展开时信息不完整模型自己补全三是输出模板没约束好模型自由发挥。排查顺序是先看召回日志确认正确条文有没有被召回到。如果没有调召回策略。如果有但模型没用看是不是上下文里条文太多被淹没了减少召回数量或提高阈值。如果召回没问题但模型还是编检查输出模板里有没有强制要求“引用条文必须来自提供的依据列表”。我一般会在指令里加一句硬约束“你只能引用下方依据列表中出现的条文号不得引用列表外的任何条文。”还有一个技巧在输出后做一次条文号校验。用正则把回答里的所有“第X条”提取出来和依据列表比对发现列表外的就标记出来。这个校验可以做成后处理发现异常就重新生成或者降级回答。5.2 用户问法太口语化检索召不回来“老板拖欠工资怎么办”这种问法和劳动法条文的表述差异很大。纯语义检索经常召不回来。我的解法是建一个口语到法律概念的映射表把常见的生活场景词映射到法律术语。比如“拖欠工资”映射到“劳动报酬”“工资支付”“被赶出来”映射到“解除租赁合同”“腾退”。这个映射表可以手工建也可以用模型从测试集里自动挖掘。我一般是先手工建一批高频的然后跑测试集看哪些问题召不回来再补映射。映射表不需要很大覆盖长尾就行因为长尾问题本来就不多。另一个技巧是查询改写。用户输入之后先用一个小模型把口语化问题改写成法律化的查询再用改写后的查询去检索。改写可以多生成几个版本分别检索后合并结果。这个方法对召回率提升很明显但会增加一点延迟。5.3 条文更新了怎么维护skill法律条文会修订司法解释会出新skill必须能低成本更新。我的做法是知识切片和调用逻辑分离。切片存在独立的JSON文件里调用逻辑存在YAML里。条文更新时只需要重新生成受影响的切片替换JSON文件调用逻辑不用动。为了快速定位受影响的切片我在切片元数据里存了“所属编章”和“条文号”。更新时按编章或条文号筛选批量替换。如果只是个别条文修订直接改对应的JSON条目就行。版本管理用Git每次更新打tag记录更新了哪些条文、依据是什么。这样出问题可以回滚也方便追溯。我还会在skill的描述里标注“知识截止日期”让用户知道这个skill的时效性。5.4 多AI协作时skill怎么复用skill的一个好处是跨平台。同一个skill包豆包能调其他支持agent skill的框架也能调。但不同平台的调用接口不一样需要做一层适配。我的做法是把skill的核心逻辑切片、检索、编排做成独立的服务对外暴露一个标准接口。各个AI平台通过这个接口调用skill平台侧只负责把用户输入传进来、把skill输出传回去。这样skill的逻辑只维护一份平台适配层很薄换平台成本很低。如果平台不支持外部服务调用只能把skill打包成平台特定的格式那就需要写一个转换脚本把通用skill定义转成平台格式。这个转换脚本一次写好后续更新自动转换也不麻烦。5.5 常见问题速查表问题现象可能原因排查方法解决方向模型编造条文号召回缺失或模板约束不足查召回日志比对依据列表调召回策略加硬约束后处理校验口语化问题召不回语义差异大看测试集漏召案例建口语映射表加查询改写回答结构不稳定模板不够明确统计各段落覆盖率强化模板加few-shot示例引用链断裂引用展开不完整检查引用图显式展开引用标注关联依据条文更新后回答旧内容切片未更新比对切片版本按编章批量替换打版本tag多平台表现不一致平台适配层差异对比各平台输入输出统一核心服务薄适配层6. 这套思路还能怎么扩展把《民法典》做成skill只是book-to-skill的一个案例。这套方法可以迁移到很多场景公司内部制度手册、医疗诊疗指南、产品说明书、行业标准规范只要是“体系化、有结构、需要精准引用”的文本都可以用同样的链路做成skill。我最近在试的一个方向是多skill协作。比如一个法律skill加一个合同起草skill用户问“帮我看看这份合同有没有风险”法律skill负责识别风险点合同起草skill负责给修改建议两个skill通过一个编排层协作。这个思路在agent skill的框架下是可行的关键是定义好skill之间的接口和数据格式。另一个方向是skill的自动化测试。我现在测试还是半手工的后面想做成CI流程每次更新切片自动跑测试集看命中率、完整率、幻觉率有没有退化退化了就阻断发布。这样维护成本能进一步降低。最后分享一个我在实操中体会很深的点skill的质量不取决于模型多强而取决于切片切得好不好、调用逻辑清不清晰、输出模板稳不稳定。模型只是执行层真正决定效果的是你喂给它的结构和约束。把这三件事做扎实用中等模型也能跑出很好的效果这三件事做不好用最强的模型也是满嘴跑火车。

把《民法典》做成AI skill：book-to-skill实操拆解与避坑指南

相关推荐

大模型推理decode阶段硬件部署：显存带宽、KV Cache与运维实战

BUCK电路DCM、CCM、BCM模式本质与实操判定

BUCK电路DCM/CCM/BCM工作模式深度解析

更多资讯

LCD屏幕Flicker根源：VCOM电压抖动实测与调校

LCD闪烁根源：VCOM电压失稳与示波器实测调校

AIGC幻觉：比生成慢更致命的坑，从软著到论文的降幻觉实操指南

室内无人机定位实战：Livox Mid360激光雷达与光流融合方案

FPGA多通道DDS并行设计：突破单路采样率瓶颈

PyTorch多CUDA Stream同步陷阱：record_stream必须配wait_event

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？