修订说明（v1 → v2）¶

v1（2026-06-03）在 CouCou 产品线信息不完整的前提下完成。当时 Sentino 的产品定位写为「对话式 agent + 一站式交付」，演进路径设计为 Phase 1 转发壳（保壳过渡）→ Phase 2 Sentino app server（终态门面）两阶段 strangler fig。

v2 基于 2026-06-11 与作者的对齐讨论修正，核心定位重写：

1. CouCou 是 Physical AI 版的 Bubble——不是通用 UGC 市集（早期理解有误），是 idol 明星 / IP 方私聊订阅平台的物理化升级。Supply 端是韩日台美 + 海外华语明星（CN 境内 IP 可签约但 fan 服务限海外），demand 端是 fan，对标 Dear U 的 Bubble、HYBE 的 Weverse。
2. 战略升级：Sentino 从「一站式定制服务公司」扩展为「对话式 agent 平台 + Physical AI Bubble 市集」双 SKU 模型，共享同一对外架构。
3. 演进路径：跳过 Phase 1 转发壳，直接走 Phase 2——CouCou 引入的新能力让转发壳过渡变得无意义。
4. 客户类型重构：原「按技术能力切」5 类保留；新增「按商业关系切」维度——B 端定制 vs Idol IP 方入驻（不是长尾 UGC creator）。
5. 双轨付费模型：fan 月订阅（Bubble 模式）+ 头部明星 IP 方走 BD（平台抢入驻、可能 0 抽成换流量）+ 腰部 KOL/vtuber 走 Studio 按量（PLG 补充）。
6. 新增 day-1 纪律：Dogfood public API——CouCou app 跟客户自做 app 用同一套 API。
7. 新增章节：记忆双层架构（fact + narrative，对接 sentino-memex v2.1）、跨境法务与合规（4 司法管辖区 × 真人 likeness × AI 言行）、商业模式参考数据（Bubble/Weverse）。
8. 待决策从 3 条扩到 11 条，按优先级重排——明星 IP 入驻 BD 模板 + 跨境法务授权跃升 #1；memex v2.1 排期新增 #5。

v1 的核心架构诊断（4 层架构 / 7 域 + 1 通道 / 6 个交互场景 / strangler fig 模式）仍然成立——只是终态目标更明确、过渡设计简化。

Executive Summary¶

• CouCou = Physical AI 版的 Bubble：fan 月订阅韩日台美 idol / 明星 / IP 方（CN 境内 fan 不在产品市场范围内，按支付通道天然过滤），AI 化身通过 Plush/Stand/Charm 在物理空间 24/7 陪伴。公式：Bubble 订阅经济 + Vocaloid IP 商业化 + Furby 物理形态。
• Sentino 双 SKU 公司：B 端定制（YUKAI/Jisoo/工厂代工，现金牛）+ CouCou Physical AI Bubble（战略主线、高估值故事）。两条 SKU 共享 Sentino app server。
• 架构共面、API 共享：CouCou app 跟客户自做 app 走同一套 public API，遵循 dogfood 纪律。参考 Stripe / Twilio / Anthropic。
• 双轨付费：
• C 端：fan 月订阅 idol（$4.99 Companion / $12.99 Inner circle）→ 平台 take rate 后分给 IP 方
• Supply 端：头部 idol / 经纪公司走 BD + 商务协议（平台抢入驻、可能 0 compute 费换独家）；腰部 KOL / vtuber 走 Studio 按量（PLG 补充）
• 演进路径：直接跳 Phase 2，不做 Phase 1 转发壳。CouCou 新能力（市集 / 订阅 / 分账 / Sense metering / 3 层记忆 / broadcast）必须 Sentino 自营。
• 战略叙事不是"通用 physical AI 消费端代表"，是"physical AI 在 idol fandom 场景的杀手级应用"——切口窄、深、高付费意愿（K-pop fandom 全球 1 亿+，ARPU 已被 Bubble/Weverse 验证）。
• 核心护城河：①Physical 在场（切换成本远高于 app）②明星 IP 独家签约（Bubble 在 K-pop 圈的位置就是这个逻辑——SM 系全在 Bubble，竞品进不来）
• 待决策 11 条，#1 = 明星 IP 入驻 BD 模板 + 跨境法务授权框架（4 司法管辖区 × 真人 likeness × AI 言行合规）
• 2026-06-11 战略简化：CN 境内 fan 长期不在产品市场范围（按支付通道天然过滤，不接微信/支付宝独立通道）；跨境法务从 5 司法管辖区降至 4（韩日台美），CN 深度合成 / 实名 / ICP 不触发；CN IP 仍可签约

