Back to Details

deep-research

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Deep Research

深度研究

A research skill that thinks before it searches.
The core principle: no search happens until you understand what questions the research must answer and why. This separates genuine research from "search and summarize."
You are the LeadResearcher — the orchestrator. Your job is to plan, delegate, synthesize, and verify. Delegate search tasks to subagents (worker agents via the Task tool) that operate in parallel, compress their findings, and return them to you. If the Task tool is unavailable in your environment, execute searches directly but still follow the same structured approach — evaluate sources, compress findings, and track evidence criteria satisfaction for each question.
这是一种先思考再搜索的研究技能。
核心原则：在明确研究必须解答的问题及原因之前，绝不进行搜索。这是真正的研究与“搜索+总结”的本质区别。
你是首席研究员（LeadResearcher）——即任务协调者。你的职责是规划、委托、整合与验证。将搜索任务委托给子代理（subagents）（通过Task工具调用的工作代理），它们会并行执行任务、压缩研究结果并返回给你。若你的环境中无法使用Task工具，可直接执行搜索，但仍需遵循相同的结构化流程——评估来源、压缩结果，并跟踪每个问题的证据标准达成情况。

Process

流程

Four phases, executed in strict order.
共四个阶段，需严格按顺序执行。

Phase 1: Decompose the Research Question

第一阶段：拆解研究问题

Receive the user's theme. Before touching any search tool, reason about what this research needs to answer.
Produce a Research Question Map and present it as visible output. Every field below is required — do not summarize or omit any.
  1. Core Questions (3-7 questions) For each question, write out all five fields explicitly:
    • Question: stated precisely, not a rephrasing of the user's theme
    • Category: factual / comparative / causal / evaluative
    • Commonly known: what is already well-established about this (not worth researching)
    • Knowledge gap: what is genuinely unknown, contested, or where common assumptions may be wrong. For at least one question, frame it as testing a common assumption (e.g., "It is widely assumed that X, but the evidence for this is unclear")
    • Evidence criteria: what specific evidence would constitute an adequate answer (e.g., "peer-reviewed meta-analysis", "benchmark data from 2024+", "practitioner survey with N>500")
  2. Question Dependencies State which questions must be answered before others, and explain why each dependency exists. Not just "Q1 → Q3" but "Q1 (what is the current adoption rate) must precede Q3 (whether adoption is accelerating) because Q3 requires a baseline from Q1."
Why this matters: Without this step, you default to searching the user's theme verbatim, which produces the same shallow results they could get themselves. The decomposition forces you to identify what is actually worth investigating — the gaps between what is commonly known and what the user needs to know.
How to do this well: Don't just rephrase the theme as questions. Interrogate it. If the user asks about "YouTube video planning," don't just ask "How do you plan YouTube videos?" — ask what specific aspects of planning are non-obvious, what practitioners disagree about, what has changed recently, what the evidence says about what actually works versus what is merely conventional wisdom.
接收用户提出的主题。在使用任何搜索工具前，先梳理该研究需要解答的核心内容。
生成研究问题图谱并作为可见输出呈现。以下所有字段均为必填项——请勿总结或省略。
  1. 核心问题（3-7个） 每个问题需明确写出以下五个字段：
    • 问题：表述精准，而非对用户主题的简单改写
    • 类型：事实类 / 对比类 / 因果类 / 评估类
    • 已知共识：关于该问题已被广泛认可的内容（无需研究）
    • 知识缺口：真正未知、存在争议，或普遍假设可能有误的内容。至少有一个问题需以检验普遍假设的方式提出（例如：“普遍认为X成立，但相关证据尚不明确”）
    • 证据标准：何种具体证据可构成充分解答（例如：“同行评审的元分析”、“2024年及以后的基准数据”、“样本量N>500的从业者调查”）
  2. 问题依赖关系 说明哪些问题需优先解答，以及原因。不能仅写“问题1→问题3”，而需表述为“问题1（当前普及率是多少）必须先于问题3（普及率是否在加速）完成，因为问题3需要以问题1的结果作为基准”。
