智慧营养健康经营平台：政企版与学校版产品策略 V0.1

讨论稿｜2026-07-23

规划对象：智慧食堂产品线及政企、学校两个主要行业版本

规划周期：未来 12 个月，首轮执行窗口 90 天

人审状态：待 Jack、产品、营养、数据、研发、交付、销售和财务共同确认

0. 一页结论

0.1 战略判断

公司已经证明了两件事：

1. 进入了真实团餐场景。 截至 2025 年报口径，党政机关、国企和学校三类渠道完成 11 个项目落地验收；当前运营母集为 17 个项目，本轮实时核验 12 个。
2. 承载了高频交易。 12 个可查询项目累计约 184.93 万笔订单、3160.19 万元交易流水；2026-07-20 DAU 项目合计 8504，近 30 个自然日日均 DAU 项目合计 7242.38。

但还没有证明第三件事：

3. 没有证明营养健康价值已经规模化成立。 现有 8 个有交易项目中仅 1 个通过营养聚合质量门禁；当前只能确认“交易规模成立、营养数据底座部分成立、行为改善和健康结果尚未成立”。

因此下一阶段不是继续给智慧食堂叠加更多交易功能，而是完成一次产品定义升级：

从智慧食堂交易信息化，升级为营养健康经营平台：用每一笔真实交易连接 C 端选择和 B 端供给，让每一餐可看、可比、可分享、可改善，让每一道菜和每一次供餐可定义、可监测、可优化、可验证。

0.2 总体产品架构

建议采用“1 个共享底座 + 2 个行业工作台 + 3 个成熟来源系统 + N 条业务闭环”：

• 1 个共享底座： 营养健康经营底座。
• 2 个行业工作台：
  • 政企营养健康经营工作台。
  • 学校膳食治理工作台。
• 3 个成熟来源系统：
  • 餐厅运营。
  • 食品安全。
  • 供应链。
• N 条业务闭环： 政企侧先跑“营养反馈—供餐优化”；学校侧先跑“营养供餐、膳食经费、食品安全”，后续扩展集团/教育局监管和家长反馈。

这不是把三套系统重做一遍。统一原则是：

来源系统负责业务事实和原始操作，行业工作台负责管理结论、差异说明、协同状态、任务闭环和证据回读；一个能力只有一个主操作入口。

0.3 资源取舍

本轮建议的 7-2-1 不是机械预算比例，而是优先级：

1. 事实底座与口径

1.1 三个项目数字必须分开

1.2 本轮冻结的讨论口径

1.3 已证实、部分证实、未证实

反向判断：184.93 万笔订单如果没有可用菜品、重量和营养版本，只是更大的交易数据库，不会自动变成营养健康资产。

2. 统一产品定义

2.1 产品愿景

让真实团餐交易成为营养健康价值的持续验证器，而不是让营养健康停留在方案、标签或一次性报告里。

2.2 核心用户价值

C 端

• 可看： 每次结算后知道这一餐吃了什么、多少、主要营养构成是什么。
• 可比： 与本人历史、个人目标、周期均值比较，不做公开健康排名。
• 可分享： 生成脱敏周报或健康行为卡，适合企微/微信或家长查看。
• 可改善： 把偏差转成下一餐可执行建议，并观察 7/30 天变化。

B 端

• 可定义： 菜品、食谱、份量、营养值、适用人群和版本有统一定义。
• 可监测： 同时看计划菜单、实际售出、实际重量、选择率、浪费和异常。
• 可优化： 将问题菜、份量、档口组合、采购和菜单调整转成有责任人的任务。
• 可验证： 下一周期回看调整是否被执行、用户是否选择、供餐结构是否改善。

2.3 共享营养健康经营底座

2.4 跨系统上下文合同

学校截图提出“同标签页切换、统一身份上下文、精准下钻与跨系统闭环”。建议政企和学校统一使用同一份最小合同：

技术验收必须覆盖：正确下钻、正确权限、上下文不串租户、操作后状态回读、返回原位置、失败可恢复。

3. 政企版：营养健康经营工作台

3.1 谁购买、谁使用、为什么购买

3.2 政企版一句话定位

