Query 调整
如何判断你的 Twitter query 对当前 workflow 来说是太宽还是太窄
很多团队会一直讨论 query 写法，但真正的问题往往是 scope。太宽的 query 会制造 review drag 和 false positives，太窄的 query 会制造 coverage gap 和 suspicious-empty run。真正要看的，不是写法是否花哨，而是它是否匹配当前 review job。
1. 改语法前先定义预期命中集合
最有用的第一步通常是先写下“好的匹配长什么样”。没有这一步，团队很容易凭感觉收紧或放宽 query。
support monitoring、launch monitoring 和 competitor review，通常都需要不同的命中预期。
- 保留 wanted match 的样例。
- 写清楚什么算 noise。
- 把下游 review job 明确说出来。
2. 看看有没有“太宽”的典型迹象
如果 reviewer 经常跳过大部分结果、不断打临时标签，或者抱怨结果看起来很随机，这条 query 往往已经比任务本身更宽了。
太宽首先是操作层问题，然后才是技术问题。
- reviewer skip-rate 是很有用的信号。
- 反复出现低价值命中通常说明 scope 太宽。
- 大而吵的结果集通常需要更窄的 framing，而不是只堆更多 filter。
3. 看看有没有“太窄”的典型迹象
如果团队明明预期应该有讨论，却不断出现 suspicious-empty run，或者重要帖子老是在 workflow 外面被看到，这条 query 很可能已经太窄了。
这种问题往往表现为 coverage 缺口，而不是明显噪音。
- 记录 suspicious-empty run。
- 保存 query 没抓到的重要帖子样例。
- 检查 exclusions 或 required terms 是否过重。
4. 用可见的 review set 来调，而不是默默改
最稳的 query 调整方式，通常是保留一小组 signal set 和一小组 noise set，然后让每次改动都同时对比两边。
静默修改只会让后面越来越难理解 workflow 为什么变了。
- 保留 before-and-after 测试集。
- 记录每次 query change 的原因。
- 按 schedule 回看 query drift。
流程已经搭起来了，但复核习惯还不稳定时，团队常问这些问题
这些问题通常会在 Twitter / X 采集已经能跑，但人工复核层还没有完全定型时出现。
什么最能说明 query 太宽？
通常是 reviewer 大部分时间都在忽略低价值命中，而不是评估真正相关内容。
什么最能说明 query 太窄？
suspicious-empty run，以及重要帖子反复出现在 workflow 外面，都是很强的信号。
团队该怎么稳妥地调 query？
保留可见的 signal set 和 noise set，让每次改动都同时对比两边的 tradeoff。
这一层通常会一起看的页面
如果主要问题还是 query 结构本身，可以继续看这页。
如果 scope 过窄已经导致 suspicious-empty run，可以继续看这页。
如果 scope 过宽制造了太多 review noise，可以继续看这页。
如果你想拿更多 query 样例来对比，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。