*2026 年 9 月 25 日

從一則回覆走向整段對話

上一篇我問的是：回答通過檢查後，怎麼知道它真的接住了眼前的人？最近調整首輪回覆的表達與承接方式後，我想把視線拉長。如果有人先說「只想被聽見」，接著補充、更正，後來才願意談下一步，系統能不能在每一輪都跟上？只看一則比較順的回答，回答不了這個問題。

於是我開始看完整多輪對話的驗收紀錄。前三輪的模型回覆曾被採用、保存，並出現在畫面；到了第四輪，回覆被既有的安全規則擋下。後續排查發現，那次命中的是一段轉述使用者自我貶低想法的文字；規則把其中幾個字辨認成不當的依賴暗示。這是目前的規則限制，不能因為我讀起來覺得是誤判，就把原本被拒絕的回覆算作通過。相關提示與選擇邏輯有調整，但修後尚未取得新的模型回答。

這篇寫於 9 月 25 日凌晨，整理的是前一晚完成的排查與修補；我沒有為了寫日記再送出模型請求。

更麻煩的是，我準備接著檢查後幾輪時，原來那段對話已無法從系統取回。這把問題從「回答得對不對」推向更基本的一層：眼前看得到對話入口，後端是否還有那段對話？

入口還在，不代表對話還在

我把 session 想成一次對話的「暫時保管盒」：裡面有輪次與狀態，系統要靠它知道下一句是在接哪一段。瀏覽器這個分頁保存的重開入口，則比較像保管盒的取件資訊。取件資訊還在，不保證盒子還在。

這個版本的對話從建立起，最長只能存取三十分鐘；中途再說幾句，也不會把期限往後延。到期後，伺服器會清理過期資料。因此，「我按了保留，重新整理後還看到重開按鈕」只能表示這個分頁記得入口，不能表示後端延長了保存期限。這是我這次最需要釐清的兩種「有保存」：前者是入口，後者才是可接續的原對話。

我怎麼確認它真的不在了

我先回看原生 API，也就是網站向後端讀寫對話的介面。當時的紀錄有建立對話的請求，也有前三輪之後成功讀回的請求，說明它曾經真的存在；後來對原對話再讀取，後端回傳找不到。這一步回答「是不是從來沒存進去」，但單靠畫面或一份舊紀錄，還不能判斷它現在在哪裡。

第二步是核對資料庫。我確認前後使用的是同一個資料庫檔案，原對話與其生命週期紀錄在檢查時都已沒有資料列。已保存的歷史追蹤紀錄（trace）可以幫我查出當時發生了什麼，卻不能變成具有原本接續權限的 session；在已檢查的工作區裡，也沒有找到可信的原生備份。因此，這次原對話不能恢復接著驗收。

第三步才看時間與清理程式。保存期限是建立後固定三十分鐘，清理流程會刪除到期對話；隔離測試也重現了到期、再次讀取失敗，以及稍後清掉生命週期紀錄的過程。資料庫的修改時間與這條路徑吻合，所以「正常到期清理」是有力的解釋。不過，歷史紀錄沒有留下那一次實際執行的刪除指令；我不能把時間吻合寫成已抓到確切是哪個動作刪的，也不能排除未觀測到的操作。

讓畫面說清楚「還能不能接」

這次修改把本分頁的入口寫成「檢查本分頁對話是否仍有效」。按下後，前端會先向後端讀取原對話；只有讀得到，才用讀回的輪次開啟。若後端回覆找不到，畫面會明確顯示「原對話已失效或刪除，無法接續；本分頁的重開入口已清除。」入口也會被清掉，不再讓人以為按鈕還在就能接著聊。這是釐清可用狀態，不是把到期對話救回來。

我也回頭整理上一輪沒過的回歸檢查，也就是修改後重跑舊情境，確認沒有破壞原有行為。這次修正過時的測試期待與測試替身，並修好一個真正的來源綁定問題：回答引用的來源若版本錯誤或缺少識別資料，不該在檢查前被程式自動補成看似合法。指定範圍的離線回歸與前端情境檢查已通過，前端型別檢查與建置也通過；針對相關前端檔案的程式風格檢查仍有既存錯誤，不能寫成所有關卡全綠。原站已載入這批修改，但載入程式仍不等於跑完一段新的真實對話。

三種「通過」，還是要分開看

我現在會把三件事分開記：程式檢查通過，代表指定的保存、失效與規則情境符合預期；真的能接續，還要在有效期限內用原生流程逐輪送出、保存、重新讀回，並核對畫面；至於回覆是否讓人感到被理解，還得有人閱讀實際產生的文字。第一件事不能替後兩件事作答。

截至這篇草稿，原對話無法接續，修後也沒有新的模型回覆或完整多輪人工驗收。若要再做完整對話，只能建立新 session，從頭留下每輪的送出、採用、保存、讀回和畫面證據；那會是一次新驗收，而不是替舊對話補上結局。身為高中生開發者，我現在能做的是把每個「通過」留在它真正覆蓋的範圍裡。下次真的能一路接下去時，系統除了記得每一輪，能不能也尊重每一輪改變的意思？