Bruce Deep Research

Bruce 深度调研

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

调研模式

根据用户需求选择模式：

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

各报告类型的建议模式

来源可信度分级

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

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 继续补充完善，不重新开始。

第二阶段：工具选择策略

工具决策表

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 研究要内容。

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/ 下每个文件，每次搜索后立即写入）：

# 搜索记录：{关键词}

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

## 搜索结果

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

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

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

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

- **来源 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:），或寻找引用了该原文的摘要文章

信息缺口的间接信号

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

搜索引擎兜底

当 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。