问题
决定做独立开发。第一个问题：做什么？
两个月里，我的日常是这样的：
- 刷 Reddit 的 r/SaaS 和 r/startups，找吐槽帖
- 逛 Product Hunt 看产品排名，翻评论区
- 翻 App Store 的 2-4 星评价
- 去 X 上关注独立开发者讨论的热门方向
每次都一样——发现一个需求，兴奋一晚上，第二天醒来开始自我否定：
- "但 Google Sheets 也能解决啊"
- "但大厂做一个一样的怎么办"
- "但加拿大才4000万人口，市场太小了"
两个月，zero progress。
我后来复盘这个过程，发现了真正的问题。
真正的问题：判断材料不够
我用来判断"这个需求值不值得做"的全部知识，来自我自己的大脑。
一个做了几年全栈开发、在市场判断上基本为零的大脑。
我不知道全球有多少自由职业者。我不知道加拿大理财市场的规模。我不知道历史上类似产品是怎么成功的。
我连判断的素材都没有，就在做判断。
更危险的是，我总能把"我不知道"伪装成"我觉得不行"。朋友说他看到了一个跨境支付的巨大需求，我第一反应是"Stripe 不是已经做了吗"——但我其实连 Stripe 的确切定价都不知道。
这就像一个从没出过村的人，在对着世界地图说：这里不值得去，那里也不值得去。
换个思路
如果我的判断不可靠，谁的行？
投资人？一年看几千个项目，失败率还是很高。成功创业者？经验高度依赖具体的时间和场景，很难复制。
然后我意识到一件事：GPT-4 和 Claude 这类大模型，读过的商业案例、市场报告、用户反馈，比我多好几个数量级。
Claude 的训练数据里，可能包含所有 YC 投资公司的公开分析、被广泛引用的市场研究报告、无数 Reddit 和 HN 上关于产品的讨论。它的"知识广度"超过任何一个人类专家。
那为什么不直接让它来做判断？
我做了什么
基于 Claude Code 的 Skill 机制，我建了一个叫 demand-mining 的流程。它不是一个独立应用，而是一个 Markdown 格式的流程定义文件——大约 200 行，定义了从信号采集到机会排序的完整逻辑。
Claude Code 的 Skill 文件放在项目 .claude/skills/<name>/SKILL.md 路径下，调用 /demand-mining 即可运行。
完整流程分 6 个阶段：
Phase 1：确定方向
输入一个领域（如"金融工具类网站"），或者不输入任何方向，让系统从 Reddit、HN、Product Hunt 等源头自动扫描当前的热门讨论。
Phase 2：多源信号采集
调用 WebSearch 和 WebFetch 工具，从以下来源抓取原始数据：
- Reddit：r/SaaS, r/startups, r/selfhosted, r/productivity 的吐槽帖
- Hacker News：Ask HN 和 Show HN 中关于痛点的讨论
- 应用商店：2-4 星评论（最可能包含具体、理性的痛点描述）
- Product Hunt：高票产品的评论区差评和改进建议
- X / Twitter：搜索 "I wish there was..." 类表达
每条原始信号必须记录来源 URL、原文关键段落（保留原话）、信号类型。
Phase 3：提取需求信号
从吐槽中提取结构化信息：谁在痛？有多痛？现在怎么解决的？是否表达过付费意愿？
关键规则：只保留有具体场景的痛点。 "这软件不好用"这类模糊评价直接丢弃。
Phase 4：五维度评分（核心）
这是整个系统最关键的一步。对每个需求信号，从 5 个维度打分（1-10），每个分数必须附带具体依据。
| 维度 | 权重 | 说明 |
|---|---|---|
| 痛点强度 | 25% | 用户语言的情绪强烈程度、是否每天受影响、是否表达付费意愿 |
| 市场规模 | 25% | 受影响人群的全球规模估算（依赖模型知识，必须给出估算逻辑） |
| 竞争格局 | 20% | 竞品的数量、质量、用户评分——必须有具体竞品名称和数据 |
| 技术可行性 | 15% | 技术栈难度、所需资源、是否有开源方案可借鉴 |
| 商业化清晰度 | 15% | 对标竞品定价、用户付费意愿、是否属于刚需支出 |
综合分 = 加权求和。
最重要的一条约束：评分阶段完全由模型基于自身知识完成，禁止询问用户意见。 这保证了评分不受我自己的认知偏差干扰。
Phase 5：过滤与排序
综合分低于 4.5 的直接淘汰。本质上相同的需求合并。剩余按分数降序排列，分为三档：
- 🔥 高优先（≥ 7.5）
- ✅ 值得关注（6.0–7.4）
- ⚠️ 待观察（4.5–5.9）
Phase 6：深度分析
对 Top 3 的需求，做以下维度的深入剖析：
- 为什么这个需求一直没有被解决？（技术壁垒？市场太小？用户付费意愿低？）
- 历史上有类似的成功案例吗？
- MVP 应该长什么样？核心验证假设是什么？
- 风险清单：技术、市场、竞争、平台风险
- 模型对自身判断的信心度（高/中/低）及原因
第一次实战：分析"金融工具"方向
我让系统分析"金融工具类网站"这个方向。
它搜索了约 15 个关键词组合，从 Reddit、HN、Product Hunt、Trustpilot、应用商店评论等 20+ 个来源中提取了 8 个需求信号，然后逐一打分排序。
排名前 3 的是：
#1 自由职业者实时税务估算 — 7.50 分
美国有 6400 万自由职业者（Upwork 2024 数据），每季度都要估算税款并预留资金。算少了面临 IRS 罚款（2025 年欠缴利率 8%），算多了占用现金流。QuickBooks Self-Employed 曾经是唯一专做这个的工具，但 Intuit 在 2024 年关闭了它，留出了数十万付费用户的空白。
#2 自由职业者一体化财务工具 — 7.15 分
发票、记账、税务估算、客户管理——自由职业者目前用 3-5 个工具拼凑，数据不互通。QuickBooks 功能太多太贵（$30+/月），Wave 免费版不断缩水，FreshBooks 有信任问题。
#3 非美国市场理财工具 — 7.10 分
Monarch Money 在 Trustpilot 上被加拿大用户打了 2.3 分——"在加拿大完全没用"。主流个人理财 App 几乎全部只支持美国银行，加拿大、英国、澳大利亚、新加坡的用户被系统性地忽视。
这三个方向，放在之前，我一个都不会认真考虑。
"税务估算？太无聊了吧。""非美国市场？我又不了解。"——这就是我的直觉在工作。而实际数据显示，这些方向恰恰是需求最强烈、竞争最少、市场最大的。
我的直觉，在每一个高评分机会上都错了。
关键设计决策
1. "禁止询问用户意见"是系统生效的前提
如果允许用户在评分阶段介入——"我觉得这个方向不错，把分调高一点吧"——认知偏差就会重新进入系统。技术可行性 9 分的"AI 财务助手"听起来很酷，但它的市场规模只有 5 分、商业化只有 4 分。如果让我来调分，它会冲到第一。
2. "必须写依据"比打分本身更重要
早期版本我给模型的指令是"请打分"，模型会给 7 分、8 分，但没有理由。改成"每个分数必须写出依据：数据来源、估算逻辑、推理过程"之后，评分质量和可验证性显著提升。7 分是"因为全球 X 万从业者"还是"因为感觉市场不小"——差别巨大。
3. 加权 vs 等权重
用等权重跑了一次对比实验。结果"听起来很酷的 AI 方向"因为有技术新颖性加分而排到了第一，但它的市场规模和商业化路径都有很大不确定性。加权把"痛点 + 市场"提到 50%，让"确定性强但无聊"的需求排到前面。对独立开发者来说，确定性比新颖性更重要。
4. 信号源的多样性决定报告质量
第一版只用 Reddit。结果讨论高度偏向技术人群，报告里全是"开发工具""效率工具"，忽略了普通用户的需求。后来扩展到应用商店评论、Trustpilot 差评，信号多样性明显提升。根据目标用户调整信号源，比盲目增加来源数量更有效。
这个系统的局限
如实说。
1. 模型知识有时效性问题。 Claude 的训练数据截止日期意味着它对最新市场变化（比如某竞品刚融了多少钱、某产品刚上线）可能不知情。报告需要结合实时搜索验证。
2. 评分存在"近因偏好"。 跑了几次后发现模型倾向于给技术性强的方向打高分。这可能反映了 Reddit 和 HN 的讨论以技术话题为主导致的训练数据偏差。对大模型来说，"税务软件"天然不如"AI 工具"性感。
3. 市场规模的数据可能不准确。 模型引用的市场规模数据来自训练语料，可能包含过时的、估算错误的、甚至互相矛盾的信息。评分依据里的数字应该被视作"初步估算"而非事实。
4. 这不能替代真正的用户调研。 报告给出的是方向级别的判断。具体到执行层面，你仍然需要去和目标用户聊、做落地页测试、跑 MVP 实验。这个系统取代的是"我该选哪个方向"，不是"怎么做出好产品"。
2026-07-07 更新
Skill 在持续迭代中。当前版本已有一次实际运行（金融工具方向），产出了一份完整的分析报告。后续计划：
- 增加领域定制能力（B2B SaaS vs 消费 App 的评分逻辑 不同）
- 引入"趋势维度"（AI 相关的需求是否在快速增长？）
- 积累案例后校准模型打分尺度
关于对错
写完这篇文章，我需要澄清一件事：
我不是在说"这个系统找到了正确答案"。评分可能有偏差，模型知识也可能有过时的地方。
我想说的是：在没有这个流程之前，我的判断来源是不可靠的直觉。有了之后，我的判断来源变成了结构化的、可追溯的、可修正的数据分析。
即使分析错了，我也可以回头看具体是哪个维度的评分出了问题，然后修正。而直觉判断错了，你连"错在哪"都不知道。
可修正的错误，比固执的正确更有价值。
如果你也在找产品方向，或者对评分维度有更好的想法，欢迎在项目 GitHub 讨论。