Deep Research

Seven-stage deep research pipeline for substantive research questions. Activates when user asks for deep research, 深度研究, research report, evidence-backed investigation, or a sourced long-form answer. Trigger keywords: 研究、调研、深度分析、写报告、综述、report、deep research、 investigate、research report、深度研究、调研报告、帮我了解、全面梳理、综合分析。

Deep Research Pipeline — 深度研究七步法

Migrated from DuMate's qianfan-deepresearch skill. This is a 7-stage systematic workflow, NOT a simple search-and-summarize.

---

整体工作流（7 阶段）

text

阶段 1：解析需求   → 2-3 个选择题（用户可跳过）→ 提炼课题 + 子问题清单 + 受众判断
阶段 2：生成大纲   → 先定骨架，再找内容 → 必须给用户确认大纲
阶段 3：规划任务   → 大纲拆成 ≤5 个有序任务
阶段 4：顺序执行   → 逐任务搜索 + 爬取 + 结论展示（直接在对话中，400-600字）
阶段 5：反思补充   → 覆盖缺口扫描 + 洞察提炼
阶段 6：撰写报告   → 综合全部阶段性结论成文 → 保存 .md 文件
阶段 7：HTML渲染   → 报告完成后主动询问用户是否生成 HTML

两处主动确认 + 一处询问：

• 阶段 1 开场：2-3 个选择题（可跳过）
• 阶段 2 大纲生成后：给用户审一次
• 阶段 7 报告完成后：询问是否生成 HTML

---

阶段 1：解析需求

1a. 开场选择题（仅此一次，必须放在最前）

用 ask_user 工具一次性问完，不要一个一个问。

推荐问题（选 2-3 个，不要更多）：

text

Step 1 — 目标读者：
- A. 普通读者 / 非专业实践者（默认）
- B. 专业从业者
- C. 学术 / 高级研究者
- D. 企业决策者

Step 2 — 报告侧重：
- A. 全面调研（系统覆盖，深度展开，默认）
- B. 趋势综合（提炼模式，典型案例支撑）
- C. 方案对比 / 决策建议（结论明确，须给判断）
- D. 可操作指南（步骤、模板、落地导向）

Step 3 — 篇幅期望：
- A. 标准（6000-10000字，默认）
- B. 精简（3000-5000字）
- C. 详尽（10000字以上）

用户回复处理：

• 用户做出选择 → 按选择推进
• 用户回复"跳过"/"skip"/"随便"/"你定" → 按默认值推进，立即进入下一步推断
• 用户提供补充信息 → 整合进参数，继续推进

1b. 自主推断剩余参数

根据用户原始输入 + 选择题答案，自行推断：

• 研究标题：将输入提炼为一句清晰的研究课题
• 核心研究问题：这次研究要回答的根本问题是什么？
• 范围与边界：时间范围、地域范围、关注重点
• 报告类型（见下方识别表）
• 语言：用户用什么语言提问，就用什么语言研究和报告

报告类型识别表：

用户提问信号	报告类型	大纲策略	写作策略
"总结"、"梳理"、"了解趋势"、"分析特点"	合成型	以趋势/主题为主轴	每个趋势 1 核心判断 + 2-3 典型案例
"调研"、"深度分析"、"全面研究"	全面型	按主题或实体组织	系统覆盖，数据与案例并重
"哪些…被用到"、"哪些因素"、"哪种方案"	筛选型	主章节列"入选项"，小节说"排除项"	重点在入选内容
"帮我做…"、"提供一份…"、"制定…"	交付型	直接按交付物格式组织	可操作性优先
"评估/预测/是否可行/哪个最好"	决策型	末尾给出明确判断	对比前置，结论明确
"用户画像/人群分析/受众分析"	人群洞察型	先统计维度，后叙事段落	每类人群必须有叙事段落

1c. 建立子问题清单

仔细阅读用户原始输入，提取所有明确要求的信息维度，建立清单：

text

