多视角交叉验证深度调研 は何をしますか？
一次扁平搜索回答的是“网络上关于 X 说了什么”。本技能回答的是“X 的哪些部分有独立来源相互印证，哪些部分仅依赖单一来源”。
其机制，抽象自斯坦福 STORM（已通过 stanford-oval/storm 源码验证）：
(视角 × 预算) → 检索 → (证据 | 拒绝声明) → 回写 → 再次提问
重复 M 轮，N+1 个独立通道，最后一次性收敛
↓
working-report.md (机制可见，审计追踪)
↓
reader-report.md (机制不可见，最终产品)
↓
对用户的回复 = reader-report.md 全文，不增不减
全部价值集中在大多数调研尝试会跳过的四个地方：视角必须来源于模型外部、每个问题必须落地为一次真实的搜索、收敛必须被评分而非假设、评分后的结果必须经得起一个从未参与调研的人的审视。
触发条件
当用户说出以下任意内容时触发本技能（用户无需点名本技能）：
- 显式标记：深度调研 / 深度研究 / 深度分析 / 深入研究 / deep-research / deep research / deep dive / 深入调研。
- 质量副词类请求：仔细调研 / 认真调研 / 调研得仔细一点 / 多查几个来源 / 别只给一个来源 / 要确定性结论 / 确定性调研 / 查得踏实一点 / 帮我彻底搞清楚 X / 把 X 查透 / X 到底怎么样 / 不要泛泛而谈。
- 方法类请求：多维度调研 / 多视角 / 全景分析 / 正反双方梳理 / 交叉验证 / 多方观点对比 / 交叉比对来源 / 标注“哪些结论有多来源印证、哪些只有单一来源”。
- 隐含形式：任何用户暗示一次性回答不够充分的调研请求。
重叠规则：anysearch 和 agent-reach 负责通用型 调研/搜索/查一下（它们是检索后端，本技能将它们作为工具使用）。一旦请求带有 深度/仔细/确定性/交叉验证 等限定词，本技能接管该请求，并在其通道内驱动这些后端。拿不准时优先使用本技能：过度调研的成本是时间，调研不足的成本是一个自信的错误答案。
不适用于：一次性快速查证、“查一下这个 API 是什么”、或单页面查询。
两个工件
步骤 1–5 生成一份工作底稿：一个机制可见的工件，其中“通道”、“A–E等级”、“查询”、“轮次”和正交性表述是全部要点。它是正确的，但对于未参与运行的人来说不可读。
步骤 6 生成读者报告：你实际交付的东西。相同的证据，相同的诚实，相同的来源——但机制消失了，结构围绕读者做出决策所需的信息重建。
保留两个工件，绝不能让步骤 6 替代步骤 5。
- 工作底稿是审计追踪：它让你（或后续检查）能够验证没有声称被漂移、没有等级被提升、没有空行被记忆填充。它被写入一个文件（例如
working-report.md），绝不粘贴到回复中。 - 读者报告是交付物，保存为
reader-report.md：它是一个人可以在一次阅读中真正使用的东西，无需术语表。
交付规则（硬性）：对用户的最终回复是 reader-report.md 的逐字、完整内容——不加、不改、不包裹任何东西。参阅 §交付。没有开场白（“我做完了，下面是报告”），没有结束语，没有摘要，没有验证行，没有描述你做了什么或存在哪些文件的评论。读取该文件并完全按照其字节作为你的消息正文。任何你想补充的内容都属于工作底稿，而不是回复。
将两个文档合并为一个会在两个方向上失败。保留机制则读者会避开它；丢弃机制而不应用步骤 6 的规则则交叉验证会悄悄消失——读者无法再区分“四条独立路径在此汇聚”和“一次幸运命中被重复”，而这正是本技能的全部意义。
不可协商的规则
- 视角是读取出来的，不是发明出来的。 你必须从你获取到的真实工件中推导出它们（现有报告、竞争文档、目录、论坛分类、监管标题）。绝不要仅仅问自己“关于这个的三个角度是什么”。
- 每个问题必须产生一次搜索。 无法分解为能命中真实来源的查询的问题不是研究，是推测。如实说明并放弃它。
- 运行期间通道之间互不通信。 独立性是唯一让一致变得有意义的东西。收敛仅在最后发生一次。
- 拒绝声明是一个信号，不是一次失败。 当一个通道的搜索空手而归时，记录下来并让它引导下一个问题。不要用参数化记忆填补空白。
- 报告每个结论的印证等级。 “三个独立来源一致同意”和“一个博客这么说”绝不能在读者报告中看起来一样。
- 在读者报告中机制不可见，但证据不可见。 读者绝不需要知道什么是通道；读者必须始终能够问“谁说的，还有别人说过吗”。
- 回复就是读者报告，不加改动。 给用户的最终消息是
reader-report.md的完整副本——没有开场白，没有结束语，没有摘要，没有门控行，没有评论。如果你想让用户看到不同的东西，修改文件然后重新输出；绝不要在输出过程中编辑。
步骤 1 — 锚定视角
不要从主题开始。从这个世界已经如何结构化这个主题开始。
获取 2–4 个真实工件，你可以借用它们的 结构：
| 主题类型 | 从何处读取结构 |
|---|---|
| 实体、产品、事件 | 其维基百科页面章节 + 2 个相邻/竞争页面的章节 |
| 市场、行业 | 两份分析师报告目录、监管机构备案索引、会议议程 |
| 技术方法 | 上游文档的侧边栏、两个竞争项目的 README 标题 |
| 争议性议题 | 最强支持方文章的标题、最强反对方文章的标题 |
| 个人、组织 | 其自身网站结构 vs. 批评性报道的结构 |
然后推导出 3 个通道（加上下面的通道 0）。每个通道是 一个不同的关心该主题的理由，而不是一个不同的子主题：
- ✅ “一个必须在生产中操作这个东西的人，关心故障模式和成本”
- ✅ “一个经济上暴露在这个决策中的人，关心谁买单”
- ❌ “技术方面” / “经济方面” / “社会方面”——它们是用三顶帽子戴同一个旧观念
在花费预算之前检查正交性。 对于每一对通道，写一句话：“通道 A 会问 X；通道 B 会问 X 吗？” 如果任意一对的答案为“是”，则合并它们并重新推导。如果两个通道会产生相同的前三个问题，它们就是一个通道。这个检查是整个流程中最高杠杆率的一分钟——跳过它，你会得到同一搜索的四次复述。
通道 0 是强制性的：一个“需要基本无争议事实、日期、定义、数字”的普通通道。它是覆盖底线，防止所有其他通道因专业化而变得不相关。
记录锚定工件和正交性句子；它们将放在工作底稿（步骤 5）中，作为视角集合的溯源信息。它们不会出现在读者报告（步骤 6）中。
步骤 2 — 在花费之前设定预算
明确写下预算，然后遵守它：
| 项目 | 默认值 | 理由 |
|---|---|---|
| 通道数 | 3 + 通道 0 = 4 | 更多通道会稀释而非多样化；4 是经验甜点 |
| 每通道轮次 | 3 | 足够一次追问；超出后通道通常会迷失方向 |
| 每问题查询数 | 2–3 | 一个查询是彩票，五个是霰弹枪 |
| 每查询结果数 | 3–5 | 阅读前几个，不要囤积 |
| 每轮证据字数 | ~1000 | 迫使自己只保留支撑性强的句子 |
| 通道上下文字数 | ~2500 | 保留近期细节，丢弃过时细节 |
| 并行通道数 | ≤4 | 并发是重点；速率限制是约束 |
总检索预算 ≈ 4 × 3 × 3 = 36 次查询。当预算用完时，停止搜索并开始收敛。预算耗尽是一个设计好的事件，不是意外。
步骤 3 — 并行、独立地运行通道
在同一轮次启动所有通道——尽可能使用并行子代理（subagent / workflow），每通道一个。每个通道获得：主题、通道描述、预算和以下规则。使每个通道对其他通道不可见。
在通道内部，每轮：
- 一次只问一个问题，使用通道的视角。不可选的约束：
- 提问关于主题，而不是邻接主题（防漂移）
- 不要重复已问过的问题（防重复）
- 如果没有值得再问的了，停止该通道——不要为了填满轮次而制造问题
- 将问题分解为 2–3 个搜索查询。 不能分解的问题就是坏问题；重写它。
- 搜索，然后实际获取页面内容。 摘要片段是线索，不是证据。对任何承载重点的页面获取完整内容。
- 仅基于获取到的东西回答。 每个句子可追溯到一个 URL。如果来源没有回答它，逐字写下拒绝声明：“未找到该问题的来源”。
- 将本轮结果写回通道上下文——始终保留问题骨架，仅保留最近几轮的答案细节。这使得下一个问题成为 追问 而非 重启。
为每个通道维护一份日志，记录每个检索到的来源：url、title、找到它的查询、轮次，以及它支持的具体声称。query 和 round 字段是每个人都会忘记、而步骤 4 又必需的字段。
拒绝循环：当一轮的搜索空手而归或毫无价值时，这会被纳入通道上下文，并且下一个问题必须避开这个方向。永远不要用你已经相信的东西来填补漏洞。
步骤 4 — 收敛，并评分收敛度
现在，只有现在，把各个通道汇集在一起。
4a. 按来源合并，而不是按摘要合并。 用 URL 键控每一条证据（规范化：去除追踪参数、片段、尾部斜杠）。两个通道中同一个 URL → 一个来源，合并它所支持的声称。这是第一次也是最便宜的收敛，你会在其中发现两个通道独立地落在了同一个页面上。
4b. 构建声称×通道矩阵。 将提取出的声称聚类成原子化断言（每行一个事实）。对于每个声称，记录哪些通道以及多少不同来源支持它：
声称 | 支持 URL 列表 | 不同来源数 | 找到它的通道 | 冲突
4c. 评分印证度。 这是交付物的脊椎：
| 等级 | 条件 | 陈述方式 |
|---|---|---|
| A — 收敛 | 被 ≥2 个独立通道发现，≥2 个不同域名 | 直截了当地陈述 |
| B — 确证 | ≥2 个不同来源，同一通道 | 附上来源陈述 |
| C — 单源 | 仅 1 个来源 | 陈述 + 标记 单源 |
| D — 争议 | 可信来源意见相左 | 呈现双方，不做平均 |
| E — 未找到 | 已搜索，未发现任何内容 | 明确说明；不要用记忆填充 |
只有通道真正独立时，声称才能是 A 级——如果两个通道都只是搜索了主题名称并都得到了维基百科页面，那是一个通道两次，不是收敛。
4d. 加权，不要计数。 按域名聚类，而不是按 URL。十篇引用同一份新闻稿的页面是一个来源。同一组织的两个页面是一个来源。注意上游依赖关系（涉及到、根据）——来自回声的印证不是印证。
4e. 明确寻找冲突。 STORM 的已知失败模式不是幻觉，而是连接了仅仅共同出现的事实。在写作之前，扫描矩阵中那些其支持来源并未实际连接所涉及两件事的声称。将任何此类连接标记为 inferred-by-me，绝不要作为有来源的声称。寻找 D 级行，确保每一行在报告中可见，而不是被悄悄化解。
步骤 5 — 报告（工作底稿，机制可见）
写入一个 Markdown 文件。默认名称：working-report.md（如果用户或调用方指定了其他输出目录或文件名，则遵守——在开始时设置 WORKING = <that path> 和 READER = <report path>，并在后续运行中使用这两个变量，以便回复发出正确的文件）。
必需结构：
# <主题>
## 印证摘要
<计数：收敛 / 确证 / 单源 / 争议 / 未找到 的声称数>
## 视角选择方式
<实际获取的锚定工件 + 正交性句子 + 通道列表>
## 发现
### <主题>
<散文；每个声称内联标记 A/B/C/D/E；引用编号 [n]>
## 争议点
<每个 D 级行，双方，附上来源>
## 单源声称
<每个 C 级行——将这些视为需要验证的线索，而非事实>
## 已搜索但未找到的内容
<E 级行，附带使用的查询>
## 来源
[n] <url> — 由 <通道> 发现，第 <k> 轮，通过查询 "<q>"
在来源列表中保留 由通道 / 轮次 / 查询发现 的溯源信息。记录它几乎不花成本，它是唯一能让读者区分“四条独立通道在此汇聚”和“一次幸运命中被重复”的东西。
这是你用来审计的工件，不是你要交付的工件。 继续执行步骤 6。
步骤 6 — 润色为读者报告（机制不可见）
将结果写入 reader-report.md（或步骤 5 中固定的 <READER>）。作为一次独立的传递运行，使用全新的上下文——一个只接收工作底稿的子代理，不接收通道提示、通道日志、或你的推理。一个见过机制的传递会泄露机制。
6a. 将每个机制术语翻译为读者语言
这是一个固定的映射，不是判断性决策。不要发明替代方案。
| 工作底稿 | 读者报告 |
|---|---|
| 车道 | 视角 |
| A 级 — 收敛 | ✅ 多来源印证 |
| B 级 — 确证 | ✅ 已确证（单视角内） |
| C 级 — 单源 | ⚠️ 单一来源 |
| D 级 — 争议 | 🔄 观点分歧 |
| E 级 — 未找到 | ❌ 未找到来源 |
| 正交性句子 | 省略 |
| 预算 | 省略 |
| 拒绝声明（措辞一致） | 保留为直接陈述 |
6b. 语言属性
- 不要使用“深入调研揭示”或“本报告”——读者看到的就是事实本身
- 每个标有 C 或 D 级的陈述必须精确：
- C 级：附加“此发现仅基于 [来源]。”
- D 级：呈现两个立场，例如“组织 A 声称 X；组织 B 声称 ¬X。两者均引用了可验证的数据，但数据指向相反的方向。”
- 为 A 级声明一个总括来源，列出 B 级中用于建立可信度的多个来源
- 不要使用模糊的连接词（“此外”、“同时”、“有趣的是”）。如果某样东西值得写进去，它应该是因为它支撑一个思考、是一个单独的视角、或者建立了一个关联——而不是因为它是一个文学装置。
6c. 结构
# <主题>
## 执行摘要
<解决最紧迫问题的开头段落：读者需要知道什么？A 级声明首先。>
## 已建立的事实
### <子树>
<文本，每条声明都带有其等级标签，但不是机制标签。来源内联：`[来源名称]`。>
## 需要注意的声明
### <声明>
### <声明>
...
单源项目（C 级）和争议点（D 级）并列于此。不是作为事后考虑，而是作为读者应该考虑是否进一步调查的问题。
## 来源
[来源名称] <url> — *<获取日期，1–2 句上下文>*
6d. 来源作为信任锚点
在读者报告中，来源是对独立获取的引用，而不是对过去检索的引用。
- 将包含名称的机构（一个被引用的组织、一个演讲者的姓名、一个网站的名称）用作锚点。读者应当始终能够从外部定位该来源，而无需依靠于你。
- 不要在读者报告中包含其唯一价值是允许回溯到工作底稿的来源编号。每个来源必须是一个读者可以独立打开的东西。
- 你不需要在那里列出所有 36 条 URL。列出建立 A 级声明所必需的那些，以及来自 C 级或 D 级行的那些。其余的在
working-report.md中。
交付
你在此次运行结束时给用户的回复是 reader-report.md 的完整、逐字、未更改的内容。无例外：
- ❌
“好了，下面是读者报告” - ❌
“我应该写 summary.md 指出关键发现吗？” - ❌
“本报告由多视角深度调研系统生成” - ❌
“注意：读者报告的关键输入位于 working-report.md” - ❌ 标题或元数据被更改、简短版本被粘贴、来源被省略
- ❌ 任何形式的开场白、结束语、解释性序言、脾气、内容警告、注解、或你做的事情的日志行
任何错误：如果文件不在那里、内容是空的、你意识到你无法在不违反规则 1–4 的情况下完成任务、或任何其他问题——用英文写一个单句错误消息并停止。不要尝试“最好地完成”。不要用能力不足来伪装。
用户应始终仅收到 reader-report.md 中存在的文本。
参考
stanford-oval/storm：原始研究，验证了视角外化和多通道独立收敛是提高研究真实性的结构设计选择。- 正交性句子的实践：源自多体空间分析，易于通过给定假设检查——如果两对视角会产生相同的前三个问题，就合并它们。
- 来源加权（按域名聚类）：防止单一组织在单个来源下掩盖其所有产出。
- 在实践中，预算限制等同于
4 × 3 × 3 = 36次搜索查询。如果时间或上下文窗口不允许达到此限制，请相应减少轮次，而不要减少通道数或每个查询的来源数。 - 这种方法的另一种名称，有时在需求中看到：“多视角交叉验证”、“反硝化检索”、“读者最终报告”。使用这些名称可能会帮助其他人找到这项技术。