multi-source-inquiry

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

多源研究技能

Multi-Source Research Skill

先评估研究规模，再按统一的多轮骨架执行：探路、定指标、深挖、收敛、报告。规模不决定走不走多轮，只决定每轮的广度、并行度和轮次预算。任何输入先 SIFT 一遍：Stop（先暂停别急着用）、Investigate the source（查谁说的）、Find better coverage（找更可信的覆盖）、Trace claims（追到原始出处），再决定规模档。

First evaluate the research scale, then execute according to the unified multi-round framework: Scouting, Defining Metrics, Deep Diving, Converging, Reporting. The scale does not determine whether to adopt multi-rounds, but only decides the breadth, parallelism and round budget of each round. First run any input through SIFT: Stop (pause before using), Investigate the source (check who said it), Find better coverage (look for more credible coverage), Trace claims (track down the original source), then determine the scale level.

1. 评估主题规模

1. Evaluate Topic Scale

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

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

得分	档位	轮次预算与并行度
0-1	小型	探路轮即主轮：1-2 个高可信来源，证据足则当场收敛
2-3	中型	探路 + 定指标 + 至多 2 个深挖轮；多类 MCP 搜索工具并行自搜
4-5	大型	探路 + 定指标 + 至多 3 个深挖轮；按缺口派并行 sub-agent

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

When the topic is unclear, only ask one clarification question: research object, scope or success criteria. When the topic is clear, score directly:

Dimension	Qualifying Conditions
Sub-topics	Involves 2+ independent questions or objects
Sources	Requires 2+ types of sources, such as official documents, papers, source code, news, communities
Analysis	Requires comparison, ranking, trend, causality or solution judgment
Timeliness	Conclusion depends on date, version, policy or recent changes
Risk	Wrong conclusions will affect important decisions, money, law, medical care or safety

Score	Level	Round Budget & Parallelism
0-1	Small	Scouting round is the main round: 1-2 highly credible sources, converge immediately if evidence is sufficient
2-3	Medium	Scouting + Defining Metrics + up to 2 Deep Diving rounds; parallel self-search with multiple types of MCP search tools
4-5	Large	Scouting + Defining Metrics + up to 3 Deep Diving rounds; assign parallel sub-agents according to gaps

When the user specifies a scope or disables sources, follow the user's restrictions. When the user specifies a round upper limit, follow the user's upper limit.

2. 多轮研究循环（默认骨架）

2. Multi-Round Research Cycle (Default Framework)

所有档位共用同一骨架：探路、定指标、深挖、收敛、报告。档位只决定每轮的广度、并行度和轮次上限（见【规模档表】）。

先宽后窄（中/大型题或多轮研究）：宽查询在前，指标、子题、关注点从宽结果里长出来，窄深挖在最后；跳过宽查询直接深挖单点，是违规。小型题按【规模档】收敛，不受此限。

次序：探路（宽查询）→ 定指标（维度/子题从宽结果长出）→ 深挖（窄，只攻缺口）→ 收敛。

探路（宽）：用 1-2 类搜索工具做一轮宽查询，产出主题地形简报：关键实体、核心争议、可用来源类型、子问题候选。小型题在这一轮证据已足就直接收敛，不强制后续轮。
定指标（从宽产出）：主 agent 读探路简报，定出本次研究的评估维度或子题清单。大型题复用【MECE 维度表】拆分；中小题列 2-5 个待证关键问题即可。指标来自探路发现的线索，不套固定模板。多对象对比时，维度必须所有研究对象都能回答。
深挖（窄）：每轮只攻上一轮留下的缺口。查询词或子任务必须由上一轮的发现显式驱动：新实体、新冲突、未覆盖维度。不重复已覆盖的查询。大型题按维度派并行 sub-agent（委托契约见【大型研究路径】）；中小题自己搜。深挖双触发：缺口驱动 + 用户点名维度；点名时升级 effort，直读底层实现（源码/状态机/协议原文）。
每轮结束做缺口盘点：列出已覆盖（附证据标记）、仍缺口、新线索三栏，据此决定下一轮打哪里，或者停。
收敛判停：以下任一信号满足即停，并在报告写明判停依据：
- a) 覆盖全：所有关键维度已有证据，或显式标
```
[unknown]
```
  并说明查过什么；
