Deep Research

Deep Research（深度调研 8 步法）

将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。

核心理念

• 结论来自机制对比，不是「我感觉像」
• 先钉牢事实，再做推导
• 资料权威优先：L1 > L2 > L3 > L4
• 中间结果必须保存，便于回溯和复用

参考文档

---

工作目录结构

~/Downloads/research/<topic>/
├── 00_问题拆解.md          # Step 0-1 产出
├── 01_资料来源.md          # Step 2 产出
├── 02_事实卡片.md          # Step 3 产出
├── 03_对比框架.md          # Step 4 产出
├── 04_推导过程.md          # Step 6 产出
├── 05.5_校验记录.md        # Step 6.5 产出（独立 Agent 校验）
├── 05_验证记录.md          # Step 7 产出
├── FINAL_调研报告.md       # Step 8 产出
└── raw/                    # 原始资料存档

中间产物格式详见 templates/intermediate-outputs.md

---

资料分层

L4 社区来源（产品对比调研必查）：GitHub Issues/Discussions、Reddit、Hacker News

---

执行流程（8 步法）

每步完成后，立即写入对应文件。

Step 0: 问题类型判断

Step 0.5: 时效敏感性判断（BLOCKING）

🔴 极高敏感领域强制规则： 1. 搜索时带时间约束（time_range: "month"） 2. 官方源优先（文档、博客、Changelog） 3. 版本号强制标注（禁止「最新版本支持」） 4. 超过 6 个月的博客仅作历史参考 5. 关键信息至少 2 个独立来源确认 6. 直接访问官方下载页面验证（不依赖搜索缓存） 7. 搜索产品支持的协议名称（MCP、ACP 等）

Step 1: 问题拆解与边界界定

把模糊主题拆成 2-4 个可调研的子问题，并明确研究对象边界（人群/地域/时间/层级）。

→ 保存：00_问题拆解.md

Step 2: 资料分层与权威锁定

搜索策略（高敏感领域）： 1. 官方源定向搜索（限定官方域名） 2. 官方下载页面直接验证（BLOCKING） 3. 协议/功能名称搜索（BLOCKING） 4. 限时广泛搜索 5. 版本核实 6. 社区声音挖掘（GitHub Issues、Reddit）

适用对象核查（BLOCKING）：收录资料前必须验证适用对象与研究边界匹配。

→ 保存：01_资料来源.md（持续更新）

Step 3: 事实抽取与证据卡片

把资料转化为可核验事实卡片，区分「官方说的」和「我推测的」。

→ 保存：02_事实卡片.md（持续更新）

Step 4: 建立对比/分析框架

根据问题类型选择固定维度：

• 通用：目标、机制、输入输出、优劣势、适用场景、成本收益
• 概念对比：定义、触发方式、执行主体、确定性、资源管理、安全边界
• 决策支持：实现成本、维护成本、风险、收益、团队能力要求

→ 保存：03_对比框架.md

Step 5: 参照物基准对齐

确保对比各方定义稳定、公认、无歧义。

Step 6: 从事实到结论的推导链

显式写出「事实 → 对照 → 结论」的推导过程，每个结论都能追溯到具体事实。

⚠️ 推导防护：结论不得悄悄升级事实卡片中的确定性层级。

• 事实卡片写「可能」→ 结论不得写「会」
• 事实卡片写「理论上」→ 结论不得写「实际上」
• 事实卡片 A 说「只有 X 被禁」+ 事实卡片 B 说「Y 可能受影响」→ 结论不得写「X 和 Y 都被禁了」
• 自检：写完每条结论后，回溯引用的事实卡片，确认确定性层级是否一致

→ 保存：04_推导过程.md

Step 6.5: 独立 Agent 校验（BLOCKING）

时机：事实卡片 + 推导过程完成后，写最终报告前。

原则：遵循 CLAUDE.md「计划校验」规范 — 产出者 ≠ 审查者。

执行方式：启动独立 Agent（Task 工具），将 02_事实卡片.md 和 04_推导过程.md 交给 Agent，校验以下维度：

1. 数据准确性：关键数字（价格、版本号、参数规模等）做二次搜索验证，至少抽查 3-5 个核心数据点 2. 推导逻辑：结论是否有跳跃、是否悄悄升级了确定性层级 3. 遗漏检查：是否遗漏了用户关心的关键对比维度

→ 保存：05.5_校验记录.md

铁律：

• ❌ 不得跳过此步直接写最终报告
• ❌ 不得自己校验自己（必须启动独立 Agent）
• ✅ 校验通过 → 继续 Step 7-8；校验发现错误 → 回溯修正事实卡片/推导过程

