安徽部队（安庆支队）食堂大屏与营养需求差异分析及下一步行动计划

状态：内部决策稿，待 Jack / 项目负责人评审日期：2026-08-22 分析对象：用户提供的《需求调研8.19.docx》判断边界：本文只分析该文档覆盖的“大屏、菜谱营养、生日妈妈菜、加餐、宣传、带量食谱、意见反馈”范围，不代表安徽部队项目的完整合同范围、完整软件范围或最终工作量。

一、结论先行

这不是“标品完全不适用”的项目，也不是“改个大屏皮肤就能交付”。更准确的判断是：标品底座可复用，但当前需求属于中等偏大的项目定制。

按 15 个可验收需求原子拆分：

4 项可直接复用或以配置方式落地，占约 27%；
4 项可基于现有能力做小开发，占约 27%；
7 项需要新增业务逻辑、数据关系或非标硬件定标，占约 47%。

因此，直接标品匹配度约 25%～30%，平台与数据底座复用度约 60%～70%。差异最大的三块是：

“生日树—寿星—妈妈菜—提前提醒—点击查看”的完整业务闭环；
按预计就餐人数自动汇总菜品原料用量的带量食谱；
将本周意见定向交给下周值班厨师，并能回写到下周菜谱的运营闭环。

当前不建议直接进入开发排期或报固定总价。先完成项目 intake、98/100 寸触摸屏现场与型号定标、真实系统演示和 P0 原型评审，再拆出标品、项目配置、定制开发和待确认项。

二、这份文档已经说清楚什么

文档确认了以下业务意图：

食堂入口设置 90～100 寸触摸大屏；
展示当餐菜品、图片、名称和主要营养素，并兼顾周菜谱；
设置生日祝福及“妈妈菜”专区，关联人员库、菜谱和提前提醒；
周三、周六突出加餐，夜餐不进入主屏；
滚动展示“吃动平衡”等健康宣传内容，并允许食堂维护；
菜谱可导出 Excel；
按人数计算原料总量，形成带量食谱；
通过 iPad 等终端采集文字意见，供下周值班厨师改进菜谱。

文档没有说清楚的关键事项包括：项目是否就是现有 P025“安徽部队项目”、这是不是完整合同范围、部署网络与安全边界、人员数据来源与公开授权、妈妈菜的下单/采购/制作流程、加餐的数据定义、带量食谱的份量和损耗口径、评价是否必须实名绑定订单、验收时间与责任人。

三、逐项差异判断

ID	需求原子	当前标品/代码证据	差异判断	建议落地方式
R01	90～100 寸触摸大屏	标准目录当前明确的是 75 寸智慧数据大屏，未证明 90～100 寸触摸型号已定标	高差异，硬件非标/待定标	现场测量后冻结 98/100 寸型号、系统、触控、分辨率、安装和售后口径
R02	当餐约 8 道菜滚动展示	现有大屏有当餐菜谱、餐次切换和轮播框架	小差异	复用大屏接口，重排为适配 4K 触摸屏的菜品卡片和自动滚动
R03	菜品图片、名称、能量、蛋白质、脂肪等	菜品库与大屏接口已有图片和多项营养字段；现有大屏已有推荐菜营养展示	小差异	统一营养字段口径，增加缺失值降级，不把每 100g、每份和实际摄入混写
R04	周菜谱适配 90～100 寸布局	系统已有周/日菜谱与打印页面，但没有证据证明概念图布局已成标品	小差异	新做一套大屏周菜谱视图，保留滚动和一屏可读性验收
R05	生日树自动展示、多人滚动、点击详情	人员库已有姓名、头像、生日字段，但没有生日大屏业务模块	中等新增	新增生日查询 API、展示组件、隐私开关和多人轮播
R06	寿星与“妈妈菜”联动到主菜谱	当前未发现寿星专属菜、人员—菜品—日期关系模型	大新增	先定义妈妈菜业务对象、申报/审核/采购/制作/上屏状态，再决定表结构与管理页
R07	提前一周提醒、员工可手动查看	当前未发现生日妈妈菜提醒和待办流程	中等新增	新增提醒任务、通知对象、处理状态和手动查询入口
R08	周三、周六加餐突出，非传统菜品也适配	系统主餐次以早/午/晚为主，部分页面和数据库兼容夜宵；没有“加餐日/加餐菜”明确语义	中等新增	不用夜宵字段冒充加餐；新增加餐标签或独立餐次定义，并明确是否计入营养和备餐
R09	夜餐不在主屏展示	现有大屏主流程按早/午/晚取当前餐，夜宵未进入主屏核心轮播	基本可复用	明确过滤规则并补夜餐有数据时仍不显示的回归用例
R10	“吃动平衡”宣传滚动，食堂可更新	现有文章后台、已发布文章快照和大屏健康知识页面可复用	配置/轻改	建立专用栏目、轮播顺序、上下线和内网素材规范
R11	调整后的菜谱导出 Excel	现有菜谱支持查看、打印、PDF/营养卡输出；Excel 能力存在于其他报表，但未发现周菜谱专用 Excel	小开发	新增周菜谱 Excel 模板，字段、餐次、加餐标记与打印版保持一致
R12	按人数自动计算原料总量，形成带量食谱	菜品已保存食材组成和食材重量，具备计算底座；未发现“预计人数—份量—损耗—汇总—导出”的完整操作流	中大新增	先做配方完整度审计，再新增人数/份量/出成率口径、单位换算、汇总和 Excel
R13	iPad 采集文字意见，不只打分	H5/APP 已有就餐评价页面，支持环境、服务、菜品评分和文字 comment	基本可复用	iPad 直接使用 H5；补登录/订单绑定、匿名策略和触摸适配确认
R14	评价同步到后台	管理后台已有评价列表、详情和文字意见字段	可直接复用	增加项目权限、餐厅筛选和数据保留规则即可
R15	下周值班厨师查看本周意见并用于下周菜谱	当前后台能看评价，但未发现值班厨师、周汇总、处理结论和写回菜谱闭环	中等新增	首版先做周汇总和处理状态；是否自动写回下周菜谱放到第二阶段

