用途：当创始人或 PM 已有完整功能构想或规格，需要提炼出值得构建的最小版本时启用。触发场景包括“我们的 MVP 是什么”“该砍什么”“缩小范围”“先做什么”“只有 4 周”“帮我排优先级”，以及团队陷入范围蔓延、需要划清必备与可选边界时。
主要能力：按固定工作流推进——先陈述 MVP 要验证的假设（格式为“我们相信[用户群]在提供[能力]后会[行为]，当[可衡量信号]出现时即验证成功”）；列出全部候选功能；用 MoSCoW 分为 Must Have、Should Have、Could Have、Won't Have；为每个 Must Have 识别技术、市场与执行风险，高风险项先做 spike 或原型；划定发布分界线并给推迟项设定触发条件；粗估 Must Have 工作量，若超出可用时间 20% 以上则强制排序并降级最低项；最后产出简洁的范围文档。输出包含假设陈述、MoSCoW 分类表（功能、理由、风险等级、工作量估算）、风险登记表、MVP 范围摘要与成功标准。
使用方式：需要来自 startup-context 的公司阶段、团队规模、资金/时间压力、现有产品与技术栈约束；来自用户的功能愿景或规格、目标用户群、核心假设、可用时间与资源、不可协商要求（合规、安全、合同承诺）。
适用场景与限制：适合新产品 MVP 或现有功能缩减。原则包括“纸杯蛋糕而非一层蛋糕”、优先学习速度、先手动后自动化、只服务一个用户群、风险优先排序。若团队无法就 Must Have 达成一致，可问“只能做 3 个功能会选哪 3 个”。推迟不等于删除，需维护带明确触发条件的待办。资料未提供具体收费、价格、平台或安装命令等信息。