ref-verify — 參考文獻幻覺防護

此技能旨在防止的特定失敗模式：LLM 根據訓練資料回憶論文內容，而非根據摘要實際內容。論文被賦予了不存在於其中的發現，或被引用以支持原文中從未出現的主張。解決方法是始終如一地應用一條規則：

關於論文的所有內容陳述都必須來自即時獲取的來源——頂層/標題性主張使用摘要，機制/實作/程序性主張則需使用全文——逐字引用或改寫。如果無法獲取所需來源，必須明確說明，絕不能用回憶的描述來填補空缺，也絕不能讓主題相關的摘要匹配來代替機制層級的主張。

模式選擇

在開始任何工作前先選擇模式。選擇會控制成本和深度。

使用者提供 DOI 進行合理性檢查？
  └─ ≤10 篇參考文獻 → 全部快速篩查
  └─ >10 篇參考文獻 → 全部快速篩查；僅對 MISMATCH/DEAD 結果進行完整審計

使用者說「找關於 X 的論文」或「引用支持主張 Y 的論文」？
  └─ 完整審計（從頭開始搜尋需要內容驗證）

使用者說「驗證/檢查我的參考文獻列表」或進行投稿前審計？
  └─ ≤5 篇參考文獻 → 全部完整審計
  └─ >5 篇參考文獻 → 先全部快速篩查；對 MISMATCH/DEAD 結果以及任何
                       因特定事實主張而被引用的參考文獻進行完整審計

使用者正在內文中撰寫並從記憶中新增單一引用？
  └─ 至少快速篩查；若要引用特定主張則進行完整審計

昂貴的部分是完整審計（五層、來源深度的證據擷取）。快速篩查每篇論文約需 5 秒。僅在任務確實需要內容驗證時才升級到完整審計。

可執行的引擎

將其作為技能層級的工作流程使用。此路徑不需要建立或要求 MCP。 CLI 是一個執行引擎，技能可以從終端機呼叫；手動協定仍然是備用方案，也是 CLI 尚未涵蓋層級的真相來源。

CLI 可用性檢查

在進行基於 DOI 的檢查前，檢查可執行的引擎是否可用：

ref-verify --help

npx skills add 不會 pip-install Python CLI。如果控制台腳本不可用，請不要將其視為驗證結果。

如果控制台腳本不可用，但儲存庫原始碼存在，請使用：

PYTHONPATH=src python3 -m ref_verify.cli --help

如果兩個指令都失敗，請遵循下方的手動備用協定。不要假裝 CLI 已執行，也不要憑記憶虛構結果。

CLI 優先工作流程

當使用者提供 DOI 或詢問基於 DOI 的摘要是否支持特定事實主張時，優先使用 CLI。目前的 CLI 範圍是 CrossRef 元數據驗證加上 DOI 綁定的摘要主張檢查。主張檢查首先使用 CrossRef，然後在 CrossRef 沒有摘要時使用 DOI 綁定的 OpenAlex、Semantic Scholar 和 PubMed 作為備用。

CrossRef 元數據篩查：

ref-verify verify-doi <doi> \
  --title "<提供的標題>" \
  --first-author <提供的第一作者姓氏> \
  --year <提供的年份> \
  --json

原始碼檢出備用：

PYTHONPATH=src python3 -m ref_verify.cli verify-doi <doi> \
  --title "<提供的標題>" \
  --first-author <提供的第一作者姓氏> \
  --year <提供的年份> \
  --json

verify-doi 僅在 PASS 時以 0 退出；WARN 和 REJECT 返回非零值。僅提供 DOI 時，會檢查 CrossRef 是否解析成功，但不足以通過元數據驗證。

處理結果：

PASS：報告元數據匹配，然後在所選模式需要時繼續執行第 4 層 DOI 登陸頁面解析和第 5 層撤稿檢查。
WARN：報告遺失或薄弱的元數據，然後繼續手動備用處理遺失的層級，而不是靜默接受該參考文獻。
REJECT：停止使用該引用作為已驗證；報告不匹配，並要求更正的 DOI 或引用，除非使用者明確要求替代方案。