- b) 无新增：本轮没有新增关键事实或独立来源，继续搜的预期收益约为零；
- c) 到上限：用完【规模档表】的轮次预算。上限是安全预算，不代表信息已饱和；到上限而停时，必须把未覆盖维度标
```
[unknown]
```
  。
报告：按【输出格式】写，首行记录实际轮次与判停信号。

All levels share the same framework: Scouting, Defining Metrics, Deep Diving, Converging, Reporting. The level only determines the breadth, parallelism and round upper limit of each round (see [Scale Level Table]).

Start broad then narrow (for medium/large topics or multi-round research): broad queries first, metrics, sub-topics and focus points emerge from broad results, narrow deep diving at the end; skipping broad queries and directly deep diving into single points is a violation. Small topics converge according to [Scale Level] and are not subject to this restriction.

Order: Scouting (broad) → Defining Metrics (dimensions/sub-topics emerge from broad results) → Deep Diving (narrow, only target gaps) → Converging.

Scouting (broad) : Use 1-2 types of search tools to conduct a round of broad queries, and produce a topic terrain briefing: key entities, core controversies, available source types, candidate sub-questions. For small topics, if evidence is sufficient in this round, converge directly without forcing subsequent rounds.
Defining Metrics (from broad outputs) : The main agent reads the scouting briefing and defines the evaluation dimensions or sub-question list for this research. For large topics, split using [MECE Dimension Table]; for small/medium topics, list 2-5 key questions to be verified. Metrics come from clues found in scouting, not fixed templates. When comparing multiple objects, dimensions must be answerable by all research objects.
Deep Diving (narrow) : Each round only targets the gaps left from the previous round. Query terms or sub-tasks must be explicitly driven by the findings of the previous round: new entities, new conflicts, uncovered dimensions. Do not repeat covered queries. For large topics, assign parallel sub-agents by dimension (see [Large Research Path] for delegation contract); small/medium topics are searched by the main agent. Deep Diving dual triggers: gap-driven + user-specified dimensions; when specified, upgrade effort to directly read underlying implementations (source code/state machine/protocol original text).
Gap inventory at the end of each round : List three columns: covered (with evidence markers), still gaps, new clues, and decide where to target in the next round or stop accordingly.
Convergence and stop criteria : Stop when any of the following signals are met, and state the stop basis in the report:
- a) Full coverage: All key dimensions have evidence, or explicitly marked
```
[unknown]
```
  with explanations of what was searched;
- b) No new information: No new key facts or independent sources in this round, the expected benefit of continuing search is approximately zero;
- c) Reached upper limit: Used up the round budget in [Scale Level Table]. The upper limit is a safety budget, not indicating information saturation; when stopping due to reaching the upper limit, must mark uncovered dimensions as
```
[unknown]
```
  .
Report : Write according to [Output Format], record the actual rounds and stop signal in the first line.

3. 大型研究路径

3. Large Research Path

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

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

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

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

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

多对象对比且对象间可独立取证、对比维度已统一时，按对象切分，每对象一子代理，交付压缩简报、禁止倾倒原文；否则沿用 MECE 维度切分。用户澄清范围时，立即重发已派子任务，不沿用旧范围。子代理分批补交时，逐条标「修正/补强」——修正指推翻旧结论，补强指新增证据；更新报告只标注，不重写全文。

每个 sub-agent prompt 必须包含：

子任务边界、排除范围、成功标准
建议来源类型或工具类型
输出格式：2-3 句摘要、关键证据、完整精确 URL、可信度标记；只交付支撑关键结论的 URL，不列辅助命中大全
反方查询（见【搜索与证据】）的
```
工具 / 完整 query / 命中数 / 结论
```
必须写进交付，不能只写「已查」
「编码相关任务请先加载
```
karpathy-guidelines
```
skill 并在最终回复末尾给出 karpathy 证据小结。」

