# Deep Research

> 验证型调研：多Agent并行、Tier 1-4信源交叉验证、可追溯，产出决策备忘录。 适用：要做决策的调研（该选A还是B、X靠不靠谱、帮我验证）、技术评估、方案对比、行业可行性。 不适用：了解来龙去脉/叙事型报告→narrative-research。 触发词：深度调研、帮我调研、evaluate、该选哪个、靠不靠谱、对比一下、competitive analysis。

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

---


# 深度调研工作流

## 搜索工具（Claude Code 环境强制）

本工作流全程 10-30+ 次搜索。在 Claude Code 里，主控和所有 sub-agent 一律用 **tavily-skill CLI**（file 模式，结果落盘不进上下文），不要用 Tavily MCP，也不要用裸 WebSearch——那是 CLAUDE.md → Web Search Routing 点名的 token 泄漏反模式：

```bash
~/.claude/skills/tavily-skill/.venv/bin/tavily-skill search "query" --output ./tmp/tavily/<slug>.json
```

非 Claude Code 环境（无此 CLI）再退回宿主自带的搜索工具。

## 核心原则

1. **激励感知验证**: 信息价值取决于来源的激励结构。厂商叙事有用但不能自证。每个主要 claim 都必须追溯到与发布方激励无关的独立证据。
2. **交叉验证**: 多个 sub-agent 覆盖有重叠的主题，用分歧和矛盾暴露盲区。
3. **可追溯性**: 所有引用保留 URL，关键引用保留原文摘录，不依赖总结。
4. **逐步聚焦**: 先扫描全貌，提取 claim，再分维度深入验证。
5. **单一主交付 + 可复用工件**: 最终报告一份，关键中间工件存入 session 目录。
6. **共享 research spine，分叉 reader mode**: 搜索、验证、工件留存共享；成稿前按读者决定 internal / external mode。

## 信息源层级

| 层级 | 类型 | 使用方式 |
|------|------|----------|
| Tier 1 | 厂商官方文档、blog、case study | 提取 claim，不做验证依据 |
| Tier 2 | Press coverage、sponsored review | 辅助理解市场叙事，不作为独立证据 |
| Tier 3 | 独立开发者 blog、HN/Reddit、Stack Overflow | 作为验证信号，注意社区偏差 |
| Tier 4 | GitHub issues、migration stories、production post-mortems、commit history | 最高可信度，行为证据而非态度表达 |

证据可信度递增：态度表达 < 使用场景描述 < 对比决策记录 < Migration stories < Production post-mortems < 代码/commit 级证据。优先收集后半部分。

**Claim 类型 ↔ 证据类型匹配**——来源可以很有名，但仍然是错误类型的证据：

| Claim 类型 | 对口证据类型 |
|-----------|-------------|
| 产品功能/特性 | 官方文档、源码 |
| 法规/合规 | 官方法律文本、监管机构发布 |
| 科学有效性 | 同行评审论文、meta 分析 |
| 市场趋势/规模 | 财报、监管披露文件 |
| 运营故障/可靠性 | Incident 报告、post-mortem |

## 两种 Reader Mode

**Mode A：Internal（共享上下文驱动的决策备忘录）** — 读者是自己或共享上下文的协作者。不复述共同常识；重点展开会改变结论的未知点、最可能被反对的点。

**Mode B：External（零预设上下文的可发布论证）** — 读者不是已知对象。必须显式回答 why this matters；关键定义和限定条件写在页面上。

先问三个问题再选 mode：(1) 读者是否已知且共享厚重上下文？(2) 主要价值是帮对方更快判断还是让对方理解并相信？(3) 拿掉私有背景后报告能否独立成立？

Mode B 动笔前多问一句：这个话题对目标读者是 **现在相关 / 未来相关 / 大概率不相关**？"当下不相关"本身是一个合法论点——如果诚实答案是"不是现在"，论点就应该这么写，而不是堆砌一堆看似紧迫的案例去暗示短期利害。

## Phase 1: 初步扫描 + Claim 提取

1. 用 Tavily 进行 2-3 次搜索，覆盖：
   - 调研对象的基本描述（Tier 1 官方信息）
   - 市场评价和媒体报道（Tier 2 市场叙事）
   - 批评、争议、已知问题（Tier 3-4 信号）
