第03章产品定义：LLM应用的最小可行产品设计

“完美是优秀的敌人。MVP不是劣质产品，是对核心价值最简洁的表达。” —— Reid Hoffman

验证了需求，现在该定义产品了。对工程师来说，这一步最容易犯的错误是：把MVP做成了完整产品的缩水版，而不是核心价值的最小实现。

本章帮你用正确的方式定义你的LLM应用MVP。

3.1 Job-to-be-Done：用户真正在雇佣什么

# 著名的"奶昔研究"背后的产品逻辑
# 麦当劳研究奶昔销量时发现：
# 早晨购买奶昔的顾客不是想要甜食
# 他们"雇佣"奶昔来完成一个工作：
# "在开车上班时打发无聊，同时代替早餐"

# 对LLM应用同样适用：

JTBD_FRAMEWORK = {
    "表面需求（用户说的）": "我需要一个AI助手帮我写邮件",
    "真实工作（JTBD）": "让我从繁琐的邮件撰写中解放出来，把时间花在更重要的事上",
    "功能需求（怎么做）": "自动生成邮件草稿，需要我只做最终确认",
    "情感需求（感受什么）": "不再为邮件焦虑，感到高效和专业",
    "社会需求（显示什么）": "发出去的邮件让收件人觉得我很专业",
}

def identify_jtbd(product_idea: str, interviews: list[dict]) -> dict:
    """
    从访谈数据中提取用户的真实Job
    """
    # 分析三类关键语句
    functional_jobs = []
    emotional_jobs = []
    social_jobs = []
    
    for interview in interviews:
        for quote in interview.get("quotes", []):
            if any(word in quote for word in ["节省时间", "自动化", "不需要手动"]):
                functional_jobs.append(quote)
            elif any(word in quote for word in ["烦", "压力", "担心", "焦虑"]):
                emotional_jobs.append(quote)
            elif any(word in quote for word in ["看起来", "专业", "老板", "团队觉得"]):
                social_jobs.append(quote)
    
    return {
        "功能性工作（效率/任务完成）": functional_jobs,
        "情感性工作（消除焦虑/提升满足感）": emotional_jobs,
        "社会性工作（印象管理/认可）": social_jobs,
    }

关键问题：当你的LLM应用真正工作时，用户的哪个"工作"被完成了？

3.2 核心功能取舍：只做一件事

# 功能优先级矩阵

from enum import Enum

class Priority(Enum):
    MUST_HAVE = "必须有（核心价值）"
    SHOULD_HAVE = "应该有（体验加分）"
    NICE_TO_HAVE = "锦上添花（v2再做）"
    WONT_HAVE = "不做（永远放弃）"

def prioritize_features(features: list[dict]) -> dict:
    """
    使用 MoSCoW 优先级方法筛选MVP功能
    
    判断标准：
    - MUST_HAVE: 没有这个功能，产品无法使用/无法创造核心价值
    - SHOULD_HAVE: 没有这个功能，用户体验明显下降，但产品仍然可用
    - NICE_TO_HAVE: 用户提到过，但不影响核心决策
    - WONT_HAVE: 很酷但不在核心路径上
    """
    categorized = {p: [] for p in Priority}
    
    for feature in features:
        name = feature["name"]
        
        # 判断标准
        is_core = feature.get("without_it_product_fails", False)
        user_requested_count = feature.get("user_requested_count", 0)
        is_technical_foundation = feature.get("is_technical_foundation", False)
        
        if is_core or is_technical_foundation:
            categorized[Priority.MUST_HAVE].append(name)
        elif user_requested_count >= 5:
            categorized[Priority.SHOULD_HAVE].append(name)
        elif user_requested_count >= 2:
            categorized[Priority.NICE_TO_HAVE].append(name)
        else:
            categorized[Priority.WONT_HAVE].append(name)
    
    return {p.value: features for p, features in categorized.items()}

# 一个合同审查AI的功能优先级示例
CONTRACT_REVIEW_FEATURES = [
    {"name": "上传PDF合同", "without_it_product_fails": True, "user_requested_count": 20},
    {"name": "识别风险条款", "without_it_product_fails": True, "user_requested_count": 20},
    {"name": "生成审查报告", "without_it_product_fails": True, "user_requested_count": 18},
    {"name": "标注具体位置（第X页第Y条）", "user_requested_count": 12, "is_technical_foundation": False},
    {"name": "合同对比功能（与标准合同比较）", "user_requested_count": 7},
    {"name": "法条引用", "user_requested_count": 5},
    {"name": "团队协作/评论", "user_requested_count": 3},
    {"name": "合同模板库", "user_requested_count": 2},
    {"name": "手机App", "user_requested_count": 1},
    {"name": "合同签署功能（如DocuSign）", "user_requested_count": 1},
]

