把推特列表当数据源：那个没人用代码去查的精选信息流
把推特列表当数据源：那个没人用代码去查的精选信息流
列表是 X 上最老、却几乎没人用代码去读的功能，这很奇怪，因为★列表恰恰已经解决了主题监控里最难的那个问题：判断哪些账号才算数。★
关键词搜索返回的是"谁用了这个词"。 列表返回的是★"谁被一个人判定为属于这里"★ —— 而在窄主题上，这个差别就是全部。
窄主题上列表为什么胜过关键词
关键词监控有两种失败模式，而列表没有：
1. 它抓的是词，不是主题。 ★搜一个词会返回所有用了它的人，包括垃圾信息、玩笑，以及不相关的同形词。★
2. 它漏掉那些从不使用该词的从业者。 一个专业人士在谈论自己的领域时，往往不会点出领域的名字 —— 他们只是在谈。★关键词搜索完全看不见他们。★
列表把这件事反了过来： 有领域知识的人挑好了账号，所以★不管某一条帖子里有没有你的关键词，你都能拿到他们的帖子★。
| 关键词搜索 | 列表时间线 | |
|---|---|---|
| 选择依据 | 谁用了这个词 | ★一个人的判断★ |
| 噪音 | 高 | ★低★ |
| 会漏掉 | 不点名领域的从业者 | 没人加进来的账号 |
读一个列表的时间线、成员和订阅者是三个调用 —— 全部公开。
读一个列表
import requests
BASE = "https://api.socialapi.tech"
KEY = "your_api_key"
HDRS = {"X-API-Key": KEY}
def read_list(list_id, limit=100):
"""一个公开列表的时间线、成员和订阅者。"""
def get(path, **extra):
r = requests.get(f"{BASE}{path}",
params={"list_id": list_id, **extra},
headers=HDRS, timeout=60)
r.raise_for_status()
return r.json()["data"]
return {
"posts": get("/v1/list/timeline", limit=limit),
"members": get("/v1/list/members", limit=limit),
"subscribers": get("/v1/list/subscribers", limit=limit),
}
L = read_list("1234567890123456789")
print(f"{len(L['members'])} 个成员 · {len(L['posts'])} 条帖子")
★成员那个调用是被低估的那个。★ 一个列表的成员，就是一批围绕同一主题、预先筛选好的账号 —— 而你可以把这些用户名拿走用在任何地方，与这个列表本身无关。
★订阅者告诉你的东西，成员告诉不了★
成员是策展人挑的。订阅者是那些觉得它值得关注的人。
★第二个信号是一个策展人自己没写出来的质量分。★ 一个 40 成员、8,000 订阅的列表，被很多人验证过；一个 40 成员、3 个订阅的，没有。
两个实际用途：
- ★在决定基于哪个列表干活之前，按订阅数给候选列表排序★
- 把订阅者当作一个发现池 —— ★会订阅一个垂直列表的人，用行动表明了自己对这个垂直领域感兴趣★
读一个列表是三个调用 —— 时间线、成员、订阅者。
⚠️ 注意： 订阅数偏向年龄。一个老的平庸列表可能比一个新的优秀列表订阅更多，所以★把它当作一个信号，而不是一个排名★。
列表的短板在哪
这一点要说清楚，因为它决定了这个做法适不适合你：
1. 没有列表搜索。 ★你没法查询"给我找关于半导体的列表"。★ 发现是那个短板 —— 你通过资料页、链接，或者偶然注意到才能找到列表，而一旦找到，里面的一切都能读。
2. 成员会过期。 ★一个 2023 年整理的列表，反映的是 2023 年谁重要。★ 没有人会去修剪它们，所以在信任这批账号之前，先看看成员最近还活不活跃。
3. 你没法查一个账号被哪些列表收录。 发现的方向是 列表 → 成员。★反向查询不存在★ —— 这是一个真实的限制，不是谁的疏忽。
★诚实的总结：拿到 ID 之后列表非常好用，而在帮你找到一个 ID 这件事上它毫无帮助。★
大家会问的问题
推特列表是什么？ 一批被整理到一起的账号，他们的帖子汇成一条时间线。★任何人都能建。★
怎么用代码读一个列表？ 三个以列表 ID 为键的调用 —— 时间线、成员、订阅者。
列表 ID 在哪找？ 在列表的 URL 里。 ★每个调用都需要它★，而且没有办法搜索到它。
能搜索列表吗？ ★不能。★ 不存在列表搜索端点 —— 这是这个做法的主要弱点。
能看到一个列表里有谁吗？ 公开列表可以 —— 成员调用返回完整资料。
能看到谁订阅了一个列表吗？ 能 —— ★而且订阅数是一个有用的质量信号★，是策展人自己没写出来的。
能查一个账号在哪些列表里吗？ 不能。 ★反向查询不存在。★
列表和社区是一回事吗？ 不是。 ★列表是在别人时间线之上的一个视图；社区是帖子真正存在的地方。★
该用列表还是关键词搜索？ ★知道哪些账号重要就用列表；不知道就用关键词。★ 两者的失败方向是相反的。
列表为什么噪音更低？ 因为选择是人做的。 ★关键词搜索背后没有任何判断。★
能持续监控一个列表吗？ 能 —— 轮询时间线做差集 —— 和关键词监控是同一个模式。
能用接口创建列表吗？ 不能。 ★创建是写操作，而我们是只读的。★
能用接口添加成员吗？ 不能 —— 同样的原因。
私密列表能读吗？ 不能。 ★私密列表对所有人保持私密★，和受保护账号是同一条边界。
一个列表能有多少成员？ 能到几千。 ★用游标翻页，不要假设一次能取完。★
列表时间线包含回复吗？ 一般是成员的帖子 —— ★在计算内容量之前，先确认回复算不算在内★。
能导出一个列表的成员吗？ 能 —— 翻页然后写出来 —— 导出模式。
列表成员的顺序有意义吗？ 不要假设有。 ★按 ID 索引★，不要按位置。
怎么找到好的列表？ 通过那些已经在这个领域里的人的资料页。 ★从业者会在自己的主题上整理列表。★
一个列表有多新？ 取决于它的策展人有多勤。 ★去看成员最近的发帖情况★ —— 过期的列表和新鲜的长得一模一样。
能知道一个列表什么时候更新的吗？ 不太可靠。 ★改用成员的发帖新鲜度去推断。★
该自己建列表还是复用别人的？ 先复用，再自己整理。 ★别人的列表是你账号集合的一份免费初稿。★
能只拿成员、不要列表吗？ ★能，而且往往应该这么做★ —— 成员才是有价值的部分；时间线只是一个便利。
列表里的帖子和账号自己时间线上的不一样吗？ 同样的帖子，只是聚合了。 ★不存在单独的内容。★
能拿列表的历史帖子吗？ 能翻到底层时间线所允许的深度 —— 存档限制。
列表和直接关注那些账号有什么区别？ ★列表不影响你自己的时间线★ —— 你可以读它而不关注任何人。
能合并多个列表吗？ 能，在本地做 —— 取回多个再合并，★按账号 ID 去重★。
订阅数是个好的质量指标吗？ ★方向上是★，但它偏向更老的列表 —— 当作一个信号看。
列表适合做竞品追踪吗？ 非常适合，而且★一个你自己维护的列表，胜过一个你不停调优的关键词查询★。
用列表最大的一个错误是什么？ ★信任一份过期的成员名单。★ 在基于这批账号干活之前，先确认他们还活跃。
简短版
★列表是 X 上唯一一个「已经有人替你回答了『这个主题下哪些账号才算数』」的地方 —— 而那正是主题监控里最贵的那部分，被免费送了出来。★
关键词搜索抓的是词；列表抓的是主题。 ★一个从不点名自己领域的专业人士，对搜索是隐形的，对列表是完全可见的。★
我们的 API 按 ID 读列表的时间线、成员和订阅者，大列表带游标。★成员那个调用才是值得去拿的★ —— 一批预先筛选好、可以用在任何地方的账号集合。只读、固定按次价格。
它的短板，直说： ★没有列表搜索，也没有反向查询★。拿到 ID 之后列表非常好用，而在帮你找到 ID 这件事上毫无帮助。
延伸阅读：社区和列表有什么不同 · 什么时候关键词监控才是对的工具 · 按简介找账号 · 导出你采集到的东西。