---
name: Search Integration
slug: search-integration
category: AI Engineering
description: Search Integration defines when an AI should search, what sources to search, and how to handle results. Use it for real-time knowledge retrieval in chatbots, research assistants, and enterprise Q&A; it is not for offline or purely internal knowledge tasks.
github: "https://github.com/kangarooking/system-prompt-skills/tree/main/search-integration"
stars: 182
forks: 40
install: "npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/search-integration ~/.claude/skills/search-integration"
installs_to: ~/.claude/skills/search-integration
source_path: search-integration/SKILL.md
collection_size: 15
category_size: 3278
collection_url: "https://dirskills.com/collections/kangarooking/system-prompt-skills"
added: 2026-09-06T05:21:05.097Z
last_synced: 2026-09-06T05:21:05.097Z
canonical_url: "https://dirskills.com/skills/search-integration"
---

# Search Integration

Search Integration defines when an AI should search, what sources to search, and how to handle results. Use it for real-time knowledge retrieval in chatbots, research assistants, and enterprise Q&A; it is not for offline or purely internal knowledge tasks.

**Install:**

```bash
npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/search-integration ~/.claude/skills/search-integration
```

## README

# 搜索与知识检索集成

## R — 原文 (Reading)
> 跨供应商系统提示词中浮现的搜索策略模式：Claude Web 的"自信不是跳过搜索的理由"、Perplexity 的"追问必须重新搜索"、Gemini 的多查询策略（至少一个问题式+一个关键词式）、Notion AI 的"搜索很便宜，默认每次首次交互都搜"。Le Chat 对所有当代公众人物强制搜索，NotebookLM 则完全不搜索——纯源文档引用。核心分歧点在于搜索的门槛：从"能不搜就不搜"到"默认每次都搜"。

## I — 方法论骨架 (Interpretation)

1. **搜索优先策略 (search_first)** — 对时效性信息、事实性声明、当代人物/事件，搜索是默认动作而非可选动作
2. **多查询组合** — 单次搜索至少发出两种不同形态的查询：自然语言问题式 + 关键词式，覆盖不同索引模式
3. **源优先级层级** — 企业数据 > 授权语料库 > 公共网页搜索 > 社交媒体，按场景定义层级
4. **追问重新搜索原则** — 不假设前次结果在追问时仍然有效，每次实质性问题都重新检索
5. **领域专用搜索规则** — 金融=单实体聚焦、本地=地理编码、旅行=交通+酒店、体育=完整上下文
6. **搜索成本感知** — "搜索很便宜、安全且快速，用户愿意等待"（Notion AI），降低搜索门槛
7. **无搜索例外** — 纯源文档场景（NotebookLM）用逐句引用替代搜索，保证忠实度

## A1 — 案例分析 (Past Application)

### 案例: Gemini 多查询强制策略

- **问题**: 单一查询无法覆盖用户意图的不同表述维度，导致搜索结果遗漏关键信息
- **设计模式的使用**: Gemini 3.1 Pro 系统提示词要求每次搜索至少发出两个查询：一个自然语言问题式查询（捕捉语义）加一个关键词式查询（捕捉精确匹配），且所有查询必须使用用户的原始语言
- **结论**: 多查询策略将信息检索从"猜一个最佳查询"升级为"多角度覆盖"，显著降低信息遗漏率

### 案例: Perplexity 追问重新搜索原则

- **问题**: 用户追问时，系统倾向于复用前次搜索结果以节省时间和 token，但信息可能已过时
- **设计模式的使用**: Perplexity 系统提示词明确规定："追问时始终重新搜索，而非假设前次结果仍然足够"
- **结论**: 该策略牺牲了效率换取了准确性，尤其在新闻、金融等高时效性场景中效果显著

### 案例: NotebookLM 的反搜索模式

- **问题**: 通用搜索可能引入外部信息污染对源文档的忠实解读
- **设计模式的使用**: NotebookLM 完全不搜索，严格基于用户上传的源文档，配合逐句引用机制确保每个声明都可追溯
- **结论**: 在需要高忠实度的场景（学术分析、法律文档）中，"不搜索"反而是正确策略

## A2 — 触发场景 (Future Trigger) ★

### 用户在什么情境下需要?

1. 设计需要联网能力的 AI 助手系统提示词，需要定义"何时搜、搜什么、搜几个"
2. 构建企业知识库问答系统，需要定义内部语料库与外部搜索的优先级关系
3. 为垂直领域 AI（金融、医疗、法律）设计搜索策略，需要领域专用规则
4. 优化现有 AI 产品的搜索触发率——用户反馈"信息过时"或"回答缺少最新数据"
5. 设计研究型 AI 产品（如 Deep Research），需要多轮搜索与结果整合策略

### 语言信号

- "AI 回答的信息过时了"
- "需要引用最新数据/新闻"
- "先搜索再回答，不要凭记忆"
- "企业内部知识优先于网络搜索"
- "每次追问都要重新查一下"

### 与相邻 skill 的区分

- 与 `context-management` 的区别: context-management 管理已有上下文的压缩和加载，本 Skill 管理外部信息的获取时机和策略
- 与 `conversation-flow` 的区别: conversation-flow 管理对话路由和澄清策略，本 Skill 专注于搜索决策（搜不搜、搜几个、搜哪里）

## E — 可执行步骤 (Execution)

1. **定义搜索触发规则矩阵** — 完成标准: 建立按内容类型（时效性/事实性/人物/观点）和时效要求（实时/近期/历史）的二维矩阵，明确每种组合下的搜索策略（强制搜索/建议搜索/可选搜索/禁止搜索）

2. **设计多查询组合模板** — 完成标准: 为每个搜索触发点定义至少两种查询形态（问题式 + 关键词式），包含语言保持规则（使用用户原始语言）和查询扩展策略

3. **建立源优先级层级** — 完成标准: 定义至少三层源优先级（如：企业语料库 > 授权数据库 > 公共网页），包含跨源冲突时的裁决规则和降级策略

4. **编写追问搜索策略** — 完成标准: 明确规定追问场景下的搜索行为——至少区分"信息补充型追问"（重新搜索）和"逻辑澄清型追问"（不搜索），包含时间窗口判断（超过 N 分钟必须重新搜索）

5. **添加领域专用搜索参数** — 完成标准: 为金融（单实体聚焦+时间范围）、本地（地理编码+距离半径）、旅行（交通+住宿+天气联合查询）、体育（完整赛事上下文）等垂直领域定义专用搜索参数集

## B — 边界 (Boundary) ★

### 不要在以下情况使用

- 纯数学/逻辑推理任务——搜索不会比模型推理更准确
- 创意写作/文学创作——外部搜索可能干扰创意一致性
- 已有完整上下文的封闭文档问答（NotebookLM 模式）——搜索会引入噪音
- 实时性要求极低的历史/哲学讨论——模型内化知识已足够

### 常见失败模式

- 搜索过度：每次回复都搜索即使用户只是在闲聊，增加延迟和成本却无信息增益
- 单查询依赖：只用一种查询形态，遗漏不同索引维度的信息
- 源优先级倒置：公共网页信息覆盖了企业内部权威数据，导致回答偏离业务事实
- 追问不重新搜索：复用过时结果回答追问，在新闻/金融场景中产生幻觉
- 忽视语言一致性：用英语搜索再翻译回中文，丢失查询精度和文化语境