Alert Payload Guide
如何设计 Twitter 监测 alert payload，让 alert 离开采集器之后依然好理解
很多 Twitter / X monitoring workflow 是在 alert payload 这一步开始分化的。有些 alert 离开 collector 之后依然很清楚，有些则马上变成没人想点开的噪音。关键在于保留够用上下文，而不是把所有字段一股脑塞进去。
1. 先从 triage 问题出发
一个 alert payload 最好能快速回答第一层 triage 问题：发生了什么、为什么重要、完整上下文在哪里。
这样接收方通常就能判断这件事该升级，还是可以先等等。
- 说明命中了什么以及为什么触发。
- 保留 source 和时间上下文。
- 给出能回到 full record 的 link 或 reference。
2. matched rule 或 query 最好显式保留
很多团队收到 alert 时，已经不知道它是被哪条 query、rule 或 watchlist 触发的，这会让后面的 debug 非常难做。
当 retrieval context 直接出现在 payload 里时，alert 会明显更有用。
- 保留 matched query 或 rule name。
- 显式写出 alert type。
- 需要时保留 workflow stage 或 queue 信息。
3. 保留最小但够用的来源上下文
payload 通常不需要整条 raw record，但往往需要 source handle、post URL，再加一条“这个来源为什么重要”的短说明。
这些信息会让 triage 快很多，也减少接收方盲点。
- 保留 source handle 或 account identity。
- 保留 post URL 或稳定 reference。
- 保留 competitor、founder、watchlist 之类的短标签。
4. 多类 alert 尽量复用同一套 base shape
不同 monitoring job 的触发条件可以不同，但 payload 如果能复用同一套基础结构，团队的消费速度会快很多。
这也会让后续自动化更容易。
- 尽量让不同 job 共用一套 base alert structure。
- 只有必要时再加少量 job-specific 字段。
- 随着 alert 范围变大，顺手 audit payload drift。
这条流程跑出第一次结果后，团队接着会问的问题
这些通常会在 Twitter / X 数据流程不再只是一次性测试、而是开始长期跑任务时出现。
最小 alert payload 里通常该放什么？
通常是 matched rule、source identity、post reference、timestamp，以及回到 full stored record 的指针。
alert payload 需要塞进完整 raw result 吗？
通常不需要。alert 最好保持 triage-friendly，完整细节由 full record 承担。
为什么 alert payload 对 AI 也重要？
因为很多 AI summary、escalation note 或 routing agent 的第一份输入，往往就是这类 triage-friendly payload。
通常会一起看的实现页
如果 alert payload 背后还需要一份稳定 stored-record schema，可以继续看这页。
如果你想先决定哪些字段值得进 alert，可以继续看这页。
如果这个 payload 后面还要喂 AI summary 或 routing，可以继续看这页。
如果 alert 触发依赖稳定 repeated collection，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。