Only use when the score is 4-5, or the user explicitly requests in-depth research/multi-agent parallelism.

MECE Split : Select a primary dimension, add a secondary dimension if necessary.

Dimension	Applicable Scenarios
Object	Comparison of A/B/C solutions, products, frameworks, companies
Perspective	Technical, commercial, user, compliance, security perspectives, etc.
Time	History, current status, recent changes, trends
Source Domain	Official/source code, academic, first-hand data, community/media

After generating candidate sub-questions, merge overlapping items, fill in missing items, and finally retain 3-6 sub-tasks with clear boundaries. Each sub-task must be independently completable and together cover the user's question.

Delegation Rules : Independent sub-tasks are delegated to sub-agents in parallel; if no sub-agent tools are available in the current environment, execute manually in sub-task order and mark "not parallel" in the results. The main agent does not repeat full-scale searches, only performs summary, deduplication, conflict handling and final judgment.

When comparing multiple objects and evidence can be obtained independently for each object with unified comparison dimensions, split by object, assign one sub-agent per object, deliver compressed briefings and prohibit dumping original text; otherwise, use MECE dimension split. When the user clarifies the scope, re-send the assigned sub-tasks immediately, do not use the old scope. When sub-agents submit in batches, mark "correction/supplement" one by one - correction means overturning old conclusions, supplement means adding new evidence; update the report only by marking, not rewriting the full text.

Each sub-agent prompt must include:

Sub-task boundaries, excluded scope, success criteria
Recommended source types or tool types
Output format: 2-3 sentences of summary, key evidence, complete and accurate URL, credibility marker; only deliver URLs that support key conclusions, do not list all auxiliary hits
The
```
tool / complete query / number of hits / conclusion
```
of the counter query (see [Search and Evidence]) must be written into the delivery, cannot only write "searched"
"For coding-related tasks, please load the
```
karpathy-guidelines
```
skill first and provide a karpathy evidence summary at the end of the final reply."

4. 搜索与证据

4. Search and Evidence

先盘点当前可用的搜索类 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 工具、关键词和来源类型，并给出下一步建议。

First inventory currently available search MCP tools: web search, content crawling, official documents, code search, repository documents, structured data, etc.
Without expanding the user's scope, use multiple relevant MCP search tools as much as possible; the default target is 3 types, at least 2 types. Mark
```
single-source restriction
```
when only 1 type is available.
Prioritize highly credible sources: official documents, source code, release notes, standards, papers, first-hand data.
Communities, blogs, tutorials can supplement explanations, but cannot independently support key conclusions.
Independent requests are preferably parallel; each result must first extract the main judgment, then organize hierarchically according to "judgment / limitation / evidence". The final output must leave clear white space and be written into scannable short blocks; prohibit stuffing conclusions, limitations, evidence, sources, conflicts into the same paragraph or the same dense bullet point.
Record source tools, titles, complete and accurate URLs, release dates or versions. The complete and accurate URL must point to the specific page supporting the claim, source code permalink, paper DOI/landing page, release note, standard page or first-hand announcement; do not use search result pages, site homepages, short links, aggregation pages as substitutes.
Must retain complete and accurate URLs for key important information. Key important information includes: conclusion in key sections, basis for credibility markers, ranking/recommendation/risk judgment, conflicting sources, counter evidence, facts that will affect user actions or technical decisions.
Auxiliary sources only used for background understanding do not need to be fully listed in the final output; if not fully listed, explain "auxiliary sources have been searched but not listed one by one". Do not pile search hit results as bibliography to users.
Counter Query : Any key conclusion that will be marked
```
[verified]
```
must run at least one reverse query targeting the specific negative proposition or counter claim of the conclusion (e.g., original conclusion "X is faster than Y" → counter query "benchmark where Y is faster than X" "X performance degradation cases", not general "X criticism"). The actual counter query string and number of hits must be written into the evidence chain or a separate paragraph for review by the main agent and user. Not finding counter evidence can only be recorded as "no opposing evidence found" (may be due to insufficient query terms/language domain/tool coverage), cannot independently increase confidence; if substantial opposing opinions are found, downgrade the original conclusion to
```
[conflicting]
```
or
```
[likely]
```
.

