结论先看
基本型后台、前厅结算、身份补贴、设备 Runtime、基础食安、硬件集成。目标是稳定上线和可验收。
期望型企业园区标准包、经营看板、移动端、食安闭环、营养展示、售前交付证据。目标是成交和复用。
魅力型健康画像、营养推荐、智能排菜、AI 识别、经营健康双看板、AI Copilot。目标是康比特差异化。
无差异过度展示、大屏装饰、低频定制报表。只有绑定验收和经营指标后再升级。
反向医疗化承诺、AI 无人工复核、绕过门禁定制、未授权公开客户案例。必须设 stop rule。
方法来源：target-chat-methodologies.html，KANO 对应图片编号 06、07。明细 CSV：smart-canteen-kano-product-mining.csv。
证据边界
| 来源 | 用于证明什么 | 证据等级 |
|---|---|---|
| 目标聊天记录方法论图片 | KANO 是本次使用的方法框架 | C：方法证据 |
| 软件、硬件、营养健康能力图 | 现有产品内容已经按 PC、移动端、设备、食安、营养、看板等能力归类 | B/D：资料体系证据，部分待补真实页面和设备信息 |
| 15 个团餐项目复盘产品证据库 | 11 个收入样本、186 条产品明细、前厅/食安/营养/硬件等产品包销售样本 | A/B：销售额和明细样本；不含毛利、回款和客户满意度 |
| 产品地图与功能现状矩阵 | 产品包战略定位、功能现状、下一步补证要求 | B/D：战略草案和待补项 |
基本型先把能上线、能结算、能验收做稳
| 产品内容 | 现有证据 | 为什么是基本型 | 下一步 |
|---|---|---|---|
| PC 运营管理后台 | SW01 映射 1745 条资料；FCM-01 标为经营底座 | 客户默认需要客户、餐厅、档口、菜品、订单、充值、补贴、报表 | 补页面/API/数据对象、演示路径和验收清单 |
| 前厅交易结算系统 | 7 个项目覆盖；26 条明细；684440 元销售样本 | 收款、绑盘、称重、读卡、POS、消费机是食堂上线入口 | 建立标准 SKU、设备接入模板和异常处理测试集 |
| 账户、身份、补贴、支付、对账、权限 | 产品地图把标准平台定义为统一底座 | 机关、园区、学校类客户首先要求财务和身份可控 | 拆成可配置模块和报价字段门禁 |
| 设备端称重结算 Runtime | SW03 映射 4392 条资料；HW01 映射 4252 条资料 | 现场称重、绑盘、结算稳定性直接影响就餐秩序 | 补型号、协议、成本、故障率、联调和验收证据 |
| 基础食安台账 | 后厨食安进销存系统 7 个项目覆盖；865775 元销售样本 | 留样、晨检、消毒、温湿度、库存验收是合规底线 | 绑定 food_safety、qc、智慧食堂的真实页面/API/设备边界 |
期望型把客户会比较的能力做成标准包
| 产品内容 | 现有证据 | 为什么是期望型 | 下一步 |
|---|---|---|---|
| 企业/园区/机关智慧食堂标准包 | 产品地图标为第一突破；收入样本估算 2633450 元 | 标准包越完整，越能减少售前定制和交付扯皮 | 做行业版方案、报价门禁、标准点位和交付清单 |
| 经营报表与数据看板 | SW06 映射 2272 条资料；FCM-06 标为续费复盘理由 | 客户会期待客流、消费、补贴、菜品、设备在线率等分析 | 建立经营健康双看板指标字典 |
| 职工移动端/小程序 | SW02 映射 1129 条资料 | 移动端影响职工触达、体验和服务感知 | 补真实页面、接口、授权采集和非医疗提示 |
| 食安监管闭环 | SW04、HW04 已归类；后厨食安有销售样本 | 从基础台账进阶到责任链和整改闭环，会增强采购理由 | 输出页面/API/设备/整改闭环证据矩阵 |
| 营养标签、菜品营养库、电子价签 | 4 个项目覆盖；214600 元销售样本；NH01 已建立 | 这是康比特营养能力进入餐厅现场的可见入口 | 做菜品营养标准、电子价签内容规范和运维责任清单 |
| 售前 intake 与交付证据治理 | FCM-07 已生成模板 | 不是前台功能，但决定报价、排期和验收可复制 | 下一个真实售前项目执行字段完整度门禁 |
魅力型康比特差异化在 AI 营养、健康服务和经营复盘
| 产品内容 | 现有证据 | 为什么是魅力型 | 下一步 |
|---|---|---|---|
| 职工健康画像 | NH02 映射 277 条营养健康资料 | 把食堂升级为员工健康和组织福利服务 | 先出非医疗边界、授权模板、脱敏规则和报告样张 |
| 营养推荐与干预 | NH03 已归类；战略 V0.3 标为差异化增强 | 可信可验收后，区别于纯软件和硬件厂商 | 定义营养师审核、推荐解释、失败处理和服务 SOP |
| 智能排菜与营养供餐 | 已有智能排菜客户版/销售版材料 | 连接营养标准、成本、菜品供应和客户体验 | 选择样板项目做 MVP，记录前后指标 |
| AI 菜品识别与后厨行为识别 | HW03 已归类；设备 intake 标为 AI 差异化 | 让食安监管和菜品管理更有展示效果 | 建立算法 benchmark、样本边界和人工复核流程 |
| 经营与健康双看板 | NH05 与 FCM-06 均已归类 | 把续费理由从系统可用升级为持续改善经营和健康服务 | 做管理层样张，绑定验收与续费复盘 |
| AI 营养健康与增长智能体 | 产品地图列为长线布局；战略 V0.3 建议内部 Copilot 先行 | 先提升售前、产品、交付复用效率，再审慎开放客户侧能力 | 记录节省时间、错误率、人工审核点和失败案例 |
无差异与反向需求
无差异过度展示
装饰性大屏、展示页面、一次性活动素材，只有绑定经营、食安、营养或验收指标后才值得升级。
无差异低频定制
低频小众报表和一次性字段进入报表字段池，按客户覆盖率和验收价值排序。
反向高风险承诺
医疗诊断式表述、AI 无人工复核、绕过字段门禁直接定制、未授权公开客户案例，全部进入人工门禁。
反向需求不是“晚点做”，而是默认不能做。除非补齐法务、客户授权、数据合规、算法指标和人工责任边界。
产品重新命名建议
| 产品包 | KANO 定位 | 建议表达 |
|---|---|---|
| 标准智慧营养健康餐厅平台 | 基本型 + 期望型底座 | 经营、结算、设备、报表、食安的统一底座 |
| 企业/园区/机关智慧食堂标准包 | 期望型主战产品 | 当前第一突破线，重点卖标准场景、报价边界和交付复用 |
| 食安监管与智能硬件场景包 | 基本型合规 + 期望型增强 | 监管强客户是基础能力，一般客户是增强包 |
| 职工营养健康服务包 | 魅力型差异化 | 先用非医疗边界、报告样张、营养师 SOP 降低风险 |
| AI 营养健康与增长智能体 | 魅力型长期布局 | 先内部 Copilot，客户侧只开放可验收、可解释、有人工复核的场景 |
| 售前 intake 与交付证据治理 | 期望型支撑能力 | 不是客户前台功能，但决定产品化、报价和交付可复制 |
下一步最小执行切片
- 做 `基本型 P0 验收清单`：后台、前厅结算、身份补贴、设备 Runtime、基础食安、硬件集成，每项绑定页面/API/设备/截图/异常处理。
- 做 `期望型标准包报价矩阵`：企业/园区/机关标准包、食安监管包、营养展示包、移动端、数据看板、售前 intake。
- 做 `魅力型 MVP 包`：选择智能排菜、健康画像、AI 菜品识别、经营健康双看板中的 1-2 个，用内部或样板项目跑验证。
- 做 `反向需求门禁表`：医疗承诺、健康数据、AI 自动决策、非标准定制、客户案例公开，全部设人工审批。
结论：基本型做稳定和验收，期望型做标准包和报价，魅力型做康比特差异化，反向需求做门禁。