搜索方法论：如何向 AI 提好问题

学习目标：掌握结构化提问框架、追问技巧和引用级验证方法，并学会给 Agent 写带预算的检索指令

预计时间：30 分钟

难度：⭐⭐

最后更新：2026 年 10 月

---

先说结论

工具会变，方法论不会。

Perplexity 可能 3 年后被替代，但「如何提好问题」「如何验证信息」「如何追问深入」这些能力，永远有用。

AI 搜索的核心不是工具，是你的提问能力。 提问质量决定回答质量。Garbage in, garbage out。

2026 年多了一件新事：你不再只是「问一次」，而是给 Agent 写一份检索指令，让它自己跑 5 轮、10 轮、20 轮。指令写得糙，Agent 就跑得越远越离谱。 这一篇后半部分专门讲这件事。

---

为什么你的提问方式决定了搜索质量

同一个话题，两种问法，结果天差地别：

# 低质量提问
「RAG 技术是什么」

# 高质量提问
「我是一个后端开发者，想在自己的项目中引入 RAG 技术
来提升文档问答的准确率。目前用的是基础的 prompt 方式，
回答经常出现幻觉。请帮我解释 RAG 的核心原理，推荐
适合小团队的开源 RAG 框架，并对比它们的优缺点。」

第一个问题，AI 会给你一段教科书式的定义。你看了等于没看。

第二个问题，AI 知道你是谁、你要什么、你遇到了什么问题、你期望什么输出。回答的针对性完全不同。

核心原则

给 AI 足够的上下文。你不会对着一个新同事只说「帮我搞一下那个东西」——对 AI 也一样。告诉它：你是谁、你在做什么、你遇到了什么问题、你期望什么样的帮助。

---

结构化提问框架：角色-背景-目标-约束

我总结了一个简单的提问框架，叫 RBGC 框架（Role-Background-Goal-Constraint）：

R - Role（角色）

告诉 AI 你的身份，让它调整回答的专业程度和语气。

# 不指定角色
「解释一下 Transformer 架构」

# 指定角色
「我是一名前端开发者，没有 NLP 背景，
请用我听得懂的方式解释 Transformer 架构」

B - Background（背景）

描述你目前的情况、已经了解什么、遇到了什么问题。

# 不提供背景
「怎么学 Rust」

# 提供背景
「我有 3 年 Python 经验，做过 Web 开发。
最近在做一个性能敏感的系统服务，想用 Rust
重写。我已经看了 Rust Book 的前 5 章。」

G - Goal（目标）

明确你想得到什么。是一个解释？一份对比？一个方案？一个推荐？

# 目标模糊
「聊聊 AI Agent」

# 目标明确
「帮我对比 LangGraph 和 CrewAI 这两个框架，
输出一份表格，包含：学习曲线、生态成熟度、
适用场景、社区活跃度。」

C - Constraint（约束）

限定回答的范围、格式、长度、时间。

# 不加约束
「推荐一些 AI 搜索工具」

# 加约束
「只考虑 2026 年还在维护、且有公开 API 的工具，
输出 3 个，每个包含：定价、检索方式（索引 API 还是
答案 API）、是否支持 MCP。价格以官网为准并标注查证日期。」

完整示例

把四个要素组合起来：

【角色】我是一个独立开发者，技术栈是 React + Node.js
【背景】我想给自己的 SaaS 产品加一个 AI 客服功能，目前
        完全没有 AI 开发经验，预算有限（月费不超过 $50）
【目标】请帮我推荐最适合的方案，包括用什么模型、怎么接入、
        大概的开发周期
【约束】只要能处理中文的方案，需要有具体的接入步骤，
        不要太学术化的解释，价格信息标注来源和日期

不必每次都写全

RBGC 框架是一个思考方式，不是一个必须填完的表格。简单问题用简单问法，复杂问题才需要四要素齐全。关键是有「给上下文」的意识。

---

追问技巧：深入、对比、验证

AI 搜索最强大的能力之一是连续对话。第一轮搜索给你基础信息，追问才能挖到有价值的内容。

深入型追问

针对某个点继续往下挖：

第 1 轮：「2026 年主流的 Agent 框架有哪些？」
追问 1：「你提到 LangGraph 适合复杂流程，能举一个具体的复杂流程场景吗？」
追问 2：「在这个场景下，LangGraph 相比 CrewAI 的具体优势是什么？」
追问 3：「有没有这个场景的开源项目可以参考？」

每一轮都在前一轮的基础上更深一步。像剥洋葱一样。

对比型追问

让 AI 从不同角度对比：