2. 总结 3-5 个需要深入调研的维度。
3. **Claim 提取**：列出关键主张，对每个 claim 标注验证通道。

**输出**: `tmp/<session_slug>/scratchpad.md`，含 claim extraction 表格：

```markdown
| Claim | 来源 (Tier) | 验证通道 | 验证状态 |
|-------|-------------|----------|----------|
| "zero-config" | Tier 1 官方 | GitHub issues 搜 setup pain | 待验证 |
```

## Phase 1.5: Prior-Work 定位

**仅当调研对象是一篇论文或一组论文时执行；产品、公司、行业话题跳过本阶段。**

1. 列 prior-work 对照表：

   | Prior work | 做了什么 | 没做什么 | 本文声称的增量 |
   |-----------|---------|---------|---------------|
   | ... | ... | ... | ... |

2. 对每个 prior work 做**外部核实**：查它自己的论文/repo/评测确认真实覆盖范围，不能只读本文 related work 一节的转述。
3. 基于核实结果判断增量大小：本文相对已核实的 prior work 边界，实际新增的是什么、有多大。
4. 定位档位（默认 C）：领域背景 30-40% + 本文 60-70%；读者对领域越陌生，越往 A 方向（更高领域背景占比）偏移。

三个常见错误模式：
- 把本文 related work 一节的框架当成事实——那是作者的叙事，不是核实结果
- 用本文"声称做到 X"衡量增量，而不是用实验结果衡量
- 100% 写本文、0% 领域背景，读者没有坐标判断这个增量是否重要

## Phase 2: 分割与并行调研

**按证据功能设计维度**（不只是按主题）：
- 官方叙事（Tier 1-2）
- 独立使用体验（Tier 3）
- 失败与边界（Tier 3-4）
- 迁移行为（Tier 4）

维度之间必须有 **≥50% 的 overlap**，让不同 agent 有机会发现矛盾。

启动 3-5 个 sub-agent，每个 prompt 中明确：
1. 具体调研主题
2. 本维度相关的 claim（要求在 Tier 3-4 源中验证）
3. 优先返回行为证据，而非态度表达
4. 必须返回 URL 和原文摘录
5. 可以覆盖的其他相关维度（形成 overlap）

**Tavily 参数**: CLI 默认即为 `--max-results 6 --search-depth advanced --answer off`，无需显式传参；sub-agent prompt 里带上「搜索一律用 tavily-skill CLI --output 落盘」

## Phase 3: 整合与交叉验证

1. 对比各 sub-agent 结果：多个发现 → 可信度高；单一来源 → 标注；互相矛盾 → 特别标注
2. 对每个 claim 核查验证状态：
   - Tier 3-4 有独立证据 → 已验证
   - 仅 Tier 1-2 → "仅 vendor source，未独立验证"
   - Tier 3-4 与 Tier 1-2 矛盾 → 以 Tier 3-4 为准
3. 如发现重大矛盾，可再启动 sub-agent 针对性验证。

## Phase 3.3: 溯源与事实核查

从整合结果里挑 5-10 个承载核心论点的来源：直接支撑主论点的、看似矛盾的、带关键数字的、可信度存疑的。

1. 用 tavily-skill CLI 重新抓取这些来源的**原文**（不是 sub-agent 的转述）：
   ```bash
   ~/.claude/skills/tavily-skill/.venv/bin/tavily-skill extract "<URL>" --output ./tmp/<session_slug>/extract/<slug>.json
   ```
2. 逐条核对：转述有没有偏离原意、有没有丢限定词（"约"、"仅适用于"、"在某些条件下"）、URL 是否指向正确页面、数字精度是否和原文一致。
3. 记录到 `tmp/<session_slug>/fact_check.md`，每条给 verdict（一致 / 部分偏差 / hallucination）+ 原文摘录。

**硬规则**：永远不用一个 sub-agent 的总结去验证另一个 sub-agent 的总结——都要落到原文。核心来源被证伪 → 阻塞写作，回 Phase 2 针对性重新调研，不得带着已知造假的支撑点继续写。

