相關社區：列出應該繼續追蹤的 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 做成完整驗證報告或訪談提綱。