蚂蚁上树有肉，排饮食计划时却要先算碳水

这几天在调整产品的饮食分类，发现现有的荤素标签有些地方不太好处理。比如蚂蚁上树，该怎么归类？里面有肉，算荤菜好像也说得通，但主体是粉丝，主要提供的是碳水。如果一顿饭已经配了米饭，再因为缺一道荤菜把它补进去，就可能把碳水又叠了一份。

问题不在于它能不能叫荤菜。平时点菜，看到里面有肉末，把它放在荤菜里，很容易理解。可产品拿这个标签做的事不同：它要根据用户选的搭配，往一顿饭里安排菜。标签一旦参与选菜，就不只是方便查找的目录了。

我想弄清楚的是，我们究竟在给什么分类。是菜名，是这道菜主要提供的营养，还是它在这顿饭里承担的位置？这三个问题看着接近，答案却不一定相同。只讨论蚂蚁上树算荤还是算素，讨论到最后，也可能没碰到真正需要改的地方。

有一点肉，不等于补上了一道蛋白菜

旧版饮食计划按几荤几素组织搭配。这个说法熟悉，用户不用学，选择起来也直接。麻烦是，菜谱里的混合菜很多，肉、蛋、豆制品、蔬菜经常放在同一道菜里。用两类去装，边界总会冒出来。

五月这次调整，红绿白的方向是老板提出的，参考的是维小饭的餐盘规则。产品里的名字随后定成了肉蛋白质、蔬菜纤维、主食碳水和汤。它想回答的，不再只是菜里有没有肉，而是这顿饭的几个位置有没有安排上。

名字换了，原来的标签不能直接换个颜色继续用。豆制品在这套组织方式里放进蛋白类，菌菇、海藻放进蔬菜纤维类，粉丝和薯类放进主食碳水类。这里说的是项目用于排计划的分类，不是要靠四个格子讲完食物的营养。

蚂蚁上树就很适合拿来检查这次变化。方案里给它的表达是主碳水、辅蛋白。肉末没有被忽略，但也不能因为存在肉末，就让它顶掉本来想补的主要蛋白位置。一个主标签决定先把它放到哪里，辅助标签留下它还包含什么，至少比在荤素之间反复改判更贴近这次任务。

不过，辅标签也不能理解成多送了一个完整位置。假设用户选了一份主食和一道蛋白菜，蚂蚁上树带着两个标签进来，不代表它可以一次把两项都填满。要不要抵扣、按多少算，还需要明确的份量和菜谱依据。我不想让页面看起来配齐了，实际上只是同一道菜被数了两次。

这次原型里另一处变化，是主食独立成位。

旧版有些主食安排放在后台处理。改版后，用户能直接选主食碳水的份数，包含半份这样的选项。它和肉蛋白质、蔬菜纤维、汤一起出现在餐次配置里，早餐、午餐、晚餐也用了同一组结构。

把主食摆出来，多了一个需要用户理解的选择，但我觉得这个选择不能完全藏着。前面已经选了米饭，后面又选到粉丝类的菜，产品就得把两者放在同一顿饭里看。不能一边按主食推荐，一边按菜名补位，最后各自都符合规则，合起来却重复了。

沿着这个例子继续推，用户换菜时也要重新检查。假设原来是一道主要提供蛋白的菜，换成蚂蚁上树，菜的数量没有变，餐盘结构已经变了。如果换菜只保证从菜库里换出另一道，前面认真选择的搭配就可能失去作用。这是分类调整后值得继续核对的交互，不是给菜卡加个标签就算结束。

套餐快选仍然有用。不想逐项调的人可以先选一个搭配，再改其中一项。只是套餐名字不能替代实际内容：选了均衡套餐，不意味着后面无论怎样换菜都仍然均衡。对我来说，快捷入口可以省操作，不能把操作造成的变化也一起省掉。

选菜流程里，方案把候选池过滤放在了前面。先依据慢病禁忌、过敏原等规则排除不合适的候选，再按主要属性找相应的菜，之后才让 AI 在过滤后的范围里考虑七天轮换、口味、季节这些因素，后面还有软约束评分与营养红线检查。

我更在意这个顺序，而不是最后菜单由谁写出来。假设一道菜命中了需要排除的过敏原，就不该因为它更符合口味、刚好能让一周不重样，又被挑回来。哪些是不能越过的条件，哪些是在可选范围内尽量做好，得先分开。

分类在这里是两边共用的基础。规则按它筛，AI 按它挑，页面还要按它告诉用户这顿饭配了什么。如果三个地方对蛋白类的理解不同，生成结果写得再自然，也掩盖不了前面没对齐的问题。尤其辅助标签很容易被用得过头：筛选时只表示含有，排餐时却被当成足够，意思就在中间变了。

这套流程现在还是方案。原型中的套餐快选、四个配置维度已经完成核心改造，但菜品归类的第二版字段仍标着待做，不能说正式算法已经按主辅属性在运行。字段能列出来，和菜库里的每道菜都能按同一标准判定，是两段工作。

后面真正费工的，可能正是那些没法只看菜名的地方。同样叫蚂蚁上树，粉丝和肉末的用量会不同；同样叫西红柿炒鸡蛋，配比也未必相同。作为产品推演，我会想先确认标签对应的是哪份标准菜谱、什么份量，再讨论推荐时怎样使用。否则给一个名字贴得越确定，越容易忘记名字下面还有差异。

我不觉得换成四类以后，边界菜就都解决了。汤里也可能有肉、有淀粉，混合菜也不会因为多了辅助标签就自动算清。新的表达只是让问题有了更合适的位置：该问主要角色的时候，不再被有没有肉带着走。

接下来检查这版方案，我更愿意拿一顿已经配好米饭的餐来问：再放进蚂蚁上树，哪里需要跟着变？是主食份量，是蛋白位置，还是需要给用户一个重新搭配的提示？这些问题比单独问它属于哪一类更具体，也更接近用户最后看到的安排。

用户不一定关心我们怎样给菜分类，但会照着菜单准备一顿饭。分类有没有用，最终得回到那里看。至少这次，我不想让那一点肉末，替整盘粉丝决定它在饭桌上的位置。