你希望永远用不上的「紧急停止开关」（但依然必须构建）
紧急停止开关是你将会构建的最无聊的东西，也是你不可或缺才能上线的东西。
我见过 AI 在生产环境出问题时会怎样。不是那种戏剧化的版本，而是那种缓慢、昂贵的版本。模型开始表现异常，输出开始变得古怪，而团队唯一的选择就是手忙脚乱：拔掉集成、关掉接口、打电话给供应商。每一个选择都要花时间，而错误行为每多运行一分钟，都在不断叠加——错误答案传到客户那里，脏数据污染了数据管道，错误的决策被当作正确的记录在案。
紧急停止开关就是应对那种手忙脚乱的答案。它是一条预先构建、经过测试、无聊的路径，让你在损害叠加之前停掉系统。你希望永远不用拉下它；但如果你不带它就上线，那就是不负责任。
紧急停止开关到底是什么
紧急停止开关不是一样东西，而是三样，分别应对不同的情形。
软停止：让新的请求不再抵达模型。进来的流量暂停，模型停止工作，而所有已经在途的工作都会完成。这是日常用的开关——当升级率飙升、漂移告警触发、审核队列被淹没时，你拉下的就是它。什么都不会丢失，系统只是暂停，让你有时间查看。
回滚：回到上一个已知可用的版本。模型变了、提示词变了、配置变了——而「变化」正是问题所在。回滚就是把上一个版本放回去。这是应对最常见故障模式的开关：那次比被它替换掉的版本更糟糕的升级。
硬停止：终止一切，包括在途的工作，并隔离系统。这是紧急开关——用于那种「继续任何事，哪怕是完成已经开始的事，都比失去它更糟」的情形。硬停止关乎爆炸半径。当你拉下它时，你是在说：再多输出的代价，超过了中断工作的代价。
紧急停止开关是三条路径：暂停、回滚，或硬停止。每一条都是预先构建、经过测试、无聊的——所以当那一刻到来时，它会成为你整周里做起来最轻松的一件事。
爆炸半径的设计
紧急停止开关只有在「有作用域」时才有效。设计问题不只是「我们能停掉 AI 吗」，而是「我们能否只停掉出问题的那部分，而不停掉其余一切？」
系统是有爆炸半径边界的。面向客户的路径是一个半径，内部分析路径是另一个，批处理管道是第三个。好的紧急停止开关设计，会在每个边界处都设置开关，这样面向客户路径上的故障，就不会拖垮那些运转正常的内部工具。一个只能「停掉一切」的团队，实际上是什么都不会停的团队，因为停掉一切代价太高。
作用域来自架构。每个集成点都有自己的开关——模型调用、提示词模板、路由规则、审核队列。每个点都设一个开关，意味着你可以停掉坏的模型而不停掉好的，停掉坏的提示词而不停掉模型。这些开关在构建时加很便宜，而在事故之后想干净利落地补上，几乎不可能。
让它真正生效的测试
一个从未被测试过的紧急停止开关，等于不存在。你第一次需要它的时候，绝不是用来发现「它不工作、它要花一小时、或者那个知道怎么操作的人正在度假」的时候。
测试纪律与任何应急系统一样：按计划、无聊、当作例行公事。每月拉一次软停止，验证流量能干净地暂停；每季度在预发布环境演练一次回滚；每年做一次端到端的完整硬停止演习，并让真正会执行它的团队参与。
演习同时也是训练。一个在演习中拉过软停止的人，在真事发生时，会清楚地知道那是什么感觉。一个演练过硬停止的团队，不会在决策的瞬间僵住。演习，正是把紧急停止开关从「一个功能」变成「一种能力」的东西。
决策框架
紧急停止开关最难的部分不是构建它，而是决定拉下它。这个决定是有框架的，而且应该写在事故之前，而不是事故之中。
当信号表明系统正在退化时——升级在上升、漂移在攀升、置信度在下降——甚至在错误对客户可见之前，就拉下软停止。软停止很便宜，尽早使用它。
当「变化」是可能的元凶时，就拉下回滚。新模型、新提示词、新配置，而行为随之改变——先回滚，再调查。回滚是恢复服务最快的方式，而且在一个正常运转的系统上做调查也更容易。
当损害的累积速度超过了诊断的速度时，拉下硬停止。这是那种罕见的情形：继续比停止更糟，而停掉一切是限制爆炸半径的唯一手段。框架被写下来，就是为了让决策由「规则」做出，而不是由「当下」做出。
紧急停止开关是 AI 系统中最无聊的部分，而这恰恰是它最重要的原因。构建那三条路径，把它们限定在爆炸半径之内，按计划测试它们，并在你需要之前写下决策框架。你希望永远不用拉下它；但到了你需要它的那一天，它必须成为你整周里最轻松的决定。