search-integration

name	search-integration
description	当系统提示词需要定义 AI 模型何时搜索、如何搜索、搜索哪些数据源、以及如何处理搜索结果时调用此 Skill。适用于所有涉及实时知识检索的 AI 产品设计——聊天机器人、研究助手、企业知识库问答等。不适用于：纯离线场景（无搜索能力的环境）、已完全内化的知识问答（如数学推导）、创意生成任务。当需求仅涉及"从本地文件读取内容"而非"联网检索外部信息"时，这不是最佳 Skill。
tags	["搜索策略","知识检索","多源查询","时效性","引用规范"]
related_skills	["context-management","conversation-flow"]

搜索与知识检索集成

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 模式）——搜索会引入噪音
• 实时性要求极低的历史/哲学讨论——模型内化知识已足够

常见失败模式

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