Twitter 评论采集
输入 Twitter 帖子 ID,获取评论正文、作者信息及互动数据。
概览
讨论热度相近的帖子,评论里的关注点可能截然不同。Twitter 评论采集把指定帖子下的评论正文、作者标识、评论链接和互动数据整理成明细,便于同时观察用户说了什么,以及哪些表达获得了更多回应。
正文与评论编号一起保留,便于将主题归类、人工标注与原始评论对应起来。作者账号和评论链接提供回溯线索,互动数据为筛选重点评论提供参考,不替代对正文的判断。
数据说明
数据来自指定 Twitter 帖子的评论采集结果,按采集时间稳定返回,并依据评论编号去重。评论正文保留原语言,不翻译,也不生成情感标签。
评论时间保留原有时区偏移;发布时间和采集时间保持各自原有文本,不将三者视为同一时刻。互动数量反映记录中的值,缺失信息不应当作零。父评论编号本身不足以证明完整回复关系,因此不据此还原完整讨论树。
结果长什么样
每条普通记录是一条评论。首行为完整样例,第二行仅作形态展示,不代表另一条已验证记录。
| 评论编号 | 作者账号 | 点赞数 | 回复数 | 评论时间 |
|---|---|---|---|---|
| 2102029309472805246 | Yukikaze______ | 2 | 1 | Mon Sep 21 13:36:55 +0000 2026 |
| 2097152384166490297 | UlanziJapan | 0 | 0 | Tue Sep 08 02:37:46 +0000 2026 |
另有「评论正文」「评论链接」「分享数」「浏览数」及媒体信息等内容,可结合原文理解互动表现。
应用场景
- 整理内容反馈时,围绕「评论正文」做主题归类,再通过「评论链接」回看上下文,避免只凭高频词判断观点。
- 筛选重点评论时,结合「点赞数」「回复数」和「评论正文」挑选需要优先阅读的内容,不把互动数量直接等同于正面评价。
- 观察讨论参与情况时,按「作者账号」归集评论,并结合「评论时间」查看表达分布,识别反复出现的关注点。
适用边界
每次采集一个帖子的评论,采集数量可设为 1–1100 条;结果按指定数量截断,拉取保护容量为 100 页、每页 11 条,不保证达到指定数量。
- 适合用于
- 需要围绕指定 Twitter 帖子收集评论,用于内容反馈或互动分析。
- 需要保留评论正文和作者标识,形成可回溯的分析明细。
- 不要用于
- 需要按关键词搜索帖子或批量输入多个帖子——应使用对应的搜索或批量采集能力。
- 需要保证覆盖全部历史评论或还原完整回复树——本应用不作此保证。
失败处理
开发者声明的失败与重试处理方式,接入时建议一并写进系统提示词。
- 1鉴权失败时先检查凭证配置和接口访问权限,不要反复重试。
- 2每次重新提交都会创建新的采集任务;提交结果不确定时,先核查已有执行记录,避免重复提交造成额外成本。
- 3采集失败或超时后先检查帖子是否可访问,并适当减少采集数量;确认原因后再重新运行。
- 4没有评论结果时先核对帖子 ID 和页面实际情况;分析前识别无数据标记,不将空数据占位当作真实评论。
- 5部分成功时只分析已经返回的数据,不据此认定全部评论均已采集。
输入参数
调用本 App 需要传入的参数,与 manifest.json 的 input.schema 同源。
- Twitter 帖子 ID
postId必填string要采集评论的 Twitter 帖子的纯数字 ID,不填写帖子链接或搜索关键词。示例2102028592125473050 - 最多采集条数
commentsSpiderNum选填integer指定本次最多采集的评论数量,默认 10 条,可填 1–1100 条;实际返回不超过指定数量,也可能不足。范围1–1100默认值10
输出数据
单条记录的字段结构,与 manifest.json 的 output.schema 同源。
- 业务编号
bizIdstring采集结果携带的业务对象编号,按原值保留,不与内容编号或采集关键词合并。示例2102028592125473050 - 评论编号
commentIdstring评论的标识,用于识别同一条评论。示例2102029309472805246 - 评论正文
commentTextstring评论的完整文本,保留原语言、提及账号和换行。示例@YozoraWolf @RVyolie @KeitaroTR I already had over 1.4k Gear Artificing Catalyst, so I wasn't worried about losing one or two week worth of shop material. All I can say is that the experience may come with quite some frustrating moment, but feels rewarding in the end. It felt worth it to me - 评论时间
commentTimestring保留评论时间的原始文本及其中的时区偏移,不转换为其他时间格式。示例Mon Sep 21 13:36:55 +0000 2026
示例数据
以下示例按 output.schema 生成;未提供示例值的字段使用结构占位符。
{
"bizId": "2102028592125473050",
"commentId": "2102029309472805246",
"commentText": "@YozoraWolf @RVyolie @KeitaroTR I already had over 1.4k Gear Artificing Catalyst, so I wasn't worried about losing one or two week worth of shop material.\n\nAll I can say is that the experience may come with quite some frustrating moment, but feels rewarding in the end. It felt worth it to me",
"commentTime": "Mon Sep 21 13:36:55 +0000 2026",
"commentType": "1",
"commentUrl": "https://twitter.com/Yukikaze______/status/2102029309472805246",
"commentUserAvatarUrl": "https://pbs.twimg.com/profile_images/2071806778090700801/bq6bQl6I_normal.jpg",
"commentUserDisplayId": "Yukikaze______",
"commentUserId": "1890315900949262338",
"commentUserName": "Yukikaze",
"commentVideos": "<commentVideos>",
"contentId": "2102028592125473050",
"crawlTime": "2026-09-22T10:33:51",
"imageUrls": "<imageUrls>",
"keyword": "2102028592125473050",
"likeCount": "2",
"parentCommentId": "2102029309472805246",
"publishTime": "2026-09-21T21:36:55",
"replyCount": "1",
"shareCount": "0",
"viewCount": "9",
"task_item": "2102028592125473050",
"no_data": false
}调用方式
本 App 支持通过 MCP、API、SDK 与文件导出方式接入,各接入方式共享同一套能力与计价。所有请求统一使用 Authorization: Bearer 请求头完成身份认证,凭证为 API Key(长期有效,在开放平台创建);MCP 客户端另支持 OAuth 免密钥登录。CLI、Skill 等更多接入方式正在规划中。本 App 异步运行,支持中途取消:取消后任务停止;已写回的部分保留,按写回计费。
通过 MCP(Model Context Protocol)协议,可在 Claude、Cursor 等 AI 客户端中直接调用本 App。选择你的客户端与认证方式,复制下方配置即可接入。
客户端配置
把 Bearer 后替换为长期有效的 API Key 即可,各类客户端与 CI、无浏览器环境通用。
{
"mcpServers": {
"bazhuayu_datahub": {
"type": "http",
"url": "https://mcp-v2.bazhuayu.com?pin=SpiderKing999/twitter-comment",
"headers": { "Authorization": "Bearer <YOUR_API_KEY>" }
}
}
}让 AI 自己完成配置
不想手动改配置?复制配置提示词,粘贴到任意 AI 客户端对话框,由它按自身方式完成接入(提示词会让 AI 向你索要 API Key,避免凭证留在对话记录或共享配置里)。
如需在同一个 MCP 连接里指定多个 App,前往 MCP 连接页(已为你指定本 App)。
价格
按实际成功返回的数据条数计费,任务失败不计费。每 11 条为一个计费单位,不足 11 条按 11 条计。
每提交一次任务计费一次,与返回条数无关。
多个计费事件按各自口径独立累计,具体以每一项说明为准;任务失败不计费。
立即体验
填写参数直接运行,结果来自真实调用。