Twitter / X API for Linear
把 Twitter/X 上的公开 bug 和反馈送进 Linear，但别把路线图塞满噪音
产品团队不需要把每个品牌提及都放进 Linear。真正有价值的是那些明确描述 bug、反复出现的使用痛点、来自合适用户的功能请求，或者值得产品复盘的发布问题。TwtAPI 提供搜索、作者上下文、近期时间线、去重和带来源的输出，让团队先判断一条公开 Twitter/X 信号是否值得变成 Linear 工单、Customer Request、Intake 项、Slack 复核项或每周产品反馈摘要。
快速结论
先看这页最重要的判断
如果你只是想先判断这条路线适不适合自己，先看这几条就够了。
Linear 应该接收产品信号，不是原始社媒噪音
有用的流程不是“发现一条推文，就创建一个工单”，而是先形成一个能被产品团队判断的信号。
- 保留推文 URL、作者、命中关键词、产品模块、客户线索，以及为什么值得看。
- 一条推文可能是真 bug、一次性抱怨、误解、竞品噪音，也可能完全没价值。进 Linear 前要先分开。
- 搜索产品名、报错短语、坏掉的流程、发布抱怨、功能请求、竞品对比和客户痛点。
- 他们想把反复出现的公开需求、使用抱怨和竞品切换信号，变成可以复核的产品反馈或客户请求。
决策指南
这页应该帮你做出什么判断
适合使用这条路线
他们想把反复出现的公开需求、使用抱怨和竞品切换信号，变成可以复核的产品反馈或客户请求。
先不要用这条路线
如果这只是一次人工查看，或者团队真正需要的是现成 dashboard、席位、报表和审批流程，先比较 SaaS 工具再决定是否接 API。
第一步验证
从公开 bug 报告、发布问题、集成错误、价格投诉、流失信号或功能请求开始，不要一上来监控所有品牌提及。
成功信号
一条推文可能是真 bug、一次性抱怨、误解、竞品噪音，也可能完全没价值。进 Linear 前要先分开。
适合谁
适合用 Linear 做交付、但客户声音在公开渠道里的产品和工程团队
这页适合已经把 Linear 当成交付系统，但还需要把公开 Twitter/X 反馈受控带进产品分诊的团队。
关注功能请求的产品团队
他们想把反复出现的公开需求、使用抱怨和竞品切换信号，变成可以复核的产品反馈或客户请求。
捕捉公开 bug 报告的工程团队
他们希望坏掉的流程、回归问题、API 报错、发布事故和反直觉行为能带着上下文出现，而不是散落在聊天截图里。
把反馈接入 Linear 的自动化搭建者
他们可以通过 Linear API 或工作流工具创建工单，真正难的是判断哪些 Twitter/X 帖子值得变成产品工作。
想给 Linear AI 分诊准备干净信号的团队
他们希望公开反馈先带上来源链接、客户线索、产品模块、重复状态和路由提示，再交给 Linear 的智能分诊或人工复核。
为什么要单独做这页
真实搜索意图是产品分诊，不只是找一个连接器
Reddit 上关于 Linear 和客户反馈的讨论有一个清楚模式：Linear 很适合规划和交付，但原始反馈在进入路线图前需要先被理解、过滤和归类。Linear 自己也在强调 Customer Requests、Intake 和 AI 辅助分诊：把客服对话、销售电话和计划外工作变成更清楚的产品工作。自动化页面已经开始把 X + Linear 写成“找到推文并创建工单”的流程。TwtAPI 应该负责 Linear 前面的 Twitter/X 检索、补上下文、去重和判断。
客户反馈不等于路线图工作
一条推文可能是真 bug、一次性抱怨、误解、竞品噪音，也可能完全没价值。进 Linear 前要先分开。
公开 bug 报告需要上下文
来源链接、作者近期记录、是否多人重复、影响的功能和可能严重程度，通常比推文本身更重要。
重复工单会伤害信任
如果每条重复投诉都创建一个 Linear 工单，流程很快会变成清理工作。去重和聚合应该发生在前面。
Linear AI 和分诊也需要可靠输入
智能分诊、AI 代理或内部分类器可以总结和路由反馈，但前提是 Twitter/X 搜索结果稳定，记录带来源，方便之后追溯。
Customer Requests 需要需求证据
一个客户请求越有用，就越应该带上谁提过、出现过几次、来自哪个用户群，以及哪些公开帖子能支撑它。
通常需要什么
送进 Linear 前需要的 Twitter/X 数据步骤
TwtAPI 更适合放在 Linear 前面，作为公开数据和判断层。Linear 只接收值得人判断的产品信号。
| 维度 | 该确认什么 | 为什么重要 |
|---|---|---|
| tweet_search | 发现公开 bug 报告和功能请求 | 搜索产品名、报错短语、坏掉的流程、发布抱怨、功能请求、竞品对比和客户痛点。 |
| user_lookup | 判断是谁在反馈 | 补公开作者上下文，区分客户、开发者、潜在客户、创作者、竞品、机器人和低匹配账号。 |
| timeline_lookup | 看这个信号是不是反复出现 | 在判断严重程度或创建 Linear 工单前，先看同一账号近期是否反复提到，或上下文里是否有更多线索。 |
| linear_handoff | 创建可复核的 Linear 工作项 | 由自建自动化或后端任务把合格记录写入 Linear 工单、Customer Requests、Intake 队列、分诊标签、Slack 复核频道、Sheets 或每周反馈摘要。 |
| linear_request_context | 保留每个客户请求背后的证据 | 把来源 URL、作者 X 用户名、命中短语、客户或公司线索、产品模块、用户群、严重程度、重复状态、相关工单引用和为什么值得复核一起带过去。 |
典型流程
一条实用的 Twitter/X 到 Linear 分诊流程
把 Twitter/X 当成公开反馈发现层，把 Linear 当成产品执行系统。中间要先判断什么值得变成工作。
- 1
先选一个反馈类别
从公开 bug 报告、发布问题、集成错误、价格投诉、流失信号或功能请求开始，不要一上来监控所有品牌提及。
- 2
进 Linear 前先检索和分类
用 TwtAPI 收集匹配推文、作者上下文和近期时间线，再用规则或 AI 判断产品模块、严重程度、客户匹配度和置信度。
- 3
重复痛点先去重和聚合
保存推文 ID、来源 URL、作者、命中短语和相关帖子，让重复投诉强化一个产品信号，而不是创建十个工单。
- 4
判断它应该是工单、Customer Request，还是摘要项
明确的 bug 可以进入分诊工单。功能需求可以进入 Customer Request。还不够强但反复出现的主题，可以先进入每周反馈摘要，等证据更多再推进。
- 5
创建最小但有用的 Linear 动作
第一版通常更适合分诊工单、Customer Request、标签建议、Slack 复核项或每周摘要，而不是自动指派工程任务。
- 6
把产品证据和工程工作分开
公开投诉可以证明需求存在，但不一定证明是 bug。先把来源帖子、客户线索和产品主题保存下来，等有人确认预期行为、复现路径和 owner 后，再创建工程工单。
- 7
用重复公开痛点强化已有 request
多条帖子描述同一个痛点时，应该给已有 Customer Request 或分诊项追加证据，而不是创建一堆新的 Linear issue。流程应该提高置信度，而不是制造工单。
FAQ
把 Twitter/X 反馈送进 Linear 前，产品团队常问的问题
这些问题通常出现在团队想把公开客户反馈带进 Linear，但又不想把产品分诊变成社媒清理工作时。
TwtAPI 是 Linear 原生应用吗？
不是。TwtAPI 是 Linear 前面的 Twitter/X 数据层。你可以通过 Linear API、n8n、webhook handler、自定义代码或复核流程，把合格输出送进 Linear。
每条匹配推文都应该创建 Linear 工单吗？
不应该。先做复核型分诊。不确定的帖子先由自建流程发送到 Slack、Sheets 或摘要，只有具体、重复、严重，或者来自重要用户群的信号才适合创建 Linear 工作。
这能配合 Linear Customer Requests 吗？
可以，只要你的流程能把公开 Twitter/X 帖子映射到产品模块、Customer Request、标签或相关工单。建议保留来源 URL、作者 X 用户名、客户或公司线索、重复状态和分类理由，方便之后追溯。
这和 Linear Intake 或 Triage Intelligence 怎么配合？
可以把 TwtAPI 当成 Linear Intake 前面的公开 Twitter/X 信号层。它先准备带来源的记录，包括产品模块、严重程度、重复状态、客户线索和路由提示，再交给 Linear 自动化或人工复核。
怎么避免重复 Linear 工单？
用推文 ID、URL、作者、命中短语、产品模块和已有工单引用去重。重复帖子可以更新同一个分诊项或反馈摘要，而不是每次都创建新工作。
TwtAPI 会把更新发回 Twitter/X 吗？
这页重点是公开数据检索和产品分诊。回复、DM 或发布更新应该单独处理，并满足对应账号授权和平台要求。
什么时候推文应该变成 Linear issue，而不是 Customer Request？
当帖子指向具体 bug、回归、坏掉的流程或发布事故，并且证据足够进入分诊时，创建 issue。产品反馈、需求证据或没有复现细节的重复痛点，更适合 Customer Request 或 digest。
下一步
把公开产品反馈带进 Linear，但别把分诊变成清理工作
从一个反馈类别开始，先在 Linear 外部判断质量，再只把带来源、可复核的产品信号送进规划流程。