相关社区：列出应该继续追踪的 subreddit、X 话题、HN 讨论和建议搜索 query。
工具任务
Reddit / X / Hacker News 用户痛点抓取器
把一句粗糙方向变成可复核的用户痛点报告。适合独立开发者、SaaS 创始人和插件作者在开工前先确认用户到底在哪里吐槽、为什么愿意付费、先切哪个小功能。
工具工作台
输入信息，查看结果，再根据页面说明进入下一步。
开始使用
一句方向就够。Agent 会把它拆成可搜索问题，查公开社区信号，并把薄弱证据写进报告。
痛点报告会显示在这里
提交后会整理相关社区、高频抱怨、用户原话、出现频率、付费意图、可切入小功能和 landing page 角度。
你会得到什么
不是“用户需要更好的工具”，而是具体到哪群人在为什么抱怨
高频抱怨：把零散帖子归并成痛点主题，保留用户原话或短摘录，避免只看二手总结。
付费意图判断：结合时间成本、当前替代方案、预算线索和重复出现频率，标出哪些痛点可能值得做。
小功能与落地页角度：把抱怨转成独立开发者可以先做的 narrow wedge，而不是一上来做大而全产品。
好工具标准
一个靠谱的痛点抓取器，应该帮你少走弯路
先找用户语言：输出要尽量保留原话、抱怨场景和社区上下文，而不是改写成咨询报告腔。
区分频率和噪音：单条帖子不等于需求，工具必须标注信号强弱和证据缺口。
连接付费动机：真正有价值的结果要指出用户损失了什么、现在怎么绕路、为什么可能愿意付费。
落到可测试切口：每个机会都要能变成小功能、landing page headline 或下一轮访谈问题。
结果使用
拿到报告后，先做最窄的验证，不要马上开工大产品
优先挑一个频率强、付费意图中高、切口足够窄的抱怨，写一个 landing page 角度。
把报告里的用户原话转成访谈问题，找 5-10 个目标用户确认这是不是日常真实痛点。
如果来源少或置信度低，先继续手动搜索 query，不要因为一个漂亮结论就开始开发。
如果多个社区都重复同一抱怨，可以用小工具、Chrome extension、AI widget 或服务化方案先试水。
常见问题
使用前需要知道的边界
它会抓取私密社群或登录后的内容吗？
不会。工具只应分析公开、可访问的讨论和搜索结果，不访问私密、登录后、删除或付费墙内容。
用户原话一定是逐字引用吗？
不一定。为了避免误引和版权问题，报告可能使用短摘录或保守转述，并保留来源线索供你复核。
出现频率是精确统计吗？
不是精确全网统计。它是基于当前可见公开信号的弱/中/强判断，适合决定下一步调研优先级。
为什么特别适合 SaaS、AI tool、插件和 Chrome extension？
这些产品常常能从一个具体重复抱怨切入：先解决订单状态、导出、通知、同步、审阅等小问题，再验证是否值得扩展。
如果某个痛点已经看起来值得做，下一步可以把 idea 做成完整验证报告或访谈提纲。