我在 2026 年 6 月回頭檢查最早的 Evidence Card 時，看到一句比「沒有引用」更危險的話：來源 1 可支持「某篇文章標題」相關論點。 這句話不是從研究結果抽出來的；當時的程式只知道來源已被接受、題名是什麼，以及可能有一段摘要。卡片看起來已經能交給 Writer，實際上「被我選中」與「足以支持某個主張」之間，還隔著一段沒有完成的查核。

這個落差讓我重新理解 Accepted Source 的位置。它不是正確印章，也不是證據充分的同義詞。它先解決的是更基本的資料流問題：搜尋候選要經過審查，只有被接受的來源能往摘要、Evidence Card、大綱與草稿走；待審與拒絕的候選不能因為下游需要材料，又悄悄回到報告裡。

Accepted 是入口狀態，不是研究結論

Day 04 留下的搜尋結果仍只是候選。到了 6 月 16 日至 17 日，來源卡開始保存待審、接受與拒絕等狀態；使用者可以接受一筆來源，也可以撤回。共同的 helper 會從來源陣列中篩出 accepted records，生成畫面再把這個子集合交給準備度判斷與報告工作區。[1]

這裡最容易犯的錯，是把一次操作決定寫成知識判定。按下接受，能合理表示「我允許這筆資料進入下一階段」；它不能單獨表示研究設計可靠、摘要完整，更不能表示某句結論已由原文支持。前者是 workflow state，後者要靠研究內容與主張逐一核對。

我因此把 Accepted Source 當成一扇只能向下游開的門。門的價值不是替來源加分，而是縮小後續元件可以看見的材料範圍。只要 Writer 仍能讀到原始搜尋結果，審查按鈕就只是畫面裝飾。

這種邊界還帶來一個實際好處：我可以用輸入集合與輸出集合檢查審查是否生效，不必從一篇看似合理的長文反推某筆來源究竟何時混了進去。錯誤因此能在接近入口的位置被發現。

單向流要在每一個交接點成立

當時的工作區已把 accepted sources 同時送進來源摘要、Evidence Card、大綱與草稿；參考資料清單也會再次只保留 accepted records。產生報告前，畫面先從完整來源集合取出 accepted 子集合，再做 readiness 檢查。若條件不足，導向報告工作區的函式會直接回傳空結果，不儲存工作區，也不切換頁面。[1][2]

6 月 18 日的架構盤點把這條路寫成：題目與搜尋規劃、來源搜尋、來源審查、已接受來源、Evidence Card、報告草稿、預覽、匯出。[3] 這張圖真正值得保留的不是方框數量，而是每一支箭頭的責任：上游交付什麼，下游就只能消費什麼。

固定資料測試也檢查了幾個關鍵行為：待審與拒絕來源不會產生卡片；撤回接受後重新產生，原卡片會消失；來源不足時不會建立或導向工作區。這些測試證明的是程式邊界，不是真實來源可靠、報告正確或使用者研究成功。

Evidence Card 暴露了還沒跨完的那一步

單向流擋住了未接受資料，卻沒有自動解決「卡片內容是否成立」。以下是 6 月 17 日歷史版本的原始節錄：

function sourceToEvidenceCard(source: SourceRecord, ordinal: number): EvidenceCard {
  const id = sourceId(source);
  const title = source.title || "標題待確認";
  const usableSections = normalizeUsableSections(source.usableSections);

  return {
    id: `evidence:${id}`,
    sourceId: id,
    claim: `來源 ${ordinal} 可支持「${title}」相關論點。`,
    evidence: compactEvidenceText(source),
    sourceTitle: title,
    sourceUrl: source.url,
    sourceDomain: sourceDomain(source.url),
    sourceProvider: source.sourceType,
    sourceCategory: source.sourceCategory?.trim() || null,
    year: source.year,
    usableSections: usableSections.length ? usableSections : defaultUsableSections(),
    confidence: source.confidence?.trim() || null,
    notes: source.reviewNotes?.trim() || "",
  };
}

