mvp-first

name	mvp-first
version	2.0.0
description	Use when user requests complex systems involving multiple modules or subsystems - like "build a XX system", "design XX architecture", or "implement XX with multiple features". Triggers to prevent over-engineering before validating core assumptions.
category	planning
complexity	medium
typical_duration	30min
dependencies	[]
benefits-from	["goal-oriented","first-principles","ddd-strategic-design"]
conflicts-with	[]
output_artifact	memory/artifacts/mvp-first/
allowed-tools	["Read","Write","Bash","Grep","Glob"]
tags	["产品规划","功能筛选","MVP","敏捷开发"]

MVP First

前置协议

环境检测

PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || echo "unknown")
BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
COMMIT=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")

echo "PROJECT: $PROJECT_ROOT"
echo "BRANCH: $BRANCH"
echo "COMMIT: $COMMIT"

前置技能检查

# 检查前置工件
GOAL_ARTIFACT="memory/artifacts/goal-oriented/latest.json"
DDD_ARTIFACT="memory/artifacts/ddd-strategic/latest.json"

if [ -f "$GOAL_ARTIFACT" ]; then
  echo "FOUND: goal-oriented artifact"
fi

if [ -f "$DDD_ARTIFACT" ]; then
  echo "FOUND: ddd-strategic-design artifact"
fi

mkdir -p memory/artifacts/mvp-first

MVP First

Overview

MVP（Minimum Viable Product）不是"最小可用产品"，而是"最小可验证产品"。

核心目的：用最小成本验证关键假设，避免基于未经验证的假设投入大量资源。

MVP 的目标是学习，不是交付产品。每一次 MVP 都是在回答一个关键问题：用户真的需要这个吗？

When to Use

digraph when_to_use {
    rankdir=TB;
    node [shape=box, style=filled, color="#c8e6c9"];

    "用户提出新需求" [shape=ellipse, color="#bbdefb"];
    "功能是否复杂?" [shape=diamond, color="#fff9c4"];
    "是否验证过假设?" [shape=diamond, color="#fff9c4"];
    "直接实现" [color="#f8bbd0"];
    "应用 MVP 思维" [color="#c8e6c9"];

    "用户提出新需求" -> "功能是否复杂?";
    "功能是否复杂?" -> "直接实现" [label="否, 简单修改"];
    "功能是否复杂?" -> "是否验证过假设?" [label="是, 新系统"];
    "是否验证过假设?" -> "直接实现" [label="是"];
    "是否验证过假设?" -> "应用 MVP 思维" [label="否"];
}

触发场景：

• 用户说"我想做一个XX功能"、"帮我规划这个项目"
• 功能涉及多个子系统或复杂架构
• 用户未验证过需求假设

不适用场景：

• 简单的 bug 修复或配置修改
• 用户明确要求完整方案
• 已经验证过需求的项目迭代

The MVP Mindset

Core Questions (Must Ask Before Implementation)

在给出任何实现方案前，必须回答：

1. 核心假设是什么？

   • 用户真的需要这个功能吗？
   • 用户会使用这个功能吗？
   • 这个功能能解决用户的问题吗？

2. 最小验证成本是什么？

   • 如何用最少的时间和资源验证假设？
   • 能不能先手动做一遍？
   • 能不能用现成工具代替开发？

3. 验证成功的标准是什么？

   • 多少用户使用算成功？
   • 什么数据证明假设成立？
   • 多久能得到结论？

MVP is NOT

❌ MVP 不是"功能简化版"
   - "保留核心功能，砍掉次要功能" → 这是产品规划，不是 MVP
   - MVP 的目标不是交付产品，而是验证假设

❌ MVP 不是"上线最小可用版本"
   - "先上线再迭代" → 可能浪费数周开发用户不需要的功能
   - MVP 可以不上线，甚至不需要写代码

❌ MVP 不是"快速交付"
   - "1周上线" → 如果方向错误，1周也是浪费
   - MVP 的目标是学习方向，不是交付速度