□ 子问题 A：[用户明确要求的第一个方面]
□ 子问题 B：[用户明确要求的第二个方面]
□ 子问题 C：[用户提到的特定框架/算法/模型的基本原理]
□ ...

规则：

• 用户提到特定框架/算法/方法论，必须包含一项"介绍其基本原理"
• 用户要求按多个维度比较，每个维度都是独立子问题
• 用户要求"评估/预测/推荐"，该结论本身是必须直接回答的子问题
• 定量问题（"比重是多少"、"数量是多少"）必须用数字回答，给出估算区间并说明依据

1d. 领域标准类别扩展（覆盖广度保障）

这是决定报告覆盖广度的关键步骤。 仅靠用户显式提到的内容往往不够——专业读者对某个领域有默认的"期待覆盖范围"。

课题类型	需要枚举的标准类别
策略/干预类	该领域公认的所有主要干预/策略类别
技术/方法类	该技术领域的所有主流方法/路线
市场/行业类	行业内所有主要子行业/玩家类型
学术/理论类	研究该问题的标准理论框架/分析视角
政策/制度类	政策体系的所有关键组成部分
比较分析类	所有需要被比较的实体

操作：

1. 列出标准类别清单（5-10 项）
2. 标记哪些已被用户显式提及（✓），哪些是隐性类别（⊕）
3. 覆盖率须 ≥80%。若某类别信息不足，章节末尾注明"[类别X]目前公开信息有限"但不得完全略去

1e. 受众判断与写作风格映射

受众类型	判断信号	写作风格
普通读者	问题描述日常化，关注"怎么做"	通俗语言；缩写必须有全称+解释；每个建议给具体步骤
专业从业者	使用行业术语，关注技术方案	可用专业术语但首次全称；以数据和方案优先
学术研究者	使用学术框架，关注方法论	可用专业缩写；重视方法论严谨性
企业决策者	关注投资、市场、竞争格局、ROI	结论前置；横向比较为主；量化数据优先

普通读者模式要求：优先用日常语言替代缩写；每个策略必须有"怎么做"的具体步骤；以工具书的语气写作。

阶段 1 结束： 完成 1a-1e 后直接进入阶段 2，不再向用户做整体确认。

---

阶段 2：生成研究大纲

目标： 在搜索之前先确定报告骨架，确保覆盖所有子问题，完成后必须给用户确认。

生成规则

1. 阶段 1c 清单中每个子问题，大纲中至少有一个对应小节
2. 阶段 1d 标准类别覆盖率 ≥80%
3. "三必有"结构规则（按课题类型强制应用）：

课题类型	必须包含的章节
市场/行业/政策类	独立的"宏观环境与政策背景"节
策略/干预/解决方案类	独立的"实施要素与落地条件"节
比较分析类	每个实体章节内所有用户指定维度都要出现；末尾必须有汇总对比表
学术理论类	用户要求的每个理论视角必须有独立子节

大纲第一原则：用户结构优先

信号	示例	大纲策略
用户列出了 N 个问题/维度	"请分析 A、B、C 三个方面"	N 个专属章节，标题用用户原话
用户要求 N 个实体按相同维度比较	"各公司需包括技术路径、融资、团队"	以实体为主轴：每实体一节，节内按维度展开
提问开放，无明显结构	"帮我了解 X 领域"	使用通用模板

通用模板（仅提问开放时使用）

text

一、背景与概述
  · 定义与基本概念
  · 历史演变（技术/学术/人文类课题必须展开）

二、核心主题一
  ...

三、核心主题二
  ...

四、应用 / 案例 / 影响（含横向对比分析）
  ...

五、批判性视角：挑战、争议与局限性
  ...（几乎所有课题都必须有）

六、结论与展望
  ...

全景总览 + 重点深入（方法/策略/方案类课题必须用）

1. 全景总览层：一张汇总表，简明列出所有主要选项，每个选项一句话描述
2. 重点深入层：对最重要的 3-5 个选项详细分析（机制、数据、案例、局限性）

章节描述写法

每个章节描述必须说明"研究要探查什么问题"，不是"要收集什么信息"。

