今天吃什么，每天问三遍，却没有正确答案。
干饭魔法书只做一件事——替你把这一顿定下来。
滚动屏幕，手机随你转动，好设计经得起立体看。
它不难，只是无穷无尽。我把这个日常决策拆成四层——前三层关于效率，最后一层关于关系。
吃什么每天要重复决定三次，没有正确答案，却要消耗真实的意志力。选择越多，越难定下来。
大多数菜谱产品停在“看”这一层：收藏了、看过了，但没有解决“我现在手里有什么、能不能做”。
年轻人对“这一顿够不够”缺乏判断依据，搜索得到的往往是广告或相互矛盾的说法。
两个人一起吃饭时，“随便”和“都行”是最难的题。决策成本翻倍，最后往往演变成“你点吧”。
用户缺的从来不是菜谱，而是替他把这一顿定下来的那一下。 真正被消耗的不是时间，而是做决定的意志力—— 所以产品的主线，是抽签式的决策仪式。
把“随便”，
变成“就它了”。
产品不追求菜谱数量，也不做社区。它只承诺一件事： 在你不想再想的时候，给你一张敢替你拍板的菜单—— 并且这张菜单，是真的做得出来的。
把开放问题收敛成 1 个答案。魔法盲盒直接用抽签的方式输出“一荤一素一主食”，把无限选择变成一次点击。
把菜谱变成能落地的清单。食材逐项勾选、替代建议、一周购物清单，解决“看完还是不知道怎么做”。
让这件事被看见。等级、成就、干饭日历，把“我今天给自己做了饭”记录成一件值得开心的小事。
把边界说清楚。孕期、慢性病等敏感场景主动提示“仅供日常参考，不能替代医生建议”，不让功能越界成医疗建议。
这台手机不是贴图，是按 50 道真实菜谱数据 1:1 重建的可交互原型——抽签、约束筛选、打卡、经验入账，全部真的能跑。
这里是按真实数据重建的可交互原型；完整的云同步、反馈闭环、深色模式与成长体系，运行在微信小程序里，长按即可体验。
页面不是按功能堆的，是按用户的路径铺的——从“不想想”到“做完了”，每个域回答一个问题。
所有功能都从同一个问题出发：这一步，有没有帮用户更快定下来？
把“选择”改成“抽取”——结果固定一荤一素一主食，结构比数量更重要。
四段式作答：营养亮点 → 这样搭配 → 推荐做法 → 需要留意，并直接挂上可做的菜谱。
搜索 + 分类 + 网格浏览，与首页典藏同源同数据——想自己拿主意的时候，这里兜底。
热量区间、现有厨具、已有食材三个维度，收在魔法屏内默认折叠——先限定范围，再开抽。
经验只来自真实行为：浏览 +2、收藏 +8、收下整席 +12、打卡 +25，2000 封顶。每一餐，都算数。
反馈状态全程可见：未读 → 处理中 → 已回复 → 已采纳 → 已归档；被采纳奖励 60 经验。
下面每个循环播放的动效，都对应小程序里真实存在的交互——仪式感、即时反馈、可追溯的成长，全部藏在几百毫秒的产品语言里。
抽签不是弹窗开奖，而是一次翻卡的仪式感——翻开的是真实菜谱，按今晚模式现抽现筛。
打卡、收藏、收下整席都真的加经验——进度条涨上去的那一下，就是回下一次的理由。
自由提问，直接返回四段式建议——识别到敏感场景时，免责声明会主动出现在最前面。
连续做饭的天数用一格格亮起来的日子来呈现——不催促，不排名，只是替你记得。
随机之所以可信，是前面有真实约束——模式、口味、忌口层层收窄，抽出的每一席都有依据。
点一下收藏，红心跳起、经验入账——想做的菜自动进清单，每个行为都会被即刻奖励。
热量区间、现有厨具、已有食材，收在魔法屏内默认折叠、随用随开。先划定范围，再让魔法书开抽——「敢替用户拍板」的前提，是约束真实存在。
搜索、分类标签、网格浏览，与首页典藏同一套数据——把「自己拿主意」的权利也留给用户。
六级成长全部由真实下厨行为点亮：打卡、收藏、收下一席……经验 2000 封顶，不催不逼，只替用户记得。
抽签只是表面——每一道菜为什么上桌、每一次抽取避开了什么，全都写得明明白白。
理由不是文案，是真实规则算出来的：贴合饮食目标、命中口味偏好、蛋白质给足、用时够短……不满意哪一道，「换一张」只替换那一道、优先换不同品类，不推翻整席；抽完还有一句话小结，交代这一席的出处。
推荐最怕越推越窄。每次抽取，算法都会从当前约束池之外挑一道没吃过的菜顶替其中一席——大多数推荐顺着你的口味，只留一个位置给「没想过但大概率会喜欢」的那道菜。探索菜也要过忌口这一关。
偏好档案里勾掉的过敏原，会在抽取池、探索位、营养助手三处同步过滤——营养助手回答之前，还会主动提示「忌口已生效」。不是打标签，是全产品联动的闸门。
页面只管展示，逻辑按域拆成服务，云端一个入口。任何一层挂掉，用户都不应该看到白屏。
// 所有云端能力收敛成一个 action 命名规范：域.动作 const cloudApiService = { drawMagicMenu: (payload) => call("magic.menuDraw", { ...payload }), askAdvisor: (question) => call("advisor.ask", { question }), matchFridge: (ingredients) => call("fridge.match", { ingredients }), awardExperience: (type, key) => call("experience.award", { type, key }) }; // 调用层自带降级：云函数 → HTTP 接口，失败也不让用户看到报错 async function call(action, payload) { try { const res = await wx.cloud.callFunction({ name: "mealApi", data: { action, payload } }); if (res.result?.ok) return res.result.data; throw new Error(res.result?.error?.message); } catch (e) { return callByHttp(action, payload); // 通道二 } }
每道菜谱携带 12 个可检索字段：分类、口味、难度、时长、份数、预算、厨具、适用模式、孕期友好、过敏原、替代建议、四段营养数据。所有推荐算法都建立在这套结构上，而非散落各页面的 if-else。
关键行为全部上报：菜谱浏览、搜索词长度与结果数、盲盒抽取、营养提问长度、是否触发免责声明。设计时就预设了“这个功能怎么衡量”。
云端配置站点名称、首页问候语、公告、维护模式与最低客户端版本。菜谱后台可增删改，不发版就能调整内容。
从一句生活洞察，到一套能点、能跑的产品——
一个人，一套 AI 协作流程。
产品亮点、可复用的设计方法，以及下一阶段的演进路线。
菜谱供给规模化
继续扩充结构化菜谱，打通外部菜谱源供给。
菜单分享卡
把今晚这一席变成可转发的图，天然自带传播。
语义化营养对话
接入大模型承接长尾提问，规则引擎转为兜底，准确率与覆盖面同时提升。
家庭协同
由双人投票扩展为多人菜单与分工，切入家庭备餐场景。
