我写了个“低卡饮食推荐”Agent，这才是 PM 的修养。这话现在说有点虚，但当时是真被逼出来的。2022年春天，上海那波封控把我钉在家里，健身房去不了，外卖也点不顺畅，体重和焦虑一起往上飙。我意识到之前搞的那些花里胡哨的私域流量工具，在生存问题面前屁用没有。身体是第一生产力，这话以前当口号，现在成了血淋淋的教训。我得给自己弄个能用的东西，一个能根据手头食材、冰箱库存和我的运动量，实时推荐低卡食谱的玩意儿。
这玩意儿一开始就是个Excel表格加几个IF函数，蠢得要死。但PM的毛病犯了，总觉得能做得更“系统”。我开始琢磨，一个真正的饮食推荐系统需要哪些数据实体。用户画像、食材库、食谱、营养元素、进食记录，还得关联上运动消耗。脑子里过了一遍，发现这他妈不就是个小型ERP吗？但这次不一样，我不是为了接单或者忽悠客户，我是为了解决自己的具体问题。这种驱动力，比之前任何外包项目都强烈。
我摊开笔记本，开始画ER图。核心表就五张。`user_profile`表，除了基础信息，关键字段是`daily_calorie_target`（每日热量目标）、`activity_level`（活动系数，用1.2到1.9的浮点数表示静坐到高强度运动）、`dietary_restriction`（饮食限制，JSON格式存，比如`{“lactose_intolerant”: true, “vegetarian”: false}`）。这张表是动态调整推荐的基础。
`ingredient_library`表，这是我花时间最多的。字段包括`name`、`category`（蔬菜/肉类/主食等）、`calorie_per_100g`、`protein`、`carbs`、`fat`，还有个`common_unit`（常用单位，比如“个”、“片”、“碗”，方便快速记录）。数据从薄荷营养师和几个健身APP的公开数据库里爬，清洗的时候发现同一食材不同来源的热量能差出20%，最后只能取中位数，标注上数据来源可信度。
`recipe`表是枢纽。`name`、`cooking_method`（煎炒烹炸）、`total_calorie`（计算得出）、`ingredient_list`（这里没用关联表，直接存了JSON数组，每个元素包含`ingredient_id`、`quantity`、`unit`，为了查询性能牺牲了点范式）。还有个`tags`字段，用逗号分隔存“快手菜”、“高蛋白”、“低碳水”、“辣”这种标签，方便过滤。
`meal_log`表记录每次进食。外键关联用户和食谱，但更常用的是直接记录`ingredient_consumption`（也是一个JSON数组，记录吃了哪些食材及其分量），因为很多时候就是随手抓点东西吃，没有固定食谱。`logged_at`（时间戳）和`estimated_calorie`（根据食材库实时计算）是关键。
`exercise_log`表相对简单，记录运动类型、时长、`estimated_calorie_burn`（消耗热量）。这张表和`meal_log`联合，就能粗略算出当日的热量缺口或盈余。
表结构画出来，我自己都乐了。这不就是最经典的CRUD吗？但妙就妙在，当这些数据流动起来，通过一些简单的规则引擎（比如“如果今日蛋白质摄入不足，优先推荐高蛋白食谱”、“如果冰箱里菠菜快坏了，提高含菠菜食谱的排序权重”），它就开始有“智能”的雏形了。我用Python的Flask快速搭了个后端，前端就用最土的HTML表单提交，没心思搞React那一套。第一个版本跑起来，我输入“鸡胸肉200克，西兰花一颗，糙米有剩饭”，它给我返回了“西兰花炒鸡丁配糙米饭，预估热量420大卡，蛋白质约35克”，那一刻的满足感，比之前搞定一个几十万的订单还实在。
这不是什么高大上的AI，它甚至没用到机器学习。但这就是产品经理的修养：在资源极度受限（时间、技术、数据）的情况下，用最清晰的数据结构定义问题，用最小的可行产品解决问题，并且让自己成为第一个深度用户。这个粗糙的Agent，后来成了我理解AI Agent思维链的原始模型。所有复杂的系统，源头可能就是这么几张表，和一个快被现实逼疯的、想要自救的产品经理。
