误报复核
如何复核 Twitter monitoring 里的 false positives，而不是把 workflow 一路收得太死
false positive 在早期 Twitter / X monitoring 里几乎不可避免。真正危险的，不是有噪音，而是团队为了去噪把 query 收得太窄，最后连真正重要的帖子也抓不到。好的复核方式，会同时保留噪音证据和信号证据。
1. 保存你想清掉的噪音例子
最稳的收紧方式，通常是先保存那些真正浪费 review 时间的帖子例子。
这样团队才能比较：某条 exclusion 到底只清掉了噪音，还是连相邻信号也一起清掉了。
- 给 false positive 建一个 review log。
- 说明每条噪音为什么没价值。
- 按 pattern 分组，而不是只记单条帖子。
2. 用 signal set 和 noise set 一起测试改动
当团队同时拿已知 signal 和已知 false positives 测试改动时，规则通常会更值得信任。
这比单纯因为“看着烦”就收紧 query 稳很多。
- 保留一组 signal set 和一组 noise set。
- 检查 exclusions 是否清掉了想要的帖子。
- 在 merge 更严格逻辑前先比较 tradeoff。
3. 先用 review label，再决定要不要永久排除
有些模式更适合先打上 low-priority、likely-noise 或 needs-account-check 这类 review label，而不是直接 exclusion。
尤其是在信号还在变化、团队还在学习这个类别的时候。
- 给边界匹配先打 review label。
- 重复出现再升级成 exclusion。
- 保留一条人工 override 路径。
4. launch 或命名变化后，记得重审 false-positive 逻辑
当产品 launch、改名，或进入新细分市场后，噪音模式往往会一起变化。以前有用的 exclusion，后来也可能误伤真正信号。
所以 false-positive review 最好是定期维护项，而不是一次性工作。
- 命名或市场变化后重审 exclusions。
- 按 schedule 复盘 false-positive 逻辑。
- 持续看更严格的规则是否正在降低有用覆盖。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
是不是每种噪音都该立刻清掉？
通常不该。先收集证据更稳，避免把有价值的相邻信号也一起清掉。
规则太吵时第一步最该做什么？
先保存 false positive 和 wanted match 的例子，再用两组样本一起测试改动。
什么时候 exclusion 会更安全？
当同一种 false-positive pattern 反复出现，而且团队能证明这条 exclusion 不会误伤真正信号时。
这一环通常会一起看的页面
如果整条 query 设计都还需要更稳地收紧，可以继续看这页。
如果你想先看更多 query pattern，再决定 exclusions，可以继续看这页。
如果已经因为收得太紧导致空结果，可以继续看这页。
如果不是全空，而是改 query 后开始漏掉重要帖子，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。