为什么 ByteSpike 自己不做 chat UI

每个多 provider 网关迟早会被问 "你们 chat playground 在哪？" —— 通常紧跟着有人提出要帮我们做。到目前为止我们拒了 5 次。这里讲算账逻辑。

2026年5月15日KL4 分钟阅读

我们这一类网关产品大概一半最终都长出一个 chat UI tab。我们早期决定 ByteSpike 自身不带 chat surface，留在另一个产品（DOSIA）里 —— 网关本体保持 headless。这套跑了 5 个月仍站得住，但被问得够多，值得把推理写下来。

网关内置 chat UI 的成本

多一类用户要服务。Chat 用户跟 API 客户的 SLO 不同（UI 延迟、移动端响应、可访问性）。两类受众抢同一份工程带宽。
功能引力。Chat UI 会一路长出历史搜索 / prompt 库 / 多模态预览 / 多人 thread。每条都是真产品。每条都给网关 repo 加肥而不服务网关本职。
身份模型冲突。网关认 API key；chat UI 想要 OAuth 风格的人类账户。塞一个产品里，每次迭代 auth 代码路径都会悄悄复杂一档。
拖慢网关的本职。今天加一个 Claude / GPT / Gemini 模型到网关只是一条 channel 配置改动。一旦 chat UI 存在，每个新模型都顺带一张 UI 侧工单。

DOSIA。一个独立的 macOS 桌面客户端，跑在网关之上，把我们本来必须塞进网关 repo 的 chat UI 主见落进它：键盘快捷键、role 文件、skill 市场、文件系统原语。同一支团队，不同产品，不同节奏（DOSIA 两周一档，网关随上游协议节拍）。

对不想要桌面客户端的开发者 —— 多数读者 —— 网关从自家代码 / Cline / Continue / Cursor / 任意 Anthropic 风格 SDK / curl 调都成。API 不会因 chat UI 在别处而消失；chat UI 在别处，正是为了让 API 保持干净。

如果你把 ByteSpike 嵌进自家应用，chat 体验你自己塑造 —— 我们不跟你抢那块面。如果你想不写客户端代码就快速评测模型，装 DOSIA 或用 /pricing 上的 curl 例子打网关。两条路网关都是同一个网关、同一份 per-request 语义。

“挑你愿意守的接触面，剩下的做成独立产品，让它们自负盈亏。”

网关内置 chat UI 的成本

多一类用户要服务。Chat 用户跟 API 客户的 SLO 不同（UI 延迟、移动端响应、可访问性）。两类受众抢同一份工程带宽。

功能引力。Chat UI 会一路长出历史搜索 / prompt 库 / 多模态预览 / 多人 thread。每条都是真产品。每条都给网关 repo 加肥而不服务网关本职。

身份模型冲突。网关认 API key；chat UI 想要 OAuth 风格的人类账户。塞一个产品里，每次迭代 auth 代码路径都会悄悄复杂一档。

拖慢网关的本职。今天加一个 Claude / GPT / Gemini 模型到网关只是一条 channel 配置改动。一旦 chat UI 存在，每个新模型都顺带一张 UI 侧工单。

我们改成发什么

对集成方意味着什么

“挑你愿意守的接触面，剩下的做成独立产品，让它们自负盈亏。”