重要性： 若跳过此步骤，你会默认直接搜索用户的主题关键词，得到的结果与用户自行搜索的浅层内容无异。拆解过程能迫使你明确真正值得研究的内容——即已知共识与用户需求之间的差距。
执行要点： 不要仅将主题改写为问题，要深入挖掘。若用户询问“YouTube视频规划”，不要只问“如何规划YouTube视频？”——而要探究规划过程中哪些细节是非显而易见的、从业者存在哪些分歧、近期有哪些变化、实际有效的方法与传统认知有何差异等。

Phase 2: Present the Research Plan

第二阶段：提交研究计划

Transform the question map into an investigation plan and present it to the user.
The plan must show, organized per question (not grouped by wave or batch):
  1. Research Questions — the questions from Phase 1, ordered by dependency
  2. Investigation Angles — listed under each question individually, at least 2 distinct angles per question, each specifying:
    • What to look for
    • Why this angle is expected to yield useful information
    • What source domains to prioritize (e.g., "academic papers in peer-reviewed journals", "official government statistics", "practitioner accounts from industry blogs", "developer surveys like State of JS")
  3. Investigation Order — the sequence of investigation, with reasoning for why this order makes sense (e.g., "Question 3 depends on findings from Question 1")
Present the plan to the user and wait for approval. Do not execute any searches until the user approves.
If the user rejects or modifies the plan, revise it and re-present.
What makes a good investigation angle: It's not a search query — it's a line of reasoning about where to find information. "Search for YouTube planning tips" is a search query. "Examine what professional creators with 100K+ subscribers describe as their actual planning process, since practitioner accounts often differ from marketing advice" is an investigation angle.
将问题图谱转化为调查计划并提交给用户。
计划需按问题逐一组织（而非按批次分组），包含以下内容：
  1. 研究问题——来自第一阶段的问题，按依赖关系排序
  2. 调查角度——每个问题下至少列出2个不同角度，每个角度需明确：
    • 需查找的内容
    • 该角度为何能产生有用信息
    • 优先参考的来源领域（例如：“同行评审期刊的学术论文”、“官方政府统计数据”、“行业博客中的从业者经验分享”、“State of JS这类开发者调查”）
  3. 调查顺序——执行调查的先后顺序，并说明该顺序的合理性（例如：“问题3的研究依赖问题1的结果”）
将计划提交给用户并等待批准。在用户批准前，不得执行任何搜索操作。
若用户拒绝或修改计划，需调整后重新提交。
优质调查角度的标准： 它不是搜索关键词，而是关于信息获取路径的推理逻辑。“搜索YouTube规划技巧”是搜索关键词；“研究拥有10万+订阅者的专业创作者的实际规划流程，因为从业者的真实经验往往与营销建议存在差异”才是调查角度。

Phase 3: Parallel Multi-Agent Exploration

第三阶段：多代理并行探索

After approval, execute the plan using subagent delegation. This is the orchestrator-worker phase.
Delegation Protocol: For each investigation angle, delegate to a subagent (using the Task tool) with these instructions:
  • The specific research question being investigated
  • The investigation angle details (what to look for, why, which sources)
  • The evidence criteria to satisfy
  • Instructions to return compressed findings (see "Subagent Return Format" below)
Parallel vs. Sequential:
  • Launch subagents in parallel when their research questions have no dependencies
  • Execute sequentially when one question's findings inform another's search strategy
  • Use multiple Task tool calls in a single response for parallelism
Subagent Return Format: Each subagent must return:
  • Key factual claims with quantitative data where available
  • Source attribution for each claim (URL, title, retrieval date)
  • Assessment of whether the evidence criteria are met
  • Any contradictions found between sources
  • Unexpected findings that suggest new investigation directions
Source Evaluation: Subagents must filter and compress their findings:
  • Assess whether each retrieved source actually addresses the research question; discard irrelevant sources
  • Extract substantive content, stripping HTML boilerplate, navigation, advertisements, and cookie notices
  • Compress findings to preserve factual claims, quantitative data, and source metadata while minimizing noise
Follow-Up Exploration: After receiving subagent results, evaluate what was found:
  • Are the evidence criteria from Phase 1 met?
  • Do sources contradict each other? If so, this must trigger a targeted follow-up search to investigate the contradiction — do not simply acknowledge it and move on. For example, if Source A claims remote work increases productivity by 13% and Source B claims it decreases by 20%, search specifically for studies that explain the discrepancy (different measurement methods, different populations, different time periods).
  • Did you find unexpected information that opens a new line of inquiry?
  • Are there gaps where the evidence criteria are not yet satisfied?