The Process

digraph mvp_process {
    rankdir=TB;
    node [shape=box, style=filled];

    "识别假设" [color="#c8e6c9"];
    "定义验证目标" [color="#bbdefb"];
    "设计最小实验" [color="#fff9c4"];
    "实施并测量" [color="#f8bbd0"];
    "分析结果" [color="#e1bee7"];
    "假设成立?" [shape=diamond, color="#fff9c4"];
    "继续投入" [color="#c8e6c9"];
    "调整或放弃" [color="#f8bbd0"];

    "识别假设" -> "定义验证目标";
    "定义验证目标" -> "设计最小实验";
    "设计最小实验" -> "实施并测量";
    "实施并测量" -> "分析结果";
    "分析结果" -> "假设成立?";
    "假设成立?" -> "继续投入" [label="是"];
    "假设成立?" -> "调整或放弃" [label="否"];
    "继续投入" -> "识别假设" [label="下一步假设"];
    "调整或放弃" -> "识别假设" [label="新假设"];
}

Step 1: 识别关键假设

用户需求通常包含多个隐含假设，识别风险最高的那个。

示例：用户想要"评论系统"

• 假设1: 用户愿意在平台上发表评论
• 假设2: 用户关心其他人评论
• 假设3: 评论会增加用户粘性
• 假设4: 需要审核和过滤机制

风险最高的假设：假设1 - 如果用户根本不评论，其他假设都不成立。

Step 2: 定义验证目标

用数字定义成功标准。

示例：验证用户是否会评论

• 成功标准：1周内至少 50 位用户发表评论
• 验证周期：7 天
• 失败标准：< 10 位用户评论，或评论内容质量过低

Step 3: 设计最小实验

找到验证假设的最小成本方式。

常见 MVP 模式（按成本从低到高）：

模式	成本	适用场景	示例
手动服务	极低	验证需求是否存在	用 Google Form 收集评论需求，手动回复
着陆页	低	验证用户意愿	做一个"评论功能即将上线"页面，收集邮箱订阅
假门	低	验证用户兴趣	放一个"评论"按钮，点击后显示"功能开发中"
向导式	中	验证用户体验	人工在后台处理评论，前端看起来像真实功能
单功能	中	验证核心价值	只能发表评论 + 查看评论，无其他功能

Step 4: 实施并测量

只开发验证假设必需的功能。

代码示例：假门 MVP（验证用户是否想要评论功能）

<!-- 评论按钮 - 假门 MVP -->
<button id="comment-btn" class="btn-primary">
  发表评论
</button>

<div id="feedback-modal" style="display:none;">
  <p>评论功能正在开发中！</p>
  <p>留下您的邮箱，功能上线第一时间通知您：</p>
  <input type="email" id="user-email" placeholder="[e-mail]">
  <button onclick="submitEmail()">提交</button>
</div>

<script>
document.getElementById('comment-btn').addEventListener('click', function() {
  // 记录点击次数 - 这是最重要的数据
  trackEvent('comment_button_clicked');

  // 显示收集邮箱的模态框
  document.getElementById('feedback-modal').style.display = 'block';
});

function submitEmail() {
  const email = document.getElementById('user-email').value;
  // 发送到后端记录
  saveEmail(email);
  alert('感谢您的关注！');
}
</script>

成本: 30 分钟开发 + 1 周观察 学习: 点击率 > 5% → 用户真的想要评论功能

Step 5: 分析并决策

基于数据而非直觉做决策。

三种结果：

• 假设成立（数据达标）→ 继续投入下一层功能
• 假设失败（数据不达标）→ 放弃或调整方向
• 数据不足 → 延长验证周期或改进实验设计

MVP Layers（分层验证）

不要一次开发完整系统，按层次逐步验证：

【示例：评论系统的 MVP 分层】

Layer 0: 验证需求是否存在
- 方式：假门按钮（点击后显示"功能开发中"）
- 成本：30 分钟
- 目标：点击率 > 5%