面向党政机关、国企、园区和企业员工餐厅，把现有订餐、消费、结算和供餐数据转成“员工每餐反馈 + 餐厅供餐优化 + 组织经营复盘”的营养健康服务。

3.3 首版产品结构

现有 Store 政企营养一期评审版已经形成五个 PC 页签，建议保留并连接真实闭环：

C 端首版只做四件事：

1. 一餐一卡。
2. 本餐与本人历史比较。
3. 7 天周报。
4. 下一餐一条可执行建议。

暂不做公开健康排名、复杂积分商城、疾病标签和全量个性化推荐。

3.4 政企版核心闭环

B端定义菜品/食谱/份量
  -> 餐厅发布菜单并供餐
  -> 员工真实选择和结算
  -> 系统生成营养餐卡与周期反馈
  -> 选择率、偏差、满意度和浪费回流
  -> B端调整问题菜、份量、档口和菜单
  -> 下一周期复盘是否改善

闭环完成的最低证据：

• 有明确的菜品和口径版本。
• 有真实餐次和实际售出。
• 有 C 端反馈到达或 B 端分析使用记录。
• 有一个责任人执行调整。
• 有下一周期复算和关闭结论。

3.5 政企版 90 天 MVP

首选候选项目：产业园。原因不是它规模最大，而是本轮唯一通过现有营养聚合质量门禁，试错成本最低。

首选餐段：午餐。项目底稿显示午餐约占有效订单 50.6%、有效流水 57.7%，最适合先验证。

3.6 政企版商业化假设

可形成四段收费结构，但当前均需财务、销售和交付核算：

1. 智慧餐厅标准软件/实施。
2. 营养健康经营模块。
3. 年度营养分析、运营和报告服务。
4. 康比特营养产品或健康活动联动服务。

是否成立不能看交易流水，要看标准复用率、交付工时、毛利、回款、服务使用、续费和主业联动。

4. 学校版：膳食治理工作台

4.1 对截图的产品解读

截图最重要的不是四个导航标签，而是三个设计原则：

1. 一个工作台，而不是第四套大而全业务系统。
2. 来源系统负责业务事实，工作台负责管理结论和协同闭环。
3. 先做可切换、可下钻、可返回，再做统一身份、对象和跨系统自动闭环。

因此，学校版不应简单复制政企版并改字段。学校版的核心购买任务是：

让校领导、后勤、财务、营养、食安、采购和家长围绕同一所学校、同一食堂、同一业务周期，看见问题、找到来源、明确责任、完成处置、回读结果并留档。

4.2 主要用户与责任

4.3 学校版四层产品结构

第一层：统一顶部壳层

• 学校。
• 食堂。
• 当前角色。
• 业务周期。
• 学校工作台、餐厅运营、食品安全、供应链的应用切换。

第二层：学校工作台

• 首页：总览、风险、待处理、应用状态。
• 膳食经费：总览、链路、差异说明、核验协同、公示档案。
• 营养供餐：任务、带量食谱、审核、分析。
• 追溯与公示：证据链、档案、家长反馈。

第三层：三套成熟来源系统

• 餐厅运营：人员账户、缴费充值、订餐、消费、退款、菜单发布、就餐结果、家长查询。
• 食品安全：明厨亮灶、晨检、消毒、陪餐、留样、农残、预警、整改、复核和档案。
• 供应链：供应商、商品、采购、配送验收、出入库、批次、盘点和成本基础。

第四层：集团/教育局监管

P0 不急于重做区域大屏。等单校对象、状态和闭环稳定后，再汇总：

• 学校接入和应用状态。
• 风险和超期任务。
• 膳食经费差异和公示状态。
• 营养供餐质量。
• 食品安全闭环。
• 跨校对标，但不公开对学生个人进行健康排名。

4.4 三条核心跨应用闭环

闭环一：营养供餐链

工作台创建供餐任务
  -> 营养员审核带量食谱
  -> 供应链执行采购
  -> 餐厅运营发布菜单
  -> 形成真实就餐结果
  -> 工作台做计划/实际差异分析
  -> 调整下一周期食谱和份量

