前言

2026 年 9 月起，GitHub 上一批新项目突然爆发式增长：把腾讯 CodeBuddy / WorkBuddy 的账号包装成 OpenAI 兼容 API，再配上 Web 管理面板做账号池。代表性的是这两个：

两个仓库都是 9 月中旬创建、一个月内涨到数千星，标签里写满了 reverse-proxy、openai-api、account-manager。对想省钱用上大模型 API 的人来说，吸引力很直接：注册个免费账号，扫个码，就能在自己的客户端里用上「兼容 OpenAI 格式」的接口。

但这篇文章不教部署。 我要做的是另一件事：把这两个项目自己在 README 里写下的内容当作证据，逐条算清楚这笔账——省下的钱，和你要押上去的东西相比，到底值不值。

先看它们自己怎么说

这两份 README 的信息量，比任何第三方分析都大。

证据一：主项目已经自己停维护了

workbuddy2api-panel 在 README 顶部用醒目块写明：项目已停止维护（2026-10-21），不再更新代码、不跟进上游变化、不再处理新的 issue/PR。给出的三条原因，值得逐字读：

1. 上游已开始禁用反代——WorkBuddy 对非官方客户端的识别与拦截正在收紧（通道校验、账号限制等），反代通道的稳定性与存续周期已不可控，继续做适配意义有限
2. 一人精力有限——这是一个人的自用工具，无力长期跟进协议变化与风控对抗
3. 非法转售泛滥——发现大量批量注册小号、对外售卖额度、二次加壳 / 卡密分发的滥用行为，与本项目初衷完全相悖

它还明确写了一句：「因使用非官方客户端导致的账号风控 / 封禁，由使用者自行承担。」

这三点等于把这类项目的生命周期判决书写在了脸上：上游在查、作者跑了、生态里全是转卖的人。

证据二：上游仓库已经删除了

同一个 README 里还有一条：本项目是 Sliverkiss/workbuddy2api 的增强分支，而上游仓库现已删除。

一个被上游删除的项目，说明什么？说明平台方的态度已经明确了。你现在照着任何一个 fork 部署，等于在一个已经被官方盯上、原作者已经撤掉的通道上继续跑流量。

证据三：免责声明把灰产路径写全了

workbuddy-manager 的 README 里有这样一段使用边界：

仅可用于管理本人及亲属自愿授权的账号；禁止批量注册、账号交易、代注册、接码、盗号、绕过平台风控，以及任何商业转售或盈利性用途。

需要专门写这么长一串「禁止」，本身就说明了这个生态里实际在发生什么。代注册、接码平台、账号买卖——这些不是边缘现象，是这类工具的主要使用场景之一。

证据四：赞助商是住宅代理，这就是风控对抗的成本

最耐人寻味的一条：workbuddy-manager 的 README 顶部挂着一个住宅代理服务的赞助位，并解释了用法——在代理的用户名里写上国家、城市和会话名，每个实例走一个住宅 IP，最长 72 小时不变，换 IP 也留在同一城市。

为什么一个「账号管理工具」需要给每个账号配一个独立住宅 IP、还要保持城市一致？

答案不言自明：因为同 IP 多账号是最典型的批量行为特征，会被风控识别。这段赞助文案，实际上是一份「规避平台风控的技术需求说明书」。

这也顺手回答了成本问题：想稳定用这套东西，你还要额外买住宅代理（赞助码还打着 7 折）。省下的订阅费，先要扣掉一笔代理费。

五类风险逐条算账

1. 账号风险：封号是设计内的结果，不是意外

这类网关的本质是用非官方客户端模拟官方流量，去访问平台的私有接口。平台的服务条款通常明确禁止：自动化访问、接口逆向、账号出借或共享、批量注册。三类行为叠加在一起，被封不是「运气不好」，而是迟早的事。

更麻烦的是连坐：多数人用的腾讯账号是同一个账号体系，一旦因为这个通道被标记，影响范围可能不止于 CodeBuddy。

2. 凭据风险：扫码纳管等于交出登录态

「扫码纳管」听起来无痛，实际操作是把账号的登录凭证 / 会话令牌交给一个 Web 控制台，由它在后台代表你发请求、签到、保活。

那么问题来了：你把凭证交给了谁？

• 一个 2026 年 9 月创建的仓库
• 一个自述「近期 issue/PR 处理、代码审查、测试与修复实现大量由 AI 辅助完成」的项目
• 一个上游已经被删除、主分支已经停维护的生态

这些描述并不意味着作者有恶意——但审计难度是客观的。代码量不小、AI 代写成分高、更新频繁、还带一键自动更新。任何一处后门或漏洞，代价是别人拿着你的登录态为所欲为。这类凭证往往无法用「改个密码」简单止损，因为会话令牌可能已经长期有效。

3. 供应链风险：签名校验证明不了「作者可信」

workbuddy-manager 强调「带签名校验的一键更新」。这是好设计，但要理解它到底保证了什么：

