一、我發現問題不只在「怎麼說」

最近收到的回饋，讓我重新思考「從心出發」的回覆：文字變長了，讀起來仍不一定有安慰效果；反覆出現「值得被顧及」這類固定肯認句，也容易像在向旁觀者解釋處境，沒有直接體諒正在說話的人。另一種落差則是，對方期待一些意見，系統卻繼續停在同一種安慰。

Day 23 追的是新增資訊與更正有沒有進入生成流程；Day 24 則提醒我，測試通過與使用者感到被理解，需要不同證據。沿著這條線，今天我想再往前追：回覆產生之前，系統究竟怎麼決定這一輪可以做什麼？

身為高中生開發者，我很容易把問題想成「再補幾條提示詞」。但即使模型知道情緒反映、具體肯認與陪伴，判錯需要，仍可能做錯事。對方想把事情說完，系統卻安排下一步；對方明確求助，系統又只重複安慰。兩種情況都不能靠增加溫暖詞句解決。

我把這個設計問題稱為 Counseling Skill Router，支持技巧路由。本文用它描述語境判斷、行為准入與技巧選擇之間的關係，不代表專案已有同名類別、API 或完整子系統。目前對應的工作，分散在意圖與偏好更新、回應規劃、技巧選取及生成檢查之中。

二、先判斷可以做什麼，再選擇怎麼支持

我需要分清楚三個層次。

第一層是當輪意圖。使用者正在傾訴、詢問、否定、假設，還是單純描述事情？「怎麼辦」可能是請求方法，也可能是在表達無措；「我不知道」沒有自動附帶「請替我安排下一步」的意思。

第二層是有效偏好與行為限制。先前要求不要建議，現在是否仍有效？這輪有沒有明確改變要求？系統所說的准入，就是確認某項行為目前被允許。辨識到求助語句，只是判斷材料，不能直接跳過這一層。

第三層才是支持技巧。在允許範圍內，這次適合具體承接、情緒反映、陪伴、探索，還是一個小建議？某個技巧可能有幫助，也不能代替使用者的意願。

目前專案的純傾聽模式 LISTEN_ONLY，要求零問題、零建議、零行動。探索 EXPLORE 與提問 ASK 有各自的路徑；本輪離線案例分別檢查零問題與一個問題的額度，兩者都沒有因此取得建議權限。「想釐清」不必然等於同意被追問，能提問也不等於能安排方法。

正式契約另有明確意見請求的一輪授權，以及撤回後立即停止的規則。這不等於「新句子永遠蓋過舊偏好」：必須先確認它確實是當輪請求，再依契約更新狀態；下一輪也不能沿用已消耗的建議權限。

如果語境仍不清楚，我的設計目標是保留不確定性，必要時才在允許提問的條件下輕量澄清。不能一邊宣告尊重純傾聽，一邊每輪追問對方到底需要什麼。

三、為什麼關鍵字不夠——幾個看似接近、其實不同的句子

下面五句都是設計示例，不是真實測試結果。表格只指出需要辨識的語境，沒有憑單句替完整系統下判決。

最近的修復，正好讓這些差異變得具體。

在本輪失敗紀錄裡，上游已拒絕把某些假設、否定句當成傾聽要求，下游通用備援判斷（fallback）卻又把文字歸為傾訴，重新取得傾聽資格。另一筆則把中性敘述也當成傾訴。這些是可定位的實作問題，不能概括成模型不夠聰明。

還有一筆測試保留原本的狀態與計畫，只把意圖改為尋求建議 SEEK_ADVICE。舊判斷因為仍有少給建議的偏好，竟繼續准入純傾聽。這個反例要保護的是狀態一致性：偏好欄位不能掩蓋意圖與計畫的衝突，也不能把拒絕純傾聽准入誤解為已授權建議。

修補除了收緊語境判斷，也在計畫與模型派送前重新核對意圖、路徑及額度，不單憑傾聽標記放行。不過，這些判斷仍含有限的字詞規則；特定反例受到保護，不表示表格中的所有自然語句都已可靠辨識。

四、傾聽不等於什麼資料都不能用

接著容易走向另一個極端：既然純傾聽不能給方法，是不是連支持知識都不能用？

本專案的 conduct-only，指的是把資料限於「系統如何回應」的行為原則。例如先承接已說出的具體困難、不替對方推論未陳述的原因、不用一連串問題要求更多交代。它不能藉由檢索，把個人行動建議、心理診斷或病理推定帶回回答。

以下是設計示例，非模型實測輸出：

「家人一吵架，你就沒辦法繼續讀，這樣真的很難專心。你現在說的是這個困難，我先不急著替你安排怎麼處理。」

這段嘗試直接體諒已說出的影響。至於要求對方換地方、戴耳機或找家人談，即使可能出現在其他資料裡，也已經跨到對使用者提出行動。