第 1 轮：「Gemini 4 Argon 和 Kimi K3 都主打长上下文和推理，
        帮我比较它们在长文档问答上的表现」
追问 1：「如果我的团队都是中文用户，两者在中文长文上的差别有多大？」
追问 2：「上下文塞到几十万字时，中间位置的信息会不会被漏掉？
        有公开的评测数据吗？」
追问 3：「两者的 API 定价差多少？按每月 1 万次调用算谁更便宜？」

验证型追问

对 AI 的回答进行质疑和验证：

第 1 轮：「AI 编程工具能提升多少开发效率？」
追问 1：「你引用的数据来源是哪里？这些数据是怎么测量的？」
追问 2：「有没有相反的研究结论？即 AI 工具降低了效率的案例？」
追问 3：「这些研究的主要局限是什么？」

追问的三个层次

1. What（是什么）：基础信息
2. Why（为什么）：原因和逻辑
3. How（怎么验证）：来源和反面观点

从 What 到 Why 到 How，信息质量逐层提升。

---

多轮对话策略

策略一：从宽到窄

第 1 轮（宽）：了解全局
  → 「2026 年 AI 搜索产品分哪几类？」

第 2 轮（窄）：聚焦到具体
  → 「在这些类型里，做 Deep Research 的有哪几个？」

第 3 轮（更窄）：深入到细节
  → 「Gemini 的 Deep Research 生成的报告，能导出成什么格式？
    有没有引用列表？」

策略二：从问题到方案

第 1 轮（问题）：描述你的困境
  → 「我的团队在代码审查上花了太多时间，有没有 AI 方案？」

第 2 轮（方案）：获取具体建议
  → 「你推荐的 GitHub Copilot Code Review 具体怎么配置？」

第 3 轮（落地）：解决实施障碍
  → 「我们用 GitLab 而不是 GitHub，有什么替代方案？」

策略三：从主张到证据

第 1 轮（主张）：AI 给出一个观点
  → AI 说「RAG 正在被长上下文模型取代」

第 2 轮（证据）：要求支持证据
  → 「这个判断的数据来源是什么？谁做的对比实验？」

第 3 轮（反证）：找反面例子
  → 「有哪些场景下长上下文仍然不够、必须用检索？」

---

给 Agent 写检索指令

这是 2026 年最重要的变化。

以前你是「操作搜索的人」：一轮一轮地问，看到不对就换词。现在是「给搜索的人下指令」：写一段 brief，Agent 自己拆子问题、自己搜、自己判断够了没有。

差别在于——你不看着它跑，所以出错也看不见。 指令必须把边界写死。

一份指令要写清的七件事

要素	写什么	不写会怎样
目标	一句话说清最终产出是什么、给谁看	Agent 跑到无关分支上去
子问题分解	你已知的关键分支（3-6 个），允许它补	漏掉你真正关心的角度
允许的信源类型	官方文档/论文/一手数据/权威媒体，以及明确排除的类型	满屏 SEO 内容农场
时间范围	只要 2025 年以后，或明确「历史沿革不限」	拿 2022 年的结论当现状
输出 schema	字段、格式、引用怎么写	回来一段没法用的大散文
停止条件	覆盖完子问题、关键结论有 ≥2 个独立来源、无新信息	无限 fan-out，烧钱
预算	max_rounds、max_sources、时间与 token 上限	一次跑 40 轮，账单吓人

可直接复用的研究 brief 模板

# research-brief.yaml
goal: >
  给一个 5 人小团队评估：2026 年是否值得把自建 RAG 迁移到
  长上下文模型直读方案。产出 800 字以内的结论 + 一张对比表。

audience: 技术负责人（懂工程，不要求学术深度）

subquestions:
  - 长上下文模型在 10 万字文档上的检索准确率，与向量检索相比如何
  - 两种方案的成本结构（一次性建库 vs 按 token 付费）
  - 数据更新频率高的场景，哪种更省事
  - 已有的失败案例或迁移回退案例

allowed_sources:
  include: [官方文档, 学术论文, 厂商公开 benchmark, 一手工程博客]
  exclude: [SEO 聚合站, 无署名的"十大排行", 内容农场, AI 生成站]
  prefer: 有发布日期、有作者、有原始数据的页面

time_range:
  published_after: 2025-01
  note: 成本数据优先用 2026 年内的

output_schema:
  - claim: 结论一句话
    evidence: 支持它的来源（URL + 原文那句）
    confidence: high | medium | low
  - comparison_table: [维度, RAG, 长上下文]

stop_when:
  - 每个 subquestion 至少有 1 个一手来源
  - 关键结论有 >= 2 个互相独立的来源
  - 连续 2 轮没有带来新信息

