Checkpoint Guide
如何给 Twitter 监测任务设置 checkpoint，避免每一轮都像从头开始
checkpoint 是 repeated Twitter / X monitoring 里最不显眼、但最影响稳定性的部分之一。真正稳的 repeated run，往往都是靠清楚 checkpoint 逻辑撑起来的。
1. 让 checkpoint 跟真实节奏走
每天跑一次的 founder watchlist 和每小时跑一次的 mention-monitoring，通常不适合用同一套 checkpoint 逻辑。
真正稳的 checkpoint，应该跟流程运行频率和团队复核能力匹配。
- 先写清楚 monitoring cadence。
- checkpoint 粒度跟 cadence 对齐。
- research pull 和 production monitoring 尽量分开设计。
2. 把 checkpoint 存在 query 或 job 旁边
当 checkpoint 明确挂在某条 query、rule 或 monitoring job 下面时，debug 会容易很多。
团队更容易看懂为什么这一轮抓到了这些结果。
- 每个 repeated job 最好有自己 checkpoint。
- checkpoint 和 query / rule name 放在一起。
- 保留最近更新时间，方便后面 debug。
3. 把 checkpoint 问题和 query 问题分开排
有些结果缺失，看起来像 query 写坏了，其实是 checkpoint 规则有问题。把这两种失败模式分开看，会让维护轻松很多。
这一步通常能减少很多无效改动。
- query 和 checkpoint 独立 debug。
- checkpoint 改动后留一条简短说明。
- 用已知 repeated example 测试 checkpoint 行为。
4. collection 深度变化时，顺手复核 checkpoint
pagination、dedup 和 cadence 变化，都会影响旧 checkpoint 是否还成立。
所以稳的 repeated collection 通常会把 checkpoint review 当成维护的一部分。
- pagination depth 变化后，顺手复核 checkpoint。
- dedup 规则变化后，也顺手复核 checkpoint。
- 保留一条小型 checkpoint 调整审计记录。
这条流程跑出第一次结果后，团队接着会问的问题
这些通常会在 Twitter / X 数据流程不再只是一次性测试、而是开始长期跑任务时出现。
checkpoint 为什么会这么重要？
因为它决定 repeated monitoring 到底是越来越稳，还是每一轮都在重新发现或错误跳过结果。
每个 job 都需要自己的 checkpoint 吗？
通常需要，因为不同 job 的 cadence、深度和 review 能力往往不一样。
最稳的第一版 checkpoint 怎么搭？
先只给一条 repeated monitoring job 配 checkpoint，把它挂在 query / rule 旁边，确认下一轮能抓到干净的增量结果。
通常会一起看的实现页
如果 checkpoint 需要和 pagination 一起设计，可以继续看这页。
如果 checkpoint 和 dedup 需要一起设计，可以继续看这页。
如果你怀疑当前 checkpoint 正在挡掉结果，可以继续看这页。
如果 retrieval logic 本身还不稳，先看这页更合适。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。