利用Claude Code构建自动化需求挖掘工具：从原理到实践

1. 问题背景

在独立开发或创业初期，方向选择是最重要也最困难的决策。传统的做法依赖个人经验和直觉，但个人认知存在显著局限：

信息不完整：不知道某个细分市场到底有多大
认知偏差：倾向于否定陌生的方向、追逐热门的方向
无法量化比较：不同方向之间的选择靠"感觉"而非数据

本文介绍一种方案：利用大模型（Claude）的海量训练知识，构建一个结构化的需求挖掘和评估系统，让模型替代人工完成需求发现、评分和排序。

2. 方案设计

2.1 架构思路

复制代码

输入（方向/领域）
    ↓
Phase 1: 确定搜索范围
    ↓
Phase 2: 多源信号采集（WebSearch + WebFetch）
    ↓
Phase 3: 信号提取 & 结构化
    ↓
Phase 4: 五维度加权评分
    ↓
Phase 5: 过滤 & 排序
    ↓
Phase 6: Top-N深度分析
    ↓
输出（机会排序报告）

2.2 为什么选择Claude Code Skill

Claude Code的Skill机制允许将一段完整的执行流程定义为可复用的配置文件。每次调用Skill时，模型会严格按照定义的流程执行，保证输出的一致性和可比较性。

相比直接让模型"分析需求"，Skill的优势：

流程标准化，每次输出格式一致
评分维度固定，不同方向可以横向比较
约束条件可配置（如过滤阈值、权重等）
可以持续迭代优化

3. Claude Code Skill机制简介

Claude Code的Skill定义在项目 .claude/skills/<skill-name>/SKILL.md 文件中，格式如下：

markdown 复制代码

---
name: skill-name
description: 一句话描述
user-invocable: true
---

# skill-name --- 标题

## 成功标准
定义"效果好"的评判标准

## 工作流程
分阶段描述执行步骤

## 输出格式
定义最终产物的结构

Skill可以通过 /skill-name 命令在Claude Code会话中直接调用。如果Skill未被自动加载，也可以手动按照SKILL.md的描述执行流程。

4. 核心实现：demand-mining Skill

4.1 信号采集阶段（Phase 1-2）

在Phase 1确定搜索方向后，Phase 2执行多源信号采集。核心搜索策略：

text 复制代码

搜索源1：Reddit
- 搜索模式：site:reddit.com <关键词> + "frustrated" / "sucks" / "alternative"
- 目标子版块：r/SaaS, r/startups, r/selfhosted, r/productivity
- 提取内容：帖子标题 + 高赞评论 + OP的回复

搜索源2：Hacker News
- 搜索模式：site:news.ycombinator.com <关键词> + "Ask HN" / "Show HN"
- 关注点：用户的"I wish"、"why is there no"类表达

搜索源3：应用商店评论
- 重点抓取2-4星评论（最可能包含具体痛点）
- 1星评价往往是情绪发泄（"垃圾软件"），5星没有参考价值
- 结构化提取：评分 + 标题 + 评论正文 + 用户地域

搜索源4：Product Hunt
- 高票产品的评论区
- 关注：功能请求、改进建议、竞品比较

每条原始信号必须记录：来源URL、原文关键段落（保留原话）、信号类型、提及频率。

4.2 需求提取阶段（Phase 3）

从原始信号中提取结构化需求：

字段	提取方法
痛点描述	用用户原话，不加修饰
当前解决方案	用户现在怎么处理的
影响人群	职业/场景/规模
需求强度	语言情绪分析 + 付费意愿标记
频率标记	跨来源的重复出现次数

过滤规则：只保留有具体场景的痛点。"这个软件不好用"这类模糊评价直接丢弃------它不能导向任何具体的产品设计。

4.3 需求评估阶段（Phase 4）

评估阶段的核心约束：完全依赖模型自身知识做判断，禁止询问用户意见。

这样做是为了消除用户的认知偏差------"我觉得这个方向不行"往往来自直觉而非数据。

5. 评分算法详解

5.1 五个维度

text 复制代码

维度1：痛点强度（权重0.25）
评分标准：
- 10分：每天痛苦，愿意立刻付费
- 7-9分：频繁发生，显著影响效率
- 4-6分：偶尔发生，有workaround
- 1-3分：很轻微的annoyance

