research

Research

面向“不够了解，需要先查清楚再决策”的场景。目标不是堆资料，而是把不同来源的证据、分歧、可信度和可执行建议收拢到一份可判断的结论里。

硬约束

• 先界定问题，再搜索；不要把第一个搜索词当成最终研究问题。
• 默认只读：不注册账号、不提交表单、不触发付费动作、不抓取受登录墙或授权限制保护的内容。
• 涉及法律、医疗、金融、安全、合规、价格、政策、版本、公司/人物现状等高变化或高风险事实时，必须使用最新可访问来源，并在结论中写明日期。
• 开放网络内容必须交叉验证。没有两个独立来源支撑的事实，只能标为“单一来源”或“待确认”。
• 不把社区观点当成事实；社区内容用于发现问题、经验和争议，结论仍要回到官方文档、源码、论文、公告、标准或一手数据。
• 输出必须能让用户做下一步决定：给结论、依据、残余风险、推荐动作和需要继续验证的点。

启动检查

1. 复述研究问题，并补齐：
   • 用户要做的决策是什么。
   • 时间范围和地域范围。
   • 需要比较的候选方案。
   • 成功标准、成本约束和不可接受风险。
2. 检查可用工具：
   • 若官方 exa 插件可用，用于高召回搜索、论文、公司/人物/竞品资料。
   • 若官方 firecrawl 插件可用，用于抓取单页、站点 crawl、把网页转为干净 Markdown。
   • 若官方 youdotcom-agent-skills 插件可用，用于带引用的 web research、搜索和内容抽取。
   • 若 voidtech-mcp-common 已启用，使用 Context7 查询库/框架官方文档；使用 Chrome DevTools 验证需要真实页面行为的主张。
3. 如果缺少开放网络工具，仍可继续做“离线研究计划”：基于本地代码、用户提供材料和已知事实输出查询清单、来源优先级和验证步骤，但不要伪造最新结论。

调研分工

优先使用子 agent / Task 工具并行执行；可指定模型时，资料收集 agent 使用 haiku（按量最省、够用），主 agent 保持当前模型做综合判断——不要为资料收集指定更强的模型，这一步的瓶颈是覆盖面而不是推理深度。若当前环境不能委派子 agent，则按相同分工顺序执行并标注为“顺序调研”。

按问题选择 3-5 条资料线（source lane），每条资料线都要给出来源、发现和可信度：

Lane	适用来源	关注点
官方与一手资料	官方文档、发布说明、标准、监管公告、源码、论文、API reference	当前事实、约束、版本、许可证、使用限制
实现与维护信号	GitHub/GitLab issue、PR、commit、release、CI、包仓库	活跃度、破坏性变更、真实 bug、维护风险
社区经验	论坛、Reddit、Stack Overflow、博客、HN、Discord 摘要	常见坑、迁移成本、非官方 workaround
竞品与替代方案	替代库/产品、benchmark、案例、定价页	取舍、迁移路径、锁定风险
本项目适配	当前代码库、团队约束、现有 skill/MCP、CI、部署环境	落地成本、边界、需要补的验证

执行步骤

1. 写出 3-7 个搜索查询，覆盖中文、英文、官方名称、常见别名和反向关键词（如 problem、limitations、migration、pricing、security）。
2. 为每条 lane 分派任务：
   • 要求 agent 返回 5-10 条高价值来源，而不是长篇摘抄。
   • 每条来源包含标题、URL、发布日期或更新时间、来源类型、关键发现、可信度和原文可核验位置。
   • 明确要求标出“不确定/相互矛盾/过时”的信息。
3. 汇总时去重并建立证据表：
   • 事实：多个可信来源一致。
   • 强信号：一手来源或大量实现证据支撑。
   • 弱信号：社区经验、单一博客、未复现 issue。
   • 冲突：来源间结论不一致，说明可能原因。
4. 对用户的决策问题给出建议：
   • 首选方案和理由。
   • 不推荐方案和触发条件。
   • 最小验证实验。
   • 需要用户或团队人工确认的事项。

输出格式

## 结论

一句话回答用户应该怎么做；如果证据不足，直接说证据不足。

## 依据

| 判断 | 证据 | 可信度 |
|---|---|---|
| ... | 来源与关键发现 | 高/中/低 |

## 分歧与不确定性

- ...

## 建议

1. ...
2. ...

## 下一步验证

- ...

## 来源

- [标题](URL) — 来源类型，日期，为什么使用它