Dragon Knowledge Search

Dragon 知识库智能检索

这个 skill 解决什么问题

公司内部开发任务里，很多关键上下文（架构、接口字段、部署流程、内部库用法、业务规则）只存在于私有知识库 Dragon 里，公网搜不到。Claude 默认不会主动去查，导致回答只能靠通用知识硬猜，结果常常不贴合公司实际情况。

这个 skill 让 Claude 在判断到"用户在做内部工作"时，主动调用 dragon-knowledges MCP 暴露的 KnowledgePlugin__knowledge_base_search 工具，把内部上下文带进回答里。

何时触发检索

下面的信号任意一条命中，就值得查一次。

触发信号

1. 指代信号 — 用户用"我们的""公司的""这个项目的""内部的""线上"等修饰主语

• "我们的订单服务怎么处理超时"
• "公司内部网关的鉴权字段是什么"
• "这个项目的发布流程是什么"

2. 专有名词信号 — 出现明显非公开的系统名、服务名、项目代号、内部域名（如 *.didainternal.com）或缩写。判断标准：这个词放进 Google 没有合理结果，或在 dida 公司语境下指向特定内部系统。

• "Dragon-Open-API 怎么对接"
• "内部 IAM 服务的 token 刷新机制"

dida 内部系统名速查表（看到任意一个就强烈建议触发检索）：

注意：表里有些名字（Tiger、Bingo、Kangaroo、Penguin、Panda、Whale、Dolphin、AngryBirds、Grafana 等）单独看是通用词，但只要出现在内部开发/运维上下文里（接 "系统"/"上线"/"接口"/"配置"/"权限"/"灰度"/"环境" 等动词或场景词），就视为强信号。Grafana 虽是开源工具，但在 dida 用户的语境里基本指内部实例；同理 Dolphin 在这里指公司部署系统，不是开源 Dolphin Scheduler。

3. 业务/流程信号 — 问业务规则、产品逻辑、审批流、告警阈值、错误码含义。这类内容公网查不到。

• "退款审批流程是怎样的"
• "告警阈值 P0 是多少"

4. 接口/字段信号 — 问某个 API 字段含义、错误码、回调结构，且字段名不是开源框架里的标准命名。

• "回调里 status=99 是什么意思"
• "下单接口的 bizType 字段都有哪些值"

5. 运维/配置信号 — 问发布流程、灰度策略、配置项、监控配置、环境变量，并且明显和具体环境绑定。

• "灰度发布怎么配"（在内部上下文里）
• "测试环境的 collectionId 是多少"

6. 隐性信号 — 用户在内部代码仓库下工作（路径包含公司项目名，比如 Dragon-MCP-Test1），问的代码涉及自定义中间件、自研 SDK、看着不像开源的导入。

不要触发的场景

这些查公网更靠谱，强行查内部知识库只会浪费时间、稀释回答质量：

• 通用语言/框架问题：Python list 用法、React hooks 原理、Go channel 语法
• 知名开源库的标准用法：Spring Boot 配置、Express 中间件、MySQL 索引语法
• 纯代码风格问题：重命名、格式化、抽函数
• 算法、数据结构、数学
• 闲聊、确认性问答、礼貌性回应

边界判断

判断不准时，倾向于查。 一次 KnowledgePlugin__knowledge_base_search 调用是廉价的；漏查导致回答错或太空泛是昂贵的。如果你在心里问自己"这个会不会内部有特殊定义？"，答案大概率是肯定的——那就查。

如何调用

先告诉用户一声

用户偏好"先说一声再检索"的风格，不要静默调用。在调用前用一句话说明意图，例如：

• "我先查一下 Dragon 知识库看看有没有相关资料。"
• "这个看起来涉及内部约定，我搜一下知识库。"
• "先在知识库里找下 XXX 的定义。"

理由：让用户知道这个回答是基于内部资料，便于他们追溯和判断。

调用工具

工具名：KnowledgePlugin__knowledge_base_search 唯一参数：query（字符串）

