案例AI 驱动的咖啡馆社交场景微信小程序，结合 PRD v2.1 的整合版需求，覆盖匹配 / 推荐 / 互动闭环。
为咖啡消费场景打造的 AI 社交小程序。用户进入合作咖啡店后，通过 LBS 定位自动匹配同店其他顾客，AI 生成个性化破冰话题，降低陌生人社交门槛。同时内置拼单优惠券、店主端 SaaS 后台，形成「引流—社交—消费」闭环。3 人核心团队 6 周完成首版上线，已接入 12 家咖啡店，单店日均流水提升 30% 以上。
上线首周最尖锐的反馈来自一家社区咖啡店店主：「客人打开小程序，显示'当前店内无其他用户'——然后他关掉再也没打开过。」LBS 匹配的前提是「同店有多人同时在线」，但新接入店铺初期日活不到 5 人，匹配成功率不到 20%。
我们的补救方案分两步。短期：当同店匹配池为空时，自动扩大到同品牌 1 公里内其他门店——虽然空间上不在一起，但通过品牌认同维持了基本的社交动机。长期：店内放置带小程序码的台卡（「扫码看看谁也在喝咖啡」），配合拼单券作为无匹配时的替代价值——用户即使没匹配到人，也能领一张单人 9 折券。这个策略把新店首周留存率从约 25% 拉到约 45%。
用户被匹配后需要实时通知——但微信小程序的一次性订阅消息限制很严：用户每次操作只能授权一次推送，且必须在用户主动点击后 7 天内使用，超期失效。我们的解法不是攻克这个限制（做不到），而是重新设计通知路径。匹配成功后优先走「站内红点 + 模板消息」而非服务通知；服务通知仅用于拼单成功和优惠券到期提醒这两个用户明确预期会收到消息的场景。同时在后端维护每个用户的订阅消息剩余次数，快用完时在前端引导用户重新授权。
初版 AI 破冰话题的生成策略是追求「有趣」——让大模型自由发挥，产出「有梗」的话题。上线第一周数据看起来不错：话题点击率 68%，用户平均浏览 2.3 条话题后才选择一条发送。但第二周开始，发送率急剧下滑——从 41% 跌到 12%。
用户访谈揭开了原因：AI 生成的「有趣」话题经常用力过猛。「看到你点了冰美式——也是个被周一暴击的打工人吗？」这种风格在部分用户看来是冒犯而非幽默。另一个问题是话题太「AI 味」——句式工整、用词精致，用户一眼看出不是人写的，反而觉得尴尬。
修正方案：把话题生成策略从「有趣优先」改为「安全优先 + 可个性化」。每条话题控制在 12–20 字，不给完整句子，给一个开放式问题开头（如「你平时周末喜欢…」「最近有没有看到…」），让用户自己补全后半句。同时训练一个简单的质量分类器，自动过滤掉包含职场抱怨、收入相关、外貌评价的话题变体。修正后发送率回到 38%，更重要的是「用户二次对话率」（发完破冰后继续聊的比例）从 19% 升到 35%。
前端：微信小程序原生（WXML / WXSS / JavaScript），理由：团队在小程序生态有积累，且项目对 UI 自定义要求不高，原生开发足够覆盖需求
后端：Node.js（Express 框架，处理 REST API + WebSocket 实时通知） + Python（FastAPI 微服务，专门负责 AI 推荐推理和话题生成，便于独立扩缩容）
数据层：MySQL 8.0（用户/订单/门店主数据） + Redis（在线状态缓存、匹配池、Session）
AI 能力：大模型 API（破冰话题生成） + 自研轻量推荐模型（LBS + 兴趣标签协同过滤）
部署：Docker Compose 多服务编排，部署在腾讯云服务器，Redis 做匹配池实时缓存。AI 推理服务独立部署，通过内部 API 网关调用
]]>