H2.10.1unified hint priority across teams设计
多个团队的提示共用同一预算时需要统一优先级排序
别名: 提示抢配额 · 跨团队优先级 · shared hint budget · coaching governance
概念解释
提示剂量的上限是用户侧的一条通道。产品里若有多个团队各自发气泡、红点、更新条，他们共用这条通道的预算，却往往各记各的「我们这周只发了一次」。没有统一的优先级，预算会被最先上线或最会抢位的团队用光，而不是被最有用的那条用掉。这条谈的是组织如何给共用名额排序，不是单条提示会不会被习惯化，也不是渐进介绍在一个产品里要不要设会话上限。
机制
每个团队优化的是自己功能的曝光，通道的损坏记在谁都不背的账上。结果是局部理性、全局超发：增长要激活、功能要采用、市场要发版，三条「都很重要」的提示在同一天下午到达。用户只经历一条时间线，无法按团队分区习惯化。统一优先级把名额收成单一队列：同一时刻只允许一条自动提示，排序键是对当前用户、当前任务的预期价值，而不是发版日历或团队政治。没有这把键，预算数字写得再漂亮，实际分配仍是先到先得。优先级还必须能跨表面比较——气泡、底栏、邮件里的产品内提示，只要打断的是同一份注意，就进同一张表，否则「我们没用气泡」会变成逃避。
边界
法律与安全阻断不进教学预算的排序，它们走自己的强制通道，但要换皮肤，以免教程序列借安全的名义插队。用户主动打开的帮助不占自动预算。不同产品线若注意完全隔离（两套独立应用、用户不交叉），可以各有预算；同一壳里的多个模块不行。实验流量上的互斥提示仍要进排序，否则实验臂会在生产预算之外再打一枪。
怎么落地
- 建一张跨团队的自动提示登记表：谁发、对谁、打断哪一层、声称的价值，没有登记的不得上线。
- 名额按用户会话发放，排序由产品指定的单一规则执行（例如：阻断错误 > 当前任务失败补救 > 首次相关的核心能力 > 发版宣传），团队不得自批插队。
- 把气泡、底栏、红点、应用内横幅算进同一张表，禁止「换个表面就不计数」。
- 验证：抽一周，按用户列出实际弹出的自动提示及所属团队。若同一会话出现两条，或低优先级宣传排在当前任务补救之前，排序就没有在运行。