四、标品能承担到什么程度

4.1 可以作为标品底座承诺

PC 管理系统、H5/APP 与大屏 Web 客户端；
菜品、菜谱、图片、食材组成和营养字段；
人员姓名、头像、生日等基础字段；
已发布健康文章的大屏读取；
就餐评价的文字提交、后台列表与详情；
基础餐次、菜谱打印和大屏轮播框架。

4.2 只能写成“基于标品定制”，不能写成开箱即用

90～100 寸触摸屏专用一屏布局；
每道菜的多营养素卡片及缺失值降级；
周菜谱大屏版与 Excel 版；
加餐高亮及夜餐过滤；
iPad 固定终端模式；
评价按周汇总给值班厨师。

4.3 当前不能作为标品承诺

生日妈妈菜完整闭环；
一周前自动提醒与处理状态；
按人数、份量、出成率和损耗形成可直接备餐的带量食谱；
90～100 寸触摸屏具体型号、安装、国产化/内网适配；
评价自动驱动下周菜谱优化。

五、建议的项目范围分层

P0：先做可演示、可评审的最小闭环

98/100 寸 4K 比例的大屏原型；
当餐菜品、营养卡、周菜谱、加餐标记、夜餐隐藏；
健康宣传轮播；
生日树和妈妈菜使用模拟数据展示完整交互；
iPad H5 评价入口与后台评价列表演示。

P0 的目标不是上线，而是让客户一次性确认页面信息架构、操作方式和业务定义。

P1：首期上线范围

大屏页面及真实菜谱/营养数据接入；
生日人员查询、隐私开关、妈妈菜登记和上屏；
加餐标识与夜餐过滤；
健康内容后台维护；
周菜谱 Excel；
iPad 文字评价、后台周汇总和处理状态。

P2：数据成熟后再上线

带量食谱自动计算与导出；
评价结论写回下周菜谱；
更复杂的个性化营养、人员提醒或采购联动。

带量食谱必须后置到配方完整度、标准份量、单位、出成率和损耗率通过数据门禁之后，否则系统会把错误配方放大成错误采购量。

六、未来 10 个工作日行动计划