result = prioritize_features(CONTRACT_REVIEW_FEATURES)
for priority, features in result.items():
    if features:
        print(f"\n{priority}:")
        for f in features:
            print(f"  - {f}")

3.3 用户旅程：从痛点到Aha Moment

LLM应用的用户旅程关键节点：

1. 发现（Discovery）
   └── 用户第一次听说你的产品
   └── 关键问题：他们在哪里发现你？什么触发了点击？

2. 注册（Sign-up）
   └── 关键问题：注册流程有多长？需要信用卡吗？
   └── 黄金法则：注册到首次使用 < 2分钟

3. ⭐ Aha Moment（第一次感受到价值）
   └── 这是最关键的节点！
   └── 用户第一次说"哦，这真的有用！"的那一刻
   └── 对于合同审查AI：上传合同后30秒内看到第一个风险条款

4. 习惯养成（Habit）
   └── 用户开始在日常工作流中使用你的产品
   └── 关键问题：用户每天/每周会用几次？

5. 付费（Conversion）
   └── 从免费试用到付费
   └── 关键问题：是什么触发了付费决策？

6. 留存（Retention）
   └── 用户持续使用，续订
   └── 关键问题：用户用了3个月后，还会用吗？为什么？

# Aha Moment设计原则

def design_aha_moment(product: dict) -> dict:
    """
    设计你产品的Aha Moment
    
    原则：
    1. 越快越好（< 60秒）
    2. 具体而可见（不是"分析完成"，是"发现了3个高风险条款"）
    3. 超出预期（给用户一个惊喜，而不只是"满足预期"）
    """
    return {
        "触发动作": product["first_action"],
        "等待时间": "< 30秒",
        "结果呈现": product["compelling_result"],
        "情感设计": "结果要让用户想截图/分享",
    }

# 合同审查AI的Aha Moment设计
aha_design = design_aha_moment({
    "first_action": "拖拽PDF到页面",
    "compelling_result": """
    ⚠️ 发现3个高风险条款：
    
    1. 第5页第2条：违约赔偿金无上限 → 建议添加赔偿上限条款
    2. 第8页第4条：自动续约且没有30天通知要求 → 建议修改通知期
    3. 第12页第1条：管辖法院条款对你不利 → 建议协商改为仲裁
    
    [查看完整报告]  [导出PDF]
    """,
})

3.4 AI交互设计：不要让用户感到被AI控制

# LLM应用的6个交互设计原则

LLM_UX_PRINCIPLES = {
    "原则1：设置合理的期望": {
        "问题": "AI有时会输出错误信息，用户一旦发现会立刻失去信任",
        "解决": [
            "明确说明'AI生成，请审核'",
            "对于关键信息，加上置信度或来源引用",
            "区分AI生成的内容和数据库事实",
        ],
    },
    
    "原则2：进度可见": {
        "问题": "LLM处理需要几秒甚至几十秒，空白等待让用户焦虑",
        "解决": [
            "流式输出（streaming）：让文字一个一个出现",
            "状态提示：'正在分析第3/15页...'",
            "进度条 + 预计剩余时间",
        ],
    },
    
    "原则3：让用户在回路中": {
        "问题": "用户不信任黑盒操作",
        "解决": [
            "AI生成后让用户编辑修改",
            "提供'重新生成'按钮",
            "显示AI的推理过程（可折叠）",
        ],
    },
    
    "原则4：失败要优雅": {
        "问题": "AI会返回无关内容或格式错误",
        "解决": [
            "兜底提示：'无法分析这部分，可能是格式问题，请手动检查'",
            "提供反馈按钮（用于收集训练数据）",
        ],
    },
    
    "原则5：输出格式化": {
        "问题": "纯文本墙让用户抓不到重点",
        "解决": [
            "结构化输出（列表、表格、风险等级标签）",
            "关键信息高亮（用颜色/icon区分严重程度）",
            "支持导出（PDF/Markdown）",
        ],
    },
    
    "原则6：成本控制透明化": {
        "问题": "用户不清楚一次操作消耗多少",
        "解决": [
            "显示剩余配额（'本月剩余20次分析'）",
            "在操作前告知预计消耗",
        ],
    },
}

3.5 MVP范围最终确认

# MVP画布（一页纸定义你的MVP）

