Pagination Guide
如何处理 Twitter 搜索分页以支持重复采集，避免每一轮都在清重复数据
一旦工作流不再只取一页结果，pagination 就会开始影响质量。很多团队都是在 repeated monitoring、深度研究拉取或 AI-ready dataset 里，才第一次意识到分页处理的重要性。
1. 先决定这条流程为什么需要更深分页
不是每条 Twitter / X search 任务都需要深分页。有些流程只需要最新信号，有些才需要更广覆盖去做分析或模型输入。
分页策略应该跟 monitoring、backfill、clustering 或 repeated review 的真实任务对齐。
- 先写清楚流程更需要 freshness 还是 depth。
- 告警型监测通常适合浅分页。
- 只有当后续分析真的需要时，才做深分页。
2. 保存 checkpoint，让下一轮更稳
每次都从零开始抓，很容易重复发现同一批结果。更稳的流程，通常会保存 checkpoint、last-seen marker 或时间窗口。
这一步会直接决定 repeated collection 到底好不好 debug。
- 每条 query 保存 checkpoint 或 last-seen marker。
- 保存 result id 用于 dedup。
- 把 backfill 和 ongoing monitoring 分开跑。
3. 分页深度要和 review 能力匹配
如果团队每轮只会 review 30 条高价值结果，就没必要每小时抓几百条低价值命中。
好的分页处理，最终还是要回到团队实际的复核和路由能力上。
- 让采集深度和人或 AI 的复核能力匹配。
- 优先让路由更干净，而不是量更大。
- 当多抓几页已经不改善判断时，就应该停。
4. 去重和 backfill 规则最好写清楚
大多数分页问题，不是 API 本身，而是重复结果、时间边界不清楚，或者把 exploratory pull 和 production monitoring 混在一起。
清楚的 dedup 和 run-type 规则，才会让这条流程长期可用。
- 给每轮采集标一个 run type，比如 monitoring、backfill 或 research。
- 每条保存的帖子都要有 dedup key。
- query 逻辑变化后，顺手复核去重规则。
团队在实现这条流程时最常问的几个问题
这些问题通常会在团队从单次测试走向可重复 Twitter / X 数据采集时冒出来。
监测流程一定要深分页吗？
通常不需要。很多监测流程只需要最新或最高优先级的一小段结果，而不是所有可能结果。
分页最常见的问题是什么？
通常是重复数据、checkpoint 不稳定，以及抓了太多团队根本不会复核的结果。
最稳的第一版实现应该怎么做？
先做一条小型 repeated collection loop，保存 result id 和 checkpoint，等复核流程稳定之后再逐步加深分页。
通常会一起看的实现型页面
如果 query 设计还没稳，先看这页更合适。
如果采集深度已经清楚，下一步是记录结构，可以继续看这页。
如果你怀疑问题不是分页，而是结果本身不对，可以继续看这页。
如果你想先看 repeated collection 背后的 search 能力页，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。