加入设备级随机种子、最近 12 道轮换,以及“上一个”和“7 天暂避”。
FLAGSHIP PRODUCT CASE
把饭点纠结,做成一次能执行的决定。
真实试用里,有人说“老是那几道”“没胃口”“推荐完还是不知道怎么做”。我把这些模糊抱怨拆成产品问题,再与 Agent 一起实现、测试和迭代。

首次打开、断网和云端不可用时的本机兜底。
V5 发布物规模;仍待云端激活与真机复验,不等于已公开生效。
可直接行动:自己做有步骤,外卖有安全搜索词。
当前自动化测试通过数,是工程证据,不是用户效果。
先把问题说对
它不是找店、地图、外卖交易或内容社区。真正的问题是:饭点已经很饿,却还要在大量选项里继续做判断。
所以产品不申请定位,不维护商家,不要求登录,也不承诺实时价格和附近供应。它只负责把场景、预算、忌口、近期重复和明确反馈收敛成一道答案。
反馈怎样改变产品
补充菜品图片、口味标签和“清淡点 / 来点辣的”等单方向调整。
60 道行动菜分别提供做法步骤或外卖安全搜索词,不伪造门店和实时价格。
重做自定义菜 V2,并把“我的食光”压缩成规则、菜品、概览、偏好和记录。
这些是已收到并落实的定性反馈,不是完成了正式实验。10 人连续 7 天的量化验证仍未完成。
四个高清产品画面
以下画面来自宣传视频最终成片的 1080×1920 编码帧,用真实产品规则和本地素材演示关键状态;它们不是商家页,也不伪装成微信开发者工具截图。

真实本地菜图配合川湘、火锅、烧烤等候选分类。

参考图、预计用时、1 人份材料与 3 至 4 步简易食谱。

先完成硬筛选,再隐藏菜名;揭晓前后保持同一道。

紧凑呈现规则、自定义菜、使用概览、主动偏好和确认记录。
一轮决定先在本机完成
用户先得到一个能用的答案,再选择“换一个”或调整少量条件。AI 增强发生在结果可用之后,因此网络和模型状态不会决定饭点能否继续。
边界比功能更重要
| 功能 | 为什么诱人 | 为什么不做 | 替代方案 |
|---|---|---|---|
| 附近餐厅 | 结果更具体 | 需要定位、商家库和供应真实性 | 只推荐吃什么 |
| 强制登录 | 方便跨端画像 | 第一顿饭就增加门槛和身份收集 | 本地状态 |
| AI 直接决定 | 看起来更智能 | 未配置、超时或非法结果会阻断任务 | 本机先决策 |
| 把 441 写成已上线 | 数字更显眼 | V5 仍待云端激活与真机复验 | 96 离线兜底 + 明示发布状态 |
怎么与 Agent 分工
01
Kun 决策
- 确认只解决吃什么,不扩张到选店和交易
- 找到试用者,把模糊抱怨解释成可排序的产品问题
- 决定反馈优先级、功能边界、真机验收和发布口径
02
Agent 协作
- 把讨论固化为 PRD、技术规格和可测试规则
- 实现本机推荐、可选云函数、状态与存储边界
- 运行自动化、视觉检查并迭代失败路径
03
验证边界
- 真实定性反馈已推动多轮迭代,145 项自动化测试通过
- 安卓和朋友的 iPhone 都提供过布局反馈,仍需新一轮双端复验
- 10 人 7 天正式验证、V5 云端激活和公开上线尚未完成
AI 放在哪里
预算、忌口、场景和“7 天不想吃”先做确定性硬过滤;餐段、喜欢、反馈、近期重复和天气再做软排序。页面先显示本机候选,后台 AI 只允许辅助排序和生成理由。
如果 AI 未配置、超时或返回非法结果,当前推荐继续可用。AI 也不能看到身份、城市、天气、自定义菜或私人历史。这不是退路,而是产品的默认可靠性。
证据强度分层
重复、没胃口、自定义菜和布局问题已经影响产品决策。
145 项测试、40 个 JS 语法检查、14 个 JSON 解析通过。
10 人连续 7 天的完成时间、换选次数、执行率和复访意愿。
试用重点不是问“喜欢吗”,而是记录完成一次决定用了多久、换了几次、最终是否执行,以及第二天是否愿意再打开。45 秒仍只是目标,不是测得的平均值。
从产品到发布内容
同一个项目继续走到 AI+营销:我与 Agent 把产品事实、不能说的承诺、竖屏分镜、程序化音乐和编码验收整合成一条可复验的 Remotion 发布链路。

这证明的是内容可以编辑、渲染和验证,不证明它已经带来播放量、增长或转化。
证据到这里为止
96 道是离线兜底,不是完整菜库;441 道是 V5 发布物,仍待部署最新云函数、切换 active 版本并完成真机复验。45 秒是目标,不是测得的平均值。
小范围真实反馈已经发生,但 10 人 7 天正式验证、公开上线和效果数据仍未完成。它也不会替用户找店、下单或判断附近供应。