Step 7: 用例验证（Sanity Check）

用一个典型场景验证结论是否成立，检查有无反例。

→ 保存：05_验证记录.md

Step 8: 可交付化处理

交付三件套： 1. 一句话总结：可在会上直接复述 2. 结构化章节：用小标题切开推导链 3. 证据可追溯：关键事实附出处链接

→ 保存：FINAL_调研报告.md

→ 打包：tar -czvf ~/outcome.tar.gz -C ~/Downloads/research <topic>

---

报告输出结构

# [调研主题] 调研报告

## 摘要
[一句话核心结论]

## 1. 概念对齐
## 2. 工作机制
## 3. 联系
## 4. 区别
## 5. 用例演示
## 6. 总结与建议
## 参考资料

详见 templates/report-structure.md

---

质量检查清单

🎯 边界守恒检查（BLOCKING - 防止调研蔓延）

核心问题：调研最容易出的问题不是「查得不够多」，而是「查得太散」。

检查流程：

1. 回顾核心问题：Step 1 拆解的子问题是什么？用一句话写下来。

2. 资料相关性审计：对 01_资料来源.md 中的每条资料，用以下结构化标准判断：

• 「这条资料能回答哪个子问题？」→ 写出对应的子问题编号
• 如果无法对应任何子问题 → 删除，不要心疼
• 如果「有点关系但不直接」→ 降级为补充材料，不进入主报告
• ★ 高风险调研（涉及政策、医疗、法律等）：建议使用 Task 工具启动独立 Agent 复核相关性判断（产出者 ≠ 审查者）

3. 事实卡片瘦身：对 02_事实卡片.md 中的每张卡片问：

• 「删掉这张卡片，核心结论还能成立吗？」
• 如果能 → 这张卡片是认知负担，移到附录或删除

4. 报告聚焦检验：最终报告中的每个章节都要能追溯到 Step 1 的子问题

典型症状：

铁律：调研的目标是回答问题，不是展示知识面。

核心检查

• [ ] 所有核心结论都有 L1/L2 级别的事实支撑
• [ ] 对比维度完整，没有遗漏关键差异
• [ ] 有至少一个实际用例验证结论
• [ ] 参考资料完整，链接可访问
• [ ] 每个引用都可被用户直接验证
• [ ] 一句话总结清晰可复述

时效性检查（🔴🟠 敏感领域 BLOCKING）

• [ ] 资料时效性已标注
• [ ] 版本号已明确标注
• [ ] 官方源已优先使用
• [ ] 下载页面已直接验证
• [ ] 协议/功能名称已搜索
• [ ] GitHub Issues 已挖掘

适用对象一致性检查（BLOCKING）

• [ ] 研究边界已明确定义
• [ ] 每条资料都标注了适用对象
• [ ] 事实卡片中无对象混淆
• [ ] 报告中无对象混淆

执行范围与理论风险区分检查（BLOCKING）

核心问题：调研涉及封禁、限制、政策执行等「行动」时，最容易犯的错误是把理论风险等同于实际后果。

错误模式：

• 事实卡片 A 正确记录了「只有 Gemini 被禁用」（确认的实际后果）
• 事实卡片 B 正确记录了「OAuth token 理论上可访问 Gmail/Drive」（安全理由/理论风险）
• 推导过程把 B 的理论范围 → 等同于 A 的执行范围
• 最终报告写成「整个账户生态受影响」← 这是偷换

三层区分（事实卡片和报告中必须明确标注）：

检查清单：

• [ ] 涉及封禁/限制/执行动作时，事实卡片是否区分了三层？
• [ ] 推导过程中，是否有从「理论风险」直接跳到「已确认后果」的逻辑跳跃？
• [ ] 最终报告中，执行动作的描述是否严格基于「已确认」层级？
• [ ] 「官方理由」和「理论风险」是否作为分析/解释出现，而非作为已发生的事实？

铁律：「X 在技术上可能发生」≠「X 已经发生」。报告中描述执行后果时，只能使用「已确认」层级的事实。「理论风险」可以作为分析维度呈现，但必须明确标注，不得混入事实性陈述。

典型事故：调研报告说「整个 Google 账户生态可能受影响」（基于 OAuth 理论范围），文章据此写「Gmail、Drive、Cloud 都受牵连——你的数字生活被掐断」。实际上用户报告只有 Gemini/Antigravity 被禁用，Gmail/Drive 完全不受影响。读者亲历者指出错误，作者声誉受损。

---

来源周全性要求

