營運與維護 · 實作指南
AI 讀到的舊狀態，可能藏在快取裏
分清業務更新時間、讀取時間與 HTTP 快取新鮮度，以可重現測試核對預約狀態。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
客服説“已經刷新”，為什麼還是舊狀態？
設想一家美國維修公司的客服助手：後台已把預約改為下午，助手卻仍顯示上午。這個虛構排查案例不證明某家產品有故障。先別重寫提示詞：瀏覽器、中間快取與應用自己的快取，都可能影響看到的數據。排查應先問“這份回答的數據在哪裏、何時取到”，再判斷模型是否誤讀。
- 業務記錄已更新
- 助手仍顯示舊副本
- 先查數據路徑
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第一張證據：業務時間，不只是頁面時間
我們建議同時顯示業務記錄的更新時間與本次讀取時間。兩者回答不同問題：記錄何時變化，應用何時取得它。RFC 9111 的 Age 欄位描述回應生成或成功驗證後的估計時長，不是業務記錄修改時間。[1] 因此，“剛打開頁面”或 Age 很小，都不能單獨證明預約仍然有效。
- 記錄更新時間
- 應用讀取時間
- Age：回應年齡
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第二張證據：兩個相似名字，兩個不同要求
MDN 説明，回應中的 no-cache 允許保存，但再次使用前必須向源站驗證；no-store 則要求快取不要保存回應。[2] 別把 no-cache 翻譯成“從不保存”。選哪種策略應由工程與數據負責人決定，不能讓 AI 根據名字猜。驗證也不等於每次都重新下載完整內容。
- no-cache：複用前驗證
- no-store：不要存儲
- 由負責人選擇策略
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第三張證據：改了回應標頭，舊副本不一定消失
MDN 提醒，快取指令不能清除中間伺服器已經存儲的回應。[2] 我們建議排查時列出瀏覽器、內容分發層與應用快取，分別核對更新或失效方式。不要把新增一個回應標頭當作歷史副本已刪除的證據，也不要為排查而無差別清空與本次問題無關的數據。
- 瀏覽器快取
- 中間層快取
- 應用快取
已接受的區域說明圖重繪，並非未經修改的原始截圖。
把“技術新鮮”與“可以承諾”分開
RFC 9111 把快取新鮮度定義為回應是否仍在規定的新鮮期內。[1] 這不是業務上的實時保證。我們的建議是：可瀏覽的狀態與最終承諾分開，確認預約前按業務規則重新核對權威系統；若無法核對，就明確説尚未確認。快取設置不能替代訪問控制或操作授權。
- 技術新鮮期
- 業務重新核對
- 確認後才作承諾
已接受的區域說明圖重繪，並非未經修改的原始截圖。
結束排查前，留下一個可復現的小實驗
用虛構預約測試：先讀取上午狀態，再在源系統改到下午，觀察正常訪問、刷新及應用快取失效後的結果。記錄命中哪一層、實際回應標頭和業務時間，而非只寫“刷新好了”。這是建議的測試方案，未在客户系統執行；通過條件應由團隊明確，例如確認界面不得把過期副本當作當前承諾。
- 讀取：上午
- 源系統改為下午
- 比較路徑與時間
已接受的區域說明圖重繪，並非未經修改的原始截圖。