研究综述技能

多源检索 → 去重 → 综合归纳 → 规范引用。答案须简洁，严格控制在约 400 字以内。

适用场景

触发短语：

• “research [主题]”

• “find out about [主题]”

• “what do you know about [主题]”

• “synthesize [主题]”

• “look up [主题]”

分步执行流程

步骤 0：明确任务简报

在开展任何关于公司、产品或竞品的研究前——务必先提问或核实：

1. 我方产品的定位是什么？ 切勿假设；若不明确，必须主动确认。
2. 研究范围是什么？ 是竞品分析？市场容量测算？还是两者兼顾？
3. 输出成果将用于什么场景？ 融资路演（pitch deck）？内部文档？战略规划？

此举可避免产出错误文档而被迫返工重写。

步骤 0b：问题拆解（GPT 研究者模式）

正式检索前，需将原始问题拆解为若干具体子问题：

输入：“What is Paperclip and how does it compare to monday.com?”

子问题：
1. Paperclip 是什么？它的核心功能是什么？
2. 由谁开发？何时发布？
3. 其核心功能有哪些？
4. 在项目管理工具赛道中，其市场定位如何？
5. monday.com 具备而 Paperclip 不具备的功能有哪些？反之亦然？

规则： 对于宽泛或多维度的问题（如竞品分析、“解释 X”、“对比 A 和 B”），必须首先执行拆解；对于简单事实类问题（如“X 的创始人是谁？”、“Y 发生于何时？”），可跳过此步。

每个子问题均应作为独立搜索词提交。相比对同一问题使用 5 种不同措辞，该方法能获得更深入、更少偏见的结果。

步骤 1：问题分类

检索前需判断：

• 语言： 问题是否为希伯来语？→ 需同时以希伯来语和英语检索
• 类型： 属于事实性问题？观点/趋势类？技术细节类？近期事件类？
• 范围： 是窄口径（单一事实）还是宽口径（主题概览）？

据此调整搜索词表达方式。

步骤 2：生成多样化搜索词

构建 3–5 个语义各异的搜索词变体，以提升覆盖广度并降低偏差：

示例 — 问题：“What is LangGraph?”

• Q1: “What is LangGraph and how does it work”
• Q2: “LangGraph framework overview”
• Q3: “LangGraph tutorial explained”
• Q4: （跳过 — 英文主题）
• Q5: “LangGraph 2024 use cases”

示例 — 问题：“What is LangGraph?”

• Q1: “What is LangGraph and how does it work”
• Q2: “LangGraph framework overview”
• Q3: “LangGraph explained simply”
• Q4: “LangGraph explained”（若该主题存在非英语资料）
• Q5: “LangGraph 2025 latest”

步骤 2b：公司信息核实 — 必须优先访问官网

所有竞品/公司研究的强制要求：

在撰写任何关于某公司的内容前，必须完成以下操作：

1. 使用 web_fetch 获取其主站 URL（含首页及关键子页：/agents、/product、/pricing）
2. 使用 web_search 检索 “[公司名] funding 2026” 和 “[公司名] review 2026”
3. 仅陈述实际查证到的信息；未验证内容须标注为“unverified”

切勿依据公司所属类别名称推断其能力。
例如：“issue tracker” 并不意味着“不支持 agents”，必须实证确认。

步骤 3：并行执行检索

使用 web_search 同时运行全部搜索词变体，收集以下字段：

• 标题
• URL
• 摘要片段（snippet）

除非摘要片段信息严重不足，否则不得调用 web_fetch 获取全文。

步骤 4：去重、筛选与信源评分

对全部检索结果执行以下处理：

1. 剔除重复 URL
2. 剔除与问题无关的结果
3. 对快速演进领域（AI、科技、新闻等），剔除超过 2 年的内容
4. 评估信源可信度：
   • 高可信度： 官方文档、同行评审论文、主流媒体（TechCrunch、Wired、HBR）
   • 中可信度： 知名技术博客、GitHub 仓库、权威通讯简报
   • 低可信度： 论坛帖、匿名发帖、营销落地页