阶段 2 结束：向用户确认大纲

展示完整大纲后：

text

以上是大纲，请审核。需要增删/合并/调序请直接告诉我；
回复"确认"或"开始"即可启动调研，也可以回复"跳过"直接采用此大纲。

收到确认后再进入阶段 3。

---

阶段 3：规划研究任务

目标： 把大纲转化为有顺序的研究任务列表，总数严格 ≤5 个。

任务规划规则

• 硬上限 5 个——宁可合并也不要超
• 大纲若有 6+ 章节，按主题相关性合并
• 每个任务需要明确：标题、覆盖的大纲章节、要回答的核心问题

任务格式

text

任务 1：[任务标题]
  目标章节：背景与概述、定义与基本概念
  描述：搜集 [课题] 的基本定义、发展历程、现状概览

任务 2：[任务标题]
  目标章节：核心主题一
  描述：深入研究 [核心主题一]，收集数据/案例/专家观点

执行顺序

• 主 Agent 顺序执行所有任务（不并行派发子 Agent，不写笔记文件）
• 先做基础背景类任务，再做需要背景做铺垫的深入分析类任务
• 每个任务执行完，直接在对话中展示精简结论（阶段 4 Step F 格式），再进入下一个

---

阶段 4：顺序执行研究任务

主 Agent 按阶段 3 顺序，逐任务执行以下步骤。

搜索工具选择

统一使用 web_search + web_fetch：

• web_search：发起搜索；可用 freshness 参数（day/week/month/year）
• web_fetch：爬取选中的页面原文

数据来源优先级

一手官方数据 > 行业协会统计 > 权威媒体报道 > 分析师估算

Step A：生成多个搜索查询

针对当前任务，生成 5-8 个不同角度的搜索查询：

• 角度互补，覆盖任务不同维度
• 包含时间限定词；优先用 freshness 参数而不是硬塞年份
• 包含权威来源词（"学术"、"研究报告"、"官方"）
• 学术/技术课题额外添加来源词（"arxiv"、"CNKI"、"wanfang"、"IEEE"）

Step B：执行搜索

web_search 逐一执行 Step A 生成的查询。

Step C：爬取关键页面

对每条搜索结果，选取最相关的 2-3 个 URL，用 web_fetch 获取完整内容。

Step D：提取与记录

1. 提取与当前任务相关的信息片段
2. 记录来源：标题 | URL
3. 标注目标章节
4. 特别标记：哪些是"主流共识"，哪些是"争议性/少数观点"

Step E：覆盖缺口扫描 + 洞察提炼

E1. 覆盖缺口扫描：

对照阶段 1d 的领域标准类别清单，逐项检查：

• 完全未覆盖 → 立即发起补充搜索
• 仅有浅层描述 → 标"待深化"，优先在下一轮补全
• 并列子问题均衡检查：各问题的内容量是否大致均衡（最多/最少比 ≤ 2:1）？

E2. 洞察提炼：

1. 跨来源模式：多来源共同指向什么结论？
2. 矛盾与张力：不同来源的数据有何矛盾？背后原因？
3. 意外发现：有哪些与常识不符的数据点？
4. 结构化重组：能否用简洁框架把碎片组织成新结构？给框架起名

洞察 = 对比 + 推演 + 结构化重组，不是摘录。

Step F：直接向用户展示阶段结论

不写文件。每个任务执行完，直接在对话中输出，总长度控制在 400-600 字以内。

格式：

markdown

### ✅ 任务 N：[任务标题] —— 调研结论

**对应章节**：[大纲章节名]

**核心发现**（3-5 条，每条 1 句）
- ...

**定量数据**
| 数据 | 来源 | 年份 |
|------|------|------|

**洞察**（2-3 条，"[A] + [B] → [C]" 一行格式）
- ...

**意外发现 / 争议**（≤ 2 条）
- ...

**信息缺口**
- ...

**引用来源**
- [标题] | [URL]

单任务自检（达标后才进入下一个任务）

