Day 09 把搜尋結果留在「值得審查的候選」位置；接下來還有一道更容易被介面外觀掩蓋的問題：來源通過入口後，卡片已經出現在畫面上，是否就代表 Writer 有證據可以寫？

我回看 2026 年 6 月 26 日的 Evidence Card builder，發現一個很有用的反例。當來源沒有摘要也沒有全文時，程式仍會產生卡片，keyEvidence 甚至可能退回來源標題；同一張卡也會標成 metadata-only，並留下「僅有 metadata，不能產生具體研究主張」的限制。[3]

也就是說，卡片存在，只證明資料已經走到這個 transport layer；它不證明材料足以支持一句研究結論。Evidence Card 真正重要的工作，不是把來源縮短，而是讓「有什麼、缺什麼、可以怎麼用」一起往下游移動。

先控制哪些來源能產卡

6 月 16 日的前端實作先建立了一條清楚的入口規則：buildEvidenceCards 只處理 review state 為 accepted 的來源；pending 與 rejected 不產卡。同一個 sourceId 不會重複產卡，來源若被撤回接受，重新產生後原卡也會消失。歷史版本的固定資料測試涵蓋了這些行為。[1]

這一步解決的是資料流污染，不是研究正確性。當時自動產生的 claim 其實只是「來源 N 可支持『某標題』相關論點」；evidence 有摘要時取第一句，沒有摘要時才退回 DOI、網址或缺口提醒。[1]

因此，accepted 的意思是「允許這筆來源進入下一階段」，不能改寫成「這筆來源已證實某個具體主張」。入口閘門很重要，但閘門與證據判定不是同一件事。

摘要內容與證據狀態要分開

到了 6 月 26 日，後端 contract 把材料基礎拆成四種狀態。這四種名稱描述的是 builder 當下拿到什麼，不是論文品質排名，也不是主張正確率。[3]

這個設計比「全部都叫摘要」前進了一步，因為下游終於能區分：眼前的文字究竟來自 metadata、abstract、已解析內容，還是 OCR。若只傳一段流暢中文，這些差異就會在 handoff 時消失。

同時也要看到當時的不足。full-text-based 只要偵測到全文或 section 就成立，confidence 也由 evidence basis 直接對應；這不等於系統已逐句驗證方法、結果、研究族群與數值。狀態標籤讓限制可見，但沒有替我們完成內容查核。

Citation marker 不是引用正確性的證明

早期後端卡片已保存 sourceId、citationMarker、claimOrFinding、keyEvidence、usableSections、limitations 與 evidenceBasis。[3] 這些欄位讓卡片比無主摘要更容易追蹤，卻不能只看欄位名稱就推定證據完整。

例如，當時的 claimOrFinding 預設取來源標題，citationMarker 則依卡片順序產生。題名可以說明來源主題，［1］ 可以把草稿連回來源清單；兩者都沒有單獨證明某句話受到原文支持。若 keyEvidence 又退回題名，三個欄位看似齊全，其實仍只有同一份 metadata。

精確位置也還沒有完整進入這個 contract。前端卡片能保留來源網址，摘要缺失時可顯示 DOI 或網址；後端卡片能保存來源身分與可用 section 名稱，但沒有逐一保證 page、span 或可重建的原文位置。[1][3] 所以當時能安全說的是「可以回到來源」，不能說每張卡都已做到逐句定位。

同一個 accepted，也可能來自不同決策

6 月 18 日的架構盤點把流程寫成：搜尋、來源審查、accepted sources、Evidence Cards、報告草稿、預覽與匯出，並建議以 accepted sources 作為報告生成的輸入。[2]

但同一時期的兩條實作路徑並不完全同義。前端卡片讀的是使用者審查後的 reviewState；6 月 26 日的研究搜尋路徑則把經規則過濾、排序與截取的結果命名為 acceptedSources，再交給後端 card builder。[1][3]

這個差異提醒我：看到 acceptedSources 這個變數名，不能反推一定有人逐篇確認過。要知道一張卡取得了什麼資格，仍要沿著資料流回查「誰做了接受決定、依據是什麼」。名稱相同，不代表權限來源相同。

這也說明為什麼資料模型不能只保存最後的布林值。若只留下 accepted: true，日後很難分辨它來自人工選取、規則篩選，還是某次匯入的預設值。早期版本尚未統一這項責任，所以公開描述時，我只能分別說明兩條路徑，不能把它們合併成一套已完成的審查制度。

Evidence Card 是交接合約，不是最終裁判

從這段歷史，我把 Evidence Card 的責任整理成四個不變條件：來源身分不能在交接時消失；材料基礎與限制必須跟著內容走；只有題名或摘要時，不能自動補出方法、結果與數值；下游句子的強度不能超過卡片實際保存的材料。

這四點是根據早期缺口整理出的設計判準，不是宣稱 6 月版本已全部完成。當時的卡片已經是結構化的下游材料，也建立了 accepted source 到 report synthesis 的中間層；但它還不是完整的 study-level fact record，更不是能自行決定證據真假的 authority。[2][3]

真正安全的 transport contract，甚至要允許自己看起來「不完整」。metadata-only 卡片可以存在，因為它保存了來源線索；但限制也必須完整存在，讓 Writer 知道現在不能寫具體研究主張。把空白補成流暢句子，才是最危險的完整感。

如果要把這個經驗搬到自己的 RAG 或研究助理，我會在每次 handoff 前問四個問題。第一，這段內容能否回到唯一來源，而不是只回到一個搜尋結果序號？第二，系統保存的是原文材料、摘要，還是模型重述？第三，缺少全文、定位或研究細節時，限制是否仍是機器可讀的欄位？第四，Writer 能否在忽略限制後照常產生更強的句子？

前三題是在檢查可追溯性，最後一題則是在檢查權限邊界。若限制只寫在 UI 提示或 prompt 裡，下游仍可能繞過；若卡片把材料層級與限制當成正式資料，驗證器才有機會在寫作前擋下越界主張。Evidence Card 的價值因此不在於替模型整理更多文字，而在於減少模型必須自行猜測的部分。

下一步不是把卡片依序接起來

Evidence Card 把單一來源的內容與限制帶到寫作入口，仍沒有回答整個研究問題。多張卡可能集中在同一個子題，也可能使用不同族群、方法與 outcome；若只是照來源順序排列，最後只會得到一篇附有引用的卡片接龍。

因此，Day 11 要處理的不是如何讓 Writer 讀更多卡，而是 synthesis 如何以研究問題為中心，連接相容的材料、保留差異，並拒絕跨越卡片沒有提供的證據邊界。

參考資料

1. ResearchForge 2026 年 6 月 16 日前端 Evidence Card 實作與同版本固定資料測試。
2. ResearchForge 2026 年 6 月 18 日架構盤點文件。
3. ResearchForge 2026 年 6 月 26 日後端 Evidence Card builder、schema 與研究搜尋路徑提交紀錄。