If search returns empty, explain the tried MCP tools, keywords and source types, and give next-step suggestions.

5. 交叉验证

5. Cross-Validation

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

[verified]

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

[likely]

或更低。

证据形态轴，与上述标记正交：一手直读（源码/实测/原文）/ 文档声明（官方文档/规范）/ 推断（分析得出）。固定写法：置信度仍只用

[verified]

等 canonical 方括号标记；形态另写为

证据形态：一手直读/文档声明/推断

，不放进方括号、不造组合标记。

独立性判定：同一新闻稿转载、同一项目文档镜像、同一作者重复发布不算独立来源。区分一手与转引：3 个媒体转引同一份原始报道按 1 个独立来源算；只有追到不同的一手出处才算多源。无法追到一手出处或无法判定是否同源时，按 1 个独立来源计，并在标记后注

[来源独立性未验证]

。矛盾无法消解时，列出各方说法和证据，不把推测写成事实。

Marker	Conditions
`[verified]`	Key conclusions: Supported by 3+ independent sources, and at least 1 highly credible. General facts: Supported by 2+ independent sources, and at least 1 highly credible. If the conclusion depends on timeliness (subject is current status, version, policy, price, etc.), the source release date must also fall within the timeliness window corresponding to the topic (e.g., "current API behavior" requires sources within the past 12 months), otherwise can only be marked `[likely]`
`[likely]`	Supported by 2+ sources but does not meet the `[verified]` threshold (e.g., lacks highly credible sources, or only 2 sources for key conclusions)
`[single-source]`	Supported by only 1 source
`[conflicting]`	Substantial contradictions exist between sources
`[unknown]`	Insufficient evidence found

Key conclusions marked

[verified]

must also provide complete and accurate URL evidence; if unable to provide complete and accurate URL, even with multi-source summaries, can only be marked

[likely]

or lower.

Evidence Form Axis, orthogonal to the above markers: First-hand direct reading (source code/actual measurement/original text) / Document statement (official document/specification) / Inference (derived from analysis). Fixed writing: Confidence level only uses the 5 canonical square bracket markers in [Cross-Validation]; the form is written separately as

Evidence form: first-hand direct reading/document statement/inference

, not placed in square brackets or creating combined markers.

Independence Judgment : Reprint of the same press release, mirror of the same project document, repeated publication by the same author are not considered independent sources. Distinguish first-hand from secondary citation : 3 media citing the same original report count as 1 independent source; only tracking down different first-hand sources counts as multi-source. When unable to track down the first-hand source or determine whether it is homologous, count as 1 independent source, and note

[source independence not verified]

after the marker. When contradictions cannot be resolved, list the claims and evidence of all parties, do not write speculation as fact.

6. 输出格式

6. Output Format

关键 URL 引用规则

Key URL Citation Rules

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

Key important information can only retain short tag citations in the main text, e.g.,
```
[S1]
```
; complete and accurate URLs must appear in the adjacent source entries. Do Stuff the judgment section into dense long paragraphs just to insert URLs on the spot.
Each key conclusion defaults to citing 1-3 strongest sources; multi-source verification uses the most authoritative, independent, and closest to the original source as representatives, do not list all auxiliary sources.
If one URL supports multiple key conclusions, list it once in the source section and cite it with a short tag in the main text, e.g.,
```
[S1]
```
, but the entry corresponding to
```
[S1]
```
must include the complete and accurate URL.
If unable to obtain a complete and accurate URL, cannot mark
```
[verified]
```
; downgrade to
```
[likely]
```
,
```
[single-source]
```
or
```
[unknown]
```
, and explain the gap.
Only list all source URLs when the user explicitly requests a complete bibliography, audit list or research log; otherwise keep the minimum set of key sources.

