从三天上线到 4000 用户：Nbility AI Gateway 三个月复盘

运营 AI 中转站三个月，我给自己找了五份工作

距离我第一次在博客里正式介绍 Nbility AI Gateway，已经过去 101 天了。

三个月前，我以为自己只是上线了一个 AI 中转站。

三个月后回头看，才发现我实际上给自己找了好几份工作：开发、运维、客服、销售，以及一份以前从没认真做过的财务。

这 101 天里，Nbility 换过域名、升级过服务器，也经历过一次因为数据库没有正确备份而丢失半天数据的事故。

我经常刚准备睡觉，就收到用户反馈；也开始学着放下程序员习惯的技术口吻，尝试向并不了解 API 的客户解释产品。

不过，这段时间的投入并没有白费。

截至目前，Nbility 已经有：

• 4000 多名注册用户
• 每天 100 多名活跃用户
• 一批长期使用的个人及企业客户
• 已经实现盈利

这篇文章不准备写成一份标准的运营报告，也不想只挑好听的部分讲。

我更想记录一下，一个人运营 AI Gateway 三个月，究竟会经历什么。

为什么又做了一次 AI 中转站

这并不是我第一次搭建 AI 中转站。

早在 2023 年，我就做过类似的项目，对模型接入、渠道管理和 API 中转这一套已经比较熟悉。

只是那时候还没有所谓的 Vibe Coding，Codex 和 Claude Code 也不像今天这样火。AI API 更多还是开发者和小范围用户在使用，没有现在这么频繁地出现在各种技术群和朋友圈里。

到了 2026 年，情况明显不一样了。

各个交流群里经常有人问：

• Claude Code 应该怎么用？
• Codex 要怎么配置？
• 为什么官方付款这么麻烦？
• 有没有稳定一点、模型齐全一点的 API？
• 为什么自己申请官方服务会受到地区、支付方式或账号条件限制？

我自己也遇到了同样的问题。

直接使用不同模型的官方服务，账号、支付和配置条件并不总是方便；使用别人的中转服务，花费又比较高，很难拿到接近成本的价格。

既然我熟悉这套系统，也看到了真实的市场需求，那不如自己再做一次。

于是有了 Nbility AI Gateway。

“Nbility”这个名字来自 N + ability。

我希望它不只是某一个模型的入口，而是把不同 AI 的能力集中到一起。用户通过一个账户、一套接口，就能调用不同厂商的模型。

刚开始时，我以为这个项目最大的难点会是技术。

后来才发现，技术反而是我最熟悉的部分。

真正难的是销售。

第一版，我只用了三天

从决定开始做，到第一版正式上线，我实际准备了三天。

这三天里，我没有直接套用 New API 的默认前端，而是借助 AI，把整套前端重新做了一遍。

现在有很多 AI 中转站使用相近的开源系统。打开网站后，页面布局、配色、控制台，甚至按钮位置都差不多。

功能当然没有问题，但当所有网站看起来都一样时，用户也很难记住其中任何一个。

我经常看到有人吐槽 New API 官方 UI 不够好看，而我之前做的几个项目，本身就比较重视界面和使用体验。

所以从一开始，我就没打算让 Nbility 停留在“把开源项目部署起来，换个 Logo 就上线”的状态。

当然，三天做出第一版，并不意味着前端设计真的只需要三天。

它背后是我做了五年前端程序员积累下来的经验，包括组件设计、信息层级、页面节奏，以及对 UI 的判断。

AI 可以帮我更快地写代码，也可以参考一些优秀网站的设计语言，但最后该保留什么、该删掉什么，依然需要人来做决定。

Nbility 的前端最终选择了完全自行重构，后端接口则保持对最新版 New API 的兼容。

这样既能保留成熟系统的接口兼容能力，也不必让用户面对一套千篇一律的界面。

有人出价一万元买这套 UI

Nbility 上线后，陆续有人联系我，希望直接购买这套前端模板。

其中最高的一次出价是：

10000 元人民币。

我最后还是没有卖。

不是价格不合适，而是我担心同质化。

一个独立产品想建立自己的视觉记忆并不容易。如果把模板卖出去，同样的界面可能很快就会出现在十几个甚至几十个站点上。

好不容易建立起来的辨识度，也会随之消失。

所以对我来说，这套 UI 不只是一个可以单独出售的模板，它本身就是 Nbility 的一部分。

接口兼容可以标准化，但产品给人的第一印象，不应该也变成标准答案。

第一批用户，并不是从广告里来的

Nbility 最早的一批用户，主要来自我的朋友圈和过去积累的社区关系。

有程序员朋友注册支持，也有朋友直接帮助搭建和完善程序。我的一位高中同学还给我带来了公司客户，这件事多少有点出乎我的意料。

