ln-201-opportunity-discoverer

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

机会发现器

类型： L3 Worker
类别： 2XX 规划

以流量优先的方式，为现有产品寻找下一个增长方向。

核心理念

反模式： 想法 → 调查 → 产品 → “流量在哪？” 正确做法： 流量 → 细分市场 → MVP → 面向现有需求发布

90% 开发者的常见错误

大多数人失败的原因是：

1. 凭空想出一个没有同类产品的点子
2. 问 5 个人“你愿意付费吗？”（他们连热狗都会说愿意买）
3. 花一大笔钱打造产品
4. 发布时才想“现在来搞流量吧”
5. 结果发现：根本没有流量，以前也从来没有

对于冷流量根本不会购买的产品，没有营销人员会为它构建转化漏斗。

流量优先原则

#	原则	反模式
1	先有流量，再有产品	先开发，再寻找流量
2	不做调查——衡量真实搜索需求	询问“你愿意买吗？”
3	利用现有需求——围绕人们正在搜索的内容发布	创建新品类
4	一个渠道，一个想法——不要分散精力	同时测试 5 个渠道
5	尽早淘汰——快速失败，不要浪费时间	平等评估所有想法

配套方法论

Marc Andreessen（pmarca）：

“从实践层面验证市场——找到愿意付费的客户，证明市场确实存在。”

Sam Altman（YC）：

“谁迫切需要这个产品？最好的答案是，瞄准一个小市场中的很大一部分。” “通过发布或尝试销售来测试想法——写代码之前先拿到意向书。”

---

目的与范围

• 在创建 Epic 之前发现增长方向
• 通过证据优先的淘汰漏斗筛选想法
• 输出：一个推荐想法 + 一个流量渠道
• 定位：位于 ln-210（Epic Coordinator）之前

运行时契约

必须阅读： 加载 references/planning_worker_runtime_contract.md、references/coordinator_summary_contract.md

运行时系列：planning-worker-runtime

标识符：

• 发现工作项标识符

阶段：

1. PHASE_0_CONFIG
2. PHASE_1_INPUT_PROCESSING
3. PHASE_2_KILL_FUNNEL
4. PHASE_3_RANK_SURVIVORS
5. PHASE_4_WRITE_DISCOVERY_REPORT
6. PHASE_5_WRITE_SUMMARY
7. PHASE_6_SELF_CHECK

摘要契约：

• summary_kind=opportunity-discovery-worker
• 独立模式可以返回摘要，而不持久化产物
• 托管模式会将相同的 JSON 写入 summaryArtifactPath
• 默认托管产物路径模式：.hex-skills/runtime-artifacts/runs/{parent_run_id}/opportunity-discovery-worker/ln-201--{identifier}.json

适用场景

在以下情况下使用此技能：

• 产品已存在，正在寻找下一个增长方向
• 有 3-10 个潜在想法或细分市场
• 希望在投入之前验证机会
• 需要选择一个要专注的渠道

以下情况请勿使用：

• 没有产品背景（从零开始的创业项目）
• 已有经过验证的方向（跳转至 ln-210）
• 为现有 Story 排定优先级（使用 ln-230）

---

输入参数

参数	必填	描述	默认值
ideas	否	以逗号分隔的列表	-
context	否	用于生成想法的产品描述	-
strict	否	严格的 KILL 阈值	true

输入模式：

• ideas="idea1, idea2, idea3" — 评估列表
• context="SaaS for X" — 根据产品生成想法
• 两者兼用 — 生成想法并加入用户提供的想法

---

KILL 漏斗流程

想法不再经过 4 轮独立且耗费大量调研的筛选。每个想法会先进行一次整合式证据核查。

Idea → [Evidence bundle: traffic + demand + competition + revenue]
          ↓
      [Hard kill matrix]
          ↓
     [Interest gate]
          ↓
      [MVP gate]
          ↓
       SURVIVOR

证据包（单轮调研）

问题： 外部证据是否足以支持深入评估？

调研资料包：

WebSearch: "[idea] how people find solutions"
WebSearch: "[idea] search volume {current_year}"
WebSearch: "[idea] competitors {current_year}"
WebSearch: "[idea] pricing SaaS"

一轮提取四项信号：

• 流量渠道： 人们会主动通过哪里寻找这类解决方案？
• 需求： 搜索量、趋势方向或强烈的社群痛点信号
• 竞争： 竞争对手数量和市场类型
• 收入： 合理的价格区间和付费意愿模式

