deep-researcher

深度研究者

概述

深度研究就是通过证据链进行系统的信息核实。

深度研究者这一超能力，可将模糊的研究请求转化为结构化调查，并明确标注置信度。不是“我找到了 X”，而是“X 已由 3 个独立来源核实，访问日期为 [dates]，置信度：高”。

核心原则：未经核实的研究只是信息收集。没有证据的核实只是一种信念。

适用场景

在以下情况下使用深度研究者：

• 已核实的发现——论断有 3 个或更多独立来源支持
• 证据链——准确的 URL、访问日期、来源可信度评估
• 置信度——了解哪些发现可靠，哪些只是推测
• 多源综合分析——总结多个权威来源间的规律，而非依赖单一来源的论断
• 技术研究——架构决策、实现模式、最佳实践
• 事实核查——找出并解释相互矛盾的来源
• 供日后参考——结构化输出，方便日后重读和引用

以下情况不要使用：

• 需要实时数据（股票价格、当前天气、今天的事件）
• 单一权威来源已足够（官方文档、RFC 规范）
• 请求缺少主题或存储位置，内容模糊
• 研究仅针对特定项目（改为创建 CLAUDE.md）

请求结构（必需）

深度研究者需要以下三项：

1. 主题（必需）——明确的研究问题

   • “比较现代 Web 框架中的身份验证策略”
   • “调查不同数据库索引方法对性能的影响”
   • “研究处理 TypeScript 错误类型的当前最佳实践”

2. 存储前缀（必需）——输出文件的存放位置

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

3. 需要避开的内容（可选）——要排除的主题或来源

   • “避开需要付费才能阅读的学术论文”
   • “跳过营销材料，专注于技术文档”
   • “排除超过 2 年的博客文章”

**拒绝协议：**缺少主题或存储前缀？研究者会拒绝请求。**你也必须拒绝模糊的请求。**如果无法从请求中提取明确的主题、存储前缀和避开项列表，就拒绝委派。明确说明需要哪些信息才能继续。模糊的输入会导致模糊的输出——拒绝请求可以保护你和研究者。

**在压力下想跳过这一步？**时间压力、权威压力、紧迫感——这些都不能改变这一要求。花 10 分钟整理，可以省下 2 小时以上的重复研究。

研究方法

阶段 1：界定主题并制定计划

将研究问题拆解为具体的子问题。确定一手来源与二手来源。在开始搜索前制定核实策略。

**关键：**如果请求带有隐含偏见（例如“证明这是正确的”），就要客观地重新表述。旨在验证既有决策的研究，从一开始就已受到影响。权威压力不会改变这一点——重新表述，并向请求者呈现两种说法。

示例：“比较身份验证策略”可拆解为：

• 有哪些策略？（一手来源：官方文档）
• 各自的优缺点是什么？（二手来源：技术分析）
• 哪种扩展性最好？（二手来源：社区讨论、基准测试）
• 当前行业共识是什么？（二手来源：近期文章、GitHub 上的模式）

**重新表述时：**主管说“证明我们的选择是正确的”→ 你提议“客观比较我们的选择与其他方案”→ 结果要么验证这一选择（更有力的佐证），要么及早发现问题（同样有价值）。

阶段 2：收集和抓取来源

• **一手来源：**官方文档、RFC、原创研究、API 参考资料
• **二手来源：**技术分析、博客文章、代码示例、社区讨论
• **目标：**每项论断至少有 3～5 个独立的权威来源
• **记录：**URL、访问日期、来源类型、作者/发布方

第 3 阶段：信息整理

按主题整理发现。记录一致与不一致之处。找出模式、异常情况和矛盾。

第 4 阶段：验证与事实核查

针对每项主要主张：

要素	内容
来源 URL	信息的确切位置
访问日期	检索时间
来源类型	学术、官方文档、新闻、社区、博客
作者／发布方	内容的创作者
置信度	高（3 个以上独立来源一致）、中（2 个来源）、低（单一来源）
矛盾	是否有来源意见不一

