前面十章造了一台相当完备的机器。但所有用过预算的人——包括用得很成功的人——都知道一个事实：它会崩。不是可能，是必然。某个月你会连着加班靠外卖活着，某次旅行你会彻底放飞，某个双十一你会发现分类额度全部见红。
这一章不管「怎么不崩」——那是前五章的事，而且就算全做到，崩还是会来。这章管的是更实际的问题：崩的那一刻，以及崩完的第二天，系统该干什么。工程上，这叫崩溃恢复；一个不设计崩溃恢复的系统，等于默认自己永不崩溃——而默认永不崩溃的系统，第一次崩溃就是最后一次。
先认识真正杀死预算的那个瞬间
预算的死亡现场几乎从不发生在超支那一刻，而发生在超支之后约十秒的心理活动里。心理学家研究节食时发现了这个机制，起了个名字，叫破罐破摔效应——节食者不小心多吃了一块蛋糕，接下来的反应不是「停下」，而是「反正今天已经破功了」，然后把整个蛋糕吃完。预算的版本：伙食超了三百 → 「这个月反正爆了」 → 彻底放飞，月底超两千。
请注意这个推理的荒谬之处：超三百和超两千之间差着一千七，而这中间的全部损失，都来自「反正已经不完美了」这一念。预算真正的死因不是破窗，是破窗之后的自拆。一次超支是擦伤，破罐破摔才是致命伤。
大白话：蛋糕吃了一角，损失是一角；因为吃了一角就把整个吃完，损失才是整个。超支的那个月，你的任务不是「回到完美」，是「别让三百变两千」。
崩溃恢复协议
既然崩溃必然发生，就把它当成一种已知的系统状态，提前写好处置流程。协议很短，三条：
第一条：止损线，不是羞耻线。某类额度见底后，规则不是「禁止再花」（做不到），而是自动降级——比如伙食见红后，外食改食堂，但不许动「把整类预算删掉放飞」的念头。目标是把超支控制在额度的零头量级，而不是追求不超。一个超 5% 的月份是完全健康的月份。
第二条：当月结算，绝不滚债。超支的部分，月末开个短会（一个人的会也行），决定从哪补：机动分类、下月对应分类微调、或干脆认账销账。选哪个都行，唯一不许的是「假装没发生」。每拖一个月，账面失真一分，你对仪表盘的信任就少一分——而系统靠信任运转。
第三条：每月一号是全新的。这是整个协议的心理核心：预算以月为单位结清，新的一月额度满血重置。上个月爆成什么样，都只是上个版本的日志。这避免了破罐破摔的最大温床——「我已经是个失败的人了」。不，你只是一个刚发布了 bug 的系统，而这个月是新版本。
从崩溃里提取情报
第五章说过，超支是报错日志。崩溃恢复不只是「收拾残局」，还有一步更值钱的：读日志，改参数。崩溃分两种，处置完全不同：
- 参数错误型：同一类连续两三个月都超——这不是你堕落了，是设定值写低了。解法：大方把这类额度调高（在别处对应调低），把预算改回和你的生活匹配。预算伺候你的生活，不是你的生活伺候预算。
- 真·异常型：偶发的、有明确外因的超支（旅行、急事）——这种不需要改参数，它本来就是机动分类和分摊基金存在的意义。用掉缓冲然后补回来，系统就是这么设计的。
坚持读日志几个月，你会攒出一份越来越准的「自我模型」：哪类开销你是真的需要、哪些波动是季节性的、你的自控力在什么状态下会断电。这份模型是任何理财大 V 都给不了你的——它只产自你自己的报错历史。
放弃之后怎么回来
最后说一种最大的崩溃：不是某个月超了，而是整个系统停转了三个月——没回顾、没派活、账户一团乱。重启的最小步骤只有两步：第一，别补课（不要试图补记三个月的账，那是重启失败的最大原因）；第二，翻开第三章，花一小时解剖一下最近流水，下个月一号直接重新派活。系统从不评判你停了多久，它只认这个月的输入。
能无限重启的系统，才是真的崩不坏的系统。下一章，最后一章，回答一个收尾的问题：这套系统要陪你到哪一天，它的尽头是什么。