kangarooking 搜索与知识检索集成
R — 原文 (Reading)
跨供应商系统提示词中浮现的搜索策略模式：Claude Web 的"自信不是跳过搜索的理由"、Perplexity 的"追问必须重新搜索"、Gemini 的多查询策略（至少一个问题式+一个关键词式）、Notion AI 的"搜索很便宜，默认每次首次交互都搜"。Le Chat 对所有当代公众人物强制搜索，NotebookLM 则完全不搜索——纯源文档引用。核心分歧点在于搜索的门槛：从"能不搜就不搜"到"默认每次都搜"。
I — 方法论骨架 (Interpretation)
- 搜索优先策略 (search_first) — 对时效性信息、事实性声明、当代人物/事件，搜索是默认动作而非可选动作
- 多查询组合 — 单次搜索至少发出两种不同形态的查询：自然语言问题式 + 关键词式，覆盖不同索引模式
- 源优先级层级 — 企业数据 > 授权语料库 > 公共网页搜索 > 社交媒体，按场景定义层级
- 追问重新搜索原则 — 不假设前次结果在追问时仍然有效，每次实质性问题都重新检索
- 领域专用搜索规则 — 金融=单实体聚焦、本地=地理编码、旅行=交通+酒店、体育=完整上下文
- 搜索成本感知 — "搜索很便宜、安全且快速，用户愿意等待"（Notion AI），降低搜索门槛
- 无搜索例外 — 纯源文档场景（NotebookLM）用逐句引用替代搜索，保证忠实度
A1 — 案例分析 (Past Application)
案例: Gemini 多查询强制策略
- 问题: 单一查询无法覆盖用户意图的不同表述维度，导致搜索结果遗漏关键信息
- 设计模式的使用: Gemini 3.1 Pro 系统提示词要求每次搜索至少发出两个查询：一个自然语言问题式查询（捕捉语义）加一个关键词式查询（捕捉精确匹配），且所有查询必须使用用户的原始语言
- 结论: 多查询策略将信息检索从"猜一个最佳查询"升级为"多角度覆盖"，显著降低信息遗漏率
案例: Perplexity 追问重新搜索原则
- 问题: 用户追问时，系统倾向于复用前次搜索结果以节省时间和 token，但信息可能已过时
- 设计模式的使用: Perplexity 系统提示词明确规定："追问时始终重新搜索，而非假设前次结果仍然足够"
- 结论: 该策略牺牲了效率换取了准确性，尤其在新闻、金融等高时效性场景中效果显著
案例: NotebookLM 的反搜索模式
- 问题: 通用搜索可能引入外部信息污染对源文档的忠实解读
- 设计模式的使用: NotebookLM 完全不搜索，严格基于用户上传的源文档，配合逐句引用机制确保每个声明都可追溯
- 结论: 在需要高忠实度的场景（学术分析、法律文档）中，"不搜索"反而是正确策略
A2 — 触发场景 (Future Trigger) ★
用户在什么情境下需要?
- 设计需要联网能力的 AI 助手系统提示词，需要定义"何时搜、搜什么、搜几个"
- 构建企业知识库问答系统，需要定义内部语料库与外部搜索的优先级关系
- 为垂直领域 AI（金融、医疗、法律）设计搜索策略，需要领域专用规则
- 优化现有 AI 产品的搜索触发率——用户反馈"信息过时"或"回答缺少最新数据"
- 设计研究型 AI 产品（如 Deep Research），需要多轮搜索与结果整合策略
语言信号
- "AI 回答的信息过时了"
- "需要引用最新数据/新闻"
- "先搜索再回答，不要凭记忆"
- "企业内部知识优先于网络搜索"
- "每次追问都要重新查一下"
与相邻 skill 的区分
- 与
context-management的区别: context-management 管理已有上下文的压缩和加载，本 Skill 管理外部信息的获取时机和策略 - 与
conversation-flow的区别: conversation-flow 管理对话路由和澄清策略，本 Skill 专注于搜索决策（搜不搜、搜几个、搜哪里）
E — 可执行步骤 (Execution)
定义搜索触发规则矩阵 — 完成标准: 建立按内容类型（时效性/事实性/人物/观点）和时效要求（实时/近期/历史）的二维矩阵，明确每种组合下的搜索策略（强制搜索/建议搜索/可选搜索/禁止搜索）
设计多查询组合模板 — 完成标准: 为每个搜索触发点定义至少两种查询形态（问题式 + 关键词式），包含语言保持规则（使用用户原始语言）和查询扩展策略
建立源优先级层级 — 完成标准: 定义至少三层源优先级（如：企业语料库 > 授权数据库 > 公共网页），包含跨源冲突时的裁决规则和降级策略
编写追问搜索策略 — 完成标准: 明确规定追问场景下的搜索行为——至少区分"信息补充型追问"（重新搜索）和"逻辑澄清型追问"（不搜索），包含时间窗口判断（超过 N 分钟必须重新搜索）
添加领域专用搜索参数 — 完成标准: 为金融（单实体聚焦+时间范围）、本地（地理编码+距离半径）、旅行（交通+住宿+天气联合查询）、体育（完整赛事上下文）等垂直领域定义专用搜索参数集
B — 边界 (Boundary) ★
不要在以下情况使用
- 纯数学/逻辑推理任务——搜索不会比模型推理更准确
- 创意写作/文学创作——外部搜索可能干扰创意一致性
- 已有完整上下文的封闭文档问答（NotebookLM 模式）——搜索会引入噪音
- 实时性要求极低的历史/哲学讨论——模型内化知识已足够
常见失败模式
- 搜索过度：每次回复都搜索即使用户只是在闲聊，增加延迟和成本却无信息增益
- 单查询依赖：只用一种查询形态，遗漏不同索引维度的信息
- 源优先级倒置：公共网页信息覆盖了企业内部权威数据，导致回答偏离业务事实
- 追问不重新搜索：复用过时结果回答追问，在新闻/金融场景中产生幻觉
- 忽视语言一致性：用英语搜索再翻译回中文，丢失查询精度和文化语境