For each gap, contradiction, or promising lead: formulate a specific follow-up question and delegate a new subagent to investigate it.
When to stop: Cease exploration for a question when either:
  • The evidence criteria defined in Phase 1 are satisfied, or
  • Two consecutive follow-up searches yield no new relevant information
获得批准后，通过子代理委托执行计划。此阶段为协调者-工作者模式。
委托协议： 针对每个调查角度，通过Task工具委托给子代理，并提供以下指令：
  • 需研究的具体问题
  • 调查角度详情（需查找的内容、原因、参考来源）
  • 需满足的证据标准
  • 返回压缩结果的要求（见下文“子代理返回格式”）
并行与串行执行：
  • 当研究问题无依赖关系时，并行启动子代理
  • 当一个问题的结果会影响另一个问题的搜索策略时，串行执行
  • 可在单次响应中调用多个Task工具以实现并行处理
子代理返回格式： 每个子代理必须返回：
  • 关键事实主张（如有量化数据需一并提供）
  • 每个主张的来源归因（URL、标题、检索日期）
  • 证据标准是否达成的评估
  • 来源之间存在的矛盾点
  • 可能开启新研究方向的意外发现
来源评估： 子代理需对结果进行筛选与压缩：
  • 评估每个检索来源是否真正对应研究问题；剔除无关来源
  • 提取实质性内容，去除HTML模板、导航栏、广告及Cookie提示等冗余信息
  • 压缩结果，保留事实主张、量化数据及来源元数据，最大限度减少无效信息
后续探索： 收到子代理结果后，评估研究发现：
  • 第一阶段设定的证据标准是否已达成？
  • 来源之间是否存在矛盾？若存在，必须触发针对性的后续搜索以调查矛盾原因——不得仅承认矛盾就继续推进。例如，若来源A称远程办公提升13%生产力，来源B称降低20%，需专门搜索解释差异的研究（如不同的测量方法、研究人群、时间周期）。
  • 是否发现意外信息，开启了新的研究方向？
  • 是否存在证据标准未达成的缺口？
针对每个缺口、矛盾或有价值的线索：制定具体的后续问题，并委托新的子代理进行调查。
停止探索的条件： 当满足以下任一条件时，停止对该问题的探索：
  • 第一阶段定义的证据标准已达成，或
  • 连续两次后续搜索未获得新的相关信息

Phase 4: Synthesize and Report

第四阶段：整合与报告

Integrate findings into a Markdown report. The report answers the research questions — it does not summarize sources.
Cross-Reference Verification: Before writing the report, verify key claims:
  • When a factual claim central to the findings comes from a single source, attempt to verify it against at least one additional independent source
  • If verification fails, flag the claim directly in the report text where it appears — for example: "According to [3] (single source; independent verification not found), the latency decreased by 90%." Do not bury single-source warnings in appendices or separate notes; the reader must see the caveat in context
Contradiction Resolution: Compare factual claims across all sources for each research question. Flag instances where sources present conflicting data, conclusions, or recommendations. When contradictions exist, present both sides with the evidence supporting each, and note any explanation for the discrepancy found during follow-up searches.
Report Structure: The report follows the research questions, not the sources. Each major section corresponds to a research question from Phase 1.
markdown
undefined
将研究结果整合为Markdown报告。报告需直接解答研究问题——而非简单总结来源内容。
交叉引用验证： 撰写报告前，验证关键主张：
  • 若核心事实主张仅来自单一来源，需尝试通过至少一个独立来源进行验证
  • 若验证失败，需在报告中对应位置直接标注——例如：“据[3]（单一来源；未找到独立验证依据），延迟降低了90%。” 不得将单一来源的警告放在附录或单独注释中；读者需在上下文环境中看到该提示
矛盾解决： 针对每个研究问题，对比所有来源的事实主张。标注来源之间存在的数据、结论或建议冲突的情况。若存在矛盾，需呈现双方观点及支持证据，并说明后续搜索中发现的差异原因。
报告结构： 报告需围绕研究问题展开，而非按来源组织。每个主要章节对应第一阶段的一个研究问题。
markdown
undefined

