如何拆分核心功能和非核心功能

你手里有一份 30 个功能的需求清单，团队只够在 MVP 阶段做 3 到 5 个。每个功能看起来都有道理，每个利益相关方都能说出「这个很重要」的理由。这不是假设场景——这是每个 AI 产品出海团队在 MVP 阶段都会遇到的真实困境。

功能拆分的本质不是「砍需求」，而是「用有限资源验证核心假设」。拆分错了，要么做出一堆没人用的功能，要么漏掉让用户留下来的关键能力。本文介绍三种主流的拆分方法——MoSCoW、Kano 模型、RICE 评分——并给出一套可以直接执行的实操流程。

核心功能的定义标准

在讨论拆分方法之前，需要先明确什么叫「核心功能」。核心功能不是「用户说想要的功能」，而是「没有它产品就跑不通的功能」。

三条判断标准

标准	说明	反例
用户能否完成核心任务	去掉这个功能，用户的主要流程是否中断	一个 AI 写作工具没有「生成文本」的功能，只剩模板选择
产品价值主张是否成立	去掉这个功能，产品的差异化卖点是否消失	一个主打「实时翻译」的工具没有翻译引擎，只剩文档管理
早期用户是否愿意为此留下	早期采用者（Early Adopter）对功能的容忍度更低，但核心能力缺失会直接导致流失	用户注册后发现关键操作需要付费才能体验，直接卸载

核心功能 vs 非核心功能的边界

核心功能和非核心功能之间不是一条固定线，而是一个光谱。实际操作中，可以用一个简单的问题来测试：

如果这个功能不存在，用户会不会去用竞品，或者干脆不用这类产品？

如果答案是「会」，那它就是核心功能。如果答案是「有这个功能更好，但没有也行」，那它就是非核心功能。

三种主流拆分方法

MoSCoW 方法

MoSCoW 是最直观的定性分类方法，把所有功能分成四个桶。

类别	含义	MVP 阶段处理
Must have	没有它产品无法运行，核心任务链路断裂	全部纳入 MVP
Should have	重要但不致命，MVP 阶段可以延后	尽量纳入，资源不够就降级
Could have	锦上添花，有了能提升体验	MVP 不包含，记录到后续版本
Won't have	当前版本明确不做，可能是时机不对或 ROI 太低	记录原因，定期复盘

MoSCoW 的关键在于 Must have 的比例控制。如果一个团队把所有功能都标为 Must have，这个方法就失去了意义。经验法则是 Must have 控制在总功能的 20% 到 40% 之间。如果超过 60%，说明分类标准太松，需要重新校准。

MoSCoW 分类示例：AI 客服工具

功能	分类	理由
AI 自动回复用户问题	Must	没有自动回复，产品不成立
多语言支持	Must	出海产品，目标市场语言是核心需求
知识库管理	Should	重要，但 MVP 阶段可以手动导入 FAQ
对话记录导出	Could	用户需要，但不影响核心使用
自定义 AI 人设	Could	差异化功能，但非 MVP 必需
与 CRM 系统集成	Won't	需要稳定用户基础后再做
实时语音通话	Won't	技术复杂度高，MVP 阶段 ROI 不明

Kano 模型

Kano 模型从用户满意度的角度来分类功能。它的核心洞察是：不同类型的功能对用户满意度的影响方式完全不同。

类型	对满意度的影响	特征	示例
必备型（Must-be）	有了不会更满意，没有会非常不满	用户视为理所当然	登录注册、数据安全、基本响应速度
期望型（One-dimensional）	做得越好越满意，做得差就不满	与满意度线性相关	AI 回答准确率、响应速度、多轮对话能力
魅力型（Attractive）	有了会很惊喜，没有也不会不满	超出用户预期	AI 自动生成摘要、一键多语言翻译
无差异型（Indifferent）	有没有都不影响满意度	用户不关心	后台日志格式、内部 API 版本号
反向型（Reverse）	有了反而不满	用户不需要甚至反感	过于频繁的推送、强制分享、过度复杂的设置

Kano 模型的使用需要通过问卷调查来判定。典型做法是对每个功能问两个问题：