Layer 1: 验证用户会使用功能
- 方式：只能发表评论 + 显示评论（无审核、无过滤、无回复）
- 成本：1 天开发
- 目标：1 周内 50+ 用户发表评论

Layer 2: 验证用户需要内容质量控制
- 方式：加审核功能（发现垃圾评论时再加）
- 成本：1 天开发
- 目标：审核通过率 > 80%

Layer 3: 验证用户需要互动
- 方式：加点赞功能（观察用户是否想要互动）
- 成本：0.5 天开发
- 目标：点赞率 > 10%

Layer 4: 验证用户需要复杂互动
- 方式：加回复功能（观察单层评论是否不够）
- 成本：1 天开发
- 目标：评论中 @他人 的比例 > 5%

关键原则：每一层都是独立的 MVP，验证一个假设后才进入下一层。

Common Mistakes

1. ❌ "保留核心功能" 不是 MVP

用户需求：评论系统（评论、回复、点赞、审核、过滤）

❌ 错误的 MVP 思维：
"保留核心功能：评论、回复、点赞、审核、敏感词过滤"
→ 这仍然是完整系统，只是去掉了积分等次要功能
→ 开发成本：1 周

✅ 正确的 MVP 思维：
"Layer 0: 假门按钮，验证用户是否想要评论功能"
→ 成本：30 分钟
→ 如果点击率 < 5%，直接省下 1 周开发时间

2. ❌ "上线后再迭代" 不是 MVP

用户需求：用户等级系统

❌ 错误的 MVP 思维：
"先上线基础等级系统（5个等级、积分规则、权限控制），后续再加徽章、排行榜"
→ 开发成本：3 天
→ 问题：可能用户根本不在乎等级

✅ 正确的 MVP 思维：
"做一个静态的等级显示（根据注册时间显示等级），观察用户是否在意等级"
→ 成本：2 小时
→ 学习：查看个人主页的用户中，看等级信息的比例 > 30% → 继续投入

3. ❌ MVP 必须是代码

用户需求：积分商城

❌ 错误的 MVP 思维：
"开发一个简单的商城页面，用户可以用积分兑换虚拟商品"
→ 成本：2 天开发

✅ 正确的 MVP 思维：
"在社区发帖：'积分兑换功能即将上线，大家希望兑换什么？' 收集 50+ 回复"
→ 成本：30 分钟
→ 学习：如果没人回复，说明积分商城不是刚需

4. ❌ MVP 可以拖延上线

用户需求：个性化推荐

❌ 错误的 MVP 思维：
"开发一个简单的推荐算法（协同过滤），下周上线验证效果"
→ 问题：如果推荐效果差，不知道是算法问题还是用户不需要

✅ 正确的 MVP 思维：
"在热门内容列表中随机插入 1 条'编辑推荐'，观察点击率"
→ 成本：1 小时
→ 学习：编辑推荐的点击率 > 随机内容的 2 倍 → 说明用户需要推荐
→ 下一步：开发真正的推荐算法

Handling User Pushback

用户常常会用各种理由反对 MVP 方法。以下是常见反对意见及说服技巧：

反对意见 1: "竞争对手已经有完整功能了"

用户的担忧：市场竞争压力，怕用户流失

说服策略：

✅ 用数据说话：

"我理解你的压力。但正因为需要快速上线，MVP 更重要：

**时间现实分析：**
- 完整功能：8个模块 × 3-5天 = 24-40天
- MVP：4.5天
- 延期风险：完整功能 100% 延期 3-4周 → 用户流失更严重

**市场风险对比：**
- 方案A（完整功能延期）：上线延迟 3-4周 → 竞争对手领先更久
- 方案B（MVP快速上线）：下周有功能 → 立即获得用户反馈，快速迭代追赶

**建议**：先用 MVP 上线核心功能，获得市场反馈，再快速迭代。"

