1. 项目概述：当法律AI“变笨”时，我们在解决什么？

最近在深度使用Claude-for-Legal这个专门为法律领域调优的AI模型时，我遇到了一个挺有意思，也相当棘手的问题： 平铺Skill/MCP导致准确率下降 。简单来说，就是当你为了让AI能处理更多类型的法律任务，一股脑儿给它“喂”了很多功能模块（Skill）或者通过模型上下文协议（MCP）接入大量外部工具后，你会发现，这个原本在单一任务上表现精专的“法律专家”，突然开始“犯糊涂”了，回答质量出现肉眼可见的滑坡。

这可不是个小问题。想象一下，你精心训练或微调了一个擅长审阅合同的AI，希望它也能顺便帮你做做法律检索、生成咨询意见。你满怀期待地给它加装了这些新能力，结果却发现，它连最拿手的合同审阅都开始出错，漏掉关键条款的风险点，或者对法律术语的理解变得模棱两可。这种“能力越多，水平越差”的现象，在复杂专业领域尤为致命。对于法律这种高精度、高风险的场景，准确率的轻微下降都可能带来严重的后果。

所以，这个项目标题“剖析Claude-for-Legal，解决平铺Skill/MCP准确率下降问题”，直指当前法律AI应用落地的一个核心痛点。它不仅仅是技术调试，更关乎如何让专业大模型在扩展能力边界的同时，守住其专业性的底线。本文将基于我处理类似问题的实践经验，深入拆解这一现象背后的原因，并分享一套从诊断到解决的实操方案。无论你是法律科技产品的开发者，还是希望更高效利用AI的法律从业者，理解这个问题及其解法，都能帮助你构建更可靠、更强大的智能法律助手。

2. 问题根源深度剖析：为什么“加法”会做成了“减法”？

要解决问题，首先得精准定位问题。Claude-for-Legal这类领域大模型出现“平铺Skill/MCP准确率下降”，并非简单的Bug，而是其底层工作机制与复杂应用场景冲突的集中体现。我们可以从以下几个层面来理解这个“减法效应”是如何发生的。

2.1 核心概念界定：什么是“平铺Skill/MCP”？

首先明确两个关键概念：

• Skill（技能） ：在AI应用框架中，通常指一个封装好的、用于完成特定任务的函数或模块。例如，“合同关键条款提取Skill”、“法律条文关联性分析Skill”、“争议焦点归纳Skill”。每个Skill都有明确的输入、输出和内部处理逻辑。
• MCP（Model Context Protocol） ：这是一种新兴的协议，旨在标准化大型语言模型（LLM）与外部工具、数据源之间的交互方式。通过MCP，Claude这类模型可以动态调用外部API、查询数据库或执行特定操作，极大地扩展了其能力边界。例如，通过MCP接入法律数据库进行实时检索，或调用电子签章系统。

所谓“平铺”，就是指在系统设计或配置中，简单地将多个Skill或MCP工具以并列、无序的方式提供给模型调用，缺乏优先级划分、场景路由和冲突解决机制。模型需要自行判断在何种情况下使用哪个工具，这对其提示词理解、任务分解和工具选择能力提出了极高要求。

2.2 准确率下降的三大核心诱因

当Skill/MCP被平铺后，准确率下降通常源于以下几个相互关联的原因：

2.2.1 注意力稀释与指令冲突 这是最根本的认知层问题。大模型基于注意力机制工作，其“思考”资源是有限的。当提示词（用户问题）同时激活多个相关的Skill或MCP工具描述时，模型内部的注意力会被分散。例如，用户问“这份NDA的保密期限是否合理？”。系统可能同时关联了“合同审阅Skill”（分析条款本身）、“法规检索MCP”（查询相关法律规定）和“历史案例比对Skill”。如果这些模块的描述权重相当，模型可能陷入“选择困难”，或者试图融合所有信息但未能抓住主次，导致输出变得笼统、偏离重点，甚至产生内部逻辑矛盾。