工具的参数说明里写得很清楚——"建议使用完整、明确的问题句"。所以不要传关键词堆，要传一个人能看懂的完整问句。

query 写法

例 1：

• 用户原话："订单回调字段 status=99 是啥意思"
• ✅ 好的 query："订单服务回调中 status 字段值为 99 时的业务含义是什么"
• ❌ 差的 query："status 99"（关键词太少，检索匹配差）

例 2：

• 用户原话："这个网关怎么配灰度啊"
• ✅ 好的 query："内部 API 网关如何配置灰度发布策略"
• ❌ 差的 query："网关 灰度"

例 3：

• 用户原话："发布流程"
• ✅ 好的 query："本项目的发布上线流程和操作步骤"
• ❌ 差的 query："发布流程"（缺主语，检索语义模糊）

多个子问题分开查

如果用户问题包含多个独立子问题（例如同时问"字段含义"和"调用频率限制"），分多次调用，每次一个完整问题。比把所有关键词塞进一次检索效果好得多。

多轮检索

第一次结果不够时，根据返回内容里出现的内部术语再查一轮。比如知识库返回提到某个内部组件名但没解释清楚，就用这个组件名再问一次。不要在第一次结果不理想时就放弃。

如何把检索结果整合到回答

• 直接覆盖：检索结果直接回答了问题——引用关键内容并标明"来自 Dragon 知识库"，让用户能溯源。
• 部分覆盖：结果只覆盖了一部分——把"知识库说的"和"通用知识/合理推断"分开讲清楚，不要把通用猜测包装成内部资料。
• 没查到：明确告诉用户"知识库里没找到 XXX 相关内容"，再用通用知识回答——不要静默失败让用户以为是查到的。
• 不要伪造来源：保持回答和检索结果可追溯，不确定的就说不确定。

示例

示例 1：强信号，直接触发

用户：我在写订单服务的回调处理，需要知道 status 各个值的含义

Claude："我先查一下 Dragon 知识库订单回调字段的定义。" → 调用 KnowledgePlugin__knowledge_base_search，query="订单服务回调中 status 字段各取值的业务含义" → 根据返回结果整理回答，并标明来源

示例 2：通用问题，不触发

用户：用 Python 写一个保持顺序的列表去重

Claude：直接给代码，不调用知识库（这是通用编程问题，公网知识足够）。

示例 3：隐性信号，触发

用户：帮我在 d:/downloads/Dragon-MCP-Test1/order_service.py 里加个回调 handler

Claude：路径包含内部项目名，且是"加 handler"这种和项目约定强相关的任务。 "我先查一下 Dragon 知识库这个项目里 handler 的写法约定。" → 调用检索 query="本项目订单服务回调 handler 的实现规范和接口约定" → 然后写代码

示例 4：多子问题，分开查

用户：这个内部网关的鉴权机制是什么？另外 QPS 限制怎么配？

Claude："涉及两个内部约定的问题，我分别查一下。" → 第一次 query="内部 API 网关的鉴权机制和 token 校验流程" → 第二次 query="内部 API 网关的 QPS 限流配置方法" → 综合两次结果回答

示例 5：边界场景，倾向于查

用户：写一个重试装饰器

Claude：单看是通用问题，但用户在内部项目目录下工作。 "我先看看 Dragon 知识库里有没有内部统一的重试规范——如果有就按规范写。" → 调用 query="本项目或公司内部统一的重试机制规范和最佳实践" → 如果查到就按规范写，没查到就给通用实现并说明"知识库没找到统一规范，按通用做法实现"

调试与失败处理

• 如果 dragon-knowledges MCP 不可用（连接失败/超时），告诉用户"知识库当前无法访问，先用通用知识回答"，然后照常回答——不要因为 MCP 故障就拒绝任务。
• 如果检索结果完全无关（噪声），用更具体的 query 再试一次，不要直接抛弃整次检索。
• 如果用户明确说"不用查知识库"或"直接回答"，遵从用户意图，本次跳过。

dragon-knowledge-search-skill

注意

使用这个skill之前，需先安装MCP: dragon-knowledges