营运与维护 · 实作指南
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] 这不是业务上的实时保证。我们的建议是：可浏览的状态与最终承诺分开，确认预约前按业务规则重新核对权威系统；若无法核对，就明确说尚未确认。缓存设置不能替代访问控制或操作授权。
- 技术新鲜期
- 业务重新核对
- 确认后才作承诺
未经修改的原始来源说明图。
结束排查前，留下一个可复现的小实验
用虚构预约测试：先读取上午状态，再在源系统改到下午，观察正常访问、刷新及应用缓存失效后的结果。记录命中哪一层、实际响应头和业务时间，而非只写“刷新好了”。这是建议的测试方案，未在客户系统执行；通过条件应由团队明确，例如确认界面不得把过期副本当作当前承诺。
- 读取：上午
- 源系统改为下午
- 比较路径与时间
未经修改的原始来源说明图。