我也在自己运营了三年的另一个项目群里推广过 Nbility。

那个项目包括 Vmail 和 wr.do。

它们对 Nbility 的帮助，不只是带来了一些初始用户，更重要的是提供了一份信任证明。

AI 中转站有一个绕不开的问题：

用户凭什么相信你？

价格低并不能自动换来信任，界面做得漂亮也不能。

用户会担心服务能开多久，账户余额会不会突然消失，出现问题以后还能不能找到人。

对于一个刚上线的平台，我很难只用一句“我们会长期运营”说服所有人。

相比口头承诺，一个已经持续运营三年的项目，显然更有说服力。

我过去维护 Vmail 和 wr.do 的经历，至少可以证明一件事：

我不是那种做完页面、推广几天，然后就消失的人。

后来，Nbility 的推广渠道逐渐增加，包括：

• 微信里的程序员朋友
• 各类技术社区
• 公众号软文
• 其他网站的横幅广告

表面上看，这些是不同的推广渠道，但它们的底层逻辑其实差不多：依赖个人 IP 和过去积累的社区信任。

如果没有之前几年在社区里的积累，仅仅依靠广告，很难让一个新出现的 AI 中转站迅速获得用户的信任。

从 nbility.dev 换到 nbility.ai

Nbility 最初使用的域名是 nbility.dev。

原因很简单：便宜，而且我对 .dev 很熟悉。

我的博客是 oiov.dev，另一个项目是 vmail.dev。所以在做新项目时继续使用 .dev，几乎是一个下意识的选择。

后来，随着产品逐渐稳定，我还是决定把域名换成现在的：

https://nbility.ai

.dev 更像一个面向开发者的实验项目，而 .ai 与 Nbility 提供的服务更直接，也更容易让第一次接触它的人理解这是一个 AI 平台。

换域名看起来只是修改一个地址，实际牵涉到的事情并不少：

• 网站入口需要迁移
• API 地址需要更换
• 文档里的链接需要更新
• 用户已经保存的客户端配置需要调整
• 过去发布的推广链接也要逐步替换

这次换域名，也成为了 Nbility 三个月发展过程中的一个分界点。

nbility.dev 更像是我先做出来试试的项目。

换成 nbility.ai 后，我开始真正把它当作一个准备长期维护的产品。

从 4 核 8G，到 8 核 32G 和 1T 硬盘

随着用户数量增长，原来的服务器逐渐不够用了。

Nbility 最早运行在一台配置为：

• 4 核 CPU
• 8GB 内存
• 30GB 磁盘

后来，服务器升级到了：

• 8 核 CPU
• 32GB 内存
• 1TB 磁盘

硬件升级本身不算复杂，真正让人紧张的是迁移。

平台里有用户信息、账户额度、订单和调用记录。

普通博客迁移失败，大不了暂时无法访问；但涉及账户和余额的服务，任何数据问题都会直接消耗用户的信任。

这三个月里，Nbility 最严重的一次问题，就是数据库没有正确备份，导致丢失了大约半天的数据。

这件事给我上了一课。

以前做个人项目时，我也知道数据库需要备份。但“知道需要备份”和“确认备份真的可以恢复”，完全是两回事。

备份任务显示成功，不代表数据一定能恢复。

备份文件存在，也不代表它就是一份完整、可用的备份。

幸运的是，Nbility 这三个月里最长的单次停机时间没有超过 20 分钟。但数据丢失带来的压力，并不会因为停机时间短就减少。

从那以后，我对数据库备份、迁移前检查和恢复验证谨慎了很多。

做服务最怕的不是遇到问题，而是在问题发生以前，一直以为自己已经准备好了。

凌晨的运维和客服

现在，我平均每天要花三个小时维护 Nbility。

这些时间并不全是在开发新功能。

更多时候，我是在：

• 检查平台稳定性
• 处理上游渠道问题
• 排查模型调用异常
• 回复用户工单
• 帮助用户检查客户端配置
• 完善平台功能
• 处理只有实际运营后才会暴露出来的细节

半夜处理故障，刚睡下又收到用户消息，已经成了常态。

用户只关心请求是否成功，不会关心背后是哪一家上游出现异常、哪个模型临时限流，或者是哪一条路由出了问题。

这也很合理。

用户付费购买的是可用的服务，技术细节本来就应该由平台处理。

但当开发、运维和客服都是同一个人时，体验就会很奇妙。

上一分钟，我可能还在看日志和数据库；下一分钟，就要回复一位不知道 Base URL 应该填在哪里的用户。

再过一会儿，可能又要和企业客户解释计费方式、并发限制和模型差异。

以前做程序员时，我习惯用技术口吻解决问题。

我总觉得，只要把原理讲清楚，对方自然就能理解。

