Query Examples
真正适合监测和研究工作流的 Twitter tweet search query 示例
很多团队说自己要 search example，但真正缺的往往不是几个关键词，而是怎么把 query pattern 接进可重复工作流。真正有价值的示例，是那些后面还能继续 debug、分页和复核的例子。
1. 从具体搜索任务开始
launch monitoring、support triage 和 competitor review 虽然都用 tweet search，但通常不该共用一套完全一样的 query 结构。
所以真正有用的例子，通常都只对应一个 job 和一条 review path，而不是一次想覆盖所有 use case。
- 至少保留一条 brand mention 示例。
- 至少保留一条 competitor launch 示例。
- 至少保留一条 support 或 onboarding complaint 示例。
2. 把“为什么这条示例有效”一起保存下来
如果团队以后还看不懂这个示例为什么这样写，它就很难复用。通常需要一起保存：哪些词是必需的，哪些是可选的，以及它原本在规避什么噪音。
因为很多监测逻辑都会在第一轮真实复盘之后开始变化。
- 把 job 描述和 query 示例放在一起。
- 留一条预期噪音来源说明。
- 在 query 旁边保存一两条真实命中样本。
3. 让示例直接连到下一步复核
最有用的示例，通常不只是说明怎么搜，还会告诉团队结果命中后该怎么做。可能是 source review、timeline review、watchlist promotion 或 escalation。
没有这一步，很多示例最后只会停留在零散搜索片段。
- 给每条示例写明命中后的下一步。
- 标记它更适合 monitoring、research 还是 AI。
- 让 routing 规则保持后续可维护。
4. 把示例当 pattern 维护，而不是把字符串当永远不变
具体关键词会一直变，但示例真正有价值的是它背后的结构和所属工作流。
通常把示例 pattern 维护好、再持续刷新措辞，会比死守一条旧字符串更稳。
- 发布、改名或新 use case 出现后，更新措辞。
- 即使文字变化，示例分类尽量保持稳定。
- 给 query 示例保持统一命名方式。
这条流程跑出第一次结果后，团队接着会问的问题
这些通常会在 Twitter / X 数据流程不再只是一次性测试、而是开始长期跑任务时出现。
什么样的 search 示例值得长期保留？
通常是有明确 job、已知噪音来源，而且命中后下一步怎么处理也已经写清楚的示例。
是不是应该给每个 use case 都写一条示例？
通常不需要。一小组强工作流示例，会比一大堆互相割裂的 query pattern 更有用。
为什么这种示例页值得单独写一页？
因为这类页面回答的是团队真的会搜索、而且后面真的会复用的实现问题，比泛化产品话术更可信。
通常会一起看的实现页
如果你想看 query 设计背后的完整工作流，可以继续看这页。
如果你想看 search 能力页，可以继续看这页。
如果示例看起来没问题，但结果集还是不对，可以继续看这页。
如果 query 设计好了，下一步是 repeated collection，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。