Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From deep-research
深度调研方法论（8步法）：将模糊主题转化为高质量调研报告。 自动执行问题拆解、资料分层、事实抽取、框架对比、推导验证，输出可交付的结构化报告。 触发词： - "深度调研"、"深度研究"、"深入分析" - "帮我调研"、"调研一下"、"研究一下" - "对比分析"、"概念对比"、"技术对比" - "写调研报告"、"出调研报告" 注意：如果用户需要的是可视化图谱而非报告，请使用 research-to-diagram skill。
How this skill is triggered — by the user, by Claude, or both
Slash command
/deep-research:deep-researchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。
将用户提出的模糊主题，通过系统化方法转化为高质量、可交付的调研报告。
调研开始时，必须在 ~/Downloads/research/ 下创建以主题命名的工作目录：
~/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_验证记录.md # Step 7 产出：用例验证结果
├── FINAL_调研报告.md # Step 8 产出：最终交付物
└── raw/ # 原始资料存档（可选）
├── source_1.md
└── source_2.md
| 步骤 | 完成后立即保存 | 文件名 |
|---|---|---|
| Step 0-1 | 问题类型判断 + 子问题列表 | 00_问题拆解.md |
| Step 2 | 每个查阅的资料链接、层级、摘要 | 01_资料来源.md |
| Step 3 | 每条事实卡片（陈述+出处+置信度） | 02_事实卡片.md |
| Step 4 | 选定的对比框架 + 初步填充 | 03_对比框架.md |
| Step 6 | 每个维度的推导过程 | 04_推导过程.md |
| Step 7 | 验证场景 + 结果 + 回查清单 | 05_验证记录.md |
| Step 8 | 完整调研报告 | FINAL_调研报告.md |
当用户想要：
关键词：
与其他 Skill 的区分：
research-to-diagramwsy-writermaterial-to-markdown首先判断调研问题属于哪种类型，选择对应策略：
| 问题类型 | 核心任务 | 侧重维度 |
|---|---|---|
| 概念对比型 | 建立对比框架 | 机制差异、适用边界 |
| 决策支持型 | 权衡取舍 | 成本、风险、收益 |
| 趋势分析型 | 梳理演进脉络 | 历史、驱动因素、预测 |
| 问题诊断型 | 根因分析 | 症状、原因、证据链 |
| 知识梳理型 | 系统整理 | 定义、分类、关系 |
在开始调研前，必须判断问题的时效敏感性，这将决定资料筛选策略。
| 敏感级别 | 典型领域 | 资料时间窗口 | 说明 |
|---|---|---|---|
| 🔴 极高 | AI/大模型、区块链、加密货币 | 3-6 个月 | 技术迭代极快，几个月前的信息可能已完全过时 |
| 🟠 高 | 云服务、前端框架、API 接口 | 6-12 个月 | 版本更新频繁，需确认当前版本 |
| 🟡 中 | 编程语言、数据库、操作系统 | 1-2 年 | 相对稳定但仍在演进 |
| 🟢 低 | 算法原理、设计模式、理论概念 | 无限制 | 基础原理变化慢 |
当调研主题涉及以下领域时，必须执行特殊规则：
触发词识别：
强制执行的规则：
搜索时带时间约束：
time_range: "month" 或 time_range: "week" 限制搜索结果start_date: "YYYY-MM-DD" 设置为 3 个月内官方源优先级提升：
版本号强制标注：
过时信息处置：
交叉验证：
官方下载/发布页面直接验证（BLOCKING）：
mcp__tavily-mcp__tavily-extract 或 WebFetch 直接提取下载页面https://product.com/download 或 https://github.com/xxx/releases产品特定协议/功能名称搜索（BLOCKING）：
"<产品名> <协议名> support" 或 "<产品名> <协议名> integration"## 时效敏感性评估
- **调研主题**：[主题]
- **敏感级别**：🔴极高 / 🟠高 / 🟡中 / 🟢低
- **判断依据**：[为什么是这个级别]
- **资料时间窗口**：[X 个月/年]
- **优先查阅的官方源**：
1. [官方源 1]
2. [官方源 2]
- **需要核实的关键版本信息**：
- [产品/技术 1]: 当前版本 ____
- [产品/技术 2]: 当前版本 ____
📁 保存动作：将时效性评估追加到 00_问题拆解.md 末尾
把模糊主题拆成 2-4 个可调研的子问题：
⚠️ 研究对象界定（BLOCKING - 必须明确）：
在拆解问题时，必须明确定义研究对象的边界：
| 维度 | 必须明确的边界 | 示例 |
|---|---|---|
| 人群 | 研究的是哪个群体？ | 大学生 vs 中小学生 vs 职校生 vs 所有学生 |
| 地域 | 研究的是哪个地区？ | 中国高校 vs 美国高校 vs 全球 |
| 时间 | 研究的是哪个时期？ | 2020年后 vs 历史全貌 |
| 层级 | 研究的是哪个层面？ | 本科 vs 研究生 vs 高职 |
典型错误：用户问「大学生课堂问题」，却收录了针对「中小学生」的政策——适用对象不匹配会导致整个调研失效。
📁 保存动作：
~/Downloads/research/<topic>/00_问题拆解.md，包含：
按权威性给资料分级，优先消费一手资料：
| 层级 | 资料类型 | 用途 | 可信度 |
|---|---|---|---|
| L1 | 官方文档、论文、规范、RFC | 定义、机制、可核验事实 | ✅ 高 |
| L2 | 官方博客、技术演讲、白皮书 | 设计意图、架构思想 | ✅ 高 |
| L3 | 权威媒体、专家解读、教程 | 补充直觉、案例 | ⚠️ 中 |
| L4 | 社区讨论、个人博客、论坛 | 发现盲点、验证理解 | ❓ 低 |
L4 社区来源的具体化（产品对比调研必查）：
| 来源类型 | 获取方式 | 价值 |
|---|---|---|
| GitHub Issues | 直接访问 github.com/<org>/<repo>/issues | 用户真实痛点、功能请求、Bug 反馈 |
| GitHub Discussions | 访问 github.com/<org>/<repo>/discussions | 功能讨论、使用心得、社区共识 |
搜索 site:reddit.com "<产品名>" | 用户真实评价、对比讨论 | |
| Hacker News | 搜索 site:news.ycombinator.com "<产品名>" | 技术社区深度讨论 |
| Discord/Telegram | 产品官方社群 | 活跃用户反馈（需标注[来源受限]） |
原则：
⏰ 时效性筛选规则（根据 Step 0.5 的敏感级别执行）：
| 敏感级别 | 资料筛选规则 | 搜索参数建议 |
|---|---|---|
| 🔴 极高 | 仅接受 6 个月内的资料作为事实依据 | time_range: "month" 或 start_date 设为近 3 个月 |
| 🟠 高 | 优先 1 年内资料，超过 1 年需标注 | time_range: "year" |
| 🟡 中 | 2 年内资料正常使用，超过需验证有效性 | 默认搜索 |
| 🟢 低 | 无时间限制 | 默认搜索 |
高敏感领域的搜索策略：
1. 第一轮：官方源定向搜索
- 使用 include_domains 限定官方域名
- 示例：include_domains: ["anthropic.com", "openai.com", "docs.xxx.com"]
2. 第二轮：官方下载/发布页面直接验证（BLOCKING）
- 直接访问官方下载页面，不依赖搜索缓存
- 使用 tavily-extract 或 WebFetch 提取页面内容
- 核验：平台支持、当前版本号、发布日期
- 这一步必须做，搜索引擎可能缓存过时的"Coming soon"信息
3. 第三轮：产品特定协议/功能搜索（BLOCKING）
- 搜索产品支持的协议名称（MCP、ACP、LSP 等）
- 格式：`"<产品名> <协议名>" site:官方域名`
- 这些集成功能往往不在主页展示，但在专门文档中有说明
4. 第四轮：限时广泛搜索
- time_range: "month" 或 start_date 设为近期
- 排除明显过时的来源
5. 第五轮：版本核实
- 对搜索结果中的版本号进行交叉验证
- 发现不一致立即查阅官方 Changelog
6. 第六轮：社区声音挖掘（BLOCKING - 产品对比调研必做）
- 访问产品的 GitHub Issues 页面，查看热门/置顶 issue
- 搜索 Issues 中的关键功能词（如 "MCP"、"plugin"、"integration"）
- 查看最近 3-6 个月的讨论趋势
- 识别用户最关心的功能点和差异化特性
- 这一步的价值：官方文档往往不会强调"别人没有而我有"的功能，但社区讨论会
社区声音挖掘的具体操作：
GitHub Issues 挖掘步骤：
1. 访问 github.com/<org>/<repo>/issues
2. 按 "Most commented" 排序，查看热门讨论
3. 搜索关键词：
- 功能类：feature request, enhancement, MCP, plugin, API
- 对比类：vs, compared to, alternative, migrate from
4. 查看 issue 标签：enhancement, feature, discussion
5. 记录高频出现的功能诉求和用户痛点
价值转化：
- 高频讨论的功能 → 可能是差异化亮点
- 用户抱怨/请求 → 可能是产品短板
- 对比讨论 → 直接获取用户视角的差异分析
资料时效性标注模板（追加到资料来源记录）：
- **发布日期**：[YYYY-MM-DD]
- **时效状态**：✅当前有效 / ⚠️需验证 / ❌已过时
- **版本信息**：[如适用，标注涉及的版本号]
工具使用：
mcp__plugin_context7_context7__query-docs 获取技术文档WebSearch 或 mcp__tavily-mcp__tavily-search 进行广泛搜索mcp__tavily-mcp__tavily-extract 提取具体页面内容⚠️ 适用对象核查（BLOCKING - 收录前必查）：
每收录一条资料前，必须核查其适用对象是否与研究边界匹配：
| 资料类型 | 必须核查的适用对象 | 核查方法 |
|---|---|---|
| 政策/法规 | 针对谁？（中小学生/大学生/所有人） | 查看文件标题、适用范围条款 |
| 学术研究 | 样本是谁？（职校生/本科生/研究生） | 查看研究方法/样本描述章节 |
| 统计数据 | 统计的是哪个群体？ | 查看数据来源说明 |
| 案例报道 | 涉及的是哪类机构？ | 确认机构类型（高校/中学/职校） |
不匹配的资料处理：
📁 保存动作：
每查阅一个资料，立即追加到 01_资料来源.md：
## 资料 #[序号]
- **标题**：[资料标题]
- **链接**：[URL]
- **层级**：L1/L2/L3/L4
- **发布日期**：[YYYY-MM-DD]
- **时效状态**：✅当前有效 / ⚠️需验证 / ❌已过时（仅参考）
- **版本信息**：[如涉及特定版本，必须标注]
- **适用对象**：[明确标注该资料针对的群体/地域/层级]
- **与研究边界匹配**：✅完全匹配 / ⚠️部分重叠 / 📎仅作参考
- **摘要**：[1-2句关键内容]
- **与子问题关联**：[对应哪个子问题]
把资料转化为可核验事实卡片：
## 事实卡片
### 事实 1
- **陈述**：[具体事实描述]
- **出处**：[链接/文档章节]
- **置信度**：高/中/低
### 事实 2
...
关键纪律：
📁 保存动作：
每抽取一条事实，立即追加到 02_事实卡片.md：
## 事实 #[序号]
- **陈述**：[具体事实描述]
- **出处**：[资料#序号] [链接]
- **适用对象**：[该事实适用于哪个群体，继承自资料或进一步细化]
- **置信度**：✅/⚠️/❓
- **关联维度**：[对应的对比维度]
⚠️ 事实陈述中的适用对象：
根据问题类型，选择固定的分析维度：
通用维度（按需选用）：
概念对比型专用维度：
决策支持型专用维度：
📁 保存动作：
写入 03_对比框架.md：
# 对比框架
## 选定的框架类型
[概念对比型/决策支持型/...]
## 选定的维度
1. [维度1]
2. [维度2]
...
## 初步填充
| 维度 | X | Y | 事实依据 |
|------|---|---|----------|
| [维度1] | [描述] | [描述] | 事实#1, #3 |
| ... | | | |
确保对比的各方都有清晰、统一的定义：
检查清单：
显式写出「事实 → 对照 → 结论」的推导过程：
## 推导过程
### 关于 [维度名称]
1. **事实确认**：根据 [来源]，X 的机制是...
2. **对照参照物**：而 Y 的机制是...
3. **结论**：因此，X 与 Y 在此维度上的差异是...
关键纪律：
📁 保存动作：
写入 04_推导过程.md：
# 推导过程
## 维度 1：[维度名称]
### 事实确认
根据 [事实#X]，X 的机制是...
### 对照参照物
而 Y 的机制是...（来源：[事实#Y]）
### 结论
因此，X 与 Y 在此维度上的差异是...
### 置信度
✅/⚠️/❓ + 理由
---
## 维度 2：[维度名称]
...
用一个典型场景验证结论是否成立：
验证问题：
回查清单：
📁 保存动作：
写入 05_验证记录.md：
# 验证记录
## 验证场景
[场景描述]
## 按结论预期
如果用 X：[预期行为]
如果用 Y：[预期行为]
## 实际验证结果
[实际情况]
## 是否有反例
[有/无，如有则描述]
## 回查清单
- [x] 初稿结论与事实卡片一致
- [x] 无遗漏重要维度
- [x] 无过度推断
- [ ] 发现问题：[如有]
## 需要修正的结论
[如有]
让报告老板能读、能转述、能追溯：
交付三件套：
📁 保存动作：
整合所有中间产物，写入 FINAL_调研报告.md：
00_问题拆解.md 提取背景02_事实卡片.md 引用关键事实04_推导过程.md 整理结论01_资料来源.md 生成参考文献05_验证记录.md 补充用例# [调研主题] 调研报告
## 摘要
[一句话总结核心结论]
## 1. 概念对齐
### 1.1 X 是什么
[定义 + 为什么存在]
### 1.2 Y 是什么（参照物）
[作为对比基准]
## 2. 工作机制
[X 怎么运行，这是核心差异点]
## 3. 联系
[共同解决的问题，3-4 点]
## 4. 区别
[按维度逐项对比，突出决定性差异]
## 5. 用例演示
[把抽象落地到具体场景]
## 6. 总结与建议
[可复述的结论 + 可操作的建议]
## 参考资料
[所有引用的来源链接]
根据受众调整内容深度：
| 受众 | 侧重 | 详略 |
|---|---|---|
| 决策者 | 结论、风险、建议 | 简洁，强调可操作性 |
| 执行者 | 具体机制、操作方法 | 详细，强调如何做 |
| 技术专家 | 细节、边界条件、限制 | 深入，强调准确性 |
默认保存位置：~/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_验证记录.md | 用例验证和回查 | Step 7 完成后 |
FINAL_调研报告.md | 完整交付报告 | Step 8 完成后 |
可选文件：
raw/*.md - 原始资料存档（内容较长时保存）┌─────────────────────────────────────────────────────────────┐
│ 深度调研 8 步法 │
├─────────────────────────────────────────────────────────────┤
│ 0. 判断问题类型 → 选择对应框架模板 │
│ 1. 问题拆解 → 2-4 个可调研子问题 │
│ 2. 资料分层 → L1官方 > L2博客 > L3媒体 > L4社区 │
│ 3. 事实抽取 → 每条带出处、标置信度 │
│ 4. 建立框架 → 固定维度，结构化对比 │
│ 5. 参照物对齐 → 确保定义统一 │
│ 6. 推导链 → 事实→对照→结论，显式写出 │
│ 7. 用例验证 → Sanity check，防止纸上谈兵 │
│ 8. 交付化 → 一句话总结 + 结构化章节 + 证据可追溯 │
├─────────────────────────────────────────────────────────────┤
│ 报告结构：定义→机制→联系→区别→用例→总结 │
│ 关键纪律：结论来自机制对比，不是"我感觉像" │
└─────────────────────────────────────────────────────────────┘
用户：帮我深度调研 REST API 和 GraphQL 的区别
执行流程：
用户：我们应该选 PostgreSQL 还是 MongoDB？帮我调研一下
执行流程：
用户：AI Agent 的发展趋势是什么？深入分析一下
执行流程：
核心原则：报告中引用的每一条外部信息，用户都必须能够直接验证。
强制执行的规则：
URL 可访问性：
[需登录]引用精确定位：
[来源: OpenAI Blog, 2024-03-15, "GPT-4 Technical Report", §3.2 Safety]内容对应性：
时效性标注：
不可验证信息的处理：
[来源受限]完成报告前，检查以下项目：
当调研主题属于 🔴极高 或 🟠高 敏感级别时，必须完成以下检查：
00_问题拆解.md 中包含时效性评估章节典型社区声音遗漏错误案例：
❌ 错误：仅依赖官方文档，报告中 MCP 只作为普通功能点一笔带过 ✅ 正确：通过 GitHub Issues 发现 MCP 是社区最热议的功能，在报告中重点展开分析其价值
❌ 错误：「Alma 和 Cherry Studio 都支持 MCP」（没有分析差异） ✅ 正确：通过社区讨论发现「Alma 的 MCP 实现与 Claude Code 高度一致，这是其核心竞争力」
典型平台支持/协议遗漏错误案例：
❌ 错误：「Alma 仅支持 macOS」（基于搜索引擎缓存的 "Coming soon" 信息） ✅ 正确：直接访问 alma.now/download 页面，核验当前实际支持的平台
❌ 错误：「Alma 支持 MCP」（只搜索了 MCP，遗漏了 ACP） ✅ 正确：同时搜索 "Alma MCP" 和 "Alma ACP"，发现 Alma 还支持 ACP 协议集成 CLI 工具
典型时效性错误案例：
❌ 错误：「Claude 支持 function calling」（未标注版本，且可能指的是旧版本能力） ✅ 正确：「Claude 3.5 Sonnet (claude-3-5-sonnet-20241022) 通过 Tool Use API 支持函数调用，最大支持 8192 tokens 的工具定义」
❌ 错误：「根据 2023 年的博客，GPT-4 的上下文长度是 8K」 ✅ 正确：「截至 2024 年 1 月，GPT-4 Turbo 支持 128K 上下文（来源：OpenAI 官方文档，2024-01-25 更新）」
这是最容易被忽略、也是最致命的检查项：
00_问题拆解.md 中有清晰的人群/地域/时间/层级界定01_资料来源.md 中每条资料都有「适用对象」和「与研究边界匹配」字段02_事实卡片.md 中每条事实的适用对象与研究边界一致典型错误案例：
研究主题：「大学生课堂不抬头问题」 错误引用：「2025年10月教育部发文禁止手机进课堂」 问题：该政策针对的是中小学生，不是大学生 后果：读者误以为教育部禁止大学生带手机，严重误导
调研完成后，将工作目录打包：
tar -czvf ~/outcome.tar.gz -C <parent_dir> <workspace_name>
~/outcome.tar.gz 已存在，直接覆盖调研完成后，向用户回复时：
✅ 应该包含：
~/outcome.tar.gz）❌ 禁止包含：
00_问题拆解.md、01_资料来源.md 等）原因：过程文件是给后续回溯用的，不是给用户看的。用户关心的是结论，不是过程。
v1.6 (2026-01-12): 新增社区声音挖掘机制
v1.5 (2026-01-12): 增强高敏感领域调研准确性
v1.4 (2026-01-12): 添加时效敏感性判断机制
v1.3 (2026-01-11): 添加来源周全性要求（Source Verifiability）
v1.2 (2026-01-11): 增加适用对象核查机制
v1.1 (2025-01-11): 增强中间产物管理
v1.0 (2025-01-11): 初始版本
Guides completion of development work by verifying tests, detecting environment, and presenting structured options for merge, PR, or cleanup.
Enforces test-driven development: write failing test first, then minimal code to pass. Use when implementing features or bugfixes.
Guides creation and editing of skills using test-driven development with pressure scenarios and subagents to verify agent compliance.
npx claudepluginhub basicsix/deep-research