反对意见 2: "下周就要上线，没时间做实验"

用户的担忧：时间紧迫，认为 MVP 会拖延

说服策略：

✅ 重构时间认知：

"**MVP 不是拖延，而是加速：**

传统方式：开发 2 周 → 测试 1 周 → 上线发现用户不需要 → 浪费 3 周
MVP 方式：实验 3 天 → 验证失败 → 立即转向 → 节省 2.5 周

**关键**：如果方向错了，开发再快也是浪费。MVP 帮你在 3 天内发现方向错误，而不是 3 周。

**建议**：用 30 分钟做 Layer 0（假门），如果点击率 < 5%，直接省下 1 周开发时间。"

反对意见 3: "用户肯定会需要这个功能"

用户的担忧：相信自己的判断，认为验证是浪费时间

说服策略：

✅ 引用数据/案例：

"**数据显示，70% 的功能用户并不需要：**

- 某社交平台开发私信功能（2周），上线后使用率 < 1%
- 如果先用假门测试（30分钟），能省下 2 周时间

**问题**：你觉得用户需要，但：
- 用户真的会使用吗？
- 使用频率有多高？
- 用户愿意付出什么代价？

**建议**：用半天时间验证假设，成本极低，但能避免数周浪费。"

反对意见 4: "给我就完整方案，我自己决定"

用户的担忧：觉得 agent 在说教，想要自主权

说服策略：

✅ 提供选择，而不是说教：

"好的，我可以给你两个方案：

**方案A（MVP）**：
- Layer 0：假门按钮（30分钟）
- Layer 1：基础评论（1天）
- 总成本：1.5天
- 风险：极低，随时可以停止

**方案B（完整功能）**：
- 数据库设计：7张表
- 接口开发：15个接口
- 功能开发：8个模块
- 总成本：4-6周
- 风险：高，可能开发用户不需要的功能

我建议方案A，但最终由你决定。你希望我先提供哪个方案的详细设计？"

反对意见 5: "MVP 太简陋，用户体验会很差"

用户的担忧：担心 MVP 影响品牌形象

说服策略：

✅ 区分"简陋"和"聚焦"：

"**MVP 不是粗制滥造，而是功能聚焦：**

❌ 粗糙的 MVP：Bug 多、界面丑、性能差
✅ 正确的 MVP：功能少、但质量高、体验好

**案例**：
- Dropbox MVP：只是一个演示视频，没有真实产品
- 结果：7万人排队等候，验证了需求
- 成本：3 天制作视频

**建议**：做一个小但精致的 MVP，核心功能打磨到位，比大而粗糙的产品更有价值。"

说服技巧总结

技巧	说明	示例
用数据说话	展示时间成本对比	"完整功能 4-6周，MVP 1.5天"
重构认知	MVP 是加速，不是拖延	"3天发现错误 vs 3周发现错误"
引用案例	真实失败案例	"70%的功能用户不需要"
提供选择	让用户感到自主	"给你两个方案，你来决定"
区分概念	MVP ≠ 粗糙	"小而精致 vs 大而粗糙"

核心原则：理解用户的真实担忧（竞争压力、时间压力、品牌形象），用数据和逻辑说服，而不是说教。

常见理性化借口识别表

当用户用以下理由拒绝 MVP 时，识别背后的思维模式：

用户说	背后的理性化	本质问题	MVP 应对方法
"这个功能很简单"	低估复杂度	未考虑子系统、边界情况	列出所有子系统（数据库、接口、前端、测试），展示真实成本
"竞品都有了"	FOMO（错失恐惧）	模仿 ≠ 验证	竞品的用户和我们的用户一样吗？先验证我们的用户是否需要
"用户肯定需要"	假设替代数据	直觉 ≠ 事实	设计最小实验（半天成本），用数据说话
"时间很紧迫"	紧迫感掩盖风险	快 ≠ 对	MVP 是加速不是拖延：3天发现错误 vs 3周发现错误
"先上线再迭代"	推迟验证	上线 ≠ 验证	如果方向错，上线就是浪费。先用假门验证方向
"我知道用户想要"	过度自信	幸存者偏差	你问的是活跃用户，那沉默的用户呢？用假门测试所有人
"这只是个小功能"	忽视累积成本	小功能 × N = 大系统	小功能也需要验证。用静态实现测试用户是否真的会点
"我们已经规划好了"	沉没成本谬误	规划成本高 ≠ 必须实现	规划是假设，不是事实。用最小成本验证假设

