代码写到一半才想起没画控制图，然后服务重试了一整晚
先讲我自己的一次教科书式失败。
某次集成一个生图 API。写完调用逻辑，跑通了一个正常场景，上线。
然后现实开始上课。
请求时好时坏。参数各种 400。
某天夜里，任务队列积压了几百个失败请求，在无差别重试。
重试了一整晚。
最讽刺的是什么？
我"学过"稳定性设计。文档里白纸黑字写了：支持重试、有降级、有熔断。
但那只是术语装饰。
我从未定义过：什么情况算故障、重试几次该停、什么条件下必须熔断。
术语写进了文档，机制从未存在。
框架当装饰，是工程里最昂贵的自我安慰。
Layer 0 控制图：四个框，缺一不开工
从那以后我立了规矩：任何新的系统设计或外部集成，写第一行代码前，先画一张控制图。
四个框：
框一：被控对象（Plant）。你到底在控制什么？一次 API 调用、一条任务队列、还是输出质量？说清楚"正常运转"长什么样。很多集成的失败，源于从头到尾没定义过"正常"。
框二：观测什么。成功率、延迟分布、配额余量、输出质量抽查？注意采集成本——定义了一堆测不了的指标等于没定义。我的习惯：每个集成不超过三个核心探针，少而真。
框三：什么会扰动它。网络抖动、限流、配额耗尽、参数校验失败、第三方静默换行为——逐类列出。这步最大价值是逼你区分"可重试的暂时故障"和"重试一万次也不会好的永久错误"。很多惨案的本质，是对后者做了前者。
框四：怎么反应（控制律）。暂时性故障→指数退避重试，上限明确；参数错误→立即失败修调用方；配额耗尽→熔断排队告警；质量漂移→降级保守模式通知人。
控制律的本质是给系统装神经系统：有感受、有分级、有反射弧。
重做那次的控制图
后来我按这套纪律重做了那个生图集成，五分钟画完：
Plant：生图任务的成功率与时效。
观测：成功率探针 + 配额余量。
扰动分四类：网络抖动（退避重试上限三次）、参数错误（立即失败修调用方）、配额耗尽（熔断排队，恢复后放行）、质量漂移（抽查核验，降级告警）。
上线后它真的又出过故障。
但那次我是看着告警、按预案处理完的，全程从容。
同样的故障，有控制图和没控制图，是两种完全不同的体验。
产品经理为什么需要这个
PRD 里的"异常流程"章节，就是控制图的弱化版。
大多数 PRD 的异常流程写得潦草，因为没人认真做过 Layer 0。
三个直接好处：需求评审的问题质量暴涨（"第三方超时时用户看到什么"比"要不要加 loading"重要一百倍）；验收标准自动生成（每类扰动对应一条验收用例）；和工程师的对话回到同一层。
这套方法的实战应用见 API 防御性设计 和 静默降级——前者是控制图的"防御"面，后者是"观测"面。