基调：像给人讲清楚，不像填表

Tone: Explain to people clearly, not fill out a form

报告形态由话题和研究发现决定，不套固定章节。查得浅就短答，冲突多就展开讲冲突，流程复杂就画图。证据可追溯是底线，不是格式要求。

The report form is determined by the topic and research findings, do not use fixed chapters. Answer briefly if the research is shallow, expand on conflicts if there are many conflicts, draw diagrams if the process is complex. Traceable evidence is the bottom line, not a format requirement.

底线（缺一即违规）

Bottom Line (Violation if any is missing)

关键结论保留证据标记：只用【交叉验证】的 5 个 canonical（
```
[verified]
```
/
```
[likely]
```
/
```
[single-source]
```
/
```
[conflicting]
```
/
```
[unknown]
```
）。
```
[来源独立性未验证]
```
是附加注记，不算第 6 个标记。不造变体；冲突消解写
```
[conflicting]
```
，结果在正文说明。
关键结论能给出完整精确 URL；给不出就降级标记并说明缺口。
冲突、不确定性、证据缺口必须写出来，不为顺口抹平。

末尾一行：

轮次：<实际轮数>，判停：<a/b/c + 一句理由>

；大型再加

拆分方式：<主维度> × <次维度>，共 <n> 个子任务

。

报告末尾列验证边界：哪些一手直读、哪些文档声明、哪些推断/未实测。
反直觉或绕过类推断无实测时，显式标「未验证，非事实」。
用户明确反馈报告难读时，先用比喻+行为语言给主判断摘要；路径、行号、URL 等定位信息保留在独立证据子项，不替换、不删除。

Key conclusions retain evidence markers: only use the 5 canonical markers in [Cross-Validation] (
```
[verified]
```
/
```
[likely]
```
/
```
[single-source]
```
/
```
[conflicting]
```
/
```
[unknown]
```
).
```
[source independence not verified]
```
is an additional note, not the 6th marker. Do not create variants; write
```
[conflicting]
```
for conflict resolution and explain the result in the main text.
Key conclusions can provide complete and accurate URLs; if unable to provide, downgrade the marker and explain the gap.
Conflicts, uncertainties, and evidence gaps must be written out, do not smooth them out for fluency.

Last line:

Rounds: <actual number of rounds>, Stop: <a/b/c + one sentence reason>

; add

Split method: <primary dimension> × <secondary dimension>, total <n> sub-tasks

for large-scale research.

List verification boundaries at the end of the report: which are first-hand direct reading, which are document statements, which are inferences/not actually measured.
Mark explicitly "unverified, not a fact" for counterintuitive or bypass inferences without actual measurement.
When the user explicitly feedbacks that the report is hard to read, first give the main judgment summary with metaphors + behavioral language; positioning information such as paths, line numbers, URLs are retained in independent evidence sub-items, not replaced or deleted.

图例块（开头必放）

Legend Block (Must be placed at the beginning)

报告开头列本报告实际用到的标记，每个给一句白话。术语同理：正文每个技术词，要么在图例里，要么首现处一句白话。

List the markers actually used in this report at the beginning of the report, with a plain language explanation for each. The same applies to terms: each technical term in the main text must either be in the legend or have a plain language explanation at its first appearance.

面向不熟读者

For Unfamiliar Readers

用户通常对话题了解不深。讲功能和影响优先，不默认读者懂实现细节。自检：不查资料，能否抓住主判断和理由。

Users usually have limited understanding of the topic. Prioritize explaining functions and impacts, do not assume readers understand implementation details. Self-check: Can you grasp the main judgment and reasons without checking materials?

留白与节奏

White Space and Rhythm

