multi-source-inquiry

name	multi-source-inquiry
description	当答案需要联网检索或独立多源验证，包括事实核查、技术对比、当前信息、冲突说法或重要建议时使用。

多源研究技能

先评估研究规模，再选择最小足够流程。小题快速查证；大题按 MECE 子主题并行研究，由主 agent 交叉验证并汇总。任何输入先 SIFT 一遍：Stop（先暂停别急着用）、Investigate the source（查谁说的）、Find better coverage（找更可信的覆盖）、Trace claims（追到原始出处），再决定走哪个规模档。

1. 评估主题规模

主题不清时，只问一个澄清问题：研究对象、范围或成功标准。主题清楚时直接打分：

维度	满足条件
子主题	涉及 2+ 个独立问题或对象
来源	需要 2+ 类来源，如官方文档、论文、源码、新闻、社区
分析	需要比较、排名、趋势、因果或方案判断
时效	结论依赖日期、版本、政策或近期变化
风险	错误结论会影响重要决策、金钱、法律、医疗或安全

得分	路径
0-1	小型：1-2 个最相关的高可信来源，直接回答，标注来源限制
2-3	中型：尽可能使用当前可用的多类 MCP 搜索工具并行搜索，交叉验证后输出
4-5	大型：先 MECE 拆分，再委托 sub-agent 覆盖不同 MCP 搜索工具/来源域并行研究

用户指定范围或禁用来源时，以用户限制为准。

2. 大型研究路径

仅当得分 4-5，或用户明确要求深度研究/多 agent 并行时使用。

MECE 拆分：选择一个主维度，必要时加一个次维度。

维度	适用场景
对象	A/B/C 方案、产品、框架、公司对比
视角	技术、商业、用户、合规、安全等视角
时间	历史、现状、近期变化、趋势
来源域	官方/源码、学术、一手数据、社区/媒体

生成候选子题后，合并重叠项、补齐遗漏项，最终保留 3-6 个边界清晰的子任务。每个子任务必须能独立完成，且共同覆盖用户问题。

委托规则：无依赖子任务并行交给 sub-agent；若当前环境没有 sub-agent 工具，则按子任务顺序手动执行并在结果中标注未并行。主 agent 不重复全量搜索，只做汇总、去重、冲突处理和最终判断。

每个 sub-agent prompt 必须包含：

• 子任务边界、排除范围、成功标准
• 建议来源类型或工具类型
• 输出格式：2-3 句摘要、关键证据、完整精确 URL、可信度标记；只交付支撑关键结论的 URL，不列辅助命中大全
• 「编码相关任务请先加载 karpathy-guidelines skill 并在最终回复末尾给出 karpathy 证据小结。」

3. 搜索与证据

• 先盘点当前可用的搜索类 MCP 工具：网页搜索、内容抓取、官方文档、代码搜索、仓库文档、结构化数据等。
• 在不扩大用户范围的前提下，尽可能使用多种相关 MCP 搜索工具；默认目标是 3 类，至少 2 类。只有 1 类可用时标注 单源限制。
• 优先高可信来源：官方文档、源码、release notes、标准、论文、一手数据。
• 社区、博客、教程可补充解释，但不能单独支撑关键结论。
• 独立请求尽量并行；每条结果必须先提炼主判断，再按“判断 / 限定 / 证据”分层组织。最终输出必须留出清楚留白，写成可扫描的短块；禁止把结论、限定、证据、来源、冲突塞进同一段或同一条密集 bullet。
• 记录来源工具、标题、完整精确 URL、发布日期或版本。完整精确 URL 必须指向支撑该说法的具体页面、源码 permalink、论文 DOI/landing page、release note、标准页或一手公告；不要用搜索结果页、站点首页、短链、聚合页替代。
• 对关键重要信息必须保留完整精确 URL。关键重要信息包括：要点区结论、置信度标记依据、排名/推荐/风险判断、冲突来源、反方证据、会影响用户行动或技术决策的事实。
• 辅助来源只用于理解背景时，不必全部列入最终输出；若未列全，说明“辅助来源已查但未逐条列出”。不要把搜索命中结果当 bibliography 堆给用户。
• 反方查询：任何会被标 [verified] 的关键结论，必须至少跑一次反方向查询，针对该结论的具体否命题或反主张（例如原结论「X 比 Y 快」→ 反方查询「Y 比 X 快的 benchmark」「X 的性能退化案例」，而不是泛泛的「X criticism」）。实际跑过的反方 query 串与命中条数需写进证据链或单独一段，供主代理与用户审查。未找到反证只能记为「未发现反对证据」（可能只是查询词/语言域/工具覆盖不够），不能单独提高置信度；搜出实质反对意见则原结论降级为 [conflicting] 或 [likely]。

若搜索为空，说明已尝试的 MCP 工具、关键词和来源类型，并给出下一步建议。

4. 交叉验证

标记	条件
[verified]	关键结论：3+ 独立来源支持，且至少 1 个高可信。一般事实：2+ 独立来源支持，且至少 1 个高可信。若结论依赖时效（标的是当前状态、版本、政策、价格等），来源发布日期还需落在主题对应的时效窗口内（例如「当前 API 行为」要求近 12 个月内来源），否则只能标 [likely]
[likely]	2+ 来源但未达 [verified] 门槛（例如缺高可信来源，或属关键结论但只有 2 个来源）
[single-source]	仅 1 个来源支持
[conflicting]	来源之间存在实质矛盾
[unknown]	未找到足够证据

