找到一張談讀書方法的資料卡，回答就有根據了嗎？在設計「從心出發」時，我最需要提防的，是檢索成功後太快放心：資料確實談到了這個主題，但模型接著說出的那句話，可能根本不在資料能支持的範圍內。

Day 21 把 Retrieval 的責任收在「提供候選」。今天我要往後追一步：候選資料中的哪一段，可以支持回答中的哪一句？這個問題不能只靠文件名稱、來源名氣或相似度分數回答。

一張資料卡，能解釋多少事？

以下是用來說明設計的假設情境，不是真實使用者紀錄，也不是本次實測結果。

使用者說：「我每天都有念，但老師換個題型，我就不知道怎麼下手。現在先不要給我方法，我只是想說說。」

假設檢索找到一張介紹「把任務拆成較小步驟」的候選資料卡，片段寫著：「可以先列出任務，再把其中一項拆成較小的步驟。」這張卡和片段都是為本文假設的，沒有對應的研究作者、療效數據或資料庫紀錄。

這段文字可以讓我核對「卡片介紹了任務拆分」這個敘述，卻沒有解釋使用者為什麼遇到新題型就卡住。從方法的介紹跳到「你的問題就是缺乏自律」，中間多出了一個沒有依據的個人判斷；若再推導成某種疾病，更超出了原文與系統角色的範圍。

身為也會遇到陌生題型的高中生，我能理解為什麼開發者容易急著找方法。但理解這種衝動，不能代替對這位使用者的了解。他明確說了什麼，和我覺得他可能需要什麼，必須分開。

檢查的單位，是準備說出的那句話

Source 回答的是資料從哪裡來，可以是一篇文章、一份文件或一張既有知識卡。Evidence 則必須相對於某項主張判斷：來源裡哪段內容，在保留哪些條件後，能支持那項敘述？同一份可信文件，對不同句子可能有完全不同的支持程度。

因此，我想檢查的 Claim，是系統準備對使用者說出的可核對敘述，而不只是整篇回答的主題。「卡片介紹任務拆分」、「這個方法能改善你的成績」、「你卡住是因為不夠自律」，雖然都圍繞讀書，需要的依據卻不一樣。假設卡片只寫了操作方式，後兩句就不能靠它成立。

即使引用了一段真的存在的文字，也還要問：原文談的是哪些人、什麼任務、什麼條件？如果資料只描述特定情境，回答卻省略條件，改成對所有人都適用，引用就只是替擴張後的結論加上外觀。

來源可信、內容支持這句話、這一輪適合這樣回應，是三次不同的判斷。前一項通過，不能替後一項代答。

現有程式留下了欄位，還沒有補上整段判斷

回到這次核對的程式，Day 21 的 RetrievalEligibilityGate 會依政策檢查候選的來源資訊、有效期限與證據類型。它接收候選集合和時間，沒有接收「準備對使用者說出的主張」，因此不能把它的准入結果解讀成逐句證實。

另一個已存在的資料結構，是 src/psychological_support/evidence/records.py 裡的 PsychologicalEvidenceRecord。以下節錄原始欄位：

    population: str
    intervention_tags: tuple[str, ...]
    outcome_tags: tuple[str, ...]
    summary: str
    limitations: tuple[str, ...]
    contraindication_notes: tuple[str, ...]
    evidence_strength: EvidenceStrength
    provenance: Provenance
    ingestion_version: str

這些欄位讓資料有地方記錄適用對象、摘要、限制與來源。但「有地方填」和「填入內容已經審查正確」仍有距離。這份結構也沒有把某句回答，綁到原文中特定支持片段的欄位；格式檢查不會自行完成語意核對。

本日尚未完成此部分，以下先整理目前設計與下一步。我把這個待補的判斷稱為 Evidence Gate；它是本文的工程概念，不是本次已確認上線的正式元件。在查閱的候選、證據紀錄與回覆路徑中，我尚未取得完整的逐句支持檢查證據。

我希望加入的，是讓每項待說出的主張連到可定位的來源版本與原文片段，保留適用條件，再記下哪些部分有支持、哪些仍不足。遇到互相衝突的資料，也應留下分歧，不能只選一句最方便組成答案的話。這些都是接下來需要驗證的設計。

有依據，也不等於現在就該給建議

回到開頭，即使未來找到足以說明任務拆分的合格資料，也不能因此忽略「現在先不要給我方法」。Response／Action 還有自己的問題：使用者這輪需要什麼？允許哪種回應？有沒有越過既有安全與互動邊界？

目前查閱的生成提示詞，確實要求依指定模式回覆、不編造使用者事實，也不要確認未經核實的信念；但提示詞中有這些要求，不足以證明每次生成都遵守，更不能當成這個假設案例已通過驗證。

沒有足夠的專業證據，也不表示系統只能沉默。使用者已經明確說出自己的困難與偏好，我可以據此設計一句承接：「你說自己每天都有念，換個題型卻還是卡住。我先不提方法，你想說的可以繼續說。」這是本文擬寫的回應示例，不是模型實測輸出。

這句話不替他找原因，也不暗示我知道他沒有說出的心理狀態。陪伴式回應不必每句附上論文；真正需要守住的，是不要趁承接情緒時，偷偷加入沒有根據的判斷。

用反例決定下一步怎麼驗證

我想用三個反例檢查這個設計。第一，只有來源名稱，卻找不到支持片段，系統應承認無法核對該項主張。第二，片段只介紹一般做法，回答卻擴張成個人原因或診斷，應刪除超出的部分。第三，資料能支持方法介紹，但使用者明確不要建議，這輪就不應把方法推給他。

這三個反例是待驗證的測試構想。這次查閱的既有離線紀錄，支持的是候選缺來源或過期時被排除等局部行為；它們沒有證明上述三種逐句與互動判斷已經完成。我也沒有為了寫這篇文章呼叫真實模型或重做網站驗收。

證據不足時，我想先縮小主張：說不清楚這位使用者卡住的原因，就不替他定義原因；尚不能證明方法適合他，就不說「你需要這個」。不確定的部分應留在判斷裡，而不是靠多放幾個引用把它藏起來。

有證據的回答仍可能生硬，自然的回答也可能缺少依據。引用數量、規則通過或測試數量，都不能單獨決定一段支持對話的品質。既有 roadmap 將 Day 23 暫列為 Outcome Validation，仍是規劃；如果沿著這個方向繼續，我接著要問的是：當系統交出一段有依據、也尊重本輪偏好的回覆，我們又該觀察什麼，才能判斷這次互動是否達成原先設定的目的？