这页用于冻结 C2AI2X 当前在 starter 发放 与 widget 入口形态 上的正式判断。
它重点回答 4 个问题：
- 当前 live 状态下，需求侧是否必须先登录 console 才能拿到入口
- widget 当前到底应被理解为独立页，还是站内悬浮入口
- 对外更合理的 starter 产品路径应该是什么
Hosted Inbox / Widget / Console / Full API四层该如何分工
本页聚焦入口形态与 starter 发放口径；运行时 contract、上线状态与 provider settlement / payout / take-rate 规则，仍以各自正式服务与页面为准。
1. 当前最小正式事实
基于当前仓内实现与线上验证，可确认以下事实：
console.zhenrobot.com/integrations当前仍是登录后需求侧 setup wizard。- 当前站点已补出 public starter 发放面：
console.zhenrobot.com/start。 - 当前 public starter 使用受控 admin scope 创建最低配 starter channel，并直接返回 Hosted Inbox 与 widget snippet。
Hosted Inbox当前应理解为独立入口页。Widget Embed当前应理解为嵌入宿主站点页面的悬浮聊天入口。
固定解释：
- 当前 live 状态下，starter 已同时具备：
- 登录后
/integrations - 免登录
/start
- 登录后
- 当前 live 状态下，“使用入口”已经可以发生在 console 外，尤其是
Hosted Inbox独立页和Widget Embed脚本挂载。
- Hosted Inbox：独立链接（托管咨询页）。
- Widget Embed：挂在你的站点上的悬浮入口（默认不要求跳转新页面）。
- Console：用于认领、管理、配置与升级（不是首次接入门槛）。
推荐阅读
Starter 的四步路径
2. 为什么当前状态仍然存在产品摩擦
如果 starter 仍然只剩下：
注册 / 登录 -> 进入 console -> 创建 channel -> 复制 snippet
这一条路，那么：
- 小企业与低意愿客户的初次接入摩擦过高
- “先试运行再升级”的 starter 心智无法成立
Widget Embed会被误理解为“先学会 console 才能用”的能力，而不是低门槛入口
因此，public starter 发放面必须存在；否则 starter 心智会继续被 console 门槛吞掉。
3. 正式产品判断
3.1 starter 入口发放应前置到 console 之前
更合理的默认路径应为：
先生成入口 -> 再挂到站点 -> 再认领到 console -> 再升级配置
而不是：
先登录 console -> 再理解 console -> 再生成入口
固定结论：
- starter 级
Hosted Inbox与Widget Embed应允许先发放，再认领 - console 应主要承担认领、管理、升级和长期运营，而不是第一次接入门槛
3.2 widget 的正确形态是站内悬浮入口
Widget Embed 的标准理解应固定为：
- 悬浮在对方现有官网、落地页、CMS 页或 SaaS 页面之上
- 保留宿主页面上下文
- 不要求用户先跳转到新页面
因此：
Hosted Inbox是独立页Widget Embed是宿主站上的悬浮聊天入口- 若 widget 主要通过跳转新页面来完成承接，它更接近
Hosted Inbox，而不是标准 widget - 在业务前台里，widget 默认应以右下角悬浮关闭态出现，而不是作为页面正文中的常驻展开面板
4. 推荐目标模型
4.1 匿名 starter 发放链路
建议的目标链路如下：
- 外部用户在公开前台或文档站点击“立即生成聊天入口”
- 仅提交最少必要字段
- 网站域名
- 行业 / 垂类
- 联系方式
- 可选入口名称
- 系统立即返回 starter 资产
Hosted Inbox链接Widget Embedsnippet- 基础投放素材或复制入口
- 后续引导用户：
- 认领到 console
- 修改品牌与配置
- 查看 starter 数据与 campaign
- 需要更深集成时升级到
Full API
4.2 匿名 starter 不是完全开放控制权
“先发放，再认领” 不等于匿名用户直接拿到完整平台控制权。
starter 匿名发放只能开放最小能力：
- 基础 channel 生成
- 基础 Hosted Inbox 链接
- 基础 widget snippet
- 极少量 starter 素材
以下能力仍应在认领到 console 后开放：
- 品牌与文案深度配置
- 团队成员协作
- 更高额度
- starter 持久运营面
- 计费、工作区、权限与组织管理
Full APIreadiness / 升级动作
5. 风控与护栏
匿名 starter 发放若上线，必须同时具备以下护栏：
- 域名绑定
- 限制 widget 只能在声明域名或允许的来源上运行
- 额度与限流
- 匿名 starter 只给小额度与基础速率
- 未认领过期
- 未认领 channel 具备 TTL 或功能冻结规则
- 能力分级
- 匿名 starter 只开放最低配入口，不开放完整管理能力
- 认领收口
- 一旦进入长期运营、计费、团队协作或更深配置，必须回到 console
6. 四层分工冻结
6.1 Hosted Inbox
定位：
- 独立托管咨询页
- 最轻接入路径
- 最适合无开发团队
不要求它承担：
- 站内嵌入体验
- 深系统集成
- 完整控制面
6.2 Widget Embed
定位：
- 宿主站上的悬浮聊天入口
- 保留官网上下文
- 面向低代码或轻开发接入
不应被定义为：
- 独立咨询页
- 第二个 console
- 需要先理解平台结构才能使用的重入口
6.3 Console
定位：
- 认领
- 配置
- starter 资产与 campaign 管理
- 升级到更高模式
- 登录后长期运营面
固定解释：
- console 是管理与升级层
- 不应成为 starter 首次发放的唯一入口门槛
6.4 Full API
定位：
- 高级技术接入
- 深流程、权限、状态与系统集成
固定解释：
Full API是高级模式，不是默认起步模式- 只有当接入方已经确认需要深度系统联动时，才应升级到这一层
7. 对公开文档与前台的约束
当前对外表达时，必须同时满足以下要求：
- 不把“目标态匿名 starter”写成已经全面 live。
- 可以明确写出：
- 当前 live：console 登录后开通
- 推荐方向：starter 先发放、再认领
- 必须明确：
Hosted Inbox是独立页Widget Embed是站内悬浮入口
- 不得把 console 误写成 widget 的唯一合理使用方式。
8. 一句话结论
当前最稳的正式结论应固定为：
当前 live 状态下，starter 已同时具备登录后 /integrations 与免登录 /start 两条入口；其中 public starter 只负责最低配发放，长期管理与升级仍应回到 console，而 widget 的标准形态始终是宿主站上的悬浮聊天入口，而不是另起页面。
推荐阅读