research

research

深入调查某个主题：从多个独立来源收集信息、核实说法、区分事实与观点，并提供带日期的引用。规范你应如何开展研究和撰写报告的标准见 references/methodology.md——开始前先阅读，并让每个子 Agent 都参考这份文件，确保所有工作采用相同的格式。

此技能有两种深度。先选择深度，再按对应工作流执行。

选择深度

用户说“deep research”“deep dive”“go deep”“thorough/exhaustive research”，或传入 --deep 时，使用深度模式。深度模式会并行调用多个子 Agent，并始终同时生成一份已保存的 Markdown 报告和一个交互式 HTML 页面。

其他情况使用标准模式——在聊天中完成一次有针对性的调查并作答。对于“research X”“look into Y”“what's the latest on Z”，默认使用标准模式。

如果主题显然范围很大（例如“研究分布式数据库的完整历史”），但用户没有说“deep”，则使用标准模式，并说明深度模式也可选：“这个主题范围较广——我先做了一次有针对性的调查；如果你想要完整的多 Agent 调研和交互式页面，请说‘deep research’。”不要擅自升级；并行调用开销较大，用户应主动选择。

---

标准工作流

1. 明确范围。 用一句话重述你要回答的问题。如果请求确实有歧义（可能指两种不同的意思），就简短地问一个澄清问题；否则直接开始，不要在简单的研究任务前盘问用户。
2. 调查。 按照 references/methodology.md 开展有针对性的搜索：优先查看官方文档，对重要说法交叉核对多个独立来源，在时效性重要时优先选择近期来源，并主动寻找相反证据。
3. 在聊天中报告。 按照 references/methodology.md 中的结构，直接在对话中撰写带引用的报告（执行摘要 → 有证据和可信度说明的调查结果 → 矛盾或不确定之处 → 结论 → 来源）。内容应简明，先给出答案。
4. 提供后续选项。 最后单独一行写：“要将这份报告保存为 Markdown 文件，还是制作成交互式页面？也可以说‘deep research’，并行调查各个子主题。”在标准模式下，除非用户提出要求，否则不要保存文件或制作页面——聊天中的报告就是交付内容。

---

深度工作流

共四个阶段。先梳理领域（阶段 1），再深入调查（阶段 2），这正是它优于单纯增加搜索次数的地方——把并行资源投入已确认真实且各不相同的分支，而不是盲目地分头搜索。

阶段 1——初步摸底

先自行广泛调查一轮：搜索到足以了解主题的大致范围，并找到有实质内容的信息所在。此阶段的目标不是得出任何结论，而是将主题拆解为 4–8 个互不重叠的不同子问题（“分支”），共同覆盖整个主题。好的分支应能独立调查，且彼此不重复（例如，对于“CDC 中的逻辑复制与 Debezium 对比”：运维开销、规模扩大时的吞吐量和延迟、模式变更处理、故障模式与恢复、生态系统和工具成熟度、成本）。

并行调查前，向用户列出分支并征求确认：

我将并行调查以下分支：

1. ...
2. ...

**下一步：**继续，还是先调整分支？

只有在用户已经说“just go” / “don't ask” / “deep research X and build the page”时才跳过等待。否则先等用户回复——此时重新确定范围成本很低；让五个 Agent 重新调查则不然。

阶段 2 — 并行分发

为每个分支启动 一个子 Agent，最多 5 个（如果侦察阶段发现的分支超过 5 个，先合并最接近的分支）。如果你的执行环境允许，就并行启动它们——在 Claude Code 中，可在一条消息里发起多个 Agent 调用。如果不允许，就按顺序运行；研究质量不变，只是耗时更长。

每个子 Agent 都需要使用网页搜索和网页抓取功能（在 Claude Code 中，使用 subagent_type: general-purpose）。每个 Agent 的提示词必须包含：

• 分支问题和一句话的范围界定（“只涉及 X；Y 由另一个 Agent 负责”）。
• 以下指令，并填入实际路径： “阅读此技能目录中的 references/methodology.md，并遵循其中的来源质量、核验和引用标准。按照该文件定义的报告结构，返回一份分支简报。” 发送前，替换为实际的绝对路径——子 Agent 无法解析相对于它未收到的技能的路径。
• 整体研究问题作为背景，确保分支研究与用户的实际目标相关。
• 返回内容： 将简报作为最终消息返回，其中包含引用的发现、置信度等级，以及对任何无法核验事项的明确说明。告诉它不要实现任何内容或编辑文件；它只负责研究和报告。

子 Agent 会将报告返回给你；系统不会自动向用户显示，因此你需要整理并保留重要内容。

阶段 3 — 综合

将各分支报告整合为一份连贯的调查报告——不要只是简单拼接：

• 交叉比对并去重多个分支共同发现的内容；合并为一项，并保留最有力的来源。
• 按照 references/methodology.md 中的冲突格式解决或标记分歧——两个分支意见不一致本身就是一项发现，不应隐瞒。
• 为每项发现评定整体置信度，并指出整项调查仍无法确定的事项。
• 使用完整的报告结构，将主报告 Write 到 ./research-<topic-slug>.md。此文件是持久化成果，也是页面的内容来源。

阶段 4 — 交接给 rich-page

通过 Skill 工具调用 rich-page 技能，并将保存的报告作为来源传入：

Build a rich visual HTML page from this research report: ./research-<topic-slug>.md
Audience: <whoever the user mentioned, else "the user / their team">. Language: <match the report>.
Output path: ./research-<topic-slug>.html
Just build it — don't ask for confirmation on the visual plan.

rich-page 接受研究资料包作为来源——其阶段 1 会从头到尾读取 Markdown 报告，并识别“适合可视化的内容”（定量结论用图表、“X 与 Y”分支用对比切换控件、提及架构时用节点图等）。告诉它“直接构建”，即可跳过阶段 2 的确认环节，让深度研究流程以交付成果收尾，而不是再多一道审批。完成后，用一条简短消息向用户提供两个路径——Markdown 报告和 HTML 页面，并说明用户可以要求重新研究任何分支，或重新设计页面样式。

---

由你研究；由人决定

报告完成后，停下来，让用户采取行动。 研究的目的是为人的决策提供信息——决定构建什么、选择哪个方案，或判断某项说法是否站得住脚。如果你从“以下是我的发现”直接跳到修改代码、配置或依赖，就抹去了研究原本要创造的决策环节，而且依据的还是用户尚未读过的发现。

因此，在呈现研究发现（标准模式）或交付成果（深度模式）之后：不要实现、重构、重新配置，也不要“直接应用最佳实践”。回答用户关于来源和分析的后续问题，然后等待用户告诉你接下来怎么做。唯一的例外是在深度模式中交接给 rich-page——这是研究交付成果的一部分，并非采取后续行动。

---

参考文件

• references/methodology.md — 来源质量层级、核验实践、引用格式、警示信号和报告结构。开始研究前请先阅读；使用深度模式时，确保每个子 Agent 都能访问该文件。

---

最初改编自 mattpocock/skills，MIT © 2026 Matt Pocock。复制此文件时请保留此行。