依据来源：用户原话的情绪强度、
"每天""崩溃""浪费时间"等关键词、
是否明确表达付费意愿

text 复制代码

维度2：市场规模（权重0.25）
评分标准：
- 10分：全球数亿人
- 7-9分：千万到亿级
- 4-6分：百万级
- 1-3分：十万以下

依据来源：模型训练数据中的市场规模知识，
受影响的职业/人群全球规模估算，
相关赛道已有产品的用户量级。
必须给出具体估算逻辑。

text 复制代码

维度3：竞争格局（权重0.20）
评分标准：
- 10分：几乎没有直接竞品
- 7-9分：有竞品但评分低、用户不满
- 4-6分：有成熟竞品但存在空白
- 1-3分：头部产品强大且用户满意度高

依据来源：竞品名称、融资金额、用户规模、
App Store评分、G2评分等公开信息

text 复制代码

维度4：技术可行性（权重0.15）
评分标准：
- 10分：独立开发者1-2周MVP
- 7-9分：小团队1-3个月
- 4-6分：需要一定技术积累
- 1-3分：需要大量资源（硬件、数据、合规）

依据来源：技术栈难度、所需资源、
是否有开源方案可以借鉴

text 复制代码

维度5：商业化清晰度（权重0.15）
评分标准：
- 10分：付费预期明确，客单价高
- 7-9分：有清晰付费场景，竞品已验证
- 4-6分：付费逻辑成立但需要验证
- 1-3分：用户习惯免费，商业化模糊

依据来源：竞品定价、用户是否已在付费、
是否属于刚需支出

5.2 综合评分公式

python 复制代码

def calculate_score(scores):
    return (
        scores['pain_intensity']    * 0.25 +
        scores['market_scale']       * 0.25 +
        scores['competition']        * 0.20 +
        scores['tech_feasibility']   * 0.15 +
        scores['monetization']       * 0.15
    )

5.3 分类阈值

python 复制代码

if score >= 7.5:
    category = "🔥 高优先"
elif score >= 6.0:
    category = "✅ 值得关注"
elif score >= 4.5:
    category = "⚠️ 待观察"
else:
    category = "❌ 淘汰"

6. 运行效果与验证

以"金融工具类网站"为方向，运行demand-mining Skill的结果：

数据采集：来自20+个来源，覆盖Reddit、HN、Product Hunt、Trustpilot、应用商店评论。

提取到的8个需求信号及评分：

排名	需求	痛点	综合分
1	自由职业者实时税务估算	不知道每季度该留多少钱交税	7.50
2	自由职业者财务All-in-one	发票+记账+税务分散在3-5个工具	7.15
3	非美国市场理财	主流App不支持本地银行	7.10
4	极简CSV记账工具	不想给银行密码，不要复杂功能	6.95
5	AI原生财务助手	自然语言交互代替看图表	6.70

关键发现：排名前3的方向，用户在运行此分析之前一个都没考虑过。这说明个人直觉和市场实际需求之间存在显著偏差。

7. 扩展与定制

7.1 调整权重

如果你的情况不同（比如有技术团队但资金紧张），可以调整评分权重。修改SKILL.md中的综合评分公式即可。

7.2 增加新的信号源

在Phase 2的搜索策略中增加新的搜索源。例如针对B2B产品，可以增加G2/Capterra的评论抓取。

7.3 自定义行业知识

如果你的领域特别垂直（比如医疗SaaS、工业软件），可以在Skill中增加领域特定的竞争力评估维度，比如"合规门槛""客户决策周期"等。

7.4 与其他工具集成

整个系统基于Markdown格式的Skill定义和报告输出，可以很容易地集成到已有的产品决策流程中。输出的报告可以直接作为PRD的前置文档。

8. 源码地址

项目完整代码和Skill定义文件见GitHub：

👉 GitHub：https://github.com/xiaoyunchengzhu/require-dis

目录结构：

复制代码

require-dis/
├── CLAUDE.md                   # 项目规范
├── .claude/skills/
│   └── demand-mining/SKILL.md  # Skill定义（核心文件）
├── reports/                    # 分析报告输出
└── memory/                     # 经验沉淀

欢迎Star⭐，也欢迎提Issue讨论评分维度的改进。

本文写于2026年7月。工具在持续迭代中，最新效果以GitHub上的版本为准。