别再只会 fork：我把 sub2api 改成了自己的 AI API 产品，并真的跑起来了

很多人以为，基于一个成熟开源项目做二次开发，本质上不过是“换个 Logo、改几个配置、搭个自己的站”。我越来越觉得，这种看法既低估了成熟代码库的价值，也低估了 AI 在工程改造里的爆发力。

我最近做的一个很具体的实验，就是 fork 了 sub2api 这个项目，然后不是停留在“部署一个现成系统”，而是持续用 AI 去理解它、拆解它、改造它、补能力，最后把它真的做成了我自己的 API 产品：

BenszAPI： https://api.benszresearch.com

这件事对我来说最有意思的地方，不是“我又做了一个站”，而是我越来越确认了一件事：AI 最有杀伤力的场景之一，不是从零写 demo，而是接管一个已经很成熟、很复杂、很有历史包袱的代码库，然后把它往你真正想要的产品方向狠狠干过去。

sub2api 给我的，不是一个模板，而是一个足够成熟的底盘

先说清楚一点：sub2api 本身不是一个空架子。它已经有相当完整的 AI API Gateway 能力，包括多账号管理、API Key 分发、精细计费、调度与并发控制、后台管理界面，以及围绕订阅额度分发的一整套基础设施。

也正因为它足够成熟，所以我一开始就没有打算“另起炉灶，重写一遍”。那条路听起来很英雄，实际上往往意味着你要把大量时间砸进那些并不构成产品壁垒、但又绝对绕不过去的底层重复劳动里。

我真正想做的，是拿这个成熟底盘当作起点，然后把产品定义权拿回来：保留它已经验证过的通用能力，把真正体现我判断的部分，全部往前推。

这也是为什么我会说，这不是简单的 fork，而是一条逐渐独立出来的产品分叉线。

从当前仓库差异来看，这条分叉线已经不是象征性的：相对 fork 时与上游的共同基线，我这边这轮改造一共涉及 64 个文件、5659 行新增、82 行删除。而且更重要的是，这些改动不是零散补丁，而是非常明确地围绕产品闭环在推进。

我到底改了什么？

我先把“能不能卖”这件事补成了真正的产品闭环

如果你只是把一个开源网关跑起来，它最多只是“技术上能用”。但一个真正的产品，不能停在“能用”，而是必须解决：用户怎么付费、怎么买、买完怎么生效、异常时怎么恢复、后台怎么管理。

围绕这一点，我在 fork 里最核心的一轮改造，就是把内置支付 + 用户自助订阅这条链路真正打通了。

这里面不是表面上多一个支付按钮那么简单，而是补了整套会直接影响线上体验的关键约束：

只允许合法、激活中的订阅分组出现在可售套餐里，避免后台配置一乱，前台直接卖错东西
用户可以通过内置支付链路直接购买或续费订阅，而不是再绕一套外部系统
当第三方 webhook 延迟或丢失时，等待页会主动做订单核验恢复，尽量避免“明明付了钱却卡在那里”的经典烂体验
后面又继续补上了余额直接购买订阅的能力，而不是逼着用户每次都再走一次第三方支付
同时修了订阅有效期单位、套餐管理页展示、管理员入口显隐这些很容易把产品做残的细节

这类改动有个共同特点：它们看起来不如“接了一个新模型”那么炫，但它们决定了一个站点究竟是个展示页，还是个能真的跑业务的产品。

换句话说，我不是只想把 sub2api 部署出来，我是想把它推进到真的可以承接付费用户的状态。

我没有满足于“功能能跑”，而是把它重新长成了 BenszAPI

另一个我非常在意的点，是品牌和首页表达。

很多 fork 项目做完之后，技术上已经不是原来的东西了，但用户一打开页面，仍然感受到的是“别人家的系统”。这种撕裂感非常强，也会直接削弱产品认知。

所以我没有把首页当作一个无关紧要的皮肤问题，而是专门围绕 BenszResearch / BenszAPI 做了一轮明显更产品化的重构：

补了专门的首页设计参考和 prompt 沉淀
重写了首页 CSS 设计系统
把原本偏暗色的视觉方向，又进一步切成了更适合当前品牌表达的亮色版本
通过站点设置里的 home_content 能力，把首页从“默认网关落地页”推进成更明确的产品入口

