多視角交叉驗證深度研究
一次普通的搜尋回答「網路上關於 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、找到它的查詢、輪次，以及它支持的確切主張。查詢和輪次欄位是每個人都會忘記、但步驟 4 需要的欄位。
未找到迴圈：當一輪的搜尋結果為空或無用時，將此資訊記入通道上下文，下一個問題必須遠離它。永遠不要用你已經相信的內容來填補漏洞。
步驟 4 — 收斂，並對收斂進行評分
現在，也只有現在，將所有通道匯合在一起。
4a. 按來源合併，而非按摘要。 每個證據以 URL 為鍵（標準化：移除追蹤參數、片段、尾部斜線）。兩個通道有相同 URL → 一個來源，合併其支持的主張。這是最初且成本最低的收斂，也是你發現兩個通道獨立地找到了同一頁面的時刻。
4b. 建立主張 × 通道矩陣。 將提取出的主張聚類為原子陳述（每個事實一行）。對於每個主張，記錄哪些通道以及多少個不同的來源支持它：
claim | supporting URLs | distinct sources | lanes that found it | conflicts
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 = <該路徑> 和 READER = <報告路徑>，並在後續執行中使用這兩個變數，以便回覆輸出正確的檔案）。
必要結構：
# <主題>
## 收斂摘要
<計數：N 個主張收斂 / 確證 / 單源 / 爭議 / 未找到>
## 視角選擇方式
<實際抓取的錨定產出物 + 正交性句子 + 通道列表>
## 發現
### <主題>
<散文；每個主張內聯標記 A/B/C/D/E；引用格式為 [n]>
## 爭議點
<每個 D 級行，雙方觀點，附帶來源>
## 單一來源主張
<每個 C 級行——將這些視為需要驗證的線索，而非事實>
## 已搜尋但未找到的內容
<E 級行，以及使用的查詢>
## 來源
[n] <url> — 由 <通道> 找到，第 <k> 輪，經由查詢 "<q>"
在來源列表中保留 found by lane / round / query 的來源資訊。記錄它的成本幾乎為零，而它是讓讀者能夠分辨「四個獨立通道在此收斂」與「一次幸運命中被重複」的唯一依據。
這是供你審計的產出物，不是你交付的產出物。 繼續進行步驟 6。
步驟 6 — 潤色為讀者報告（機制不可見）
將結果寫入 reader-report.md（或按照步驟 5 中固定的 <READER>）。使用全新的上下文作為一個獨立階段來執行——一個只接收工作底稿的子代理，不接收通道提示、通道日誌或你的推理過程。一個看過機制的階段會洩漏機制。
6a. 將每個機制術語翻譯為讀者語言
這是一個固定的對應表，不是一個判斷問題。不要發明替代方案。
| 工作底稿 | 讀者報告的表述 |
|---|---|
| 通道 | 觀點 / 角度 |
| 通道 0（事實） | 基本事實 |
| 輪次 | 追問輪次 |
| 正交性句子 | 我們選擇此視角的理由 |
| A — 收斂 | ✅ 多方獨立確認 |
| B — 確證 | ✅ 多來源一致 |
| C — 單源 | ⚠️ 僅單一來源，建議進一步查證 |
| D — 爭議 | 🔀 存在爭議，呈現雙方觀點 |
| E — 未找到 | ❌ 經搜尋未找到相關資訊 |
6b. 重建敘事結構
不要按照通道組織報告。按照主題組織報告。如果三個通道都討論了安全性，那麼報告中應該有一個「安全性」章節，匯集了所有三個通道的證據，並逐句標明收斂等級。
6c. 每個主張保持可追溯性
讀者報告中的每個事實陳述都必須伴隨著一個引用。層級 A 和 B 的主張應顯示多個引用（例如 [1][3][7]）。層級 C 的主張顯示一個引用並加上「僅單一來源」的標記。層級 D 的主張顯示「支持方：[2][5]；反對方：[4][8]」。層級 E 的主張應如此表述：「對於 [問題]，在檢索 [特定查詢] 後未找到公開來源」。
6d. 語言和風格
- 使用適合受過教育的非專業人士而非領域專家的語言。解釋專業術語。
- 避免任何暗示內部過程的語言：「我們的調查顯示」、「在多輪分析中」。直接陳述事實。
- 使用「證據收斂等級」一詞；不要使用「通道」或「輪次」。
- 在適當的地方使用表格來總結跨視角的一致性和差異。
讀者報告是完全自足的。 如果一個主張需要特定領域的知識才能評估，請在報告中提供該知識。讀者應該能夠理解、評估並基於報告做出決策，而無需查閱外部資料（來源連結本身除外）。來源連結是用來驗證的，不是用來填補報告中遺漏的上下文。
6e. 對抗報告中出現的幻覺
在最終輸出前，進行一項特定的審查：刪除所有來源引用，然後問「這個文件本身是否包含任何聽起來像是由人為構想而非基於證據的主張？」如果答案是肯定的，修改該主張，使其與證據的強度（或缺乏證據）更緊密地契合。
交付：最終回覆
最終使用者回覆的內容是 reader-report.md 的全部文字。逐字逐句。前面沒有「以下是報告」，後面沒有「製作完畢」。
也就是說：
- ✅ 正確：輸出寫入
reader-report.md的全部內容。 - ✅ 正確：如果使用者指定了自訂輸出路徑，輸出寫入
READER變數所設定的檔案。 - ❌ 錯誤：輸出一個包裹著「我已經完成了深度研究，使用了 4 個視角和 3 輪搜尋」的內容。全部放入工作底稿。
- ❌ 錯誤：在報告之前詢問使用者是否要繼續。步驟 5 完成時，你擁有你需要的一切。
- ❌ 錯誤：假設如果
reader-report.md與working-report.md類似，你可以節省時間。這正是導致報告中保留機制痕跡的原因。
工作底稿仍在檔案系統中。使用者可以詢問關於它的問題。只是不要在你未經請求的回答中包含它。
永遠不要在回覆層級添加引言、結尾或元評論。 如果你覺得必須要說些什麼，將其添加到工作底稿中，或修改讀者報告的內容。回覆的位元組必須與 reader-report.md 完全一致。
附錄：與其他技能的互動
| 技能 | 關係 |
|---|---|
anysearch / agent-reach | 這些是此技能的檢索後端。此技能在其通道內呼叫它們的搜尋功能。當請求帶有深度/仔細/確定性限定詞時，此技能擁有所有權。 |
create / write / file | 用於寫入 working-report.md 和 reader-report.md。 |
read / fetch | 用於取得錨定產出物和實際頁面內容。 |
subagent / workflow | 用於並行執行通道。 |