1. URL 可访问性：所有链接公开可访问 2. 引用精确定位：标明具体章节/页码 3. 内容对应性：引用能在原文找到对应 4. 时效性标注：标注发布/更新日期 5. 不可验证信息：标注 [来源受限]，不作为唯一支撑

---

最终回复规范

✅ 应该包含：

• 一句话核心结论
• 关键发现摘要（3-5 点）
• 打包文件位置（~/outcome.tar.gz）

❌ 禁止包含：

• 过程文件列表
• 详细调研步骤
• 工作目录结构

---

版本历史

对比框架模板

根据问题类型选择对应的对比维度框架。

---

一、概念对比型框架

适用于：技术概念对比、产品对比、方案对比

8 维度对比表

使用说明

1. 先填写事实（基于事实卡片） 2. 再填写差异说明（推导） 3. 标注哪些是"决定性差异" 4. 补充缺失维度（如果有）

---

二、决策支持型框架

适用于：技术选型、方案决策、工具选择

决策矩阵

风险评估子表

场景适用性

---

三、趋势分析型框架

适用于：技术趋势、市场分析、发展预测

演进时间线

[起源阶段] → [发展阶段] → [成熟阶段] → [当前状态] → [未来趋势]
   ↓            ↓            ↓            ↓            ↓
 [关键事件]   [关键事件]   [关键事件]   [关键事件]   [预测依据]

PESTEL 分析（外部驱动因素）

竞争格局

预测与不确定性

---

四、问题诊断型框架

适用于：故障分析、问题根因、瓶颈诊断

5 Why 分析

问题现象：[描述]
    ↓ Why?
原因 1：
    ↓ Why?
原因 2：
    ↓ Why?
原因 3：
    ↓ Why?
原因 4：
    ↓ Why?
根本原因：[Root Cause]

鱼骨图分析

                    ┌─ 人员因素
                    ├─ 流程因素
问题 ←──────────────┼─ 技术因素
                    ├─ 环境因素
                    └─ 工具因素

证据链

解决方案对比

---

五、知识梳理型框架

适用于：概念整理、知识体系、领域入门

概念层次结构

一级概念（领域）
├── 二级概念（分类）
│   ├── 三级概念（子类）
│   │   └── 具体实例
│   └── 三级概念
└── 二级概念
    └── ...

概念关系表

核心概念卡片

## 概念：[名称]

**定义**：[一句话定义]

**本质**：[更深层的解释]

**类比**：[用熟悉事物类比]

**边界**：
- 是什么：
- 不是什么：

**关联概念**：[列表]

**常见误解**：[列表]

---

维度选择指南

事实卡片模板

用于记录和整理调研过程中抽取的可核验事实。

模板格式

## 事实卡片 #[编号]

**主题**：[所属主题/维度]

**事实陈述**：
[具体的事实描述，使用陈述句，不带主观判断]

**出处**：
- 来源：[文档名称/网站]
- 链接：[URL]
- 章节：[具体章节/段落]
- 获取日期：[YYYY-MM-DD]

**置信度**：[✅ 高 / ⚠️ 中 / ❓ 低]

**置信度理由**：
- ✅ 高：官方文档明确说明
- ⚠️ 中：官方博客/演讲提及，但未正式文档化
- ❓ 低：推测或来自非官方来源

**更名/演变历史**（产品/项目/组织适用）：
- 前身：[之前的名称，如有]
- 更名时间：[YYYY-MM-DD]
- 各阶段规模：[如 GitHub stars、用户量等在不同时间点的数据]
- 备注：[更名原因，如商标争议、品牌策略等]

**相关事实**：[关联的其他事实卡片编号]

**备注**：[补充说明、矛盾信息、待验证点]

使用示例

## 事实卡片 #001

**主题**：Claude Skills 触发机制

**事实陈述**：
Skills 是 model-invoked（模型调用的），Claude 会根据用户请求与 SKILL.md 中 description 字段的匹配度决定是否启用该 Skill，不需要用户显式调用。

**出处**：
- 来源：Claude Code 官方文档
- 链接：https://code.claude.com/docs/en/skills
- 章节：How skills work
- 获取日期：2025-01-11

**置信度**：✅ 高

**置信度理由**：
官方文档明确说明："Claude will automatically use relevant skills when they match your request"

**相关事实**：#002（渐进式加载）, #003（SKILL.md 结构）

**备注**：与传统函数的显式调用形成对比

事实卡片汇总表

矛盾信息记录

当发现不同来源的信息有矛盾时，记录如下：

## 矛盾 #M001

**事实 A**：[来源 A 的说法]
**事实 B**：[来源 B 的说法]