budget:
  max_rounds: 6
  max_sources: 20
  max_wall_clock: 12m
  on_budget_exceeded: 停止搜索，输出当前结果并列出未覆盖项

这份模板的价值不在格式，在每一行都在削掉一种失败模式。

别让 Agent 自己决定搜到什么时候

默认行为是「再搜一轮看看」。搜索是廉价的，token 和你的注意力不是。不设 max_rounds / max_sources，你会得到一个 40 条引用、其中 25 条是同一篇文章转载的报告。

一定要写死：

• max_rounds：最多几轮迭代
• max_sources：最多读几篇
• 时间预算：超过就停，输出未完成状态

预算耗尽不是失败，输出「已覆盖什么、没覆盖什么」比硬凑一个完整报告有用得多。

指令越具体，Agent 越可能给你惊喜：具体的目标让它把算力花在你关心的分支上，而不是花在猜你要什么上。

---

Deep Research 的计划评审

Gemini、Perplexity、ChatGPT 的 Deep Research 在开跑前都会给一份研究计划（几个子问题、准备查什么）。

大多数人直接点「开始」。这是浪费。

那几十秒的计划评审，是你唯一能在跑之前纠偏的机会。 跑完之后你只能重跑，重跑又是一轮钱和时间。

三步评审

第一步：砍分支

计划里通常有一个明显无关的分支。砍掉。

你的问题是「小团队要不要自建 RAG」
计划列了「RAG 的历史演进」「Transformer 架构原理」
→ 砍。这些是背景知识，不是决策依据。

第二步：指定来源等级

明确告诉它每个子问题该看什么级别的来源：

成本问题 → 必须用厂商官方定价页，不接受媒体转述
准确率问题 → 必须用论文或公开 benchmark，不接受博客总结
迁移经验 → 一手工程博客优先，其次技术媒体

不指定的话，它会用「一篇讲得很顺的二手文章」回答所有问题。

第三步：检查子问题覆盖

你心里那 4 个关键角度，计划里是否都在？缺的当场加。

跑完做来源审计

报告出来，先别看正文，先扫引用列表：

检查项	不合格的信号
来源域名	一半来自同一家媒体，或大量不认识的小站
来源类型	全是二手总结，没有一份官方文档或论文
时间分布	关键成本/能力数据是 1 年前的
独立性	三条引用其实是同一篇稿子的转载
可打开性	点进去是 404 或需要登录的付费墙

审计不过，报告结论一律按「未经证实」处理。

一个习惯

Deep Research 跑完，先花 3 分钟看引用列表，比花 30 分钟逐句读正文更值。引用列表是这份报告的真实质量报告。

---

引用级验证：从「有引用」到「引用真的支持这句话」

早年我们说「多源验证 + 点开原文」。2026 年不够了——有引用不等于引用支持结论。模型完全可能挂一个真实的链接，然后写一句链接里根本没有的话。

五步验证法

1. 打开引用原文，确认支持的是同一句话（quote span）

不是「这篇文章讲了这个话题」，而是「这句话就在原文里，意思一致」。

AI 说：「Exa 的 Auto 模式比 Lite 模式准 40%」[2]
→ 点开 [2]
→ 原文说的是「Auto 模式在需要多跳检索的任务上表现更好」
→ 没有 40% 这个数字，也没有直接对比
→ 结论：数字是模型补的，标注为不可信

这一步最容易被跳过

因为点开链接、Ctrl+F 找关键词、读上下文，很烦。但这是唯一能拦住「引用真实、结论虚构」的动作。2026 年最常见的错误不是没引用，是引用张冠李戴。

2. 看发布日期与数据年份

文章 2026 年 8 月发，引用的数据可能是 2023 年的。这两个日期都要看，而且要分开看。

3. 看样本与口径

同一个数字，口径差一点，结论完全不同：

「70% 的企业在用 AI Agent」
→ 样本是多少家？哪个行业？
→ 「在尝试」还是「已进入生产」？
→ 是「用过一次」还是「每周都在用」？

碰到模糊的口径，直接把这句话降级为「据估算」，或者干脆删掉。

4. 多模型 / 多引擎跑同一问题，记录冲突

同一个问题丢给两个不同家的产品（比如 Gemini 4 Argon 跑一遍、Kimi K3 跑一遍、Perplexity 跑一遍），把回答里的事实性断言列出来对比。

冲突的地方就是重点：

Gemini：产品 A 支持 MCP
Kimi：产品 A 不支持 MCP
→ 去官方文档看。官方说是 beta，部分功能支持。
→ 两个模型都「不完全对」，你的答案在中间。