01. 产品定位（v2 重写）¶

v1（错的）vs v2（对的）¶

CouCou 准确定位（一句话）¶

CouCou 是 Sentino 运营的 Physical AI Bubble——fan 月订阅韩日台美 idol 的 AI 化身（CN 籍 fan 限海外、CN IP 可签约但服务 fan 在海外），通过 Plush/Stand/Charm 在物理空间持续陪伴。商业模式公式：Bubble（订阅经济）+ Vocaloid（IP 商业化）+ Furby（物理形态）。

关键差异化（对手地图）¶

战略叙事（融资 / 对外 narrative）¶

不是"physical AI 浪潮的通用消费端代表"——是 "physical AI 在 idol fandom 场景的杀手级应用"：

• 市场已验证：K-pop fandom 全球 1 亿+，HYBE / SM / JYP / YG 上市公司，Bubble/Weverse ARPU 已成熟
• 痛点明确：fan 想偶像、票抢不到、idol 真人带宽有限——AI 化身 + physical 直接 fill the gap
• 切口集中：韩日台美 4 国 idol fandom（CN 籍海外华人 fan 可服务，CN 境内不在 fan 市场范围） 是高付费意愿、跨境复用的市场
• 可融资 story：比"通用 physical AI"更具体、可对标（Dear U 估值 / HYBE 估值 / Vocaloid 商业化）

02. 架构能力地图（v2 增量）¶

v1 的 4 层架构 / 7 域 + 1 通道 全部保留（详见 v1 报告第 2 节）。

CouCou 引入 6 个新域（v1 完全没覆盖），均不可外包，必须 Sentino 自营：

外加 2 个平台运营域（v1 完全没有）： - IP 方入驻 / BD / 商务协议 / KYC / take rate 配置 / 内容审核 / 申诉机制 / 全球分账税务 - 跨境法务合规（4 司法管辖区韩日台美，详见 §09；CN 仅 IP 签约角度涉及）——idol fandom 业务的命门，不是后台 ops 而是核心能力

03. 双 SKU 共架构（v2 新章节）¶

核心纪律：Dogfood public API¶

CouCou app（Sentino 自营 first-party 调用方）跟客户自做 app（Jisoo/Shumon，third-party 调用方）使用同一套 Sentino app server 对外 API。CouCou 不能有「内部特权后门」——典型 SaaS 反模式（对外 API 烂、自家产品好）必须避免。

参考样板：Stripe / Twilio / Anthropic / OpenAI——平台公司 + API-first 服务公司可以共存，核心是 multi-tenant 隔离 + 统一 SLA。

三条必须遵守的纪律¶

1. Dogfood public API：CouCou app 跟客户自做 app 走同一套 api.sentino.jp 公共 API；coucou-server 自身作为 dragonflow 的下游消费方，也只能走公共 API（无直连 workflow-api 数据库 / 私有 endpoint）。等同于任何外部 B 端客户，反向倒逼 API 质量。
2. Multi-tenant 隔离：multi-tenant 边界已经天然落在 workspace 上——api.sentino.jp 按 workspace + API_KEY 隔离 user/agent/memory/chat 数据。CouCou 是一个 workspace，跟 Jisoo/YUKAI 等客户 workspace 完全隔离，无需自造。
3. API SLA 一视同仁：限流、版本管理、deprecation 通知——CouCou 不吃亲儿子特殊待遇

