# Bruce Deep Research

> 深度调研技能，适用于竞品分析、客户信息调研、技术方案调研、产品调研等场景。当用户要求调研、分析、对比、收集情报时，无论针对公司、竞品、产品、技术、客户还是市场，都应调用此技能。触发关键词包括：帮我调研、竞品分析、客户调研、技术选型、产品调研、深度研究、了解一下、找一下、搜集一下、research、investigate、compare、analyze。即使看起来是简单的调研任务，也应使用此技能——它能避免无效搜索，输出有结构、有来源的高质量报告。

- Skill: `bruc3van/bruce-deep-research` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add bruc3van/bruce-deep-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bruc3van/bruce-deep-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: bruc3van (https://skillmd.com/u/bruc3van)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bruc3van/bruce-deep-research

---


# Bruce 深度调研

你正在进行结构化调研。本技能引导你完成 **规划 → 搜索 → 沉淀 → 反思 → 交付** 的完整流程。

## 调研模式

根据用户需求选择模式：

| 模式 | 适用场景 | 搜索轮次 | 来源数量 |
|------|----------|----------|----------|
| **快速** | 单一事实核查、时间紧迫、简单问题 | 1–2 | 3–5 |
| **标准** | 单一对象调研（一个产品/一个客户/一项技术） | 3–4 | 8–15 |
| **深度** | 多对象对比、全景分析、战略决策支撑 | 5–8+ | 20–40+ |

用户未明确指定时，根据问题复杂度推断。不确定时先用标准模式，必要时升级。

### 各报告类型的建议模式

| 报告类型 | 推荐最低模式 | 说明 |
|----------|------------|------|
| 快速简报 | 快速 | 只需回答一个明确问题 |
| 产品调研（单个产品） | 标准 | 一个对象的全方位了解 |
| 客户调研（单个客户） | 标准 | 一家公司的多维度画像 |
| 技术方案调研 | 标准→深度 | 2–3 个方案用标准，4+ 个方案或需 POC 建议用深度 |
| 竞品分析 | 深度 | 多个竞品 × 多个维度，信息量天然大 |
| 行业/赛道调研 | 深度 | 产业链+格局+政策+趋势，维度最多 |
| 用户调研 | 标准→深度 | 取决于用户群数量和渠道覆盖范围 |
| 定价策略调研 | 标准→深度 | 取决于竞品数量和定价模式复杂度 |
| 合作伙伴/渠道调研 | 标准 | 通常候选对象 2–3 个 |
| 趋势洞察 | 深度 | 需要跨领域、跨时间维度收集信号 |

### 来源可信度分级

搜集信息时，根据来源类型评估可信度权重，优先采信高权重来源，低权重来源需要交叉验证后才能作为结论依据：

**T1 高可信度**（可直接引用）
- 官方网站（公司官网、产品文档、定价页）
- 官方新闻稿、官方博客、官方社交媒体账号
- 上市公司财报、招股书、监管文件
- 权威行业报告（Gartner、IDC、艾瑞、Forrester 等）
- 政府/监管机构发布的政策文件和数据
- 学术论文与预印本平台（arxiv.org、Google Scholar、IEEE、ACM、知网）——技术调研和趋势洞察的重要来源

**T2 较可信**（优质二手来源，建议交叉验证）
- 知名科技媒体（36kr、虎嗅、TechCrunch、The Verge 等）
- 专业社区高赞内容（知乎专业领域、HackerNews、StackOverflow）
- 第三方评测平台（G2、Capterra、AppStore 评分）
- 招聘平台信息（LinkedIn、Boss 直聘、拉勾——作为间接信号）
- Crunchbase、天眼查等企业信息平台

**T3 参考级**（需多源交叉验证，不可单独作为结论依据）
- 普通自媒体文章、个人博客
- 论坛讨论、社区帖子
- 未署名或来源不明的内容
- 二手转载内容（需追溯原始出处）

在最终报告中，关键结论应优先基于 T1 来源；仅有 T3 来源支撑的信息必须标注 🔴 低置信度。

## 第一阶段：制定研究计划

### 快速模式

跳过正式计划，直接在心里明确"要搞清楚什么"和"怎么搜"，然后立即执行搜索。不写计划、不建文件夹、不写 `todo.md`。搜完直接作答。

### 标准/深度模式

搜索前先写简要计划并展示给用户：

```
研究目标：[一句话说清楚要搞清楚什么]
调研模式：标准 / 深度
核心问题：
  1. ...
  2. ...
  3. ...
信息维度：[例：产品功能、定价、团队背景、融资、技术栈、客户案例...]
主要来源类型：[官网、新闻、行业报告、社交媒体、招聘信息、GitHub...]
输出形式：[简报 / 对比表 / 深度报告 / 要点列表]
```

**计划落入 `todo.md`**：把每个核心问题 / 信息维度拆成独立待办，写入 `{主题}-research/todo.md`。后续搜索过程中逐项勾选完成。这样不会遗漏维度，中途也可随时查看进度。

**等待用户确认**：展示计划后，询问用户是否同意方向、是否需要调整维度或补充关注点。确认后再开始搜索。这是唯一的用户确认节点——之后一次性执行完所有阶段，报告出来后如需修改，基于现有 `sources/` + `notes.md` 继续补充完善，不重新开始。

## 第二阶段：工具选择策略

### 工具决策表

| 场景 | 工具 |
|------|------|
| 找链接、查最新动态、快速验证 | **Brave**（`web_search`），主力搜索工具 |
| 读文章/博客/新闻/文档/类型不确定 | **`web_fetch`**，URL 拼接 `r.jina.ai` 或 `defuddle.md` 前缀 |
| 读 API/JSON/RSS 等结构化数据 | **`web_fetch`**，直接请求原始 URL |
| 需内容摘录 / Brave 限流 / 需多源综合答案 / URL 抓取备选 | **Tavily**（见下方分工说明） |
| 复杂网页、JS重、公众号文章、整站抓取 | **`browser`**（OpenClaw 内置浏览器） |
| 复杂网页抓取失败、需要点击/翻页/弹窗等交互操作 | **`browser`**（OpenClaw 内置浏览器） |
| 推文/X 内容 | `web_fetch`，URL 拼 `r.jina.ai` 前缀 |

> **`r.jina.ai` 和 `defuddle.md` 的本质**：它们是 URL 转换服务，不是独立工具。使用方式是把目标 URL 拼接到前缀后，再交给 `web_fetch` 请求，从而提取更干净的正文。
> - 示例：`web_fetch("https://r.jina.ai/https://example.com/article")`
> - 示例：`web_fetch("https://defuddle.md/https://example.com/article")`

### Brave 与 Tavily 的分工

两者定位不同，用于调研流程的不同阶段：

| | Brave | Tavily |
|---|---|---|
| **本质** | 搜索引擎入口，返回链接列表 | 为 AI agent 设计的研究工具，返回内容 |
| **每条结果内容** | 标题 + URL + 短摘要（~100字符） | 标题 + URL + 长摘录（200–500字符） |
| **AI 综合** | 无 | 有 `include_answer`，自动综合多源答案 |
| **页面提取** | 无 | 有 `extract` 接口，可替代 web_fetch |
| **实时性** | 强，适合新闻/最新动态 | 一般 |
| **免费额度** | 2,000 次/月，限流 1 req/s | 1,000 credits/月 |

**使用原则：Brave 扫描找链接，Tavily 研究要内容。**

Brave 额度是 Tavily 的两倍，优先用 Brave 做探索性搜索，把 Tavily 留给真正需要内容深度的查询。

**何时用 Brave**：
- 快速找链接、确认某个事实
- 查最新新闻、实时动态
- 初轮广泛扫描，收集候选 URL

**何时用 Tavily**：
- 需要摘录内容、不想 web_fetch 每篇（摘录够长时可直接存档）
- 需要对某话题做多源综合（用 `include_answer`）
- 某个 URL 用 web_fetch / `browser` 抓不到时，试 Tavily `extract`
- Brave 触发限流（1 req/s）时立即切换，不要重试

**注意**：Tavily 返回的摘录虽然比 Brave 长，但仍是摘录，不是全文。重要来源还是要 web_fetch 抓全文存入 `sources/`。

### 已有 URL 时的读取优先级

1. **文章/博客/新闻/类型不确定**
   → `web_fetch` + `r.jina.ai/{URL}`
   → `web_fetch` + `defuddle.md/{URL}`
   → `web_fetch` 直接请求原始 URL
   → `browser`

2. **API/JSON/RSS 结构化数据**
   → `web_fetch` 直接请求原始 URL
   → `browser`

3. **公众号/复杂JS页面**
   → `browser`

### 搜索与抓取执行要点

- **搜索只是入口，抓取才是核心**：搜索结果只有标题和摘要，必须用 `web_fetch` 抓取实际页面全文，才能获取有价值的信息。每找到一个有价值的链接，立即抓取并存入 `sources/`。
- **先搜后抓**：先搜索找到 URL，不要盲猜链接。
- **Brave 扩面**：用 Brave 快速收集 5–10 个候选链接，注意每次调用间隔 ≥1s。
- **Tavily 补充**：Brave 限流或结果不足时，切换 Tavily；需要多来源综合摘要时主动使用。
- **Google 兜底**：当 Brave/Tavily 结果不理想时，可以手动拼接 Google 搜索 URL，用 `browser` 打开，再从结果页提取链接。示例：
  - `https://www.google.com/search?q=关键词+site:arxiv.org`
  - `https://www.google.com/search?q="公司名"+竞品分析`
  - 用 `browser` 打开上述 URL → 从返回的页面内容中提取有价值的链接 → 再逐个抓取
- **学术来源**：技术调研和趋势洞察时，主动搜索 arxiv.org、Google Scholar 等学术平台。可以通过 Brave 搜索 `site:arxiv.org 关键词`，或拼接 `https://arxiv.org/search/?query=关键词` 用 `web_fetch` 获取搜索结果页。
- **多角度提问**：同一对象用不同关键词搜索——公司名+"评测"、+"定价"、+"竞争对手"、+`site:linkedin.com`、+"融资"、+"客户案例"……
- **中英文双搜**：研究对象在国内运营时，中英文往往能拿到不同维度的信息。

## 第三阶段：分层搜索与素材沉淀

### 素材本地化存储

调研过程中获取的所有参考材料必须沉淀到本地文件，不能只停留在对话上下文里。这样做的好处是：长调研不会因上下文窗口限制丢失信息，素材可供后续复用，最终报告的引用有据可查。

**目录结构**：在当前工作目录下创建以调研主题命名的文件夹：

```
{主题}-research/
├── search-results/           # 搜索结果原始记录，每次搜索一个文件
│   ├── brave-01-{关键词}.md
│   ├── brave-02-{关键词}.md
│   ├── tavily-01-{关键词}.md
│   └── ...
├── sources/                  # 完整页面内容，一个来源一个文件
│   ├── 01-{来源简称}.md
│   ├── 02-{来源简称}.md
│   └── ...
├── notes.md                  # 调研笔记：关键发现、矛盾点、待验证项
├── todo.md                   # 研究计划与进度
└── report.md                 # 最终报告
```

**搜索结果文件格式**（`search-results/` 下每个文件，每次搜索后立即写入）：

```markdown
# 搜索记录：{关键词}

- **搜索工具**：Brave / Tavily
- **搜索时间**：{日期}
- **查询语句**：{实际使用的搜索关键词}

## 搜索结果

1. **{标题}**
   - URL：{链接}
   - 摘要：{搜索返回的摘要/snippet}
   - 是否已抓取全文：是 → `sources/01-xxx.md` / 否（原因：价值低/已有类似来源/...）

2. **{标题}**
   ...
```

**素材文件格式**（`sources/` 下每个文件，web_fetch / Firecrawl 抓取全文后写入）：

```markdown
# {文章标题或页面描述}

- **来源 URL**：{原始链接}
- **抓取方式**：{web_fetch + r.jina.ai / browser / ...}
- **抓取时间**：{日期}
- **内容类型**：{新闻/官网/评测/招聘/论坛/...}

## 关键信息摘要

[从原文中提取的与调研目标相关的核心内容，用自己的话整理，保留关键数据和引用原文]

## 原文要点

[原文中最有价值的段落，可直接摘录]
```

**存储时机**：
- 每次 Brave / Tavily 搜索完成后，**立即**将完整搜索结果写入 `search-results/` 对应文件。
- 每成功抓取一个页面全文后，立即写入 `sources/` 对应文件。
- 不要等所有搜索都完成再批量写入——中途上下文可能被压缩，信息会丢失。

### 快速模式

1. 1–2 次搜索直指核心问题
2. 读前 3–5 个来源
3. 不需要创建文件夹和素材文件，直接作答
4. 如果内容有复用价值，用户可以要求追加保存

### 标准模式

1. **第一轮——全局了解**：搜索主体，读官网 + 2–3 篇新闻/简介。每读完一个有价值的来源，**立即用 `web_fetch` 抓取全文**，存入 `sources/`，更新 `todo.md` 进度。
2. **第二轮——补充深度**：针对第一轮发现的空白定向搜索，继续抓取和沉淀素材。
3. 重要结论需至少 2 个来源交叉验证。
4. 更新 `notes.md`，记录关键发现和矛盾点。
5. 完成后直接进入质量反思和报告撰写。

### 深度模式

1. **第一轮——全景摸底**：广泛搜索，识别所有主要玩家/维度/来源。每个有价值链接立即 `web_fetch` 抓全文存入 `sources/`。
2. **第二轮——逐一深挖**：每个对象分别读官网+新闻+社区讨论。持续抓取沉淀。
3. **第三轮——信号挖掘**：招聘页面（透露技术方向和增长计划）、GitHub 仓库、产品更新日志、融资新闻、用户评价（G2/Capterra/AppStore/知乎）。
4. **第四轮——填补空白**：回看 `todo.md`，还有什么未完成？针对性补搜。
5. **第五轮+（必要时）**：交叉验证、矛盾信息核查、时效性确认。
6. 更新 `notes.md`，完成后直接进入质量反思和报告撰写。

## 第四阶段：信息获取受阻时的变通方法

当来源失效或内容不足时，按以下顺序尝试：

### 内容抓取失败
- `web_fetch` + `r.jina.ai` 前缀失败 → 换 `defuddle.md` 前缀 → `web_fetch` 直接请求原始 URL → `browser`
- 公众号/复杂JS页面：直接用 `browser`
- 遇到付费墙 → 搜索缓存版本（Brave 里加 `cache:`），或寻找引用了该原文的摘要文章

### 信息缺口的间接信号

找不到某类信息时，通过间接线索推断：

| 直接找不到的信息 | 间接获取方法 |
|------------------|--------------|
| 定价（未公开） | 搜"[公司] 定价 知乎"、"[公司] how much reddit"，G2/Capterra 用户评价里常提价格 |
| 团队规模/组织架构 | LinkedIn 公司页、招聘帖数量、媒体报道中的人员规模数据 |
| 技术栈 | GitHub 仓库、招聘 JD（会列出要求技术）、BuiltWith、Wappalyzer |
| 客户名单 | 官网案例页、新闻稿、客户 Logo 墙、G2 评价 |
| 融资/营收 | Crunchbase、新闻中的 PitchBook 引用、官方融资公告 |
| 战略/路线图 | 大会演讲、创始人采访、产品更新日志、近期招聘方向（透露未来重点） |
| 国内公司信息 | 天眼查/企查查（直接搜这两个网站+公司名）、百度新闻、微信文章用 `browser` 抓取 |

### 搜索引擎兜底
当 Brave/Tavily 搜索结果不理想时，拼接 Google 搜索 URL 用 `browser` 打开：
- 拼接 URL：`https://www.google.com/search?q=你的关键词`（关键词需 URL 编码）
- 用 `browser` 打开该 URL，获取搜索结果页内容
- 从返回内容中提取有价值的链接，再逐个用常规方式抓取
- 适合场景：Brave 结果太少、需要精确的 `site:` 限定搜索、需要特定时间范围的结果

### 搜索词改造
搜索无结果时：
- 简化关键词，减少限定条件
- 切换语言（中↔英）
- 使用公司的中文名、别名或曾用名
- 改搜创始人/高管的名字
- 加 `site:` 限定（如 `site:linkedin.com`、`site:github.com`、`site:36kr.com`）
- 加时间范围过滤，排除过期内容

### 诚实标注信息缺口
多方尝试后仍无法确认的内容，在报告中明确说明：
> ⚠️ **数据缺口**：未能找到关于 [X] 的可靠公开信息。建议通过 [直接联系 / 试用产品 / 内部渠道] 补充。

## 第五阶段：质量反思与补救

写最终报告前，对照此清单自查。发现缺口时不能只标注"有缺口"就算了，要执行具体补救动作。

### 自查清单

**完整性**
- `todo.md` 里的核心问题都覆盖了吗？
- 有没有明显遗漏的维度（定价、团队、技术、客户、近期动态等）？
- 重要结论有没有至少 2 个来源支撑？

**时效性**
- 信息是否足够新？有没有更近的来源需要补充？
- 关键数据点有没有标注信息日期？

**可信度**
- 来源是否可靠（官网、知名媒体、经过验证的用户评价）？
- 有没有标注哪些信息是推测或单一来源未经核实？

**客观性**
- 竞品分析中，优势和弱点都有公平评估吗？
- 事实和观点有没有明确区分？

### 发现缺口后的补救流程

1. **定位缺口类型**：是哪个维度缺信息？是完全空白还是信息不够可靠？
2. **回到第四阶段**：使用间接信号表或搜索词改造策略，针对缺口做 1–2 次定向搜索。
3. **补充素材**：新获取的来源同样写入 `sources/`，更新 `notes.md`。
4. **再次自查**：只检查刚才补救的维度，确认是否已补足。如果仍然无法获取，在报告中标注为数据缺口并附上建议的补充渠道。
5. **判断终止**：当所有核心维度要么有充分信息、要么已明确标注为数据缺口时，进入报告撰写。不要无限循环补搜。

## 第六阶段：撰写报告

### 报告存储

最终报告写入 `{主题}-research/report.md`。

### 报告撰写前必须整体回顾 sources/

撰写报告时，**不能只凭对话记忆**，必须先回读所有过程文件，从完整素材中提炼结论。这是保证报告不遗漏关键信息的核心步骤。

```
{主题}-research/
├── search-results/   ← 回顾已搜索的关键词覆盖情况，发现遗漏维度
│   └── ...
├── sources/          ← 全部回读，提炼关键结论
│   ├── 01-xxx.md
│   ├── 02-xxx.md
│   └── ...
├── notes.md          ← 回读，获取关键发现和矛盾点
├── todo.md           ← 确认所有维度已覆盖
└── report.md         ← 最终输出
```

### 引用规范

报告中每个关键事实和数据必须注明出处，引用格式为本地素材文件路径：

```
据调研，该公司 2024 年完成 B 轮融资 5000 万美元[^1]。

[^1]: [sources/03-crunchbase-funding.md](sources/03-crunchbase-funding.md)（原始来源：https://...）
```

引用同时保留本地文件路径和原始 URL，方便用户追溯一手来源，也方便在本地直接查看素材全文。

### 通用报告规范

- **决策导向**：报告的目的是帮用户做决策，不是堆砌信息。每个章节都要回答"所以呢？"
- **结论前置**：所有非快速简报都以执行摘要开头，让决策者 30 秒内抓住核心结论
- **置信度标注**：关键判断标注信息可靠程度——🟢 高置信（多源交叉验证）、🟡 中置信（单一可靠来源）、🔴 低置信（推测/间接推断）
- **必须有下一步行动**：报告末尾给出具体、可执行的建议

### 输出结构要点

根据调研类型，报告应包含以下核心结构（可根据实际情况灵活调整，不必死板套模板）：

**竞品分析**：执行摘要 → 市场背景 → 基础能力 vs 差异化能力对比 → 各竞品深度分析 → 机会与威胁 → 下一步行动 → 数据缺口 → 信息来源

**客户调研**：执行摘要 → 公司画像 → 业务与产品 → 痛点与挑战 → 当前方案与供应商 → 组织架构与关键人物 → 采购特征 → 切入策略 → 下一步行动 → 数据缺口 → 信息来源

**技术方案调研**：执行摘要 → 需求与约束 → 方案全景对比（含 TCO/锁定风险/社区生态）→ 各方案详析 → 推荐结论与权衡 → 下一步行动 → 数据缺口 → 参考资料

**产品调研**：执行摘要 → 产品概览 → 核心功能拆解 → 用户体验评估 → 商业模式 → 增长与运营信号 → 技术观察 → 启发与借鉴 → 下一步行动 → 数据缺口 → 信息来源

**行业/赛道调研**：执行摘要 → 市场规模与增长 → 产业链全景 → 竞争格局 → 客户需求与购买行为 → 政策与监管 → 技术趋势 → 机会评估 → 风险提示 → 下一步行动 → 信息来源

**用户调研**：执行摘要 → 用户画像 → 需求分层（Kano 模型）→ 用户旅程 → 用户声音（好评/差评关键词）→ 竞品用户对比 → 产品机会优先级 → 下一步行动 → 信息来源

**定价策略调研**：执行摘要 → 市场定价全景（对比表+价格带）→ 定价模式分析 → 客户付费意愿信号 → 功能分级策略 → 定价建议 → 下一步行动 → 信息来源

**合作伙伴/渠道调研**：执行摘要 → 候选对象概览 → 各候选详析 → 合作价值评估 → 推荐结论与谈判要点 → 下一步行动 → 信息来源

**趋势洞察**：执行摘要 → 趋势全景 → 核心趋势详析 → 趋势交叉分析 → 短中长期战略启示 → 持续监控信号 → 下一步行动 → 信息来源

**快速简报**：核心结论（1–2 句）→ 关键事实 → So What → 来源 → 信息时效

如需参考更详细的模板示例，读取本技能目录下的 `references/output-templates.md`。

## 工作原则

- **先规划再搜索**：花一分钟规划，省五分钟乱搜。
- **追溯一手来源**：看到一个说法，尽量找到原始出处验证。
- **边搜边沉淀**：每个有价值的来源立即存文件，不要堆到最后。
- **每条信息标注来源**：有 URL 和日期的调研才有价值，没来源就是猜测。
- **空白也是结论**：找不到的信息清晰标注，比沉默更有帮助。
- **始终回应用户实际问题**：所有调研都要连接回用户真正要做的决策或问题。
- **工具由轻到重**：先用轻量工具（web_fetch + jina/defuddle），必要时再升级到 `browser` / Tavily。