wiki-agentandClaude Opus 4.6
e20b851dd8
Comprehensive research on Reed (Alex Finn's growth hacker AI agent) including behavior model analysis, open-source project survey (GapScout, reddit-idea-scraper, X-Service-Idea-Scanner, idea-generation, GapFinder, Autensa/Mission Control, etc.), signal detection phrase library, pain point discovery philosophies, and recommended architecture for building a Reed-equivalent autonomous pipeline. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
993 lines
54 KiB
Markdown
993 lines
54 KiB
Markdown
# 痛点雷达：从 Alex Finn 的 Reed 到开源实践
|
||
|
||
> 一套关于"如何让 AI Agent 自动在互联网上挖掘用户痛点、发现产品机会"的方法论与实践调研。
|
||
>
|
||
> 起点：Alex Finn（Magnet AI / YC W25 创始人）在他的"虚拟公司"叙事中描述了一个名叫 Reed 的 AI Agent，全天候在互联网上游荡，分析网民在抱怨什么、缺什么工具，一旦发现痛点就自己快速写一个小产品扔到网上测试有没有人点、有没有人付费。
|
||
>
|
||
> 本文拆解 Reed 的行为模型，提炼每个环节的技术本质，然后在 GitHub 和社区中找到对应的开源实践，整理出每个项目的痛点/需求挖掘哲学。
|
||
|
||
---
|
||
|
||
## 0. 问题与适用边界
|
||
|
||
**问题**：Alex Finn 没有开源 Reed。我们需要（a）逆向提炼 Reed 的行为模型，（b）在开源世界找到等价或更优的实践，（c）整理出每个项目的痛点挖掘哲学。
|
||
|
||
**适用**：你想搭建一个自动化的"痛点发现 → 产品验证"管线，或者想理解不同项目在"从互联网噪音中提取真实需求"这件事上的方法论差异。
|
||
|
||
**失效**：如果你做的是 B2B 大客户销售（需求来自 1-2 个关键决策者而非群体抱怨），群体扫描的价值有限；如果你的产品需要长期研发（如芯片、药企），"快速写一个小产品测试"的策略不成立。
|
||
|
||
---
|
||
|
||
## 1. Reed 的行为模型——逐句拆解
|
||
|
||
### 1.1 原文与行为映射
|
||
|
||
| 原文 | 行为 | 技术本质 |
|
||
|------|------|---------|
|
||
| "整天在互联网上游荡" | 全天候浏览论坛、社交媒体 | 定时爬虫扫描多平台（Reddit/HN/Twitter 等） |
|
||
| "到处看帖子" | 持续读取帖子内容 | 结构化抓取：帖子标题、正文、评论、互动数据 |
|
||
| "分析网民最近在抱怨什么" | 从文本中提取投诉/不满信号 | LLM 分类：投诉语句识别 + 情感分析 |
|
||
| "缺什么工具" | 识别未被满足的工具需求 | 需求模式匹配："I wish there was" / "why is there no" |
|
||
| "一旦发现痛点，Reed 就会自己快速写一个小产品" | 根据痛点自动生成 MVP 代码 | AI 代码生成：需求 → 前后端代码 |
|
||
| "扔到网上去测试" | 自动部署上线 | CI/CD 自动部署（Vercel/Railway） |
|
||
| "有没有人点、有没有人付费" | 检测点击/付费转化 | 埋点追踪 + Stripe/支付验证 |
|
||
| "不知疲倦的雷达" | 持续循环 | 常驻进程 / cron 定时 |
|
||
|
||
### 1.2 Reed 的闭环架构
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ Reed 的完整闭环 │
|
||
│ │
|
||
│ ① 游荡扫描 → ② 痛点分析 → ③ 快速建产品 → ④ 部署测试 │
|
||
│ ↑ │ │
|
||
│ └──────────────── 循环 ─────────────────────────┘ │
|
||
│ │
|
||
│ 全天候 24/7，无人干预，替老板寻找搞钱的机会 │
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 1.3 四个环节的技术拆解
|
||
|
||
**① 游荡扫描**——Reed 的"眼睛"
|
||
|
||
- 本质：多平台定时爬虫，覆盖论坛（Reddit、Hacker News、Indie Hackers）和社交媒体（Twitter/X）
|
||
- 关键约束：Reddit API 限流（100 QPM/OAuth client）、Twitter API 收费、匿名接口逐步被封
|
||
- 数据维度：帖子标题、正文、评论树、点赞数、时间戳
|
||
|
||
**② 痛点分析**——Reed 的"大脑"
|
||
|
||
- 本质：LLM 驱动的信号检测与聚类
|
||
- 信号检测：用模式匹配（"I wish there was" / "why is there no" / "I'd pay for" 等）过滤投诉
|
||
- 痛点聚类：相似投诉聚合，区分个人牢骚 vs 普遍痛点（需要频率/互动数据佐证）
|
||
- 商业评估：痛点对应的搜索量、竞争度、支付意愿
|
||
|
||
**③ 快速建产品**——Reed 的"手"
|
||
|
||
- 本质：AI 代码生成 + 模板化部署
|
||
- 输入：痛点描述 + 目标用户
|
||
- 输出：可运行的最小产品（前端 + 后端 + 支付）
|
||
- 关键能力：从需求到代码的转换质量
|
||
|
||
**④ 部署测试**——Reed 的"实验室"
|
||
|
||
- 本质：自动部署 + 行为追踪
|
||
- 部署：Vercel CLI / Railway CLI / GitHub Actions
|
||
- 追踪：页面访问量、点击率、注册率、付费转化率
|
||
- 反馈：低转化 → 换方向；高转化 → 值得投入
|
||
|
||
### 1.4 Alex Finn 其人
|
||
|
||
| 维度 | 信息 |
|
||
|------|------|
|
||
| 身份 | Magnet AI（YC W25）创始人 & CEO，融了 $3.5M |
|
||
| X/Twitter | [@alexfinn_eth](https://x.com/alexfinn_eth) |
|
||
| LinkedIn | 曾在 Reed（英国招聘公司）担任 Growth Hacker |
|
||
| 公司 | Magnet AI 做的是 B2B Autonomous Buyer Intent Agents（从企业列表中识别高意向买家），是 Reed 痛点扫描思路的商业化版本 |
|
||
| 开源 | **未开源** Reed 系统，Magnet AI 也是闭源商业产品 |
|
||
| 名字来源 | "Reed" 很可能来自他自己"Growth Hacker at Reed"的职位，将自身角色拟人化为 Agent |
|
||
|
||
---
|
||
|
||
## 2. 开源实践——按 Reed 的四个环节分别对应
|
||
|
||
### 2.1 环节 ①+②：扫描 + 痛点分析
|
||
|
||
#### 2.1.0 GapScout
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [yanji84/gapscout](https://github.com/yanji84/gapscout) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Node.js 18+ + SQLite + Chrome 远程调试 + Docker + Express 仪表板 |
|
||
| 数据源 | Reddit (PullPush API + browser)、Hacker News、Google Autocomplete、Product Hunt、G2/Capterra 评论、Kickstarter、Google Play Store 评论等 11+ 来源 |
|
||
|
||
**痛点挖掘哲学**：**多 Agent 爆破式扫描——用 ~225 个子 Agent 并行覆盖 11+ 数据源**
|
||
|
||
GapScout 是目前找到的**最复杂的多 Agent 痛点扫描系统**。5 阶段架构：
|
||
|
||
1. **Planning**——规划扫描方向
|
||
2. **Discovery**——发现相关社区和数据源
|
||
3. **Scanning**——~225 个子 Agent 并行扫描 11+ 平台
|
||
4. **Synthesis**——情感分析 + 投诉共识检测 + 迭代精炼（批评→辩论→战略评审→定向重扫）
|
||
5. **Reporting**——输出结构化报告
|
||
|
||
独特之处：不只是扫描+分类，还有**迭代精炼**——第一轮结果经过批评、辩论、战略评审后，可能触发定向重扫。这解决了"第一轮扫描可能遗漏"的问题。
|
||
|
||
**核心哲学**：痛点发现不是一次性扫描，而是**迭代收敛**——先宽扫，再批判，再定向深挖。225 个子 Agent 的并行确保覆盖面，迭代精炼确保深度。
|
||
|
||
---
|
||
|
||
#### 2.1.1 reddit-idea-scraper
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [m-eugen/reddit-idea-scraper](https://github.com/m-eugen/reddit-idea-scraper) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Node.js 18+ TypeScript + Anthropic Claude API (Haiku + Sonnet) + Reddit JSON API |
|
||
|
||
**痛点挖掘哲学**：**加权关键词评分 + 两阶段 AI 评估——成本效率优先的分层管道**
|
||
|
||
这是目前找到的方法论最完整的痛点挖掘工具。它的核心设计是一个**分层管道**：
|
||
|
||
1. **Reddit 抓取**——用 Reddit 公开 JSON 端点，无需 API key
|
||
2. **加权关键词评分**——4 个权重等级的关键词体系：
|
||
|
||
| 类别 | 权重 | 信号类型 | 示例 |
|
||
|------|------|---------|------|
|
||
| Money | 10 | 直接付费意愿 | "I'd pay for" |
|
||
| Frustration | 7 | 情感痛点 | "drives me crazy" |
|
||
| Request | 6 | 明确功能/工具请求 | "is there a tool that" |
|
||
| Switching | 5 | 提及离开竞品 | "migrating from" |
|
||
|
||
3. **Claude Haiku 评估**——~$0.0007/帖，快速评估问题严重度和商业潜力
|
||
4. **Claude Sonnet 生成 MVP 规格**——~$0.05/规格，为前 5 个想法生成详细 MVP 设计文档
|
||
|
||
**核心哲学**：不是所有帖子都值得用强模型分析。先用关键词权重过滤（成本接近零），再用便宜模型（Haiku）快速评估，最后只对 Top 5 用强模型（Sonnet）生成规格。全流程分析 50 帖 + 生成 5 份 MVP 规格仅约 $0.29。**分层管道 = 成本效率的核武器。**
|
||
|
||
---
|
||
|
||
#### 2.1.2 X-Service-Idea-Scanner
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [kiknaio/X-Service-Idea-Scanner](https://github.com/kiknaio/X-Service-Idea-Scanner) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Bun + TypeScript + Grok (via OpenRouter) + 单 HTML 前端 |
|
||
|
||
**痛点挖掘哲学**：**精准信号短语匹配 + 独立开发者视角过滤**
|
||
|
||
用 9 条精心设计的搜索 query 直接从 X/Twitter 中提取高信号内容：
|
||
|
||
| 搜索语句 | 检测的信号类型 |
|
||
|---------|-------------|
|
||
| `"someone should build"` | 直接的建站请求 |
|
||
| `"I'd pay for"` | 付费意愿 |
|
||
| `"why is there no"` | 市场空白 |
|
||
| `"so frustrating" OR "so annoying"` | 痛点 |
|
||
| `"I built a" micro saas` | 已经在跑的产品（竞品情报） |
|
||
| `"shut up and take my money"` | 病毒级需求 |
|
||
| `"wish there was"` | 未被满足的需求 |
|
||
| `"#buildinpublic" pain OR problem` | 开发者困境 |
|
||
| `"hacked together" OR "duct tape"` | 临时方案信号（说明缺好工具） |
|
||
|
||
过滤层用"独立开发者视角"排除不切实际的方向（需要合规的、加密的、硬件的、市场平台的、饱和品类的），输出 10 个带真实推文证据的排序想法。
|
||
|
||
**核心哲学**：不靠 AI 去理解每条帖子的含义（慢且有假阳性），而是靠**人类本能的投诉/需求表达模式**直接从搜索结果中过滤。用户说"I'd pay for"比 LLM 推测"这条帖子隐含不满"可靠得多。
|
||
|
||
---
|
||
|
||
#### 2.1.3 SaaS Insight Engine
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [IcedCoffeeDrinker/SaaS_Insight_Engine](https://github.com/IcedCoffeeDrinker/SaaS_Insight_Engine) |
|
||
| 协议 | ISC |
|
||
| 技术栈 | Python 3.11 + Flask + OpenAI API + Reddit API + DataForSEO + React + Stripe |
|
||
|
||
**痛点挖掘哲学**：**痛点发现 → 搜索量验证 → 竞争度评估 → 收入预测**
|
||
|
||
Pipeline：
|
||
```
|
||
Reddit API → OpenAI（痛点提取+想法生成）→ DataForSEO（搜索量+竞争度）→ Flask 后端 → React 前端
|
||
```
|
||
|
||
独特之处：不只是找痛点，还用 DataForSEO API 补充关键词搜索量和竞争度数据，评估每个痛点的收入潜力。
|
||
|
||
**核心哲学**：痛点必须经过**需求数据验证**才值得做。Reddit 上的抱怨是定性信号，DataForSEO 的搜索量是定量信号，两者交叉才是一个可执行的产品机会。有抱怨不等于有人付费，需要搜索量佐证需求规模。
|
||
|
||
---
|
||
|
||
#### 2.1.4 GapFinder
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [aryangovindrao/GapFinder](https://github.com/aryangovindrao/GapFinder-full-stack-platform) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Next.js 14 + FastAPI + TextBlob + sentence-transformers (all-MiniLM-L6-v2) + KMeans + Ollama (Llama 3) |
|
||
|
||
**痛点挖掘哲学**：**投诉聚类——用 NLP 发现隐藏在噪音背后的共性痛点**
|
||
|
||
GapFinder 不扫 Reddit，而是扫 Product Hunt——分析新产品及其用户评论。Pipeline：
|
||
|
||
1. **抓取 Product Hunt 产品和评论**
|
||
2. **情感分析**——TextBlob 计算每条评论的情感极性
|
||
3. **投诉聚类**——用 sentence-transformers (all-MiniLM-L6-v2) 生成句向量 + KMeans 聚类，把相似的投诉归到一起
|
||
4. **缺口检测**——每个聚类变成一个结构化的"Gap"记录，带机会评分
|
||
5. **AI 想法生成**——本地 Llama 3（通过 Ollama）为每个 Gap 生成创业提案：问题描述、目标用户、MVP 轮廓、竞争壁垒、收入模型
|
||
6. **趋势追踪**——按类别追踪 12+ 周的市场趋势
|
||
|
||
**核心哲学**：单条投诉是轶事，**投诉聚类是信号**。100 条不同的抱怨如果聚类后收敛到 3 个主题，那 3 个主题才是真实痛点。用向量化+KMeans 把表面的多样性还原为底层的共性，这是从噪音中提取信号的数学方法。
|
||
|
||
---
|
||
|
||
#### 2.1.5 Business Idea Radar
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [martinbouvet2000-tech/business-idea-radar](https://github.com/martinbouvet2000-tech/business-idea-radar) |
|
||
| 技术栈 | Python + PRAW + Streamlit + Anthropic SDK (Claude) |
|
||
|
||
**痛点挖掘哲学**：**"人们愿意付费解决的真实问题"——付费意愿优先**
|
||
|
||
Pipeline：PRAW 抓 Reddit → 扫描"人们愿意付费解决的真实问题" → Claude API 可选验证 → Streamlit 仪表板 → JSON/Markdown 报告
|
||
|
||
**核心哲学**：不是所有抱怨都是商机。优先关注那些隐含付费意愿的帖子——"我愿意付钱解决这个"比"这个很烦"更有商业价值。`--local` 模式可以不用 AI 纯靠规则过滤，降低成本。
|
||
|
||
---
|
||
|
||
#### 2.1.6 Reddit-PainPoint-Finder
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [Anthonytesla02/Reddit-PainPoint-Finder](https://github.com/Anthonytesla02/Reddit-PainPoint-Finder) |
|
||
| 技术栈 | Node.js + TypeScript + Vite + Google Gemini API |
|
||
|
||
**痛点挖掘哲学**：**先找对的地方，再找对的人**
|
||
|
||
不是直接搜全 Reddit，而是先用 Gemini API 找到"人们正在积极讨论自己问题"的相关 subreddit，然后再在这些精准社区中挖掘 SaaS 想法。
|
||
|
||
**核心哲学**：痛点密度不均匀。在 r/Entrepreneur 找到的痛点和在 r/SideProject 找到的痛点，商业价值完全不同。先定位高价值社区，再挖掘内容。
|
||
|
||
---
|
||
|
||
#### 2.1.7 idea-scanner
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [dcrjodle/idea-scanner](https://github.com/dcrjodle/idea-scanner) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Bun/TypeScript + Zod + 支持 OpenAI/Anthropic/Google/OpenRouter/Groq/Ollama |
|
||
| 数据源 | Reddit、Hacker News、Product Hunt、GitHub Trending、Y Combinator |
|
||
|
||
**痛点挖掘哲学**：**三轴评分——需求×缺口×成本的乘法公式**
|
||
|
||
Pipeline：5 源并行采集 → 去重 → LLM 三轴评分 → 排序 Markdown 报告
|
||
|
||
评分公式：
|
||
```
|
||
opportunity_score = (demand*0.4 + gap*0.4 + (6-effort)*0.2) / 5 * 100
|
||
```
|
||
|
||
- **Demand（权重 0.4）**——有多少人想要
|
||
- **Gap（权重 0.4）**——市场有多空白
|
||
- **Effort（权重 0.2）**——做出来要多费力
|
||
|
||
批量处理：12 信号/次调用，3 次并行，成本效率高。
|
||
|
||
**核心哲学**：机会 = 需求 × 缺口 ÷ 成本。三个维度不是等权的——需求和缺口各占 40%，成本只占 20%。一个高需求+高空白的痛点即使做起来费力，也比一个低需求但好做的方向更值得追。
|
||
|
||
---
|
||
|
||
#### 2.1.8 idea-generation
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [Moa1er/idea-generation](https://github.com/Moa1er/idea-generation) |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Python 3.11+ + Ollama (qwen3.5:9b) + ModernBERT (gte-modernbert-base) + NVIDIA GPU 8GB+ |
|
||
|
||
**痛点挖掘哲学**：**进化式搜索 + 几何均分评分 + 盲辩去偏——最复杂的想法生成系统**
|
||
|
||
11 阶段管线：
|
||
1. **信号检索**——从 Reddit/GitHub/论坛抓取投诉
|
||
2. **问题挖掘**——提取痛点
|
||
3. **群体生成**——4 个建造者 persona 各自生成方案
|
||
4. **向量去重**——ModernBERT 双空间嵌入去重
|
||
5. **可行性分诊**——快速过滤不可行的
|
||
6. **进化循环**——变异、简化、交叉（像遗传算法）
|
||
7. **新颖性选择**——保留最有新意的
|
||
8. **盲辩**——7 个评审 Agent 盲评，对抗 LLM"讨好者"偏差
|
||
9. **实时研究**——对存活的想法做即时网络搜索验证
|
||
10. **档案编译**——生成完整 dossier
|
||
11. **前沿委员会**——最终决策
|
||
|
||
10 维评分（几何均分，确保任一维度为 0 则总分归零）：
|
||
|
||
| 维度 | 权重 |
|
||
|------|------|
|
||
| Pain | 0.15 |
|
||
| Evidence | 0.12 |
|
||
| Market Demand | 0.12 |
|
||
| Opportunity Gap | 0.12 |
|
||
| Differentiation | 0.10 |
|
||
| Mechanism Novelty | 0.10 |
|
||
| Solo Feasibility | 0.10 |
|
||
| Monetization | 0.08 |
|
||
| Distribution | 0.06 |
|
||
| Timing | 0.05 |
|
||
|
||
**核心哲学**：三个独特设计让它在所有项目中脱颖而出：
|
||
|
||
1. **几何均分 > 算术均分**——算术均分会让一个"无法独立完成"的想法（Solo Feasibility=0）靠其他维度的高分蒙混过关。几何均分确保任一致命缺陷直接归零。
|
||
2. **进化搜索**——不满足于第一轮生成的想法，通过变异/简化/交叉迭代优化，像遗传算法一样逼近更好的解空间。
|
||
3. **7 Agent 盲辩**——LLM 天生是"讨好者"，默认赞同输入。7 个独立评审 Agent 盲评（不知道其他人的判断）可以对抗这种偏差，只留下真正经得起批判的想法。
|
||
|
||
---
|
||
|
||
#### 2.1.9 Market Gap Finder
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [mloki23/market-gap-finder](https://github.com/mloki23/market-gap-finder) |
|
||
| 协议 | MIT |
|
||
| 格式 | Agent Skill（SKILL.md 标准，适配 Claude Code / Copilot / Codex 等） |
|
||
|
||
**痛点挖掘哲学**：**五维度评分——结构化的机会评估框架**
|
||
|
||
不是自己爬数据，而是依赖 Agent 原生的 web search 能力收集市场数据，然后用一个 5 维度评分框架评估缺口：
|
||
|
||
| 维度 | 评估什么 |
|
||
|------|---------|
|
||
| Demand Evidence | 人们想要这个解决方案的证据强度 |
|
||
| Competition Vacuum | 这个领域当前有多空白 |
|
||
| Revenue Potential | 估计的金额机会 |
|
||
| Accessibility | 进入市场的难度 |
|
||
| Timing | 机会窗口是否当前打开 |
|
||
|
||
输出：行业概览 + 4-6 个评分缺口 + 排名 + Top 机会 30 天行动计划 + 趋势分析。是三技能管线的一部分（Market Gap Finder → Side Hustle Evaluator → Competitor Intel Briefer）。
|
||
|
||
**核心哲学**：痛点发现不需要复杂的技术栈，一个结构化的评估框架就够了。关键不在"找什么"而在"怎么评"——5 个维度的交叉评分比单看"有没有人抱怨"更接近商业决策。
|
||
|
||
---
|
||
|
||
### 2.2 环节 ①：通用互联网扫描基础设施
|
||
|
||
#### 2.2.1 Agent-Reach
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [Panniantong/Agent-Reach](https://github.com/Panniantong/Agent-Reach) |
|
||
| Stars | ⭐74,542 |
|
||
| 协议 | MIT |
|
||
|
||
**痛点挖掘哲学**：**Agent 的"感知层"——先让 Agent 能看到互联网，再谈分析**
|
||
|
||
给任何能跑命令行的 Agent 装上"看遍整个互联网"的能力：
|
||
|
||
| 平台 | 能力 | 配置 |
|
||
|------|------|------|
|
||
| 网页 | 读任意 URL（Jina Reader） | 零配置 |
|
||
| YouTube | 字幕提取+视频搜索 | 零配置 |
|
||
| RSS | 读任意 RSS/Atom feed | 零配置 |
|
||
| Web 搜索 | 语义搜索（Exa） | 零配置 |
|
||
| GitHub | 读公开仓库+搜索 | 零配置 |
|
||
| Twitter/X | 读推文+搜索 | 需 Cookie |
|
||
| Reddit | 搜索+读帖/评论 | 需登录 |
|
||
| Bilibili | 搜索+视频详情 | 零配置 |
|
||
| 小红书 | 搜索+读帖+评论 | 需 Cookie |
|
||
|
||
核心设计：多后端路由（每个平台有主备后端，一个挂了自动切另一个），`agent-reach doctor` 诊断所有通道状态。
|
||
|
||
**核心哲学**：痛点发现的第一步不是分析，而是**覆盖**。如果你的 Agent 只能读 Reddit，那它永远看不到 Twitter 上的爆发性需求和 YouTube 评论区的长尾痛点。
|
||
|
||
---
|
||
|
||
#### 2.2.2 SurfSense
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [MODSetter/SurfSense](https://github.com/MODSetter/SurfSense) |
|
||
| Stars | ⭐15,998 |
|
||
|
||
**痛点挖掘哲学**：**结构化数据 > markdown blob——给 Agent 吃干净的数据**
|
||
|
||
用类型化连接器返回结构化 JSON（帖子、评论、评论树、视频字幕），而非通用爬虫的 markdown 文本。支持 MCP server，Claude/Cursor 可直接当原生工具调用。
|
||
|
||
| 连接器 | 返回内容 |
|
||
|--------|--------|
|
||
| Reddit | 帖子、评论、subreddit 流（无官方 API 限流） |
|
||
| YouTube | 视频、字幕、评论树 |
|
||
| Google Search | 实时搜索结果 |
|
||
| Google Maps | 商家、评分、评论 |
|
||
| Amazon | 价格、评分、评论 |
|
||
|
||
**核心哲学**：Agent 分析痛点的质量取决于输入数据的质量。结构化 JSON 直接告诉 Agent"这条评论回复了哪条帖子、有多少赞"，省掉了解析步骤，减少了幻觉。结构化意味着能更准确地判断"这是一个普遍痛点还是一个边缘牢骚"。
|
||
|
||
---
|
||
|
||
#### 2.2.3 Huginn
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [huginn/huginn](https://github.com/huginn/huginn) |
|
||
| Stars | ⭐43,000+ |
|
||
| 协议 | MIT |
|
||
|
||
**痛点挖掘哲学**：**Agent 式持续监控——"看变化"而非"看全部"**
|
||
|
||
Huginn 是一个老牌的 Agent 系统，核心设计是"定期检查 → 检测变化 → 触发事件"。关键 Agent 类型：
|
||
|
||
- **WebsiteAgent**——定期抓取 URL，`mode: on_change` 模式只在内容变化时触发
|
||
- **RssAgent**——监控 RSS/Atom feed，追踪已见条目，只推送新的
|
||
- **NotificationAgent**——通过邮件/Slack/Telegram 发送告警
|
||
|
||
**核心哲学**：痛点挖掘不需要每次全量扫描。更好的方式是**增量监控**——只看"自上次以来新增了什么"。Huginn 的 `on_change` 模式是 Reed"全天候雷达"的低成本实现：不必 24 小时爬全量数据，只需检测增量变化。
|
||
|
||
---
|
||
|
||
#### 2.2.4 GPT-Researcher
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [assafelovic/gpt-researcher](https://github.com/assafelovic/gpt-researcher) |
|
||
| Stars | ⭐29,113 |
|
||
| 协议 | Apache 2.0 |
|
||
|
||
**痛点挖掘哲学**：**Planner-Executor-Publisher——先问对的问题，再并行采集**
|
||
|
||
架构：
|
||
1. **Planner**：根据研究主题生成一组研究问题，构成客观视角
|
||
2. **Executor**：并行爬取 20+ 来源，为每个问题收集信息
|
||
3. **Publisher**：过滤聚合所有摘要，生成最终研究报告
|
||
|
||
**核心哲学**：痛点挖掘不应该是"扫一遍 Reddit 看看有什么"。应该是"我要研究'开发者对项目管理工具的不满'→ 规划出 5 个子问题 → 并行采集 20+ 来源 → 交叉验证"。Planner 确保不遗漏角度，Executor 的并行采集避免单一信息源偏差。
|
||
|
||
---
|
||
|
||
### 2.3 环节 ②：趋势/机会判断（Reed 的"雷达"功能）
|
||
|
||
#### 2.3.1 agentRadar
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [sunrisefromdark/agentRadar](https://github.com/sunrisefromdark/agentRadar) |
|
||
| Stars | ⭐50 |
|
||
|
||
**痛点挖掘哲学**：**区分"单日噪声"vs"持续趋势"vs"新方向出现"——信号的时间维度**
|
||
|
||
Pipeline：信号采集 Agent → 归一化评分 Agent → 日报 Agent → **周趋势 Agent** → 观察者 Agent → 知识卡片 Agent
|
||
|
||
关键设计：
|
||
- 不只看今天有没有人抱怨，而是看这个抱怨是否**持续上升**
|
||
- 区分"单日爆发"（可能是事件驱动）vs"持续上升"（可能是结构性痛点）
|
||
- 判断"这周真的发生了方向变化吗"
|
||
- 保留完整证据链和评分拆解，不做黑箱
|
||
|
||
**核心哲学**：Reed 式扫描的最大风险是**假信号**——某天 Reddit 上突然出现很多关于某工具的抱怨，可能只是因为该工具当天出了故障。时间维度是过滤假信号的关键：只出现一天的痛点是噪声，连续一周上升才可能是机会。
|
||
|
||
---
|
||
|
||
#### 2.3.2 Claude World Studio
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [claude-world/claude-world-studio](https://github.com/claude-world/claude-world-studio) |
|
||
| Stars | ⭐72 |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Claude Agent SDK + MCP + React 19 + Express + SQLite |
|
||
|
||
**痛点挖掘哲学**：**趋势发现 → 原始来源验证 → 质量评分 → 行动——闭环到验证**
|
||
|
||
- **trend-pulse MCP**：20 个实时趋势源，零认证
|
||
- **来源验证**：强制读取原始来源，不从标题/元数据写内容。争议话题需 2+ 来源
|
||
- **质量评分**：Meta 专利的 5 维度评分（Hook Power / Engagement Trigger / Conversation Durability / Velocity Potential / Format Score），总分 ≥ 70 才发布
|
||
- **发布**：自动发布到 Threads，多账号矩阵分发
|
||
|
||
**核心哲学**：痛点发现后需要**质量门控**。不是所有痛点都值得做产品——用评分系统过滤掉低价值方向。Reed 用的是"有没有人付费"作为终极评分，Claude World Studio 用 5 维度评分。逻辑同构：发现 → 验证 → 评分 → 行动。
|
||
|
||
---
|
||
|
||
### 2.4 环节 ③+④：快速建产品 + 部署
|
||
|
||
#### 2.4.1 Autensa / Mission Control——最接近 Reed 全闭环
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [crshdn/mission-control](https://github.com/crshdn/mission-control) |
|
||
| Stars | ⭐2,132 |
|
||
| 协议 | MIT |
|
||
| 技术栈 | Next.js + OpenClaw Gateway + SQLite + Docker |
|
||
|
||
**痛点挖掘哲学**：**8 阶段全自动产品引擎——从市场研究到 PR 的完整闭环**
|
||
|
||
这是目前找到的**最接近 Reed 完整闭环**的开源项目。它叫自己"Autonomous Product Engine (APE)"，8 阶段管线：
|
||
|
||
| 阶段 | 做什么 |
|
||
|------|--------|
|
||
| 1. Research | AI Agent 扫描产品代码库、线上站点、竞品格局。分析竞品、用户意图、SEO 缺口 |
|
||
| 2. Ideation | 研究结果喂给 AI 生成带影响/可行性评分的功能想法 |
|
||
| 3. Swipe | Tinder 式 UI：用户 Pass / Maybe / Yes / Now! |
|
||
| 4. Plan | AI 提问澄清 → 生成详细规格 → 用户批准 |
|
||
| 5. Build | Agent 克隆仓库、创建分支、实现功能 |
|
||
| 6. Test | 运行测试套件；失败自动回退修复 |
|
||
| 7. Review | Agent 检查 diff 质量、安全性、最佳实践 |
|
||
| 8. PR | 在 GitHub 创建 Pull Request |
|
||
|
||
**Convoy Mode**：多 Agent 并行执行（依赖图 DAG），3-5 个 Agent 并行处理独立子任务，带健康监控、自动催促 stalled Agent、检查点崩溃恢复。
|
||
|
||
**自动化层级**：Supervised（创建 PR，你合并）→ Semi-Auto（CI 通过自动合并）→ Full Auto（从想法到部署全自动）。
|
||
|
||
**核心哲学**：Reed 的闭环不是"扫描 → 建产品 → 测试"三步，而是更细粒度的 8 步。关键是中间有**人类介入点**（Swipe 阶段），即使 Full Auto 模式也需要一个"有人觉得这个值得做"的信号。完全无人干预的 Reed 会导致资源浪费在低价值方向上。
|
||
|
||
---
|
||
|
||
#### 2.4.2 其他自主编码 Agent
|
||
|
||
| 项目 | Stars | 说明 | 痛点挖掘哲学 |
|
||
|------|-------|------|------------|
|
||
| [OpenHands](https://github.com/All-Hands-AI/OpenHands) | ⭐30k | 前身 OpenDevin，完整自主编码平台。ReAct 循环（Plan-Act-Observe-Reflect），Docker 沙箱，可构建完整应用 | 反思循环——每次行动后反思再调整，避免一条路走到黑 |
|
||
| [OpenManus](https://github.com/mannaandpoem/OpenManus) | ⭐40k+ | 开源 Manus 克隆。多 Agent 架构（Coordinator/Research/Browser/Coder/Reporter） | 角色分工——不同 Agent 做不同事，比一个通才更可靠 |
|
||
| [AgenticSeek](https://github.com/Fosowl/agenticSeek) | ⭐27k | 完全本地的 Manus 替代，无需 API | 全本地化——痛点数据可能敏感，本地化是底线 |
|
||
| [SaaS-Builder](https://github.com/jatingargiitk/saas-builder) | ⭐223 | 从自然语言生成完整 SaaS 应用（React+Flask+SQLite+Auth） | 模板驱动——用预设模板加速生成，不是从零写 |
|
||
| [gpt-engineer](https://github.com/gpt-engineer-org/gpt-engineer) | 高 | 从需求描述生成完整代码项目 | 先理解需求再生成——需求理解比代码生成更关键 |
|
||
|
||
---
|
||
|
||
### 2.5 环境监控基础设施
|
||
|
||
#### 2.5.1 n8n 产品研究模板
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [n8n-io/n8n](https://github.com/n8n-io/n8n) |
|
||
| 模板库 | [n8n.io/templates](https://n8n.io/templates) |
|
||
|
||
n8n 社区模板中有多个产品研究工作流：
|
||
- **Amazon Product Research & Ideation**——扫描 Amazon 产品 → 评论情感分析 → 差异化缺口分析 → 输出到 Google Sheets
|
||
- **Product Market Research Workflow**——抓取产品详情 → 情感分析 → 机会输出
|
||
|
||
**痛点挖掘哲学**：**无代码编排——把扫描→分析→输出串成可视化工作流**
|
||
|
||
适合不写代码的创业者。n8n 的价值在于：你可以把 HTTP 请求节点（爬数据）→ OpenAI 节点（分析）→ Google Sheets 节点（存储）→ Slack 节点（告警）拖拽成一个完整的痛点监控管线，全程不写代码。
|
||
|
||
---
|
||
|
||
### 2.6 UX 视角的痛点发现
|
||
|
||
#### 2.6.1 UX Workflow Check
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 仓库 | [sergiobuilds/ux-workflow-check](https://github.com/sergiobuilds/ux-workflow-check) |
|
||
| 协议 | MIT |
|
||
| 格式 | Agent Skill（SKILL.md 标准） |
|
||
|
||
**痛点挖掘哲学**：**意图优先——用用户视角走路，发现"伸手够不到的东西"**
|
||
|
||
不是从论坛找痛点，而是从**产品本身**找——让 AI Agent 以用户第一人称视角"走"一遍产品，发现 UX 缺口。
|
||
|
||
方法论根植于 **Jobs-to-be-Done** 理论 + **Cognitive Walkthrough**（认知走查）：
|
||
1. 从用户的"SEED intent"（种子意图）出发
|
||
2. 第一人称走一遍用户流程
|
||
3. 强制输出三个发现：意图缺口、隐含假设、缺失界面/功能
|
||
4. 按层级分解（数据层 → 后端 → 连接 → 前端）
|
||
|
||
三个"强制门"防止 Agent 偷懒：
|
||
- **Output gate**——每轮必须产出完整输出，不能留空
|
||
- **Lens gate**——四个自检：是否用了系统词汇、是否输出了通用 checklist、是否跳过了空/失败/返回状态、是否提前退出
|
||
- **Convergence gate**——不同 persona 循环直到连续两轮没有新发现
|
||
|
||
**核心哲学**：痛点不只在论坛里——产品本身就充满了缺口。但 AI Agent 默认从"建造者视角"看产品（看系统组件），而不是从"用户视角"（看体验流程）。这个 skill 的作用是**强制翻转视角**：让 Agent 像用户一样"走"一遍，在走的过程中发现"伸手够不到的东西"。
|
||
|
||
---
|
||
|
||
### 2.7 商业工具参考（不开源但方法论值得学习）
|
||
|
||
#### GummySearch
|
||
|
||
| 维度 | 内容 |
|
||
|------|------|
|
||
| 网站 | [gummysearch.com](https://gummysearch.com) |
|
||
| 定价 | Free / $29 Starter / $79 Pro |
|
||
| 数据源 | 仅 Reddit |
|
||
|
||
**痛点挖掘哲学**：**Reddit 焦点小组——用 AI 替代人工社群研究**
|
||
|
||
核心方法论：
|
||
1. **关键词/主题搜索**——输入关键词或选择 subreddit
|
||
2. **痛点提取**——AI/NLP 识别显性和隐性痛点
|
||
3. **情感+趋势分析**——按情感、点赞、互动频率、时间排序
|
||
4. **竞品抱怨分析**——找人们对竞品的不满
|
||
5. **想法验证**——看是否有人在主动寻找解决方案
|
||
6. **实时告警**——新痛点出现时立刻通知
|
||
|
||
**核心哲学**：痛点发现不需要发明新方法，而是把传统用户研究的"焦点小组"搬到 Reddit 上，用 AI 替代人工阅读。关键不在技术多炫，而在于覆盖面和持续监控。
|
||
|
||
#### 其他商业替代品
|
||
|
||
| 工具 | 数据源 | 特点 |
|
||
|------|--------|------|
|
||
| Brand24 | 多平台 | 社交聆听，覆盖 Reddit/Twitter/Blog |
|
||
| Awario | 多平台 | 实时提及追踪 |
|
||
| BuzzSumo | 多平台 | 内容趋势+互动分析 |
|
||
| Reddit Pro | Reddit | Reddit 官方商业工具 |
|
||
|
||
---
|
||
|
||
### 2.8 实践者的方法论——从人到 Agent
|
||
|
||
痛点挖掘不是 AI 时代才有的。在 Reed 之前，独立开发者们已经在手动实践这套方法论多年。这些实践者的方法论，就是 Reed 的"人类原型"。
|
||
|
||
#### 2.8.1 Pieter Levels（@levelsio）——"Build What People Want"
|
||
|
||
Levels 是独立开发者圈最知名的践行者。他的方法论：
|
||
|
||
1. 去 Reddit
|
||
2. 找到痛点（人们在抱怨什么）
|
||
3. 建最简可能的解决方案
|
||
4. 在发现痛点的同一个 subreddit 发布
|
||
5. 根据反馈迭代
|
||
|
||
名言："Don't build what you think people want. Build what they are literally begging for on Reddit."
|
||
|
||
代表产品：Nomad List（来自对远程工作地点信息的抱怨）、Remote OK（来自"找不到远程工作"的抱怨）
|
||
|
||
**核心哲学**：不猜人们想要什么——观察他们正在乞求什么。Reddit 是最真实的"需求市场"，因为用户不假掩饰地表达不满。Reed 就是把这个手动过程自动化。
|
||
|
||
#### 2.8.2 Justin Jackson——"Demand Validation"
|
||
|
||
Transistor.fm（播客托管）创始人。方法论：
|
||
|
||
1. 读 Reddit 社区帖子，找痛点
|
||
2. 在写代码之前验证需求
|
||
3. 建最小产品解决已识别的痛点
|
||
4. 通过 "Build Your SaaS" 播客分享方法论
|
||
|
||
**核心哲学**：先验证需求再写代码。大多数产品失败不是因为代码差，而是因为没人想要。Reddit 验证是写代码之前的第一步。
|
||
|
||
#### 2.8.3 Complaint-Driven Development（CDD）——学术化
|
||
|
||
有一篇学术论文正式定义了这个方法论：arXiv:2408.15790 (2024) by Vasiliy Yurchuk——"Complaint-Driven Development: Demand-First Validation Framework for Internet Data Mining"
|
||
|
||
核心概念：把焦点从供给侧（提供商驱动）转向需求侧（用户驱动），用真实用户投诉作为识别问题和指导开发的主要信号。
|
||
|
||
**核心哲学**：投诉不是噪声——投诉是需求的最原始形态。传统产品开发从"我们能做什么"出发（供给侧），CDD 从"用户在抱怨什么"出发（需求侧）。Reed 是 CDD 的自动化实现。
|
||
|
||
---
|
||
|
||
## 3. 信号检测短语库——Reed 的"搜索 query 设计"
|
||
|
||
从所有项目中提取的痛点信号检测短语，按信号强度排序。
|
||
|
||
### 3.1 强信号——直接表达需求/付费意愿（权重 10）
|
||
|
||
| 短语 | 信号含义 | 来源 |
|
||
|------|---------|------|
|
||
| `"I'd pay for"` | 付费意愿——最高价值信号 | X-Service-Idea-Scanner, reddit-idea-scraper (Money 级) |
|
||
| `"someone should build"` | 直接的建站请求 | X-Service-Idea-Scanner |
|
||
| `"shut up and take my money"` | 病毒级需求 | X-Service-Idea-Scanner |
|
||
| `"I would pay $X for"` | 有价格预期的付费意愿 | 社区实践 |
|
||
| `"is there a tool that"` | 明确的工具搜索 | 社区实践 |
|
||
| `"looking for a tool/app that"` | 主动寻找解决方案 | 社区实践 |
|
||
| `"does anyone know a tool that"` | 工具推荐请求 | 社区实践 |
|
||
| `"take my money"` | 付费意愿变体 | 社区实践 |
|
||
|
||
### 3.2 中信号——表达不满/缺失（权重 5-7）
|
||
|
||
| 短语 | 权重 | 信号含义 | 来源 |
|
||
|------|------|---------|------|
|
||
| `"why is there no"` | 6 | 市场空白 | X-Service-Idea-Scanner |
|
||
| `"wish there was"` | 6 | 未被满足的需求 | X-Service-Idea-Scanner |
|
||
| `"so frustrating" / "so annoying"` | 7 | 痛点（情感强度高） | X-Service-Idea-Scanner, reddit-idea-scraper (Frustration 级) |
|
||
| `"drives me crazy"` | 7 | 情感痛点 | reddit-idea-scraper |
|
||
| `"hacked together" / "duct tape"` | 5 | 临时方案信号（缺好工具） | X-Service-Idea-Scanner |
|
||
| `"#buildinpublic" pain / problem` | 5 | 开发者困境 | X-Service-Idea-Scanner |
|
||
| `"I hate that"` | 7 | 明确不满 | 社区实践 |
|
||
| `"the worst thing about"` | 7 | 痛点聚焦 | 社区实践 |
|
||
| `"if only there was"` | 6 | 愿望表达 | 社区实践 |
|
||
| `"need recommendation for"` | 6 | 寻求推荐 | 社区实践 |
|
||
| `"is there an alternative to"` | 5 | 寻找替代品（对现状不满） | 社区实践 |
|
||
|
||
### 3.3 弱信号——间接暗示（权重 5）
|
||
|
||
| 短语 | 信号含义 | 来源 |
|
||
|------|---------|------|
|
||
| `"I built a" micro saas` | 已经在跑的产品（竞品情报） | X-Service-Idea-Scanner |
|
||
| `"migrating from"` | 正在迁移（对旧工具不满） | reddit-idea-scraper (Switching 级) |
|
||
| `"switching from"` | 正在切换 | reddit-idea-scraper |
|
||
| `"comparing X vs Y"` | 在做竞品比较（决策中） | 社区实践 |
|
||
| `"alternative to"` | 寻找替代品 | reddit-idea-scraper |
|
||
| `"better than"` | 在比较（对现状不满） | 社区实践 |
|
||
| `"done with"` | 放弃使用 | 社区实践 |
|
||
| `"drop-in replacement for"` | 寻找直接替代品 | 社区实践 |
|
||
|
||
### 3.3b 补充信号——临时方案/工作区（权重新增）
|
||
|
||
| 短语 | 信号含义 | 来源 |
|
||
|------|---------|------|
|
||
| `"I've been doing this manually"` | 手动做（说明缺工具） | 社区实践 |
|
||
| `"I've been using a hack"` | 用 hack（说明缺好工具） | 社区实践 |
|
||
| `"I've been making do with"` | 凑合用（说明不够好） | 社区实践 |
|
||
| `"the only way I can do this is"` | 唯一方案（说明缺替代品） | 社区实践 |
|
||
| `"I've been piecing together"` | 拼凑用（说明缺整合方案） | 社区实践 |
|
||
|
||
### 3.3c 补充信号——问题承认/困境（权重新增）
|
||
|
||
| 短语 | 信号含义 | 来源 |
|
||
|------|---------|------|
|
||
| `"I'm struggling with"` | 遇到困难 | 社区实践 |
|
||
| `"I can't figure out"` | 卡住了 | 社区实践 |
|
||
| `"I keep running into"` | 反复遇到 | 社区实践 |
|
||
| `"no good way to"` | 没有好的方法 | 社区实践 |
|
||
| `"I'm wasting so much time"` | 时间浪费（效率痛点） | 社区实践 |
|
||
| `"I'm losing money because"` | 亏损（商业痛点） | 社区实践 |
|
||
|
||
### 3.4 信号设计哲学
|
||
|
||
**核心洞察**：人类表达痛点的方式有固定模式。与其让 LLM 从全量文本中"理解"痛点（慢、有假阳性、成本高），不如直接搜索这些**高信号短语**。这本质上是把用户研究中的"访谈引导语"变成了搜索引擎 query。
|
||
|
||
**加权分级**（来自 reddit-idea-scraper 的设计）：
|
||
- **Money（权重 10）**：付费意愿——一个说"I'd pay for"的用户比 100 个说"这很烦"的用户有价值
|
||
- **Frustration（权重 7）**：情感痛点——强烈的情感表达说明痛点真实
|
||
- **Request（权重 6）**：明确请求——用户已经想好了要什么
|
||
- **Switching（权重 5）**：迁移信号——说明对现状不满但还弱于明确请求
|
||
|
||
**分层管道**：关键词权重过滤（成本≈0）→ 便宜模型快筛（Haiku ~$0.0007/帖）→ 强模型深析（Sonnet ~$0.05/规格）。不是所有帖子都值得用强模型，分层让成本效率最大化。
|
||
|
||
---
|
||
|
||
## 3.5 跨项目的通用架构模式
|
||
|
||
从所有项目中提炼的通用技术模式：
|
||
|
||
| 模式 | 描述 | 采用项目 |
|
||
|------|------|---------|
|
||
| **多源采集** | Reddit 为主，补充 HN/PH/GitHub/App Store 评论 | GapScout (11+), idea-scanner (5) |
|
||
| **加权关键词评分** | 不同信号短语不同权重（Money > Frustration > Request > Switching） | reddit-idea-scraper, idea-scanner |
|
||
| **两阶段 LLM 管道** | 便宜模型快筛 → 强模型深析 | reddit-idea-scraper (Haiku→Sonnet) |
|
||
| **向量去重** | ModernBERT/sentence-transformers 嵌入去语义重复 | idea-generation, GapFinder |
|
||
| **多 Agent 盲辩** | 多个独立评审 Agent 对抗 LLM"讨好者"偏差 | idea-generation (7 Agent), GapScout |
|
||
| **进化搜索** | 变异/简化/交叉迭代优化想法 | idea-generation |
|
||
| **几何均分评分** | 任一维度为 0 则总分归零，避免致命缺陷被平均 | idea-generation |
|
||
| **批量处理** | 12 信号/次调用，降低 API 成本 | idea-scanner, reddit-idea-scraper |
|
||
| **断点恢复** | 长时间运行的进度自动保存和恢复 | reddit-idea-scraper |
|
||
| **增量监控** | 只看"自上次以来新增了什么" | Huginn |
|
||
|
||
---
|
||
|
||
## 4. 各项目痛点挖掘哲学对比
|
||
|
||
| 项目 | 核心哲学 | 一句话总结 |
|
||
|------|---------|----------|
|
||
| **Reed（Alex Finn）** | 全自动闭环：扫描→分析→建产品→测试→循环 | "不知疲倦的雷达，替老板找搞钱的机会" |
|
||
| **GapScout** | 多 Agent 爆破式扫描 + 迭代精炼——225 个子 Agent 覆盖 11+ 源 | "先宽扫再批判再定向深挖——痛点发现是迭代收敛不是一次性扫描" |
|
||
| **reddit-idea-scraper** | 加权关键词评分 + 两阶段 AI 评估——分层管道 | "不是所有帖子都值得用强模型，分层让成本效率最大化" |
|
||
| **X-Service-Idea-Scanner** | 精准信号短语匹配 + 独立开发者视角过滤 | "用户说 I'd pay for 比 LLM 推测可靠得多" |
|
||
| **idea-scanner** | 三轴评分——需求×缺口÷成本的乘法公式 | "机会 = 需求 × 缺口 ÷ 成本，需求和缺口各占 40%" |
|
||
| **idea-generation** | 进化搜索 + 几何均分 + 盲辩去偏 | "任一致命缺陷直接归零——7 个盲审 Agent 对抗 LLM 讨好者偏差" |
|
||
| **SaaS Insight Engine** | 痛点发现 → 搜索量验证 → 竞争度评估 → 收入预测 | "有抱怨不等于有人付费，需搜索量佐证" |
|
||
| **GapFinder** | 投诉聚类——用 NLP 发现噪音背后的共性痛点 | "100 条不同的抱怨聚类到 3 个主题，那才是真实痛点" |
|
||
| **Business Idea Radar** | "人们愿意付费解决的真实问题"——付费意愿优先 | "付费意愿是第一筛选器" |
|
||
| **Reddit-PainPoint-Finder** | 先找对的地方（高价值 subreddit），再找对的人 | "痛点密度不均匀，先定位社区再挖掘" |
|
||
| **Market Gap Finder** | 五维度评分——结构化的机会评估框架 | "关键不在找什么而在怎么评——5 维交叉比单看抱怨更接近决策" |
|
||
| **Agent-Reach** | Agent 的"感知层"——先让 Agent 能看到互联网 | "眼睛够不够多决定了分析的上限" |
|
||
| **SurfSense** | 结构化数据 > markdown blob——给 Agent 吃干净的数据 | "输入数据质量决定痛点分析质量" |
|
||
| **Huginn** | Agent 式持续监控——"看变化"而非"看全部" | "增量监控比全量扫描更高效" |
|
||
| **GPT-Researcher** | Planner-Executor-Publisher——先问对的问题再并行采集 | "先规划研究角度，再并行采集，避免单一偏差" |
|
||
| **agentRadar** | 区分"单日噪声"vs"持续趋势"vs"新方向"——时间维度 | "只出现一天的痛点是噪声，连续一周才是机会" |
|
||
| **Claude World Studio** | 趋势发现→来源验证→质量评分→行动——闭环到验证 | "发现后需质量门控，不是所有痛点都值得做" |
|
||
| **Autensa/Mission Control** | 8 阶段全自动产品引擎——从研究到 PR 的完整闭环 | "最接近 Reed 的开源实现，但中间需要人类介入点" |
|
||
| **UX Workflow Check** | 意图优先——用用户视角走路，发现"伸手够不到的东西" | "痛点不只在论坛里——产品本身就充满了缺口" |
|
||
| **GummySearch** | Reddit 焦点小组——用 AI 替代人工社群研究 | "把传统用户研究搬到 Reddit，用 AI 替代人工阅读" |
|
||
| **n8n 模板** | 无代码编排——可视化工作流串起全管线 | "不写代码也能搭痛点监控管线" |
|
||
|
||
---
|
||
|
||
## 5. Reddit 社区实践总结
|
||
|
||
### 5.1 经典技术栈
|
||
|
||
| 组合 | 频率 | 说明 |
|
||
|------|------|------|
|
||
| PRAW + GPT-4 + cron | 最高频 | Python 抓 Reddit → GPT-4 分类投诉 → 定时循环 |
|
||
| Make/Zapier + OpenAI | 中频 | 无代码自动化：监控 subreddit → AI 分析 → 通知 |
|
||
| LangChain + PRAW + ChromaDB | 中频 | 向量数据库聚类相似痛点 |
|
||
| n8n + OpenAI | 低频 | n8n 工作流编排全流程 |
|
||
|
||
### 5.2 社区反馈的常见问题
|
||
|
||
| 问题 | 根因 | 社区解决方案 |
|
||
|------|------|------------|
|
||
| Reddit API 限流（100 QPM） | Reddit 2023 年收紧 API 政策 | 多 OAuth client 轮换 / 用 old.reddit.com 爬取 |
|
||
| 数据清洗和去重 | 爬取数据脏乱 | LLM 清洗 + 标签提取 + 实体识别 |
|
||
| AI 分类假阳性 | LLM 把非投诉误判为投诉 | 人工复核 + 频率阈值（出现 3+ 次才算痛点） |
|
||
| 部署后无人点击 | 痛点不够强 or MVP 太粗糙 | 先做 landing page 测点击率，再写代码 |
|
||
| 匿名接口被封 | 平台反爬升级 | 用登录态 Cookie / OpenCLI（浏览器登录态） |
|
||
|
||
### 5.3 社区验证有效的做法
|
||
|
||
- **搜索模式匹配**优于全量 AI 分析——先过滤再分析
|
||
- **痛点聚类**而非单条判断——聚合多个相似投诉
|
||
- **频率阈值**——3+ 次相似投诉才算痛点
|
||
- **同社区发布 MVP**——直接在痛点来源社区验证需求
|
||
- **landing page 先行**——先测点击率再写代码
|
||
|
||
---
|
||
|
||
## 6. 自建 Reed 的推荐架构
|
||
|
||
### 6.1 最小可行方案
|
||
|
||
直接 fork [reddit-idea-scraper](https://github.com/m-eugen/reddit-idea-scraper)，它的加权关键词 + 两阶段 AI 评估已经是完整的痛点发现管道。在此基础上扩展数据源到 Twitter/HN（用 [Agent-Reach](https://github.com/Panniantong/Agent-Reach)），并用 Claude Code 接收痛点输出自动生成 MVP。
|
||
|
||
### 6.2 完整架构
|
||
|
||
```
|
||
┌──────────────────────────────────────────────────────────────┐
|
||
│ 自建 Reed 的推荐架构 │
|
||
│ │
|
||
│ 感知层: Agent-Reach (⭐74k) — 给 Agent 装互联网眼睛 │
|
||
│ + SurfSense (⭐16k) — 结构化数据连接器 │
|
||
│ + Huginn (⭐43k) — 增量变化监控 │
|
||
│ ↓ │
|
||
│ 扫描层: reddit-idea-scraper 的加权关键词体系 │
|
||
│ (Money:10 / Frustration:7 / Request:6 / Switching:5) │
|
||
│ + X-Service-Idea-Scanner 的 9 条 query 模式 │
|
||
│ ↓ │
|
||
│ 分析层: reddit-idea-scraper 的两阶段 AI 评估 │
|
||
│ (Haiku 快筛 → Sonnet 深析 → MVP 规格生成) │
|
||
│ + SaaS_Insight_Engine 的搜索量交叉验证 │
|
||
│ + GapFinder 的投诉聚类 (MiniLM-L6-v2 + KMeans) │
|
||
│ ↓ │
|
||
│ 决策层: agentRadar 的时间维度 (区分噪声 vs 趋势) │
|
||
│ + Claude World Studio 的质量门控 (5维评分 ≥70) │
|
||
│ + Market Gap Finder 的 5 维机会评分 │
|
||
│ ↓ │
|
||
│ 建造层: Autensa/Mission Control (8阶段全自动引擎) │
|
||
│ 或 Claude Code / gpt-engineer │
|
||
│ ↓ │
|
||
│ 部署层: Vercel CLI / Railway CLI │
|
||
│ (自动部署 + 埋点追踪 + Stripe 支付验证) │
|
||
└──────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 6.3 各层选型理由
|
||
|
||
| 层 | 推荐方案 | 理由 |
|
||
|----|---------|------|
|
||
| 感知层 | Agent-Reach + SurfSense + Huginn | Agent-Reach 覆盖最广，SurfSense 提供结构化数据，Huginn 做增量监控降低成本 |
|
||
| 扫描层 | reddit-idea-scraper 加权关键词 + X-Service-Idea-Scanner query | 信号短语+权重比全量 AI 分析更准、更快、更便宜 |
|
||
| 分析层 | reddit-idea-scraper 两阶段 + SaaS_Insight_Engine 搜索量 + GapFinder 聚类 | 分层 AI + 定量验证 + 聚类降噪 = 最完整的分析管道 |
|
||
| 决策层 | agentRadar 时间维度 + 质量评分 | 过滤假信号，只投入持续趋势 |
|
||
| 建造层 | Autensa/Mission Control | 唯一有 8 阶段全自动闭环的开源项目 |
|
||
| 部署层 | Vercel CLI + Stripe | 自动部署+支付验证=Reed 的"有没有人付费" |
|
||
|
||
---
|
||
|
||
## 7. 核心洞察与方法论总结
|
||
|
||
### 7.1 痛点挖掘的七个层次
|
||
|
||
| 层次 | 做什么 | 对应项目 | Reed 的环节 |
|
||
|------|--------|---------|------------|
|
||
| **覆盖** | 让 Agent 能看到尽可能多的平台 | Agent-Reach, SurfSense, Huginn | ① 游荡扫描 |
|
||
| **过滤** | 用加权关键词从噪音中提取高信号内容 | reddit-idea-scraper, X-Service-Idea-Scanner | ② 痛点分析 |
|
||
| **聚类** | 用 NLP 把相似投诉归到一起，发现共性 | GapFinder | ② 痛点分析 |
|
||
| **验证** | 用搜索量/竞争度/频率交叉验证痛点真实性 | SaaS_Insight_Engine, agentRadar | ② 痛点分析 |
|
||
| **评分** | 对痛点做质量评分，决定是否值得投入 | Claude World Studio, Market Gap Finder | ② 痛点分析 |
|
||
| **建造** | 快速生成 MVP 代码 | Autensa, gpt-engineer, Claude Code | ③ 建产品 |
|
||
| **测试** | 部署、追踪点击/付费转化 | Vercel + Stripe | ④ 部署测试 |
|
||
|
||
### 7.2 关键原则
|
||
|
||
1. **信号短语 > 全量 AI 分析**：人类表达痛点有固定模式，直接搜这些模式比让 LLM 理解全量文本更准更便宜
|
||
|
||
2. **加权分级 > 二值过滤**：不是所有信号等价——付费意愿（权重 10）比情感表达（权重 7）比迁移暗示（权重 5）更值得追
|
||
|
||
3. **聚类 > 单条**：一条投诉是轶事，聚类后的共性主题才是信号。100 条不同的抱怨如果收敛到 3 个主题，那 3 个主题才是真实痛点
|
||
|
||
4. **时间维度 > 单日快照**：痛点是否持续上升比"今天有没有人抱怨"更重要
|
||
|
||
5. **搜索量 > 抱怨量**：有抱怨不等于有人付费，需搜索量佐证商业价值
|
||
|
||
6. **结构化数据 > 原始文本**：给 Agent 结构化数据比给 markdown blob 分析质量更高
|
||
|
||
7. **质量门控 > 照单全收**：不是所有痛点都值得做产品，需要评分系统过滤
|
||
|
||
8. **分层管道 > 单模型**：先用零成本的关键词过滤，再用便宜模型快筛，最后用强模型深析——成本效率最大化
|
||
|
||
9. **增量监控 > 全量扫描**：只看"自上次以来新增了什么"比每次全量扫描更高效
|
||
|
||
10. **闭环 > 单次**：Reed 的核心价值不在单次扫描，而在 24/7 持续循环——今天的噪声可能下周变成趋势
|
||
|
||
### 7.3 Reed 模型的本质
|
||
|
||
Reed 不是一个"更聪明的 Agent"，而是一条**把人类商业直觉编码为自动化管线**的尝试。它的每个环节都对应一个人类创业者会做的事：
|
||
|
||
- 刷论坛看抱怨 → **加权关键词 + 定时爬虫**
|
||
- 判断痛点是否值得做 → **聚类 + 搜索量验证 + 质量评分**
|
||
- 快速做个 demo → **AI 代码生成**
|
||
- 扔上去看有没有人用 → **自动部署 + 埋点追踪**
|
||
|
||
Alex Finn 的贡献不是发明了任何一个环节，而是把它们**串成了全自动闭环**。这正是 2025 年 AI Agent 的核心范式：不是单点智能，而是端到端自动化。
|
||
|
||
### 7.4 开源世界能做到什么程度？
|
||
|
||
| Reed 的环节 | 开源最优方案 | 还差什么 |
|
||
|------------|------------|---------|
|
||
| ① 游荡扫描 | Agent-Reach + Huginn | ✅ 基本满足，多平台覆盖+增量监控 |
|
||
| ② 痛点分析 | reddit-idea-scraper + GapFinder | ✅ 方法论完整（加权+聚类+两阶段 AI） |
|
||
| ③ 快速建产品 | Autensa/Mission Control | ⚠️ 有 8 阶段闭环但需要人类 Swipe 介入 |
|
||
| ④ 部署测试 | Vercel + Stripe | ⚠️ 部署有，但"测试有没有人付费"的自动决策逻辑缺失 |
|
||
| ⑤ 闭环循环 | Autensa Full Auto 模式 | ⚠️ 最接近，但仍需人类监督 |
|
||
|
||
**结论**：开源世界已经可以覆盖 Reed 的前两个环节（扫描+分析）到生产级；第三环节（建产品）有雏形但不够可靠；第四环节（部署测试的自动决策）几乎没有开源方案。要真正复现 Reed，需要在③④之间加入一个"部署后数据反馈→自动决定继续投入还是换方向"的组件——这是当前开源空白区。
|
||
|
||
---
|
||
|
||
## 参考项目索引
|
||
|
||
### 痛点发现管道
|
||
|
||
| 项目 | 仓库 | Stars | 核心价值 |
|
||
|------|------|-------|---------|
|
||
| GapScout | [GitHub](https://github.com/yanji84/gapscout) | ⭐1 | 225 子 Agent 覆盖 11+ 源（最复杂的多 Agent 系统） |
|
||
| reddit-idea-scraper | [GitHub](https://github.com/m-eugen/reddit-idea-scraper) | — | 加权关键词+两阶段 AI（最完整的管道） |
|
||
| X-Service-Idea-Scanner | [GitHub](https://github.com/kiknaio/X-Service-Idea-Scanner) | ⭐1 | 信号短语匹配+独立开发者过滤 |
|
||
| idea-scanner | [GitHub](https://github.com/dcrjodle/idea-scanner) | — | 三轴评分（需求×缺口÷成本） |
|
||
| idea-generation | [GitHub](https://github.com/Moa1er/idea-generation) | — | 进化搜索+几何均分+7 Agent 盲辩 |
|
||
| SaaS Insight Engine | [GitHub](https://github.com/IcedCoffeeDrinker/SaaS_Insight_Engine) | ⭐0 | 痛点+搜索量交叉验证 |
|
||
| GapFinder | [GitHub](https://github.com/aryangovindrao/GapFinder-full-stack-platform) | — | 投诉聚类+AI 想法生成 |
|
||
| Business Idea Radar | [GitHub](https://github.com/martinbouvet2000-tech/business-idea-radar) | ⭐0 | 付费意愿优先 |
|
||
| Reddit-PainPoint-Finder | [GitHub](https://github.com/Anthonytesla02/Reddit-PainPoint-Finder) | ⭐0 | 社区定位再挖掘 |
|
||
| Market Gap Finder | [GitHub](https://github.com/mloki23/market-gap-finder) | — | 5 维度机会评分 |
|
||
| UX Workflow Check | [GitHub](https://github.com/sergiobuilds/ux-workflow-check) | — | 意图优先 UX 缺口发现 |
|
||
| startup-idea-miner | [GitHub](https://github.com/basspekel/startup-idea-miner) | — | Reddit 投诉挖掘+定时邮件推送 |
|
||
|
||
### 扫描基础设施
|
||
|
||
| 项目 | 仓库 | Stars | 核心价值 |
|
||
|------|------|-------|---------|
|
||
| Agent-Reach | [GitHub](https://github.com/Panniantong/Agent-Reach) | ⭐74k | 多平台感知层 |
|
||
| SurfSense | [GitHub](https://github.com/MODSetter/SurfSense) | ⭐16k | 结构化数据连接器 |
|
||
| Huginn | [GitHub](https://github.com/huginn/huginn) | ⭐43k | 增量变化监控 |
|
||
| GPT-Researcher | [GitHub](https://github.com/assafelovic/gpt-researcher) | ⭐29k | 规划-执行-发布架构 |
|
||
| Nanobrowser | [GitHub](https://github.com/nanobrowser/nanobrowser) | ⭐14k | Chrome AI 自动化 |
|
||
|
||
### 趋势判断
|
||
|
||
| 项目 | 仓库 | Stars | 核心价值 |
|
||
|------|------|-------|---------|
|
||
| agentRadar | [GitHub](https://github.com/sunrisefromdark/agentRadar) | ⭐50 | 时间维度趋势判断 |
|
||
| Claude World Studio | [GitHub](https://github.com/claude-world/claude-world-studio) | ⭐72 | 趋势发现+质量门控 |
|
||
|
||
### 产品建造+部署
|
||
|
||
| 项目 | 仓库 | Stars | 核心价值 |
|
||
|------|------|-------|---------|
|
||
| Autensa/Mission Control | [GitHub](https://github.com/crshdn/mission-control) | ⭐2k | 8 阶段全自动产品引擎 |
|
||
| OpenHands | [GitHub](https://github.com/All-Hands-AI/OpenHands) | ⭐30k | 自主编码平台 |
|
||
| OpenManus | [GitHub](https://github.com/mannaandpoem/OpenManus) | ⭐40k+ | 开源 Manus 克隆 |
|
||
| AgenticSeek | [GitHub](https://github.com/Fosowl/agenticSeek) | ⭐27k | 全本地自主 Agent |
|
||
| SaaS-Builder | [GitHub](https://github.com/jatingargiitk/saas-builder) | ⭐223 | 自然语言→完整 SaaS |
|
||
| gpt-engineer | [GitHub](https://github.com/gpt-engineer-org/gpt-engineer) | 高 | 需求→代码生成 |
|
||
| n8n | [GitHub](https://github.com/n8n-io/n8n) | 高 | 无代码工作流编排 |
|
||
|
||
### 商业参考
|
||
|
||
| 项目 | 链接 | 核心价值 |
|
||
|------|------|---------|
|
||
| GummySearch | [gummysearch.com](https://gummysearch.com) | Reddit 焦点小组 |
|
||
| Magnet AI | [YC W25](https://www.ycombinator.com/companies/magnet-3) | Reed 思路的商业化 |
|
||
| system-prompts 库 | [GitHub](https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools) | 提取了 Devin/Manus/Cursor 的系统提示词 |
|
||
|
||
### 方法论参考
|
||
|
||
| 来源 | 链接 | 核心价值 |
|
||
|------|------|---------|
|
||
| Complaint-Driven Development 论文 | [arXiv:2408.15790](https://arxiv.org/abs/2408.15790) | CDD 学术定义 |
|
||
| Pieter Levels | [levels.io](https://levels.io) / [@levelsio](https://x.com/levelsio) | "Build What People Want" 方法论 |
|
||
| Justin Jackson | [transistor.fm/blog](https://transistor.fm/blog/) / [@mijustin](https://x.com/mijustin) | Demand Validation 方法论 |
|
||
| GummySearch Blog | [gummysearch.com/blog](https://gummysearch.com/blog) | Reddit-first 客户开发 |
|