这周最大的体会：生产事故不是靠单点补丁修好的，是靠拆成基础契约来根治的。
有个幻觉类 bug 修了三轮才收敛。前两轮踩的是同一个坑——以为把关键词加进白名单就行。真正稳下来，是承认”事后审计”救不了”事前伪造”，把整个检查翻转成了事前拦截。另一个跨实例的破坏性操作确认问题，也是同一个思路：与其在业务点上打补丁，不如承认”单机内记状态在多实例下百分之百失效”是根问题，直接下沉到基础层。两件事指向同一条方法论：事故的修复深度，取决于愿不愿意重写契约，而不是只加护栏。
第二个体会是治理型改动必须有量化对标。有个路由层”照抄用户原句”的痼疾拖了一个多月才根治，核心原因就是一直没有决策依据。这次先把验收脚本补上，照抄率从过半降到零，一周收口。留下的经验：验收脚本的重要性不亚于改动本身，甚至应该先写脚本再动代码——没有基准，就没资格谈灰度。
第三，一个线上事故如果需要三处一起修才能修好，说明之前的分层假设是错的。这周记忆链路瘦身，把已下线旧引擎的遗留通路清干净之后，才看清那个”整段巨型条目当偏好注入”的老毛病，其实是三层各让一步共同造成的。每层都不能只信”上层已经收敛好了”，每层都得对自己吐出去的数据负责。这也是为什么后来给每个功能开关都立了规矩：必须有到期日，必须有负责人。