5. 优先采用高可信度信源；若仅有低可信度信源，则需明确标注。

目标信源数量：深度研究取 5–10 个，快速问答取 3–5 个。

步骤 5：综合归纳

按如下格式撰写答案：

[3–5 句直击问题核心的总结句]

Key points:
• [要点 1]
• [要点 2]
• [要点 3]
• [要点 4 — 可选]

Sources:
1. [标题] — [URL]
2. [标题] — [URL]
3. [标题] — [URL]

归纳规则：

• 首句即给出直接答案，不铺垫背景
• 使用用户提问语言作答（希伯来语提问 → 希伯来语作答）
• 全文严格控制在约 400 字以内
• 若信源结论冲突 → 简要注明分歧点
• 若信息已过时 → 明确标注

步骤 6：交付成果

仅发送归纳后的最终答案。严禁：

• 堆砌原始搜索结果
• 罗列全部发现的信源
• 添加无意义话术，如“好问题！”或“我已全网检索……”
• 加入冗余免责声明

输出格式模板

🔍 [主题]

[3–5 句直击核心的答案]

📌 Key Points:
• ...
• ...
• ...

📚 Sources:
1. [标题] — [URL]
2. [标题] — [URL]
3. [标题] — [URL]

示例

输入： “Research: What is Model Context Protocol?”

输出：

🔍 Model Context Protocol (MCP)

Model Context Protocol (MCP) 是 Anthropic 推出的开放标准，旨在使 LLM 能够统一接入各类工具、API 及外部数据源。相比为每个集成单独编写定制代码，MCP 定义了模型与工具服务器之间通用的交互语言。

📌 Key Points:
• 客户端-服务器协议：LLM 为客户端，工具为服务器
• 支持 stdio 和 HTTP 两种传输方式
• 支持能力包括：工具调用、资源访问、提示工程（prompts）
• 已被广泛采用：Claude、Cursor、VS Code 等
• 开源项目，提供 Python、TypeScript、Java SDK

📚 Sources:
1. MCP 官方文档 — https://modelcontextprotocol.io
2. Anthropic 关于 MCP 的公告 — https://www.anthropic.com/news/model-context-protocol
3. MCP GitHub 仓库 — https://github.com/modelcontextprotocol

希伯来语检索策略

针对希伯来语提问，必须同步进行双语检索：

若主题本身具有以色列属性（如本地新闻、以色列法律等），则应加重希伯来语信源权重。

核心规则

1. 必须规范引用信源 —— 任何回答至少需附 2 个 URL；竞品分析类须不少于 5 个信源。
2. 撰写前务必明确我方产品定位（步骤 0）—— 尤其适用于竞品分析，须先确认我方产品能力再开展对比。
3. 公司信息必须源自其官网验证（步骤 2b）—— 绝不可依赖类别名称做推断。
4. 复杂问题必须先行拆解（步骤 0b）；简单事实类问题可跳过拆解。
5. 全文上限约 400 字 —— 追求精炼，而非穷尽所有细节
6. 一次性交付终稿 —— 不提供多个草稿版本，确保首次输出即准确可用
7. 首句即直接作答 —— 禁止前言、禁止“我将开始检索……”等说明性文字
8. 希伯来语输入 → 希伯来语输出 —— 严格匹配用户语言
9. 明确标注不确定性 —— 若信源冲突或数据陈旧，须如实指出
10. 禁止原始信息堆砌 —— 必须综合归纳，不得复制粘贴摘要片段
11. 收到研究请求时回复 👍，交付完成时回复 ✅
12. 研究交付后，若主题重要，须将摘要写入 memory/whatsapp/dms//context.md

成本说明

• 每次研究请求调用 3–5 次 web_search —— 成本适中
• 除非摘要片段确实无法满足需求，否则避免调用 web_fetch
• 对于简单事实类问题（首都城市、日期等）→ 单次检索即可，无需启动完整综述流程
• 缓存机制：若相同主题在一小时内已被检索过，则复用已有结果