Menu
深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。 触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析 注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
| name | deep-research |
| description | 深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。 触发词：/deep-research、深度调研、帮我调研、调研一下、对比分析 注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。 |
将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。
| 文档 | 内容 |
|---|---|
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
每步完成后，立即写入对应文件。
| 问题类型 | 核心任务 | 侧重维度 |
|---|---|---|
| 概念对比型 | 建立对比框架 | 机制差异、适用边界 |
| 决策支持型 | 权衡取舍 | 成本、风险、收益 |
| 趋势分析型 | 梳理演进脉络 | 历史、驱动因素、预测 |
| 问题诊断型 | 根因分析 | 症状、原因、证据链 |
| 知识梳理型 | 系统整理 | 定义、分类、关系 |
| 敏感级别 | 典型领域 | 资料时间窗口 |
|---|---|---|
| 🔴 极高 | AI/大模型、区块链 | 3-6 个月 |
| 🟠 高 | 云服务、前端框架 | 6-12 个月 |
| 🟡 中 | 编程语言、数据库 | 1-2 年 |
| 🟢 低 | 算法原理、设计模式 | 无限制 |
🔴 极高敏感领域强制规则：
time_range: "month"）把模糊主题拆成 2-4 个可调研的子问题，并明确研究对象边界（人群/地域/时间/层级）。
→ 保存：00_问题拆解.md
搜索策略（高敏感领域）：
适用对象核查（BLOCKING）：收录资料前必须验证适用对象与研究边界匹配。
→ 保存：01_资料来源.md（持续更新）
把资料转化为可核验事实卡片，区分「官方说的」和「我推测的」。
→ 保存：02_事实卡片.md（持续更新）
根据问题类型选择固定维度：
→ 保存：03_对比框架.md
确保对比各方定义稳定、公认、无歧义。
显式写出「事实 → 对照 → 结论」的推导过程，每个结论都能追溯到具体事实。
⚠️ 推导防护：结论不得悄悄升级事实卡片中的确定性层级。
→ 保存：04_推导过程.md
时机：事实卡片 + 推导过程完成后，写最终报告前。
原则：遵循 CLAUDE.md「计划校验」规范 — 产出者 ≠ 审查者。
执行方式：启动独立 Agent（Task 工具），将 02_事实卡片.md 和 04_推导过程.md 交给 Agent，校验以下维度：
→ 保存：05.5_校验记录.md
铁律：
用一个典型场景验证结论是否成立，检查有无反例。
→ 保存：05_验证记录.md
交付三件套：
→ 保存：FINAL_调研报告.md
→ 打包：tar -czvf ~/outcome.tar.gz -C ~/Downloads/research <topic>
# [调研主题] 调研报告
## 摘要
[一句话核心结论]
## 1. 概念对齐
## 2. 工作机制
## 3. 联系
## 4. 区别
## 5. 用例演示
## 6. 总结与建议
## 参考资料
详见 templates/report-structure.md
核心问题：调研最容易出的问题不是「查得不够多」，而是「查得太散」。
检查流程：
回顾核心问题：Step 1 拆解的子问题是什么？用一句话写下来。
资料相关性审计：对 01_资料来源.md 中的每条资料，用以下结构化标准判断：
事实卡片瘦身：对 02_事实卡片.md 中的每张卡片问：
报告聚焦检验：最终报告中的每个章节都要能追溯到 Step 1 的子问题
典型症状：
| 症状 | 表现 | 问题 |
|---|---|---|
| 边界蔓延 | 调研 A，顺便查了 B、C、D | 报告臃肿，重点模糊 |
| 资料囤积 | 收集 50 条资料，只用了 10 条 | 浪费时间，增加噪音 |
| 概念发散 | 解释一个概念时引入 3 个新概念 | 读者认知过载 |
| 炫技式延伸 | 「其实还有更深层的机制……」 | 偏离用户实际需求 |
铁律：调研的目标是回答问题，不是展示知识面。
核心问题：调研涉及封禁、限制、政策执行等「行动」时，最容易犯的错误是把理论风险等同于实际后果。
错误模式：
三层区分（事实卡片和报告中必须明确标注）：
| 层级 | 含义 | 标注格式 | 示例 |
|---|---|---|---|
| 已确认 | 一手用户报告证实发生了 | [已确认] | "Gemini 服务被禁用" |
| 官方理由 | 执行方的解释/动机 | [官方理由] | "OAuth token 可能被滥用于访问更广的 Google 服务" |
| 理论风险 | 技术上可能但未被用户报告证实 | [理论风险] | "Gmail、Drive 等服务可能受牵连" |
检查清单：
铁律：「X 在技术上可能发生」≠「X 已经发生」。报告中描述执行后果时，只能使用「已确认」层级的事实。「理论风险」可以作为分析维度呈现，但必须明确标注，不得混入事实性陈述。
典型事故：调研报告说「整个 Google 账户生态可能受影响」（基于 OAuth 理论范围），文章据此写「Gmail、Drive、Cloud 都受牵连——你的数字生活被掐断」。实际上用户报告只有 Gemini/Antigravity 被禁用，Gmail/Drive 完全不受影响。读者亲历者指出错误，作者声誉受损。
[来源受限]，不作为唯一支撑✅ 应该包含：
~/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 | 初始版本 |
Based on SOC occupation classification
