工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 采用是用户获得价值，不是功能被渲染。漏斗需要把不知道、想用但失败、成功一次和形成习惯区分开，才能知道该优化发现还是可靠性。
产品闭环要覆盖开始、等待、取消、失败、恢复与再次进入，并保证自动化服从用户最后一次明确选择。指标应衡量任务结果，而不是按钮点击数量。
工程边界与取舍
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 事件使用短期伪匿名 cohort，曝光仅在功能真实可见时记录；success 由协议终态生成，repeat 在周级聚合且不采内容或对端关系。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“功能采用率怎么量：曝光、尝试、成功、重复使用和留存要分开”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 分母用所有注册用户会稀释只对已连接用户可用功能；只看成功事件又无法知道是没人尝试还是大量失败。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
把测试跑成闭环
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 用合成用户覆盖未曝光、曝光未点、尝试失败、成功一次和重复使用，验证各漏斗守恒且隐私删除后 cohort 不可反查。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。