用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill mvp-scoping命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | mvp-scoping |
| description | 划分 MVP 范围、明确非目标范围时使用。适用于第一版功能定义、范围控制、需求收敛。优先使用 MoSCoW 四级分类 + 非目标范围明示。 |
MVP = 能验证核心价值的最小闭环
不是"少做几个功能"，而是"做最少的功能但能跑通完整业务流程"。
错误理解：
完整产品 = 100 个功能
MVP = 10 个功能
→ 砍 90 个，但用户体验断裂
正确理解：
完整产品 = 100 个功能
MVP = 能完成 1 个核心业务闭环的最少功能
→ 假设 15 个功能能跑通，就做 15 个
Must Have（必须有）
没有它功能不能成立
例：电商 MVP 的"下单"功能
Should Have（应该有）
影响体验，但可在第二版补
例：电商 MVP 的"优惠券"
Could Have（可以有）
锦上添花，资源充足时再做
例：电商 MVP 的"商品评分"
Won't Have（暂不做）
明确排除，防止范围蔓延
例：电商 MVP 的"直播带货"
比 MVP 范围更重要的是明确写出"不做什么"：
为什么需要非目标：
- 防止需求方反复加塞
- 减少团队理解偏差
- 保留后续版本的设计空间
- 避免在不重要的事情上浪费精力
写法：
❌ "这一版不做太多功能"（模糊）
✅ "这一版不做：
- 多语言支持（仅中文）
- 移动端原生 APP（仅 H5）
- 第三方支付集成（仅微信支付）
- 商家自助入驻（仅运营手动配置）"
1. 列出所有候选功能
↓
2. 识别核心业务闭环
（用户从进入到完成核心目标的最短路径）
↓
3. 标注每个功能在闭环中的角色：
- 必经节点 → Must
- 可省略但有损 → Should
- 完全可选 → Could
↓
4. 明确写出 Won't（非目标）
↓
5. 用 1 句话描述 MVP：
"用户可以 [做什么]，从而 [获得什么价值]，但暂时不能 [哪些限制]"
↓
6. 检查闭环是否完整（不能有断点）
## MVP 范围：[功能/产品名]
### 核心业务闭环
[一句话描述用户能完成什么]
### Must Have（这一版必须有）
| # | 功能 | 在闭环中的角色 |
|---|------|---------------|
| 1 | 用户注册/登录 | 入口 |
| 2 | 浏览商品列表 | 发现 |
| 3 | 商品详情页 | 决策 |
| 4 | 加入购物车 | 收集 |
| 5 | 下单结算 | 转化 |
| 6 | 在线支付 | 完成 |
| 7 | 订单状态查询 | 反馈 |
### Should Have（第二版补）
- 商品搜索
- 优惠券系统
- 收藏夹
### Could Have（资源充足时）
- 商品评分
- 个性化推荐
### Won't Have（明确不做）
- ❌ 多语言（仅中文）
- ❌ 原生 APP（仅 H5）
- ❌ 直播带货
- ❌ 商家自助入驻
- ❌ 退款流程（人工处理）
### 范围说明
[为什么这样切？哪些是为了验证什么假设？]
□ 核心业务闭环是否能跑通（不能有断点）
□ Must 中的功能去掉任何一个，闭环是否会断
□ Should/Could 是否真的可后置（不是"应该有但偷偷觉得不能没有"）
□ Won't 是否明确写出（不能模糊带过）
□ 一句话能不能说清楚 MVP 是什么
□ 范围切分是否服务于验证某个假设
templates/mvp-scope-template.md — MoSCoW 分类 + 非目标范围 + MVP 一页纸简报上游：
opportunity-tree → 提供候选方案
prioritization → 提供优先级评分（辅助 MoSCoW 判断）
平行：
prd-writing → MVP 范围进入 PRD 第 5 节
pol-probe → 高不确定的 Must 先做验证实验
下游：
转交项目经理 → 按优先级拆排期
Must 范围转交 UI/UX/API/开发 → 开始执行