5. 同一问题隔一周再跑，观察答案漂移

模型的检索索引、系统提示、可用来源都在变。同一个问题，一周后答案可能变了。

漂移本身不是错误，但你要知道哪些结论是稳的，哪些是这次运气好搜到的。稳定的结论可以引用，漂移的结论必须自己核实。

什么时候值得做全套五步

不是所有回答都要。判断标准：这个结论会不会让你做决定、花钱、或者写进对外文档。 会，就做全套。不会，扫一眼来源域名够了。

---

常见提问错误

错误	示例	改进
太宽泛	「聊聊 AI」	「AI 在 2026 年对软件开发行业有什么具体影响？」
太具体	「某工具 v0.45.2 修复了什么 bug」	去官方 changelog 看，不要问 AI
预设结论	「为什么 Rust 比 Go 好？」	「Rust 和 Go 各自适合什么场景？」
缺少上下文	「怎么部署？」	「我有一个 Next.js 应用，部署在 Vercel 上，想迁移到自己的服务器」
一次问太多	「给我讲完整个 AI Agent 领域」	拆成多个问题，逐个深入
fan-out 过度	让 Agent「尽量多找资料」	写死 max_rounds 和 max_sources，够了就停
把摘录当全文	只看搜索结果的摘要片段就下结论	点进原文，确认上下文没被截断
信源同质化	10 篇「独立来源」其实是同一篇稿子的转载	检查域名与作者，要求互相独立的来源
被植入内容污染	信了某篇排名文里的「新概念」	交叉核实概念是否存在于官方文档/论文
上下文塞满	一次喂 200 个来源让模型总结	分批总结再合并，中间信息会被漏掉

两个 2026 年的新坑

SEO 与植入内容污染。 2026 年 10 月有一项实验：1004 条 AI 生成的回答里，有 176 条引用了一篇虚构概念的植入帖子——那个概念在现实里根本不存在，只是被写进一篇看起来很正规的文章，然后被模型当成事实来源。

AI 引用的「来源」本身，可能就是为了被引用而写的。 判断方法很土但有效：这个概念在官方网站、论文、一手文档里出现过吗？只在博客和聚合站出现，就当它不存在。

上下文塞满导致中间信息丢失。 上下文越长，模型对中间位置的信息越容易漏。塞 30 篇资料进去，总结出来常常是开头几篇 + 结尾几篇。对策：分批读、分批总结，每批产出结构化笔记，最后合并笔记而不是合并原文。

---

实操练习

1. 用 RBGC 框架写一个带时间范围约束的问题，在 Perplexity 和 Kimi 各跑一遍，对比两者引用的来源差异
2. 对同一个回答做 3 次追问：一次深入、一次对比、一次验证
3. 写一份 research-brief.yaml，只改 goal 和 subquestions，其余沿用本文模板，交给一个支持 Deep Research 的工具跑
4. 拿到 Deep Research 的报告后，先做来源审计（看引用列表），再做一次引用级验证：随机挑 2 条引用，点进去确认原文是否支持那句话
5. 把同一个事实性问题分别问 Exa 驱动的检索和 Tavily 驱动的检索，记录它们给的前 5 条结果有何不同

---

参考来源

• Perplexity 官方文档：Search 与 Deep Research
• Google Gemini 官方帮助中心：Deep Research
• OpenAI：Deep Research 介绍
• Exa 官方文档：Search API 与内容抽取
• Tavily 官方文档：Search API
• Anthropic：Building effective agents

---

本节小结

✅ 提问质量决定回答质量——RBGC 框架（角色-背景-目标-约束）是结构化提问的利器

✅ 追问是 AI 搜索的杀手锏：深入型、对比型、验证型，三种追问各有用途

✅ 从宽到窄、从问题到方案、从主张到证据——三种多轮对话策略

✅ 给 Agent 写检索指令要写死七件事：目标、子问题、信源类型、时间范围、输出 schema、停止条件、预算

✅ 别让 Agent 自己决定搜到什么时候——max_rounds / max_sources / 时间预算，耗尽时输出未覆盖项而不是硬凑

✅ Deep Research 的价值一半在开跑前的计划评审：砍无关分支、指定来源等级；跑完先审引用列表

✅ 验证升级到引用级：确认 quote span、看数据年份、看样本口径、多模型对比冲突、隔周观察漂移

✅ 2026 年的新风险：植入内容被当成事实来源、上下文塞满后中间信息丢失

---

← 上一节：Deep Research 深度研究 | 继续学习：工具横评与选型 →