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