汇报部门：数字体育科技事业部
汇报人：姜阳
适用场景：2026 年半年度策略专项会产品研发补充稿
证据边界：5 个专利、10 个软著、硬件方向、AI 营养和 AI Agent 工程师转型为内部战略口径；正式对外、投标或经营承诺前，需要补齐证书编号、权利状态、软著名称、硬件型号报价、接口验证、试点项目和人效数据。
我从产品研发角度补充。今年的重点不能再停留在“去年我们要补结算、补食安、补进销存”这条线上。那些仍然要做，但今年更关键的问题是：我们已经有一定技术储备，接下来要把这些储备转成客户看得见、销售拿得出、投标用得上、交付能复用的产品能力。
今年产品研发的主线，我建议概括为三句话：
第一，技术储备要产品化。5 个专利、10 个软著不能只放在证书文件夹里，而要绑定到智慧餐厅的具体能力、招投标技术参数、客户演示话术和标准产品包。
第二，硬件体系要重新定义。现有硬件要做横向对比，找到更低成本、更好对接、更稳定交付的供应商；未来硬件要结合食安行业法规和监管难点来设计，不是为了堆设备，而是为了提高效率、减少人工台账、补齐监管证据链。
第三，AI Native 要落到团队和产品里。AI 不能只用于写材料，而要进入需求、研发、测试、交付、知识库和营养服务本身。团队要逐步从“会用 AI 工具”转向“能和 AI Agent 一起交付产品”的工程化能力。
我们现在已经具备 5 个专利、10 个软著的技术储备。下一步不是简单在汇报里写“我们有专利和软著”，而是要回答三个问题：
因此，建议马上建立一张“技术储备到产品能力”的矩阵，把每个专利、软著对应到四类能力：
| 技术储备转化方向 | 对应产品能力 | 对销售和投标的价值 |
|---|---|---|
| 营养算法与 AI 营养 | AI 营养建议、带量食谱、营养档案、吃动平衡 | 形成康比特区别于普通智慧食堂厂商的专业壁垒 |
| 食安监管与证据链 | 留样、晨检、消毒、农残、明厨亮灶、监管台账 | 支撑食安监管类项目的技术响应和控标参数 |
| 结算与数据采集 | 称重结算、菜品识别、人员识别、补贴支付 | 支撑前厅高频入口和数据沉淀 |
| 进销存与成本管理 | 采购、验收、入库、出库、库存、成本核算 | 支撑客户降本增效和后厨管理闭环 |
这件事的价值在于，技术储备一旦和产品模块、投标参数、证据材料绑定，就不再只是“研发成果”，而是能帮助销售讲优势、帮助投标控参数、帮助交付做验收的业务资产。
今年硬件第一条线，是对现有硬件做系统梳理。我们不能每个项目都临时找设备、临时问接口、临时谈价格。这样交付慢，成本不可控，也很难形成标准包。
现有硬件要按“功能、价格、接口、稳定性、售后、交付风险”六个维度做横向对比，至少覆盖结算设备、称重设备、人脸识别、菜品识别、留样设备、明厨亮灶、环境监测、消毒/农残类设备。每类设备都要形成三张表：
这条线的目标很明确：同等功能下找到更低成本、更好对接、更容易交付的硬件组合。硬件不是越贵越好，也不是谁先到项目现场就用谁。硬件要为产品标准化服务，为毛利和交付效率服务。
短期看，现有硬件横评可以降低项目成本；中期看，可以形成教育版、企事业单位版、食安监管版的硬件推荐包；长期看，可以让我们在招投标里形成“软件 + 硬件 + 服务”的整体控标能力。
今年硬件第二条线，是面向未来的硬件规划。这个方向要结合我对食安行业的理解来看。
过去很多食堂没有出入库秤，没有晨检仪，也没有把留样、消毒、农残、温湿度、人员健康、采购验收这些动作真正设备化、数据化。但法律法规和监管要求一直存在，客户也一直有压力。只是过去靠人工台账、纸质记录、拍照留痕在勉强解决。
这恰恰是未来硬件的机会。我们不应该把硬件理解为“多卖几台设备”，而应该理解为“把法规要求和监管难点变成自动采集、自动留痕、自动预警、自动生成台账的数据入口”。
未来重点可以围绕几类硬件机会展开：
| 监管难点 | 未来硬件方向 | 产品价值 |
|---|---|---|
| 食材采购验收靠人工记录 | 入库秤、验收秤、扫码验货设备 | 自动记录供应商、食材、重量、批次和验收结果 |
| 出库和成本核算不准确 | 出库秤、领料称重设备 | 把实际消耗和菜品、食谱、库存、成本关联起来 |
| 晨检流于形式 | 晨检仪、人员健康采集设备 | 自动记录体温、健康状态、上岗人员和异常提醒 |
| 留样记录不完整 | 留样称重/拍照设备 | 自动记录菜品、重量、时间、责任人和留样证据 |
| 消毒、农残、温湿度难监管 | 检测设备、传感器、环境监测设备 | 自动生成监管台账，减少补录和漏录 |
| 监管部门难以实时掌握风险 | AI 摄像头、异常识别、监管大屏 | 从事后查台账升级为过程预警和风险管控 |
这条线的核心目的，是提高效率，管控监管难点。客户不是为了买硬件而买硬件，而是为了少填表、少漏项、少被罚、少扯皮、少出食品安全事故。
今年还有一个关键问题：食安硬件、进销存、结算和营养不能各做各的。真正有价值的是把这些数据串起来。
举例来说，出入库秤采集的是食材重量，进销存记录的是采购和库存，前厅结算记录的是实际消费，带量食谱记录的是计划摄入，营养系统计算的是能量、蛋白质、脂肪、碳水和微量营养素。如果这些数据打通，就可以形成“从采购到餐盘再到营养摄入”的闭环。
这就是康比特做 AI 营养的机会。普通智慧食堂厂商只能告诉客户卖了多少饭、库存还剩多少；我们应该进一步告诉客户：
所以 AI 营养不是一个孤立的“AI 营养师聊天框”。它应该成为智慧餐厅的数据中枢，把食材、菜品、人员、消费、库存、食安、运动和健康数据连接起来，形成可解释、可干预、可复购的营养服务。
今年产品上可以先做三个可展示场景：
| 场景 | 输入数据 | AI 输出 |
|---|---|---|
| 带量食谱 × 采购反算 | 食谱、人数、食材、库存、出入库称重 | 自动反算采购量、缺口和成本 |
| 个人/群体营养档案 | 人员、消费记录、菜品营养、运动/体质数据 | 摄入分析、结构偏差、营养建议 |
| 食安 + 营养联合预警 | 食安台账、硬件采集、库存、消费和营养指标 | 风险提醒、异常解释、整改建议 |
今年团队建设也要重新定义。我们不能只说“大家要会用 AI”，而是要明确团队要转向 AI Agent 工程师能力。
目前已经看到一些成效：会议纪要可以进入知识库，历史资料可以通过 RAG 被重新利用，策略稿、方案、竞品分析、任务拆解、测试用例和部分代码可以由 Codex 辅助生成。相比过去完全靠人工整理，AI 已经在资料整理、方案生成、代码辅助和知识沉淀上提高了效率。
但现在的问题是，这些能力还偏个人使用，缺少稳定流程。下一步要把 AI 用法工程化，变成团队统一的交付方式。
建议把团队 AI Native 落地拆成四个层次：
| 层次 | 当前状态 | 下一步动作 |
|---|---|---|
| 资料层 | 会议纪要、项目资料、策略资料已能进入知识库 | 建立数科产品资料、硬件资料、证书资料、竞品资料的固定入库规则 |
| 研发层 | Codex 可辅助需求拆解、代码生成、测试生成 | 建立“需求 -> 任务契约 -> 代码 -> 测试 -> review -> 复盘”的 AI 研发闭环 |
| 产品层 | AI 可辅助方案、报告、竞品分析 | 建立产品包、报价包、演示包、控标包的标准生成流程 |
| 组织层 | 个别人效率提升明显 | 让产品、研发、测试、交付都按统一证据路径和验收指标与 Agent 协作 |
所谓 AI Agent 工程师，不是只会提 prompt，而是要能把业务问题拆成 Agent 可执行的任务，把上下文、接口、数据、测试、验收和复盘都准备好，再通过 AI 完成交付加速。
今年 AI Native 的落地，要避免停留在概念上。我建议至少用四类指标来证明成效。
第一，研发效率指标。比如食安监管、进销存或硬件接口适配模块，传统模式需要多少人月，AI 辅助后实际用了多少人月，代码 review 通过率如何，返工率如何。
第二，交付效率指标。项目方案、测试用例、用户手册、培训材料、验收材料能否自动生成初稿，人工修改比例是多少，是否减少项目经理和交付同事的重复劳动。
第三，知识复用指标。同类项目再次出现时，是否能从历史会议、项目资料、硬件接口、证书材料和竞品分析中快速生成可用方案，而不是每次从零开始。
第四，产品价值指标。AI 营养是否真的进入客户可感知功能，是否能支持带量食谱、采购反算、营养档案、健康建议和食安营养联合预警，而不是只停留在内部提效。
如果这四类指标跑通，AI Native 才不是一句口号，而是会同时改变产品能力、研发方式、交付效率和客户价值。
这里还建议补一张“模块复用率和毛利表现”台账。朱总要看的不是我们讲了多少模块，而是这些模块到底覆盖了多少项目、是不是能复用、毛利表现好不好、哪些地方反复定制。当前覆盖项目数和覆盖率需要从项目台账、合同和验收资料回填，口径建议统一为：覆盖率 = 覆盖项目数 / 纳入统计的智慧餐厅项目总数。
| 模块 | 覆盖项目数 | 覆盖率 | 毛利表现 | 高频定制点 | 后续动作 |
|---|---|---|---|---|---|
| 营养结算 | 待按项目台账补数 | 待测算 | 收入主力 | 支付、账户、补贴 | 标准配置 |
| 智慧食安 | 待按项目台账补数 | 待测算 | 毛利偏低 | 设备、施工、联调 | 硬件白名单 |
| 进销存/智慧采购 | 待按项目台账补数 | 待测算 | 毛利较好 | 库存、采购、成本 | 学校版/配餐联动 |
| 软件开发 | 待按项目台账补数 | 待测算 | 毛利高 | 个性化需求 | 模块化开发 |
| 施工/硬件 | 待按项目台账补数 | 待测算 | 毛利低 | 现场差异 | 供应商管理 |
这张表的作用，是把“可复制”从口号变成管理动作：营养结算要尽快标准化配置，食安和施工硬件要用白名单控制成本，进销存要沉淀学校版和配餐联动，软件开发要把高毛利能力模块化。后续只要每月回填覆盖项目数、覆盖率和毛利，就能判断数科业务到底是在做项目，还是在形成可复制的产品包。
下半年建议按 90 天做一个闭环。
0 到 30 天，先把底账建起来。完成 5 个专利、10 个软著的产品能力映射和控标参数矩阵；完成现有硬件供应商横评；列出食安法规和监管难点对应的未来硬件机会清单；确定 AI 营养三个演示场景；确定一个 AI 研发试点模块。
31 到 60 天，做出可展示资产。形成现有硬件低价替代白名单；选择出入库秤、晨检仪或留样称重设备中的 1 到 2 个方向做样机和接口验证；做出“带量食谱 × 采购反算”“营养档案”“食安营养联合预警”演示；用 Codex 跑通一个模块从需求到测试的闭环。
61 到 90 天，进入市场验证。用一个教育或企事业单位样板项目验证软硬件组合、AI 营养演示、控标材料和交付流程。验证指标包括硬件成本降低、接口联调周期、AI 节省人月、演示转化、客户反馈、投标参数可用性和售后问题数量。
本次会议建议拍板五件事。
最后，我建议今年下半年的产品研发不要再只说“我们要补系统”。今年要讲清楚：我们有什么技术储备，怎么转成产品壁垒；现有硬件怎么降本，未来硬件怎么从监管难点长出来；AI 营养怎么和食安、进销存、结算数据打通；团队怎么从会用 AI 工具，真正转向 AI Agent 工程师。只有这几件事落地，数科项目才会从项目交付，走向真正可复制的软硬件一体产品能力。