既然不想买服务器，我就在边缘计算上动脑筋。这句话说给2021年的我听，他肯定觉得我疯了，那时候满脑子都是云服务器集群、负载均衡、数据库读写分离，好像不搞个微服务架构都不好意思跟人打招呼。但现在，2023年，我连每月几十块的VPS账单都觉得刺眼，不是付不起，是觉得恶心。那种感觉就像你明明只想喝口水，却被迫签了一个自来水厂的年度维护合同。
身体管理这事，把我逼到了技术的墙角。去年体检报告上那几个飘红的箭头，比任何产品需求文档都更有压迫力。我开始用MyFitnessPal记饮食，记了三个月，数据一堆，屁用没有。它只会告诉我今天碳水超标了，但不会告诉我明天在成都这个遍地是油、满街是辣的地方，我他妈到底能吃什么。我需要一个能理解“微辣”、“免香菜”、“少油”且热量不超1800卡的东西，这不是一个卡路里计算器能解决的，这是一个结合了地域饮食文化、个人口味偏好和营养学的规划问题。
所以，我把问题拆了。服务器？不买。核心逻辑跑在本地，用最轻量的方式。我在树莓派4B上跑通了ChromaDB，这就是我的边缘向量数据库。所有我手动录入的、从外卖平台扒下来的历史饮食数据，都被我转换成向量存了进去。对，就是爬虫，老手艺了，但这次爬的是美团和饿了么的“我的订单”页面，用Playwright搞定动态渲染，专抓菜名和商家分类。清洗数据的时候，那些“爆辣”、“特辣”的标签，被我单独提出来作为口味强度的特征维度。
真正的魔法在调用上。我写了个脚本，每天下午五点，自动触发。本地脚本先从我ChromaDB里检索出最近一周我吃得最爽（通过我事后手动打的满意度标签）、且热量适中的几餐作为“正面样本”，把菜名、口味描述、预估热量打包成一个上下文。然后，调用OpenAI的API，但不是让它天马行空。我的Prompt是这样写的：“你是一个精通川菜烹饪和营养学的成都本地厨师。根据用户以下历史偏好及约束：{上下文}。请生成一份今天的晚餐建议。必须满足：1. 典型成都家常菜风格，可微辣。2. 包含主要食材和简易做法。3. 总热量不超过650卡。4. 输出格式严格为：菜名 | 主要食材 | 预估热量 | 关键烹饪提示（少油/免勾芡等）。” GPT-4吐出来的，就不再是“鸡胸肉沙拉”这种让我毫无食欲的东西了，而是“青椒肉丝（少油版） | 猪里脊、青椒 | 320卡 | 肉丝用淀粉抓腌，热锅冷油快炒，最后沿锅边淋少许生抽”、“冬瓜圆子汤（清淡版） | 猪肉末、冬瓜 | 220卡 | 肉末加姜末、蛋清搅上劲，水微开下丸子，撇净浮沫”。这就有执行性了。
整个流程，API调用是唯一需要网络和花钱的环节。我把请求频率压到最低，一天一次，用n8n做了个最简单的定时自动化，脚本跑在树莓派上，结果直接生成txt文件丢到我的钉钉机器人。一个月下来，GPT-4的API费用不到5美元，比我之前那台低配云服务器便宜十倍。数据在本地，隐私可控；核心推荐逻辑由大模型完成，智能度够用；成本极低，符合我当前“超级个体”阶段对每一分钱现金流都要斤斤计较的心态。
技术宅解决生活问题，最后往往又会落回技术。但这次不一样，我不是为了炫技，是为了保命。用向量数据库做记忆，用大模型做决策，用边缘设备做执行，这套“边缘智能”流水线，治好了我两个焦虑：一是晚上吃什么的选择焦虑，二是害怕被云服务商和臃肿SaaS持续收割的财务焦虑。身体和钱包，总得有一个是轻松的。现在看，也许两者都能稍微喘口气了。