• 它保证：这次更新确实来自同一个作者，没被中间人篡改
• 它不保证：这个作者是可信的

信任锚点仍然是人。而这个人是匿名 ID、项目一个月新、二进制发布、还会自动更新——这是供应链攻击面里最难审计的一种组合：你运行的是一份没有可复现构建、随时会被替换的二进制。

4. 稳定性风险：协议一改，全部归零

私有接口是逆向出来的，没有任何兼容承诺。平台改一个字段校验、加一层设备指纹、换一次签名算法，你的网关立刻 502。

这件事已经发生了：主项目 10 月 21 日停更，理由第一条就是「上游已开始禁用反代」。你花几小时部署好的东西，可能明天就变成一堆报错的日志——而那时你已经把工作流搭在它上面了。

5. 成本与合规：省的钱可能还没赔的多

把账算全：

在个人娱乐场景，最坏结果是损失一个账号。但如果这被用在任何有交付责任的地方，赔的就不只是订阅费了。

为什么这类项目注定活不长

这不是道德判断，是结构判断。这类项目同时要对抗三件事：

1. 协议变更：私有接口没有稳定性承诺，平台每次发版都可能让你的实现失效
2. 风控识别：对话补全类产品的账号共享，是最容易被行为特征识别的滥用类型——同 IP、异常频率、非官方客户端指纹
3. 生态自毁：一旦有人开始批量注册、卖卡密，平台就会收紧到「所有人一起死」，这正是主项目停维护的第三条原因

三段式结局几乎固定：火 → 收紧 → 弃坑。你选择进入的时间点，决定了你要不要经历最后那段。

如果你已经上手了：止损清单

不写操作步骤，只列原则：

1. 把主账号摘出来——任何长期使用、绑定真实业务或个人资料的账号，不要放进任何账号池
2. 不要接生产流量——把它当玩具，别让任何有交付期限的事依赖它
3. 清理授权——检查该账号的登录设备与授权记录，发现不认识的就下线；必要时改密码
4. 不要转售、不要代注册、不要接码——这几件事已经从「违反 ToS」跨到可能涉法的区间
5. 做好随时关停的心理准备——不要在这条通道上构建任何你无法承担中断的流程

更划算的合规替代

如果你的真实需求是「用便宜的 API 额度调大模型」，有两条正路：

路线一：官方 API + 自建网关。 用官方发放的 API Key，在自建网关上做多 Key 轮询、限额、日志、模型映射——该有的工程能力一样不少，而且不涉及任何账号共享。同类开源网关（如 new-api、one-api 系）成熟度和社区支持都远好于一个两个月新的逆向项目。本站此前写过 ai-gateway 的部署教程，就是这个思路。

路线二：把官方额度用足。 各家都有新用户额度、学生认证、低价档模型（Flash / Lite / Mini 系列）。日常写代码、跑脚本，用便宜档位的官方 API，实际花销经常低于「订阅费 + 住宅代理 + 踩坑时间」的总和。

核心区别只有一句：官方 Key 是授权给你的，账号池里的凭证是借来的。 授权的东西可以长期规划，借来的东西随时会被收回。

评估任何「账号池 / 反代」项目的五问

以后再遇到类似的工具，按这五条过一遍，基本能判生死：

1. 它访问的是官方公开 API，还是逆向的私有接口？ 后者没有兼容承诺
2. 它需要我交出什么？ 只要涉及登录态、Cookie、扫码授权，就要按「交出账号」的严重程度来评估
3. 它的更新机制是什么？ 二进制 + 自动更新 = 把执行权限长期授予一个匿名作者
4. 它自己的 README 有没有写「禁止批量注册 / 商业转售 / 绕过风控」？ 写了，说明这就是它的主要用途
5. 它活了多久、上游还在不在？ 一个月新 + 上游已删除 = 别把任何重要事情放上去

小结

这两个项目本身不算「恶意软件」，作者也明确写了自用定位和禁止转售。但它们所依附的模式——逆向私有接口 + 账号池 + 自动化保活 + 住宅代理规避风控——注定是一笔短命的生意：

• 技术上：上游一改协议就失效，主项目已经停更
• 账号上：封号是设计内的结果，还会连坐同账号的其他服务
• 安全上：登录态托管给一个 AI 大量代写、上游已删库的新项目
• 成本上：省下的订阅费，要先付给住宅代理和踩坑时间

如果你的目的是「便宜地用上大模型」，答案从来不是把别人的账号变成你的管道，而是用官方 Key 搭自己的网关——同样是工程活，但这个网关明天还在。

参考

• workbuddy2api-panel（GitHub，已停止维护）
• workbuddy-manager（GitHub）
• One API（开源 OpenAI 兼容网关）
• New API（开源大模型网关）
• 腾讯云 CodeBuddy 官网
• 本站：AI Gateway 部署教程（自建网关思路）

推荐链接

• 大佬CM博客
• 大佬周润发博客
• 大佬青云志博客