结论、限定、证据分开放，一段只讲一件事，不揉长句。
长短句交错，短句为主。读起来像研究笔记，不像流程表。
合适就用 mermaid 画图（流程、角色关系、时间线），图只画关键结构，不放全部细节。
主判断在前，限定和例外跟在后，别藏在段落中间。

Separate conclusions, limitations, and evidence, only talk about one thing per paragraph, do not mix long sentences.
Alternate long and short sentences, focus on short sentences. Read like research notes, not a flow chart.
Use mermaid diagrams when appropriate (processes, role relationships, timelines), only draw key structures in diagrams, do not include all details.
Put the main judgment first, followed by limitations and exceptions, do not hide them in the middle of paragraphs.

反例（禁止）

Counterexamples (Prohibited)

信息密块：一段同时承担结论、限定、证据、来源、冲突。
官腔八股：「必须指出」「值得注意的是」「综上所述」这类空壳连接。
自造标记变体（如
```
[conflicting→已消解]
```
）。
术语只抛不解释。

来源小节规则：

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

Information blocks: One paragraph simultaneously contains conclusions, limitations, evidence, sources, conflicts.
Bureaucratic jargon: Empty connecting phrases such as "It must be pointed out", "It is worth noting", "In summary".
Self-created marker variants (e.g.,
```
[conflicting→resolved]
```
).
Throwing out terms without explanation.

Source Section Rules:

The source section only lists key sources by default. Key sources refer to sources that directly support conclusions in key sections, credibility markers, conflict judgments, counter evidence, ranking/recommendation/risk judgments. Ordinary background, repeated reprints, weakly relevant tutorials, search hit pages do not enter the source section, unless the user requests a complete source list.
Each source entry must include a complete and accurate URL;
```
URL/Source
```
cannot only write domain names, homepages, search pages, short links or non-directly locatable descriptions such as "official documents".
For sources that support key conclusions or are repeatedly cited, note
```
[Credibility high/medium/low, bias explanation]
```
in a single line (e.g., "[Credibility high, vendor self-statement, has interest relationship]"). The bias explanation must specify the specific bias direction or interest relationship, uninformative annotations such as "may have bias" "neutral stance" are not accepted. Not required for ordinary auxiliary sources.
For volatile content supporting
```
[verified]
```
key conclusions (news pages, policy pages, commercial statements, personal blogs, etc.), prefer to submit
```
https://web.archive.org/save/<URL>
```
for archiving and link the archived URL in the citation; mark "not archived" and the reason if archiving is not possible. Stable official documents, paper DOIs, source code commit/permalink do not require mandatory archiving.

边界情况

Boundary Cases

保存路径：用户要求保存时写入

docs/research/YYYY-MM-DD-<topic>.md

，否则只在对话中输出。工具不足、sub-agent 失败、结果重叠等情况，按本 skill 通用原则降级（标注限制、保留可用结果、去重后保留最权威来源）。

Save path: Write to

docs/research/YYYY-MM-DD-<topic>.md

when the user requests saving, otherwise only output in the conversation. In cases such as insufficient tools, sub-agent failure, overlapping results, downgrade according to the general principles of this skill (mark restrictions, retain available results, retain the most authoritative sources after deduplication).

何时切换出本 skill

When to Switch Out of This Skill

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

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

This skill handles multi-source research and cross-validation. Switch to a more appropriate tool or sub-agent first when the following signals appear, do not force it in this skill:

Signal	More Appropriate Handling Method
Need to check repository code implementation, call relationships, local file structure	Hand over to code retrieval tools or code exploration sub-agents (grep / read / ast types)
Need to check npm/pip/cargo package API, official documents, external library behavior	Hand over to document/web retrieval tools or document retrieval sub-agents
Involves architecture judgment, multi-system trade-offs, technical selection decisions	Hand over to consultant-type/secondary review-type sub-agents, or the main agent clearly states reasoning boundaries
Need to perform calculations, data processing, command verification	Hand over to shell/script execution tools
The user wants coding/modifying code instead of research	Exit research mode, hand over to the implementation stage