Lookup vs Timeline Guide
什么时候该用 Twitter user lookup，什么时候该用 timeline API，不要把两个 endpoint 当成可以互换的东西
在产品文档里，user lookup 和 timeline 常常挨着出现，但它们解决的不是同一个问题。Lookup 更适合确认这个账号是谁，timeline 更适合理解这个账号最近一直在怎么说、值不值得进入工作流。
1. 当问题是“这个账号是谁”时，用 lookup
如果流程更关心 handle-level enrichment、角色判断或稳定账号记录，通常 lookup 才是更合适的第一步。
这在 watchlist、CRM 风格 enrich、founder monitoring 和来源分类里很常见。
- 用 lookup 做账号身份归一。
- 保存 handle、name 和 profile 层上下文。
- 把账号记录当成后续流程的稳定对象。
2. 当历史会影响判断时，用 timeline
如果一条命中帖子不足以判断来源是否重要、是否可信、是否值得升级处理，通常 timeline 才是关键。
这一步在研究、监测、竞品复核和升级处理流程里都很常见。
- 用 timeline 看重复主题和近期变化。
- 确认这个账号是不是持续在谈这个主题。
- 当一条帖子可能触发更大动作时，看历史更稳。
3. 如果一个答案已经够了，就不要两个 endpoint 一起拉
很多流程之所以变复杂，是因为团队在还不知道账号是否重要之前，就同时拉 lookup 和 timeline。
更稳的方式，是先只做能回答当前问题的最小 source-context 动作。
- 身份不清楚时，先 lookup。
- 历史表达才是问题时，先 timeline。
- 只有重要结果再升级到更深来源检查。
4. 把 endpoint 选择理由留在工作流里
真正决定可维护性的，不只是选了哪个 endpoint，而是为什么在这个步骤选了它。
把这个原因留在记录里，未来 debug 和交接都会轻松很多。
- 记录这个结果是 lookup-validated、timeline-reviewed，还是两者都做过。
- 当 source-context 判断重要时，留一条简短说明。
- 在相似流程里复用同一套标签。
团队在实现这条流程时最常问的几个问题
这些问题通常会在团队从单次测试走向可重复 Twitter / X 数据采集时冒出来。
只用 user lookup 能支撑监测流程吗？
通常不够。lookup 解决的是身份，timeline 才更常决定这个来源在一段时间里是否值得持续关注。
每个账号都要看 timeline 吗？
通常不需要。只有当历史会影响优先级、解释或路由时，timeline review 才真正值得做。
最稳的实现模式是什么？
先用 search 找帖子，身份成问题时补 lookup，一条帖子不够判断时再补 timeline。
通常会一起看的实现型页面
如果你想先看账号 enrich 背后的能力页，可以继续看这页。
如果你想先看 timeline review 背后的能力页，可以继续看这页。
如果下一步是搜索之后的实际复核流程，可以继续看这页。
如果这条流程正在走向账号 watchlist，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。