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 内部系统名速查表（看到任意一个就强烈建议触发检索）：

   类别	系统	主要功能
   账号权限	LionKing	账号与权限管理（功能权限、数据权限）；也接管第三方平台
   AI 驱动的组织操作系统	Phoenix	定位为企业的 数字中枢 ，整合知识、人才、协作、流程与安全治理，支持人机协同与多智能体协作
   AI 智能平台	Dragon	不仅是多模型 AI 对话平台，更是 智能运营中枢 ，融合 AI 能力、知识管理、业务流程自动化，帮助企业实现降本增效、提升客户体验、沉淀知识资产
   工作流编排	Beaver	可视化工作流编排平台 ，用户可通过拖拽式设计器自主创建、调试、发布、监控工作流
   业务前台	Shopping	面向下游客户（ToB）的酒店预订平台
   业务前台	EBooking	酒店管理系统 + 房间库存录入（面向上游供应商）
   价格库存	Wolf / Wolf 2.0	房型价格调整，CSA 上线/下线管理
   客户管理	AngryBirds / CRM	客户关系管理（客户信息、销售跟进、商机管理）
   数据分析	Analysis / Whale / Whale 2.0	数据分析系统
   运营	Admin	后台管理
   运营	Marketing	营销相关
   业务系统	Tiger / Bingo	业务系统
   BDS	Kangaroo	BDS 使用
   财务	Finance	财务系统（第三方支付对接、流水计算）
   内容	Content（内容系统）	维护酒店静态信息，数据格式映射
   部署运维	Dolphin	部署、配置、监控（含 dolphin-cms 配置中心）
   监控	Grafana	监控系统（dida 内部 Grafana 实例）
   接口网关	API 渠道系统	接收 Client API 请求，调用供应商系统
   接口网关	API 供应商系统（Supplier Service / SS）	访问上游 Supplier，返回房型信息
   客服	客服系统	处理异常订单
   自研开关	Penguin / Panda / AutoLine / FalconService / f-operating / f-supplier / f-analysis / f-order / f-policy / f-profit / f-monitor / EBookingBookingAPI	系统自动开关、流程编排类自研服务
   办公环境	Wuying / 无影	阿里云工作空间（全员工使用）

   注意：表里有些名字（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 再试一次，不要直接抛弃整次检索。
• 如果用户明确说"不用查知识库"或"直接回答"，遵从用户意图，本次跳过。