微信扫一扫多源研究技能
先评估研究规模，再选择最小足够流程。小题快速查证；大题按 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-guidelinesskill 并在最终回复末尾给出 karpathy 证据小结。」
3. 搜索与证据
- 先盘点当前可用的搜索类 MCP 工具：网页搜索、内容抓取、官方文档、代码搜索、仓库文档、结构化数据等。
- 在不扩大用户范围的前提下，尽可能使用多种相关 MCP 搜索工具；默认目标是 3 类，至少 2 类。只有 1 类可用时标注
单源限制。 - 优先高可信来源：官方文档、源码、release notes、标准、论文、一手数据。
- 社区、博客、教程可补充解释，但不能单独支撑关键结论。
- 独立请求尽量并行；每条结果先压缩为 2-3 句摘要，再聚合分析。
- 记录来源工具、标题、完整精确 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 引用规则
- 关键重要信息必须在同一 bullet、同一段落末尾，或紧邻的来源条目中给出完整精确 URL。
- 每条关键结论默认引用 1-3 个最强来源；多源验证用最权威、最独立、最贴近原始出处的来源代表，不罗列所有辅助来源。
- 若一个 URL 同时支撑多条关键结论，可在来源小节列一次，并在正文用短标签引用，例如
[S1]，但[S1]对应条目必须包含完整精确 URL。 - 若无法取得完整精确 URL，不得标
[verified]；降级为[likely]、[single-source]或[unknown]，并说明缺口。 - 用户明确要求完整 bibliography、审计清单或研究日志时，才列出全部来源 URL；否则保持关键来源最小集。
保持简洁，默认使用：
## 要点
- [verified] ...
- [single-source] ...
- [conflicting] A 说 ...；B 说 ...
## 分析
### 子主题 A
...
## 来源（仅关键来源）
1. [S1] 标题 — 完整精确 URL — 支撑：[对应关键结论] — [可信度 高/中/低，偏见说明]
2. [S2] 标题 — 完整精确 URL（归档：https://web.archive.org/...）— 支撑：[对应关键结论] — [可信度 高/中/低，偏见说明]
辅助来源：已查但未逐条列出；仅用于背景理解或交叉检查，未单独支撑关键结论。
来源小节规则：
- 来源小节默认只列关键来源。关键来源指直接支撑要点区结论、置信度标记、冲突判断、反方证据、排名/推荐/风险判断的来源。普通背景、重复转载、弱相关教程、搜索命中页不进入来源小节，除非用户要求完整来源清单。
- 每个来源条目必须包含完整精确 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/脚本执行工具 | | 用户要的不是研究而是写代码/改代码 | 退出研究模式，交给实现环节 |