**来源对比**：
- A 来自：[来源A的权威级别]
- B 来自：[来源B的权威级别]

**处理方式**：
- [ ] 采信权威更高的来源
- [ ] 两者都保留，在报告中说明分歧
- [ ] 需要进一步验证

**验证方案**：[如何验证哪个是正确的]

中间产物模板

00_问题拆解.md

# 问题拆解

## 原始问题
[用户提出的问题]

## 问题类型
[概念对比型/决策支持型/趋势分析型/问题诊断型/知识梳理型]

## 研究对象边界定义

| 维度 | 边界定义 | 说明 |
|------|----------|------|
| **人群** | [明确的群体] | 如：大学生 vs 中小学生 |
| **地域** | [地区限定] | 如：中国高校 vs 全球 |
| **时间** | [时期限定] | 如：2020年后 |
| **层级** | [层面限定] | 如：本科 vs 研究生 |

## 时效敏感性评估

- **敏感级别**：🔴极高 / 🟠高 / 🟡中 / 🟢低
- **判断依据**：[为什么是这个级别]
- **资料时间窗口**：[X 个月/年]
- **优先查阅的官方源**：
  1. [官方源 1]
  2. [官方源 2]

## 子问题列表

1. [子问题 A：定义与机制]
2. [子问题 B：对比分析]
3. [子问题 C：边界条件]
4. [子问题 D：延伸分析]

01_资料来源.md

## 资料 #[序号]

- **标题**：[资料标题]
- **链接**：[URL]
- **层级**：L1/L2/L3/L4
- **发布日期**：[YYYY-MM-DD]
- **时效状态**：✅当前有效 / ⚠️需验证 / ❌已过时
- **版本信息**：[如涉及特定版本]
- **适用对象**：[该资料针对的群体/地域/层级]
- **与研究边界匹配**：✅完全匹配 / ⚠️部分重叠 / 📎仅作参考
- **摘要**：[1-2句关键内容]
- **与子问题关联**：[对应哪个子问题]

02_事实卡片.md

## 事实 #[序号]

