القائمة
划分 MVP 范围、明确非目标范围时使用。适用于第一版功能定义、范围控制、需求收敛。优先使用 MoSCoW 四级分类 + 非目标范围明示。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/zhaoxuya520/AI-Fullstack-Delivery-Workflow --skill mvp-scopingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
استنادا إلى تصنيف 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/开发 → 开始执行