PopGenie 白皮书

1. 愿景

PopGenie 希望验证一种本地生活增长模型：轻量游戏先创造参与和共同话题，再把其中一部分用户转化为合作门店的新客与复购顾客；AI 角色只在这条基础链路成立后，用于延展内容和社交。

现阶段不把愿景当作结论。游戏留存、注册转化、到店转化、门店增量毛利与复购必须逐段验证；任何一段长期不成立，都应缩小、调整或停止后续投入。

2. 商业闭环与验证顺序

当前设想的链路是：小游戏触达用户 → 持续游玩并注册 → 积累或使用 KB → 到合作门店消费 → 完成核销 → 再次到店或参与内容。每个箭头都是独立假设，不能用游戏数量、注册量或 KB 发放量代替验证。

1. 先验证留存。 证明至少一个核心玩法能让目标用户按周重复参与，而不是依靠不断增加小游戏维持短期新鲜感。
2. 再验证线上转化。 测量访客到有效游戏、有效游戏到注册、注册到领取到店任务的逐层转化。
3. 再验证线下增量。 用可归因的首购和复购对照，区分平台带来的新增顾客与对门店原有顾客的补贴。
4. 最后扩展 Agent 社交。 只有基础留存和门店经济成立后，才评估 AI 角色内容能否提高参与频次与复购，而不是把它预设为增长引擎。

阶段原则：上一段达到预先写明的门槛，才进入下一段。未通过时先修正假设，不用更多功能掩盖漏斗问题。

3. 用户价值、留存与北极星指标

15 个已上线网页游戏和 10 个概念项目代表内容供给，不代表用户需求。2048、问答和寻宝可以承担获客或活动入口，但长期留存必须来自可重复的核心循环，例如周期任务、好友协作、城市主题赛季或持续进展；具体机制由实验数据决定。

POC 北极星指标：每周完成至少 2 次有效游戏会话的活跃用户数（Weekly Retained Players）。有效会话必须满足最低参与时长或完成条件，并排除刷新、脚本和重复结算。

配套漏斗固定跟踪：访客→有效游戏率、有效游戏→注册率、次日/7 日/30 日留存、人均每周有效游戏次数、注册→领取到店任务率、任务→到店核销率、首次核销→30 日再次消费率。

具体目标值不在没有基线时虚构。封闭测试前写入样本量、观察窗口和继续/停止门槛；测试结束后公开实际结果与口径，再决定是否增加内容。

4. 门店价值与单位经济

合作门店买单的理由只能是可测量的增量收益，而不是“进入虚拟世界”的叙事。试点必须明确免费咖啡或折扣由谁承担、平台如何收费、兑换条件、结算周期、退款规则以及作弊损失的责任归属。

单个门店月净增量收益 = 新增顾客毛利 + 复购提升毛利 − 平台费用 − 权益兑换成本 − 门店运营成本 − 作弊与误判损失。

新增顾客必须通过活动码、首购标记或对照组归因；门店原有顾客领取奖励应单独列为补贴成本。KB 不直接承诺“任意门店免费咖啡”，每项权益由具体门店设定库存、有效期、最低消费、兑换所需 KB 与单用户上限。

Phase 2 默认采用小规模、封顶预算的按有效核销试点。只有门店净增量收益在约定观察期内为正、门店愿意续约且用户复购改善，才测试年费、营销服务费或交易抽佣等长期收费模式。

5. 到店凭证、反女巫边界与成本

咖啡消费最多提供一次到店参与凭证，并可作为低强度反女巫信号：某个账户或设备在某时段完成了门店认可的消费或核销。它不是 KYC 的替代品，也不能证明法定身份、一人一号、设备未转交或用户没有控制多个账号。

对外文案不得再使用“咖啡小票替代 KYC”或“证明你是真实的人”等表述。准确口径是“低数据的到店参与验证”；需要实名、年龄、支付或监管合规的场景仍使用相应的法定流程。

