Eat-What｜随机吃什么

“今天吃什么”常常不是因为没有选项，而是选项太多、每个都能找到保留理由。Eat-What 是我从自己的选择困难出发做的一款轻量决策工具：用户先在“吃什么”和“喝什么”之间选择模式，再按当下场合、口味和临时排除项缩小范围，最后让工具给出一个明确结果。它不搜索餐厅，也不在运行时调用大模型替用户推荐；项目重点是用 AI Coding 快速把一个真实、反复出现的个人需求转化为可运行产品。

这个需求最初来自我自己的日常观察，而不是正式用户调研。面对外卖、聚餐或下午茶选择时，主要有三个问题：第一，候选越多，比较越容易循环；第二，完全均匀的随机选择可能抽到当前场景明显不合适的选项；第三，每次决策都从头开始，过去对某个结果的喜欢程度没有被利用。产品机会不是增加更多推荐信息，而是把决策压缩成少量选择，让用户先表达必要边界，再接受一个足够合适的结果。

首版目标是建立一条尽可能短、同时保留个人偏好的决策链路：用户可以快速切换吃 / 喝模式，用场合、口味和临时排除缩小候选，并通过一次点击获得结果；结果评分会改变后续抽取权重，常用候选、分类和历史记录在本地持续保留。后续验证应关注从打开页面到接受结果的耗时、重新抽取次数、结果接受率和持续使用意愿。当前没有这些量化数据，因此不把“减少选择困难”写成已经验证的效果。

本项目没有进行访谈、问卷或规模化行为研究。需求拆解来自我对自身决策过程的持续观察：选择对象分为食物和饮品；当下判断会受到单人、聚餐、夜宵、下午茶等场合影响；甜、辣、清淡等口味能够快速排除不合适候选；有些选项只是“这一次不想要”，不应从长期词库永久删除；过去的满意程度应影响下一次出现概率。基于这些变量，MVP 优先验证个人使用闭环，而不是先构建复杂推荐系统。

主界面以一个明确的抽取器为中心，顶部切换“吃什么 / 喝什么”，筛选面板负责场合和口味，临时排除用于表达本轮边界。点击抽取后，候选名称快速轮播并停在最终结果上；用户可为结果打 1–5 星，或将其从本轮候选中排除。设置侧栏支持新增、编辑和删除候选，维护分类与标签；历史侧栏保留最近 20 次结果及当时评分。最终抽取不是完全均匀随机：系统先过滤场合、口味和排除项，再把每个候选的评分作为权重。这个方案不追求复杂预测，而是让“随机替我做决定”与“结果仍尊重我的偏好”保持平衡。

Demo 使用 React 19、TypeScript 与 Vite 构建单页应用，Tailwind CSS 负责界面样式，Motion 提供模式切换、候选轮播和侧栏出现等反馈。食物、饮品、分类和历史记录分别写入浏览器 localStorage，不要求账号或后端服务。AI Coding 主要用于把需求变量转换为状态结构和交互流程、生成与调整组件实现、检查运行结果并持续修正。仓库保留了 Gemini SDK 依赖，但当前源码没有模型调用，因此产品能力来自前端规则和本地数据，而不是生成式 AI。

当前已交付一个可公开体验的纯前端 Demo 和 GitHub 仓库，覆盖吃 / 喝双模式、默认与自定义词库、分类和标签、场合与口味筛选、临时排除、评分加权随机、最近 20 条历史以及本地持久化。它证明了从个人问题定义到交互闭环和可运行实现的完整 AI Coding 路径。项目目前没有真实用户量、决策效率、结果接受率或留存数据；这些仍是下一阶段需要验证的部分。

这次实践让我更明确：面对选择困难，产品不一定需要给出更复杂的解释，关键是让用户用最低成本表达边界，并愿意接受系统替自己完成最后一步。继续迭代时，工程上应先修正筛选回调依赖、定时器清理和本地数据异常保护，并拆分过于集中的组件；产品上需要验证评分加权是否真的提高结果接受度，以及重复结果是否需要冷却机制。如果扩展到多人场景，还可以加入候选共享、共同排除和投票，但这些都应在个人闭环稳定后再做。