Alert 路由
如何在 alert 里路由 Twitter search、lookup 和 timeline review，而不是每次都全量补齐
很多 alert workflow 会变得又贵又难解释，是因为每次命中帖子都直接触发完整 retrieval stack。更干净的设计，通常会按 discovery、source validation 和 deeper account context，把 search、lookup 和 timeline review 分到不同阶段。
1. 把 search 作为 discovery 和 trigger 层
在大多数 alert 系统里，search 的职责是先发现 candidate post 或 conversation。它更适合做 matching 和 triage，而不是一开始就回答所有来源问题。
这样 trigger stage 会更便宜，也更容易解释。
- 让 search 先决定这条 candidate 是否值得复核。
- 保持 trigger logic 可读而且收敛。
- 不要把深层 source 逻辑全塞进 search 阶段。
2. 只有 source identity 会改变决策时，再上 lookup
当 alert 是否升级，取决于这个账号是谁时，user lookup 才最有价值，比如 competitor、founder、partner 或 recurring research source。
这意味着 lookup 通常更适合放在 trigger 之后，而不是之前。
- 只有当 source type 影响优先级时才跑 lookup。
- 对明显低价值或无关命中，直接跳过 lookup。
- 保存 lookup 是否改变了 routing decision。
3. timeline review 更适合 promotion 和 escalation
当一条帖子不足以解释“为什么这个来源重要”，或者 alert 可能升级成 watchlist / narrative shift review 时，timeline review 才真正有意义。
这通常不是基础 alert trigger 那一层该承担的事。
- 把 timeline review 留给高价值 alert。
- 用 account history 来确认 promotion 或 escalation。
- 让 timeline stage 在 run record 里可见。
4. 在 alert payload 里保留 stage-level provenance
当接收方能看出这条 alert 只是来自 search，还是已经被 lookup 和 timeline enrichment 过，alert 就会更容易被信任。
这也会让后面的 debug 快很多。
- 标记每个 alert field 来自哪个阶段。
- 保存 lookup 或 timeline 是否真的执行过。
- 保留能回到各层 full record 的 link。
接口已经能跑，但流程还不稳时，团队通常会问这些问题
这些问题通常会在团队开始重复运行同一条 Twitter / X 任务之后出现。
每条 alert 都应该跑 search、lookup 和 timeline review 吗？
通常不该。大多数流程会因为 discovery、source validation 和 deeper context 分层而更干净。
什么时候 lookup 值得多跑一步？
当 source identity 会改变 routing decision 时，比如要区分 competitor account 和随机 mention。
什么会让 alert routing 以后更容易 debug？
一份能明确显示哪个阶段执行了、贡献了什么字段、以及为什么停在这里或升级的 payload 或 run record。
这一环通常会一起看的页面
如果你还在设计更大的 endpoint-choice 逻辑，可以继续看这页。
如果 source enrichment 阶段还不清楚，可以继续看这页。
如果下一步是把 stage provenance 放进 alert 本身，可以继续看这页。
如果你想看 promotion 流程里 timeline context 值得保留什么，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。