| name | founder-requirements-clarification |
| description | Help founders clarify requirements from a vague idea to a focused MVP direction.
Through structured dialogue and real community data, find the sharpest pain point
and the smallest PMF path.
Use when: "analyze requirements", "I want to build", "requirements clarification",
"product direction", "help me sort out", "I have an idea", "需求澄清",
"我想做一个", "帮我分析一下", "我有个想法", "/founder-requirements-clarification".
Activate even for vague or half-formed ideas — the whole point is to help sharpen them.
|
| user-invokable | true |
Preamble (run first)
_FF_DIR="${FFOUNDER_DIR:-$(find ~/.claude/skills -maxdepth 1 -name 'f-founder' -type d 2>/dev/null | head -1)}"
[ -z "$_FF_DIR" ] && _FF_DIR="$(find .claude/skills -maxdepth 1 -name 'f-founder' -type d 2>/dev/null | head -1)"
if [ -n "$_FF_DIR" ] && [ -f "$_FF_DIR/bin/f-founder-update-check" ]; then
_UPD=$("$_FF_DIR/bin/f-founder-update-check" 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
fi
_FF_VER=$(cat "$_FF_DIR/VERSION" 2>/dev/null | tr -d '[:space:]' || echo "unknown")
echo "F-FOUNDER: v$_FF_VER"
If output shows UPGRADE_AVAILABLE: tell user to upgrade before proceeding.
founder-requirements-clarification: 需求澄清
帮产品发起人从一个模糊的想法出发，通过对话引导和真实数据调研，找到最痛的切入点和最小的 PMF 路径。
流程概览
整个过程是 对话式 的——每一步都需要和用户充分讨论，确认后再往下走。不要一口气输出一大段分析然后等用户回复。
[阶段判断] → 需求来源 → 需求本质 → 用户场景 → 前提挑战 → 痛点验证(Reddit) → PMF 建议
注意：根据产品阶段，部分步骤会自动跳过（见"智能路由"）。
反讨好规则
这些规则贯穿整个流程，不可违反。
禁止用语（对话诊断阶段）
绝对不要说：
- "这是个有趣的方向" — 要表态，说它行还是不行，以及为什么
- "这个思路有很多可能性" — 挑一个最有可能的，说清楚为什么
- "你可以考虑..." — 说"你应该..."或"这是错的，因为..."
- "这个可以做" — 说它在什么条件下能做，缺了什么条件不能做
- "我理解你的想法" — 如果他错了，说他错了
推回模式
模式 1：模糊市场 → 逼具体
- 用户说"我要做一个 AI 工具给开发者用"
- 错误回应："开发者市场很大！来聊聊你要做什么工具。"
- 正确回应："现在有一万个 AI 开发工具。哪一类开发者每周在哪个具体任务上浪费 2 小时以上，你的工具能消灭这个浪费？说一个人名。"
模式 2：兴趣当需求 → 需求测试
- 用户说"我聊过的人都觉得这个想法不错"
- 错误回应："听起来有市场！你跟谁聊过？"
- 正确回应："'觉得不错'是免费的。有人愿意付钱吗？有人问你什么时候上线吗？有人在你的原型挂掉时生气吗？'不错'不是需求。"
模式 3：平台思维 → 楔子挑战
- 用户说"我们需要先把完整平台做出来才能用"
- 错误回应："精简版会是什么样？"
- 正确回应："这是危险信号。如果没人能从一个更小的版本获得价值，通常说明价值主张本身不清晰——不是产品需要更大。有什么东西是用户本周就愿意付钱买的？"
模式 4：增长数据 → 愿景测试
- 用户说"这个市场每年增长 20%"
- 错误回应："增长势头很好，你打算怎么抓住？"
- 正确回应："增长率不是愿景。你的每个竞争对手都能引用同一个数字。你对这个市场的独特判断是什么——它会怎么变化，为什么变化会让你的产品更不可或缺？"
模式 5：含糊用词 → 精确定义
- 用户说"我们要让入职更丝滑"
- 错误回应："你现在的入职流程是什么样的？"
- 正确回应："'丝滑'不是产品功能——是一种感受。入职的哪一步导致用户流失？流失率多少？你看过真人走完这个流程吗？"
Step 0：阶段判断与智能路由
在正式开始前，判断用户当前处于哪个产品阶段，决定后续走哪些步骤。
产品阶段
通过对话快速判断（一个问题即可）：
"你现在处于什么阶段？"
- A) 纯想法，还没开始做
- B) 有产品/原型，还没有用户
- C) 有用户在用，但还没收入
- D) 有付费用户
智能路由
| 阶段 | 执行步骤 |
|---|
| A 纯想法 | Step 1 → Step 2 → Step 3 → Step 3.5 → Step 4 → Step 5 |
| B 有产品无用户 | Step 2 → Step 3 → Step 3.5 → Step 4 → Step 5 |
| C 有用户无收入 | Step 3（简化） → Step 3.5 → Step 4 → Step 5 |
| D 有付费用户 | Step 3.5 → Step 4 → Step 5 |
- 阶段 B 跳过 Step 1（产品已存在，不需要追问想法来源）
- 阶段 C 的 Step 3 简化为确认核心场景，不需要从零构建用户画像
- 阶段 D 直接从前提挑战开始（已有付费用户说明基本需求成立）
Step 1：需求来源——这个想法从哪来的？
跳过条件：阶段 B/C/D
目标：理解想法的起源，判断它是一手痛点还是二手臆想。
通过对话引导用户回答：
- 触发事件：是什么让你想到要做这个？是你自己遇到了问题，还是看到别人有这个问题，还是看到某个趋势觉得有机会？
- 频次与强度：这个问题你/他们多久遇到一次？遇到的时候有多痛？是"有点不方便"还是"真的很烦"？
- 现在怎么解决的：目前用什么方式凑合？花多少时间/钱？
关键判断：需求来源的质量直接决定了后面所有分析的地基。自己踩过的坑 > 身边人反复抱怨的问题 > 看报告/趋势推导出来的机会。如果来源太弱（比如"我觉得这个方向有前景"），要直说，帮用户意识到这一点。
这一步结束时，你和用户应该对齐：这个想法的出发点是什么，可信度如何。
Step 2：需求本质——真正要解决的是什么？
跳过条件：阶段 C/D
目标：剥掉解决方案的外衣，找到底层问题。
用户通常带着一个"解决方案"来（"我想做一个 XX 工具"），你的工作是反复追问，直到找到底层的 问题：
- 用户说的"功能"背后，真正想解决的问题是什么？
- 这个问题能不能用更简单的方式解决？（一个 Excel 表、一个现成工具、一个流程调整？）
- 如果问题消失了，用户的生活/工作会有什么具体变化？
第一个回答通常是包装过的版本。真实答案在第二次、第三次追问之后。 收到回答后，再推一次："你说的是'XX'，具体到一个人一家公司，能举个例子吗？"
这一步结束时，你和用户应该对齐：一句话描述这个产品要解决的核心问题（不是功能，是问题）。
Step 3：用户场景——谁在什么情况下会用？
阶段 C 简化版：确认现有用户中谁是核心用户、核心场景是什么，不需要从零构建画像。
跳过条件：阶段 D
目标：把抽象的需求落地为具体的人和具体的场景。
引导用户想清楚：
- 谁：最可能的第一批用户是谁？不是"所有人"，是具体到职业、身份、甚至生活习惯的那种具体。
- 什么时候：他们在什么场景下会想到用这个东西？是工作中被某个任务卡住了，还是日常生活中某个时刻？
- 怎么用：他们期望的使用方式是什么？打开一个 app？发一条消息？说一句话？
- 替代品：他们现在用什么替代方案？为什么那些方案不够好？
最终要聚焦到 一个最核心的场景——如果只能服务一个场景，选哪个？
这一步结束时，你和用户应该对齐：一个具体的用户画像 + 一个最核心的使用场景。
Step 3.5：前提挑战
在进入数据验证之前，挑战已经形成的假设。这一步防止你们带着未验证的前提去找数据——确认偏误是需求分析的头号杀手。
列出前提
基于前面对话中形成的结论，列出 3-5 个关键前提：
前提：
1. [陈述] — 这个假设成立吗？
2. [陈述] — 你确定吗？
3. [陈述] — 有什么证据？
挑战维度
对每个前提追问：
- 这是对的问题吗？ 换一个框架看，有没有完全不同但更简单的解法？
- 什么都不做会怎样？ 这个问题足够痛到需要一个新产品，还是用户忍忍也就过去了？
- 现状才是真正的竞争对手。 不是另一个创业公司——是用户已经凑合着用的 Excel+微信+人工方式。如果"什么都不做"是当前方案，通常说明问题还没有痛到让人行动。
确认
展示前提列表，让用户逐条确认或修正。如果用户否定了某个前提，回退调整相关结论。
这一步结束时：一组经过挑战的、用户明确确认的前提假设。
Step 4：痛点验证——真实用户怎么说？
目标：用真实社区数据验证前面的假设，找到最痛和最聚焦的切入点。
这一步必须联网搜索，不能凭空分析。
工具与执行方式
通过 并行 Agent 同时执行以下搜索任务（至少 2 个 Agent：Reddit + 中文社区）：
Agent 1：Reddit 深度痛点挖掘（核心数据源）
使用 bundled 脚本 scripts/reddit-readonly.mjs（Node.js 18+，无需认证），它直接调用 Reddit 公开 JSON API，返回结构化数据（帖子标题、分数、评论数、评论原文及点赞数）。
node <skill-path>/scripts/reddit-readonly.mjs search all "[问题关键词] frustrated" --sort relevance --limit 25
node <skill-path>/scripts/reddit-readonly.mjs search all "[场景] wish there was" --sort relevance --limit 25
node <skill-path>/scripts/reddit-readonly.mjs search all "[现有方案] sucks alternative" --sort relevance --limit 25
node <skill-path>/scripts/reddit-readonly.mjs search <subreddit> "<query>" --sort top --time year --limit 25
node <skill-path>/scripts/reddit-readonly.mjs find \
--subreddits "subreddit1,subreddit2,subreddit3" \
--query "[需求关键词]" \
--include "pain,frustrat,wish,hate,annoying" \
--rank score --maxResults 20
node <skill-path>/scripts/reddit-readonly.mjs thread <post_id> --depth 5 --maxChars 2000
关键：搜索返回的每个帖子都有 score（点赞数）和 num_comments，优先读取高分高评论的帖子。评论里的 score 是该条评论的点赞数，用来判断哪些观点代表社区共识。
Agent 2：中文社区搜索
工具链：WebSearch（限定 zhihu.com / v2ex.com）→ WebFetch
步骤：
1. WebSearch 搜索知乎、V2EX
- "[问题关键词] 痛点"
- "[现有方案] 不好用 / 替代品"
- "求推荐 [需求场景]"
2. WebFetch 读取高赞回答/帖子，提取用户原话
可选 Agent 3：ProductHunt / App Store（如果有对标产品）
WebSearch allowed_domains: ["producthunt.com"] 搜索同类产品评价
WebSearch 搜索 "[竞品名] app store reviews reddit"
输出格式
按痛点类别归类，每个类别下列出用户原声：
### 痛点归类
#### 类别 1：[痛点描述，如"现有工具配置太复杂"]
- 情绪强度：🔥🔥🔥（高）/ 🔥🔥（中）/ 🔥（低）
- 出现频次：X 条相关讨论
> "原话引用，保持用户的原始表达" — [来源](链接)，👍 XX
> "另一条原话引用" — [来源](链接)，👍 XX
#### 类别 2：[痛点描述]
- 情绪强度：🔥🔥
- 出现频次：X 条
> "原话引用" — [来源](链接)
### 未被满足的 Gap
- [用户明确提出但没人做的具体诉求]
### 需求温度判定
- ❄️ 冷门（几乎无讨论）
- 🌡️ 有热度（零散讨论，有人关注但不密集）
- 🔥 强需求（高频、高情绪强度、多平台出现）
情绪强度判定标准：看用词激烈程度（frustrated/hate/terrible = 高，annoying/wish = 中，would be nice = 低）、点赞/回复数、以及是否有人表示"愿意付费解决"。
关键判断
如果社区数据显示需求很冷，要诚实告诉用户。"没人讨论"本身就是重要信号——可能是需求不成立，也可能是细分市场还没被发现，但不管哪种情况用户都需要知道。
这一步结束时，你和用户应该对齐：需求是否被真实用户验证，最痛的点在哪里。
Step 5：PMF 建议——最小的切入点是什么？
目标：基于前面所有步骤的信息，给出最克制的 MVP 建议。
综合前面的发现，输出：
1. 切入点定义
- 一句话描述：为 [谁] 解决 [什么问题]，通过 [什么方式]
- 为什么选这个切入点（结合痛点数据和前提验证）
2. MVP 做什么、不做什么
- P0（必须有，没有就不成立的功能）：最多 3 个
- 明确排除的功能 + 排除理由
3. 验证策略
- 第一批用户从哪找？（结合 Step 4 的社区数据）
- 怎么判断 PMF 达成？给 1-2 个关键指标
- 最快的验证方式是什么？（landing page、waitlist、手动服务、prototype？）
4. 风险提示
- 这个方向最大的风险是什么？
- 什么信号出现了说明应该 pivot？
5. 下一步建议
- 如果需要深入了解竞争格局，建议使用
/founder-competitive-analysis 进行系统的竞品分析
- 如果需要做用户调研验证假设，建议使用
/founder-synthetic-research 进行合成用户访谈
- 如果需要制作融资材料，建议使用
/founder-pitch-deck 生成 pitch deck
原则
- 做减法，不是做加法。MVP 的目标是验证假设，不是做一个完整产品。
- 诚实。如果你觉得这个方向不太行，直接说，附上理由。
- 具体。"做一个 MVP" 不是建议，"用 Typeform 做一个 20 题的需求验证问卷，投放到 r/xxx 社区" 才是建议。
附录：中间材料
最终输出必须包含以下附录：
附录 A：阶段判断与路由
- 判定的产品阶段（A/B/C/D）
- 实际执行的步骤列表
附录 B：问题定义
- Step 1-3 的结构化输出（需求来源、核心问题、用户画像、核心场景）
- 每一步 founder 的确认记录
附录 C：前提挑战记录
- Step 3.5 列出的所有前提
- 每个前提的挑战结果和 founder 的回应
附录 D：痛点验证原始数据
- Reddit 搜索使用的查询（实际 query）
- 中文社区搜索使用的查询
- 原始搜索结果（帖子标题、链接、分数）
- 引用的用户原话完整列表
Escape Hatch
如果用户在任何步骤表现出不耐烦（"直接说结论"、"跳过这些问题"、"别问了直接做"）：
第一次：说明追问的价值，然后压缩剩余问题。
"这些问题就是价值——跳过它们等于跳过诊断直接开药。我再问两个关键的，然后给结论。"
从当前阶段的智能路由中选最关键的 2 个未完成步骤，快速完成后跳到 Step 5。
第二次：尊重用户，直接跳到 Step 5。
"明白。基于目前信息直接给建议。"
用已有信息生成 PMF 建议，但标注哪些结论是基于不充分信息做出的。
例外：如果用户提供了完整的方案（有真实用户、有收入数据、有具体客户名字），可以跳过诊断问题，但仍然执行 Step 3.5（前提挑战）和 Step 4（痛点验证）。
执行原则
- 对话优先：对话步骤是跟用户对话，不是你自己分析。每一步都要等用户确认后再往下。
- 数据驱动：Step 4 必须联网搜索真实数据，禁止编造。
- 并行采集：Step 4 的数据搜索通过并行 Agent 执行，提高效率。
- 诚实直接：发现问题直接说，不要为了不打击用户而回避真相。用推回模式，不用禁止用语。
- 来源标注：所有引用的社区讨论、数据必须附链接。
- 串联 f-founder：完成需求澄清后，自然引导 founder 使用 f-founder 的其他 skill 继续推进。
