英国外卖点餐软件博客：把14种过敏原放进菜单里，而不是另开一张表格

表格维护过敏原，改一次菜单要改两处

这家点餐软件公司认为，用表格单独维护过敏原信息的问题不在花多少力气，而在结构：过敏原被当成菜单之外另一样要维护的东西，于是每次菜单变动实际上是两次变动，第二次往往被忘掉。三个月后新增一道特餐、换一个供货商、面包悄悄换成布里欧修，菜单动了，表格没动，这份本该起保护作用的文件就不再准确。

把过敏原设在食材上，让菜品继承

文章提出的做法是：过敏原是一种食材的属性，食材碰到的东西应当自动继承它。过敏原设在产品这一层，一道菜只声明一次含有什么，不必在每个用到奶酪的菜品上重新填一次“牛奶”，而是设在奶酪本身。同一道菜的大份和小份共用过敏原，规格不同不等于声明不同，应当从主产品继承下来。食材的过敏原信息变化时，只改一个地方，所有用到它的菜品跟着更新。

文章认为，这样做的差别在于过敏原数据会不会失效：用表格时，准确性取决于有没有记得更新每一个受影响的单元格；用继承时，准确是默认状态，要出错得主动去破坏它。

加料和替换会带进新的过敏原

文章指出，最容易漏掉的是加料和替换：基础菜品的声明是对的，客人加了鳀鱼（鱼）、换了另一种奶酪、加了蒜香蘸酱，这一单的声明就不再正确，而没有任何环节拦下这些新增的过敏原。所以过敏原要挂在加料选项上，而不只是基础菜品上：“加奶酪”带牛奶，“换成布里欧修面包”带鸡蛋、常常还有芝麻。客人最终看到的声明应当反映他实际点的那一份，而不只是起点的那道菜。替换也一样，去掉麸质的饼底去掉了小麦，换一种酱汁可能加进大豆，两个方向都要看。

“含有”和“可能含有”是两回事

文章区分了两种诚实的说法：“含有”指这种过敏原是配料，是有意放进去的，是确定的事实；“可能含有”指它不是配料，但无法排除交叉污染，比如共用炸锅、共用台面、空气里的面粉，说的是控制不了的风险，不是配方。两者不能互换。把“可能含有坚果”当成整张菜单的通用免责声明，会让对过敏在意的客人学会忽略它；而漏标真实的交叉污染风险，是更危险的错误。文章认为有用的写法是具体的：这道菜含有 X，这道菜因为厨房的做法可能含有 Y。

文章列出过敏原数据出错的几种常见情形：新菜品上线却没有填过敏原信息；换了供货商，“同样”的食材可能带来不同的过敏原或不同的交叉污染风险，换供货商应当触发重新核对；配方微调没人记录，加了一种增稠剂、换了一种油、添了一样装饰，在厨房里是小事，在标签上是大事；加料选项漏填，一直挂在每一单上。文章认为，靠的不是格外勤快，而是一个短流程：菜品、食材、供货商或加料选项一变，过敏原数据就是这次变动的一部分，而不是事后的补充任务。