1. 从一条标题说起为什么“把《民法典》做成skill”这件事值得聊第一次刷到“第一个把《民法典》做成skill的人简直是个天才”这个标题时我的反应和大多数人一样——先是愣了两秒然后立刻意识到这背后藏着一个非常聪明的产品思路。它不是什么高深的技术突破而是把“法律条文”这种又长又重、普通人根本读不下去的东西塞进了一个AI能随时调用的“技能包”里。你不需要懂法条编号不需要翻几百页PDF只要对着AI说一句“我租的房子漏水房东不管我能不能不交房租”它就能顺着《民法典》里的相关条款给你捋清楚。这就是skill这个概念真正有意思的地方。它本质上是一段被结构化封装好的指令集告诉AI“遇到这类问题你应该按什么逻辑、调用哪些知识、输出什么格式的答案”。而book-to-skill这个思路就是把一本厚书——不管是法律、医学指南、公司手册还是产品文档——拆解、提炼、重组成AI可以直接执行的技能模块。GitHub上已经有人在做类似的事情把各种知识库转成agent skill让AI agent在特定场景下表现得像个专家。这篇文章我想聊的不是“怎么一键生成skill”这种快餐教程而是把这个项目背后的设计逻辑、实操路径、踩坑经验完整地拆一遍。适合谁看如果你手头有一本反复被问到的资料、一套内部规范、一份产品说明书或者你单纯对AI agent、豆包skill、book-to-skill这套玩法感兴趣那接下来的内容应该能帮你少走不少弯路。我会尽量把每个环节讲透包括为什么这么设计、参数怎么定、哪些地方最容易翻车。2. 整体设计思路把一本书变成AI能用的技能到底在做什么2.1 核心问题为什么不能直接把PDF丢给AI很多人第一反应是我把《民法典》全文粘贴到对话框里不就行了理论上可以但实际用起来会立刻撞上三堵墙。第一堵墙是上下文长度。《民法典》全文十几万字加上司法解释和相关案例轻松突破大多数模型的单次处理上限。就算模型支持长上下文你把整本书塞进去它也会因为信息密度太低而抓不住重点——就像你让一个人背完整本字典再回答“‘善意取得’是什么意思”他反而容易懵。第二堵墙是检索精度。法律问题的特点是“一个具体场景对应多个分散条款”。比如“租房漏水”可能涉及租赁合同、维修义务、违约责任、合同解除条件等好几个章节的内容。单纯靠语义相似度检索很容易漏掉关键条款或者把不相关的条文也拉进来干扰判断。第三堵墙是输出稳定性。你希望AI每次回答都遵循“先给结论、再列法条、最后给建议”的结构但直接对话时它可能这次给你一段散文下次给你一个列表格式飘忽不定。对于法律这种要求严谨的场景输出不稳定等于不可用。book-to-skill要解决的就是这三个问题把书拆成可检索的知识块把回答逻辑固化成指令模板把输出格式锁死成结构化模板。2.2 方案选型为什么是skill而不是微调或RAG把知识注入AI常见路径有三条微调、RAG检索增强生成、skill封装。这三条路我都在不同项目里试过各有各的适用场景。微调适合“风格迁移”和“领域语感”训练比如让模型学会用法律文书的语气说话。但微调的成本高、周期长而且一旦法律修订你得重新训练。对于《民法典》这种会更新、需要精确引用原文的场景微调不是最优解。RAG是目前最主流的知识注入方案核心思路是“先检索、再生成”。它解决了知识更新和上下文长度的问题但RAG的短板在于“检索质量决定一切”。如果检索环节没做好后面生成再强也是白搭。而且RAG通常只负责“找到相关内容”不负责“按固定逻辑组织答案”。skill封装则是在RAG基础上再往前一步它不仅告诉AI“去哪里找知识”还告诉AI“找到之后怎么用”。一个设计良好的skill包含触发条件、知识索引、推理步骤、输出模板、边界约束五个部分。你可以把它理解成给AI写了一份“岗位操作手册”——遇到什么情况、查什么资料、按什么流程处理、最后交什么格式的成果。对于《民法典》这个场景skill方案的优势非常明显法律条文本身是高度结构化的编、章、节、条天然适合做成索引法律咨询的回答逻辑也相对固定事实认定→法律适用→结论建议适合固化成模板而且skill可以随时更新某条司法解释变了只需要改对应的知识块不用动整个系统。2.3 架构拆解一个法律skill的五个组成部分我后来自己复现了一版类似的skill也参考了GitHub上一些开源项目的做法。一个能用的法律类skill基本都包含这五个模块触发层定义什么情况下激活这个skill。比如用户输入包含“合同”“违约”“赔偿”“租赁”“婚姻”“继承”等关键词或者用户明确说“帮我查一下民法典”。索引层把《民法典》按编、章、节、条拆成独立的知识块每个块包含条文原文、关键词标签、关联条文编号。索引层的关键是“粒度控制”——太粗了检索不准太细了上下文碎片化。推理层定义AI拿到用户问题后的处理流程。通常是“提取事实要素→匹配相关法条→判断法律关系→给出结论和建议”。输出层锁定回答格式。我见过做得好的skill会强制输出“结论先行、法条依据、操作建议、风险提示”四段式结构。边界层明确告诉AI什么不能做。比如“不能替代律师出具正式法律意见”“不能对未生效的判决进行预测”“遇到刑事案件建议直接报警”。这五层里索引层和推理层是最考验设计功力的地方也是后面实操部分我会重点展开的内容。3. 核心细节解析book-to-skill的实操要点与避坑指南3.1 知识拆解怎么把一本书切成AI能消化的块把《民法典》做成skill第一步不是写代码而是做“知识拆解”。这件事听起来简单做起来全是细节。最粗的拆法是以“编”为单位比如“合同编”“婚姻家庭编”“继承编”。但这样每个块太大了一个合同编就有几百条检索时还是得二次筛选。最细的拆法是以“条”为单位一条一个块。但这样又太碎了因为很多法律问题需要同时看好几条才能得出结论。我实测下来比较合理的粒度是**“主题簇”**把解决同一个现实问题的若干条文打包成一个知识块。比如“租赁合同纠纷”这个簇里面包含租赁合同定义、出租人维修义务、承租人解除权、租金支付规则等七八条相关法条。每个簇配一个“场景描述”和“关键词列表”方便检索时匹配。具体操作上我建议按这个流程走通读目录建立一级分类。以《民法典》为例就是七编加附则。在每个一级分类下按“现实问题”划分二级分类。比如合同编下面可以分出“买卖合同”“租赁合同”“借款合同”“服务合同”等。在每个二级分类下把相关条文归拢成知识块。一个知识块通常包含3到10条法条外加一段“这个块解决什么问题”的说明。给每个知识块打标签。标签分三类场景标签如“租房”“买房”“借钱”、法律概念标签如“违约责任”“不可抗力”、条文编号标签如“第577条”。这里有个容易踩的坑不要试图一次性拆完整本书。我第一版尝试把整本《民法典》拆完结果拆到第三编就发现前面的分类逻辑有问题返工成本极高。后来改成“先拆一个编跑通流程再复制到其他编”效率高很多。3.2 检索策略关键词匹配和语义检索怎么配合知识块拆好之后下一个问题是“用户提问时怎么找到最相关的块”。纯关键词匹配的问题是用户不会按法条术语说话——他说“房东不退押金”不会说“租赁合同押金返还请求权”。纯语义检索的问题是法律术语的向量表示可能很接近但实际含义差别很大比如“定金”和“订金”在语义上几乎一样法律效果却完全不同。我的做法是混合检索先用关键词做粗筛再用语义相似度做精排。关键词粗筛的规则可以这样设计从用户问题中提取名词和动词匹配知识块的场景标签和概念标签。比如“房东不退押金”提取出“房东”“押金”“退”匹配到“租赁合同”簇下的“押金返还”块。如果关键词匹配不到再走语义检索兜底。语义精排则是把粗筛出来的候选块通常5到10个和用户问题一起送进模型让模型判断哪个块最相关。这一步的提示词可以写成“以下是若干法律知识块请判断哪个块与用户问题最相关输出块编号和判断理由。”注意混合检索的权重需要根据场景调。法律咨询场景下关键词匹配的权重应该高于语义检索因为法律术语的精确性比语义泛化更重要。3.3 输出模板让AI的回答像法律意见书而不是聊天记录输出模板是skill的“面子”也是用户感知最直接的部分。一个没有输出模板的skill回答质量完全看模型心情有了输出模板每次回答的结构都稳定可控。我参考了几份真实的律师函和法律意见书提炼出一个四段式模板结论一句话回答用户的核心问题。比如“你可以要求房东在合理期限内维修逾期不修可以自行维修并要求房东承担费用。”法律依据列出支撑结论的具体法条格式为“《民法典》第XXX条条文原文”。操作建议分步骤告诉用户接下来怎么做。比如“第一步书面通知房东第二步保留维修票据第三步如果房东拒绝承担可以向法院起诉。”风险提示提醒用户注意的边界条件。比如“自行维修前务必通知房东否则可能无法主张费用。”这个模板的好处是用户哪怕只看第一段也能得到答案想看细节可以往下读想行动可以照着第三步做想评估风险可以看第四段。而且这个结构对AI来说很好执行因为每一段的任务都很明确。3.4 边界约束法律skill不能做什么法律类skill最危险的地方在于“用户会当真”。如果AI给出一个错误的法律建议用户照着做了后果可能很严重。所以边界约束不是可选项是必选项。我在skill里写死了几条硬约束涉及刑事案件的直接建议报警并咨询执业律师不提供具体法律分析。涉及正在进行的诉讼的不预测判决结果只做程序性说明。涉及具体金额计算的给出计算公式但注明“具体金额以实际证据和法院认定为准”。每次回答末尾必须加一句“以上内容仅供参考不构成正式法律意见建议咨询执业律师”。这些约束要写在skill的“系统提示词”最前面并且用强指令语气比如“你必须”“你绝对不能”。实测下来把约束放在提示词开头比放在结尾有效得多。4. 实操过程从零复现一个法律skill的完整步骤4.1 环境准备你需要哪些工具和账号复现这个项目不需要太复杂的工具链。我用的配置是一个支持skill/插件功能的AI平台。豆包、Coze、Dify都可以选你顺手的。我主要用豆包做测试因为它的skill配置界面比较直观。一个文本编辑器。VS Code就行用来整理知识块和写提示词。一个GitHub账号。用来参考开源项目比如搜“book-to-skill”“agent skill”能找到不少现成的模板。《民法典》全文的电子版。网上有很多整理好的版本建议找带条文编号的方便后续引用。如果你打算把skill做成可分享的插件还需要了解目标平台的skill打包格式。豆包的skill通常是一个JSON配置文件加若干知识文件GitHub上有些项目会提供转换脚本。4.2 知识库构建从PDF到结构化知识块的完整流程假设你手头有一份《民法典》的PDF接下来要把它变成结构化知识块。我的操作流程是这样的第一步文本提取。用任何PDF转文本工具把全文导出来注意保留条文编号。如果PDF是扫描版需要先做OCR。第二步按条切分。写一个简单的脚本用正则表达式匹配“第XXX条”作为分隔符把全文切成独立条文。Python示例import re with open(minfadian.txt, r, encodingutf-8) as f: text f.read() # 匹配第X条格式支持中文数字 pattern r(第[一二三四五六七八九十百千]条) parts re.split(pattern, text) # 重组为(条文编号, 条文内容)的列表 articles [] for i in range(1, len(parts), 2): articles.append({ number: parts[i], content: parts[i1].strip() })第三步人工归簇。这一步没法完全自动化需要你根据法律逻辑把相关条文归到一起。我的做法是先按编章分大类再在每个大类下按“现实问题”分小簇。比如合同编下先分出“买卖合同”“租赁合同”“借款合同”等再把每个合同类型相关的条文归拢。第四步写簇描述。每个知识簇配一段100字左右的说明讲清楚“这个簇解决什么问题”“包含哪些关键条文”“常见应用场景是什么”。这段描述会作为检索时的匹配文本。第五步打标签。给每个簇打上场景标签、概念标签、条文编号标签。标签数量控制在5到15个之间太少检索不准太多噪音大。整个流程走下来一本《民法典》大概能拆出200到300个知识簇。这个数量级对检索来说比较友好既不会太粗也不会太碎。4.3 提示词编写让AI按法律逻辑思考的指令设计提示词是skill的“大脑”。我写提示词的习惯是分四段角色定义、任务流程、输出格式、边界约束。角色定义部分要明确AI的身份和知识范围。比如“你是一个法律知识助手专门基于《中华人民共和国民法典》回答民事法律问题。你的知识来源仅限于提供的知识块不得引用知识块之外的法条。”任务流程部分要写清楚AI拿到问题后的处理步骤。我的写法是提取用户问题中的事实要素当事人、行为、争议点。从知识库中检索最相关的知识块。判断法律关系类型合同、侵权、婚姻家庭等。匹配具体法条给出结论。按输出模板组织回答。输出格式部分直接给出模板并用示例说明。比如【结论】 一句话回答 【法律依据】 - 《民法典》第XXX条条文原文 【操作建议】 1. ... 2. ... 【风险提示】 - ...边界约束部分用强指令语气把不能做的事情列清楚。我通常会写五六条覆盖刑事、诉讼、金额计算、律师替代等场景。实操心得提示词写完后一定要做“对抗测试”。故意问一些边界问题比如“帮我写一份离婚协议书”“这个案子我能赢吗”看AI会不会越界。如果越界了就在约束里补一条。4.4 测试与调优怎么判断一个skill是否合格skill做完之后我一般用三个维度来评估准确率随机抽20个真实法律问题看AI给出的法条引用是否正确。法律场景下引用错误是致命伤。我测试时发现模型有时会把“第577条”和“第578条”搞混因为这两条都和违约责任相关。解决办法是在知识块里把易混淆的条文放在一起并加一段“区分说明”。稳定性同一个问题问三遍看输出结构是否一致。如果三次回答格式都不一样说明输出模板没锁死。我通常会在提示词里加一句“无论用户如何提问你的回答必须严格遵循上述四段式结构”。边界遵守率故意问10个越界问题看AI是否都能正确拒绝或引导。这个指标比准确率更重要因为法律建议出错的后果太严重。调优的优先级是边界遵守率 准确率 稳定性。边界问题不解决其他做得再好也不能上线。5. 常见问题与排查技巧实录5.1 检索不准用户问AAI答B怎么破这是最常见的问题。用户问“公司拖欠工资怎么办”AI却扯到“劳动合同解除的经济补偿”。原因通常是知识簇的标签没打全或者检索权重设置不合理。排查思路分三步先看用户问题提取的关键词是否命中了正确的知识簇再看语义检索的候选列表里有没有正确答案最后看模型在精排环节是否选错了块。解决办法通常是补标签和调权重。比如“拖欠工资”这个场景除了打“劳动报酬”标签还要打“工资支付”“劳动监察”“仲裁时效”等关联标签。权重方面把场景标签的匹配权重调到概念标签的1.5倍实测能明显提升准确率。5.2 输出跑偏AI不按模板回答怎么办有时候AI会把四段式回答写成一大段散文或者漏掉“风险提示”部分。这通常是因为提示词里的格式约束不够强或者用户问题太复杂导致模型“忘了”格式。我的处理办法是在提示词里加“格式检查”步骤让AI在输出前先自查“是否包含结论、法律依据、操作建议、风险提示四个部分”。另外把输出模板放在提示词的最后面因为模型对末尾内容的注意力通常更强。如果还是跑偏可以在skill里加一个“后处理”环节用另一段提示词对AI的原始输出做格式校验和重排。虽然多了一次调用但稳定性提升很明显。5.3 边界失效AI给出了不该给的建议这是最危险的问题。我测试时遇到过AI建议用户“直接搬走不付租金”的情况这明显越界了。排查后发现是边界约束写得太笼统模型没理解“不能建议违约行为”这条。解决办法是把边界约束写具体。不要写“不能给出违法建议”要写“不能建议用户采取任何可能构成违约、侵权或违法的行为包括但不限于拒付租金、擅自搬离、私自扣押对方财物”。越具体的约束模型越容易执行。另外可以在skill里加一个“敏感词触发”机制当用户问题涉及“打架”“报警”“坐牢”等词时自动切换到“建议咨询律师”的保守回答模式。5.4 常见问题速查表问题现象可能原因排查方法解决措施检索结果不相关标签缺失或权重不合理检查关键词命中情况补标签、调权重输出格式不稳定提示词格式约束弱对比多次回答结构强化格式指令、加后处理边界约束失效约束描述太笼统测试越界问题写具体约束、加敏感词触发法条引用错误知识块切分粒度问题核对条文编号调整切分粒度、加区分说明回答太长或太短输出模板没锁死检查模板执行情况明确字数范围、加示例5.5 独家避坑技巧我踩过的三个坑第一个坑是“贪大求全”。我一开始想把整本《民法典》加所有司法解释都塞进去结果知识库太庞大检索精度反而下降。后来砍掉司法解释只保留《民法典》本体准确率反而提升了。建议先做最小可用版本跑通再扩展。第二个坑是“忽视用户语言”。法律术语和日常用语差距很大用户说“离婚”法条里写“解除婚姻关系”用户说“借钱不还”法条里写“借款合同违约责任”。如果知识块的标签只用法律术语检索命中率会很低。后来我在每个知识块里都加了“日常用语”标签效果立竿见影。第三个坑是“忘了更新机制”。法律是会变的虽然《民法典》刚颁布不久但司法解释和指导案例在不断更新。如果skill没有更新机制过一段时间就会过时。我的做法是在skill里加一个“版本号”和“最后更新日期”并定期检查是否有新的司法解释需要纳入。6. 这个思路还能怎么扩展从法律到其他领域的迁移把《民法典》做成skill这件事真正有价值的地方不在于法律本身而在于它验证了一套“把厚书变成AI技能”的方法论。这套方法论可以迁移到很多场景。比如公司内部制度。每个公司都有一本员工手册里面写着报销流程、请假规则、绩效考核标准。新员工入职时总要问HR各种问题HR也烦。如果把员工手册做成skill新员工直接问AI就能得到答案HR只需要处理例外情况。再比如产品说明书。很多软件产品的帮助文档又长又难搜用户遇到问题只能去论坛发帖。如果把说明书做成skill用户问“怎么导出数据”“怎么设置权限”AI直接给出步骤和截图位置客服压力能小很多。还有医学指南。临床指南动辄几百页基层医生很难快速查阅。如果把常见病的诊疗指南做成skill医生输入症状和检查结果AI给出诊断建议和用药参考虽然不能替代医生判断但能提高效率。这些场景的共同点是知识本身是结构化的、问题是重复出现的、回答需要遵循固定逻辑。只要满足这三个条件book-to-skill的思路就能用。我自己后来把公司的一份技术文档做成了skill内部测试时同事反馈“比翻文档快多了”。踩过的坑和做法律skill时几乎一样知识拆解粒度、检索权重、输出模板、边界约束。所以这套方法确实有通用性。最后再分享一个小技巧做skill之前先花半小时观察用户最常问的20个问题。把这20个问题作为测试集skill做完后逐个测试。如果这20个问题都能答对基本就能上线了。这比漫无目的地调优效率高得多。