Pagination Guide
如何处理 Twitter 搜索分页以支持重复采集，避免每一轮都在清重复数据
一旦流程不再只取一页结果，分页就会开始影响质量。很多团队都是在重复监测、深度研究拉取或给 AI 准备数据集时，才第一次意识到分页处理的重要性。
2026-04-20
1. 先决定这条流程为什么需要更深分页
不是每条 Twitter / X 搜索任务都需要深分页。有些流程只需要最新信号，有些才需要更广覆盖去做分析或模型输入。
分页策略应该跟监测、补拉历史数据、聚类，或重复复核的真实任务对齐。
- 先写清楚流程更需要 freshness 还是 depth。
- 告警型监测通常适合浅分页。
- 只有当后续分析真的需要时，才做深分页。
2. 保存 checkpoint，让下一轮更稳
每次都从零开始抓，很容易重复发现同一批结果。更稳的流程，通常会保存检查点、最近一次看到的标记，或时间窗口。
这一步会直接决定重复采集到底好不好排查。
- 每条搜索条件保存检查点或最近一次看到的标记。
- 保存结果编号用于去重。
- 把补拉历史数据和持续监测分开跑。
3. 分页深度要和复核能力匹配
如果团队每轮只会复核 30 条高价值结果，就没必要每小时抓几百条低价值命中。
好的分页处理，最终还是要回到团队实际的复核和路由能力上。
- 让采集深度和人工或 AI 的复核能力匹配。
- 优先让路由更干净，而不是量更大。
- 当多抓几页已经不改善判断时，就应该停。
4. 去重和补拉规则最好写清楚
大多数分页问题，不是 API 本身，而是重复结果、时间边界不清楚，或者把探索式拉取和正式监测混在一起。
清楚的去重和任务类型规则，才会让这条流程长期可用。
- 给每轮采集标一个任务类型，比如监测、补拉或研究。
- 每条保存的帖子都要有去重键。
- 搜索逻辑变化后，顺手复核去重规则。
团队在实现这条流程时最常问的几个问题
监测流程一定要深分页吗？
通常不需要。很多监测流程只需要最新或最高优先级的一小段结果，而不是所有可能结果。
分页最常见的问题是什么？
通常是重复数据、检查点不稳定，以及抓了太多团队根本不会复核的结果。
最稳的第一版实现应该怎么做？
先做一条小型重复采集循环，保存结果编号和检查点，等复核流程稳定之后再逐步加深分页。
通常会一起看的实现型页面
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证帖子检索、账号复核或历史发言接入路径，并把输出接进稳定团队循环。