Deep Research

Name: Deep Research
Author: nexu-io
ASecurity
深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。
3,052 stars
0 votes
0 copies
3 views
Added 5/26/2026
researchgogit
Works with

mcp
Security Analysis

A100/100
Scanned 5/27/2026
Install via CLI
$openskills install nexu-io/nexu
Files
SKILL.md
---
name: deep-research
catalog-name: Deep Research
description: |
  深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。
  触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析
  注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。
---

# Deep Research（深度调研 8 步法）

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

## 核心理念

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

## 参考文档

| 文档 | 内容 |
|------|------|
| `templates/intermediate-outputs.md` | 中间产物格式模板 |
| `templates/comparison-framework.md` | 对比框架模板 |
| `templates/fact-card.md` | 事实卡片模板 |
| `templates/report-structure.md` | 报告结构模板 |

---

## 工作目录结构

```
~/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`

---

## 资料分层

| 层级 | 资料类型 | 可信度 |
|------|----------|--------|
| **L1** | 官方文档、论文、规范、RFC | ✅ 高 |
| **L2** | 官方博客、技术演讲、白皮书 | ✅ 高 |
| **L3** | 权威媒体、专家解读、教程 | ⚠️ 中 |
| **L4** | 社区讨论、个人博客、论坛 | ❓ 低 |

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

---

## 执行流程（8 步法）

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

### Step 0: 问题类型判断

| 问题类型 | 核心任务 | 侧重维度 |
|----------|----------|----------|
| 概念对比型 | 建立对比框架 | 机制差异、适用边界 |
| 决策支持型 | 权衡取舍 | 成本、风险、收益 |
| 趋势分析型 | 梳理演进脉络 | 历史、驱动因素、预测 |
| 问题诊断型 | 根因分析 | 症状、原因、证据链 |
| 知识梳理型 | 系统整理 | 定义、分类、关系 |

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

| 敏感级别 | 典型领域 | 资料时间窗口 |
|----------|----------|--------------|
| 🔴 极高 | AI/大模型、区块链 | 3-6 个月 |
| 🟠 高 | 云服务、前端框架 | 6-12 个月 |
| 🟡 中 | 编程语言、数据库 | 1-2 年 |
| 🟢 低 | 算法原理、设计模式 | 无限制 |

**🔴 极高敏感领域强制规则**：
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>`

---

## 报告输出结构

```markdown
# [调研主题] 调研报告

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

## 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 的子问题

**典型症状**：

| 症状 | 表现 | 问题 |
|------|------|------|
| **边界蔓延** | 调研 A，顺便查了 B、C、D | 报告臃肿，重点模糊 |
| **资料囤积** | 收集 50 条资料，只用了 10 条 | 浪费时间，增加噪音 |
| **概念发散** | 解释一个概念时引入 3 个新概念 | 读者认知过载 |
| **炫技式延伸** | 「其实还有更深层的机制……」 | 偏离用户实际需求 |

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

### 核心检查

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

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

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

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

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

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

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

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

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

| 层级 | 含义 | 标注格式 | 示例 |
|------|------|----------|------|
| **已确认** | 一手用户报告证实发生了 | `[已确认]` | "Gemini 服务被禁用" |
| **官方理由** | 执行方的解释/动机 | `[官方理由]` | "OAuth token 可能被滥用于访问更广的 Google 服务" |
| **理论风险** | 技术上可能但未被用户报告证实 | `[理论风险]` | "Gmail、Drive 等服务可能受牵连" |

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

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

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

---

## 来源周全性要求

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

---

## 最终回复规范

**✅ 应该包含**：
- 一句话核心结论
- 关键发现摘要（3-5 点）
- 打包文件位置（`~/outcome.tar.gz`）

**❌ 禁止包含**：
- 过程文件列表
- 详细调研步骤
- 工作目录结构

---

## 版本历史

| 版本 | 变更 |
|------|------|
| v2.1.0 | **新增 Step 6.5**：独立 Agent 校验（BLOCKING），写报告前必须校验事实和推导 |
| v2.0.0 | **重构**：模板外移到 templates/，SKILL.md 精简 |
| v1.6 | 社区声音挖掘机制 |
| v1.5 | 官方下载页面验证、协议名称搜索 |
| v1.4 | 时效敏感性判断机制 |
| v1.3 | 来源周全性要求 |
| v1.2 | 适用对象核查机制 |
| v1.1 | 中间产物管理 |
| v1.0 | 初始版本 |
Deep Research

Works with

Security Analysis

Attribution

Comments (0)