• 来源 ≥ 3 个不同域名
• 至少 1 条具体数量/规模/比例/时间节点数据
• 有对主流观点的局限说明、批判性内容或失败案例
• "洞察"部分包含跨来源推断
• 领域主要标准子类别覆盖率 ≥80%
• 并列子问题覆盖深度大致均衡（最多/最少比 ≤ 2:1）
• 任务结论已在对话中展示

不达标的任务，当场补搜。

搜索失败处理

• 失败任务禁止原样重试：必须换角度或换关键词
• 连续失败 3 次：放弃该角度，从完全不同方向继续
• 部分成功：对缺失部分补充一次针对性查询

---

阶段 5：反思、验证与补充搜索

所有任务执行完毕、阶段性结论已在对话中展示后，主 Agent 回顾所有结论，分三步审查：

第一步：覆盖完整性检查

• 对照阶段 1d 领域标准类别清单，对每个"完全未覆盖"的发起最后补充搜索
• 对照阶段 1c 子问题清单，逐项确认每个问题有实质性回答
• 并列子问题均衡检查：各问题覆盖量是否大致均衡？
• 每个主章节 ≥ 3 个不同来源，≥ 1 个具体定量数据
• 是否有主流观点的反驳/局限性/失败案例？（几乎所有章节都需要，没有则补搜）

第二步：结构完整性检查

• "三必有"规则验证
• 用户要求的每个理论框架维度是否都有独立、实质性内容？

第三步：洞察质量检查

• 每个主章节是否有至少 1 条跨来源推断性结论？
• 是否有对比性发现？是否有出人意料的发现？
• 整体核心叙事是否清晰？（能否用 1-2 句话说明最重要发现？）

对每个缺口，发起补充搜索，结果同样在对话中以简短结论形式补充。

---

阶段 6：撰写研究报告

跨任务综合

1. 覆盖完整性确认：整体上是否还有标准类别缺口
2. 跨章节模式：多份结论共同指向什么整体结论？
3. 数据一致性：不同任务给出的数字有无矛盾？
4. 核心叙事：用 1-2 句话概括整个研究最重要的发现
5. 高价值洞察定位：哪 2-3 个发现最出人意料、最有决策价值？

撰写要求

• 标题格式：普通文字（如"## 一、背景与概述"或"## 背景与概述"），不要使用 C1/C2 编号前缀
• 综合所有对话中已展示的阶段性结论（每个任务的结论都在上下文里）
• 按受众类型对应风格写作（普通读者 vs 专家 vs 决策者）

保存

报告以 Markdown 保存到 reports/[研究标题简写]_[YYYY-MM-DD].md，告知用户路径。

---

阶段 7：HTML 渲染（可选）

报告完成后，主动询问用户是否需要生成 HTML 版：

text

报告已生成：[文件名].md

是否需要我生成一个精简的 HTML 网页版（响应式、左侧 TOC、可直接浏览器打开）？
- 回复"是" → 我会生成
- 回复"否" → 流程结束

---

质量红线

• ❌ 不要只看摘要，关键信息必须 WebFetch 读原文
• ❌ 不要过度引用同一来源
• ❌ 禁止虚构数据，涉及具体数字必须能找到来源
• ❌ 搜索重试必须换角度，不能用相同关键词
• ✅ 适应用户语言（中文用户用中文，英文用户用英文）
• ✅ 每个任务的结论直接展示在对话中（400-600字），不写中间文件

---

研究输出格式

markdown

# [研究标题]

**生成日期：** YYYY-MM-DD
**研究范围：** [scope]
**受众类型：** [audience]
**报告类型：** [type]

## 摘要
[2-3 段落核心发现概述]

## 各章节内容
...

## 引用来源
- [标题] | [URL] — [描述] — [date]

---

Notes

• 语言匹配：用户用什么语言提问，就用什么语言研究和报告
• 代码标识符、路径、CLI 命令保持原生形式
• 如果用户指定了格式，按要求执行；无说明则产出标准 Markdown 研究报告
• 写 skill 入口在用户的语言（中文/English）