多产品共用 Base - VisibleBase

一个 Base 如何同时服务多个产品，而不把产品差异和基础设施混在一起。

多个产品共用 Base 时，最重要的不是“省一台服务器”，而是把共享能力和产品差异拆开。

应该共享的是：

provider env
模型目录
service 路由
hooks、usage 和日志
user_token 校验能力

应该继续留在产品侧的是：

页面和交互
用户体系
套餐、订单、余额的业务规则
每个产品自己的品牌、定价和定位

一张图看清楚复用边界

产品 A例如网页工具。product_id = prod_web

产品 B例如 Chrome 插件。product_id = prod_extension

产品 C例如客户 Demo 或内部工具。product_id = prod_demo

一个 VisibleBase复用模型目录、provider env、service 逻辑、usage 记录和 hooks。

`product_id` 应该怎么用

product_id 是产品边界，而不是模型边界。

它适合用来表达：

这是哪个产品发起的调用
某个产品是否还处于 active
hooks 应该把 usage 记到哪个产品
某个用户在不同产品里的调用是否要区分

一个常见做法是给每个产品一个稳定的 product_id：

const product = await admin.products.create({
  name: "Chrome Extension",
});

const issued = await admin.tokens.apply({
  product_id: product.product_id,
  user_id: "user_123",
  metadata: {
    plan: "starter",
    channel: "extension",
  },
});

token metadata 适合放什么

product_id 负责“这是哪个产品”，而 token metadata 更适合表达“这个用户在这个产品里的业务状态”。

常见字段：

plan
organization_id
channel
feature_flag
team_id

这样 hooks 就可以基于 ctx.product 和 ctx.user.metadata 做差异化处理，而不需要为每个产品单独复制一套 Base。

多产品共享时的推荐分层

产品侧

保存自己的路由、界面和业务体验
用 UserClient 调 Base
只持有 product_id + user_token

业务后端

负责登录、订单、余额、订阅和业务数据
在可信环境里使用 AdminClient
在登录成功后申请 user_token

Base

负责模型目录
负责 provider 调用
负责 usage 和 hooks
负责可复用的 AI service 逻辑

什么时候应该新建一个 product

这些场景通常值得新建 product：

一个独立的产品或独立市场
需要单独暂停或启用调用
需要单独做 usage 统计或商业策略
需要区分浏览器插件、Web App、客户 Demo 这类不同产品形态

这些场景通常不需要新建 product：

同一产品里的不同页面
同一产品里的不同 feature flag
单个用户的不同会话

这些更适合继续放在你自己的业务系统或 token metadata 里。