现在你打开 https://api.benszresearch.com，看到的已经不是一个泛化的 Sub2API 实例，而是明确在表达这件事：

这是 BenszAPI
它想做的是 AI API Gateway
它强调的是多模型统一接入、Agent 工程化、科研写作增强这些属于我自己的方向

而且从线上站点当前公开配置就能看出来，这不是一张空首页：目前它已经启用了注册、邀请码、TOTP 双因素认证、Turnstile、人机验证、支付能力，并且在自定义端点里显式暴露了 CC Switch - Codex 这样的入口。

这说明我做的事情不是“把 upstream 界面换个颜色”，而是在把整套系统逐渐改造成服务我自己业务结构的站点。

我把“能发布、能维护、能补发镜像”这套工程后勤也补齐了

很多人做 fork，只盯功能本身，但真正折磨人的，经常不是功能，而是后面的发布维护。

所以我在这个分叉里做的第三块关键改造，是把版本驱动的发布自动化也补了起来：

新增版本同步检查 workflow
新增从 VERSION 文件自动创建 GitHub Release 的流程
新增 Docker 镜像自动发布与缺失镜像补发链路
补了本地验证脚本和 Makefile 入口
连 GitHub 仓库该怎么配置 secrets、variables、actions 权限，都补成了教程文档

这类工作很少会被外部用户看见，但它极其关键。

因为只有当 release、镜像、版本号、文档这些东西开始形成闭环，一个 fork 才真的具备了“持续演进”的工程能力。否则你今天能改，明天能跑，后天就会被发布过程和环境漂移反噬。

说得再直白一点：我不是只想把代码改爽，我是想把这条产品线养活。

我还补了真正有运营价值的通知机制

再往后走一步，就是产品不是只有代码和支付，还得有运营视角。

因此我后来又补了一块我认为很实用的能力：新增用户订阅后，管理员可以收到专门的邮件通知。

这个能力背后也不是简单地 send mail 一把，而是考虑了几个产品层面的现实问题：

单独配置“管理员订阅通知邮箱”，而不是和其他系统邮件混在一起
默认可以留空关闭，避免误发
继续走异步队列，不阻塞订阅开通主链路
邮件正文里不只是告诉你“有人买了”，还会尽量带上用户、分组、订阅状态和容量判断线索

这件事的重要性在于，当你开始真的运营一个 API 产品时，你会发现“知道刚刚发生了什么”本身就是一种基础能力。它会直接影响你后续的客服响应、资源调度和容量预判。

这次尝试最让我兴奋的，不是功能，而是方法论被验证了

如果把这次事情抽象一下，我真正验证到的其实是一个非常重要的方法：

基于成熟代码库做定向分叉，再让 AI 深度参与理解、修改、测试、文档、发布和产品打磨，这条路完全可以跑出自己的产品。

我越来越不相信“只有从零写出来的东西才算自己的东西”。

真正决定一个产品是不是你的，不是第一行代码是不是你敲的，而是：

你是否理解底层系统在干什么
你是否能判断哪些地方该保留，哪些地方该重写
你是否能持续把系统往自己的业务目标上拧
你是否有能力把改动沉淀成测试、文档、发布流程和稳定的运维闭环

在这个意义上，AI 给我的最大帮助，也不是“自动生成代码”这么浅的一层，而是它极大放大了我对复杂成熟项目做定向理解和快速改造的能力。

以前很多人面对一个大型开源项目会退缩，不是因为想法不够，而是因为读懂成本太高、改动风险太大、验证链路太长。

现在这件事开始变了。

你可以用 AI 帮你读上下文、追调用链、补测试、写计划、修文档、梳发布流程、做 UI 重构。最后留下来的，不再只是“AI 写了几段代码”，而是你真的把一个成熟系统变成了自己的东西。

我觉得这才是真正有意思的地方。

不是“AI 替你开发”，而是AI 让你对成熟软件的接管能力，第一次变得如此具体、如此便宜、如此凶猛。

如果你也在考虑：要不要基于一个已经很成熟的开源项目，做出属于自己的产品版本，那么我的答案已经越来越明确了：

完全值得。前提不是你要从零重写一切，而是你要敢于拿回产品定义权。

项目 GitHub：

https://github.com/huangwb8/sub2api

上游参考项目：

https://github.com/Wei-Shaw/sub2api