twitter

twitter skill 概览

twitter skill 能做什么

twitter skill 通过 twitterapi.io 帮你获取实时的 Twitter/X 数据，包括用户资料、推文、回复、粉丝、关注、社区、Spaces 和趋势。它最适合需要基于事实进行社交媒体查询，而不是靠生成式猜测的 agent。

适合谁安装

如果你需要 Social Media 工作流中的社交证明、账号调研、帖子上下文、受众核查或推文级分析，就应该安装 twitter skill。它适合希望直接从 Twitter/X 获取结构化答案，而不是手动打开应用逐条浏览的用户。

为什么它有用

它最大的优势是覆盖面广，而且接口可脚本化：一个 skill 就能处理用户、推文线程、关系检查以及发现/搜索类端点。这让 twitter guide 很适合快速核验、监测和内容研究这类场景，因为单靠 prompt 往往会漏掉精确 ID、限制条件或分页信息。

如何使用 twitter skill

安装并配置访问权限

按推荐流程安装：npx skills add ReScienceLab/opc-skills --skill twitter。然后在 shell 环境中设置 TWITTERAPI_API_KEY，因为这些脚本需要这个凭证才能调用 API。如果缺少该 key，skill 就无法拉取数据。

先看对的文件

先读 SKILL.md，了解支持哪些命令；然后查看 scripts/twitter_api.py 以及你准备运行的具体脚本。为了更快上手，还可以顺手看一下 scripts/credential.py 了解认证处理，以及 scripts/get_user_info.py、scripts/search_tweets.py 和 scripts/get_tweet_thread.py，它们覆盖了最常见的 Twitter 使用模式。

把模糊需求变成可执行的 prompt

好的输入要同时写清对象、查询类型和输出形式。比如：“Use the twitter skill to find recent tweets from @elonmusk and summarize the last 10 posts by topic and engagement signals.” 更进一步，你还应该明确自己要的是最新推文、回复、粉丝，还是关系检查，因为不同端点对应的标识符和限制条件都不一样。

提高结果质量的实用工作流

优先选择最贴近任务的最小命令：get_user_info.py 用于身份信息，get_user_tweets.py 用于发帖历史，search_tweets.py 用于主题发现，get_tweet_thread.py 用于会话上下文。做 Twitter/X 调研时，先验证一个单一可信来源，再按需扩展到回复、引用或粉丝等相关端点，补充支撑证据。

twitter skill 常见问题

twitter skill 能抓取什么？

它可以抓取用户信息、推文、回复、粉丝、关注、已验证粉丝、社区、Spaces、趋势、搜索结果和关系数据。如果某条帖子链接到长文内容，它还支持根据 tweet ID 提取文章。

twitter skill 只能用于 Twitter/X 帖子吗？

基本是，但它的能力不止于单条帖子查询。twitter skill 同样适合账号调研和网络关系上下文分析，这在你的任务关注影响力、受众或社区行为，而不只是某一条推文时尤其有用。

什么情况下不该用它？

如果你只需要随意概述、没有 API 访问权限，或者任务并不需要实时的 Twitter/X 数据，就不该用它。对于源材料已经在你自己的数据集里、无需外部查询的场景，它也不是好选择。

它适合新手吗？

适合，只要你从一个端点和一个清晰问题开始。新手通常先用 get_user_info.py 或 search_tweets.py 试跑，能得到更好的 twitter install 结果，然后在理解输入格式后再切换到更具体的脚本。

如何改进 twitter skill

给 skill 明确的对象和目标

最强的输入会直接写出用户名、tweet ID、community ID 或搜索短语，以及你想要的结果。比如：“Find the latest 20 tweets from @openai and group them by launch, research, and hiring” 就比 “analyze OpenAI on Twitter” 清楚得多。

让端点匹配问题本身

常见失败模式是笼统地问“Twitter activity”，却没有说明你要的是推文、回复、提及还是粉丝。要提升 twitter usage，先把需求映射到对应的脚本家族：搜索类用于发现，用户类用于资料/历史，推文类用于会话上下文。

加上真正重要的约束

当限制条件会影响答案时，就要明确写出来，比如时间窗口、数量上限和输出风格。你可以要求“last 50 tweets”“only replies”或“relationship between two accounts”，这样 skill 就不会返回太多噪音。对于 twitter for Social Media 调研来说，这一点尤其重要，因为时效性和来源类型都会改变结果。

用下一次查询迭代，而不是重来

拿到第一轮结果后，最好用第二个查询继续细化，而不是重新发一个大而泛的请求。如果某个用户资料看起来相关，就继续查粉丝或提及；如果某条推文很重要，就进一步看回复、引用和线程上下文。这样的工作流通常比一个过大的 prompt 更容易产出干净的最终答案。