如果产品有这个功能，你觉得如何？（喜欢 / 理应如此 / 无所谓 / 能容忍 / 不喜欢）
如果产品没有这个功能，你觉得如何？（喜欢 / 理应如此 / 无所谓 / 能容忍 / 不喜欢）

两组答案的交叉组合决定了功能属于哪个类别。

Kano 模型判定矩阵

	有该功能：喜欢	有该功能：理应如此	有该功能：无所谓	有该功能：能容忍	有该功能：不喜欢
没该功能：喜欢	反向型	反向型	反向型	反向型	反向型
没该功能：理应如此	魅力型	无差异型	无差异型	无差异型	无差异型
没该功能：无所谓	魅力型	无差异型	无差异型	无差异型	无差异型
没该功能：能容忍	魅力型	无差异型	无差异型	无差异型	无差异型
没该功能：不喜欢	魅力型	期望型	必备型	必备型	疑问结果

MVP 阶段的目标很清晰：先全部覆盖必备型，尽量做好期望型，挑选 1 到 2 个魅力型作为亮点，忽略无差异型，避免反向型。

RICE 评分

RICE 是一个定量评分框架，适合在功能数量较多、需要精确排序时使用。

公式：

$$RICE = \frac{Reach \times Impact \times Confidence}{Effort}$$

维度	含义	常用单位
Reach（触达）	一个时间段内有多少用户会用到这个功能	用户数 / 季度，或用户数 / 月
Impact（影响）	对单个用户的影响程度	3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence（信心）	对以上估算的确信程度	100% = high, 80% = medium, 50% = low
Effort（工作量）	团队需要投入的人力	人月（person-months）

RICE 评分示例：AI 写作工具

功能	Reach（月活用户数）	Impact	Confidence	Effort（人月）	RICE 分数
AI 文本生成	1000	3（massive）	80%	3	800
多语言翻译	600	2（high）	80%	2	480
模板库	800	1（medium）	100%	1	800
协作编辑	300	2（high）	50%	4	75
版本历史	400	1（medium）	80%	2	160
AI 续写建议	500	1.5（medium-high）	50%	2	187.5
导出 PDF	700	0.5（low）	100%	0.5	700

按 RICE 分数从高到低排序，优先做分数最高的功能。这个方法的优势在于透明——每个数字都可以讨论和修正，最终排序是可追溯的。

三种方法对比

维度	MoSCoW	Kano 模型	RICE 评分
分类方式	定性四分类	基于用户满意度的五分类	定量打分排序
适用阶段	需求评审、Sprint 规划	用户调研后、功能设计前	功能清单已经较长、需要精确排序
数据需求	低，团队讨论即可	中，需要用户问卷	高，需要估算或历史数据
优点	简单直观，利益相关方容易理解	关注用户真实感受，避免「自嗨式」功能	可量化、可比较、可追溯
缺点	容易把太多东西标为 Must	需要问卷设计和数据分析	估算不准时结果会误导
适用团队规模	小型团队、快速决策	有用户调研资源的团队	功能多、需要数据驱动的中型团队
建议搭配	与用户故事地图搭配	与 RICE 搭配做最终排序	与 MoSCoW 搭配划分版本边界

实操步骤：从功能清单到优先级排序

第一步：列出完整功能清单

把所有利益相关方提出的功能全部记下来，不做任何筛选。来源包括：用户访谈、竞品分析、团队脑暴、业务需求文档。

这一步的关键是 不做判断。先把所有想法收集到一个地方，确保没有遗漏。通常一个 AI 产品的初始功能清单会在 20 到 50 个功能之间。

第二步：定义产品的核心价值主张

用一句话回答：这个产品解决什么问题，为谁解决？

例如：「帮助跨境电商卖家自动生成多语言商品描述，从中文一键翻译成英语、日语、西班牙语。」

这句话会成为后续所有判断的锚点。凡是与这句话无关的功能，优先级都应该降低。

第三步：用 MoSCoW 做粗分

把所有功能按 MoSCoW 分进四个桶。重点关注 Must have 的比例——如果超过 40%，说明标准太松，需要逐条挑战：「如果没有这个功能，用户真的不能用吗？」

第四步：对 Must have 做 Kano 验证

对 Must have 里的功能做 Kano 分析。如果某个功能被用户归类为「无差异型」或「反向型」，即使团队认为它很重要，也需要重新评估。