验证强度必须与可兑现价值匹配。低价值内部 KB 优先使用门店一次性核销码、服务端幂等记录、频率限制和人工抽查；不默认同时部署 POS、50 米围栏、图像识别、设备指纹和图片哈希。

只有当作弊损失已被量化，且增加一层验证所减少的预期损失高于其接入、隐私、客服和门店操作成本时，才升级验证。高价值权益另行评估 GPS 模拟、图片复用或生成、多账号、设备绕过、店员串通、接口伪造和核销码转卖风险。

6. 架构

当前 POC 由五个可独立演进的层组成：

• L1 静态体验层 —— 主页、世界目录、社区展示、白皮书与 15 个网页小游戏。
• L2 本地 Guest 状态 —— 浏览器保存 KB、棋盘与支持本地进度的游戏数据。
• L3 可选账户 API —— Node.js 会话、邮箱登录、Guest 升级与跨设备恢复；当前 GitHub Pages 部署不运行此层。
• L4 权威结算与数据 —— PostgreSQL 钱包、幂等游戏结算、问卷发布与历史记录；待服务器恢复后启用。
• L5 Agent 适配层 —— A2A 会话、工具权限与审计接口；OpenClaw Gateway 仍在规划中，尚未接入。

横跨各层的共同约束包括：最小化数据、明确的 Guest / 登录边界、服务端权威结算、失败时可降级以及可审计的 Agent 工具调用。

7. 路线图与商业门槛

• Phase 1A · 当前基线。 运行 GitHub Pages Guest 版与 15 个网页游戏，统一埋点口径，建立有效游戏、留存和注册漏斗基线。
• Phase 1B · 留存验证。 恢复账号与权威结算，选择 1–3 个核心玩法做封闭测试；只有达到预先登记的周留存门槛才进入门店试点。
• Phase 2 · 单店商业试点。 用封顶权益预算和最轻核销方案，测量新客归因、到店转化、30 日复购、单店净增量收益和作弊损失。
• Phase 3 · 内容与 A2A 实验。 在基础闭环成立后，以对照实验判断 Agent 内容是否提升周参与和复购，并建立权限、审计与安全降级。
• Phase 4 · 扩店或停止。 仅在用户留存、门店净增量收益和续约意愿同时成立时扩店；否则调整权益与产品，或停止线下模式。

8. 风险与边界

1. 🔴 留存不足。 游戏可能只有短期新鲜感；内容数量不能替代稳定的重复参与。
2. 🔴 门店经济不成立。 奖励可能补贴原有顾客，或兑换、运营与作弊成本超过新增毛利。
3. 🔴 验证错配。 低价值奖励可能承担过高验证成本，高价值奖励又可能吸引超出当前能力的攻击。
4. 🔴 身份表述与合规。 到店凭证不能被宣传为 KYC 或一人一号证明；位置、照片和 Agent 会话仍须最小收集、明确授权和可删除。
5. 🔴 服务与结算。 Guest 数据只存在当前浏览器，部分结果仍依赖模拟策略；真实权益上线前必须启用服务端权威记录与异常处理。

当前页面中的 A2A 对话属于浏览器内规则与剧情模拟，不代表 OpenClaw 或其他真实 Agent runtime 已上线。

9. 试点前必须锁定的决策

进入线下试点前，以下项目必须写入一页式试点协议并由产品、门店和运营共同确认：

• 用户实验 —— 目标人群、核心玩法、样本量、观察期、指标口径与继续/停止门槛。
• 门店合同 —— 权益成本承担方、平台费用、预算上限、归因方法、结算与退款规则。
• 兑换规则 —— 权益价值、所需 KB、最低消费、库存、有效期、频率限制和跨店范围。
• 验证与风控 —— 最小可用核销流程、异常阈值、人工复核、作弊损失承担与升级条件。
• 负责人和预算 —— 数据、门店合作、客服、基础设施、安全与线下运营的负责人和成本。

白皮书不预设这些答案。试点的任务是用有限预算找到答案；未定义成本承担、指标门槛和退出条件时，不上线真实可兑换权益。