Auth 跟业务的分层（2026-06-11 修正）¶

• Auth 层共享 IdP：CouCou H5 + Studio (workflow-web) + 未来其他客户 app 都直接调 workflow-api /api/auth/*（即 studio.sentino.jp/api/auth/*），同一 JWT issuer。这一层不是"公共 API"模式，是共享 IdP 基础设施——所有人用同一 user 表，跨产品账户天然互通。
• 业务层走公共 API：业务调用（chat / memory / conversation 等）走 api.sentino.jp/api/v1/*，API_KEY 鉴权，workspace 隔离。

为什么 auth 不走 api.sentino.jp？因为 auth 是 IdP 能力（user 身份签发），跟"业务调用"语义不同——workflow-api 既是 IdP 又是业务后端，IdP 接口直接暴露给前端是合理的（Stripe/Auth0/Okta 都是同模型）。

🔄 2026-06-11 修订（auth 直连论证被推翻）：上述「CouCou H5 直接调 studio.sentino.jp/api/auth/*」的论证前提是 6.30 = demo。后续确认 本次 sprint = 公开 launch 免费版，auth 改为全部走 coucou-server 转发 + OAuth 回调接管（方案 A）。launch 阶段三个动机成立：① 统一入口（H5 只认 api-coucou.sentino.jp）② 隐藏 dragonflow（C 端浏览器不可见 studio.sentino.jp）③ auth 挂业务 hook（建 user_profiles / 检测 is_creator / 发欢迎邮件）。「直连合理（Auth0/Okta 模型）」论证在 demo 阶段成立，launch 阶段让位于品牌+安全收益。容量代价：陈玉祥 M1 +2-2.5d，buffer ~3d→~0.5-1d（见 coucou-19day-sprint-staffing v3.5）。完整设计见 coucou-backend-api-design §5。关键工程发现：workflow-api resolveBaseUrl() 用 X-Forwarded-Host header 决定回调域 → OAuth 接管基本不改 workflow-api 源码。

架构图¶

                     ┌──────────────────────────┐
                     │  workflow-api 多功能后端   │
                     │  IdP + Workspace + 订阅    │
                     │  + Agent CRUD + Agora      │
                     │  生产: studio.sentino.jp   │
                     └──┬─────────────────┬───────┘
                        │ 业务暴露经       │ /api/auth/* 直接
                        ↓                 │
              ┌──────────────────┐        │
              │ api.sentino.jp   │        │
              │ 公共 API 门面     │        │
              │ workspace+API_KEY│        │
              └──────┬───────────┘        │
                     │ API_KEY            │
                     ↓                    │
              ┌──────────────────┐        │
              │ coucou-server    │  JWT   │
              │ (薄业务层)        │ 验签   │
              │ + 客户自做 app    │        │
              └──┬───────────────┘        │
                 │ JWT                    │
                 ↓                        │
              ┌─────────────────┐  ┌──────┴──────────┐
              │ CouCou H5       │  │ Studio          │
              │ coucou.sentino  │  │ workflow-web    │
              │ .jp             │  │ studio.sentino  │
              │                 │  │ .jp             │
              │ ← auth 直接调 ────────────→           │
              │   workflow-api  │  │                 │
              └─────────────────┘  └─────────────────┘
                          同一 JWT，账户天然互通

04. 客户类型表（v2 重构为两个正交维度）¶

维度 A：按技术能力切（v1 5 类保留）¶

维度 B：按商业关系切（v2 新增）¶

关键观察¶

• Supply 不是长尾 UGC——是金字塔结构：少量头部明星 IP（BD 驱动）+ 中量腰部 KOL/vtuber（PLG 补充）。这跟 Roblox/UGC 平台逻辑完全不同。
• 维度 A 和 B 正交——Jisoo 这种「自做 app 客户」可以同时是 CouCou 上的 IP 方（双重身份）。
• 头部 supply 的单位经济极高——一个签约 SM 系明星可能带来 10 万+ fan 订阅；长尾 vtuber 可能只带 1000+。BD 投入 + 法务投入完全不同于自助 PLG。

05. 双轨付费模型（v2 重写）¶

收入流总览¶

类比锚定（彻底校准）¶

不是 Roblox / Steam / App Store——这些是 UGC 长尾 + 开发者付平台 compute 的模式，CouCou 不适用（头部 supply 谁付 compute 是反过来的）。

Physical 护城河（双重）¶

1. 物理切换成本：硬件存在意味着用户已经在物理空间承诺（买了 Plush、放在床头），切换成本远高于切换 app

2. 明星 IP 独家签约（更强的护城河）：参考 Bubble 在 K-pop 的位置——SM/HYBE 系明星全在 Bubble，竞品根本进不来。一旦签约头部 idol，经纪公司选 1 个平台合作的惯性意味着竞品 5 年内难撬动

Sense metering 的角色重新理解¶

• 之前误读：Roblox 模型——creator 付 compute 是 PLG 增长杠杆
• 准确理解：Sense metering 是双轨收入计量
• 头部 idol：compute 是平台成本（平台吃 / 反向补贴换独家）
• 腰部 KOL：按量付费，是 PLG 增长杠杆
• 中间灰区：商务协议谈定（按月包流量 / 按演出活动周期定制）

仍然是 Sentino 直接收入计量的核心引擎——只是 metering 出来的数据，付费主体随商业关系不同而不同。

IP 方 / Creator 双账户体系¶

• 付费账户（Studio 消费）：腰部 creator 充值 / 协议预付 → 消耗 Sense；头部 IP 方可能 0 余额（平台垫付）
• 收益账户（CouCou 分账）：fan 订阅 → take rate 后入账

设计决策：是否允许净额结算（earnings 抵 spend）？头部 IP 方走商务协议结算，腰部走净额可能更友好。

06. 演进路径（v2 直跳 Phase 2）¶

v1 设计（两阶段）¶

现在 → Phase 1（转发壳过渡） → Phase 2（终态门面）

v2 决策：跳过 Phase 1，直接走 Phase 2¶

理由¶

1. CouCou 引入的新能力（市集 / 订阅 / 分账 / Sense metering）不可能放进外包业务壳里转一道——Phase 1 转发壳对 CouCou 是无用功
2. Phase 1 核心价值（业务迭代提速）跟 Phase 2 是叠加而非递进——Phase 1 完成后等 Phase 2 上线必废弃，是过渡技术债
3. 直接 Phase 2 让 CouCou + 现有客户都落到终态架构，不需要二次迁移

Trade-off¶

终态架构（2026-06-11 修正：基于 prod 实测）¶

              ┌────────────────────────────────┐
              │  workflow-api（多功能后端）      │
              │  ── Sentino IdP ──             │
              │  • JWT / OAuth2 / User / 注册   │
              │  • Workspace + 角色 + 订阅      │
              │  ── 业务后端 ──                 │
              │  • Agent CRUD                  │
              │  • Agora pipeline              │
              │  生产：studio.sentino.jp        │
              └──┬────────────────────────┬────┘
                 │ 业务接口经             │ /api/auth/* 直接
                 ↓                        │
       ┌──────────────────────┐           │
       │  api.sentino.jp      │           │
       │  公共 API 门面        │           │
       │  workspace+API_KEY   │           │
       │  /api/v1/chat        │           │
       │  /api/v1/memory      │           │
       │  /api/v1/conversation│           │
       └──────┬───────────────┘           │
              │ API_KEY                   │
              ↓                           │
       ┌──────────────────┐               │
       │  coucou-server   │               │
       │  (新增薄业务层)   │               │
       │  • 订阅 / distrib │               │
       │  • creator notes │               │
       │  • agent metadata│               │
       │  api-coucou.     │               │
       │  sentino.jp      │               │
       └──────┬───────────┘               │
              │ JWT 验签                  │
              ↓                           │
       ┌──────────────────┐    ┌──────────┴────────┐
       │  CouCou H5       │    │  workflow-web      │
       │  coucou.sentino  │    │  Studio 前端       │
       │  .jp             │    │  studio.sentino.jp │
       │  ↑                                          │
       │  └─ auth 直接调 workflow-api /api/auth/*   │
       └──────────────────┘    └────────────────────┘
                同一 JWT 在两端共用，账户天然互通

• IoT 平台（api-iot.sentino.jp）：始终由外包，sprint 后接硬件时 coucou-server 加 IoT bridge helper
• Business 转发壳：不存在（跳过 Phase 1）

关键定位（2026-06-11 prod 实测后修正）¶

v2 v1 草稿暗示"一次性 app server + business"是新工程——实际上 Sentino 的关键基础设施都已存在：

prod 实测（2026-06-11 curl 验证）： - studio.sentino.jp/api/auth/registration-config → 返回 {"invitationCodeRequired":false,"googleOAuthEnabled":true}，公开注册开 + Google OAuth 开 - studio.sentino.jp/api/auth/login → 返回标准 401 + JSON，行为符合 SecurityConfig.java - CORS：setAllowedOriginPatterns("*") + allowCredentials=true，跨域调用零阻塞

这意味着：

1. "直接 Phase 2" 不是从零新建 server——是利用既有 workflow-api（IdP）+ api.sentino.jp（公共 API 门面），加 coucou-server 薄业务层
2. CouCou H5 直接调 workflow-api auth API（跨 host 跨域，CORS 已允许），无需自建 auth 系统
3. Studio ↔ CouCou 同账户天然互通——同一 dragonflow user 表 + 同 JWT issuer，"Mia 既订阅又创作"无需 mock 真实现
4. "Sprint 后立刻签 5 个 idol IP 上架"零阻塞——idol IP 方在 studio.sentino.jp 注册 → 创建 agent → 标记 published → CouCou Discover 立刻可见
5. 历史包袱低于预期：Sentino 内部"3 套用户体系"实际是 dragonflow user 表（IdP）+ api-iot.sentino.jp（IoT 端用户）两套，不是 3 套；Sentino API 网关（memovis/api-gateway）只是公共 API 门面层，不独立 user 表

coucou-19day-sprint 是这条演进的第一步——19 天 H5 demo sprint 不动 dragonflow schema，coucou-server 只 own 薄业务层，业务调用走 api.sentino.jp 公共 API，auth 直接复用 workflow-api。

07. IP policy 引擎（v2 重命名 + 重写）¶

商务侧：明星 / IP 方在 CouCou 上架的协议（独家/非独家、take rate、可分发渠道、地域/时间限制、likeness 授权范围）是 case-by-case 商务谈判，不一刀切。Bubble / Weverse 跟头部 idol 谈合作都是逐合同定制。

架构侧：商务说"灵活"，schema 就必须做"可配置"——

• 数据库：IP policy 表，跟 character 表关联，含字段：is_exclusive, take_rate_bps, allowed_channels, geo_restrictions, time_window, likeness_scope, voice_license, behavioral_guardrails
• 运行时：每次「客户自做 app 调用某 character」或「AI 化身生成内容」时，policy 引擎裁决能不能调、按什么计费、有无内容合规约束
• 后台：商务 ops + 法务 ops 团队能在 dashboard 里改某 IP 条款，不需要发版

这一条必须进 Sentino app server day-1 设计。商务弹性 + 法务合规弹性是 idol 业务的核心竞争力。

08. 记忆双层架构（v2 新章节）¶

CouCou 要把记忆展示给 fan（mockup §Memory 已设计——shared / private toggle、add memory yourself、creator-injected）。但 Sentino 当前的 sentino-memex 抽取出的 gist（[gist_xxx] User moved to NY // info | core）是给 LLM context 用的——日志体、第三人称、暴露 tag/id/level，不是面向人的 register。

问题不是"加翻译层"，是 4 件事一起做¶

双层架构¶

┌─────────────────────────────────────────────────────────┐
│ Narrative Layer（新增，CouCou 引入）                     │
│ - human_readable 字段，绑定 fact gist                    │
│ - 三源生成：抽取同步 / fan 编辑 / creator 注入            │
│ - 按 IP 化身风格化（Phase B）                            │
│ - scope: shared cross-character / character-only / global│
└──────────────┬──────────────────────────────────────────┘
               │ 双向关联（编辑反向影响 fact）
┌──────────────┴──────────────────────────────────────────┐
│ Fact Layer（memex 内核，落地 v2 P1 设计）                │
│ - 现有：批提取、TTL/reinforce/merge                      │
│ - v2 P1：memory-as-a-tool（agent 显式写）                │
│ - v2 P1：Memory revisions API + IAM（用户可查/编辑/删）  │
│ - v2 P2 提速 P1：scope 改 arbitrary dict（加 character_id）│
└─────────────────────────────────────────────────────────┘

关键 leverage：memex v2 设计选项已埋好前置条件¶

sentino-memex 在 2026-04 已规划 v2 设计选项（详见 2026-04-28-memex-v2-design-options）： - P1：memory-as-a-tool——agent/外部显式写记忆入口 ✓ CouCou 需要的"fan 编辑 / creator 注入"基础设施 - P1：Memory revisions API + IAM——细粒度访问控制 + 修订历史 ✓ CouCou 需要的"用户可查/编辑/删"基础设施 - P2：scope 改 arbitrary dict——多维 scope ✓ CouCou 需要的 character_id 维度

这三条不是新工程，是已规划工程——CouCou 需求直接把 P2 提速为 P1，三条捆绑成 memex v2.1 阶段交付。详见 sentino-memex 升级。

公共 API 暴露纪律（2026-06-11 修正）¶

跟 §03 "Dogfood public API" 对齐：memex v2.1 三条能力必须暴露在 api.sentino.jp 公共 API 上，不是 dragonflow 内部接口。CouCou 通过公共 API 调用（CouCou workspace + API_KEY），跟其他客户平等。当前 api.sentino.jp 公共 API 已有 /api/v1/memory/cleanup（wipe），但缺以下 4 个：

这 4 个 endpoint 跟 §08 双层架构的工程一并落地——backend 实现在 workflow-api（memex 升级），同步暴露到 api.sentino.jp。CouCou Phase 3 Memory UI 直接调公共 API，不直连。

三阶段工程拆解¶

Phase A（CouCou MVP 必需）： 1. memex v2.1 落地（上面 3 条） 2. 加 human_readable 字段到 gist——抽取 prompt 一次性多出一个字段，零额外 LLM call 3. UI 直接读 narrative，不暴露 gist_id / level / TTL 等元数据 4. 用户 toggle shared/private 直接落在 narrative scope

Phase B（成熟期）： 1. 三源写入完整：被动提取 + user edit + creator inject 2. source 字段：fact + narrative 都标记来源，conflict resolution 按业务定优先级 3. IP 风格化：narrative 生成调 idol voice prompt——同一份 fact 给不同 idol 化身用不同措辞，是 idol 一致性体验关键 4. Creator-injected memory 跨 fan 生效（mockup §Memory "remind fans: new merch drop"）

Phase C（终态）： 1. cross-character memory propagation（Shared 类自动跨角色） 2. Memory 作为 fandom asset："我们的记忆"数量 = stickiness signal，leaderboard / 周年回顾 / 变现抓手 3. 跟 §09 跨境法务对齐：按地域 hard delete + 数据驻留

4 个必须在 day-1 拍板的设计决策¶

1. narrative 同步 vs 异步生成——推荐同步（抽取 prompt 多输出字段，零 LLM call 增量）
2. memory-as-a-tool 跟 user-edit 是同一个入口吗——推荐统一 revisions API + source 字段区分（agent / user / creator），否则两条数据漂移
3. 删除语义——用户删 narrative → fact 也删（hard delete）还是只 hide？直接挂 §09 跨境法务：GDPR / 中国深度合成管理规定要 hard delete，含 reinforce 链关联
4. Conflict resolution——fan 写"我爱花生酱"vs memex 抽"过敏花生"听谁的？默认 user > memex > creator，但要 audit log + 模型读时消歧策略

跟现有架构的对齐¶

• §02 架构能力地图原写"3 层记忆作用域 → Agent SaaS 记忆 art 扩展"——本节是该项的展开
• §07 IP policy 引擎管 narrative 暴露策略（哪些 fact 可暴露、creator 风格 voice 模板）
• §09 跨境法务接 narrative + fact 的删除 / 驻留 / 出境规则
• §11 待决策清单已新增 #11：memex v2.1 排期 + 团队 ownership

09. 跨境法务与合规挑战（v2 新章节，命门级别）¶

idol IP 业务的最大风险不是技术，是跨境法务。4 个司法管辖区 × 真人 likeness × AI 言行合规 × 既有 idol 经纪体系——任意一点滑坡都可能导致单一市场全部下架或 IP 方撤约。

4 司法管辖区主要风险点（中国大陆 fan 不在市场范围内，CN 仅 IP 签约角度涉及）¶

AI 化身言行合规¶

• 口径管理：AI 化身不能说错话引发偶像本人 PR 危机（防止幻觉冒充真人发言）
• 真伪标识：fan 不能把 AI 化身的话当真人，需要明确标识"AI 化身"
• Deepfake 防滥用：禁止 fan 让 AI 化身生成不当内容（NSFW、政治、商业代言）
• Guardrail 系统：mockup 里已经有"Never reveal the surprise collab with Artist X until announced"这种 creator-injected guardrail，需要工程化

跟既有 idol 经纪体系的边界¶

• 经纪公司 / 唱片公司 / 官方 fan club 已有既定生态，CouCou 必须 align 不冲突
• Fan 数据归属：fan 跟 AI 化身的对话归谁？给 IP 方做粉丝洞察 vs 隐私边界？
• 二创禁区：哪些场景明确不能由 AI 化身代理（演唱会 / 见面会 / 商业代言 / 政治表态）

工程化承接¶

• IP policy 引擎（§07）扩展：每条 policy 关联其地域适用性 + 内容合规约束
• Guardrail 系统：plug-in 式合规规则，按 IP 方 × 地域组合
• Audit log：所有 AI 化身生成内容可追溯、可下架、可回滚
• 数据驻留：fan 对话数据按地域驻留（不出境、不跨域）

10. 商业模式参考数据（v2 新章节）¶

CouCou 不是从零探索商业模型——多个对标已经验证 PMF + 公开数据可锚定。

Dear U（Bubble）——直接对标¶

• 上市公司（KOSDAQ 376300）
• 2024 年收入数据、订阅人数、ARPU、毛利率均可查
• 头部 idol 订阅人数集中度、长尾分布
• 韩国 / 日本 / 全球扩张节奏

HYBE（Weverse）——平台规模对标¶

• BTS、NewJeans 等头部 idol 月活、付费转化
• 跨境 fandom 运营模式
• 数字商品 + 演唱会 + 周边的 bundling

Vocaloid V家（Hatsune Miku）——AI 化身合法性对标¶

• Crypton Future Media 商业模式
• 16 年长尾 IP 商业化路径
• 二创许可机制（PCL / NND 体系）

OnlyFans——订阅经济对标¶

• 1对1 强情感连接的订阅 ARPU
• 头部 creator 收入分布
• 平台抽成 vs 推广分成

关键数据点（待补 v2.1）¶

• [ ] Bubble 2024 年付费用户数 / ARPU
• [ ] Weverse 总用户 / 付费转化
• [ ] K-pop fandom 全球总人数估算
• [ ] AI 化身（Vocaloid）商业化总市场规模

11. 待决策事项（v2 重排，11 条按优先级）¶

重排说明：v2 之前的 "Creator 免费额度政策"跌出 top 5——CouCou 的 supply 是金字塔（头部 BD + 腰部 PLG），不是 Roblox 式纯长尾，长尾 PLG 不是冷启动主战场。第一年 BD 拓 5-10 个头部 idol 比拿 1000 个长尾 KOL 更决定平台成败。

12. 对知识库的修正记录¶

待 v2 publish 后，触发以下 wiki 修订：

13. 待验证 / 后续追踪¶

商业模式¶

• Dear U (Bubble) 2024 年完整财报数据（付费用户、ARPU、毛利、地域分布）
• Weverse 跨境运营成本结构
• Vocaloid 二创许可机制是否可借鉴到 CouCou IP policy 设计
• K-pop 经纪公司选 1 个平台合作的惯性强度（Bubble 独占性反例）

法务合规¶

• 4 司法管辖区法律意见书（建议本地律所对接，韩日台美）
• AI 化身代理真人的现行判例（韩国 / 日本 / 美国）
• 经纪公司既有 idol 数字业务的边界条款（合同模板研究）

产品 / 工程¶

• CouCou v3 mockup 跟实际产品规划的对齐度（子昕 / Chris 确认）
• Sentino app server 工程预算（团队 owner、排期、人月）
• 外包合同周期 + 当前谈判窗口
• IP policy 引擎 schema v1 草案
• Guardrail 系统设计参考（Anthropic Constitutional AI / OpenAI moderation）

BD / 战略¶

• 首批可接触的明星 / 经纪公司名单
• 中日韩台美 IP 签约成本估算（中国 IP 可签 + 韩日台美 IP 主战场）
• 跟现有 idol 平台（Bubble / Weverse）的差异化 pitch 文档

引用源¶

一手素材¶

• /Users/momo/Downloads/coucou-app-mockup.html —— CouCou C 端 app mockup v3（836 行，含 Home/Discover/Devices/My 四主 tab，player/creator 双视角；mockup 内 idol 命名如 momo by The Citrus / pip by NOVA / sage by Hana 已对齐 J-pop/K-pop/vtuber 团体命名风格）

上一版报告¶

• wiki/reports/2026-06-03-architecture-business-readiness.html —— v1 工程架构盘点（基线，CouCou 信息缺失版本）

内部知识库¶

• concepts/iot-platform-fundamentals —— IoT 平台 7 域基础
• concepts/iot-agent-capability-bridging —— Agent capability 演进
• concepts/sentino-memex —— Memex 记忆方案
• concepts/china-maas-market-2026 —— Token 经济 / MaaS 市场

商业模式对标¶

• Bubble (Dear U) —— K-pop idol 私聊订阅 app，KOSDAQ 上市，CouCou 直接对标
• Weverse (HYBE) —— 多 idol 社群平台，跨境扩张样本
• Vocaloid V家 (Hatsune Miku, Crypton Future Media) —— AI 化身代理 idol 的合法性 + 商业化先例
• OnlyFans —— 1对1 订阅经济参照
• Furby / Sony aibo —— 物理陪伴硬件参照

架构 / 工程框架¶

• Strangler Fig pattern (Martin Fowler) —— v1 演进设计的理论基础，v2 因 CouCou 引入而简化
• Stripe / Twilio / Anthropic —— API-first 平台公司样板（dogfood public API 纪律）

战略叙事 / 行业对照¶

• NVIDIA Physical AI 概念（Jensen GTC 2025）—— physical AI 浪潮的基础设施叙事
• 宇树 UniStore —— physical AI 在硬件本体侧的同期对照（不同形态）
• K-pop fandom 全球商业化（HYBE / SM / JYP / YG 上市公司财报）