deep-research

深度研究

此技能可让 AI Agent 对复杂主题开展严谨的多步骤研究。Agent 不会只返回单条搜索结果，而是将研究问题拆分为多个子问题，从不同类型的来源（学术论文、行业报告、官方文档、新闻报道和专家评论）收集信息，交叉比对研究结果以确保一致性，并综合整理成结构清晰、附有引用的报告。最终报告会提供深入分析，呈现细微差异，指出观点冲突，并强调知识空白。

工作流

1. 拆解研究问题： 将用户提出的宏观问题拆分为 3-6 个有针对性的子问题，覆盖主题的不同方面。每个子问题都应聚焦于某个具体角度，例如历史背景、现状、主要参与者、技术细节或未来展望。这样可以确保广泛覆盖主题，而不是只从单次搜索中获取浅层信息。

2. 识别并收集来源： 针对每个子问题，从多个来源类别进行搜索：学术数据库、官方文档、可信的新闻媒体、行业分析师报告和社区论坛。每个子问题至少查找 2-3 个来源。记录每个来源的 URL、发布日期、作者和相关性评分，以便后续排序。

3. 提取并整理关键发现： 阅读每个来源，提取核心论点、数据点、统计数据和专家观点。按主题或子问题将发现整理成结构化提纲。为每项发现标注来源，以便追溯。

4. 交叉比对并验证： 比较不同来源的发现，找出共识、矛盾和空白。标记仅由单一来源支持或与多数证据相矛盾的论点。解决分歧时，注意来源的时效性和权威性。

5. 综合整理报告： 将经验证的发现整合成连贯的叙述。报告应包含执行摘要、各主题的详细章节、对局限性和未解决问题的讨论，以及完整的参考文献列表。使用清晰的标题和项目符号，方便阅读。

6. 审阅并完善： 重新阅读报告，检查逻辑是否连贯、论点是否缺乏依据，以及背景信息是否完整。核实所有引用是否准确，并确认执行摘要能如实概括详细发现。如果仍有空白，可向用户提出进一步研究建议。

用法

向 Agent 提供研究主题，也可以提供具体的子问题、所需的深度级别或偏好的来源类型。Agent 将遵循完整的工作流，并返回结构化报告。

Research the current state of WebAssembly adoption in 2025.

Focus areas:
- Browser and server-side runtime support
- Major companies and projects using WebAssembly in production
- Performance benchmarks compared to native code
- Toolchain maturity (languages, compilers, debugging)
- Key limitations and open challenges

示例

示例 1：2025 年 WebAssembly 的发展现状

用户请求：

深入研究 2025 年 WebAssembly 的发展现状——采用情况、工具链、性能和前景。

查询分解：

子查询	角度
"WebAssembly browser support 2025 Chrome Firefox Safari"	运行时支持
"WebAssembly server-side WASI Wasmtime Wasmer production"	服务端采用情况
"WebAssembly performance benchmarks vs native 2024 2025"	性能数据
"Rust Go C++ compile to WebAssembly toolchain maturity"	工具链生态
"WebAssembly limitations garbage collection threads 2025"	尚待解决的挑战

收集的来源（摘录）：

• W3C WebAssembly 工作组状态报告（w3.org，2025 年 1 月）
• “Figma 中的 Wasm 生产实践”——Figma Engineering Blog（2024）
• Bytecode Alliance WASI 0.2 公告（bytecodealliance.org，2024）
• “WebAssembly 与 JavaScript：2025 年基准测试”——InfoQ（2025）
• MDN Web Docs——WebAssembly GC 提案状态（developer.mozilla.org）

综合报告（摘录）：

执行摘要： WebAssembly 已从仅用于浏览器的技术，发展为适用于服务端、边缘和嵌入式工作负载的可移植编译目标。所有主流浏览器均已全面支持 Wasm 2.0，包括 GC 和 Threads 提案。WASI 0.2 已稳定组件模型，使语言无关的插件架构成为可能，并已被 Fastly、Fermyon 和 Cloudflare Workers 采用。性能基准测试显示，对于计算密集型任务，Wasm 的执行速度可达到原生速度的 85%–95%；不过，启动延迟和 GC 集成仍是持续推进的领域。Rust 和 C/C++ 的工具链生态最为成熟，Go 和 Python 的支持也在迅速改善。尚待解决的关键挑战包括缺乏标准化的调试协议，以及面向 UI 密集型浏览器应用的直接 DOM 访问能力有限。

---

示例 2：产品发布前的竞争分析

用户请求：

为我们的产品发布调研 AI 代码审查工具的竞争格局。

查询分解：

子查询	角度
"AI code review tools market 2025 overview"	市场格局
"GitHub Copilot code review features pricing"	竞争对手深入分析
"CodeRabbit AI automated code review capabilities"	竞争对手深入分析
"developer survey AI code review adoption satisfaction"	用户评价
"AI code review tool limitations false positives"	弱点与缺口

综合报告（摘录）：

市场概述： AI 代码审查市场已形成三个层级：集成式平台工具（GitHub Copilot、GitLab Duo）、独立 AI 审查服务（CodeRabbit、Codacy AI），以及结合大模型增强功能的开源代码检查工具（MegaLinter + GPT 封装器）。开发者采用情况调查显示，在拥有 50 名以上工程师的公司中，42% 的团队使用某种形式的 AI 辅助审查。

发现的竞争缺口： 目前没有工具能提供覆盖整个代码库的架构一致性检查——它们都只针对 PR 差异进行操作。若有产品将差异级建议与代码库级模式约束结合起来，就有机会占领服务不足的“平台工程”细分市场。

最佳实践

• 丰富来源类型。 切勿依赖单一类别的来源。将一手来源（官方文档、数据集）与二手分析（博客文章、分析师报告）结合起来，以获得均衡的观点。
• 记录每项主张的来源信息。 为每条提取的发现附上来源 URL、作者和日期，以便审查最终报告并核实引文。
• 优先选择近期来源，但也要纳入奠基性著作。 优先考虑过去 1-2 年内发布的来源，但也要纳入定义该领域的基础论文或文档。
• 尽可能量化。 将“广泛采用”等模糊主张替换为“38% 的受访团队正在使用”等具体数字，让报告更具可操作性。
• 明确呈现分歧。 来源相互矛盾时，应呈现双方观点及其证据，而非默默择一。这有助于建立信任，也让读者自行判断。
• 尽早划定范围边界。 清楚定义研究的范围内与范围外内容，避免陷入无止境的细枝末节，并让报告保持聚焦。

边缘情况

• 快速演变的主题： 如果研究主题每周都在变化（例如仍在讨论中的政策争议、刚披露的安全漏洞），请醒目注明知识截止日期，并建议用户在采取行动前核实研究结果。
• 来源有限或需付费访问： 如果关键来源需要付费或访问受限，请注明这一缺口，在有摘要或概要时引用，并建议用户获取完整内容进行核实。
• 高权威来源相互矛盾： 如果两个可信度相当的来源直接相互矛盾，请并列呈现双方的主张，说明各自的方法，并将该发现标记为“存在争议”，而非强行给出结论。
• 文献稀少的新兴主题： 对于非常新的技术或概念，应承认现有证据有限，侧重采用一手来源（发行说明、RFC、官方公告），并明确区分已证实的事实与推测。
• 多语言或特定地区的研究： 如果主题涉及多个地理区域，请注明来源覆盖的区域，并指出研究结果可能无法普遍适用于全球。