这一步常见的问题是把「团队觉得重要」等同于「用户觉得重要」。Kano 的价值就在于用用户数据来纠正这种偏差。

第五步：用 RICE 对 Must have 和 Should have 排序

对 Must have 和 Should have 中的功能做 RICE 评分。Reach 和 Effort 用团队估算，Impact 基于用户调研或业务目标，Confidence 基于数据来源的可靠性。

排序后，按分数从高到低选取，直到资源用完。排在前面的就是 MVP 的核心功能集。

第六步：检查 MVP 功能集的完整性

拿到 MVP 功能集后，做三个检查：

核心任务是否完整：用户能否用这些功能完成主要流程？如果流程有断裂，需要补上。
是否有魅力型功能：至少保留 1 到 2 个魅力型功能作为产品亮点，这是早期用户愿意分享和推荐的理由。
是否包含反向型功能：如果有，立即移除。

功能拆分和优先级排序流程

流程图画布 · 115%

Mermaid 流程图加载中...

案例：两个 AI 出海产品的功能拆分

案例一：AI 面试模拟工具

一款帮助求职者用 AI 模拟面试的产品，目标市场是东南亚和印度。

初始功能清单有 28 个功能。用 MoSCoW 粗分后：

类别	功能	数量
Must have	AI 提问、语音/文字回答、面试反馈	3
Should have	面试记录回放、常见问题库	2
Could have	简历分析建议、多语言支持、分享面试结果	3
Won't have	视频面试、真人教练匹配、企业端管理后台	20

用 RICE 对 Must 和 Should 排序后，确认 MVP 包含 5 个功能：AI 提问（RICE 800）、文字回答（RICE 600）、面试反馈（RICE 750）、面试记录回放（RICE 300）、常见问题库（RICE 400）。

Kano 验证发现，「AI 面试反馈」是魅力型功能——用户没想到能得到即时反馈。团队决定把它作为产品亮点，在 landing page 上重点展示。

案例二：AI 数据分析助手

一款帮助中小企业老板用自然语言查询业务数据的产品，目标市场是拉美。

初始功能清单有 35 个功能。MoSCoW 粗分时，团队把所有功能都标为 Must have——这是非常常见的错误。

经过逐条挑战后重新分类：

类别	功能	数量
Must have	自然语言查询、数据表连接、结果可视化	3
Should have	查询历史、常用查询收藏	2
Could have	定时报告、数据导出、团队协作	3
Won't have	自定义仪表盘、API 接入、权限管理、数据清洗	27

重新分类后 Must have 从 35 个降到 3 个。团队最初把所有功能都标为 Must，是因为「每个功能都有人需要」。但 MVP 阶段只需要验证一个核心假设：中小企业老板是否真的愿意用自然语言来查询业务数据。验证这个假设，只需要 3 个功能。

常见错误和应对

错误	表现	应对方法
所有功能都是 Must have	MoSCoW 失去区分度	逐条问「去掉它产品还能用吗」
只凭直觉排序	RICE 数字是编出来的	用用户调研数据校准 Impact 和 Confidence
忽略反向型功能	做了用户反而不喜欢的功能	Kano 问卷必须包含「有这个功能你感觉如何」
不做 Kano 验证	团队自认为的「必备」其实是「无差异」	至少对 Must have 做小范围用户验证
魅力型功能为零	MVP 没有传播点，早期增长困难	刻意保留 1 到 2 个让用户惊喜的功能

检查清单

在进入开发之前，用以下清单做最终检查：

核心价值主张能用一句话说清楚
Must have 功能数量控制在总功能的 20% 到 40%
每个 Must have 功能都能对应到核心任务链路中的一个环节
用 Kano 验证过 Must have 功能，确认没有「无差异型」混入
用 RICE 对 Must have 和 Should have 做过排序，排序结果可追溯
MVP 功能集中至少有 1 个魅力型功能作为传播亮点
MVP 功能集中没有反向型功能
核心任务链路完整——用户能从起点走到终点
Won't have 列表中的每个功能都记录了不做的理由
功能拆分结果已经和所有利益相关方对齐，没有未解决的争议
Reach 和 Effort 的估算有依据，不是拍脑袋
有明确的指标来验证 MVP 是否成功（留存率、转化率、NPS 等）