資料可以告訴系統如何聽，不能因此替使用者決定如何生活。

這次我核對到兩條實際接線：支持原則經檢索、資格檢查與篩選後，进入生成輸入的行為限制；本地技巧則由既有知識目錄 KnowledgeCatalog 載入，檢查來源與模式相容性，再把行為要點放入 communication_techniques。

因此，這裡有比「資料檔案存在」更具體的證據：程式把選取結果組進生成請求，本輪離線測試也檢查了這個位置。但它仍只證明資料流，不能證明模型善用了技巧。沒有合格資料時，也不能捏造來源；符合准入的純傾聽仍可依使用者已說出的內容回應。

五、回歸測試也需要檢查自己的假設

本次 FH-LISTEN-REGRESSION-AND-RECOVERY-CLOSURE-06 的 FAILURE-POLICY-MAP.md，把最初六筆失敗分成四筆實作缺陷與兩筆測試政策衝突。這個區分很重要：程式違約，要修程式；測試仍要求已被正式修訂的舊契約，就得先核對政策沿革。

L01、L02 原先使用「禁止全部檢索」的測試替身。後來正式候選已建立受治理的支持原則檢索與 conduct-only 輸入，後續需求也明確要求技巧實際參與生成。原測試因此在第一輪檢索時就中斷，L02 要保護的第二輪更正甚至還沒執行。

這不表示可以直接刪除限制。替代測試要求檢索走支持原則路徑、純傾聽准入有效，並維持零問題、零建議與零行動；同時保留風險仍為未知、介入受限、原解析流程，以及更正後當輪內容、歷史與版本變化的檢查。

新增反例也檢查：支持卡能進入提示詞，不代表輸出可以帶入建議、主張綁定或行動。未取得傾聽資格的中性、假設與引用案例，仍保留不得檢索及派送的限制。

我想守住的順序，可以寫成下面這段概念示意，非專案原始碼：

語境 = 辨識當輪文字與相關上下文
限制 = 核對有效偏好、模式與安全邊界
允許行為 = 依正式契約核對(語境, 限制)
若尚無准入：保留不確定性，走既有受限處理
技巧 = 選取來源合格且相容的支持方式
回覆 = 在允許行為內生成(使用者內容, 技巧)
檢查回覆是否越界、捏造或忽略更正

測試的價值，在於把准入正例與拒絕反例一起留下。不能為了變綠修改預期值，也不能為了保留舊預期，讓正式允許的支持資料流永遠無法運作。

六、工程封閉之後，還要回到那個正在說話的人

截至本文依據的本輪結案紀錄，工程已封閉，原站已載入對應修改，可開始人工第一輪試聊 T1。本輪沒有進行真實模型供應端對話，安慰效果、模型語意品質與人工接受度仍未驗證。今天的寫作也只有唯讀查核，沒有新增測試或模型請求。

我需要把四件事分開：工程檢查通過，表示指定契約受到檢查；原站載入，表示修改已進入該次記錄的服務；觀察真實模型回覆，才有新的生成文字可讀；使用者實際接受，則需要對方的回饋。前兩項不能替後兩項作答。

「從心出發」是非診斷、非治療的數位心理支持專案，不取代心理師或醫療服務。這裡談的是互動設計與工程限制，沒有宣稱技巧經系統使用後具備臨床效果。一般需求理解也與危機安全判斷分屬不同責任，不能因為能辨識幾種求助句，就推論已可靠辨識危機。

我現在比較想記住的是：選支持技巧之前，先讓對方這一輪說的話真正改變判斷。他可以需要安慰，也可以想聽意見，還可以在下一輪改變主意。

支持技巧路由不該把人分進固定的情緒格子。對我而言，它是一個反覆提醒自己的位置：對方現在說了什麼、允許我做什麼，以及我是不是又急著把自己的方法放上去。

參考資料（本次唯讀核對的專案內部文件與程式）：

• Day 23、Day 24 的 article-public.md；本次查看的文章目錄未找到 Day 25 正文，因此未將其提示詞安排視為已發表內容。
• FH-LISTEN-REGRESSION-AND-RECOVERY-CLOSURE-06：FAILURE-POLICY-MAP.md、FINAL.md。
• 政策沿革：FH-DIALOGUE-CLOSURE-02 的 REQUEST.md、FH-WARM-LISTEN-CRISIS-SAKURA-E2E-01 的 FINAL-REPORT.md、FH-AUTH-RECOVERY-AND-SEMANTIC-CLOSURE-04 的 owner-request.txt 第九節。歷史資料流紀錄不代表品質通過。
• 對應候選程式與測試：formulation.py、planner.py、engine.py、natural_prompt.py、techniques.py、test_listen_only_policy.py、test_listen_recovery_closure.py。