必须回读：食谱版本、采购状态、菜单版本、实际售出、重量/营养覆盖、差异和下一步。

闭环二：膳食经费链

餐厅运营缴费/充值
  -> 消费/退款
  -> 供应链采购/库存
  -> 财务或银行系统会计主账
  -> 工作台核验协同
  -> 公示与档案

工作台只做链路、差异说明、核验协同和公示归档，不承担学校会计主账。多学校场景必须做到学校、学生、账单、账户和支付结果不串校。

闭环三：食品安全链

食安系统发现风险
  -> 工作台聚合督办
  -> 食安系统处置整改
  -> 食安系统复核关闭
  -> 工作台状态回读
  -> 追溯复盘和档案

工作台不能以“已派单”代替“已关闭”；关闭必须包含处置证据、复核人、复核时间和来源系统状态。

4.5 学校版 P0/P1/P2

4.6 学校版首个试点验收

首个试点应同时满足：

• 一所学校、一个主要食堂、明确校方 owner。
• 餐厅运营、食安、供应链三个系统均有可访问环境和对象 ID。
• 每条核心闭环各选一个真实样本。
• 深链接携带学校、食堂、角色、周期、对象和返回路径。
• 工作台只读摘要与来源事实一致。
• 至少有一次任务从发起、下钻、执行、回读到关闭。
• 家长侧沿用现有入口，信息范围和隐私边界经学校确认。

若三个来源系统中任一没有责任人、测试环境或可回读状态，先停在信息架构和接口合同，不把静态页面宣布为产品闭环。

5. 政企版与学校版的共同与差异

6. 指标体系：先证明“可算、可用、可改”

6.1 北极星分层

为避免一个“有效营养闭环餐次”掩盖过程问题，建议拆成三层：

• L1 可计算营养餐次： 有效订单、菜品明细、有效重量、可用营养主数据和版本齐全。
• L2 已反馈营养餐次： L1 中已经向 C 端展示餐卡，或进入 B 端供餐分析。
• L3 改善关联餐次： L2 中能够关联用户选择变化，或关联一个已复盘关闭的 B 端优化任务。

正式北极星建议使用 L3；建设期同时观察 L1、L2，避免团队通过多发卡片制造虚假繁荣。

6.2 数据质量门禁

候选门禁如下，均为 D 级建议，必须由数据、产品和营养负责人在试点前冻结：

候选数值：订单菜品覆盖率不低于 85%、菜品主数据关联率不低于 95%、重量有效率不低于 90%。这些数值不是现行制度，也不应在评审前写入合同或验收承诺。

6.3 三类指标不能混

订单流水再高，也不能替代产品价值和经营价值指标。

7. 90 天执行总图

M0：0-2 周，冻结事实和接口

输出：

• 17 项目注册表和同一时间快照。
• 现有营养门禁规则和失败原因。
• 产业园政企试点确认单。
• 学校试点确认单。
• 跨系统上下文和对象 ID 合同。

责任角色：产品负责人、数据负责人、营养负责人、政企产品、学校产品、架构。

停止条件：没有真实数据 owner、来源系统 owner 或可测试环境，不进入开发。

M1：3-6 周，修数据和接只读

输出：

• 机场、金斯瑞、赛迪等 Top 3 交易项目质量工单。
• 产业园真实只读数据进入政企五页签。
• 学校工作台壳层、应用切换和深链接原型。
• 指标证据抽屉和口径版本。

停止条件：未过 G1 的项目不进入个体营养反馈；学校下钻串租户或无法返回时不进入业务闭环。

M2：7-10 周，跑通真实闭环

输出：

• 政企午餐“一餐一卡—问题菜—调整—复盘”闭环。
• 学校营养供餐、膳食经费、食品安全各一个真实闭环。
• 每个任务的来源、责任人、期限、动作、回读和证据。

停止条件：只有页面、报表或派单，没有来源系统执行和回读，不算完成。

M3：11-13 周，做继续/迭代/停止决策

回答五个问题：

1. 有多少餐次真正可计算？
2. 有多少用户真正看过和连续使用？
3. 餐厅是否真正调整过菜、份量或菜单？
4. 学校是否真正减少了跨系统找人、对账和追踪成本？
5. 这套能力复制到第二个项目需要多少配置、开发和交付工时？

