名称: 网络研究 描述: 在规划功能时需要当前API文档、库模式或外部知识时使用；当测试技术选择或声明的假设时；当在设计决策前验证假设时 - 收集来自互联网的可靠、最新信息，以告知技术决策 用户可调用: false
在互联网上研究
概述
收集来自互联网的准确、最新、来源可靠的信息，以告知规划和设计决策。测试假设、验证声明，并为API、库和最佳实践找到权威来源。
何时使用
用于：
- 在集成设计前查找当前API文档
- 测试假设（“库X是否比Y快？”、“方法Z是否适用于版本N？”）
- 验证技术声明或假设
- 研究库比较和替代方案
- 查找最佳实践和当前社区共识
不用于：
- 代码库中已有的信息（使用代码库搜索）
- Claude培训中的一般知识（直接回答）
- 项目特定约定（检查CLAUDE.md）
核心研究工作流程
- 清晰定义问题 - 具体优于模糊
- 首先搜索官方来源 - 文档、发布说明、变更日志
- 交叉引用 - 在多个来源中验证声明
- 评估质量 - 分层来源（官方 → 已验证 → 社区）
- 简洁报告 - 先提供答案，然后提供链接和证据
假设测试
当给定要测试的假设时：
- 识别可证伪的声明 - 将假设分解为可测试部分
- 搜索支持证据 - 什么确认了这个？
- 搜索反驳证据 - 什么与这个矛盾？
- 评估来源质量 - 按层级加权证据
- 报告发现 - 支持/反驳/不确定，带有证据
- 注明置信水平 - 强共识 vs 单一来源 vs 冲突信息
示例：
假设: “库X对于大型数据集比Y快”
搜索：
✓ 比较X和Y的基准测试
✓ 两者的性能文档
✓ 提到性能的GitHub问题
✓ 实际案例研究
报告：
- 支持: [证据和链接]
- 反驳: [证据和链接]
- 结论: [支持/反驳/混合] 带有 [置信水平]
快速参考
| 任务 | 策略 |
|---|---|
| API文档 | 官方文档 → GitHub README → 近期教程 |
| 库比较 | 官方站点 → npm/PyPI统计 → GitHub活动 |
| 最佳实践 | 官方指南 → 近期帖子 → Stack Overflow |
| 故障排除 | 错误搜索 → GitHub问题 → Stack Overflow |
| 当前状态 | 发布说明 → 变更日志 → 近期公告 |
| 假设测试 | 定义声明 → 搜索双方 → 加权证据 |
来源评估层级
| 层级 | 来源 | 使用 |
|---|---|---|
| 1 - 最可靠 | 官方文档、发布说明、变更日志 | 主要证据 |
| 2 - 一般可靠 | 已验证教程、维护示例、信誉博客 | 支持证据 |
| 3 - 谨慎使用 | Stack Overflow、论坛、旧教程 | 检查日期、交叉验证 |
在发现中始终注明来源层级。
搜索策略
多种方法：
- WebSearch 用于概述和当前信息
- WebFetch 用于特定文档页面
- 如果有可用，检查MCP服务器（Context7、搜索工具）
- 跟随链接到权威来源
- 在社区资源之前搜索官方文档
交叉引用：
- 在多个来源中验证声明
- 检查发布日期 - 偏好近期
- 标记重大变更或弃用
- 注意信息可能过时
- 区分稳定API和实验功能
报告发现
先提供答案：
- 首先直接回答问题
- 其次是支持细节和来源链接
- 当相关时提供代码示例（带有归属）
包括元数据：
- 版本号和兼容性要求
- 时间敏感主题的发布日期
- 安全考虑或最佳实践
- 常见陷阱或迁移问题
- 基于来源共识的置信水平
清晰处理不确定性：
- “未找到[主题]的官方文档”是有效的
- 解释搜索了什么和在哪里查找
- 区分“不存在”和“找不到可靠信息”
- 以适当警告呈现找到的内容
- 建议替代搜索词或方法
常见错误
| 错误 | 修复 |
|---|---|
| 只搜索一个来源 | 交叉引用最少2-3个来源 |
| 忽略发布日期 | 检查日期，标记过时信息 |
| 平等对待所有来源 | 使用层级系统，相应加权 |
| 验证前报告 | 首先在来源间验证声明 |
| 模糊假设测试 | 分解为具体可证伪声明 |
| 跳过官方文档 | 始终从层级1来源开始 |
| 对单一来源过度自信 | 注明来源层级并寻找共识 |