compactEvidenceText 有摘要時取第一句；沒有摘要時，可能只留下 DOI、網址或「仍需補充重點摘錄」的提醒。這代表卡片保住了來源身分與位置，卻可能產生過度寬鬆的 claim。題名能幫助辨識研究，摘要首句能提供初步線索，但兩者都不能自動證明一個具體主張。

這不是否定 Evidence Card，而是替它重新定義責任：卡片應該把可引用內容、來源身分、適用章節與限制顯式帶到下游；缺少哪一項，就保留缺口。若卡片用一個流暢句子填平空白，Writer 只會把同一個錯誤寫得更像結論。

Readiness 擋住的是材料條件

6 月 17 日的 readiness 不再只看「有沒有按生成」。它會檢查已接受來源、相關性、可用摘要與章節涵蓋，也會把低相關或離題卻被接受的項目列入診斷。材料不足時停止；介於兩者之間時只能建立較保守的草稿；條件較完整時才進入完整報告路徑。[1]

但這仍是一組啟發式門檻。來源筆數、摘要存在與章節標記，可以回答「目前是否有基本材料可組織」，不能回答「這些材料是否真的支持準備寫下的每一句話」。我若把 readiness 通過寫成 evidence sufficiency，就會把流程條件冒充研究判定。

當時的草稿邏輯已經有一個重要的安全提醒：只把 accepted sources 當成佐證池，不假裝做過未執行的實驗、問卷或訪談；摘要不足時，正文要提醒仍需回查原文。這個限制比讓草稿看起來完整更重要，但它依然只是早期防線。[2]

分階段，不代表已有唯一權限來源

這一版 workflow 已經分段，權限卻仍散在畫面狀態與多個 helper。畫面先篩一次 accepted sources，Evidence Card、摘要與參考資料函式各自又篩或解讀一次，readiness 再用自己的規則判斷能否前進。正常路徑下它們方向一致，卻沒有一個單一元件能替所有下游回答「這筆材料目前究竟可用到什麼程度」。[1][3]

所以我能公開說的是：那時已建立 source-first 的單向流程，並以測試保護幾個交接點；我不能說它已建立成熟的證據真值系統。更不能拿後來才出現的設計詞彙，倒寫成 6 月已完成的能力。

這個界線也改變了我看 UI 的方式。主要畫面應該讓使用者看見會影響決策的資訊：哪些候選待審、哪些已接受、材料還缺什麼。Evidence Card 與技術診斷可以保留在詳細檢視或除錯層，不必把每個內部欄位塞進主流程。透明度不是資料越多越好，而是決策依據與限制不能被藏起來。

我最後留下三個可測的不變條件

第一，入口不變條件：只有 accepted sources 能建立下游材料。第二，撤回不變條件：來源一旦不再接受，重新產生的卡片、摘要、草稿與參考資料都不能繼續把它當佐證。第三，強度不變條件：下游語氣不能強過卡片實際保存的內容；只有題名或位置，就只能寫成待查線索，不能升格成結論。

前兩項在當時已有固定資料測試可追；第三項則是我從早期卡片實作讀出的工程要求，不是已完成能力。這樣分類後，我不需要用一句「系統會避免幻覺」掩蓋差距，也能清楚知道下一步該補的是 claim 與 evidence 的對應，而不是再加一個更強的 prompt。

單向資料流解決了「哪些材料可以往下走」，接著還有另一個風險：搜尋前為了增加召回而擴寫題目時，原本的研究對象、範圍與排除條件可能被改掉。下一篇，我會回到 query expansion，拆解一個題目如何展開成多組查詢，又不在展開途中搜歪。

參考資料

1. ResearchForge 2026 年 6 月 17 日來源審查、Evidence Card 與 generation readiness 的提交紀錄，以及相同歷史版本的固定資料測試。
2. ResearchForge 2026 年 6 月 17 日 accepted-source 摘要與 report synthesis 的提交紀錄。
3. ResearchForge 2026 年 6 月 18 日架構盤點：source-first workflow 與各階段責任快照。