分流不是分类，而是选择下一步
给反馈贴上“Bug”或“功能请求”标签，并没有解决由谁处理、什么时候处理、还缺什么信息。有效分流的输出应该是：问题定义、证据质量、影响判断、负责人和明确下一步。
如果一条反馈离开分流队列后仍需要接手人重新理解，它只是被移动了，并没有被分流。
进入决策前需要的最小证据
- 用户目标与预期结果。
- 实际发生的行为和原始表述。
- 受阻工作流、频率、替代方案与后果。
- 客户、套餐、角色和相关账户价值。
- 产品页面、版本、模型、Prompt、Trace 或工具状态。
- 相似报告、首次与最近发生时间。
信息不足时，不要直接降低优先级。先问一个最可能改变路由或优先级的问题。
按照问题性质和所需动作路由
客服已有答案、临时替代方案、账户沟通或使用指导。
知识团队文档缺失、内容过期、检索来源错误或常见问题无法回答。
产品能力边界、工作流摩擦、功能取舍和跨客户需求。
工程可复现 Bug、性能问题、集成失败和明确 AI 回归。
安全 / 合规数据泄露、权限、滥用或法规风险，应绕过常规评分。
优先级要同时看影响和证据
评分至少应覆盖影响范围、严重程度、客户价值、增长速度、战略匹配和证据置信度。不要让高频但轻微的问题自动压过低频却阻断续费的失败。
把各维度保留在界面上。相同总分可能来自完全不同的风险形态，需要不同处理方式。安全、数据丢失和合规问题应使用硬规则直接升级。
让人工复核纠正系统，而不只是确认系统
团队应能标记信号为认可、薄弱或错误，并记录原因：分类错误、证据不足、重复聚类错误、影响被高估、已经解决或不符合战略。反馈结果应回到 Prompt、规则和 Eval 数据集。
- 只复核新出现、快速变化或越过阈值的信号。
- 打开代表性原始证据。
- 确认负责人和下一步。
- 记录什么信息会改变判断。
- 为待观察问题设置明确复查日期。
衡量分流是否减少了工作，而不是转移工作
- 从提交到明确负责人的时间。
- 决策就绪反馈的比例。
- 信号认可、薄弱和错误比例及原因。
- 接手团队仍需人工追问的次数。
- 认可信号的行动率。
- 因错误路由而退回或重复创建的比例。
真正好的分流，让正确团队更早看到完整案例，同时让其余噪音安静地留下作为未来证据。