[verified] 的关键结论还必须能给出完整精确 URL 证据；无法给出完整精确 URL 时，即使有多源摘要，也只能标 [likely] 或更低。

独立性判定：同一新闻稿转载、同一项目文档镜像、同一作者重复发布不算独立来源。区分一手与转引：3 个媒体转引同一份原始报道按 1 个独立来源算；只有追到不同的一手出处才算多源。无法追到一手出处或无法判定是否同源时，按 1 个独立来源计，并在标记后注 [来源独立性未验证]。矛盾无法消解时，列出各方说法和证据，不把推测写成事实。

5. 输出格式

关键 URL 引用规则

• 关键重要信息在正文里可以只保留短标签引用，例如 [S1]；完整精确 URL 必须出现在紧邻的来源条目中。不要为了就地塞 URL，把判断区写成密集大段。
• 每条关键结论默认引用 1-3 个最强来源；多源验证用最权威、最独立、最贴近原始出处的来源代表，不罗列所有辅助来源。
• 若一个 URL 同时支撑多条关键结论，可在来源小节列一次，并在正文用短标签引用，例如 [S1]，但 [S1] 对应条目必须包含完整精确 URL。
• 若无法取得完整精确 URL，不得标 [verified]；降级为 [likely]、[single-source] 或 [unknown]，并说明缺口。
• 用户明确要求完整 bibliography、审计清单或研究日志时，才列出全部来源 URL；否则保持关键来源最小集。

最终输出必须同时满足：简洁、可扫描、有留白，且不牺牲限定条件、冲突信息与证据可追溯性。默认使用：

## 要点

- [verified] 主判断 ...
  - 限定 / 条件：...
  - 关键证据：...[S1]

- [single-source] 主判断 ...
  - 证据缺口 / 不确定性：...

- [conflicting] A 说 ...；B 说 ...
  - 分歧点：...
  - 当前仍未知：...

## 分析

### 这条判断为何成立
...

### 哪些条件、例外或冲突会改变判断
...

## 来源（仅关键来源）

1. [S1] 标题
   完整精确 URL
   支撑：[对应关键结论]
   [可信度 高/中/低，偏见说明]

2. [S2] 标题
   完整精确 URL（归档：https://web.archive.org/...）
   支撑：[对应关键结论]
   [可信度 高/中/低，偏见说明]

辅助来源：已查但未逐条列出；仅用于背景理解或交叉检查，未单独支撑关键结论。

输出行为规则

• 必须先给主判断，再给限定 / 条件 / 例外 / 不确定性。 不要把这些信息揉成一长句。
• 必须把限定条件、冲突信息、证据缺口分开站位。 可以用短句、缩进子项或单独小节，但不能压平。
• 必须让来源区与判断区分层。 正文负责告诉用户“目前怎么判断”；来源区负责告诉用户“依据来自哪里”。
• 必须保留 evidence labels、conflicts、uncertainty、exact URL。 可读性改进不能以删除这些信息为代价。
• 禁止写成信息密块。 如果一段或一条 bullet 同时承担结论、限定、证据、来源、冲突多个角色，必须拆开。

反例（禁止）

- [likely] X 更好，因为 A 来源说... 但 B 来源不同意，不过官方文档又提到条件 C，所以这里可能只在版本 V 成立，详见 https://... 和 https://...

上面这种写法把结论、限定、冲突、来源和 URL 挤在同一块里，用户难以扫读，禁止照此输出。

来源小节规则：

• 来源小节默认只列关键来源。关键来源指直接支撑要点区结论、置信度标记、冲突判断、反方证据、排名/推荐/风险判断的来源。普通背景、重复转载、弱相关教程、搜索命中页不进入来源小节，除非用户要求完整来源清单。
• 每个来源条目必须包含完整精确 URL；URL/出处 不得只写域名、首页、搜索页、短链或“官方文档”这类不可直接定位的描述。
• 对支撑关键结论、或被反复引用的来源，单行注明 [可信度 高/中/低，偏见说明]（例如「[可信度 高，厂商自述，存在利益相关]」）。偏见说明须指明具体偏见方向或利益关系，不接受「可能有偏见」「立场中立」这类无信息标注。普通辅助来源不用。
• 对支撑 [verified] 关键结论的易变内容（新闻页、政策页、商业声明、个人博客等），优先提交 https://web.archive.org/save/<URL> 留档并在引用里挂归档链接；无法归档时标注「未归档」及原因。稳定官方文档、论文 DOI、源码 commit/permalink 不强制归档。

大型研究额外补一行：拆分方式：<主维度> × <次维度>，共 <n> 个子任务。

边界情况

保存路径：用户要求保存时写入 docs/research/YYYY-MM-DD-<topic>.md，否则只在对话中输出。工具不足、sub-agent 失败、结果重叠等情况，按本 skill 通用原则降级（标注限制、保留可用结果、去重后保留最权威来源）。

何时切换出本 skill

本 skill 处理多源研究与交叉验证。出现以下信号时，优先切到更合适的工具或 subagent，不要在本 skill 里硬撑：

信号	更合适的处理方式
需要查仓库代码实现、调用关系、本地文件结构	交给代码检索工具或代码探索 subagent（grep / read / ast 类）
需要查 npm/pip/cargo 包 API、官方文档、外部库行为	交给文档/网页检索工具或文档检索 subagent
涉及架构判断、多系统权衡、技术选型决策	交给顾问型/二级评审型 subagent，或主 agent 明说推理边界
需要执行计算、数据处理、命令验证	交给 shell/脚本执行工具
用户要的不是研究而是写代码/改代码	退出研究模式，交给实现环节