2026-09-15 · 决策建议稿。依据用户分享的13张截图、两篇新开普官方文章、我方既有源码与v0.5交接材料。截图所属厂商由用户说明，未独立确认产品版本/租户配置；只评价看得到的流程，不将“未展示”写成“完全没有”。原始聊天和身份信息不进入报告或公开原型。
1. 我的判断：先把“今天这顿怎么吃”做扎实
新开普这组截图给用户提供了查菜、查营养、登记和看运动的工具；我们要交付的是一次可以直接执行的用餐决定，并根据实际吃了什么继续调整。
这组展示确实有改进空间。问题主要在“信息如何变成行动”：用户看到每100克热量、营养素目标和运动热量后，仍要自己推算一餐搭配、份量和下一步。界面换得更漂亮，不能单独解决这个问题。
不过，对方在官方材料中已经有称重、绑盘、一卡通、排菜与运营数据的布局，也公开介绍了AI助手和模型部署。我们不能将它概括成“只有静态页面”。真正要比较的是：同一个普通用户，在同一个食堂、同一餐段、同一组可供应菜品下，谁能更快帮助他做出适用选择、形成可信记录，并持续执行。新开普称重选餐方案；新开普智慧校园AI。厂商宣传的效果百分比没有作为本报告的验证结果。
建议接下来把首个可交付增量定为：“这一餐帮你选，吃完以后帮你调。” 体检/微体检、睡眠和全天状态作为可用背景逐步进入，不阻塞第一条餐食服务链。
2. 截图里哪些地方不够好，如何改
| 证据 | 看到了什么 | 对用户的影响（我方判断） | 我们的具体改法 |
|---|---|---|---|
| IMG-01/08 | 主入口以账户卡、交易和功能宫格为主；个人信息单独填写 | 用户需要在工具之间寻找健康任务 | 交易入口保留快捷位；健康服务首屏突出“这一餐怎么选”，只在需要时补关键背景 |
| IMG-02 | 今日菜谱列菜名、每100克能量、营养详情 | 能查数据，但一餐仍需自己组合 | 将当天可供应菜分成两套适用搭配；能换一道菜，显示替代原因与条件 |
| IMG-04/10 | 能量查询多行只显示单位，没有显示数值 | 不清楚是未加载、资料缺失还是没有能量 | 加载/缺失/计算中分开；资料缺失时不展示空数值旁的单位造成错觉 |
| IMG-05 | 菜品详情按每100克给能量；构成区只见“素鸡50g” | 无法从当前展示理解配方、成品出成与基准重量 | 补配方版本、熟重/可食部/出成口径；缺配方就只保留已知类别，不给伪精确餐单 |
| IMG-06/09 | 饮食登记为空；营养主页显示当日摄入0、进度0% | 用户容易把“系统没记录”理解成“今天没吃” | “已记录摄入”和覆盖范围同显；明确未记录/本人确认未进餐，下一餐建议按资料完整度降级 |
| IMG-07 | 运动页有步数、消耗、运动登记与帮助 | 未展示这些数据怎样影响本餐或当下行动 | 有来源与适用规则才影响行动；不要把步数直接换算为可以额外吃多少 |
| IMG-03 | 期望菜品投票机会为0、按钮禁用 | 不知道为什么不能操作、何时再来 | 在业务规则确实需要时保留，并说明未开放/名额用尽/下期时间；不占健康首页主位置 |
| IMG-12/13 | 有通用解绑确认及独立用户解绑页 | 用户不一定知道解绑对象与影响 | 分清餐盘、设备/移动端绑定、健康数据分享；确认框写明影响范围，保留必要认证 |
这些不是全面质量判决。 能量空值可能是加载或配置问题；没有记录不能证明对方没有自动采集；营养分析详情、个性化推荐结果、通知与专家后台都未完整提供。不能据这些截图评价算法准确率、安全性、留存或整套产品能力。
也没有证据支持“所有营养计算都错了”：截图目标能量与三营养素克数按常用4/4/9换算约相符，可能只是取整差异。真正应追查的是食材/成品基准、实际份量、来源覆盖和个体目标依据。比如“大米饭”的展示值需要核对生熟和数据库条目后才判断，不按菜名猜一个标准热量来指责对方。
3. 我们已经有什么，下一步只补什么
目前不应重做完整小程序、PC管理后台或支付/绑盘系统。
| 现有资产 | 本次核对 | 具体复用 | 不把什么当已完成 |
|---|---|---|---|
| ai_app餐品详情 | 源码有“拍照添加”、相机/相册入口 | 沿用餐品详情的拍照记录位置，不改回早期AI问答上传入口 | 按钮存在不证明识别/跨系统人员映射已接通 |
| store膳食记录页 | foodRecord.vue有三餐数据、能量展示及FoodRecord调用，按人员/日期取数 | 继续在原页补原图/逐菜/修正/差异内容，不新增一级PC菜单 | 本地分支源码不等于当前生产状态 |
| 饮食记录v0.5 | 最新规则为分图明细、进餐时间、三层匹配、单工作表Excel；体重本期暂缓 | 作为事实记录和专业纠错的基础链 | 不把历史新增体测/AI问答上传方案重新带回本期 |
| VWCG-1361 | 已交接郭东伟，交接记录明确唯一执行入口 | 先验收这条链，新增需求先作后续增量评审 | 本轮不改该任务范围，不并行重写其代码，也不声称已上线 |
| 45项产品需求与双端概念原型 | 有睡眠、食动、状态、授权、阶段解读等合成演示 | 保留目标结构和交互参考 | 我们的概念PC不替代已经选定的store实系统原页 |
| 阶段营养师资源 | 可有阶段讲座与数据解读 | 审核首批规则、看异常、做周期解释 | 不承诺每天一对一或实时专业值守 |
4. 第一版只增加三个服务动作
饭前：给两套本食堂确实能选的搭配
入口建议放在现有首页一张“这一餐怎么选”卡片，连接现有餐品详情。它是一张完成任务的卡片，不是再建一个全新菜单系统。
卡片示例（虚构业务情境，不是个人处方）：
今天在A餐厅吃午餐。按你已确认的“增加餐食多样性”目标，提供两套可供应搭配。可以换菜；每套说明适用条件、可选份量和当前价格。没有可靠份量或价格资料时就明确缺项，不假报精确总量。
生成顺序固定：本人授权和已确认限制→餐厅/餐段/供应→目标及必要偏好→已知实吃与活动背景→合适菜品组合→规则校验→展示。价格、窗口、售罄、过敏/限制是硬约束，模型不能编造。一般饮食偏好无需等完整体检或全品牌可穿戴接入后才提供基础选择。
营养师先审一小组可复用规则和菜单模板；系统用确定规则筛选组合，AI负责把理由说清楚。样例建议“今天菜单里的蔬菜、主食和合适蛋白来源怎么搭配”，不是先让大模型自由生成一份食堂买不到的菜谱。
饭后：自动形成已有证据，只有歧义才确认
食堂已授权取餐/称重事件优先复用；外食沿用正在交付的拍照链。取餐、照片识别与实吃确认不同：取餐能说明拿了什么，照片能提供候选食物和估计份量；没有剩餐或本人确认，不能把它包装成精确摄入。
保持v0.5“三层匹配”：菜品库→食物成分表→外部AI库；首次可靠命中后停止，未命中/基准不一致进入待处理。对模型给出的未知油盐、重量保留不确定性；人工修改后新AI结果先当候选，不能覆盖当前值。
本人看到“已记录哪些、还有哪些未知”；营养师在原PC页看原图、逐菜、时间、估计、来源与修改历史。修正一次，手机、PC和导出使用同一版本。
下一餐：把差异变成一项能做到的调整
只有已知记录足以支持时，才在下一次可行动窗口给一个具体选择。做到了就结束本次，不重复催；做不到则处理缺菜、时间不合适或份量不适等障碍。不能用“午餐吃多了”自动触发跳餐或补偿性运动。
首版只启用一个提醒主题：“下一餐的搭配选择”。补充一条可查看的数据待确认事项，不把它变成反复推送。频次建议先限定每天最多一次普通主动触达，由用户选时段/关闭；这是待试点冻结的产品参数，不是医学要求。未取得通知渠道许可时，只在站内卡片展示，不跨渠道追催。
医疗复查继续独立管理。体检结果可以约束适用范围，但临床建议由相应专业人员确认；不让餐食行动结案替代医疗跟进。
5. 最小数据合同，比增加AI模型更重要
| 对象 | 最小可用字段 | 缺失时怎样处理 |
|---|---|---|
| 本人关联 | 组织、内部人员ID、会员ID映射、本人授权与版本 | 关联不明不合并，不能按姓名猜同人 |
| 供应菜单 | 餐厅/窗口、日期餐段、菜品ID、可售状态、更新时间；若展示价格需实际价格 | 无供应时不给“可点”承诺；可用运营手动维护先验证 |
| 菜谱基准 | 配方版本、原料与用量、可食部/生熟状态、出成重量、营养来源和质量状态 | 不同基准不直接相乘；缺资料只做受限结构选择或人工补齐 |
| 饮食事实 | 原事件/照片ID、本人、进餐时刻、食物/份量、来源、确认层级、修改版本 | 无份量不精算，晚到记录重评待发建议，重复事件不重复累计 |
| 行动候选 | 当前目标、依据事件/菜单/规则版本、适用窗口、两套组合、替代选择 | 无适用选项时说明原因，不“凑两套” |
| 提醒反馈 | 主题、许可、发送/抑制原因、完成/稍后/不合适、下次评估条件 | 没回复是未知；已完成/已撤权/过期/售罄时取消未发动作 |
计算必须有可重算口径。若菜谱营养总量E、成品可食总重W都经确认，则每100克估计为E÷W×100；个人取用m克的估计为E÷W×m。这里仍是食物模型估计，包含烹调与剩餐的不确定性，不能叫实验室测得的实际吸收量。
6. 交付分三段，每段都能验收
以下是规划估算，前提为一个已同意试点的点位、两餐段、少量可靠菜单，有前后端/测试投入和营养规则审核。具体工期由现有任务负责人据接口结论确认；不覆盖原任务排期，不承诺“本周五上线”。
| 顺序 | 交付包 | 责任及依赖 | 通过条件 |
|---|---|---|---|
| 第0段：先验事实链 | 优先完成并验收VWCG-1361已有范围 | 郭东伟按现有任务推进；产品/测试配合 | 图片→分图逐菜→三层匹配→人工修正→单表导出；人员/权限/时间一致，不能用样例通过替代真实联调 |
| 第1段：菜单和口径准备，建议3–5工作日 | 一个点位约10–20道试点菜的供应、配方和基准确认；营养模板与拒绝规则 | 餐厅运营/营养负责人/数据人员；需真实菜单样本 | 试点菜关键字段齐或明确禁止精算；每条已启用规则有审核者与反例；如果做不到先人工维护，不扩场景 |
| 第2段：一餐选择与下一餐调整，建议两个5日迭代 | 第一次：两套组合/换菜/缺失降级；第二次：实吃版本联动/提醒抑制/反馈 | 前后端与测试；第0段事实接口可用，不另造相同链路 | 菜品售罄、限制、错人、重复、修正、已完成、撤权、未许可均按下述测试断言工作 |
| 第3段：14天可用性试验 | 10–20名自愿健康成年人，观察午餐选择及下一餐 | 产品/运营组织，营养师阶段解读；不默认为有招募权限 | 看真实可执行性、选择时间、记录负担、持续使用、专家工时；不宣称短期健康疗效 |
14天是本次餐食功能试验，与原28天整体服务建议分层；没有替用户决定正式收费周期。整体产品方向继续保留，第一轮只验证这三个动作。
7. 验收时拿这些反例测试，不看“大屏有多满”
- 供应：某道菜售罄，旧推荐必须失效；无可靠替代就说明暂无合适组合。
- 个人限制：相同菜单、不同已确认限制，输出不同组合或拒绝，而不是只换名字。
- 缺记录：没有早餐记录不能说早餐摄入0，更不能推导晚上要补齐固定热量。
- 基准重量：生料、熟菜、可食部不明时不能假装单位一致；可追到成分及配方版本。
- 重复与修正：同一照片重传不多算；人工修正影响后续安排，原识别保留。
- 行为证据：取餐、识别、实吃确认、剩餐分开；摄入覆盖不全时周变化必须显示不足。
- 提醒：用户已选好、已完成、稍后、关闭或撤权，队列不再照旧发送；模型失败先显示事实，不堵菜单。
- 隔离：A的数据和计划不能进入B的页面；机构负责人不能默认查看个体体检结果。
- 资源：所有“营养师已审”和实际场次有真实人员记录；没有排期不得生成已预约状态。
- 商业：不买营养品的用户也能完成整条服务；不为了销售商品篡改建议排序。
功能验收中以上关键错误应为0；真实负载、通知延迟、并发和可靠性指标须在开发前冻结。原型截图不能证明这些后端条件。
8. 用什么证明比现在更好
不做主观百分制排名；本次截图没有竞品实测漏斗或留存数据。可用同一真实菜单、同一目标与限制，为用户提供“菜单列表方式”和“具体组合方式”完成同一选择任务，交替顺序，记录时间、正确理解、适用性和失败原因。
试点建议观察四项：
- 用户是否能在约一分钟内找到愿意吃且符合已确认限制的搭配；这是一项待验证体验目标。
- 推荐组合在实际餐段可供应的比例；价格/供给有变化时是否及时失效，而不是只统计已点击。
- 饭后需要用户额外操作多少次，是否能在少量确认后保留可信记录；未知不能自动填满。
- 用户是否再次使用、接受下一餐调整，以及运营/营养师每人每周花了多少时间。
必须分开报告个人偏好、过程指标、身体测量与医学检查；减重或短期状态变化不能直接归因于一次推荐或某款商品。成交/续费必须是真实交易，成本包括营养师审核、菜单维护、接口、模型、客服与获客；本次没有这些实数，不推算市场规模或利润。
9. 康比特如何形成自己的优势
康比特已有营养方法、商品供给与数字餐厅资源，但是否能形成优势，需要在一个真实点位证明三件事：建议能买到、记录靠得住、后续调整让用户继续愿意用。
先把服务嵌入既有餐厅和小程序：售前演示一条完整用餐任务；签约时明确菜单维护/接口/专家责任和可验收范围；交付时用同样的反例验收；运行后记录真实使用和工时。商品按需接入，后续再评估周期服务收费，不能把“查热量免费、卖营养品赚钱”当默认结论。
新开普的交易、设备和校园渠道是需要尊重的基础能力。我们优先争取的是营养决策与持续执行的服务价值，不重造支付、完整ERP、社区投票或全品牌可穿戴平台。现有客户能否购买新增服务仍需核实买方、预算和验收，并不因原来买过设备就自动成立。
10. 本周可直接启动的工作与边界
建议本周先冻结一张真实菜单、一个本人数据关联方式、一个膳食记录接口和一组审核过的选择规则。 这四样齐备后才能把“帮你选这一餐”排入可验收迭代。
- 产品：带本报告审三张卡的任务流，确认试点点位与可服务人群；明确必做/不做。
- 数据/营养：核对试点菜谱的基准与替代规则；列出不适用和资料不足反例。
- 郭东伟与对应技术人员：沿VWCG-1361现有范围完成事实链；确认后续扩展需要的接口，不在本轮另行指派或加任务。
- 运营：确认谁维护菜单和售罄状态、谁承担阶段解读、实际工时与试点参与许可。
- 测试：按本报告10个反例形成合成数据用例，再以授权真实环境验证。
详细增量执行契约见一餐决策执行切片，追踪现有REQ-R30～37等，不重编号既有需求。当前是落地方案完成，真实实施DoR仍待菜单/身份/专业规则/接口/性能条件关闭。未修改郭东伟任务、未联系聊天参与人、未登录或操作竞品账户、未覆盖此前公开原型。