2.2.2 上下文污染与知识边界模糊 每个Skill或MCP工具都可能携带自身的示例、描述和参数信息。当大量此类信息被平铺在系统的上下文（如系统提示词、Few-shot示例池）中时，会造成“上下文污染”。模型可能错误地将某个Skill的特定处理逻辑或数据格式，应用到不相关的任务上。更严重的是，这可能会模糊模型自身通过微调（fine-tuning）获得的、内化的法律领域知识（Claude-for-Legal的核心价值），让模型更依赖于外部工具调用，而后者若配置不当或数据源有噪点，则会引入错误。

2.2.3 路由决策负担与错误累积 在平铺架构下，模型需要承担“路由决策”的重任：先理解问题，再判断该调用哪个（或哪几个）工具，最后整合结果。这个决策链每一步都可能出错。模型可能选错了工具（例如，用“文书生成Skill”去处理一个法律解释问题），也可能在整合多个工具结果时发生逻辑谬误。尤其是在法律领域，问题往往复杂交织，这种“自助餐”式的工具选择模式，极易导致解决方案的碎片化和不连贯性，最终反映为回答质量下降。

注意 ：这种现象在通用模型上可能不明显，因为通用模型本身知识边界宽泛，容错性高。但对于Claude-for-Legal这类深度领域模型，其优势在于对专业知识的精准把握。平铺的外部工具若干扰了这种精准性，副作用就会被放大。

3. 解决方案设计：从“平铺”到“精装”的架构演进

解决之道，绝非简单地减少Skill数量，而是要进行系统性的架构升级，从“工具集市”转向“智能调度中枢”。核心思想是： 为模型减负，让专业的工具在专业的时机，被专业地调用 。以下是经过实践验证的解决方案框架。

3.1 核心思路：引入分层决策与路由层

关键在于在用户（或上游系统）、Claude-for-Legal模型与底层Skill/MCP工具之间，增加一个 智能路由层（Orchestration Layer） 。这个层负责：

1. 意图识别 ：精准解析用户查询的真实意图和法律场景。
2. 技能匹配 ：根据意图，从技能库中匹配最合适的一个或一组技能，而非全部暴露。
3. 流程编排 ：决定技能的执行顺序和依赖关系，处理多步骤任务。
4. 结果合成 ：将各个技能的输出进行整合、去重和格式化，形成最终答案。

这样，Claude-for-Legal模型主要专注于它最擅长的部分：基于给定的、精确的上下文进行深度法律推理和内容生成，而不需要分心去管理工具。

3.2 方案一：基于规则与分类的显式路由

这是最直接、可控性最高的方法，特别适合技能边界清晰、场景相对固定的情况。

3.2.1 构建法律场景-技能映射矩阵 你需要建立一个详细的映射表。这个表不是简单的列表，而是一个多维矩阵，考虑因素包括：

• 任务类型 ：审阅、检索、起草、咨询、分析、校对等。
• 文档领域 ：公司法、劳动法、知识产权、股权投资、国际贸易等。
• 操作对象 ：合同、法条、案例、咨询问题、文书草稿等。
• 输出需求 ：风险列表、修改建议、条文摘要、对比报告、生成文本等。

例如：

用户输入关键词/意图	主要场景	优先级技能	辅助技能	应避免的技能
“审查这份劳动合同的解除条款”	合同审阅 > 劳动法	合同条款审阅Skill	劳动法规检索MCP	文书生成Skill、案例生成Skill
“根据《民法典》第584条，帮我计算一下违约金的合理范围”	法律咨询 > 合同法	法律条文解释Skill	违约金计算工具MCP	合同起草Skill、案例检索MCP
“起草一份软件著作权许可协议要点”	文书生成 > 知识产权	协议要点生成Skill	知识产权法规检索MCP	合同深度审阅Skill

3.2.2 实现路由逻辑 路由层可以是一个独立的服务（如Python FastAPI服务），它接收用户输入，通过关键词匹配、意图分类模型（可以是一个轻量级文本分类模型）或规则引擎，查询上述映射矩阵，确定本次调用的一级技能。然后，将 用户问题 和 仅选定的技能描述 ，一同构造为精准的提示词，发送给Claude-for-Legal。这确保了模型上下文的纯净和任务聚焦。

