任务调度
如何调度 Twitter search collection 任务，既保持新鲜度又不浪费请求
调度设计，往往决定一条 Twitter / X workflow 是不是长期可用。好的 schedule 会同时反映信号变化速度、可用请求预算，以及团队究竟会如何处理每次 run 的结果。
1. 让 cadence 对应信号，而不是对应习惯
很多团队默认几分钟跑一次 search，只因为技术上做得到。更好的问题是：这个信号到底变化多快，以及有人会多快处理结果？
support queue、founder watchlist 和 weekly research digest，通常需要完全不同的 cadence。
- 按信号紧急程度设置 cadence。
- 把实时告警和慢速研究采集分开。
- 写清楚为什么这个频率已经够用。
2. 把 collection 和 enrichment 拆成不同的时钟
核心 search pass 往往需要比后续 lookup、timeline review 或 summarization 更紧的频率。
把这些阶段拆开，整条 workflow 会更轻，也更容易 debug。
- 让 core search 用最短但有意义的 cadence。
- 把 lookup 和 timeline enrichment 放到第二阶段。
- 不要默认每次 collection 都接一次 summary。
3. 让每次 run 的时间窗口显式可见
只有当每次 run 明确显示它覆盖了什么时间窗口，以及 checkpoint 怎么移动，这条 schedule 才真正值得信任。
这也是团队理解 gap、overlap 和 expected silence 的基础。
- 给每次 run 保存 evaluated window。
- 每次成功后记录 checkpoint movement。
- 让 gap 和 overlap 可回看。
4. workflow scope 变化时，顺手重看 schedule
一套 cadence 也许适合一开始的小 query set，但不一定适合后面更多 watchlist、更多 enrichment 和更多 alert routing。
稳的团队通常会在请求预算或下游动作明显变化时，顺手重审调度设计。
- job scope 扩大时，顺手审 cadence。
- 把 schedule 跟请求压力和下游负担一起看。
- 给 schedule 变更保留明确 owner。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
监测型 search job 应该多频繁跑一次？
这取决于信号变化有多快，以及团队能多快处理结果。更快不一定更好。
search、lookup 和 timeline review 该共用一个 cadence 吗？
通常不该。核心 collection 步骤往往需要和 enrichment、review 阶段不同的频率。
什么会让 scheduled run 以后更容易 debug？
显式的 run window、可见的 checkpoint movement，以及任务有意跳过某些阶段时留下的说明。
这一环通常会一起看的页面
如果 cadence 现在需要更干净的 checkpoint 模型，可以继续看这页。
如果 schedule 频率正在制造请求压力，可以继续看这页。
如果重复调度开始制造 duplicate review noise，可以继续看这页。
如果你想回到 search 能力页本身，可以继续看这里。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。