时间	动作	责任角色	必须产出	通过标准
D1	冻结项目身份和范围	项目负责人 + 销售	一页项目 intake	明确客户单位、合同/售前阶段、本文是否完整范围、上线节点和决策人
D1～D2	现场与硬件实测	交付 + 供应商 + 客户信息化	点位测量表、网络/电源/安装照片、候选型号	冻结屏幕尺寸、触摸、4K、操作系统、浏览器、开机方式、壁挂承重和售后
D2	标品现状演示	产品 + 研发	真实系统录屏/截图和差异矩阵	客户看到现有菜谱、大屏、文章、评价和后台，不再只看概念图
D2～D3	数据审计	产品 + 营养 + 厨务	人员字段、菜谱、菜品图片、配方、单位完整度报告	生日/头像来源明确；菜品图片和核心营养素覆盖率可量化；配方缺失清单可追踪
D3～D5	P0 高保真原型	产品 + UI	98/100 寸主屏、生日详情、评价入口原型	客户逐块确认显示内容、滚动规则、点击路径、敏感信息边界
D5	业务定义评审	客户 + 项目 + 产品 + 营养	15 项需求确认表	妈妈菜、加餐、夜餐、带量食谱、意见处理五个核心口径全部有负责人和结论
D6～D8	技术方案与估算	研发 + 测试 + 交付	接口/数据模型、任务拆分、测试矩阵、粗估	标品/配置/定制/硬件分开估算；每项有验收、依赖和风险
D9～D10	商务与排期门禁	项目负责人 + 销售 + 研发负责人	范围确认书、BOM V0、里程碑计划	合同、报价、方案、功能范围、硬件型号和验收口径一致后才进入开发

七、必须向客户追问的 12 个问题

这份文档是否就是安徽部队/安庆支队项目的完整软件范围，还是只覆盖一块大屏？
项目处于售前、已签合同、交付中还是变更追加阶段？合同和验收节点是什么？
大屏确定为 90、98 还是 100 寸？必须触摸吗？操作系统、分辨率和安装高度是什么？
大屏运行在互联网、办公网还是隔离内网？是否允许访问现有服务器？
人员库由谁提供，姓名、照片和生日是否允许在公共区域展示？是否需要本人授权和隐藏开关？
“妈妈菜”由寿星、家属、食堂还是管理员申报？谁审核，何时截止，是否影响采购和成本？
“提前一周提醒”提醒谁，通过系统站内、短信、企业微信还是只在后台待办？
加餐是独立餐次、正餐内附加菜，还是福利食品？是否计入营养分析、库存和评价？
夜餐和夜宵是否同一概念？后台是否仍要维护，只是不在主屏显示？
带量食谱按计划人数、实际报名人数还是历史预测人数计算？份量、出成率、损耗率和单位由谁维护？
iPad 评价必须绑定人员和订单，还是允许匿名公共终端？如何防止重复提交？
“下周值班厨师”如何排班，谁必须查看，查看后是否需要处理状态、回复或菜谱变更记录？

八、当前决策建议

建议拍板

把该项目从“范围不清的灰色 intake”升级为“需求澄清与 P0 原型阶段”；
指定一个项目负责人统一收口客户、供应商、产品、研发、营养和交付；
先做真实系统对照和 98/100 寸原型，不先写完整 PRD、不先承诺固定工期；
首期优先保证大屏、生日妈妈菜、健康宣传和意见反馈可用；
带量食谱单独设置数据门禁，不与大屏页面同时承诺上线。

暂不拍板

不把概念图当成已实现界面；
不把人员表里有生日字段当成生日妈妈菜已经存在；
不把菜品有食材重量当成带量食谱已经可交付；
不把后台能看评价当成值班厨师改菜谱闭环已经完成；
不在 90～100 寸触摸屏型号、内网环境和安装条件未冻结前给出硬件交付承诺。

九、证据与置信度

A 级：用户提供的 DOCX；store、ai_api、ai_web 当前代码与数据库脚本；标准产品主数据。
B 级：项目控制库中的安徽部队既有状态、交付周报和 28 项目定标资料。
D 级：工期范围、项目身份对应关系、客户数据授权、带量食谱业务公式和硬件最终型号，均待确认。

当前结论对“需求与现有能力差异”置信度为中高；对“最终工期、价格和交付日期”置信度低，不能据此直接对外承诺。

十、评审状态

预期评审人：Jack、安徽部队项目负责人、产品负责人、研发负责人、营养/厨务代表、交付负责人。
当前决策：待评审。
评审重点：项目范围是否完整；P0/P1/P2 是否合理；生日妈妈菜与带量食谱是否为合同硬验收；是否同意先原型后估算。
已认可经验：待人审后填写。
否定反模式：不得把字段存在、概念图或相邻模块当成已交付闭环。