# Dragon Knowledge Search

> 在用户做 dida(道旅科技) 公司内部项目相关的开发、写代码、写文档、查接口、排查部署或运维问题时，主动检索 Dragon 私有知识库（通过 dragon-knowledges MCP 的 KnowledgePlugin__knowledge_base_search 工具），获取内部技术文档、架构设计、API 规范、字段定义、业务流程、错误码、配置和运维资料。务必在以下场景主动触发，不需要用户显式说"用 Dragon"或"查知识库"：用户提到"我们的"/"公司的"/"内部"/"这个项目的"/"线上"等指代内部资产；用户提到任意 dida 内部系统名（如 Beaver、Phoenix 、LionKing、Shopping、EBooking、Wolf、Wolf 2.0、AngryBirds、CRM、Analysis、Whale、Admin、Marketing、Tiger、Bingo、Kangaroo、Finance、Content、Dolphin、Grafana、Penguin、Panda、AutoLine、FalconService、f-operating、f-supplier、f-analysis、f-order、f-policy、f-profit、f-monitor、EBookingBookingAPI、Wuying/无影、客服系统、API 渠道系统、API 供应商系统、Supplier Service/SS、BDS）；用户问业务规则、产品逻辑、审批流、告警阈值、错误码含义；用户问某个 API 字段、回调结构、内部 SDK 用法且字段名不像开源框架；用户问发布/灰度/部署/配置/监控且和具体内部环境绑定；用户在公司内部代码仓库里写代码、改 bug、写注释或写文档；用户提到 didainternal.com 域名或类似内部域名。当判断不准时倾向于查——一次内部检索成本远低于"答错或答得太通用"的代价。Use this skill aggressively whenever the user is doing internal dida company development work, even without explicit mentions of Dragon/knowledge base.

- Skill: `heinerwong/dragon-knowledge-search` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add heinerwong/dragon-knowledge-search`
- Raw SKILL.md: https://api.skillmd.com/api/skills/heinerwong/dragon-knowledge-search/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: heinerwong (https://skillmd.com/u/heinerwong)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/heinerwong/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 再试一次，不要直接抛弃整次检索。
- 如果用户明确说"不用查知识库"或"直接回答"，遵从用户意图，本次跳过。