deep-research

深度研究

概述

跨多个来源研究一个主题，并在对话中给出有引用、结构清晰的综合结论。视角的广度、交叉引用的深度，以及严谨的引用规范，是它区别于搜索摘要的关键。请在聊天中输出结果——只有在用户要求时才写入文件。

五种搜索角度

每次至少覆盖 3 种；在计划中列出它们，并为每次搜索标注角度。

角度	查找内容
官方	一手文档、规范、厂商来源、同行评审论文
比较	“X vs Y”、替代方案、正面对比分析
批评	局限性、已知问题、失败案例
时效性	最新进展、更新日志、趋势文章（在查询中包含年份）
社区	HN、Reddit、博客、Stack Overflow——提供线索，而非权威

模式

模式	触发条件	搜索数量	输出
quick	“快速了解 X”、低风险问题	3-5	一段话 + 3-5 个来源；采用更宽松的门槛
默认	常规的单领域主题	5-10+	完整综合模板
comparison	“比较 X 和 Y”、“优缺点”	10-15	报告开头必须提供对比矩阵
landscape	“调查 X 的整体格局”、宽泛领域	10+	并行子 Agent → 达成共识（PLAYBOOK）

对于带有观点倾向的问题（如“我该用 X 吗？”），如果你已有依据充分的判断，应先直接回答，再提出是否要深入研究。用户想要明确意见时，进行 10 次搜索是在浪费用户的时间。

工作流——每一步都是进入下一步的门槛

1. 本地优先——先运行 rg "<topic>" .，阅读明显匹配的内容，再进行任何网络搜索。如果本地材料已经涵盖该主题，默认选择 UPDATE，而不是 CREATE。说明你找到了什么；即使结果是“本地没有匹配项”也可以。
2. 计划——发布你对问题的理解、要采用的角度和模式，然后开始搜索。第 5 步会根据已发布的计划进行衡量。
3. 消除歧义（需要时）——对于有歧义的专有名词和缩写，先进行一次广泛搜索以确认所指对象，并说明结果。如果仍不明确，就询问用户。如果查询围绕的是一个你熟悉、但变化很快的领域中的名称——例如 AI 模型、开发者工具，或任何数月内就会变化的事物——那么名称本身就是需要核实的对象：先搜索再回答，并至少在一个查询中使用用户写下的名称。局部背景知识恰恰会让过时的答案听起来权威，因此，熟悉并不是跳过搜索的理由。
4. 搜索——至少搜索 5 次。由广到细，再查找争议（“X 批评”、“X 与替代方案对比”），最后查时效性。对所有会在回答中实质引用的来源，都要使用 WebFetch 阅读——搜索结果摘要不算读过。优先选择一手来源，其次是二手来源，再次是三手来源。如果两个来源互相矛盾，应在报告中保留这种分歧，不要默默选取其中一方。
5. 充分性门槛——发布一行：searches: N | angles: <list> | full reads: M | gaps: <list>。如果某个计划章节没有资料支撑，就继续搜索或删去该章节——不要凑内容。
6. 综合——使用下方模板；根据主题调整章节名称。将最后一轮发现与第 2 步的计划进行对照；如果两者冲突，应修订 Tl;dr，而不是把冲突藏在后面的章节中。
7. 核验引用——每个引用的 URL 都必须对应本轮实际抓取的页面。逐条核对每个重要论断的来源，然后重述用户最初的问题，并删去与问题无关的章节。

综合模板

# [Topic] — Research Summary
> Interpreted as: [if ambiguity was present]

## Tl;dr
[2-3 sentences answering the original question.] *Confidence: high/med/low — why.*

## Overview / Core Information
Definition, how it works, key concepts. *Confidence: ...*

## Comparison Matrix  [REQUIRED when comparing 3+ items, place right after Tl;dr]
| Item | Dimension 1 | Dimension 2 | Notes |
|------|-------------|-------------|-------|

## Trade-offs and Criticism
Limitations, valid criticisms, when not to use this. *Confidence: ...*

## Current Landscape
Recent developments, adoption signal, direction. Note disagreements. *Confidence: ...*

## What we still don't know  [when gaps are non-trivial]
- Open question