实操心得 ：规则路由的启动成本低，但维护成本会随着技能增多而上升。建议为映射矩阵配备一个管理后台，并记录每次路由的决策日志和最终效果，用于定期优化规则。初期可以从高频、高价值的场景开始构建。

3.3 方案二：基于LLM的智能动态路由

对于场景复杂、输入多变的情况，可以用一个更轻量、更通用的LLM（甚至是Claude自身的一个轻量化版本或专用提示词）来充当路由决策者。这实现了更高阶的自动化。

3.3.1 设计路由决策提示词 为路由LLM设计一个专用的系统提示词，例如： “你是一个法律AI技能调度专家。你的任务是根据用户的法律问题，从技能库中选择最合适、最少的技能来解决问题。技能库描述如下：[此处用结构化方式清晰列出所有Skill/MCP的 名称、一句话核心功能、适用场景举例 ]。请严格按以下步骤思考：

1. 分析用户问题的核心法律意图和涉及领域。
2. 从技能库中选出 唯一 一个最核心的技能。如果问题必须由多个技能协同解决，选出不超过3个，并明确主次。
3. 输出JSON格式：{“primary_skill”: “技能A”, “secondary_skills”: [“技能B”], “reasoning”: “你的思考过程”}”

3.3.2 实现与集成 工作流变为：

1. 用户请求抵达。
2. 路由服务先将请求和技能库描述发送给“路由LLM”。
3. 解析路由LLM返回的JSON，获取技能列表。
4. 根据技能列表，动态组装面向Claude-for-Legal的最终提示词，其中仅包含选定技能的详细说明。
5. 调用Claude-for-Legal并获得结果。

3.3.3 两种方案的对比与选型

特性	基于规则的路由	基于LLM的智能路由
可控性	极高 ，完全由开发者定义	中等，依赖路由LLM的稳定性
灵活性	低，对新场景需更新规则	极高 ，能处理未见过的组合场景
性能开销	低，几乎无额外延迟	较高，增加一次LLM API调用
解释性	强 ，规则清晰可追溯	弱，决策过程可能是个黑盒
适用阶段	技能库稳定、场景明确的成熟期	技能快速迭代、探索新场景的成长期

我的建议是： 两者结合，分层使用 。用规则覆盖80%的高频、关键场景，保证核心流程的绝对稳定；用智能路由处理20%的长尾、复杂场景，提供灵活性。同时，可以将智能路由的决策结果，作为优化规则库的数据来源。

4. 关键实施步骤与核心环节实现

有了架构设计，我们来看具体如何实施。以下是一个从零开始构建智能路由层，并集成Claude-for-Legal的实操流程。

4.1 第一步：技能标准化与元信息管理

这是所有工作的基础。你必须为每一个Skill或MCP工具创建一份清晰的“说明书”。

1. 建立技能注册表 ：使用一个数据库表或JSON配置文件来管理所有技能。

   {
     "skill_id": "contract_review_v1",
     "name": "合同核心条款审阅",
     "description": "针对常见合同类型（如买卖、服务、租赁），识别关键法律与商业条款，并提示常见风险点。",
     "input_schema": {"doc_text": "string", "doc_type": "enum"},
     "output_schema": {"risk_items": [{"clause": "string", "risk": "string", "suggestion": "string"}]},
     "applicable_scenarios": ["合同审阅", "风险初筛"],
     "non_applicable_scenarios": ["法律条文解释", "案例深度分析"],
     "invocation_prompt": "你是一个专业的合同律师，请基于以下条款文本进行分析...",
     "weight": 0.9
   }
   

   • applicable_scenarios 和 non_applicable_scenarios 是路由的关键依据。
   • invocation_prompt 是调用该技能时，拼接到Claude-for-Legal前的具体指令。
   • weight 可用于优先级排序。

2. 为MCP工具编写清晰描述 ：MCP Server提供的工具，同样需要被抽象为这样一个技能元数据。描述应聚焦于其功能本质，而非技术实现。

4.2 第二步：构建路由决策中心

根据你选择的方案（规则或LLM）来实现路由中心。

