理解 VisibleBase
产品模型
为什么 VisibleBase 是一个可复用的 AI ServerBase，而不是每个项目都重建一套后端。
VisibleBase 最核心的心智不是“一个产品对应一个后端”，而是：
一个长期运行的 Base，服务多个 AI 产品。
这样做的原因很简单。真正被重复建设的，通常不是你的业务后端，而是 AI 调用这一层：
- provider key 存放
- 模型目录
- token 校验
- usage 记录
- hooks、限额、扣费和日志
这些能力一旦你开始做第二个、第三个 AI 产品，就会反复出现。
一个 Base，多个产品
产品 A网页工具、内容产品、工作流小工具。
product_id = prod_a产品 BChrome 插件、桌面工具、移动端入口。
product_id = prod_b产品 C客户 Demo、内部工具、行业专题站。
product_id = prod_cVisibleBase共享模型目录、provider env、service 路由、token 校验、usage 和 hooks。
什么应该留在 Base
- 模型目录和 provider 配置
user_token校验text()、stream()、image()这类 service 调用能力- usage 记录、日志、限额和商业 hooks
- 多个产品可以共用的调用逻辑
什么继续留在产品或业务系统
- 用户注册、登录和账号体系
- 订单、订阅、余额和 CRM
- 页面、交互、工作流和内容数据
- 每个产品自己的品牌、定价和市场策略
换句话说，VisibleBase 集中的是“AI 基础设施”，不是“全部业务系统”。
为什么这比“每个项目一个后端”更稳
如果你每做一个新产品都复制一套 AI 后端，很快会遇到这些问题：
- provider key 分散在多个地方
- token 规则不一致
- usage 和日志口径不统一
- 新 provider、新模型、新限额策略要改很多 repo
把 AI 调用层收敛到一个 Base 后，新产品通常只需要做两件事：
- 新建一个
product_id - 在产品侧接入
UserClient
product_id 在这个模型里代表什么
product_id 不是模型名，也不是租户系统的全部抽象。
它更像 Base 看待“产品边界”的主键，用来回答这些问题：
- 这是哪个产品发起的调用
- 这个产品是否处于
active状态 - hooks 和 usage 应该按哪个产品维度记录
- 一个用户在不同产品里的调用是否需要区分
如果你在做多产品组合，product_id 是最稳定的边界。
model 在产品层里的角色
当前实现里，model 是数据库里的全局目录项，不属于某个 service，也不属于某个 product。
对产品来说，model 更像“可见能力”：
- 可以显式传给
client.text({ model }) - 也可以不传，让
service.default()补齐 query fallback
这意味着产品端看到的是稳定模型 ID，而不是上游 provider 的具体细节。