下篇：AI 小程序真正难的不是页面，而是交互语义、状态闭环和商业复购

# 下篇：AI 小程序真正难的不是页面，而是交互语义、状态闭环和商业复购 ## 写在前面 到了下篇，我们要讲最硬的一部分：产品为什么能跑起来。 一个 AI 小程序，看起来可能只是几个页面： - 首页 - 扫码页 - 场景页 - 聊天页 - 我的页 - 社交页 但真正决定它是不是产品的，不是页面数量，而是三个东西： 1. 交互语义是否清楚 2. 状态闭环是否完整 3. 商业复购是否自然 这三个问题如果没有想透，小程序就会变成一个“能点的 Demo”。看起来有功能，但用户不知道发生了什么，也不会回来。 我们这次做 AI 酒友小程序，最大的收获就在这里。 ## 一、交互语义：按钮点下去，到底是谁在说话 AI 产品和普通小程序最大的不同，是它多了一个“会说话的角色”。 普通小程序里，用户点击按钮，系统执行动作。比如“提交”“保存”“购买”“返回”。 但 AI 小程序里，情况复杂很多： - 用户点按钮，是不是代表用户向 Agent 说了一句话？ - Agent 会不会立即回复？ - 这个按钮是让 Agent 生成内容？ - 这个按钮是进入另一个页面？ - 这个按钮是否消耗次数？ - 用户看到结果时，会不会误解？ 我们一开始也遇到了这个问题。 比如酒友能力按钮里有“说心情”“写祝酒词”“投漂流瓶”“找同频”。这些按钮表面都像功能，但本质完全不同。 后来我们把它们分成四类： ### 1. 引导型 Agent 先问用户一个问题，不消耗次数。 例如： - 倾诉 - 整理心事 - 交友边界 - 写给未来 用户点了以后，Agent 不应该假装用户已经表达完了，而应该先问： “今晚最重的那种感觉是什么？” 这类按钮的本质是：**Agent 引导用户表达。** ### 2. 生成型 Agent 直接生成一段内容，消耗一次对话权益。 例如： - 祝酒词 - 写诗 - 开心宣言 - 小游戏 用户点了以后，Agent 直接输出结果。 这类按钮的本质是：**Agent 替用户创作。** ### 3. 进入型 进入另一个页面，不消耗对话次数。 例如： - 漂流瓶 - 社交 - 我的 - 记忆卡 这类按钮的本质是：**系统导航。** ### 4. 提交型 提交或改变状态。 例如： - 领取权益 - 投出漂流瓶 - 申请交换 - 保存联系方式 这类按钮的本质是：**改变产品状态。** 这个分类非常重要。因为它解决了 AI 产品里最常见的混乱： **用户不知道自己点的是“说话”“让 AI 做事”“跳转页面”，还是“提交状态”。** 如果这个不清楚，Agent 产品就会让人迷糊。 ## 二、聊天页为什么必须让 Agent 成为主角 在 AI 酒友小程序里，聊天页是最重要的页面。 因为真正的体验发生在这里：用户说话，Agent 接住，Agent 生成祝酒词，Agent 帮用户整理心情，Agent 引导用户去投漂流瓶或生成记忆卡。 但我们开发时发现，聊天页很容易被做成“功能面板”： - 顶部身份卡太大 - 状态条太多 - 能力按钮太抢眼 - 输入框被挤到底部 - 对话窗口太小 - Agent 回复后不自动滚动 这会让用户感觉自己不是在和酒友聊天，而是在操作一个复杂工具。 后来我们做了调整： - 对话窗口变大 - 顶部信息压缩 - 能力按钮变轻 - 消息气泡更适合长文本 - 发送后自动滚到最新消息 - 输入框始终清楚可用 这背后的原则是： **AI 陪伴类产品，内容区不是展示区，而是关系发生区。** 如果关系发生区被挤压，产品灵魂就会消失。 ## 三、状态闭环：产品不是页面，而是一串状态变化 这次我们另一个重要发现是：页面做出来不等于产品成立。 真正的产品是状态流。 以 AI 酒友为例，用户完整路径应该是： 扫码进入 -> 领取权益 -> 选择场景 -> 选择酒友 -> 对话消耗次数 -> 投出漂流瓶 -> 捞到别人的瓶子 -> 进入社交聊天 -> 申请交换微信 -> 生成记忆卡 -> 回到我的空间。 每一步都应该改变状态。 如果状态没有保存，用户就会觉得产品是假的。 比如： - 扫码领取后，回到我的页看不到次数。 - 发送消息后，次数没有减少。 - 投出漂流瓶后，漂流瓶次数没有减少。 - 生成记忆卡后，记录里找不到。 - 申请交换后，没有等待状态。 - 重复扫码又重复领权益。 这些问题会直接破坏信任。 所以我们后来补了本地状态模块，统一管理： - `credits`: AI 对话次数 - `bottles`: 漂流瓶次数 - `records`: 记忆卡权益 - `claimedCdks`: 已领取瓶码 - `current`: 当前酒款、场景、酒友 - `chatLogs`: 聊天记录 - `thrownBottles`: 投出的漂流瓶 - `caughtBottles`: 捞到的漂流瓶 - `socialChats`: 社交聊天 - `contactVault`: 联系方式保险箱 - `wechatRequests`: 微信交换申请 - `memoryCards`: 记忆卡 这一步做完后，产品才开始像一个真实系统。 ## 四、微信交换：不能做成粗糙交友工具 社交是这个产品里很有想象力的一部分，但也是风险最高的一部分。 如果我们简单做成： “用户上传微信二维码，对方点击同意后直接看到。” 这会很危险，也很粗糙。 因为它会带来几个问题： - 用户隐私被过早暴露 - 对方是否同频还没确认 - 产品像陌生交友软件 - Agent 的边界保护价值消失 - 用户可能对平台不信任 所以我们设计了“联系方式保险箱”。 它的规则是： 1. 用户在我的页保存微信号或二维码。 2. 默认仅自己可见。 3. 社交聊天后，可以申请交换。 4. 申请后不直接发送微信，只进入等待对方确认。 5. 双方都确认后，才同时解锁联系方式。 6. Agent 可以给出判断摘要，提醒是否适合交换。 这套逻辑更符合我们的产品精神： **不是为了让陌生人快速加微信，而是让两个酒友在被 Agent 保护的情况下，确认值得后再建立真实连接。** 这也是 AI 酒友和普通社交软件的区别。 ## 五、商业复购：不要只做一次性体验 很多小程序做完后，有一个问题：用户体验一次就走了。 AI 酒友如果只是让用户扫码体验 5 次聊天，也可能变成一次性活动。 所以商业闭环必须从一开始就设计。 我们这次形成了几个复购点： ### 1. 酒瓶权益 用户买酒，扫码获得： - AI 对话次数 - 漂流瓶次数 - 记忆卡权益 次数用完后，可以继续买酒获得权益。 这让酒水销售有了新的理由：不是只卖酒，而是卖一段 AI 陪伴体验。 ### 2. 充值权益 如果用户已经喜欢这个酒友，可以直接购买更多 AI 对话次数。 这适合高频用户。 ### 3. 复制 Skill 到 WorkBuddy 有自己 Agent 的用户，可以把酒友 Skill 复制到自己的龙虾里，继续养长期酒友。 这样平台不一定承担所有模型费用，也能推广 WorkBuddy。 ### 4. 漂流瓶回应 用户投出瓶子后，会期待有没有回应。 这形成自然回访。 ### 5. 记忆卡回看 用户喝酒时留下的文字、声音、情绪、关系，可以成为回看的理由。 这让产品从“工具”变成“记忆容器”。 商业化不是硬塞付费按钮，而是让用户觉得： **我还想继续这个关系，我还想保存这个时刻，我还想再开一瓶。** ## 六、给虾友的 AI 小程序状态闭环检查清单 如果你也在做 AI 小程序，可以用下面这套清单检查。 ### 1. 用户入口清楚吗？ - 用户从哪里来？ - 扫码、分享、小程序搜索、私域链接分别怎么处理？ - 如果用户不是第一次来，进入哪里？ ### 2. 用户资产清楚吗？ - 用户有什么权益？ - 次数在哪里显示？ - 权益如何增加？ - 权益如何消耗？ - 消耗后用户是否能感知？ ### 3. AI 行为清楚吗？ - 哪些动作是 AI 提问？ - 哪些动作是 AI 生成？ - 哪些动作消耗次数？ - 哪些动作只是跳转？ ### 4. 记录是否沉淀？ - 用户完成一次体验后，留下什么？ - 聊天记录、生成内容、卡片、关系、任务、订单是否保存？ ### 5. 社交是否安全？ - 是否过早暴露隐私？ - 是否有双方确认？ - 是否有撤回、拒绝、等待状态？ - 是否有安全提示？ ### 6. 复购是否自然？ - 用户为什么回来？ - 用完权益后怎么继续？ - 是否和商品、会员、Skill、服务形成闭环？ ### 7. 后台能否承接？ 原型可以用本地状态，但正式产品需要后台： - 用户表 - CDK 表 - 权益流水 - 聊天记录 - 漂流瓶池 - 匹配关系 - 联系方式加密存储 - 交换确认记录 - 内容安全审核 如果这些表想不清楚，前端做得再美也很难上线。 ## 七、下篇总结 AI 小程序真正难的不是页面。 页面只是表面，真正难的是： **交互语义、状态闭环、安全边界和商业复购。** 我们这次做 AI 酒友小程序，最大的收获是：当一个产品里有 Agent、有情绪、有社交、有权益、有记忆时，每个按钮都不只是按钮。 它可能代表： - 用户的一句话 - Agent 的一次回应 - 系统的一次跳转 - 权益的一次消耗 - 关系的一次推进 - 隐私的一次授权 如果这些语义混在一起，产品就会乱。 如果这些语义被拆清楚，产品就会稳。 给虾友最后一句建议： **不要只问页面能不能点，要问每一次点击之后，用户、Agent、系统、状态和商业闭环分别发生了什么。** 这才是 AI 小程序从 Demo 走向产品的关键。