用一件事盘活整个闭环，而不是先堆推荐功能
整个产品成立的前提是「用户愿意持续维护库存」，这也是最大风险。而「做饭 → 消耗」这一环如果缺失，库存数据会很快失真——推荐和临期提醒全部失效。
所以把「做完菜扣减库存」排为 P0：它不是一个功能，它是让所有其他功能保持有效的地基。
SYSTEM · CASE STUDY
随手做菜
「有食材但不知道做什么」是每天重复的决策疲劳。
微信小程序：库存管理、OCR 入库、按现有食材推荐。定位不是炫技 AI，是帮普通人真的每天做饭——不是菜谱库，而是库存驱动的轻量决策工具。
背景与问题
年轻人每天都要回答「今天吃什么」——看似简单，实际很耗决策精力：菜谱散落各处、选好菜才发现缺料、冰箱食材放到过期浪费。
要解决的不是「找不到菜谱」，而是「面对现有食材，懒得想今天做什么」。
定位 · 差异化
✗ 市面产品：菜谱大全
本质是内容消费——海量菜谱等你来搜。但真实高频场景不是「学做菜」，而是「快点定下来今天做什么」。
✓ 随手做菜：库存驱动的决策工具
从「你冰箱里有什么」出发做推荐——选菜即可做、顺便消耗临期食材。这是它与市面产品最大的差异。
我的角色
个人项目，独立完成全流程：用户与场景分析 → PRD → 功能优先级 → 产品 / 交互设计 → 数据埋点与验证方案。开发环节借助 AI 编程工具（Claude / Cursor）实现前端（微信原生）+ 后端（云函数 / 云数据库）落地。
核心闭环
整个产品是一个闭环，而不是单向漏斗——「做完菜扣库存」让库存数据保持真实，推荐才能持续有效。
录入食材
手动添加 · OCR 订单截图一键入库
↓
基于库存推荐
能不能做 × 临期优先 × 荤素搭配
↓
选菜做饭
今天抽一顿 / 生成菜单 / 分享点单
↓
做完推断扣减库存
「做饭 → 消耗」闭环的关键一环
↓库存变化 → 回到推荐
库存持续真实 · 推荐持续有效
临期提醒不失灵 · 浪费减少
Demo
一段真实小程序操作录屏，展示从库存到推荐的核心体验。
关键产品决策 · 为什么 P0 是「做完菜扣库存」
AI 怎么用
产品侧用 AI 解决真实体验问题，开发侧用 AI 提升独立交付效率：
OCR 截图识别入库
接入腾讯云 OCR，把购物订单截图一键识别成食材。自研后处理：过滤价格 / 店名 / 广告噪声 → 提取「菜名 + 重量」→ 食材词库校验，只保留真正的食材。
库存匹配 + 加权推荐
按食材重要性分级判断「能不能做」，再结合「临期优先、荤素搭配」动态加权——让「今天抽一顿 / 生成菜单」贴合真实库存，而非随机抽菜谱。
开发侧：用 Claude / Cursor 辅助编码，独立完成微信原生前端 + 云函数 / 云数据库后端的完整落地。
数据驱动 · 埋点与指标体系
自研轻量埋点（事件写入云数据库）+ 云函数计算指标，围绕关键假设设计指标——用数据验证假设、决定开发优先级，而不是凭感觉堆功能。
| 关键假设 | 对应指标 | 回答什么问题 |
|---|---|---|
| 用户知道下一步做什么 | 首个动作转化、空转退出率 | 新用户是否迷失在首页 |
| 库存是核心、用户愿意维护 | 库存维护率；维护 vs 未维护用户的推荐接受率对比 | 产品前提是否成立（最大风险） |
| 推荐有价值 | 推荐接受率、按匹配度分层的接受率 | 推荐算法方向是否正确 |
| 核心闭环真正跑通 | 做完菜扣库存率 | 「做饭 → 消耗」这一环是否发生 |
成果与反思
- 小程序已经上线。真实反馈发现，多位用户最初把它理解成「发现大量新菜谱」，而核心承诺其实是「用已经有的食材做饭」。
- 上线改变了问题：下一步不再只是功能是否好用，而是用户能否理解产品的核心承诺。
- MVP 方向进一步收束到更低成本的库存录入、库存驱动推荐，以及缩短「看到推荐」到「真的做饭」之间的距离。
- 局限：个人项目、暂无规模化用户——指标体系用于后续灰度验证，而非已验证的增长数据（诚实声明）。
技术栈
微信小程序（原生）· 微信云开发（云函数 / 云数据库）· 腾讯云 OCR · 自研埋点 + 指标计算 · Claude / Cursor 辅助交付