流量渠道示例：

渠道	信号	最适合
搜索/SEO	人们在 Google 上搜索“[问题] 解决方案”	信息产品、工具
YouTube	存在教程搜索	教育、操作指南
市场平台	存在对应类别（ProductHunt、AppStore）	应用、插件
社群	活跃的 subreddit、论坛	小众产品
付费广告	竞争对手正在投放广告	已验证的需求
主动拓客	ICP 明确且容易触达	B2B 高客单价

需求阈值：

搜索量	结论
>10K/月	需求强劲
1K-10K/月	可行的小众市场
<1K/月	需求较弱，除非有非常强的小众市场信号作为补偿

竞争阈值：

竞争对手	指数	市场类型	结论
0	1	蓝海	如果需求真实，则存在机会
1-2	2	新兴	最佳切入点
3-5	3	成长中	需要差异化
6-10	4	成熟	困难但可行
>10	5	红海	通常应淘汰

收入阈值：

ARPU	市场类型	可行性
>$100/用户/月	企业级	利润率高
$50-100	专业人士	良好
$20-50	专业消费者	可行
$5-20	消费者	需要较大销量
<$5	广告支持	通常不值得做

硬性淘汰矩阵

出现任何硬性停止条件时，立即淘汰：

• 没有可识别的流量渠道
• 需求明显低于可行阈值，且没有可弥补的小众市场信号
• 竞争指数 = 5，且没有明确的切入点
• 小团队业务的预期收入低于 $20/用户

记录淘汰原因，并停止分析该创意。

个人兴趣

问题： 你会享受构建这个产品的过程吗？

方法： AskUserQuestion — 评分 1-5

Rate your interest in building [idea]:
1 = Meh, would do for money only
2 = Low interest
3 = Neutral
4 = Interested
5 = Excited, would build for free

重要原因：

• 兴趣低 = 3 个月后倦怠
• 兴趣高 = 在艰难时期也能保持动力
• 你会为此投入 2 年以上

何时询问： 仅针对通过外部证据包筛选的创意。

淘汰条件： 评分 1-2——你会在达到 PMF 前放弃。

输出： 评分 1-5

---

MVP 可行性

问题： 你能在 4 周内发布吗？

评估：

因素	问题	警示信号
技术	是否具备现有技能，还是需要学习？	新技术栈
依赖	是否需要外部 API 或合作伙伴？	需要等待他人
内容	是否需要大量创作内容？	需要数月写作
监管	是否有法律/合规要求？	许可证、审批
团队	能否独立完成，还是需要招聘？	无法独自开始

时间估算：

周数	复杂度	结论
1-2	独自完成，具备现有技能	最佳
2-4	只需少量学习	良好
4-8	需要掌握一些新技术	可接受
>8	需要大量基础设施	淘汰

何时评估： 仅针对通过外部证据和兴趣门槛筛选的创意。

淘汰条件： MVP 需要超过 8 周——验证速度太慢。

输出： 周数估算 + 阻碍因素

---

工作流

阶段 1：输入处理（2 分钟）

1. 解析输入：

   • 如果是 ideas：拆分逗号分隔的列表
   • 如果是 context：通过 WebSearch 生成 5-7 个创意
   • 如果两者都有：合并

2. 验证数量：

   • 最少：3 个创意
   • 最多：10 个创意

3. 创建输出目录：

   mkdir -p docs/reference/research/
   

输出： 创意队列（3-10 项）和 PHASE_1_INPUT_PROCESSING 检查点

---

阶段 2：KILL 漏斗（逐个创意）

先为每个创意进行一轮打包证据收集，再仅对存活创意应用个人筛选：

FOR each idea:
    Build evidence bundle:
        traffic + demand + competition + revenue

    Apply hard kill matrix
        IF failed → KILL, log reason, NEXT idea

    Ask Interest
        IF score 1-2 → KILL, log reason, NEXT idea

    Assess MVP-ability
        IF >8 weeks → KILL, log reason, NEXT idea

    → SURVIVOR: add to survivors list

Token 效率：

• 一次处理一个创意
• 每个创意进行一轮研究，而非分成四个独立研究阶段
• 尽早 KILL = 不询问兴趣，不评估 MVP
• 每个创意处理完后清空上下文

---

阶段 3：为存活创意排序（2 分钟）

如果有存活创意：