class MVPCanvas:
    def __init__(self):
        self.canvas = {}
    
    def fill(
        self,
        problem: str,           # 一句话描述核心问题
        target_user: str,       # 具体用户（职位+公司规模）
        unique_value: str,      # 你与竞争对手的差异
        solution: str,          # 核心解决方案（一句话）
        key_features: list[str], # MVP的3个核心功能（不超过3个！）
        success_metric: str,     # 如何判断MVP成功
        timeline: str,          # 构建周期
    ):
        self.canvas = {
            "问题": problem,
            "目标用户": target_user,
            "独特价值": unique_value,
            "解决方案": solution,
            "核心功能（最多3个）": key_features[:3],
            "成功标准": success_metric,
            "构建周期": timeline,
        }
        return self
    
    def print_canvas(self):
        print("=" * 50)
        print("MVP 画布")
        print("=" * 50)
        for key, value in self.canvas.items():
            if isinstance(value, list):
                print(f"\n{key}:")
                for i, item in enumerate(value, 1):
                    print(f"  {i}. {item}")
            else:
                print(f"\n{key}: {value}")
        print("=" * 50)

# 示例
canvas = MVPCanvas().fill(
    problem="小律所律师每次审合同需要2-4小时，压力大且容易漏掉细节",
    target_user="独立律师事务所的初级律师，1-20人规模事务所",
    unique_value="专注中国劳动合同，识别准确率比通用AI高30%",
    solution="上传合同PDF，60秒内生成结构化风险报告",
    key_features=[
        "PDF上传 + 文字提取（支持扫描件OCR）",
        "风险条款识别 + 风险等级标注（高/中/低）",
        "一键导出PDF报告（带律师事务所Logo）",
    ],
    success_metric="2周内10个律师完成试用，3个愿意付费$299/月",
    timeline="3周（1周基础功能，1周UI打磨，1周内测）",
)
canvas.print_canvas()

本章小结

五个核心认知：

JTBD比功能列表更重要：用户雇佣你的产品完成一个工作，不是一组功能；理解真正的"工作"才能做出用户离不开的产品
MVP只做3件事：必须有的功能最多3个；去掉所有"锦上添花"，只留下"没有就死"的功能；其余的都是v2+的事
Aha Moment决定留存：用户在60秒内必须看到明确的价值；Aha Moment没有发生，再好的功能也白费
AI交互设计有独特挑战：期望管理、进度可见、人在回路——LLM的不确定性需要UI设计来弥补，让用户感到被控制而不是被AI控制
MVP画布一页纸说清楚：问题、用户、差异化、3个功能、成功标准、周期——说不清楚的产品，写再多代码也没用

核心行动：

# 今天就填写你的MVP画布
# 把3个核心功能写在便利贴上，贴在你的显示器旁边
# 每次想加新功能时，先问自己：没有这个功能，产品还能运转吗？

本章提示词模板

模板一：MVP功能清单审查

我正在为[产品描述]规划MVP，以下是我打算做的功能：
[列出功能清单]

目标用户是[描述]，核心Aha Moment是[用户第一次感受到价值的场景]。

请帮我：
1. 识别哪些功能是真正的"Must Have"（缺了产品就废了）
2. 哪些是"Should Have"（有了更好，但不是MVP必需）
3. 哪些应该直接扔掉（对核心价值无贡献）
4. 最终推荐3个MVP核心功能
5. 评估我定义的Aha Moment是否足够快速和直观

特别关注：是否有功能可以合并，以及是否有我遗漏的关键功能。

模板二：用户旅程设计

产品：[一句话描述]
目标用户：[描述]
核心工作（JTBD）：[用户真正想完成的事]

请帮我设计完整的用户旅程（从发现到成为忠实用户），包括：
1. 每个阶段的用户目标/期望
2. 每个阶段的关键动作
3. 可能的摩擦点（让用户放弃的原因）
4. 消除摩擦点的设计建议
5. 如何设计Aha Moment（具体到30秒内用户看到什么）
6. 习惯养成的触发器设计（让用户每天/每周回来）

[→ 第04章：技术架构：AI SaaS的最小可行技术栈](第04章_技术架构：AI SaaS的最小可行技术栈.md)

第03章 产品定义：LLM应用的最小可行产品设计

第03章 产品定义：LLM应用的最小可行产品设计

3.1 Job-to-be-Done：用户真正在雇佣什么

3.2 核心功能取舍：只做一件事

3.3 用户旅程：从痛点到Aha Moment

3.4 AI交互设计：不要让用户感到被AI控制

3.5 MVP范围最终确认

本章小结

本章提示词模板

第03章产品定义：LLM应用的最小可行产品设计

第03章产品定义：LLM应用的最小可行产品设计