前十章，我们像搭机器一样把龙餐馆搭了起来：菜单是接口，后厨是装配线，队列会堵，瓶颈会卡，过载会雪崩，于是我们上了限流背压，做了缓存，算清了每一单赚多少、菜该卖多少钱。到这里，龙餐馆已经是一台能跑的机器。
但一台机器能跑，不等于它能自己跑好。今天中午厨房状态好、菜出得快，明天可能一个厨师崩了、退菜堆成山；这周某道招牌卖爆、备料不够，下周它突然没人点、剩了一冰箱。世界一直在变。如果每一次变化都要老板亲自冲进去救火，那这家店本质上还是靠一个人的注意力在硬撑——老板一请假，机器就失稳。
这一章讲的，就是怎么让龙餐馆自己学会调节：不靠盯，靠回路。
什么是反馈回路
反馈回路 (feedback loop)——把系统输出的结果，回头拿来调节它自己的下一步行为，形成一个闭环。
说人话：做完一件事，看看结果怎么样，再拿这个结果去改下一次怎么做。看结果、回头调，就是"反馈"。做完就完、不回头看的，叫开环。
开环就是只管往前做、不看结果、不回头调。比如：每天固定备 100 份牛腩，卖不卖得完不管，客人爱不爱吃不管。开环系统在稳定的世界里能凑合，可现实从不稳定，于是开环的店永远在"要么剩一堆、要么早早卖光"之间来回踩空。
闭环则不同。它长这样：
厨房出菜 → 客人的反应（吃光 / 退菜 / 差评 / 复购）→ 我们看见这个反应 → 调整（换菜、改火候、调备料）→ 厨房再出菜……
这个圈一旦合上，龙餐馆就从"一台被推着走的机器"变成"一台会自我纠正的系统"。
负反馈让日常稳住，正反馈是双刃剑
反馈分两种，方向相反。
负反馈——结果偏了，系统就往反方向使劲，把它拉回来，让系统收敛、稳定。最好的例子是空调：屋里热了就制冷，到点了就停，冷过头再停制冷。它的天职就是把温度稳在设定值附近，永远在纠偏。
正反馈——结果往哪偏，系统就往哪个方向加码，越滚越大，自我放大。第六章那场延迟雪崩就是正反馈：慢一点 → 队伍更长 → 更慢 → 队伍更更长。口碑爆发也是正反馈：好评招来客人 → 更多好评 → 更多客人。
关键区别，工程师一看就懂：
- 日常运营要的是负反馈。你要的是稳：等位长了就想办法缩短，退菜多了就赶紧查。负反馈是你每天赖以活命的"恒温器"。
- 正反馈是双刃剑。同一个放大机制，方向对了是福（好评滚雪球、门口排队本身吸引更多人），方向错了是灾（差评滚雪球、拥堵引发踩踏、退菜拖垮厨房节奏）。
所以我们对正反馈的态度不是"消灭它"，而是"想办法让它只朝好的方向滚，一旦发现它朝坏的方向滚，就立刻用负反馈的手段（比如第七章的限流）去掐断那个放大链条"。
龙餐馆里，回路怎么合上
反馈不是玄学，它是一串具体的"信号 → 判断 → 动作"。列几条龙餐馆每天真在跑的回路：
- 退菜率高 → 是某道菜今天出了问题，还是这个灶的厨师状态差？→ 换人、重调火候，或临时把这道菜从菜单撤下。
- 等位时长过长 → 加临时座位、提醒服务员催翻台、或干脆临时限流（回扣第七章：门口挂"约 40 分钟"，宁可劝退一部分，也别让所有人一起崩）。
- 复购率低 / 客人反馈差 → 这是慢信号，指向菜单本身 → 改菜、下架、上新。
- 剩菜损耗大 → 备料备多了 → 下调这道菜的备料量（回扣第八章：备料本质是给热门菜做的缓存，缓存该多大，要按命中率来定）。
这里有个最容易被忽视、却最要命的点：信号必须被看见，而且必须真的驱动动作。如果退菜率高但没人统计、没人管，那这条"回路"是断的——它退化成了开环。很多店不是没有信号，而是信号在空转：数据躺在那儿，没人看，看了也不改。没合上的回路，等于没有回路。
两个要命的参数：延迟和增益
合上回路只是第一步。回路调得好不好，取决于两个参数——凡是碰过 PID、碰过控制系统的工程师，对这两个词会心一笑。
延迟：信号来得太慢，你救的是尸体
延迟是指：结果发生，到你看见它、再到你纠正它，中间隔了多久。
反馈太慢是致命的。等你月底盘账才发现某道菜难吃，客人早就默默走光、再不回来了——你纠正的是一具已经凉了的系统。控制系统里有条铁律：反馈滞后会导致震荡甚至失控。你根据一小时前的"路况"打方向盘，必然会左右画龙。
所以好的回路要把信号"提前"：别等复购率（几周才看得出）才反应，退菜、皱眉、剩了半盘这些即时信号，就该当场触发动作。信号越即时，方向盘打得越准。
增益：反应太猛，你会把自己甩出去
增益是指：看到一点偏差，你出多大力去纠正。
反应过猛，系统会来回震荡。典型翻车：今天生意差，一冲动把备料砍一半；第二天客人来了，没货、又手忙脚乱地加。你以为在纠偏，其实是在给系统制造更大的抖动——这跟第六章那种"一慌就疯狂重试、反而压垮系统"是同一种病。
好的控制，四个字：及时，适度。看到偏差别不管（延迟别太大），也别一把梭哈（增益别太高）。稳稳地、小步地往回收，才收敛得快。
反直觉的核心：韧性不来自不犯错
到这里可以说出这一章最反直觉的一句话了：
好的系统，不追求永不出错；它追求让错误被快速看见、被快速纠正。
菜偶尔咸了、某天某个灶崩了、某道新菜没人买——这些都会发生，而且一定会发生。追求"永不出错"是个幻觉，越追越脆。真正的韧性来自"闭环快"，不来自"不犯错"：错误一出现，几分钟内被信号捕捉，几分钟内被动作纠正，它就只是一朵小水花，翻不成大浪。
这也顺手改写了老板的角色。老板不该是救火队长——哪起火冲哪，累死自己，店还没变好。老板该是设计反馈回路的人：他的工作是搭好"信号怎么采、谁来看、看了触发什么动作"这套机制，然后让店自己去纠自己的偏。前者是运行时的算力，后者是架构。
可观测性：看不见，就无从反馈
最后收一个前提。所有反馈的第一步都是"看见"，所以整套回路真正的地基是可观测性——能不能从外部看出系统内部的状态。
说人话：机器不会开口告诉你它现在难不难受，你得能从外面读出来。读不出来的东西，你既救不了它，也调不了它。
看不见的信号，无法反馈。所以龙餐馆的"监控"其实一直都在，只是我们平时不这么叫它：
- 仪表盘——今日退菜率、等位时长、各菜销量、损耗，一屏看清。这是给系统装的
metrics。 - 巡台——经理走一圈，看哪桌菜没动、哪桌在皱眉、哪桌招手很久没人理。这是采即时信号。
- 尝味——出餐前主厨尝一口。这是在源头做健康检查，把坏结果拦在到客人之前。
这三样越灵敏，回路的延迟就越小，龙餐馆自我纠偏的速度就越快。一家看得清自己的店，才谈得上会调节自己。
下一站
好了，现在的龙餐馆是一台带负反馈的控制系统：它能靠信号自己收敛回正轨，老板从盯着救火，变成了设计回路的人。
可是——这一切的"看见"和"纠偏"，都发生在一家店里：经理巡的是这一个大堂，主厨尝的是这一口锅。那么问题来了：当我们要开第二家、第三家、第十家分店，这套自我调节还成立吗？总店的信号看得见分店后厨吗？一个店的"及时适度"，复制到十个店，会变成什么样的混乱？下一章，我们从一家店，走向一群店。