1. 计算综合得分：

   Score = Demand_score + (6 - Competition_index) + Revenue_score + Interest + MVP_score
   

2. 按得分降序排列

3. 选出 TOP 推荐

如果没有存活创意：

• 报告：“所有创意均已淘汰。重新考虑方向。”
• 显示 KILL 日志以供学习

---

阶段 4：输出（2 分钟）

生成： docs/reference/research/[YYYY-MM-DD]-discovery.md

同时输出结构化运行时摘要：

• schema_version
• summary_kind=opportunity-discovery-worker
• run_id
• identifier
• producer_skill=ln-201
• produced_at
• 包含 input_mode、ideas_analyzed、generated_ideas、survivors_count、killed_count、top_recommendation、report_path、warnings 的 payload

结构：

# Opportunity Discovery: [Date]

## Summary
- Ideas analyzed: X
- Survivors: Y
- Killed: Z

## TOP RECOMMENDATION

**Idea:** [Name]
**Channel:** [Primary channel]
**Why:** [2-3 sentence rationale]

### Key metrics:
- Demand: [volume]/month
- Competition: [Index] [Ocean type]
- Revenue: $[X]/user
- MVP: [X] weeks

## Survivors Table

| Idea | Channel | Demand | Competition | Revenue | Interest | MVP | Score |
|------|---------|--------|-------------|---------|----------|-----|-------|
| ... | ... | ... | ... | ... | ... | ... | ... |

## KILL Log

| Idea | Killed at | Reason |
|------|-----------|--------|
| ... | ... | ... |

## Next Steps
1. Create Epic with ln-210 for top recommendation
2. Focus on [channel] as primary acquisition
3. Target MVP in [X] weeks

---

时间限制

创意数量	预计时间
3	15-20 分钟
5	25-35 分钟
10	50-70 分钟

注意： KILL 漏斗比完整评分更快——糟糕的创意会被尽早淘汰。

---

集成

在工作流中的位置：

Product exists
     ↓
ln-201 (Opportunity Discovery) ← THIS SKILL
     ↓
ln-210 (Epic Coordinator)
     ↓
ln-220 (Story Coordinator)

依赖项：

• WebSearch（除兴趣筛选外的所有筛选）
• AskUserQuestion（兴趣筛选）
• Write、Bash（输出）

---

关键规则

1. 流量优先——没有流量渠道就不进行分析
2. 一次性打包证据——如果一轮研究就能回答流量、需求、竞争和收入问题，就不要分开执行多个研究密集型阶段
3. 立即 KILL——不要为已淘汰的创意评分
4. 只给一个推荐——避免陷入犹豫
5. 不做调查问卷——只使用真实搜索数据
6. 兴趣很重要——仅向具备外部可行性的创意询问兴趣
7. MVP 速度——发布慢，学习就慢

---

使用示例

提供创意：

ln-201-opportunity-discoverer ideas="AI writing tool, code review bot, translation API"

提供背景信息：

ln-201-opportunity-discoverer context="B2B developer tools SaaS"

输出示例：

# Opportunity Discovery: 2026-01-29

## TOP RECOMMENDATION

**Idea:** Code review bot
**Channel:** SEO (developers search "code review tool")
**Why:** Growing demand (15K/mo), emerging market (3 competitors),
$50/user pricing proven, can MVP in 3 weeks with existing skills.

## KILL Log

| Idea | Killed at | Reason |
|------|-----------|--------|
| AI writing | Competition | Red Ocean (25+ competitors) |
| Translation API | Revenue | Commoditized, <$10/user |

---

完成定义

• 根据产品背景和市场信号进行创意头脑风暴
• 在做出淘汰决定前，为每个创意收集证据包
• 在进行兴趣和 MVP 检查前应用硬性淘汰矩阵
• 为存活创意评分并排序
• 在 docs/reference/research/[YYYY-MM-DD]-discovery.md 生成探索文档
• 确定 TOP RECOMMENDATION，并注明渠道和依据
• KILL 日志记录所有已淘汰创意及淘汰原因
• 返回结构化的 opportunity-discovery-worker 摘要
• 提供 summaryArtifactPath 时写入摘要工件

参考文件

文件	用途
filter_criteria.md	所有筛选条件的 KILL 阈值
channel_analysis.md	流量渠道识别
discovery_template.md	输出 Markdown 模板

• 必须阅读： 加载 references/research_tool_fallback.md

---

版本： 2.0.0 最后更新： 2026-01-29