真正开始做销售后，我才发现，这种想法经常是错的。

客户不一定想听完整的技术原理。他们更关心的是：

• 能不能用？
• 适不适合自己的业务？
• 成本是多少？
• 出了问题谁来处理？

把复杂问题说简单，有时候比把复杂系统做出来更难。

这也是为什么我现在认为，运营 Nbility 最难的部分不是技术，而是销售。

我第一次认真建立了财务账本

做程序员时，我很少认真计算一个项目的完整成本。

服务器花了多少钱，上游 API 花了多少，这些成本比较直观。

但开始运营 Nbility 后，我才发现，成本远不止这些。

为了推广平台，我找过公众号博主发布软文，也在其他网站购买过横幅广告。

除此之外，还有：

• 域名成本
• 服务器成本
• 硬件扩容成本
• 上游 API 成本
• 广告投放成本
• 公众号软文费用
• 其他网站的横幅费用
• 日常维护投入的时间

如果没有账本，很容易产生一种错觉：

账户里有收入，项目就是赚钱的。

真正开始记录每一笔收入和成本后，我才慢慢知道：

• 哪个推广渠道实际带来了用户
• 哪些广告只是看起来热闹
• 哪些模型用量很高，但利润很薄
• 服务器和上游成本分别占多少
• 一次活动究竟是在获客，还是只补贴了原有用户

建立财务账本听起来不像什么值得写进技术博客的事情，但这可能是我三个月里学到的最实用的一课。

一个项目可以凭兴趣开始，但想要长期运行，最后一定要面对数字。

好消息是，Nbility 目前已经实现盈利。

它还没有变成一家需要我全职投入的公司，我仍然把它定义为一项长期服务，也是一份认真经营的副业。

但它已经不再只是服务器上的一个个人实验。

三个月，4000 多名用户

截至写下这篇文章时，Nbility 已经有 4000 多名注册用户，每天有 100 多名活跃用户。

这个数字当然不能和大平台相比。

但对于一个主要由我独立维护的项目来说，它已经超出了最初的预期。

更重要的是，这些用户并不只是注册后就离开。

有人通过 Nbility 使用 Claude Code 和 Codex，有人把 API 接入自己的程序，也有人将它用于公司业务。

不同用户对模型、稳定性、价格和接口兼容性的要求都不一样。这些真实需求，也在反过来推动平台继续完善。

Nbility 目前提供：

• 统一的 AI 模型接入
• 统一的账户额度和计费管理
• 兼容常见的 OpenAI API 调用方式
• 多渠道 Token 管理
• 调用日志与监控
• 图像生成 Playground
• 提示词库
• 邀请与推广返佣功能
• 完全重构的独立前端 UI

前端是独立设计和开发的，接口则保持对最新版 New API 的兼容。

我希望它最终给用户的感觉，不是“又一个中转站”，而是一个愿意长期维护、出现问题能找到人、使用时不需要反复折腾的 AI Gateway。

如果再让我做一次

如果回到三个月前，我还是会做 Nbility。

但我不会再认为，把技术做出来就完成了大部分工作。

技术只是起点。

之后还有稳定性、服务器迁移、数据库备份、用户客服、市场推广、销售和财务。

任何一个环节处理不好，都可能让之前写下的代码失去意义。

这三个月也让我重新认识了“独立开发”这件事。

独立开发并不只是一个人写代码。

它意味着产品里所有暂时没人负责的事情，最后都由你负责。

服务器报警，你负责。

用户不会配置，你负责。

广告没有效果，你负责。

数据库备份出了问题，还是你负责。

它确实很累，但也有一种非常直接的满足感。

每一个页面、每一次修复、每一位愿意留下来的用户，都和你的决定有关。

写在最后

距离 Nbility 第一次出现在我的博客上，已经过去 101 天。

这期间有过增长，也有过事故；有实现盈利时的开心，也有半夜处理故障时的疲惫。

我还不敢说自己已经学会了怎样运营好一个平台，但至少现在的 Nbility，比三个月前更像一个能够长期走下去的产品。

接下来，我还是会继续维护它。

不追求一夜之间做得多大，也不准备依靠夸张的宣传吸引所有人。

先把稳定性做好，把用户的问题处理好，把每一笔账算清楚。

如果你正在使用 Claude Code、Codex 或其他 AI 工具，希望通过一个入口调用不同模型，可以访问：

访问 Nbility AI Gateway

如果你想先体验，可以注册后前往工单支持页面创建工单：

创建工单，申请免费测试额度

通过工单可以免费申请 $5 平台额度，用于测试模型和接口是否适合自己的使用场景。

三个月只是开始。

至于 Nbility 最终能走多远，我想用下一个三个月、下一年，以及更长的时间来回答。