使用方法：

1. 识别用户的理性化类型（看表格第2列）
2. 理解本质问题（第3列）
3. 应用对应的应对方法（第4列）
4. 用数据和逻辑说服，而不是情绪化争论

Real-World Impact

案例：某社交平台要开发"私信功能"

传统方式（无 MVP 思维）：

• 开发成本：2 周（消息存储、实时推送、已读状态、消息列表、发送界面）
• 上线后：日活用户中使用率 < 1%
• 浪费：2 周开发时间 + 服务器资源

MVP 方式：

• Layer 0（假门）：在个人主页放一个"私信"按钮，点击后显示"功能开发中"（成本：30 分钟）
• 观察 3 天：点击率 0.3% → 放弃开发
• 节省：2 周开发时间

结果对比：

指标	传统方式	MVP 方式
开发成本	2 周	30 分钟
学习周期	2 周 + 1 周	3 天
资源浪费	高	极低

Quick Reference

用户说...	MVP 思维回应
"我想做一个XX功能"	"先做个假门，看用户是否真的想要"
"这个功能很着急"	"最快的验证方式是：先做个最简单版本，验证方向对不对"
"先实现核心功能"	"核心功能也是假设。哪个假设风险最高？先验证那个"
"用户肯定需要"	"用数据验证。设计一个最小实验，成本不超过半天"
"竞品都有这个功能"	"竞品的用户和我们的用户一样吗？先验证我们的用户是否需要"

Red Flags - You're NOT Doing MVP

• 你在"砍功能"，但没有问"最核心的假设是什么"
• 你的 MVP 需要 > 2 天开发时间
• 你在规划数据库表结构，而不是规划验证实验
• 你在说"先上线再迭代"，而不是"先验证再投入"
• 你的 MVP 包含审核、过滤、权限等"基础设施"
• 你没有定义验证成功的数字标准

看到这些信号 → 停下来，重新思考：我在验证什么假设？

References

• The Lean Startup - Eric Ries（MVP 概念起源）
• Running Lean - Ash Maurya（MVP 实战方法）
• The Mom Test - Rob Fitzpatrick（如何验证需求）

后置协议

工件输出

保存 MVP 规划结果到工件文件：

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
ARTIFACT_FILE="memory/artifacts/mvp-first/result-$TIMESTAMP.json"

cat > "$ARTIFACT_FILE" <<EOFJSON
{
  "skill": "mvp-first",
  "version": "2.0.0",
  "timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
  "project": "$PROJECT_ROOT",
  "branch": "$BRANCH",
  "commit": "$COMMIT",
  "input": {
    "user_request": "用户的原始请求"
  },
  "output": {
    "mvp_features": [],
    "non_mvp_features": [],
    "mvp_timeline": "",
    "key_assumptions": [],
    "validation_metrics": []
  },
  "next_skills": [
    "pdca-cycle"
  ]
}
EOFJSON

echo "ARTIFACT SAVED: $ARTIFACT_FILE"
ln -sf "$ARTIFACT_FILE" memory/artifacts/mvp-first/latest.json

目标文件更新

如果存在目标文件，记录 MVP 规划完成。

建议后续技能

## 后续建议

基于 MVP 规划结果，建议继续执行：

**推荐技能链**：
1. /pdca-cycle - 进入 PDCA 循环实施阶段

是否继续执行？
- A) 执行推荐的技能链
- B) 不继续，结束当前任务