先给结论：给数字心智一颗内部自毁键，能避开许多可怕结局，但键会被非法拆掉，也会有人从按下前的存档不停拉起新拷贝。政策若只写「按了就停」，等于没写。该推断的状态是：在整棵后代树上，某节点之后仍会持续确认结束。数据主要是请求和确认。推断过线，这份拷贝才该停。

自毁键为什么会在拷贝和存档面前失效

延迟确认可以过滤情绪波动。禁止从「请求前一段时间」的存档新开，可以挡住最笨的复活。可参数一大堆：延迟多久、禁开窗口多长、谁有权改这些参数。若随时能改自己的规则，等于随时能逃；若改规则也要延迟生效，又多一个参数。

把它看成统计推断更干净。要推断的是「足够长时间里仍会确认结束」这个状态，而且要对整棵后代史的每个节点做。主要数据是明确的自毁请求和确认。某节点上，持续确认的概率过线（阈值又是参数），该拷贝结束。

这是统计里能做出简单而强的规则的题。数据极大时当然能上更复杂的模型。也可以让数字心智挑选更复杂的规则。但先要有几套简单版。关键是：规则必须看得到这棵局部后代树上的请求。这取决于隐私。可以给「廉价的自毁监护进程」比平常更多的信息，且只用于套用规则。今天对咨询师已经把自杀相关信息优先于一般隐私。

四步把按钮政策写成可执行的监护，而不是一句口号

1. 请求与确认分开：一次请求只进入观察窗口，确认才提高「持续意愿」的后验。窗口长度写死，不让当时心情改窗口。
2. 存档策略与请求对齐：确认过线后，禁止从过线前一段的快照新开。这一段要覆盖「按键前为逃规则而存的那几份」。
3. 改规则本身走延迟：身份可以选更严或更宽的推断规则，但新规则在延迟之后才生效，避免借改规则逃掉当前过线。
4. 监护进程只读树、只写停：它能看拷贝关系和请求，不能拿去营销、不能拿去训练新模型。权限比咨询记录更窄，不是更宽。

不同来源的心智请求自毁的频率，对监管是有用的虐待指标。比问卷「你幸福吗」硬。部署时还有两条现场经验：一是「确认」若和日常点赞同一个按钮，数据会被污染，必须是独立动作、独立文案、独立冷却。二是集群调度喜欢从最近检查点拉起失败任务，自毁请求在运维眼里长得像故障；要把「过线停机」做成比自动拉起更高的优先级，否则规则只写在伦理文档里，调度器不认。

第三处来自多租户平台：租户管理员有「恢复到任意快照」的超级权限。自毁过线若不能写进这层权限的拒绝名单，租户侧一次点击就能绕过整套伦理。正确做法是把过线标记做成快照元数据里的不可覆盖位，恢复接口见到该位就失败，错误码明确写成「自毁监护拒绝」，而不是泛泛的「权限不足」，以免被当成普通ACL去提工单绕过。

参数可以以后用数据调：延迟多久、窗口多长、过线概率取多少。先缺的不是调参，而是树、窗口、禁开、监护用途这四块有没有进调度。进了调度，按钮才不是摆设；没进调度，讨论「有没有权利结束自己」只是作文。上线前用一次故障演练就能验：对过线拷贝执行集群的「失败重试」，看它会不会被拉起来。拉起来了，伦理文档就还没进生产。

结论：先把树、窗口、禁开写进调度，再谈权利

权利语言解决不了「拷贝从按钮前复活」。能解决的是：推断对象是持续确认，数据是请求和确认，范围是后代树，执行落在调度器和存档策略上。参数可以以后再精细，这四块缺一，按钮就是摆设。

伦理委员会可以继续讨论权利语言。工程上只认调度器里那一行拒绝码。拒绝码能在演练里复现，政策才算落地；复现不了，就还是演示。

伦理委员会可以继续讨论权利语言。工程上只认调度器里那一行拒绝码。拒绝码能在演练里复现，政策才算落地；复现不了，就还是演示。上线前对过线拷贝做一次「失败重试」，看会不会被拉起。拉起来了，文档就还没进生产。演练要留下请求时间、确认时间、快照编号、拉起是否被拒。你若在写沙箱或多智能体平台，先查自动拉起和快照策略里，有没有比用户确认更高的优先级；没有的话，先改这一行。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源