输出：GO / ITERATE / STOP 评审，不自动扩面。

8. 把“干好多事儿”变成产品组合管理

“做了很多事”不是问题本身；问题是事项没有共同北极星、没有版本边界、没有证据门禁，也没有停止条件。

从下一轮开始，任何需求进入排期前必须回答六个问题：

1. 它服务哪个客户和角色？
2. 它进入共享底座、政企版还是学校版？
3. 它闭合哪一条业务链？
4. 它改善 L1、L2、L3、学校管理闭环还是经营指标？
5. 它完成时需要什么真实证据？
6. 它能成为标准能力、配置项、项目定制，还是应该拒绝？

建议统一用四类需求标签：

8.1 当前停止清单

• 不在营养数据门禁前继续扩 C 端“智能推荐”。
• 不把学校工作台做成支付、食安、库存和财务的第四套主系统。
• 不用静态大屏或本地 Mock 冒充真实闭环。
• 不以交易流水代替收入、毛利、回款和续费。
• 不以“项目已交付”代替“标准产品已证明可复制”。
• 不以营养聚合代替行为改善，更不代替健康或医疗效果。
• 不让单一客户定制直接进入共享底座。

9. 经营逻辑

9.1 为什么值得做

• 已有真实场景和高频交易，获客入口不是从零开始。
• 康比特的差异化不应停在收银、订餐和食安，而应连接营养专业能力。
• 共享营养底座可同时服务政企和学校，具备复用潜力。

9.2 怎么做大

• 政企版先用营养数据就绪项目验证产品价值。
• 学校版用单校工作台验证多角色协同，再扩多校/教育局。
• 三套来源系统保持独立成熟，统一对象、上下文和闭环协议，降低重复建设。

9.3 怎么赚钱

候选收入包括项目实施、标准软件/模块、SaaS/运维、营养分析服务、监管服务、设备数据服务和主业联动。当前没有足够数据确认哪一种已形成稳定持续收入。

9.4 怎么证明可复制

第二个项目的标准能力复用率、配置比例、交付周期、实施/售后工时、缺陷、毛利和回款，比第一个项目的功能数量更重要。

9.5 怎么反哺主业

只有当营养服务使用、组织健康活动、康比特营养产品联动和持续付费形成真实样本，才可以讲主业协同；当前是待验证命题。

10. 待评审的 12 个关键决策

1. 是否确认“营养健康经营平台”为统一上位产品定义？
2. 是否确认“一个共享底座 + 政企/学校两个行业工作台”的产品边界？
3. 政企首个真实试点是否选产业园，首个餐段是否选午餐？
4. 学校首个试点是哪所学校，三个来源系统的 owner 分别是谁？
5. 现有营养质量门禁的正式字段、阈值和失败分类是什么？
6. L1/L2/L3 是否作为建设期北极星分层？
7. C 端一期是否只保留餐卡、历史比较、周报和下一餐建议？
8. 学校 P0 是否只做管理闭环、应用切换、精确下钻和回读？
9. 膳食经费主账、会计责任和公示口径由哪个系统负责？
10. 跨系统身份、对象 ID 和深链接协议由谁牵头冻结？
11. 第二个复制项目必须记录哪些研发、交付、财务数据？
12. 哪些需求从今天开始明确停止、延期或转为项目定制？

11. 本稿状态

本稿已经完成：

• 统一产品定义。
• 政企版和学校版结构。
• 共享能力与来源系统边界。
• 三条学校闭环和一条政企 C/B 闭环。
• 90 天路线图、指标门禁、停止清单和待决策项。

本稿尚未完成：

• 正式 SPAN/PDC/APPEALS 数字评分。
• 毛利、回款、交付工时、续费和服务收入验证。
• 竞品同范围价格和能力对比。
• 学校试点、业务 owner 和来源系统合同冻结。
• 人工评审后的正式版本计划。

因此本稿状态是：

V0.1 可讨论、可拆任务，但不是最终经营计划、研发排期、客户承诺或对外材料。