对于规则引擎 ，你可以使用像 Drools 、 Easy Rules 这样的框架，或者自己用Python/Node.js写一个简单的决策树。核心是维护好3.2.1中提到的场景-技能映射矩阵。

对于LLM路由 ，我强烈建议单独部署一个轻量、快速的模型来负责此事，比如DeepSeek、Qwen等的高效版本，或者直接使用Claude Haiku这类成本低、速度快的模型。关键是要 限制其输出格式 ，并 提供清晰、有限的技能列表 给路由LLM做选择，而不是让它自由发挥。

一个简单的Python伪代码示例（使用OpenAI格式API）：

async def intelligent_router(user_query: str, skills_metadata: list) -> dict:
    """智能路由函数"""
    # 1. 构建路由LLM的提示词
    router_prompt = f"""
    [系统指令如上文所述]
    技能库：
    {json.dumps(skills_metadata, ensure_ascii=False)}

    用户问题：{user_query}
    """
    # 2. 调用路由LLM
    routing_response = await call_llm_api(model="claude-3-haiku", prompt=router_prompt)
    # 3. 解析返回的JSON
    try:
        decision = json.loads(routing_response)
        return decision
    except json.JSONDecodeError:
        # 降级策略：返回一个默认技能或触发人工处理
        return {"primary_skill": "general_legal_qa", "secondary_skills": []}

4.3 第三步：上下文组装与模型调用

这是提升Claude-for-Legal表现的精髓所在。路由决策后，不是简单地把技能丢给模型，而是精心组装上下文。

1. 动态生成系统提示词 ：不要使用固定的、包含所有技能描述的长提示词。而是根据路由结果动态生成：

   你是一名专业的法律AI助手，现在请根据用户的问题，运用以下特定的专业能力来提供帮助：
   
   【核心能力：合同核心条款审阅】
   功能：针对常见合同类型，识别关键法律与商业条款，并提示常见风险点。
   调用方式：当用户提供合同文本并要求审阅时使用。
   输出要求：以清晰的列表形式，指出条款位置、风险分析和修改建议。
   
   【辅助能力：中华人民共和国劳动法法规检索】
   功能：实时查询最新的劳动相关法律法规。
   调用方式：当合同审阅涉及劳动条款，需要核实具体法条时，由你主动指示系统调用。
   
   请严格依据上述能力来分析和回答用户的问题。如果用户的问题超出这些能力的范围，请如实告知。
   

   这个提示词限定了模型的“思考范围”，极大减少了干扰。

2. 结构化用户输入与历史 ：将用户当前问题、相关的历史对话（如果有）、以及必要的文档片段，以清晰的结构（如使用XML标签）提供给模型。

3. 调用Claude-for-Legal ：将组装好的提示词发送给Claude-for-Legal API。此时，由于上下文高度相关且纯净，模型能更好地发挥其法律领域微调的优势。

4.4 第四步：结果后处理与反馈闭环

模型返回的结果可能需要进一步处理：

1. 结果解析与格式化 ：如果模型输出包含结构化数据（如JSON），确保正确解析。如果是自然语言，可以按照既定模板进行美化。
2. 工具调用执行 ：如果模型在回复中指示需要调用某个MCP工具（例如，“请查询《劳动合同法》第三十九条”），路由层需要拦截这个指令，调用相应的MCP Server，并将返回的结果再次融入上下文，可能发起新一轮的模型调用（多轮工具使用）。
3. 日志与反馈收集 ：记录完整的交互链：用户输入 -> 路由决策 -> 组装后的提示词 -> 模型输出 -> 最终答案。这为后续分析准确率下降问题提供了宝贵的数据。可以设计一个“反馈”按钮，让用户标注回答质量，用于优化路由规则和技能描述。

5. 常见问题、排查技巧与避坑指南

在实际部署和优化过程中，你会遇到各种问题。以下是一些典型问题及我的解决经验。

5.1 问题一：路由决策不准，该用的技能没用上

