deep-research

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 年 🟢 低 算法原理、设计模式 无限制 🔴 极高敏感领域强制规则 ： 搜索时带时间约束（ time_range: "month" ） 官方源优先（文档、博客、Changelog） 版本号强制标注（禁止「最新版本支持」） 超过 6 个月的博客仅作历史参考 关键信息至少 2 个独立来源确认 直接访问官方下载页面验证（不依赖搜索缓存） 搜索产品支持的协议名称（MCP、ACP 等） Step 1: 问题拆解与边界界定 把模糊主题拆成 2-4 个可调研的子问题，并 明确研究对象边界 （人群/地域/时间/层级）。 → 保存 ： 00_问题拆解.md Step 2: 资料分层与权威锁定 搜索策略 （高敏感领域）： 官方源定向搜索（限定官方域名） 官方下载页面直接验证（BLOCKING） 协议/功能名称搜索（BLOCKING） 限时广泛搜索 版本核实 社区声音挖掘（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，校验以下维度： 数据准确性 ：关键数字（价格、版本号、参数规模等）做二次搜索验证，至少抽查 3-5 个核心数据点 推导逻辑 ：结论是否有跳跃、是否悄悄升级了确定性层级 遗漏检查 ：是否遗漏了用户关心的关键对比维度 → 保存 ： 05.5_校验记录.md 铁律 ： ❌ 不得跳过此步直接写最终报告 ❌ 不得自己校验自己（必须启动独立 Agent） ✅ 校验通过 → 继续 Step 7-8；校验发现错误 → 回溯修正事实卡片/推导过程 Step 7: 用例验证（Sanity Check） 用一个典型场景验证结论是否成立，检查有无反例。 → 保存 ： 05_验证记录.md Step 8: 可交付化处理 交付三件套 ： 一句话总结 ：可在会上直接复述 结构化章节 ：用小标题切开推导链 证据可追溯 ：关键事实附出处链接 → 保存 ： FINAL_调研报告.md → 打包 ： tar -czvf ~/outcome.tar.gz -C ~/Downloads/research <topic> 报告输出结构 # [调研主题] 调研报告 ## 摘要 [一句话核心结论] ## 1. 概念对齐 ## 2. 工作机制 ## 3. 联系 ## 4. 区别 ## 5. 用例演示 ## 6. 总结与建议 ## 参考资料 详见 templates/report-structure.md 质量检查清单 🎯 边界守恒检查（BLOCKING - 防止调研蔓延） 核心问题 ：调研最容易出的问题不是「查得不够多」，而是「查得太散」。 检查流程 ： 回顾核心问题 ：Step 1 拆解的子问题是什么？用一句话写下来。 资料相关性审计 ：对 01_资料来源.md 中的每条资料，用以下结构化标准判断： 「这条资料能回答哪个子问题？」→ 写出对应的子问题编号 如果无法对应任何子问题 → 删除，不要心疼 如果「有点关系但不直接」→ 降级为补充材料，不进入主报告 ★ 高风险调研（涉及政策、医疗、法律等）：建议使用 Task 工具启动独立 Agent 复核相关性判断（产出者 ≠ 审查者） 事实卡片瘦身 ：对 02_事实卡片.md 中的每张卡片问： 「删掉这张卡片，核心结论还能成立吗？」 如果能 → 这张卡片是 认知负担 ，移到附录或删除 报告聚焦检验 ：最终报告中的每个章节都要能追溯到 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 完全不受影响。读者亲历者指出错误，作者声誉受损。 来源周全性要求 URL 可访问性 ：所有链接公开可访问 引用精确定位 ：标明具体章节/页码 内容对应性 ：引用能在原文找到对应 时效性标注 ：标注发布/更新日期 不可验证信息 ：标注 [来源受限] ，不作为唯一支撑 最终回复规范 ✅ 应该包含 ： 一句话核心结论 关键发现摘要（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 初始版本