为什么票数和提及次数会误导
投票易于理解，却受到谁看见门户、请求如何表述，以及内部团队是否主动拉票的影响。一百票可能只是偏好；三个企业账户的报告，却可能揭示正在阻断续费的工作流。
频率还会隐藏重复。一次事故产生十条消息，不等于十个独立账户都遇到了问题。优先级判断必须先定义底层问题，再统计独立证据。
优先级的基本单位应该是一个拥有可检查证据的问题，而不是一个拥有投票数字的功能标题。
六个证据加权维度
影响范围独立受影响用户和账户，并根据用户群规模与相关性调整。
严重程度偏好、摩擦、任务阻断、数据风险、合规问题或完全故障。
客户价值留存、扩容、收入暴露、战略学习和工作流重要性。
增长速度信号是稳定、加速，还是刚好与版本或模型变更相关。
战略匹配解决问题是否支持产品选择的客户和差异化。
置信度来源多样性、上下文完整度、可复现性和反面证据。
保留每个分项。两个信号可能同分，一个来自广泛但轻微的影响，另一个来自范围窄但极高的业务风险，它们需要完全不同的响应。
一套实用的评分模型
每个维度按 0 到 5 分评分，再根据决策类型设置权重。事故响应应更重视严重程度和增长速度；Roadmap 规划则可以提高客户价值和战略匹配。
一个平衡起点是：范围 20%、严重程度 20%、客户价值 20%、增长速度 15%、战略匹配 15%、置信度 10%。转换为 100 分，只把它当排序工具，而不是自动决策。
- 低于 35：保留反馈，等待更多证据。
- 35–54：相关 Roadmap 或客服工作出现时复核。
- 55–74：指定负责人并明确响应。
- 75 及以上：立即调查或升级给相关团队。
为例外设置硬规则
安全问题、数据丢失、法律风险、严重无障碍故障或可复现宕机应绕过常规评分。模型应支持判断，而不是压制判断。
召开决策复盘，而不是反馈会议
- 只查看新出现、发生变化或越过阈值的信号。
- 打开最高优先级结论背后的证据。
- 问清楚什么信息会改变优先级。
- 选择负责人和下一步：调查、建设、沟通、观察或拒绝。
- 记录原因和复查日期。
- 结果变化后回访受影响用户。
这种结构可以防止热门请求吞噬每场会议，同时让正在出现的回归及时浮出水面。