針對 DOI 摘要的單一主張檢查：

ref-verify check-claim <doi> --claim "<具體事實主張>" --json

原始碼檢出備用：

PYTHONPATH=src python3 -m ref_verify.cli check-claim <doi> --claim "<具體事實主張>" --json

預設情況下，check-claim 首先使用 CrossRef。如果 CrossRef 沒有摘要，它會嘗試 DOI 綁定的 OpenAlex、Semantic Scholar 和 PubMed 備用來源。使用 --source crossref、--source openalex、--source semantic-scholar 或 --source pubmed 進行特定來源的除錯。明確選擇非 CrossRef 來源會繞過 CrossRef，因此可以隔離 OpenAlex、Semantic Scholar 或 PubMed 的失敗。

處理結果：

ACCEPT：引用 CLI 的證據，並繼續任何所需的手動 DOI 解析、第二來源存在性和撤稿層級。
WARN 或 PARTIAL：報告所選摘要來源支持了什麼以及未支持什麼，然後在需要更多層級時繼續手動備用。
UNVERIFIABLE：來自嘗試過的 CLI 來源沒有可用的、受信任的、DOI 綁定的摘要證據。繼續下方的手動備用鏈，而不是將主張視為被拒絕或支持。

CLI 的 ACCEPT 僅是摘要層級的證據。如果主張描述了機制、實作或程序，請不要將該結果提升為完整審計的裁決；在第 3 層對主張進行分類，並首先取得所需的全文證據。

對於 JSON 輸出，使用 abstract_source、source_attempts 和 error_code 來決定下一步：

CLAIM_SUPPORTED：找到明確的摘要支持。
CLAIM_NOT_EXPLICIT：摘要可用，但主張未得到明確支持。
CLAIM_AMBIGUOUS：存在數值證據或背景資訊，但綁定不明確。
NO_ABSTRACT：嘗試過的 DOI 綁定來源未提供摘要文字。
DOI_NOT_FOUND：所選來源未找到 DOI 綁定的記錄。
DOI_MISMATCH：主要或明確選擇的 DOI 綁定記錄與請求的 DOI 不匹配。
SOURCE_API_ERROR、SOURCE_TIMEOUT、SOURCE_RATE_LIMITED、SOURCE_UNSUPPORTED：來源查詢失敗、超時、被速率限制或無法使用。

CLI 不會取代第 4 層的 DOI 登陸頁面解析、第 5 層的雙來源存在性檢查或撤稿檢查。在所選模式需要時，繼續手動協定處理這些層級。

快速篩查 — 元數據 + DOI 合理性檢查

當使用者提供 DOI 或完整引用並想要進行合理性檢查時使用。

訪問 CrossRef：https://api.crossref.org/works/{DOI}
將返回的標題 + 第一作者姓氏與使用者提供的進行比較
擷取 https://doi.org/{DOI} — 確認它解析成功並指向正確的論文
每篇參考文獻報告一行：

Smith et al. (2021) 10.1234/example — PASS (標題/作者匹配，DOI 解析成功)
Jones (2019) 10.5678/other — MISMATCH (CrossRef：Jones & Lee 2019，非 Jones 單獨)
Kim (2023) 10.9999/fake — DEAD DOI

升級到完整審計的情況：DOI 解析到不同的論文、任何欄位不匹配，或使用者為特定事實主張引用。

完整審計 — 適用於文獻搜尋或投稿前檢查

在以下情況使用：搜尋論文以支持某個主張，或進行最終的引用掃描。

每篇論文執行所有五層。各層按它們能捕捉到的問題排序——不要跳過。

第 1 層 — 存在性

獨立搜尋兩個來源：

CrossRef：https://api.crossref.org/works?query.bibliographic={title+author}&rows=5
Semantic Scholar：https://api.semanticscholar.org/graph/v1/paper/search?query={title+author}&fields=title,authors,year,externalIds,abstract&limit=5
預印本使用 arXiv：https://export.arxiv.org/api/query?search_query=ti:{title}&max_results=3

