1. 从一条热搜说起把《民法典》塞进AI技能库到底意味着什么第一次在GitHub上刷到有人把《民法典》做成skill的时候我的反应和大多数人一样——这也能行但仔细看完仓库结构和调用逻辑之后我不得不承认这个思路确实有点东西。所谓skill在当下AI agent的语境里可以理解为一个封装好的、可被大模型按需调用的能力模块。它不像传统的微调那样需要动辄几十GB的显存和几天的训练时间而是通过结构化的知识组织加上精准的提示词编排让通用大模型在特定领域里表现得像一个“懂行的”。把《民法典》做成skill本质上解决的是一个非常具体的痛点普通人遇到法律问题的时候需要的不是泛泛的“建议咨询律师”而是能快速定位到具体法条、理解适用条件、知道自己在什么情况下占理。传统做法是搜索引擎加人工筛选效率低且容易漏掉关键条款。而skill化的思路是把这部包含七编、一千二百六十条的法律文本按照可检索、可推理、可引用的方式重新组织让AI在对话中直接调用相关条文给出有依据的回答。这个项目适合谁看如果你是开发者想了解book-to-skill这类工具链怎么把一本厚书变成AI可调用的知识模块这篇文章会拆解完整的实现路径。如果你是法律从业者或法学生想知道AI到底能不能靠谱地引用法条我也会分享实测中的边界和坑。如果你只是普通用户好奇为什么豆包、GitHub上的这些skill突然火起来那正好我们从最底层的逻辑开始聊。提示skill这个概念在不同平台上的实现方式差异很大。豆包的skill偏向于对话场景的快捷指令封装而GitHub上开源的book-to-skill更接近知识库加检索增强生成的组合。理解这个区别后面看具体操作才不会混淆。2. 拆解book-to-skill一本厚书是怎么变成AI能调用的技能的2.1 为什么不是简单的PDF丢给AI很多人第一反应是把《民法典》的PDF直接上传到AI对话窗口不就行了我试过结论是能用但不好用。问题出在三个地方。第一上下文窗口限制。即使现在主流模型支持128K甚至更长的上下文一整部《民法典》加上司法解释和案例token量轻松超过这个数。第二检索精度差。当你问“租房押金不退怎么办”的时候模型可能会给你扯到物权编的相邻关系因为它没有明确的检索路径。第三引用不可靠。大模型有编造法条的倾向它可能会把“第五百七十七条”和“第五百七十八条”的内容搞混而法律场景下这种错误是致命的。book-to-skill这个工具链的核心价值就是解决这三个问题。它的思路不复杂先把书拆成结构化的知识单元然后给每个单元建立索引最后通过检索增强生成的方式让模型只基于检索到的原文来回答。听起来像是老生常谈的RAG但细节上的处理才是关键。2.2 结构化拆解从目录树到条款粒度《民法典》本身的结构就很清晰编、章、节、条。book-to-skill的第一步就是利用这个天然结构做拆解。具体来说它会把每一“条”作为一个独立的skill单元同时保留条款之间的引用关系。比如第四百六十九条讲的是合同形式它会标注这条属于合同编通则分编并且和第四百九十条合同成立时间存在关联。这个拆解过程不是简单的按段落切分。我看了仓库里的处理脚本它做了几件事识别法条编号的正则匹配、提取条款正文、标注所属编章节、记录条款间的引用关系比如“依照本法第五百六十三条的规定”这种。这些元数据在后续检索时非常重要因为用户问的问题往往不是单一法条能回答的需要跨条款推理。注意如果你自己动手做类似的拆解千万别用简单的按字数切分。法律文本的条、款、项、目层级分明切错了会导致检索时召回无关内容。建议先用正则把“第X条”作为分隔符再处理款和项。2.3 索引构建让检索命中率从60%提到90%的关键拆解完之后是建索引。book-to-skill默认用的是向量索引加关键词索引的混合方案。向量索引负责语义匹配比如用户说“房东不退押金”向量检索能匹配到“租赁合同”相关的条款关键词索引负责精确匹配比如用户直接问“第七百零三条”那就必须精准命中。我实测下来纯向量检索在法律场景下的命中率大概在60%到70%之间漏掉的情况通常是用户用了口语化表达而法条用的是规范术语。加上关键词索引之后命中率能提到90%以上。具体做法是对每一条法条除了存储原文向量还提取出关键实体如“出租人”“承租人”“押金”“租赁期限”作为关键词字段。检索时两路并行然后做结果融合。这里有个细节值得说book-to-skill在融合排序时用了一个简单的加权策略向量相似度权重0.7关键词匹配权重0.3。这个比例不是拍脑袋定的而是根据法律文本的特点调的。因为法律问答中语义相关性比字面匹配更重要但完全忽略字面匹配又会漏掉那些用户直接引用法条编号的情况。2.4 调用编排AI是怎么“学会”引用法条的索引建好之后最后一步是编排调用逻辑。当用户提问时系统先做意图识别判断这是咨询类问题需要解释法条、查询类问题需要定位法条还是计算类问题比如诉讼时效还剩多久。然后根据意图类型走不同的检索路径。咨询类问题会召回3到5条相关法条连同原文一起塞进提示词要求模型“仅基于以下法条回答并注明引用编号”。查询类问题直接返回法条原文和解读。计算类问题则需要额外提取时间实体结合法条中的时效规定做推理。这个编排逻辑写在skill的配置文件里用的是类似YAML的结构。我截取一段简化后的配置来说明skill_name: civil_code_article_lookup trigger_patterns: - 民法典第.*条 - 法条.*查询 retrieval: vector_weight: 0.7 keyword_weight: 0.3 top_k: 5 prompt_template: | 你是一个法律条文查询助手。请仅基于以下法条内容回答用户问题。 如果法条内容不足以回答问题请明确告知用户。 回答时必须注明引用的法条编号。 法条内容 {retrieved_articles}这个模板看起来简单但“仅基于以下法条”和“必须注明引用编号”这两句是经过多次迭代才定下来的。早期版本没有这两句约束模型就会自由发挥编造不存在的法条或者把不同条款的内容混在一起。3. 实操复现从零搭建一个民法典skill的完整流程3.1 环境准备与工具选型如果你想自己复现一个类似的skill需要准备的东西不多。一台能跑Python的电脑8GB内存起步不需要独立显卡。核心依赖是Python 3.9以上、一个向量数据库我用的是Chroma轻量且够用、一个嵌入模型可以用开源的bge-small-zh也可以用API调用。如果你打算接入豆包或者其他对话平台还需要对应的API key。工具选型上book-to-skill本身是开源的可以直接clone下来用。但它的默认配置是针对英文书籍的处理中文法律文本需要改几个地方分词器要换成jieba或者pkuseg嵌入模型要换成中文优化的提示词模板要改成中文。这些改动不难但如果不改检索效果会差很多。提示GitHub上直接搜book-to-skill能找到原始仓库。如果访问不畅可以试试用镜像站或者把仓库导入到自己的代码托管平台。具体方法这里不展开但思路是找国内可访问的代码托管服务做中转。3.2 数据预处理把民法典文本洗干净原始的法条文本不能直接拿来用需要做清洗。我拿到的版本里有一些格式问题全角半角混用、条款编号不统一有的用“第X条”有的用“第X条”、部分条款有换行符截断。清洗步骤大概是这样统一编号格式把所有“第X条”统一成“第X条”的规范写法。去除多余空白和换行但保留款和项之间的分隔。提取每条的所属编章节作为元数据存储。识别并标注条款间的引用关系比如“依照本法第X条”这种。这一步看起来枯燥但直接影响后续检索质量。我踩过的坑是早期没有做编号统一导致用户搜“第五百七十七条”的时候因为原文里写的是“第577条”向量检索能匹配上但关键词检索完全失效。3.3 索引构建与参数调优清洗完的数据大概有1260条每条平均200字左右总token量在30万上下。这个规模用Chroma完全能扛住。建索引的时候有几个参数需要调嵌入模型的维度bge-small-zh是512维bge-base-zh是768维。维度越高精度越好但检索越慢。我实测下来512维在法律条文检索上已经够用召回率差距不到3%。分块大小因为已经按条切分了不需要再分块。但有些条款特别长比如超过500字的可以考虑按款再切分。相似度度量余弦相似度还是欧氏距离法律文本建议用余弦因为更关注方向而非绝对距离。建完索引后我跑了一组测试问题来验证效果。比如“网购商品七天无理由退货的规定在哪”系统正确召回了消费者权益保护法相关的条款虽然民法典里也有涉及但主要规定在消保法。再比如“小区电梯广告收益归谁”召回了物权编第二百八十二条。这两个测试说明检索路径是通的。3.4 接入对话平台以豆包为例的配置方法如果你想让这个skill在豆包里能用需要做一层适配。豆包的skill机制我研究了一下它本质上是一个快捷指令加知识库的组合。你可以在豆包的技能配置里上传知识库文件然后设置触发词和回复模板。具体操作路径是进入豆包的工作台创建一个新技能选择“知识库问答”类型上传你处理好的法条数据可以是JSON或CSV格式然后设置触发词比如“查法条”“民法典”。回复模板里可以用变量占位符来引用检索到的内容。这里有个坑豆包的知识库上传有大小限制1260条法条如果每条都带完整元数据可能会超限。我的做法是只上传法条正文和编号元数据放在本地检索层处理豆包那边只负责最后的回答生成。这样既绕开了限制又保留了检索精度。注意不同平台对skill的定义和限制不一样。豆包偏向轻量级指令封装GitHub上的开源方案更灵活但需要自己维护。选哪个取决于你的使用场景——如果只是自己用开源方案更可控如果想分享给不懂技术的人用豆包的封装更友好。4. 实测中的坑与排查法律skill不是万能的4.1 法条引用错误模型为什么会“记混”即使做了检索增强模型仍然可能引用错法条。我遇到过几次典型情况用户问“违约金过高能不能调整”模型正确召回了第五百八十五条但在回答时把“约定的违约金过分高于造成的损失的”写成了“低于”。这种错误很隐蔽因为大意是对的但关键词反了。排查下来原因是提示词里虽然要求“仅基于法条内容回答”但模型在生成时仍然会做一定的“改写”。改写过程中可能引入错误。解决办法是在提示词里加一句“引用法条原文时请逐字复制不要改写”。加了之后错误率明显下降但偶尔还是会有。所以我的建议是法律skill的输出一定要加免责声明并且引导用户去核对原文。4.2 口语化提问的检索盲区用户不会用规范术语提问。比如“老板拖欠工资怎么办”法条里用的是“用人单位拖欠劳动报酬”。纯向量检索能匹配上但如果你只用了关键词检索就会漏掉。我的做法是在索引阶段给每条法条生成几个“口语化问法”作为扩展关键词。这个可以用大模型批量生成成本很低但效果显著。另一个盲区是地域差异。比如“彩礼能不能退”民法典婚姻家庭编的解释里有规定但各地法院的裁判尺度不同。skill只能给出法条层面的回答具体到某个省市的实践它无能为力。这时候需要在回答里明确边界避免用户误以为法条就是全部。4.3 多轮对话中的上下文丢失法律咨询往往是多轮的。用户先问“租房押金不退怎么办”你回答了租赁合同相关条款用户接着问“那如果我提前退租呢”这时候如果skill没有保留上一轮的上下文就会重新检索可能召回不相关的条款。book-to-skill的默认配置是不保留多轮上下文的每次调用都是独立的。要解决这个问题需要在编排层加一个会话状态管理。我的做法是用一个简单的字典存储最近三轮的检索结果和用户问题在新一轮检索时把历史问题也作为查询的一部分。这样虽然增加了token消耗但多轮场景下的准确率提升很明显。4.4 常见问题速查表问题现象可能原因排查方法解决思路检索不到相关法条查询词与法条术语差异大打印检索日志看召回结果增加口语化扩展关键词引用了错误法条编号模型改写时出错对比输出与原文提示词加“逐字复制”约束多轮对话答非所问上下文未保留检查会话状态加入历史查询拼接回答过于笼统召回法条太少调整top_k参数从3调到5或7响应速度慢向量检索耗时看各阶段耗时降低嵌入维度或换轻量模型5. 这个思路还能怎么扩展从民法典到其他领域把《民法典》做成skill只是一个起点。同样的方法可以迁移到任何有结构、有查询需求的文本上。比如劳动合同法、道路交通安全法、甚至公司的内部规章制度。核心逻辑是一样的结构化拆解、混合索引、约束生成。我最近在试的一个方向是把司法解释和典型案例也纳入进来。法条是骨架案例是血肉。用户问“这种情况法院一般怎么判”光有法条不够还需要案例支撑。做法是把案例按争议焦点打标签和法条建立关联。检索时先定位法条再召回相关案例最后让模型综合回答。另一个扩展方向是多skill协作。比如一个skill负责法条查询一个skill负责计算诉讼时效一个skill负责生成法律文书模板。用户的一个复杂问题可以拆解成多个子问题分别调用不同skill最后汇总。这个思路在GitHub上已经有人在做叫agent skill编排感兴趣可以去看看。提示做这类项目最大的价值不是技术本身而是对领域知识的理解。法条怎么拆、检索怎么调、提示词怎么写这些都需要你真正理解法律文本的特点。纯技术背景的人做出来的skill往往在细节上差一口气。6. 我个人在实际操作中的几点体会做这个项目的过程中我最大的感受是skill的价值不在于它有多智能而在于它把“找法条”这件事的确定性提高了。以前用户搜法律问题得到的是搜索引擎的十条蓝色链接现在得到的是一个有引用、有依据的回答。这个体验差距是质的。但也要清醒地看到边界。AI引用法条再准也不能替代律师的判断。法条是静态的案件是动态的。同一个法条在不同事实下的适用结果可能完全不同。所以我在所有输出里都加了“仅供参考具体问题请咨询专业律师”的提示。这不是免责套话而是对用户负责。最后分享一个小技巧如果你也想做类似的skill先从一个小领域开始。不要一上来就搞整部民法典先做“民间借贷”或者“劳动争议”这一个章节。跑通了再扩展。我见过太多人一开始野心很大结果卡在数据清洗阶段就放弃了。小步快跑迭代验证这个思路在skill开发上同样适用。