deep-researcher

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Deep Researcher

Overview

概述

Deep research IS systematic information verification with evidence trails.

The deep-researcher superpower converts vague research requests into structured investigation with explicit confidence levels. Instead of "I found X", it's "X verified by 3 independent sources, accessed [dates], confidence level: high".

Core principle: Research without verification is just collection. Verification without evidence is faith.

深度研究是指带有证据追踪的系统性信息验证。

Deep Researcher 能力可将模糊的研究请求转化为结构化的调查，并明确标注置信度等级。不再是“我发现了X”，而是“X已通过3个独立来源验证，获取日期[具体日期]，置信度等级：高”。

核心原则：未经验证的研究只是信息收集。没有证据的验证只是主观判断。

When to Use

适用场景

Use deep researcher when you need:

Verified findings - Claims backed by 3+ independent sources
Evidence trails - Exact URLs, access dates, source credibility assessment
Confidence levels - Know which findings are solid vs. speculative
Multi-source synthesis - Patterns across authorities, not single-source claims
Technical research - Architecture decisions, implementation patterns, best practices
Fact-checking - Contradicting sources identified and explained
Future reference - Structured output you can re-read and cite later

Don't use when:

You need real-time data (stock prices, current weather, today's events)
Single authoritative source is sufficient (official docs, RFC specifications)
Request is vague without topic or storage destination
Research is project-specific (create CLAUDE.md instead)

在以下场景中使用Deep Researcher：

已验证的研究结果 - 结论由3个及以上独立来源支持
证据追踪 - 提供精确的URL、获取日期、来源可信度评估
置信度等级 - 明确区分哪些研究结果可靠，哪些属于推测
多源信息综合 - 整合多个权威来源的模式，而非单一来源的结论
技术研究 - 架构决策、实现模式、最佳实践
事实核查 - 识别并解释相互矛盾的来源
未来参考 - 结构化输出内容，便于后续重读和引用

不适用场景：

需要实时数据（如股票价格、当前天气、当日事件）
单一权威来源已足够（如官方文档、RFC规范）
请求模糊，无明确主题或存储目标
项目专属研究（应创建CLAUDE.md）

Request Structure (REQUIRED)

请求结构（必填）

Deep researcher needs three things:

Topic (required) - Clear research question
- "Compare authentication strategies in modern web frameworks"
- "Investigate performance implications of different database indexing approaches"
- "Research current best practices for handling TypeScript error types"

Storage Prefix (required) - Where output files go

```
/research/auth-strategies
```
```
./findings/database-performance
```
```
~/projects/typescript-research
```

Things to Avoid (optional) - Topics or sources to exclude
- "Avoid paywalled academic papers"
- "Skip marketing materials, focus on technical documentation"
- "Exclude blog posts older than 2 years"

Rejection Protocol: Missing topic or storage prefix? Researcher rejects request. You must also reject vague requests. If you can't extract clear topic, storage prefix, and avoid list from a request, REFUSE TO DELEGATE. State back what you'd need to proceed. Vague input = vague output—rejecting protects both you and the researcher.

Under pressure to skip this? Time pressure, authority pressure, urgency—none of these change this requirement. 10 minutes structuring saves 2+ hours of re-research.

Deep Researcher 需要以下三项信息：

主题（必填）- 清晰的研究问题
- "对比现代Web框架中的认证策略"
- "研究不同数据库索引方式对性能的影响"
- "调研当前处理TypeScript错误类型的最佳实践"

存储前缀（必填）- 输出文件的存储路径

```
/research/auth-strategies
```
```
./findings/database-performance
```
```
~/projects/typescript-research
```

需规避内容（可选）- 需排除的主题或来源
- "避免付费学术论文"
- "跳过营销材料，重点关注技术文档"
- "排除发布时间超过2年的博客文章"

拒绝规则： 若缺少主题或存储前缀，研究工具将拒绝请求。你也必须拒绝模糊的请求。如果无法从请求中提取清晰的主题、存储前缀和规避列表，请拒绝委托。告知对方需要补充哪些信息才能继续。模糊的输入只会产生模糊的输出——拒绝请求是为了保护你和研究工具的成果。

面临压力想跳过这一步？ 时间压力、权威压力、紧急性——这些都不能改变这项要求。花10分钟整理结构，能节省2小时以上的重复研究时间。

Research Methodology

研究方法论

Phase 1: Topic Scoping & Planning

阶段1：主题界定与规划

Break research question into specific sub-questions. Identify primary vs. secondary sources. Define verification strategy before searching.

Critical: If request comes with implicit bias (e.g., "prove this was right"), reframe it objectively. Research meant to validate past decisions is corrupted at intake. Authority pressure doesn't change this—reframe and present both versions to the requester.

Example: "Compare auth strategies" becomes:

What strategies exist? (primary: official docs)
Pros/cons of each? (secondary: technical analysis)
Which scale best? (secondary: community discussion, benchmarks)
Current industry consensus? (secondary: recent articles, GitHub patterns)

When reframing: Director says "Prove our choice was right" → You propose "Compare our choice vs. alternatives objectively" → Either validates the choice (stronger vindication) or reveals issues early (valuable).

将研究问题拆解为具体的子问题。区分主要来源与次要来源。在搜索前确定验证策略。

关键提示： 若请求带有隐含偏见（如“证明我们的选择是正确的”），需将其重构为客观表述。旨在验证过往决策的研究从一开始就存在偏差。即使面临权威压力，也要重构请求并向委托方呈现两种方案。

示例： “对比认证策略”可拆解为：

现有哪些认证策略？（主要来源：官方文档）
每种策略的优缺点？（次要来源：技术分析）
哪些策略的扩展性最佳？（次要来源：社区讨论、基准测试）
当前行业共识是什么？（次要来源：近期文章、GitHub模式）

重构示例： 主管要求“证明我们的选择是正确的”→ 你提出“客观对比我们的选择与其他方案”→ 要么能更有力地验证原有选择，要么能提前发现问题（同样具有价值）。

Phase 2: Source Collection & Crawling

阶段2：来源收集与爬取

Primary sources: Official documentation, RFCs, original research, API references
Secondary sources: Technical analysis, blog posts, code examples, community discussion
Target: 3-5 independent authoritative sources per claim
Document: URLs, access dates, source type, author/publisher

主要来源： 官方文档、RFC、原始研究、API参考
次要来源： 技术分析、博客文章、代码示例、社区讨论
目标： 每个结论对应3-5个独立权威来源
记录内容： URL、获取日期、来源类型、作者/发布方

Phase 3: Information Collation

阶段3：信息整理

Organize findings by theme. Note agreements and disagreements. Identify patterns, outliers, contradictions.

按主题组织研究结果。记录不同来源的共识与分歧。识别模式、异常点和矛盾点。

Phase 4: Verification & Fact-Checking

阶段4：验证与事实核查

For each major claim:

Element	What
Source URL	Exact location of information
Access Date	When retrieved
Source Type	Academic, official docs, news, community, blog
Author/Publisher	Who created this
Confidence	high (3+ independent agreement), medium (2 sources), low (single source)
Contradictions	Any sources disagreeing

Handling contradictions: When sources disagree, investigate why. Allocate 1-2 hours to understand context-dependence. If 1-2 hours doesn't resolve it, document the contradiction at medium/low confidence rather than picking one source arbitrarily. Contradictions are information—they tell you the topic is context-dependent.

Under exhaustion pressure? The skill doesn't make fatigue disappear. What it does is make lazy source-picking shameful. Document why you picked one over others, or spend the time understanding the disagreement. Don't pretend "they all have merits" is research.

针对每个主要结论：

元素	说明
来源URL	信息的精确获取地址
获取日期	信息的检索时间
来源类型	学术文献、官方文档、新闻、社区内容、博客
作者/发布方	内容的创建者
置信度	高（3个及以上独立来源一致）、中（2个来源）、低（单一来源）
矛盾点	存在异议的来源

矛盾点处理： 当来源存在分歧时，调查背后的原因。分配1-2小时理解场景依赖性。若1-2小时内无法解决分歧，需记录矛盾点并标注为中/低置信度，而非随意选择某一来源。矛盾点本身也是信息——它说明该主题具有场景依赖性。

感到疲惫时？ 该能力无法消除疲劳，但能避免随意选择来源的偷懒行为。记录你选择某一来源的原因，或花时间理解分歧所在。不要用“各有优劣”来敷衍研究。

Phase 5: Structured Output

阶段5：结构化输出

Research writes to provided directory:

<prefix>/
├── <topic>-thinking.md       # Reasoning, methodology, decisions
├── <topic>-research.md       # Raw findings organized by theme
├── <topic>-verification.md   # Evidence of verification, source audit
├── <topic>-insights.md       # Key insights, patterns, implications
└── <topic>-summary.md        # Executive summary with conclusions

研究结果将写入指定目录：

<prefix>/
├── <topic>-thinking.md       # 推理过程、研究方法、决策记录
├── <topic>-research.md       # 按主题整理的原始研究结果
├── <topic>-verification.md   # 验证证据、来源审核记录
├── <topic>-insights.md       # 关键见解、模式、影响分析
└── <topic>-summary.md        # 包含结论的执行摘要

Output Format

输出格式

thinking.md

Your research process, decisions made, rabbit holes explored, assumptions, limitations.

记录你的研究过程、做出的决策、探索的方向、假设前提和局限性。

research.md

Findings organized by key themes or questions. Direct quotes with source attribution. Publication dates. Both supporting and contradicting evidence.

按关键主题或问题组织研究结果。直接引用内容需标注来源。包含发布日期。同时呈现支持和矛盾的证据。

verification.md

Source credibility matrix. Verification approach for each claim. Cross-reference patterns. Confidence levels. Gaps or unverifiable claims. URLs with access dates.

来源可信度矩阵。每个结论的验证方法。交叉引用模式。置信度等级。研究空白或无法验证的结论。带获取日期的URL。

insights.md

Patterns synthesized across sources. Emerging consensus vs. outlier views. Surprising findings. Areas needing further research.

跨来源整合的模式。新兴共识与非主流观点。意外发现。需要进一步研究的领域。

summary.md

1-2 paragraph executive summary. Key findings with confidence levels. Main limitations or caveats. Recommendations.

1-2段的执行摘要。带置信度等级的关键研究结果。主要局限性或注意事项。建议。

Core Standards

核心标准

No speculation - Flag anything not directly sourced

No synthesis without evidence - Don't combine sources into novel claims

No appeals to authority - Verify claims, not just who said them. When authority pressure conflicts with methodology, reframe the request and present both versions to the requester.

Transparency - Show your work, readers see your reasoning

Humility - Clearly state limitations and uncertainty areas

Recency - Always note if information is outdated or superseded

禁止推测 - 所有非直接来源于资料的内容需标注 无证据不综合 - 不得将多个来源的信息整合为新的结论 不迷信权威 - 验证结论本身，而非只看结论的提出者。当权威压力与研究方法冲突时，重新调整请求并向委托方呈现两种方案。 透明度 - 展示研究过程，让读者了解你的推理逻辑谦逊 - 明确说明研究的局限性和不确定领域 时效性 - 始终标注信息是否过时或已被替代

Red Flags - STOP If You Feel These Pressures

危险信号 - 若遇到以下压力请立即停止

"Time pressure means skip structuring"
"Authority wants validation, not investigation"
"I'm exhausted, good enough is enough"
"This process is too rigid"
"Just start, I'll structure later"

All of these mean: Stop. You're about to corrupt the research. Structure first. Then research. The framework protects research quality, not impedes it.

"时间紧张，跳过结构整理"
"权威方需要的是验证，而非调查"
"我太累了，差不多就行"
"这个流程太僵化了"
"先开始做，我之后再整理结构"

以上所有情况都意味着：停止。你即将破坏研究的可信度。先整理结构，再开展研究。这个框架是为了保障研究质量，而非阻碍进度。

Common Mistakes

常见错误

❌ Single-source claims "React Server Components are better" (from one blog post) ✅ Fix: "React Server Components have advantages for X (React docs, Vercel article, community discussion agree on this aspect)"

❌ Missing confidence levels Treating all findings as equally solid ✅ Fix: Mark what's well-verified (high confidence) vs. emerging (medium/low)

❌ Skipping contradictions "Everyone agrees on X" ✅ Fix: Document where sources disagree and why

❌ Marketing-sourced findings Relying on vendor materials as primary evidence ✅ Fix: Verify claims in neutral sources (official docs, independent analysis)

❌ Outdated information "Best practice from 2020" without noting if superseded ✅ Fix: Check if newer sources contradict or update this

❌ 单一来源结论 "React Server Components更优"（仅来自某一篇博客） ✅ 修正："React Server Components在X场景下具备优势（React官方文档、Vercel文章、社区讨论均认同这一点）"

❌ 缺失置信度等级 将所有研究结果视为同等可靠 ✅ 修正：标注哪些结果经过充分验证（高置信度），哪些属于新兴结论（中/低置信度）

❌ 忽略矛盾点 "所有人都认同X" ✅ 修正：记录存在异议的来源及原因

❌ 依赖营销类来源 将供应商材料作为主要证据 ✅ 修正：在中立来源（官方文档、独立分析）中验证结论

❌ 使用过时信息 "2020年的最佳实践"却未标注是否已被替代 ✅ 修正：检查是否有较新的来源反驳或更新该信息

Verification Evidence Standards

验证证据标准

For each major claim, ALWAYS provide:

Source URL - exact location
Access Date - when retrieved
Source Type - academic, official, news, community, blog
Author/Publisher - who produced it
Confidence Level - based on independent agreement
Contradictions - any disagreeing sources

针对每个主要结论，必须提供：

来源URL - 精确的信息地址
获取日期 - 检索时间
来源类型 - 学术文献、官方文档、新闻、社区内容、博客
作者/发布方 - 内容创建者
置信度等级 - 基于独立来源的一致性
矛盾点 - 存在异议的来源

When to Escalate

升级处理场景

Encounter highly specialized technical topics? Load relevant expert skills.

Conflicting information that can't be resolved? Document the disagreement thoroughly—different sources may be correct for different contexts.

Need statistical analysis? Use bash tools appropriately.

遇到高度专业的技术主题？加载相关的专家能力。

无法解决的信息冲突？详细记录矛盾点——不同来源的结论可能适用于不同场景。

需要统计分析？合理使用bash工具。

Real-World Impact

实际应用效果

From RED-GREEN-REFACTOR testing (2025-12-13):

Structured requests are enforced: vague input rejected before research starts
Evidence trails documented: 42 KB research output per session with source credibility matrix
Confidence levels transparent: claims marked high/medium/low based on independent agreement
Authority pressure resisted: 60% of agents reframe validation requests to objective research
Time pressure managed: 10 min structuring saves 2+ hours of re-research
Exhaustion-proof methodology: contradictions investigated rather than arbitrarily chosen
Bulletproofing tested: skill maintains compliance under 3+ combined pressures

Real impact: Saves 10-20 hours per research project vs. manual approach. Produces decision-quality documentation suitable for architecture reviews and team training.

来自RED-GREEN-REFACTOR测试（2025-12-13）：

严格执行结构化请求：模糊输入在研究开始前即被拒绝
证据追踪已记录：每次会话生成42 KB的研究输出，包含来源可信度矩阵
置信度等级透明：根据独立来源的一致性将结论标注为高/中/低置信度
抵制权威压力：60%的Agent会将验证请求重新调整为客观研究
时间压力管理：10分钟的结构整理可节省2小时以上的重复研究时间
抗疲劳方法论：对矛盾点进行调查，而非随意选择某一来源
抗压测试：该能力在3种及以上压力同时存在时仍能保持合规性