## Sources  [group under sub-headers when >5]
- [Title (YYYY-MM-DD)](url) — what this contributed

**来源规则：**对于实质性主题，使用 8-15 个以上来源；每项论断都必须可追溯；注明每个来源的贡献；包含发布日期；兼顾官方、行业和社区来源。

**篇幅：**根据问题调整报告长度——默认模式下的报告大约为一屏正文，另加来源列表。对于来源无法支撑的模板章节，应删去而非凑内容；与其臆测，不如提出可以扩展某个章节。

示例

✅ 良好（quick 模式，简略版——步骤编号与上方工作流一致）：

user: quick read on whether Bun is stable enough for a CLI tool
assistant:
[1] No local material. [2] Mode: quick. Angles: Official, Criticism, Currency.
[5] searches: 4 | angles: 3 | full reads: 3 | gaps: Windows support thin

Bun 1.x is stable for single-binary CLIs on macOS and Linux; Windows still
trails on a few Node APIs, so check your dependency list against the compat
table. *Confidence: med — official compat table + two 2026 issue threads; no
Windows production reports found.*
Sources: [bun.sh compat table (2026-06)](url) — API coverage · [GitHub issue (2026-05)](url) — Windows gaps · [HN thread (2026-04)](url) — field reports

❌ 不佳： 搜索一次“htmx”→“它是一个轻量级 JS 库，可替代 React，有些人喜欢用。来源：htmx.org”——没有本地核查、没有计划、没有交叉引用、没有置信度标签，且只有一个来源。

✅ 良好（妥善处理分歧）：“来源 A（官方文档，2026 年）称该标志默认开启；来源 B（广受引用的博客，2024 年）称默认关闭。默认值在 v3 中发生了变化——B 的发布时间更早。”两者都注明了出处，日期解释了分歧。

完整的默认模式（htmx）和对比模式演练：references/EXAMPLES.md。

注意事项

• 编造引文是最常见的失败模式。 只有在本次运行中实际获取过 URL，才能引用它。如果获取失败，请寻找可访问的同类来源，或删去相关说法——绝不要拼凑出看似合理的 URL。
• WebFetch 在付费墙页面和 JavaScript 渲染页面上会返回模板内容或空内容。 这算作未读取。请如实说明，或搜索可访问的镜像；不要用搜索摘要补充内容并将其计入 full reads。
• 排名靠前不代表权威。 在大多数技术查询中，SEO 内容农场和 AI 撰写的摘要排名都高于一手文档。技术说法应优先引用官方文档、.gov/.edu 网站和同行评审来源，并以页面本身标注的发布日期为准——搜索结果日期往往是重新索引的日期。
• 反驳不是证据。 用户质疑有来源支持的说法时，应再次搜索，而不是直接改口。报告新来源的说法，包括“它们仍然支持原来的说法”。
• 多 Agent 全面调研最容易偏离方向。 每个子 Agent 都会优化自己的角度，因此第 6 步的共识审查才是重新审视原始问题的环节——而不是收尾。
• 即使在 quick 模式下，比较三个或更多项目仍需使用矩阵。 用散文比较 3 个以上选项难以阅读；五行矩阵占用的篇幅比它替代的段落更少。
• 查询中陈旧的年份会在不知不觉中影响时效性。 涉及时效性的查询应使用当前年份——不带日期的结果往往会偏向数年前的信息。
• 摘要会复述来源原文却不加标注。 如果句子沿用了来源的措辞，请加引号并注明出处；否则请用自己的间接表述改写。每个来源只标注一处简短引文即可——references/EXAMPLES.md 中的完整示例展示了这一做法。

集成

• track-session——对于长期研究项目，将计划和来源列表保存到 SESSION_PROGRESS.md，以便运行可恢复。
• track-roadmap——研究为路线图决策提供依据；请在条目中引用摘要。
• 研究为决策提供依据，但不会替人做决定。阅读代码库是第 1 步；用户偏好通过 AskUserQuestion 获取，设计决策则由用户做出。

多 Agent 全面调研模式、另存为笔记的交接方式及故障排除：references/PLAYBOOK.md。