aicanyin
今年年初，我在一家连锁面馆搭了个餐饮AI智能体，负责点餐推荐、预订和售后。测试前我觉得这玩意儿接个API就能跑，结果头两周各种翻车，后两周才慢慢稳下来。今天把这30天的完整过程和测试方法写出来，给准备上AI的餐饮老板和同行一个参考。
为什么非要跑满30天？
很多AI厂商演示的时候特别好看，现场点菜、回答问题都很流畅。但真实餐饮场景根本不是那回事——饭点瞬时流量大、网络波动、客人说话带口音、还有喝多了问东问西的。如果只测一两天，根本暴露不了问题。我们这次定的目标是：连续30天不重启、不人工接管，看它到底能扛多久。这个思路有点像压力测试，但更贴近真实营业。
测试之前，我们设了三个指标：系统可用率（能正常响应的时间占比）、意图识别准确率（说话人本意判断对不对）、平均响应时间（从说完到回话的耗时）。每天跑完数据汇总成报表，每周Review一次。
30天测试结果：数据说话
整体来看，系统最终撑住了，但前期很狼狈。先说结果：30天里，AI智能体一共处理了18000多次对话，系统可用率99.2%，意图识别准确率94.7%，平均响应时间1.6秒。作为参考，我们同门店人工客服的平均响应时长是45秒。单看数字，AI确实比人快，但问题在于那0.8%的不可用时间几乎全发生在午市高峰，一卡就是十几分钟，客人排队点单就急了。
让我在意的是准确率。94.7%听起来还行，但放到18000次对话里，意味着有将近1000次出错。客人说”不要香菜”，AI给推荐了香菜牛肉饭，这体验就毁了。所以我后来把测试重点切换到了错误场景处理上——比起答得快，更重要的是答得对。
踩过的三个坑，比数据更值得看
靠前个坑是网络抖动。餐厅路由器一般，一到饭点就卡。AI智能体只要断线超过10秒，会话就丢失，客人得重新说一遍。后来改成离线缓存加上自动重连，才解决了这个问题。
第二个坑是多轮对话的上下文丢失。客人说”换成小碗”，AI得知道前面点的是牛肉面，但系统会把上一轮忘了，场面一度很尴尬。我们专门加了对话记忆模块，才让上下文连贯。
第三个坑是口音和同音词。”宽面”说成”宽miàn”还行，但”燃面”和”盐面”就乱了。后来我们把语音识别词库换成了当地方言模型，准确率提升了5个百分点。
这里说句题外话，中国烹饪协会会长杨柳在一次行业峰会上提过，餐饮行业正在从经验驱动转向数据驱动，我当时没太当回事。自己测完才发现，数据跑出来的稳定性和依赖经验的判断，完全不是一回事。
30天后的结论：可以用，但得留后手
测试结束后，我们没彻底关掉AI，而是让它和人工客服并行运行。AI处理标准化点单，遇到”变态辣””少油多菜”这类个性化需求就转给人。这个模式目前运行得很稳。
如果你也想测餐饮AI智能体，我建议至少跑一个完整的营业周期（包括周末和节假日），并且提前准备好模拟断网、突发大流量这些场景。稳定性不是靠厂商吹出来的，是自己跑出来的。测完你就知道，这玩意儿到底适不适合你的店。