僅在兩個來源中標題基本匹配且第一作者姓氏一致時，論文才被確認。

雙來源命中 → CONFIRMED
單來源 → SINGLE-SOURCE ⚠ — 謹慎進行，在輸出中註明
零來源 → NOT FOUND ✗ — 停止；清楚報告；不要虛構替代品

第 2 層 — 元數據

從已確認的來源中提取並進行比較：標題、所有作者（姓氏）、年份、期刊全名、DOI、卷/頁碼（如果缺失則標記為 [NOT IN SOURCE]）。如果任何欄位在來源之間不同，顯示兩者——不要靜默選擇一個。

第 3 層 — 內容可追溯性 ← 最重要的層級

這是此技能核心價值所在。目標不僅是「這篇論文是否存在」，而是「這篇論文是否真的包含被歸因於它的主張」。

步驟 0 — 對主張進行分類。

在獲取任何內容之前，對正在驗證的主張進行分類：

頂層/標題性主張 — 摘要通常會陳述的發現（整體結果、頂層數字、一般結論）。對於此類別，僅摘要證據是合法的真相來源。
機制/實作/程序性主張 — 描述某事物如何運作或完成：特定的機制、演算法、架構、參數、實驗步驟、控制條件，或與表格/圖表/方法部分相關而非摘要結果的數值。摘要通常會省略此類內容，即使論文支持它。信號詞："mechanism"、「如何」、"architecture"、"algorithm"、「實作」、"procedure"、"protocol"、"parameter"、「控制組」、"ablation"、"table"、"figure"，或任何比一段摘要所能陳述的更具體的主張。

如果主張是機制/實作類別，即使摘要在主題上相關，僅摘要檢查也不足夠。擷取摘要作為存在性/主題匹配的證據，但不要僅憑摘要做出裁決——繼續執行下方的第 3b 層。

使用以下優先順序擷取摘要：

CrossRef 原始 JSON：https://api.crossref.org/works/{DOI} — 檢查 abstract 欄位
OpenAlex：https://api.openalex.org/works/doi:{DOI}?mailto={contact_email} — 重建 abstract_inverted_index
Semantic Scholar：在您的 S2 DOI 查詢中附加 &fields=abstract
開放獲取備用：https://api.unpaywall.org/v2/{DOI}?email={contact_email} — 檢查 is_oa 和 oa_locations
預印本使用 arXiv 備用：https://export.arxiv.org/api/query?id_list={arxiv_id}
生命/生物論文使用 PubMed Central：https://www.ncbi.nlm.nih.gov/pmc/articles/{PMCID}/

對於需要聯絡電子郵件的 API，請用來自設定的、使用者授權的實際地址替換 {contact_email}。不要發送佔位地址。

擷取後，檢查：摘要是否包含被引用的特定主張？

摘要明確包含該主張（逐字引用） → CONTENT: SUPPORTED
摘要關於該主題但未提出特定主張 → CONTENT: PARTIAL — 引用它實際說的內容
摘要與主張矛盾 → CONTENT: CONTRADICTED — 不要使用此引用
嘗試所有來源後仍無法存取摘要 → CONTENT: UNVERIFIABLE — 使用者必須檢查全文
主張是機制/實作類別，且在嘗試所有第 3b 層來源後仍無法取得全文 → CONTENT: ABSTRACT-ONLY — 全文不可用，驗證不足。此標籤絕不能升級為 SUPPORTED/ACCEPT。

絕不能放鬆的規則：如果你描述一篇論文「顯示」、「證明」或「報告」了什麼，你必須以所需深度引用或直接改寫已擷取的來源文字。即使你很有把握，也不允許根據記憶進行總結。

第 3b 層 — 全文確認（僅限機制/實作類別主張）

每當步驟 0 將主張分類為機制/實作類別時，或者當摘要的裁決為 PARTIAL 且主張比摘要摘要層級更為具體時，就需要執行此步驟。僅針對直接從摘要獲得 CONTENT: SUPPORTED 的頂層主張跳過此步驟。

