changan-su/forsion/web-research

网络调研

总流程

1. 拆解问题:明确要回答的 2-5 个子问题,复杂调研先用 todo_write 列出。
2. 对每个子问题用 web_search 搜索(关键词策略见下)。
3. 从结果中挑 2-3 个高质量来源,用 web_fetch 深读原文,不要只凭搜索摘要下结论。
4. 交叉验证后归纳,输出带引用的结论。

web_search 关键词策略

• 中英文都搜:技术类信息英文资料通常更全更新,中文搜索补充本土生态(微信/支付宝/国内云厂商等场景反之以中文为主)。同一问题至少各搜一轮。
• 从具体到宽泛:先搜最具体的表述(报错原文加引号、确切 API 名),没结果再逐步放宽。
• 限定站点提高信噪比:
• site:github.com 找 issue/源码;site:stackoverflow.com 找报错;
• site:docs.xxx.com 或 关键词 official documentation 找官方文档;
• site:news.ycombinator.com / site:reddit.com 找真实使用评价。
• 限定时效:加年份(如 2025)或版本号(如 react 19)过滤过期内容。
• 报错排查:整段报错太长时,截取去掉路径和变量值后的稳定部分加引号搜。
• 一次搜索不理想就换表述重搜(同义词、换语言、加/减限定词),最多 3-4 轮;仍无果应如实告知用户而非硬编。

web_fetch 深读

• 优先 fetch:官方文档 > 源码/changelog > 高票 SO 回答/活跃 issue > 知名技术博客 > 内容农场(基本不可信)。
• GitHub 技巧:README 之外,优先看 CHANGELOG.md、releases 页、相关 issue 的最新回复(顶楼可能已过时)。
• fetch 到的长页面,围绕子问题提取关键段落,记录页面上的发布/更新日期。
• 页面打不开时:尝试去掉 URL 参数、换 http/https,或搜索 cache: 替代来源。

交叉验证(下结论的门槛)

• 重要结论必须有 2 个以上相互独立的来源支持。注意"独立":多篇互相转载/同源翻译的文章只算一个来源。
• 来源冲突时:比发布时间(新者优先)、比权威性(官方 > 社区)、比证据(给出可复现代码/数据者优先);无法裁决就把分歧如实呈现给用户。
• 区分事实与观点:基准测试数据、API 行为是事实;"X 比 Y 好"是观点,呈现时要带上立场背景。
• 对 AI 生成感强、无署名无日期、与其他来源矛盾的页面降权。
• 可本地验证的尽量验证:版本号、API 是否存在等,用 run_bash(如 npm view <pkg> version)实测一次胜过三个来源。

时效性检查(每个来源必做)

• 找页面的发布/更新日期;没有日期的来源可信度降一档。
• 对照当前日期判断:涉及版本、价格、API、政策的信息,超过 1-2 年的视为"可能过时",需用更新来源确认。
• 软件类调研明确"截至何版本":答案里写清楚"以 vX.Y 为准"。
• 警惕搜索结果里高排名的老文章(SEO 强但内容旧)。

输出格式

结论部分采用如下结构:

## 结论
直接回答用户问题(1-3 句),标注确信度(确认/较可能/存疑)。
 
## 依据
-要点 1 …… [来源1]
-要点 2 …… [来源1][来源3]
-存在分歧的点:A 来源称 X,B 来源称 Y,倾向 X 因为……
 
## 来源
1.页面标题 — URL(发布/更新日期)
2.…

• 每个关键论断后内联标注来源编号,让用户可逐条溯源。
• 引用只列实际深读且支持了结论的来源,不堆砌搜索结果列表。
• 来源不足或全部过时,明确写"该结论证据有限",不要伪装成确定答案。
• 数字、版本号、命令等关键细节,从 fetch 的原文复制,不凭记忆改写。