清晨，我们带着电脑、答辩材料和反复调试过的“食智采”系统从学校出发，赶赴2026“创客中国”（青岛赛区）暨第十二届“市长杯”首届OPC创客赛现场。一路上大家没有太多闲聊，各自对着电脑核对PPT和演示流程，把采购核算、供应商对接、客源分析、营销生成四个模块重新顺了一遍，生怕现场某一个环节出现纰漏。

抵达赛场后，候场区已经聚集了不少参赛团队。有人站在走廊里掐着时间练习路演，有人还在修改PPT。我们找了一处空位，再次导入昨日订单、菜品配方和库存数据，确认采购建议能够正常生成。随后检查供应商消息推送、ECharts客群分析图表以及营销Agent的文案和配图输出。直到整套流程完整跑通，悬着的心才稍稍放下。

此前做项目的一幕幕也在这时不断浮现。最初走访高校食堂时，我们发现，采购人员每天仍需依靠订单和经验估算食材用量，供应商沟通则要逐一整理、发送；到了经营端，顾客偏好、消费时段和菜品热度分散在大量销售数据中，而门店又很难持续为小红书、抖音等平台制作营销内容。正是这些真实问题，让我们逐渐搭建起“食智采”从采购端到营销端的完整闭环。

轮到我们上场，屏幕上的五分钟倒计时随即开始。介绍结束后，我们直接进入实操：系统读取订单、配方和库存，自动核算第二天的食材采购量；采购结果按供应商分类，随即生成包含品类、数量、配送时间和地点的标准化消息。切换到客源分析页面，菜品热度、口味偏好、价格区间和消费时段依次呈现在图表中，AI进一步生成客群画像与经营建议。最后，营销Agent根据热销菜品完成趋势分析，再生成适配小红书、抖音和公众号的差异化文案与配图。

我印象最深的是，其中有一位评委问道：“你们四个模块里，真正核心的是什么？”我们没有只指向某一个功能，而是回答，“食智采”真正想解决的是数据在餐饮经营中的流转问题。订单和库存进入采购，采购结果进入供应商沟通，销售数据形成客群画像，热销菜品再进入营销内容生成。

走下台后，我们第一时间把评委提出的问题重新记进项目文档。此前无数次修改代码、调试接口、调整提示词，关注的是功能能不能跑通；真正站到比赛现场，才发现评委更关心的是它能否替经营者少算一次表、少发一次重复消息，真正进入每天的经营流程。

虽然五分钟的路演很短，但从一份订单，到采购表、供应商消息、客群画像，再到最后生成的营销内容，我们终于把此前分散的功能完整串了起来。比赛展示的是已经做出来的部分，而现场留下的问题，也指向了接下来仍需继续打磨的方向。让AI不只停留在演示页面，而真正走进餐饮经营的一线，才是“食智采”继续做下去的意义。