按以下優先順序擷取論文正文，在第一個成功處停止：

本地 Zotero PDF — 如果已設定 Zotero 資料庫，查詢其資料庫以取得此 DOI，解析附件金鑰，並讀取連結的 PDF。常見的預設路徑是 ~/Zotero/zotero.sqlite，附件在 ~/Zotero/storage/{key}/ 下；請探索實際路徑，而不是假定它。
research-wiki 儲藏庫 — 當 research-wiki 技能可用時，在其設定的儲藏庫中搜尋已匯入的全文副本。不要假定機器特定的儲藏庫路徑。
開放獲取連結 — 解析並擷取實際的全文（不僅是可用性標記）：
- Unpaywall：https://api.unpaywall.org/v2/{DOI}?email={contact_email} → 擷取 best_oa_location.url_for_pdf（或任何 oa_locations[].url_for_pdf）。
- arXiv：https://export.arxiv.org/api/query?id_list={arxiv_id} → 擷取完整的論文，而不僅僅是 <summary> 欄位。
失敗 — 如果以上方法都無法產生可讀的全文，請不要將摘要視為足夠。應用上方定義的 CONTENT: ABSTRACT-ONLY 標籤。

取得全文後，引用支持、部分支持或與主張矛盾的段落。對於機制/實作主張，CONTENT: SUPPORTED 需要全文引用——摘要層級的主題匹配不能滿足此要求。

第 4 層 — DOI 解析

擷取 https://doi.org/{DOI}。確認登陸頁面與預期的論文匹配。來自包含標題和卷號的 URL 片段的 403（機器人封鎖）不是失效連結——將其註記為付費牆。重新導向到不相關的頁面是嚴重失敗。

第 5 層 — 撤稿

搜尋 "{第一作者姓氏}" "{期刊名稱}" retraction 並檢查 DOI 登陸頁面是否有撤稿橫幅。被撤稿的論文不得用作主要來源。

輸出格式

快速篩查：每篇參考文獻一行（參見上方）。

完整審計：每篇論文一張卡片，然後一個摘要表格。

參考文獻審計
────────────────────────────────────────────────
論文：   [來自即時來源的標題 — 非來自記憶]
DOI：     [DOI] — [✓ 已解析 | ✗ 已失效 | ✗ 錯誤論文 | ⚠ 付費牆-403]
作者：   [完整的作者列表，來自即時來源]
年份：    [年份]
期刊：    [完整的期刊名稱]

第 1 層 — 存在性：   ✓ 已確認（Crossref + Semantic Scholar）
第 2 層 — 元數據：   ✓ 匹配
第 3 層 — 內容：     [SUPPORTED | PARTIAL — 引用摘要/全文]
第 4 層 — DOI：       [已解析 | 已失效]
第 5 層 — 撤稿：       [✓ 未撤稿 | ✗ 已撤稿 — 不要使用]

關鍵原則

始終先嘗試 CLI。僅在 CLI 不可用或無法處理所需層級時才回退到手動協定。
從不憑記憶描述論文內容。每一句關於論文內容的陳述都必須連結到一個即時擷取的來源。
當來源不可用時明確說出——不要編造。
當使用者僅引用一篇論文時至少執行快速篩查。僅在搜尋論文、審核參考文獻列表或為特定主張引用時才執行完整審計。
始終區分頂層主張（摘要足夠）和機制/實作主張（需要全文）。
對於機制/實作主張，摘要層級的支持絕不能升級為已確認。

Moonweave-Research/ref-verify

ref-verify 是什麼？

在你喜歡的 AI 中提問

說明文件

ref-verify — 參考文獻幻覺防護

模式選擇

可執行的引擎

CLI 可用性檢查

CLI 優先工作流程

快速篩查 — 元數據 + DOI 合理性檢查

完整審計 — 適用於文獻搜尋或投稿前檢查

輸出格式

關鍵原則

相關技能

steipete/sag

steipete/oracle

steipete/peekaboo

mattpocock/design-an-interface

mattpocock/prototype

mattpocock/grill-me