FLAGSHIP PRODUCT CASE

把饭点纠结,做成一次能执行的决定。

真实试用里,有人说“老是那几道”“没胃口”“推荐完还是不知道怎么做”。我把这些模糊抱怨拆成产品问题,再与 Agent 一起实现、测试和迭代。

状态:小范围真实试用迭代中形态:微信小程序更新:2026-07-22
今天吃啥 1080p 产品动效演示画面,展示真实本地菜图与候选分类
1080p 产品动效演示:基于真实产品事实与本地菜图制作。
96 道

首次打开、断网和云端不可用时的本机兜底。

441 道

V5 发布物规模;仍待云端激活与真机复验,不等于已公开生效。

60 道

可直接行动:自己做有步骤,外卖有安全搜索词。

145 项

当前自动化测试通过数,是工程证据,不是用户效果。

先把问题说对

它不是找店、地图、外卖交易或内容社区。真正的问题是:饭点已经很饿,却还要在大量选项里继续做判断。

所以产品不申请定位,不维护商家,不要求登录,也不承诺实时价格和附近供应。它只负责把场景、预算、忌口、近期重复和明确反馈收敛成一道答案。

反馈怎样改变产品

这些是已收到并落实的定性反馈,不是完成了正式实验。10 人连续 7 天的量化验证仍未完成。

四个高清产品画面

以下画面来自宣传视频最终成片的 1080×1920 编码帧,用真实产品规则和本地素材演示关键状态;它们不是商家页,也不伪装成微信开发者工具截图。

一轮决定先在本机完成

01输入边界场景 / 预算 / 忌口
02硬过滤不合适就排除
03本机排序历史与重复权重
04立即给结果AI 不阻断

用户先得到一个能用的答案,再选择“换一个”或调整少量条件。AI 增强发生在结果可用之后,因此网络和模型状态不会决定饭点能否继续。

边界比功能更重要

功能为什么诱人为什么不做替代方案
附近餐厅结果更具体需要定位、商家库和供应真实性只推荐吃什么
强制登录方便跨端画像第一顿饭就增加门槛和身份收集本地状态
AI 直接决定看起来更智能未配置、超时或非法结果会阻断任务本机先决策
把 441 写成已上线数字更显眼V5 仍待云端激活与真机复验96 离线兜底 + 明示发布状态

怎么与 Agent 分工

01

Kun 决策

  • 确认只解决吃什么,不扩张到选店和交易
  • 找到试用者,把模糊抱怨解释成可排序的产品问题
  • 决定反馈优先级、功能边界、真机验收和发布口径

02

Agent 协作

  • 把讨论固化为 PRD、技术规格和可测试规则
  • 实现本机推荐、可选云函数、状态与存储边界
  • 运行自动化、视觉检查并迭代失败路径

03

验证边界

  • 真实定性反馈已推动多轮迭代,145 项自动化测试通过
  • 安卓和朋友的 iPhone 都提供过布局反馈,仍需新一轮双端复验
  • 10 人 7 天正式验证、V5 云端激活和公开上线尚未完成

AI 放在哪里

预算、忌口、场景和“7 天不想吃”先做确定性硬过滤;餐段、喜欢、反馈、近期重复和天气再做软排序。页面先显示本机候选,后台 AI 只允许辅助排序和生成理由。

如果 AI 未配置、超时或返回非法结果,当前推荐继续可用。AI 也不能看到身份、城市、天气、自定义菜或私人历史。这不是退路,而是产品的默认可靠性。

INPUT吃饭条件
LOCAL / REQUIRED确定性推荐永远先返回可用结果
AI / OPTIONAL排序与理由增强失败、超时、非法输出均跳过
OUTPUT一个可执行决定

证据强度分层

真实反馈

重复、没胃口、自定义菜和布局问题已经影响产品决策。

工程验证

145 项测试、40 个 JS 语法检查、14 个 JSON 解析通过。

仍待验证

10 人连续 7 天的完成时间、换选次数、执行率和复访意愿。

试用重点不是问“喜欢吗”,而是记录完成一次决定用了多久、换了几次、最终是否执行,以及第二天是否愿意再打开。45 秒仍只是目标,不是测得的平均值。

从产品到发布内容

同一个项目继续走到 AI+营销:我与 Agent 把产品事实、不能说的承诺、竖屏分镜、程序化音乐和编码验收整合成一条可复验的 Remotion 发布链路。

今天吃啥竖屏宣传片最终编码视频的九宫格联系表
最终编码视频抽帧:1080 × 1920、30 fps、25.024 秒、H.264/AAC。

这证明的是内容可以编辑、渲染和验证,不证明它已经带来播放量、增长或转化。

证据到这里为止

96 道是离线兜底,不是完整菜库;441 道是 V5 发布物,仍待部署最新云函数、切换 active 版本并完成真机复验。45 秒是目标,不是测得的平均值。

小范围真实反馈已经发生,但 10 人 7 天正式验证、公开上线和效果数据仍未完成。它也不会替用户找店、下单或判断附近供应。