1. 一个具体问题
旅客觉得酒店房间干净理所当然，却会因不干净强烈不满；高速网络越稳定，满意度可能越高；意外获得合适的延迟退房则可能带来惊喜。所有功能都用“有多少人说想要”来排序，会忽略它们对满意度影响的不同方式。
2. 一句话解释
Kano 模型区分不同需求属性与满意度的关系，帮助理解基本要求、线性改善和惊喜价值为何不能简单相加。
3. 出处与原意
Noriaki Kano 及合作者在 1984 年《Attractive Quality and Must-Be Quality》中提出相关模型。常见应用包括必备型、期望或一维型、魅力型，也讨论无差异和反向属性。问卷中的矛盾回答还需要单独检查，不能强行归为一种需求。
4. 原理与机制
必备属性缺失会引发不满，做到后未必显著增加赞赏；一维属性的表现改善通常对应更高满意度；魅力属性在没有时未必被要求，出现时却能带来额外价值。判断依赖具体用户和情境，并会随时间变化，过去的惊喜可能变成今天的基本要求。通常使用成对问题询问“有该属性”和“没有该属性”的反应，再依据组合分类。它不是让团队猜测曲线，也不自动决定优先级：成本、风险和战略仍要纳入。
成对问题的措辞需要具体且对称。“如果产品非常好用，你有什么感受”无法对应单一属性；“如果预约后能收到确认信息”才较容易判断。没有该属性的问法也不能夸张成灾难场景，否则会人为提高必备分类。正式分析前可让少量受访者解释他们如何理解问题，检查回答是否反映同一功能，而不是对不同版本的想象。
5. 一个完整案例
假设案例：一款预约工具考虑三个改进：防止重复预约、缩短加载时间、自动生成出行提醒。团队先访谈并向目标用户发出成对问题。结果显示重复预约是强烈不满来源，加载速度与满意度持续相关，提醒只对部分用户有吸引力。团队先修复重复预约，再优化最慢页面，最后对经常跨城的用户试验提醒。上线后检查投诉与实际使用，而不是把问卷里的“喜欢”直接等同于愿意付费。
6. 适用条件与反例
适合需求组合、体验改进与功能取舍。不同客群混在一起可能互相抵消，尤其是有人喜欢自动化、有人重视控制权时。安全、隐私和必要合规要求不能因用户没主动表达就被当作不重要；模型衡量的是满意关系的一部分。
7. 今天可以尝试的行动
选择五项候选能力，分别询问存在与缺失时的感受，并记录受访者处境。先检查必备项是否欠账，再比较其他项目的预期价值与实现成本。对分歧大的属性按客群拆开验证，不急着给全体用户贴同一标签。