## Phase 3.5: 红队论点 + 决定 Reader Mode

**有明确论点（thesis-bearing）的调研才跑红队环节**；纯事实汇总类调研可跳过红队，直接做 reader mode 决定。

1. 写 `tmp/<session_slug>/brainstorm_brief.md`：论点、已验证事实、不确定 claim、反例、目标读者、约束条件。
2. 启动角色化 sub-agent（evidence skeptic / target reader / decision maker），每个都回答同样四个问题：论点的最强表述是什么？最薄弱的前提是什么？有哪 3-5 项需要重新核查？什么证据会推翻这个论点？
3. 汇总三方回答，提炼候选论点（可能不止一版）。
4. 针对最薄弱前提，跑**一轮**范围收窄的 round 2——只攻击那个前提，不重新扫全局；新来源追加进来源索引。

**Reader Mode 决定**：写进 scratchpad：`mode`、目标读者、哪些前提可默认共享、哪些必须显化。

## Phase 4: 撰写最终报告

**动笔前穿透检查**：
1. 每个主要正面判断是否至少有一个 Tier 3+ 独立证据源？
2. 找不到独立支撑的判断 → 显式标注"此点仅有 vendor source"
3. 是否同时呈现了 vendor narrative 和 independent reality？

**Internal mode 写作顺序**: 结论 → 关键依据 → 未确认点 → 建议动作

**External mode 写作顺序**: Why it matters → 核心判断 → 背景与定义 → 分维度证据 → 边界与反例 → 决策意义

**确定性引用校验（交付前必跑）**：

```bash
python3 ~/.claude/skills/deep-research/scripts/verify_citations.py <报告.md> --sources tmp/
```

脚本在本 skill 的 `scripts/` 目录下（Codex 环境把 `~/.claude` 换成 `~/.codex`）。它用 URL 签名（域名+路径前段）把报告里每条引用对到 `tmp/` 落盘的搜索结果和笔记的 URL 池，抓虚构 URL、空链接/悬空引用、汇总与正文不一致、单一来源集中（>25%）。critical 必须修复后重跑，exit 0 才能交付；warning 逐条人工判断（同域不同文的要确认是不是同一篇）。

**存储**: `contexts/survey_sessions/<topic>_survey_YYYYMMDD.md`

## 续研（Round 2+）

同一课题的后续调研不重跑全流程、不重写全文：
1. 复用 `tmp/<session_slug>/`：读旧 scratchpad 和 claim 表，明确上轮「未验证 / 仅 vendor source」的遗留点
2. Claim 表增量扩展：新 claim 追加行，旧 claim 更新验证状态（含「已验证 → 被新证据推翻」）
3. 只对新维度和新矛盾点启动 sub-agent，已验证结论不重复搜索
4. 交付 **delta memo** 而非重写全文：变化了什么 / 新证据 / 对既有结论的影响 / 剩余不确定性

## URL 留存规范

必须保留 URL：直接引用、数据来源、评价来源、官方信息。正文引用用 inline `[来源](URL)` 或如下格式，报告末尾加 `## 来源汇总` 列出全部来源 URL——引用校验脚本按此结构检查。

```markdown
**来源描述**（URL）
> 原文摘录
```

避免：无 URL 的引用（"有人评价说..."）、只总结不引用原文。

## 常见陷阱

| 陷阱 | 对策 |
|-----|------|
| 只搜到正面信息 | 专门搜 "criticism", "negative review", "scam" |
| 为反而反（强行 contrarian） | 无真实主流叙事可反驳时，不得为反而反；改为交付一个决策相关的非显然洞察 |
| 信息来源单一 | 强制要求 sub-agent 找多个独立来源 |
| 过度总结丢失细节 | 保留原文摘录 |
| 维度划分太干净没有 overlap | 故意让边缘模糊 |
| Sub-agent 返回太浅 | prompt 中强调"深度"、"具体"、"原文" |
| 调研变成 vendor marketing 汇总 | Phase 1 提取 claim → Phase 2 分维度验证 → Phase 3 核查 → Phase 4 穿透检查 |
| internal 误用为"可以不解释" | 共同常识跳过，读者不熟悉的要展开 |