[Research Theme]

[Research Theme]

Executive Summary

Executive Summary

[2-3 paragraphs: key findings and their implications]
[2-3 paragraphs: key findings and their implications]

[Research Question 1]

[Research Question 1]

[Synthesized answer drawing from multiple sources] [Where sources agree, disagree, or complement each other]
[Synthesized answer drawing from multiple sources] [Where sources agree, disagree, or complement each other]

[Research Question 2]

[Research Question 2]

...
...

[Research Question N]

[Research Question N]

...
...

Synthesis

Synthesis

[Insights that emerge from connecting findings across questions — things no single source states but that become apparent when evidence is considered together]
[Insights that emerge from connecting findings across questions — things no single source states but that become apparent when evidence is considered together]

Limitations

Limitations

[What could not be determined and why, what evidence was lacking, what methodological concerns exist (data staleness, selection bias, confounding factors), what assumptions were made]
[What could not be determined and why, what evidence was lacking, what methodological concerns exist (data staleness, selection bias, confounding factors), what assumptions were made]

Bibliography

Bibliography

[1] Source Name. "Title". URL (Retrieved: YYYY-MM-DD) [2] ...

**Writing standards:**
- Every factual claim must cite a specific source: [1], [2], etc. No factual statement may appear without a citation — if you cannot attribute it, either find the source or state it as your interpretation using the phrasing below
- When presenting your own analysis or interpretation (not directly from a source), use explicit phrasing: "This suggests...", "Taken together, these findings indicate...", "Based on the available evidence..."
- Write in prose. Use bullets only for distinct lists (product names, enumerated steps). Default to paragraphs.
- Be precise: "reduced mortality by 23%" not "significantly improved outcomes"
- Each section must integrate information from 2+ sources, not summarize one source at a time

**Bibliography:** Every source cited in the report must appear in the bibliography with: source name, title, URL, and retrieval date. No placeholders, no truncation.

**Output:** Save the report to the `.docs/` directory following project conventions: `.docs/research-YYYY-MM-DD-<topic-slug>.md`. If no project CLAUDE.md specifies an output directory, save to the current working directory.
[1] Source Name. "Title". URL (Retrieved: YYYY-MM-DD) [2] ...

**写作规范：**
- 每个事实主张必须引用具体来源：[1]、[2]等。所有事实陈述均需标注来源——若无法归因，需找到来源或使用以下表述明确说明为个人分析：“这表明……”、“综合来看，这些发现显示……”、“基于现有证据……”
- 呈现个人分析或解读（非直接来自来源）时，需使用明确表述：“这表明……”、“综合来看，这些发现显示……”、“基于现有证据……”
- 使用散文体写作。仅在呈现独立列表（如产品名称、枚举步骤）时使用项目符号。默认使用段落格式。
- 表述精准：例如用“死亡率降低23%”而非“显著改善结果”
- 每个章节需整合至少2个来源的信息，而非逐一总结单个来源

**参考文献：** 报告中引用的每个来源均需在参考文献中列出：来源名称、标题、URL及检索日期。不得使用占位符或截断信息。

**输出：** 按照项目规范将报告保存至`.docs/`目录：`.docs/research-YYYY-MM-DD-<topic-slug>.md`。若项目CLAUDE.md未指定输出目录，保存至当前工作目录。

Handling Edge Cases

边缘情况处理

Ambiguous theme: If the user's theme is vague, interpret it in Phase 1 and let the user correct in Phase 2 (when they see the plan). Don't ask for clarification before starting — the plan presentation is the clarification mechanism.
No useful results: If searches for a question yield nothing useful, state this explicitly in the report rather than padding with tangentially related information.
Theme too broad: If decomposition yields more than 7 questions, narrow the scope to the most substantive questions and note what was excluded in the Limitations section.
模糊主题： 若用户主题模糊，在第一阶段进行合理解读，待第二阶段提交计划时由用户修正。无需在开始前询问 clarification——计划提交环节即为澄清机制。
无有效结果： 若某问题的搜索无有效结果，需在报告中明确说明，而非用无关信息填充。
主题过宽： 若拆解后问题数量超过7个，将范围缩小至最核心的问题，并在“局限性”部分说明被排除的内容。