!封面
你打开你的 CLAUDE.md，里面塞着这些东西：
- 知识库检索顺序：先读理解与适用，再读法条，不够再读公众号
- 合同审核八步流程
- 法条必须用北大法宝验证
- 客户A偏好红色字体批注、客户B只要清洁版
- 法律咨询回答控制在500字以内
- 小孩数学作业的辅导步骤
- 案件分析的六阶段框架
- 凡是碰到PDF先转Markdown
每次你跟AI对话，这些规则全部被加载进去。不管你现在是在审合同、查一个劳动法问题，还是帮小孩改口算题。
然后你发现AI的行为越来越飘。明明在审合同，它突然给你的输出加了一个500字限制。明明在查法条，它开始问你要不要生成批注版。你以为是模型的问题。
不是模型的问题。
你的CLAUDE.md正在变成一个垃圾场。所有规则混在一起，不相关的互相干扰，改一条规则要小心翼翼生怕影响其他场景。根源不是规则太多——是规则放错了层级。
一个被忽视的第一性原理
法律人用AI，迟早会走到这一步：从临时对话，到建立自己的规则体系。多数人写规则的方式很直接，想到一条写一条，全部塞进当前工作区的CLAUDE.md。
问题就出在"全部塞进去"。
你真正需要的是一个分层架构：把规则按照"是否跨场景通用"拆成两层。对所有法律工作都适用的，放在用户级（全局规则）；只在特定场景生效的，放在项目级（工作区规则）。
这个设计决策，决定了你的AI系统是越来越精准，还是越来越混乱。
两层架构：一张图讲清楚
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 400">
<defs>
<marker id="arrow" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
<path d="M0,0 L8,3 L0,6 Z" fill="#555"/>
</marker>
</defs>
<rect width="600" height="400" fill="#fff" rx="4"/>
<!-- 用户级规则层 -->
<rect x="40" y="30" width="520" height="130" rx="4" fill="#f5f5f5" stroke="#333" stroke-width="1.5"/>
<text x="300" y="58" text-anchor="middle" font-size="16" font-weight="700" fill="#1a1a1a">用户级规则（全局 · 所有法律工作区自动继承）</text>
<line x1="60" y1="70" x2="540" y2="70" stroke="#ddd" stroke-width="0.5"/>
<text x="70" y="92" font-size="12" fill="#444">法律知识库检索规范</text>
<text x="240" y="92" font-size="12" fill="#444">法条效力甄别规则</text>
<text x="410" y="92" font-size="12" fill="#444">主体信用查询规则</text>
<text x="70" y="116" font-size="12" fill="#444">法律研究规范</text>
<text x="240" y="116" font-size="12" fill="#444">法律解释方法论</text>
<text x="410" y="116" font-size="12" fill="#444">法律推理方法</text>
<text x="70" y="140" font-size="12" fill="#444">检索策略规则</text>
<text x="240" y="140" font-size="12" fill="#444">法条验证规则（北大法宝）</text>
<text x="410" y="140" font-size="12" fill="#444">中文标点规范</text>
<!-- 继承箭头 -->
<line x1="300" y1="162" x2="300" y2="185" stroke="#555" stroke-width="1.5" marker-end="url(#arrow)"/>
<text x="315" y="178" font-size="10" fill="#777">自动继承</text>
<!-- 项目级规则层 -->
<rect x="40" y="190" width="520" height="170" rx="4" fill="#fafafa" stroke="#555" stroke-width="1.5"/>
<text x="300" y="218" text-anchor="middle" font-size="15" font-weight="700" fill="#1a1a1a">项目级规则（工作区专属 · 按场景差异化）</text>
<line x1="60" y1="230" x2="540" y2="230" stroke="#ddd" stroke-width="0.5"/>
<!-- 三个工作区 -->
<rect x="55" y="245" width="155" height="100" rx="3" fill="#fff" stroke="#888" stroke-width="1"/>
<text x="132" y="267" text-anchor="middle" font-size="12" font-weight="700" fill="#1a1a1a">合同审核</text>
<text x="132" y="287" text-anchor="middle" font-size="10" fill="#555">客户习惯清单</text>
<text x="132" y="305" text-anchor="middle" font-size="10" fill="#555">八步审核流程</text>
<text x="132" y="323" text-anchor="middle" font-size="10" fill="#555">批注版合同输出</text>
<rect x="225" y="245" width="155" height="100" rx="3" fill="#fff" stroke="#888" stroke-width="1"/>
<text x="302" y="267" text-anchor="middle" font-size="12" font-weight="700" fill="#1a1a1a">案件分析</text>
<text x="302" y="287" text-anchor="middle" font-size="10" fill="#555">六阶段分析框架</text>
<text x="302" y="305" text-anchor="middle" font-size="10" fill="#555">主张-要件-证据映射</text>
<text x="302" y="323" text-anchor="middle" font-size="10" fill="#555">庭前准备清单</text>
<rect x="395" y="245" width="155" height="100" rx="3" fill="#fff" stroke="#888" stroke-width="1"/>
<text x="472" y="267" text-anchor="middle" font-size="12" font-weight="700" fill="#1a1a1a">法律咨询</text>
<text x="472" y="287" text-anchor="middle" font-size="10" fill="#555">建文件夹留档</text>
<text x="472" y="305" text-anchor="middle" font-size="10" fill="#555">字数限制规则</text>
<text x="472" y="323" text-anchor="middle" font-size="10" fill="#555">附录法条原文</text>
<!-- 底部标注 -->
<text x="300" y="390" text-anchor="middle" font-size="10" fill="#999">用户级规则写一次，所有项目自动继承 / 项目级规则只写场景特有的</text>
</svg>看这张图。用户级规则在上层，是底座，所有法律工作区自动继承。项目级规则在下层，是差异化配置，每个工作区只写自己独有的那部分。
一个判断标准就能帮你分清该放哪：
"这个规则在另一个法律场景下还适用吗？"
>
如果适用 —— 用户级。
如果不适用 —— 项目级。
用户级规则：你的"法律人操作系统"
什么叫"对所有法律工作都适用的规则"？
知识库检索规范。你规定了一条规则："但凡碰到法律问题，先去读理解与适用，再读法条原文，不够再去查公众号文章。"这条规则，在合同审核场景下要用，在案件分析场景下要用，在做法律咨询的时候也要用。你是不是要在三个工作区的CLAUDE.md里各写一遍？不需要。把它写在用户级，三个工作区自动继承。
法条效力甄别。"引用的法条必须通过北大法宝验证，确认现行有效后才能作为结论依据。"所有法律工作区都需要。
主体信用查询。"材料中首次出现企业主体，自动查询工商信息、涉诉风险和失信记录。"审合同需要，做尽调需要，做案件分析也需要。
法律解释方法论。文义解释、体系解释、目的解释的三步法，所有法律推理场景共用。
这些规则的共同特征：它们描述的是"法律人用AI"这件事本身的底层逻辑，跟你当前在做什么类型的法律工作没有关系。它们就像操作系统的内核——不管你在上面跑什么应用，内核都在那里。
把通用规则沉淀在用户级，三个直接的好处：
- 只写一次。建一个新场景的工作区，你不用从零开始写规则。用户级那十几条通用规则已经在那里了，你只需要写这个场景特有的三五条。
- 一处修改，全局生效。你发现知识库检索顺序应该调整——先查案例库，再查法条——改用户级的那条规则，所有工作区同步更新。不用跑三个地方改三次。
- 不相关的规则不干扰。小孩作业辅导的规则，写在法律工作的CLAUDE.md里，每次审合同都在加载。把它放在它自己的项目级工作区里，法律工作区就清净了。
项目级规则：每个场景的"专属驾驶模式"
通用规则给了你底座，但AI真正好用，靠的是场景级的精细调校。
合同审核、案件分析、法律咨询——它们要的输出格式不同、工作节奏不同、对"做得好"的定义也不同。你不给每个场景写专属规则，AI就用同一套逻辑处理所有事情。结果每个场景都"还行"，但每个场景都不到位。
项目级规则写这个场景特有的东西。
以合同审核工作区为例。它的项目级规则至少包括：客户习惯清单（客户A偏好红色字体批注、客户B只要清洁版加一份风险摘要），八步审核流程（从识别主体到输出三件套），批注版合同的技术规范（用什么工具、生成什么格式）。这些规则出了合同审核的场景就没意义——你不可能在法律咨询里要求AI生成批注版文件。
以案件分析工作区为例。它的专属规则是六阶段分析框架、主张-要件-证据映射表、庭前准备清单。这些结构在合同审核里用不上，在咨询里也用不上。
以法律咨询工作区为例。它的专属规则可能是"每个问题建一个文件夹留档""回答限制在500字以内""文末附录相关法条原文"。这些规则是咨询场景特有的节奏：快速、简洁、可追溯。但你不能把这套逻辑套到合同审核上——审核意见写成500字，客户会打电话问你"是不是漏了什么"。
项目级规则的结构，可以按四个阶段来组织：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 160">
<defs>
<marker id="arrow2" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
<path d="M0,0 L8,3 L0,6 Z" fill="#555"/>
</marker>
</defs>
<rect width="600" height="160" fill="#fff" rx="4"/>
<!-- 四个节点 -->
<rect x="20" y="30" width="120" height="60" rx="3" fill="#f5f5f5" stroke="#333" stroke-width="1.5"/>
<text x="80" y="55" text-anchor="middle" font-size="14" font-weight="700" fill="#1a1a1a">输入</text>
<text x="80" y="75" text-anchor="middle" font-size="10" fill="#666">材料格式/来源</text>
<rect x="170" y="30" width="120" height="60" rx="3" fill="#f5f5f5" stroke="#333" stroke-width="1.5"/>
<text x="230" y="55" text-anchor="middle" font-size="14" font-weight="700" fill="#1a1a1a">处理</text>
<text x="230" y="75" text-anchor="middle" font-size="10" fill="#666">分析流程/步骤</text>
<rect x="320" y="30" width="120" height="60" rx="3" fill="#f5f5f5" stroke="#333" stroke-width="1.5"/>
<text x="380" y="55" text-anchor="middle" font-size="14" font-weight="700" fill="#1a1a1a">输出</text>
<text x="380" y="75" text-anchor="middle" font-size="10" fill="#666">格式/字数/交付物</text>
<rect x="470" y="30" width="120" height="60" rx="3" fill="#f5f5f5" stroke="#333" stroke-width="1.5"/>
<text x="530" y="55" text-anchor="middle" font-size="14" font-weight="700" fill="#1a1a1a">归档</text>
<text x="530" y="75" text-anchor="middle" font-size="10" fill="#666">文件结构/留档</text>
<!-- 箭头 -->
<line x1="140" y1="60" x2="168" y2="60" stroke="#555" stroke-width="1.5" marker-end="url(#arrow2)"/>
<line x1="290" y1="60" x2="318" y2="60" stroke="#555" stroke-width="1.5" marker-end="url(#arrow2)"/>
<line x1="440" y1="60" x2="468" y2="60" stroke="#555" stroke-width="1.5" marker-end="url(#arrow2)"/>
<!-- 下方具体示例 -->
<text x="80" y="115" text-anchor="middle" font-size="10" fill="#888">PDF先转MD</text>
<text x="230" y="115" text-anchor="middle" font-size="10" fill="#888">知识库检索→法条验证→交叉比对</text>
<text x="380" y="115" text-anchor="middle" font-size="10" fill="#888">法律意见书+批注版合同</text>
<text x="530" y="115" text-anchor="middle" font-size="10" fill="#888">按问题建文件夹，日期+主题命名</text>
</svg>四阶段框架的好处：你不需要一次性写出完美的规则。你只需要在每次使用过程中发现缺失，往对应的阶段补一条。输入环节缺了格式转换规则？补上。输出环节发现应该附录法条原文？补上。归档环节发现文件命名混乱？补上。
规则就是这样养出来的。
规则不是写出来的，是养出来的
好用的规则不是一次性设计的，是一次次用出来的。
你建了一个法律咨询工作区，写了初始规则。第一次用它查一个问题，AI按你的规则跑了一轮，生成了一个答案。你看着这个答案，发现它的法条引用没有标出处——你在规则里加了一条"所有引用的法条必须标注来源标签"。第二次用，它标了标签，但附录里漏了两条相关法条——你又加了一条"输出必须附录所有相关法条原文"。
每用一次，改一条规则。用十次改十条，用一百次改一百条。半年以后，这个工作区的规则已经精确地刻画了你对"一个好的法律咨询答案"的全部判断标准。
这个过程本质上是一个隐性知识显性化的过程。你没有写一篇论文论述"法律咨询应该怎么做"，你只是每次看到AI的输出时，指出它哪里不够好，然后把它变成一条规则。你大脑里的判断标准，通过一条条规则的迭代，沉淀进了AI的行为里。
这不会自动发生。它需要两件事：你有一个分层架构，知道改的这条规则该放在哪一层；你有迭代的意识——不是用完就完了，每次用完之后花30秒想一想，"这一次有什么可以固化下来？"
在四明山法师AI夜校的课程里，我带学员演示过一个完整的法律咨询工作区构建过程：从零开始建文件夹，写初始规则，跑第一个问题，发现不足，改规则，再跑，再改。完整走一遍之后，学员通常会发现，初始写的规则和迭代五轮之后的规则已经是两个东西。初始规则是你"想象中的需求"，迭代后的规则是你"真实用出来的需求"。两者的差距，大得惊人。
四种最常见的错误
在实践中，最常见的错误模式有四种。
大杂烩式CLAUDE.md。
所有规则不分层级，全部塞进一个工作区的CLAUDE.md里。规则文件越来越长，每次对话加载的上下文越来越多，不相关的规则互相干扰。审合同的时候加载了案件分析的六阶段框架，做咨询的时候加载了合同审核的客户习惯清单。Token浪费还是小事，真正麻烦的是AI在多重规则冲突下，行为变得不可预测。
全放用户级。
意识到分层的重要性了，但矫枉过正——把所有规则都写在用户级。包括"合同审核输出必须附带批注版"这种明显只在合同场景生效的规则。当你做一个法律咨询的时候，用户级的那条批注版规则也在生效。AI可能会困惑：这个咨询要不要也输出一个批注版？通用规则束缚了特定场景的灵活性。
每个工作区重复写通用规则。
三个工作区的CLAUDE.md里，都写了"知识库检索规范"。三份内容一模一样。某天你发现检索顺序应该调整——先查案例库，再查法条——你要改三个地方。漏改一个，三个工作区的行为就不一致。维护成本乘三。
工作区粒度不当。
有人把每个案件建一个工作区——两个月后案件结案，工作区闲置，下次碰到同类案件又要重新建。有人把全部法律工作塞在一个工作区里——咨询、审核、诉讼全混一起，规则互相干涉。
合理的粒度是按工作类型划分：法律咨询一个、合同审核一个、案件分析一个。原因是不同类型的法律工作，规则体系不同，但同一类型内的不同案件，规则高度趋同。
什么时候不需要分层
两层架构不是银弹。以下三种情况，你可能暂时不需要操心这件事：
刚开始用AI，规则还很少。 总共就三五条规则，全部放一个CLAUDE.md也没问题。分层是在规则数量膨胀之后才产生价值的管理手段。先写规则，用到觉得乱了，再分层。
只做一个场景。 如果你只用AI审合同，没有其他法律工作场景，用户级和项目级在效果上没有区别。但建议还是分开——你不知道哪天会开始用AI做别的事。提前分层，成本很低；事后拆分，成本很高。
团队共用一套工作区。 如果你和团队成员共享同一套工作区规则，分层的逻辑会复杂很多——不同成员的用户级规则可能冲突。这种情况更适合用一个共享的项目级规则仓库，成员各自维护用户级规则。
两层架构是起点，不是终点。场景足够多、规则足够复杂时，两层可能不够用——你可能需要一个中间层（比如"房地产案件通用规则"，介于用户级和具体案件之间），也可能需要按团队角色分层。但两层已经解决了80%的混乱问题，先从这里开始。
一个可以立刻做的事
如果你已经读到这里，有一个动作可以在五分钟内完成：
打开你的CLAUDE.md，逐条过一遍你的规则。每看一条，问自己："这条规则在其他法律场景下还适用吗？"适用，标U（User）；不适用，标P（Project）。标完之后，把标P的规则留在当前工作区，把标U的规则移到用户级。
做完这一步，你下次新建一个工作区的时候，会发现你不需要复制粘贴任何通用规则——它们已经在用户级等着你了。你只需要写这个场景特有的那几条。
分层不是技术问题，是思维习惯问题。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。