web-search

name	web-search
description	当任务需要联网检索、外部依据、最新技术知识、官方文档、GitHub 仓库、论文博客、标准、数据集、benchmark、许可证、价格、API 或工程实践依据时使用；适合代码生成前的技术选型、方案设计、内容生成、论文理解、工具库更新和其他 skill 需要外部依据支撑结论的场景。用户明确要求不联网时不要使用。

web-search

技能定位

用于给代码开发、内容生成、方案设计、技术选型、论文理解、官方 API 使用、工具库更新、前沿博客和 benchmark 规则提供可追溯的外部依据。目标是弥补 Agent 的知识滞后，避免在外部事实可能变化时凭记忆回答。

本 skill 不绑定单一项目、单一技术栈或单一资料类型。它既服务学术论文，也服务工程实践、官方文档、作者仓库、release notes、数据集主页、RFC / 标准、供应商文档和社区高质量实践。

触发场景

• 用户明确要求联网、检索、查资料、查论文、查官方文档、查 GitHub、查 benchmark 或查最新进展。
• 信息可能近期变化，例如模型版本、API、库用法、框架能力、许可证、价格、标准、论文结论、数据集规则、release notes 或供应商政策。
• 代码生成、技术选型、架构设计、内容生成或文档编写依赖外部事实。
• 另一个 skill 需要外部依据支撑结论，例如 $knowledge-explainer 需要解释最新论文、官方文档、benchmark、争议结论或现代 API。
• 用户问“现在主流怎么做”“有没有官方实现”“最新版本怎么用”“这个 benchmark 规则是什么”“这个库还推荐吗”。

不触发场景

• 用户明确要求不联网、不检索或只基于本地材料回答。
• 本地源码、README、设计文档、测试日志已经足够回答，且问题不依赖最新外部信息。
• 纯文件整理、格式修复、已有代码解释、无外部事实依赖的一次性任务。
• 用户只要求本地 diff、当前实现、仓库内调用链或已有文档的总结。

检索源优先级

优先使用一手来源，并按任务类型调整具体来源：

1. 官方文档、标准、RFC、供应商文档、官方 release notes。
2. 作者仓库、官方 GitHub、论文代码、数据集主页、benchmark 官方页面。
3. 一手论文、会议页面、作者主页、arXiv、OpenReview、ACL Anthology、主要会议或期刊页面。
4. 高质量技术博客、工程实践文章、项目 issue、维护者讨论、迁移指南。
5. 社区问答、论坛、社交媒体只作为补充，不能作为唯一依据。

不同项目可以替换具体来源类型，但不能降低“优先一手来源、二手来源只作补充”的原则。

最小检索流程

1. 明确任务类型：
   • 官方 API / 库用法确认。
   • 代码生成前技术选型。
   • 论文、方法、benchmark 或数据集调研。
   • 工程实践、架构方案或迁移策略对照。
   • 许可证、价格、标准、兼容性或发布规则核对。
2. 拆关键词：
   • 用户原始中文问题。
   • 英文关键词、同义词、论文术语、库名、版本名、接口名。
   • 当前项目相关关键词，但不要把项目私有事实写成外部事实。
3. 优先查一手来源：
   • API / 库任务至少查官方文档或官方 release notes。
   • 论文 / benchmark / 数据集任务至少查论文、会议页面、作者仓库或官方主页。
   • 工程选型任务至少查官方文档、维护者仓库或权威迁移说明。
4. 对来源做可信度分层：
   • 明确哪些是已确认事实。
   • 明确哪些是来源之间存在冲突的判断。
   • 明确哪些是工程推断。
   • 明确哪些仍需用户或真实环境验证。
5. 只把可靠来源纳入最终结论。若只能找到二手来源，必须说明“证据不足”，不能写成确定事实。

输出结构

按任务需要裁剪，但默认包含：

1. 问题重述：这次检索要解决什么决策或事实。
2. 检索关键词：列出中文关键词和英文关键词。
3. 核心发现：按官方规范、论文依据、工程实践、社区补充等来源类型分组。
4. 结论分层：
   • 已确认事实。
   • 来源冲突与取舍。
   • 工程推断。
   • 仍需真实环境验证的边界。
5. 项目落地点：如果和当前项目相关，说明对模块、流程、接口、数据、测试、文档或设计取舍的影响；如果只是背景知识，明确说明不直接落代码。
6. 来源清单：给出可点击链接，并标注来源类型、年份或更新时间。

代码生成前的特别要求

当检索服务于代码生成、配置修改或架构决策时，必须先把结论转成工程约束：

• 推荐使用哪个官方 API、库、协议、格式或实现路径。
• 不推荐什么做法，原因是什么，依据来自哪里。
• 当前项目的最小可行实现是什么。
• 哪些内容只能作为后续扩展，不能包装成当前已完成能力。
• 需要新增或更新哪些测试、smoke test、文档或验证证据。
• 如果来源和当前项目环境不完全匹配，说明差异和需要真实环境验证的边界。

质量要求

• 不允许只写“网上说”“资料显示”这类不可追溯表达。
• 不允许只给二手转述；二手来源只能作为补充。
• 不允许把论文、博客或官方能力夸大成当前项目已实现。
• 涉及现代库、API、模型、标准、许可证、价格或 benchmark 时，必须核对最新官方来源。
• 若不同来源冲突，必须说明冲突点、取舍理由和仍需验证的部分。
• 若网页无法访问，说明访问限制，并改用可访问的一手来源或高质量来源。
• 输出外部依据时，必须区分已确认事实、冲突判断、工程推断和未验证边界。

自检

输出前检查：

1. 是否满足触发条件，且用户没有要求不联网。
2. 是否至少优先使用了一手来源。
3. 是否给出可追溯链接，而不是泛泛转述。
4. 是否区分事实、冲突、推断和未验证边界。
5. 如果服务于代码生成，是否把外部结论转成最小工程约束和验证要求。
6. 是否没有把任何单一项目的私有路径、模块名、benchmark、trace 文件或测试命令写成通用模板事实。