| ProductSpec | ||
| LICENSE | ||
| README.md | ||
What2Cook Today
一个帮你"今天吃什么"的对话式 AI 助手。不是又一个菜谱搜索 App，而是一个减少决策疲劳的"决策收窄器"。
本仓库为 滴水湖大赛 S1W1 初赛阶段 的项目提案与文档归档。
项目说明
项目要解决的问题
下班路上、回家前那 30–60 分钟，独居的上班族常常面对一个反复出现却让人头疼的小问题：今天到底吃什么？现有的菜谱类工具普遍走的是"提供更多内容"的逻辑，而不是"帮你做决定"的逻辑——结果是越翻越累，最后还是回到那几道熟悉但乏味的家常菜。
What2Cook Today 把"我不知道吃啥"变成"我知道买什么、怎么做"，是一个面向独居用户的轻量决策助手。
目标用户
主要面向 25–35 岁、独居、能做饭但下班后不想做饭决定的城市上班族（代号 Chloe）。她会做家常菜、看得懂普通菜谱，经常下班路上才想起晚饭，但又不想再翻菜谱；她收藏过很多菜谱，但收藏从来不等于决定。
代表性用户原话：
"我存了一堆菜谱，可真到饭点还是不知道吃啥。"
使用场景
- 下班路上 / 到家前：还没决定今晚吃什么，需要一份干净利落的推荐
- 去超市 / 菜场之前：需要一份能直接照着买的清单
- 打开冰箱之后：手头有几样食材但不知道怎么搭配
- 想换换口味但懒得做计划时：让产品帮你跳出"老三样"
为什么这个问题值得做
- 高频且低被解决度：吃饭是每天的决策，但绝大多数菜谱类应用仍在做"内容推荐"，没有正面解决"决策收窄"。
- LLM + 长期记忆让"懂你"成为可能：传统推荐系统给不了"你昨天嫌油腻、今天又只剩 30 分钟"这种对话式适应；只有具备记忆与对话能力的 AI 能真正胜任这个角色。
- 链路完整：从"吃什么"到"买什么"再到"怎么做"是一条天然闭环，做透了能形成稳定复用，而不仅仅是工具型流量。
我们准备怎么验证
正式开发前会先做一轮 Wizard-of-Oz 实验：5 位目标用户，连续 3 天，团队人工扮演系统，向用户给出菜单、购物清单和烹饪步骤。判断指标：
- 至少 4/5 用户愿意主动提供口味偏好与反馈
- 至少 3/5 用户连用 3 天
- 第 3 天用户的平均"调整推荐次数"比第 1 天下降
- 用户能用自己的话说出"比普通菜谱 App 更懂我 / 更省力"
这一步通过后才进入工程开发。完整的实验设计见 Lean-UX-Canvas.md，详细产品设计见 PRD.md。
AI+应用项目提案 (Specs)
2.1 项目名称
What2Cook Today — 今天吃什么 · 决策助手
一句话定位：让独居上班族在 1 分钟内确认今晚的菜单、购物清单与做法。
2.2 应用场景
赛道归属：零售 / 生活服务（覆盖个人厨房决策与日常生鲜采购的高频场景）。
具体使用场景：
- 场景 A · 通勤决策：用户在下班路上的手机网页里输入"今天 30 分钟、不要太油"，得到一份可执行的菜单。
- 场景 B · 采买前决策：用户在前往超市 / 菜场前确认菜单，立即得到区分"已有 / 待买"的购物清单。
- 场景 C · 冰箱前的决策：用户提供手头几样食材，系统推荐能利用这些食材的搭配。
- 场景 D · 反馈与记忆沉淀：饭后用户给出快速反馈（好 / 一般 / 别再推），系统将其转化为可见、可编辑的记忆条目。
产品形态为移动优先的 Web App，不依赖原生客户端，便于初赛阶段快速发布与验证。
2.3 目标用户
| 维度 | 描述 |
|---|---|
| 年龄 | 25–35 岁 |
| 居住状态 | 独居（一线 / 新一线城市） |
| 烹饪能力 | 会做家常菜，看得懂普通菜谱 |
| 时间状态 | 下班疲惫，晚饭决策时间窗约 30–60 分钟 |
| 现有行为 | 收藏过菜谱，但实际做饭时仍然犹豫 |
| 真实痛点 | 不缺菜谱，缺"今天吃啥"的决断 |
详细人物画像与 JTBD 分析见 JTBD.md。
2.4 核心问题
用户面对的不是"找不到菜谱"，而是"做不了决定"。
具体痛点：
- 选择过载：菜谱数量充足，但与"今天的我"匹配的菜谱无法快速浮现。
- 重复疲劳：决策成本高 → 用户回到老三样 → 饮食单调。
- 信息分散：口味偏好、冰箱库存、季节、特价、健康目标分散在不同地方。
- 可执行性差：很多看起来不错的菜谱实际缺食材、技法过难或耗时不合。
- 不被理解：用户担心 AI 给出的只是"看起来合理"的菜谱，而不是"懂我"的菜谱——这是产品最核心的信任风险。
2.5 产品思路
核心理念：决策收窄器，不是内容堆叠器。
主流程（首屏到下厨）：
- 轻量输入 — 收集最少必要约束：人数、时间、可用食材（可不填）、今日偏好。所有字段可选，支持自然语言。
- 单条推荐 + 解释 — 默认推荐一个菜单组合（一主 + 一辅），并附 2–4 条匹配标签 + 一句话说明（必须包含记忆引用 + 今日上下文引用）。
- 对话式调整 — 用户用自然语言修正（"不要太辣"、"换点别的"），单次菜单调整上限 3 轮，第 3 轮后系统主动给出兜底选项。
- 菜单确认 → 购物清单 — 区分"已有 / 待买"食材，按人数动态计算分量。
- 菜谱步骤 — 来自策划菜谱库（v0.1 ≥ 200 道家常菜），LLM 不直接生成步骤文本。
- 饭后反馈 → 可见的记忆更新 — "好 / 一般 / 别再推"三选一 + 可选自然语言反馈；系统询问反馈粒度（菜级 / 组合级 / 口味级）后更新可视化记忆条目。
关键设计原则：
- 默认只推一个，不堆砌选择
- 推荐解释里必须能看到"它记得什么"和"今天怎么对得上"
- 用户可用自然语言修正，不需要表单切换
- 用户可一键查看 / 编辑 / 清空食物记忆
- v0.1 季节 / 特价食材手动配置，不依赖外部超市 API
2.6 AI 在哪里发挥作用
What2Cook Today 不是一个"加了 AI 包装"的菜谱 App，AI 是它能存在的根本原因。下表列出"没有 AI 就做不到"的能力点：
| 能力 | 没有 AI 就做不到 | 我们怎么用 |
|---|---|---|
| 对话式约束收集 | 传统表单不支持"今天有点累、不想用油"这种半结构化输入 | LLM 解析自然语言 → 结构化今日上下文 |
| 个性化推荐解释 | 普通推荐系统给不出"因为你上周嫌它油，所以这次改清蒸"这种解释 | 生成推荐时强制引用记忆 + 今日上下文 |
| 多轮自然修正 | 传统筛选器无法理解"再清淡一点"这种相对修改 | LLM 维持对话状态，对菜单做局部调整而非重启流程 |
| 反馈归纳为记忆 | 规则系统无法把"今天有点咸"提炼为"她偏好淡口" | LLM 提议记忆更新 + 用户确认粒度 |
| 多约束库内选菜 | 关键词检索无法权衡偏好 / 时间 / 食材 / 季节多重约束 | LLM 在策划菜谱库内做约束求解，并给出轻量替换建议 |
安全边界：菜谱步骤、用量、烹饪时间均来自人工策划的菜谱库，LLM 不允许改写步骤主体——只允许"在库内选 + 加上下文注解"。这避免了 LLM 在食品安全敏感场景下的幻觉风险。当库内无匹配时，系统优雅降级提示"换个偏好再试"，而不是编造菜谱。
2.7 评测标准
将"项目是否做成"拆解为以下可验证问题：
一、关键任务是否完成（核心承诺）
- 用户能否在 1 分钟内完成"打开 App → 确认菜单"？指标：决策时长中位数 ≤ 60 秒，P75 ≤ 120 秒
- 第一条推荐是否经得起考验？指标：首推确认率（不修改即确认）≥ 35%；< 20% 视为失败
- 菜单确认后是否真的进入购物 / 烹饪环节？指标：购物清单查看率 ≥ 50%
二、AI 输出是否符合要求
- 每条推荐解释是否同时包含 ≥ 1 条记忆引用 与 ≥ 1 条今日上下文引用（生成层硬约束校验）
- 菜谱步骤是否 100% 来源于菜谱库，无 LLM 编造
- 库内无匹配时是否优雅降级，而非编造菜谱
三、是否减少人工步骤
- 用户是否还需要在不同 App 之间切换比较菜谱、库存、特价？目标：单一入口完成
- 输入门槛：是否做到"只填一项也能启动推荐"
四、是否随使用提升体验
- 调整轮数下降斜率：第 4–6 次推荐相比第 1–3 次，平均调整轮数下降 ≥ 30%
- 第 5 次确认后单题问卷"它比第一次更懂你吗"，"更懂"占比 ≥ 50%
- 次日复用率 D+1 ≥ 25%，D+7 ≥ 40%
五、用户隐私与可控性
- 用户能否一键清空 / 导出全部食物记忆
- 用户能否随时查看并编辑被记住的偏好
完整指标定义、阈值与早期预警信号见 PRD.md 第 10 节。
仓库结构
What2cookToday/
├── README.md # 本文件 — 项目总览与初赛提案
├──ProductSpec/
├── PRD.md # 产品需求文档 (v0.2)
├── JTBD.md # Jobs To Be Done 用户需求分析
├── Lean-UX-Canvas.md # Lean UX 假设与验证计划
当前阶段
- 初赛阶段：产品提案 (Specs) 已完成
- 下一步：Wizard-of-Oz 实验 → MVP 工程实现
- 仓库已设为公开，可供评审查阅
许可
- 本项目采用 GNU General Public License v3.0 only (GPL-3.0-only) 许可协议。
- Copyright (C) 2026 Deepblue
- 完整许可文本见 LICENSE。