• 现象 ：用户问了一个很具体的公司法问题，但路由却分配给了“通用法律问答”技能，导致回答不够深入。
• 排查与解决 ：
  1. 检查技能元数据 ：首先确认“公司法问题”是否被正确标注在相关技能的 applicable_scenarios 中。描述是否足够具体？“公司法”可能太宽泛，需要细化为“股权激励”、“公司治理”、“出资纠纷”等。
  2. 优化意图识别 ：如果是规则路由，检查关键词是否覆盖不足。如果是LLM路由，分析路由LLM的“思考过程”（ reasoning 字段），看它是否误解了用户意图。可能需要优化路由提示词，加入更明确的指令，如“优先考虑专业性最强的技能”。
  3. 引入用户画像或会话上下文 ：有时单轮问题信息不足。例如，用户之前都在讨论一份投资协议，那么他接着问“回购条款有效吗？”，就应该路由到“股权投资协议审阅”技能，而不是通用的“合同审阅”。需要在路由决策时加入会话历史分析。

5.2 问题二：模型输出仍包含无关技能的内容

• 现象 ：虽然路由只选了技能A，但Claude-for-Legal的回答里，却提到了技能B或技能C的功能。
• 排查与解决 ：
  1. 检查系统提示词污染 ：这是最常见的原因。确保你动态组装的系统提示词 绝对没有 包含未被选中的技能描述。检查代码中是否有全局的、默认的提示词片段被错误地拼接了进去。
  2. 检查模型微调数据污染 ：如果Claude-for-Legal是你们自己微调的，回顾一下微调数据集中，是否混杂了多种技能任务的示例，且没有做好隔离？这可能导致模型内部产生了不应有的关联。解决方法是在微调时，为不同任务的数据打上明确的类型标签，并在提示词中强化该标签。
  3. 降低模型“创造力”参数 ：尝试将Claude的 temperature 参数调低（例如设为0.1或0.2），让它的输出更倾向于确定性，减少“自由发挥”可能带来的偏离。

5.3 问题三：多技能协作时，结果合成生硬

• 现象 ：路由正确选择了技能A和B，模型也分别调用了它们，但最终答案像是两段话的简单拼接，缺乏逻辑连贯性。
• 排查与解决 ：
  1. 设计合成提示词 ：不要仅仅把两个技能的结果扔给用户。应该设计一个“合成阶段”，让Claude-for-Legal（或另一个轻量模型）担任“合成官”。例如： “你是一名资深法律顾问。以下是关于XX问题的两份初步分析材料：材料1（来自审阅技能）侧重于……；材料2（来自检索技能）提供了……。请将这两份材料整合成一份逻辑连贯、直接回答用户问题的最终法律意见，避免重复，突出核心结论。”
  2. 明确技能主次与流程 ：在路由时，不仅选出技能，还要明确它们的执行顺序和依赖关系。例如，“先检索相关法条，再基于法条审阅合同条款”。将这个流程体现在给模型的提示词中，引导模型进行顺序思考。

5.4 性能与成本优化要点

• 路由缓存 ：对于常见、重复的问题（如“审阅劳动合同”），其路由决策结果是相同的。可以对“用户问题”的embedding进行向量化，并缓存路由结果，避免每次重复计算。
• 技能调用懒加载 ：不是所有被选中的技能都需要立即准备其全部上下文。对于MCP工具，可以在模型明确发出调用指令时再实际调用，避免不必要的开销。
• 监控与告警 ：建立关键指标监控：路由延迟、各技能调用频率、模型响应时间、用户满意度反馈（如果有）。设置告警，当某个技能的调用失败率上升或平均响应时间变长时，及时通知。

最后一点个人体会 ：解决“平铺Skill/MCP准确率下降”问题，本质上是在进行一场“AI人机交互”的设计。你不能指望一个专家（即使是AI专家）在工具堆满桌面的房间里还能高效、精准地工作。你需要扮演好“助理”或“项目经理”的角色，帮它整理桌面，在合适的时间递上合适的工具，并帮它梳理好工作成果。这个路由层和编排逻辑，就是这个“助理”的大脑。投入精力设计好它，你的Claude-for-Legal才能真正从一个“什么都会一点”的杂家，蜕变回那个在专业领域里值得信赖的专家。