优先级排序
如何给 Twitter monitoring 结果做优先级排序，让团队先看到真正重要的帖子
当每条命中的帖子都进入同一个队列时，monitoring output 很快就会让人疲劳。priority scoring 不需要很复杂，但必须反映 source importance、match quality、workflow urgency，以及团队下一步到底要做什么。
1. 先定义“为什么这条值得看”
更好的 scoring system，通常会先定义少量显式原因，比如 competitor source、crisis keyword、founder watchlist 或强产品抱怨。
这样 reviewer 更容易理解它为什么浮上来。
- 只保留少量 priority reason。
- 让每个 reason 对应真实 workflow action。
- 把高优先级条件显式写出来。
2. 把 source、match quality 和 workflow urgency 一起看
有用的 priority model 往往不会只看一个维度。来自关键 source 的弱匹配，可能也值得看；来自低价值 source 的强关键词命中，反而不一定。
关键是让 tradeoff 可解释。
- 把 source importance 作为一个输入。
- 评估这条 post 和 rule 的匹配强度。
- 让 workflow urgency 影响最终等级。
3. 分数旁边最好保留解释
只有一个数字，很难 debug，也很难让 teammate 信任。哪怕只是保存一条短的 reason list，也会让 priority queue 好用很多。
这里可见性往往比数学优雅更重要。
- 保存这条结果为什么高分。
- 让最重要的一两项因素可见。
- 允许 reviewer 干净地表达和分数不同意。
4. 定期回看 priority drift
随着产品命名、watchlist 和 review goal 改变，原本有效的 scoring model 也会漂移。
最直接的信号，通常是 reviewer 是否在频繁手动改队列顺序。
- 审 repeated manual override。
- workflow 大改后重看 scoring。
- 给 score logic 变更保留 owner。
流程已经搭起来了，但复核习惯还不稳定时，团队常问这些问题
这些问题通常会在 Twitter / X 采集已经能跑，但人工复核层还没有完全定型时出现。
什么最该先决定优先级？
通常是 source importance、match quality，以及 workflow 对这条结果是否真的有后续动作。
priority scoring 一定要复杂吗？
不一定。小而清楚、可见的模型，通常比复杂系统更有用。
什么会让 scoring system 更值得信任？
每条结果都能解释为什么浮上来，再加上对 manual override 的定期复盘。
这一层通常会一起看的页面
如果高优先级结果现在需要更好的 alert output，可以继续看这页。
如果 routing stage 也应该影响 priority，可以继续看这页。
如果噪音命中正在拖垮队列，可以继续看这页。
如果你想看 score explanation 该放在哪层 run data，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。