偏好确认
问答收集场景、预算、距离、口味与忌口,缺信息时主动追问。
冲突识别
管家拆出每个人的硬约束与软偏好,明确指出冲突在哪里。
推荐生成
候选自检 → 最终推荐 → 一键生成可发群里的邀约文案。
围绕年轻人本地生活的高频决策:吃饭、约局、周末、突发,做一个会主动出现、能协调多人、会自检方案的 AI 管家。命题 01:基于 OpenClaw 的全天候私人管家。
美团、点评、地图、微信、小红书来回切,信息都在,却还得自己比较、筛选、协调和拍板。
忘预算、忘忌口、路线不现实、信息不足也硬生成。看着漂亮,真去执行就踩坑。
难的不是找店,是每个人都有不能违反的限制:不吃辣、赶时间、预算紧,很难有人折中。
学习、项目、实习都忙,每天都在“吃什么、去哪、和谁约、怎么安排”的小决策里打转。一个人查店还行,多人约饭就乱了:口味、预算、时间、距离全在打架,最后谁都说“随便”。
两个增强点,把方案从“生成建议”变成“可靠执行”,避开 01 赛道的同质化。
生成方案前,先像审计员一样逐项检查预算、忌口、时间、距离、氛围、公平性、可执行性。不合格就自动修正或追问,再输出。
抽取每个人的硬约束与软偏好,明确指出冲突在哪里,生成几个折中方案;用最低个人满意度而不只是平均分来排序。
一条完整链路,体现管家如何理解每个人、识别冲突、自检方案,再推进到可执行动作。
明晚三人,人均≤100,适合聊天
各自补充口味、预算、时间
拆出硬约束与软偏好
逐项规则检查
最稳、最公平的一家
一键复制去推进
成员偏好
冲突识别
口味冲突:小林想吃辣,阿杰完全不吃辣。不吃辣为硬约束,优先保护。
时间冲突:小周 20:30 前要回,排队久 / 太远的店降权。
预算冲突:总体人均 100,但阿杰希望不超过 80。
方案自检
Web 作品页是面向评审的可访问镜像:保持产品能力一致,复用现有后端链路,用浏览器友好的身份、路由与存储承载完整体验。
微信小程序与 Web 体验并行。Web 版复刻小程序流程,用 demo session 替代 wx.login。
Next.js App Router 同时承载作品页、在线体验页面与 API routes。
OpenClaw 负责单人推荐与动态追问;不可用时降级到本地推荐,保证评审流程不断。
任务、登录 session、周末规划写入服务端 JSON store;浏览器本地保留记忆、收藏与草稿。
POST /api/food/recommendPOST /api/group-tasksPOST /api/weekend/planslocalStorage + profile完整走一遍“偏好确认 → 冲突识别 → 推荐生成”,证明不是纸面方案,而是真的跑起来了。
问答收集场景、预算、距离、口味与忌口,缺信息时主动追问。
管家拆出每个人的硬约束与软偏好,明确指出冲突在哪里。
候选自检 → 最终推荐 → 一键生成可发群里的邀约文案。