关于 researching-on-the-internet
用于收集最新且有来源依据的网络信息,支持规划与设计决策的研究技能。它强调优先查阅官方资料、交叉核实主张,并以证据为基础简洁汇报。
主要功能
- 01优先检索权威来源
- 02交叉核实主张与证据
- 03测试可证伪的假设
- 04评估来源质量与时效
- 05附链接和置信度汇报
适用场景
- 01集成前查阅最新 API 文档
- 02比较库与替代方案
- 03核实技术主张和假设
- 04调查当前最佳实践
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ ed3dai/ ed3d-plugins --skill researching-on-the-internet安装后在 Claude Code 中输入/researching-on-the-internet确认已加载。
详细介绍
在互联网上进行研究
概述
从互联网上收集准确、最新且来源可靠的信息,为规划和设计决策提供依据。测试假设、核实说法,并查找有关 API、库和最佳实践的权威来源。
适用场景
适用于:
- 在设计集成方案前查找最新的 API 文档
- 测试假设(“库 X 比库 Y 快吗?”、“方案 Z 能与版本 N 配合使用吗?”)
- 核实技术说法或假设
- 调研库的对比结果和替代方案
- 查找最佳实践和当前社区共识
不适用于:
- 代码库中已有的信息(使用代码库搜索)
- Claude 训练数据中的常识(直接作答即可)
- 项目特定的惯例(查看 CLAUDE.md)
核心研究流程
不要使用嵌套子 Agent。 如果你作为研究子 Agent 运行,请直接使用当前可用的 Web/搜索/抓取工具开展研究。不要分派或调用其他子 Agent。
- 明确问题 - 具体胜过模糊
- 优先搜索官方来源 - 文档、发行说明、变更日志
- 交叉核对 - 在多个来源之间核实说法
- 评估质量 - 按层级划分来源(官方 → 已验证 → 社区)
- 简洁汇报 - 先给出答案,再提供链接和证据
测试假设
收到待验证的假设时:
- 找出可证伪的说法 - 将假设拆分为可测试的部分
- 搜索支持性证据 - 有哪些证据可以确认?
- 搜索反驳性证据 - 有哪些证据与之矛盾?
- 评估来源质量 - 根据层级衡量证据的权重
- 汇报发现 - 根据证据说明支持/反驳/无法确定
- 注明置信度 - 是高度共识、单一来源,还是信息相互矛盾
示例:
Hypothesis: "Library X is faster than Y for large datasets"
Search for:
✓ Benchmarks comparing X and Y
✓ Performance documentation for both
✓ GitHub issues mentioning performance
✓ Real-world case studies
Report:
- Supported: [evidence with links]
- Contradicted: [evidence with links]
- Conclusion: [supported/contradicted/mixed] with [confidence level]
快速参考
| 任务 | 策略 |
|---|---|
| API 文档 | 官方文档 → GitHub README → 最新教程 |
| 库对比 | 官方网站 → npm/PyPI 统计数据 → GitHub 活动情况 |
| 最佳实践 | 官方指南 → 最新文章 → Stack Overflow |
| 故障排查 | 搜索错误信息 → GitHub issues → Stack Overflow |
| 当前状态 | 发行说明 → 变更日志 → 最新公告 |
| 测试假设 | 明确说法 → 搜索正反两方 → 衡量证据权重 |
来源评估层级
| 层级 | 来源 | 用途 |
|---|---|---|
| 1 - 最可靠 | 官方文档、发行说明、变更日志 | 主要证据 |
| 2 - 通常可靠 | 已验证的教程、维护中的示例、信誉良好的博客 | 辅助证据 |
| 3 - 谨慎使用 | Stack Overflow、论坛、旧教程 | 检查日期并交叉核实 |
在发现中始终注明来源层级。
搜索策略
采用多种方法:
- 使用 WebSearch 获取概览和最新信息
- 使用 WebFetch 获取特定文档页面
- 如果可用,检查 MCP 服务(Context7、搜索工具)
- 沿链接查找权威来源
- 搜索社区资源前,先搜索官方文档
交叉核对:
- 在多个来源之间核实说法
- 检查发布日期,优先选择较新的来源
- 标记破坏性变更或弃用情况
- 注明信息可能已过时的情况
- 区分稳定 API 与实验性功能
报告发现
先给出答案:
- 首先直接回答问题
- 其次提供支持性细节和来源链接
- 相关时附上代码示例(注明出处)
包含元数据:
- 版本号和兼容性要求
- 时效性主题的发布日期
- 安全注意事项或最佳实践
- 常见陷阱或迁移问题
- 根据来源共识评估的置信度
清晰说明不确定性:
- “未找到关于 [topic] 的官方文档”是有效表述
- 说明搜索了什么内容,以及查阅了哪些地方
- 区分“不存在”和“未能找到可靠信息”
- 对发现的内容添加适当的限定说明
- 建议替代搜索词或方法
常见错误
| 错误 | 修正方法 |
|---|---|
| 只搜索一个来源 | 至少交叉比对 2-3 个来源 |
| 忽略发布日期 | 检查日期,并标记过时信息 |
| 把所有来源一视同仁 | 使用分级体系,并按权重评估 |
| 未经核实就报告 | 先跨来源核实说法 |
| 假设检验含糊不清 | 拆分为具体且可证伪的说法 |
| 跳过官方文档 | 始终从第 1 级来源开始 |
| 仅凭单一来源就过度自信 | 标明来源级别,并查找共识 |
评论
支持 Markdown