寓言故事
客栈换菜单时，没有把正在吃饭的客人赶出去
客栈每天接待很多客人。厨房有固定菜单、火候和上菜顺序，掌柜过去一改菜单，就要停业半天重新贴牌。
生意变大后，停业代价越来越高。只是改一道菜名、换一个折扣、调整一条忌口规则，也要让全店等着。伙计先偷偷在后厨口头传新规。结果前厅还是旧菜单，后厨已经按新菜单做菜，账房又按第三套价格结账。
一次过敏客人差点吃错菜。掌柜发现，问题不是不能改，而是改动没有一致、可控地进入正在运行的店。他设计了热换菜单的办法。新规则先检查格式和风险，再推到后厨试用；通过后逐桌生效，失败时能立刻退回旧菜单。
正在吃饭的客人不被打断。新来的订单用新菜单，已下单的菜按原规则完成，所有切换都有版本记录。后来，客栈能快速调整提示词、工具配置、路由规则和机器版本，而不必每次重启整间店。
掌柜没有急着再发口头命令。他让账房先做一张换菜单木牌，写清哪一桌从旧规走，哪一桌从新规走，谁批准，何时撤回。
第二天他们只在靠窗三桌试行。厨师发现一道菜会卡住炉口，便把木牌翻回旧面，前厅继续接待，客人只觉得上菜慢了一点。几轮之后，伙计们学会把改动当作进店的新客，而不是砸掉整间客栈重建。小改动能进来，也能被看见、被撤回。
这次小事故让众人停下来复盘。他们没有急着换一套更响亮的说法，而是把出错的入口、被误解的规则和需要保留的边界逐一写清。 后来众人再遇到类似情况时，先看现场约束和失败痕迹，再决定该放宽、收紧还是换一种做法。
掌柜明白，运行中的系统需要可控变更能力；热加载的价值，是让小而频繁的更新不变成服务中断和状态混乱。