- **陈述**：[具体事实描述]
- **出处**：[资料#序号] [链接]
- **适用对象**：[该事实适用于哪个群体]
- **置信度**：✅高 / ⚠️中 / ❓低
- **关联维度**：[对应的对比维度]

03_对比框架.md

# 对比框架

## 选定的框架类型
[概念对比型/决策支持型/...]

## 选定的维度
1. [维度1]
2. [维度2]
...

## 初步填充

| 维度 | X | Y | 事实依据 |
|------|---|---|----------|
| [维度1] | [描述] | [描述] | 事实#1, #3 |

04_推导过程.md

# 推导过程

## 维度 1：[维度名称]

### 事实确认
根据 [事实#X]，X 的机制是...

### 对照参照物
而 Y 的机制是...（来源：[事实#Y]）

### 结论
因此，X 与 Y 在此维度上的差异是...

### 置信度
✅/⚠️/❓ + 理由

05_验证记录.md

# 验证记录

## 验证场景
[场景描述]

## 按结论预期
如果用 X：[预期行为]
如果用 Y：[预期行为]

## 实际验证结果
[实际情况]

## 是否有反例
[有/无，如有则描述]

## 回查清单
- [ ] 初稿结论与事实卡片一致
- [ ] 无遗漏重要维度
- [ ] 无过度推断

## 需要修正的结论
[如有]

报告结构模板

根据问题类型选择对应的报告结构。

---

一、概念对比型报告

# [X] vs [Y]：深度对比分析

## 摘要

[一句话核心结论，可直接复述]

例："X 更像是 [定位A]，Y 更像是 [定位B]；核心差异在于 [决定性差异]。"

---

## 1. 概念对齐

### 1.1 X 是什么

**官方定义**：[引用官方文档]

**通俗解释**：[用读者熟悉的语言解释]

**为什么存在**：[解决什么问题]

### 1.2 Y 是什么（参照物）

**定义**：[稳定/公认的定义]

**作为对比基准的理由**：[为什么选它做参照]

---

## 2. 工作机制

> 这是区分 X 与 Y 的核心章节

### 2.1 X 的工作机制

[详细描述 X 怎么运行，关键流程是什么]

### 2.2 Y 的工作机制

[简要描述 Y 的机制，作为对照]

### 2.3 机制差异总结

| 维度 | X | Y |
|------|---|---|
| [关键维度1] | | |
| [关键维度2] | | |
| [关键维度3] | | |

---

## 3. 联系（共同点）

> 建立桥梁，避免"完全不一样"的极端论断

1. **[共同点1]**：[解释]
2. **[共同点2]**：[解释]
3. **[共同点3]**：[解释]

---

## 4. 区别（核心差异）

> 按维度逐项对比，重点突出决定性差异

### 4.1 [维度1]：[维度名称]

- **X**：[描述]
- **Y**：[描述]
- **差异影响**：[这个差异意味着什么]

### 4.2 [维度2]：[维度名称]

...

### 4.3 决定性差异总结

最关键的 3 个差异：

1. **[差异1]**：[一句话说明]
2. **[差异2]**：[一句话说明]
3. **[差异3]**：[一句话说明]

---

## 5. 用例演示

> 把抽象落地到具体场景

### 场景：[场景描述]

**如果用 X**：
[具体怎么做]

**如果用 Y**：
[具体怎么做]

**对比**：
[这个场景下，哪个更适合，为什么]

---

## 6. 总结与建议

### 6.1 一句话总结

> 可在会上直接复述

[总结句]

### 6.2 何时选 X

- [场景1]
- [场景2]

### 6.3 何时选 Y

- [场景1]
- [场景2]

### 6.4 注意事项

- [注意点1]
- [注意点2]

---

## 参考资料

### 一手资料（L1/L2）

1. [标题](链接) - [简要说明]
2. ...

### 辅助资料（L3/L4）

1. [标题](链接) - [简要说明]
2. ...

---

## 附录：事实卡片摘要

| 编号 | 事实 | 出处 | 置信度 |
|------|------|------|--------|
| #001 | | | ✅ |
| #002 | | | ⚠️ |

---

二、决策支持型报告

# [决策问题]：方案分析与建议

## 摘要

**问题**：[一句话描述决策问题]

**建议**：[推荐方案] + [核心理由]

**前提条件**：[建议成立的前提]

---

## 1. 决策背景

### 1.1 业务场景

[描述需要做决策的业务背景]

### 1.2 关键约束

- 约束 1：[描述]
- 约束 2：[描述]

### 1.3 决策目标

- 主要目标：[描述]
- 次要目标：[描述]

---

## 2. 候选方案概述

### 方案 A：[名称]

[一段话概述]

### 方案 B：[名称]

[一段话概述]

### 方案 C：[名称]（如有）

[一段话概述]

---

## 3. 多维度对比

| 维度 | 方案 A | 方案 B | 方案 C |
|------|--------|--------|--------|
| 实现成本 | | | |
| 维护成本 | | | |
| 学习曲线 | | | |
| 性能表现 | | | |
| 扩展性 | | | |
| 生态成熟度 | | | |

---

## 4. 风险分析

### 方案 A 风险

| 风险 | 可能性 | 影响 | 缓解措施 |
|------|--------|------|----------|
| | | | |

### 方案 B 风险

| 风险 | 可能性 | 影响 | 缓解措施 |
|------|--------|------|----------|
| | | | |

---

## 5. 场景化建议

| 如果你是... | 推荐 | 理由 |
|-------------|------|------|
| [场景1] | 方案 A | |
| [场景2] | 方案 B | |
| [场景3] | 方案 C | |

---

## 6. 最终建议

### 6.1 推荐方案

**推荐：[方案名称]**

### 6.2 推荐理由

1. [理由1]
2. [理由2]
3. [理由3]

### 6.3 前提条件

此建议基于以下假设：
- [假设1]
- [假设2]

### 6.4 下一步行动

1. [行动1]
2. [行动2]

---

## 参考资料

[同上]

---

三、快速报告模板（简化版）

适用于时间紧张或问题较简单的场景。

# [主题] 调研简报

## 核心结论

[一句话结论]

## 关键发现

1. **[发现1]**：[说明] ([来源])
2. **[发现2]**：[说明] ([来源])
3. **[发现3]**：[说明] ([来源])

## 主要差异/要点

| 维度 | 结论 |
|------|------|
| | |
| | |
| | |

## 建议

- [建议1]
- [建议2]

## 参考资料

- [来源1](链接)
- [来源2](链接)

---

交付检查清单

完成报告前，确认以下项目：

• [ ] 摘要可复述：一句话总结清晰，老板能转述
• [ ] 结论有支撑：每个核心结论都有事实卡片支撑
• [ ] 来源可追溯：关键引用都有链接
• [ ] 层次清晰：用小标题切分，可快速定位
• [ ] 不确定性标注：推测性结论有标注
• [ ] 用例落地：至少一个实际场景验证
• [ ] 格式一致：表格、列表、标题风格统一