大多数需求发现策略从"用户说了什么"出发。GitHub Issues 是用户"提了什么"。
这两者有本质区别。用户在 Twitter 或 Slack 上的发言受平台形态影响：简短、有表演性、意识到观众。而他们在 GitHub 提 Issue，背后有截止日期：内容具体、详细，直接指向一个此刻把他们卡住的问题。
对于目标用户是开发者、技术型创始人或任何使用开源工具的 B2B 买家的 SaaS 产品来说，GitHub Issues 是目前最真实的未过滤需求数据来源之一。
GitHub Issues 的独特价值
一条被用户满腔沮丧提出的 GitHub Issue，包含其他渠道无法稳定提供的信息：
具体性：用户不只是说"出问题了"，而是描述他在做什么、看到了什么错误、期望的结果是什么。这个细节告诉你使用场景、运行环境和问题的严重程度。
复现规律：如果六个月内有五个不同的用户对同一个工具提了相同的 Issue，那不是 bug，是产品空白。这个空白就是一个市场。
变通方案：功能请求的评论区里往往有社区自建的绕过方案。50 个人手工实现了同一个 workaround，说明这是个等待被做成产品的需求。
技术背景：GitHub Issues 带有元数据（repo、工具、版本、关联代码），能帮你判断哪些用户群受影响，痛点有多严重。
值得重点关注的 Issue 模式
不是所有 GitHub Issues 都是需求信号。高价值的 Issue 往往有这样一个结构：
"我们想用 [工具 Y] 做 X，但它不支持 Z。我们一直在手工处理，但扩不起来。"
关键要素：一个工作流、一个具体工具、一个缺失能力、一个规模问题。四个要素同时出现，几乎必然是需求信号。
还有几类值得跟踪：
- 迁移类请求："有没有从 X 迁到 Y 的方式？"——通常说明对 X 有不满，不只是对 Y 好奇。
- 集成类请求："这个支持 [平台] 吗？"——指向相邻市场的未满足需求。
- "不再维护"类讨论：一个项目停止维护后，活跃用户寻找替代品的状态——这类用户的替换意愿极强。
怎么系统化监控 GitHub Issues
GitHub Search API 支持跨所有公开 repo 检索 Issue 和 PR，可以按以下条件过滤：
- 标题和正文中的关键词
- 日期（只看近期 Issue，过滤掉历史存档）
- 状态（open/closed——已关闭但有大量点赞却没修复的 Issue，往往是强信号）
一个有用的查询模式：
is:issue is:open "no support for" OR "doesn't work with" [你的关键词] label:enhancement
竞品情报查询：
is:issue is:open "migrate from" OR "alternative to" [竞品名称]
定期跑这些查询并对结果打分，就能获得一个实时的市场痛点累积地图——比 Twitter 上的讨论早、比产品评测早、比竞品发布 feature 公告早。
从 Issue 到对话
当你发现一条高意向 GitHub Issue，这个信号告诉你：
- 这个用户是技术人，且在活跃使用
- 他有一个明确的问题
- 他已经尝试在现有工具内解决这个问题并失败了
这完全改变了你的触达方式。你不需要发通用冷邮件，而可以直接引用他提的具体问题："我看到你提的那个 Issue，说 X 不支持 Y——Glean 就是专门处理这种场景的。"
这类个性化触达的回复率，比关键词匹配冷邮件高得多——因为你在引用的是对方自己已经知道是真实问题的东西。
时机优势
GitHub Issues 有一个其他渠道很难复制的时效性：它在最大痛苦的时刻被提出。用户刚刚撞墙，不是在事后回忆，也不是在写复盘——他们在描述一个今天就需要解决的问题。
这个窗口很短。快速提出并关闭的 Issue 说明痛点是临时的。几周内不断有新人评论、点赞、却一直没有解决的 Issue，代表持续的、未满足的需求——这才是值得围绕它建产品或调整定位的信号。
Glean 监控 GitHub Issues、Hacker News、RSS 订阅源以及手动导入的社区链接。信号按意向度 1–10 打分，进入队列等人工审核，行动前必须人工批准。免费试用 →