Z2.03.2Threshold setting as a product decision设计研究
阈值设定是产品决定
别名: 工作点选择 · operating point · 阈值即政策
概念解释
误报与漏报的平衡点没有技术上的正确解：同一套硬件，把阈值调敏感或调迟钝，是两个都可行的产品立场——「安全优先」还是「安静优先」，「宁可多问」还是「别来烦我」。把阈值说成「算法自动决定」，是把一个价值判断藏进了技术术语后面。阈值即政策。
这不是修辞观察：默认阈值决定了用户对这个功能的第一印象与信任基线，从而决定功能是被留下还是被关掉。它是产品行为，应当走产品决策的流程与责任。
机制
阈值在ROC 曲线上选工作点——技术上任何点都能实现，区别只在后果的分配：谁被吵到、谁承担漏掉的风险。三个机制让「默认值」远比它看起来重要：
- 默认即基线：多数用户从不改设置，出厂阈值就是事实上的终身政策——它不是建议，是执行。
- 第一印象塑造信任：头几天误报密集，用户关掉功能且不再回头；头几周过于安静，用户在真正的事件面前不信任它。工作点直接写进用户的系统心智模型。
- 责任与合规进入阈值：烟火、一氧化碳的报警阈值有强制标准可依；儿童监护、跌倒检测则处于空白——同一产品线里，自由裁量的部分恰恰是后果最模糊的部分。
「算法决定」的说法之所以流行，因为它对双方都省事：工程团队免于论证后果分配，产品团队免于为告警频率签字。代价是问题在故障时刻以「产品怎么这样」的形式返回，没有任何人认领。
怎么研究
- 用户对工作点的感知：智能家居与告警系统的访谈研究一致发现，用户能清晰区分「太敏感」与「不可靠」两种抱怨并据此取舍（关掉 vs 弃用），说明工作点是可被用户读取的产品态度而非技术细节。
- 警报管理标准的演化：医疗警报管理从「更多警报更安全」转向分级与削减，临床上可追溯的标准过程——工作点调整被制度化为治理对象，可作其他领域的参照。
- A/B 与长期跟踪：不同默认阈值的对照组比较功能留存、告警忽略率与漏报代价，是直接度量工作点后果的设计。
方法论注意点：短期实验室评测天然偏袒敏感设置（受试者被要求找事件，误报可容忍）；工作点的真实后果要在数周的家庭使用里度量——第一周与第十周的最优阈值经常不同。
边界
- 不是所有阈值都自由。 涉及生命安全且有强制标准的（烟火、一氧化碳）按标准执行，产品立场没有裁量空间；有裁量的是标准未覆盖的灰色地带。
- 「全交给用户调」不是答案。 调整入口解决的是家庭间差异（同组另一条的事），默认值的重要性不被它削减——多数用户从不调，默认仍是主要工作点。
- 阈值不是一次定终身。 软件更新会动模型、动阈值，产品立场可能在用户不知情时被改变——阈值变更需要与初设同级的评审。
怎么落地
- 为每个检测功能写一句产品立场声明（「宁可多问一次也不漏」/「安静优先，漏报用户自理」），进需求文档、过团队评审——让价值选择留下责任人。
- 默认阈值按最脆弱用户校准：独居老人与合租青年的最优工作点不同，产品定位决定取谁；说不清取谁，说明定位还没想清楚。
- 阈值与检测模型的变更走产品评审而非纯算法调参；对用户明示「这次更新改变了灵敏度」。
- 验证办法：新默认上线后跟踪三个量的移动——告警忽略率、功能留存率、漏报回测率。忽略率上升=太敏感；留存下降+用户抱怨「不可靠」=太迟钝；两个方向都要有人看板。