处理矛盾： 来源意见不一时，调查原因。投入 1–2 小时了解其背景依赖性。如果 1–2 小时后仍无法解决，就以中／低置信度记录矛盾，而不是随意选择一个来源。矛盾本身也是信息——它们说明该主题取决于具体情境。

疲惫不堪、难以坚持？ 这项技能无法消除疲劳，但能让懒得挑选来源的做法变得难以接受。说明你为何选择某个来源而非其他来源，或花时间弄清分歧所在。不要假装说“它们各有优点”就是研究。

第 5 阶段：结构化输出

研究结果写入提供的目录：

<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

输出格式

thinking.md

记录研究过程、作出的决定、探索过的岔路、假设和局限。

research.md

按关键主题或问题整理发现。引用原文并注明来源。记录发布日期，以及支持和反驳的证据。

verification.md

来源可信度矩阵。针对每项主张的验证方法。交叉引用模式。置信度等级。缺口或无法验证的主张。附带访问日期的 URL。

insights.md

综合各来源中的模式。新兴共识与少数观点。出乎意料的发现。需要进一步研究的领域。

summary.md

用 1–2 段撰写执行摘要。列出带有置信度等级的关键发现。说明主要局限或注意事项。提出建议。

核心标准

不做推测——标记任何缺乏直接来源支持的内容

综合结论必须有证据——不要将多个来源拼合成未经证实的新主张

不诉诸权威——验证主张，而不只是确认主张出自谁之口。当权威压力与方法论冲突时，重新界定请求，并向请求者同时呈现两种版本。

透明——展示研究过程，让读者看到你的推理

保持谦逊——明确说明局限和不确定之处

关注时效性——始终注明信息是否已过时或被取代

危险信号——感受到以下压力时就停止

• “时间紧迫，所以跳过结构化流程”
• “权威人士要的是肯定，不是调查”
• “我累了，差不多就行”
• “这个流程太死板了”
• “先开始吧，之后我再整理”

这些都意味着：停下。你即将损害研究质量。先搭建结构，再开展研究。这个框架是为了保障研究质量，而不是妨碍研究。

常见错误

❌ 仅凭单一来源得出主张 “React Server Components 更好”（依据一篇博客文章） ✅ 修正：“React Server Components 在 X 方面有优势（React 文档、Vercel 文章和社区讨论都认同这一点）”

❌ 缺少置信度等级 把所有发现都当作同样可靠 ✅ 修正：标明哪些已得到充分验证（高置信度），哪些仍处于探索阶段（中／低置信度）

❌ 跳过矛盾 “大家都认同 X” ✅ 修正：记录来源意见不一之处及原因

❌ 依据营销材料得出发现 将供应商材料作为主要证据 ✅ 修正：通过中立来源（官方文档、独立分析）验证主张

❌ 信息过时 引用“2020 年的最佳实践”，却不说明它是否已被取代 ✅ 修正：检查较新的来源是否与之矛盾或对其作出更新

验证证据标准

对于每项重大主张，始终提供：

1. 来源 URL - exact location
2. 访问日期 - 检索时间
3. 来源类型 - 学术、官方、新闻、社区、博客
4. 作者/发布者 - 内容的创作者
5. 置信度 - 基于独立观点的一致程度
6. 矛盾之处 - 存在分歧的来源

何时升级处理

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

遇到无法解决的冲突信息？详细记录分歧——不同来源可能适用于不同情境。

需要统计分析？适当使用 bash 工具。

现实影响

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

• 结构化请求得到强制执行：研究开始前会拒绝含糊的输入
• 证据链得到记录：每次会话可生成 42 KB 研究输出，并附带来源可信度矩阵
• 置信度清晰透明：根据独立观点的一致程度，将主张标记为高/中/低
• 抵御权威压力：60% 的 Agent 会将验证请求重新表述为客观研究
• 妥善应对时间压力：花 10 分钟梳理结构，可节省 2+ 小时的重复研究
• 经得起疲惫考验的方法：调查矛盾，而非随意选边
• 防护能力经测试：即使面临 3+ 种压力叠加，技能仍能保持合规

实际影响：与手动方式相比，每个研究项目可节省 10–20 小时。生成的文档达到决策所需的质量，可用于架构评审和团队培训。