手搓通用API节点：当BizyAir停服之后

一、停服，是危机也是转机

2026年6月底，我像往常一样打开 ComfyUI，准备用 BizyAir 的 NanoBanana2 节点出几张白描线稿——结果控制台刷出一片红：

[BizyAir] API Error: 503
"Service permanent shutdown"

每次启动浪费 42 秒重试，疯狂报错。不是网络问题，是服务真没了。

316寝室聚会刚搞完，几张白描线稿还是用 BizyAir 赶出来的——没想到那成了它的遗作。

更关键的是：这件事暴露了一个更深层的问题——我一直依赖别人写的"一键节点"。有人维护就岁月静好，一旦停服就手足无措。这种"黑盒依赖"在一个 AI 工具日新月异的时代，简直是定时炸弹。

二、探索：从迷茫到开窍

最开始的想法很朴素：找个替代节点。搜到 GrsAI，装上试了两下，生成成功了一张图，但体验极其不稳定。而且 GrsAI 本质上和 BizyAir 一样——都是"别人的一键烤箱"。

真正让我开窍的，是从二哥那儿弄明白了一个根本概念：

    ComfyUI 里调用 AI API 有两种方式：

    方式一：别人写好的专属节点（GrsAI、BizyAir 都是这种）→ 你只管放食材、调温度，烤箱坏了你就抓瞎。

    方式二：通用 HTTP 节点 + 直接调 API → 你自己拼零件，任何 API 都能接，烤箱坏了换一个就行。

弄明白这个逻辑之后，问题就变成了：能不能手搓一个通用节点，不管用哪个 API 服务商，只要填 URL、填 Key、填 JSON 模板就能出图？

二哥："能。"

我说："开干。"

三、踩坑实录：通往成功的路总是曲折的

坑 #1：ComfyUI 的"两个家"

我以为 ComfyUI 的工作目录是 Documents\ComfyUI\，把节点放那儿，重启一万次都找不到。后来发现 ComfyUI Desktop 实际运行路径是：

C:\Users\sy10sd1\ComfyUI-Installs\ComfyUI (4)\ComfyUI\

这个路径是从控制台日志里"(.venv) PS C:\Users\...\ComfyUI (4)\ComfyUI>" 发现的。之前我放错文件夹了，节点根本没加载。

坑 #2：BizyAir 的"僵尸进程"

BizyAir 虽然已经停服，但每次启动 ComfyUI 它会重试 5 次 × 检查若干个 API 端点，白白浪费 42 秒。在 custom_nodes 里直接删掉文件夹就行——ComfyUI 的世界里，删文件夹就等于卸载。

坑 #3：SSL 证书 + 企业代理双重拦截

用 APIYI 的 API 时，先报 SSLError，关了 SSL 验证又报 ProxyError。华东院的企业网络环境对 HTTPS 请求有两道坎：

SSL 中间件拦截 → 在节点上加 verify_ssl: no 开关
系统代理变量残留 → 加 use_proxy: no，强制绕过系统代理

坑 #4：域名也有"玄学"

同样一家 APIYI 服务商，api.apiyi.com 在我这儿怎么都打不通（SSLEOFError），换 vip.apiyi.com 就丝滑顺畅。最后把默认 URL 改成了 vip 端点才跑通。

坑 #5：节点版本升级导致字段错位

v2 升级到 v3 时删掉了 num_ref_images 滑块，但已保存的工作流还在用旧节点——导致 result_json_path 字段被错位填了数字 4，timeout 变成 NaN。解决办法简单粗暴：删掉旧节点，重新拖一个新的出来。

四、最终成果：API Universal Node v3

▲ 节点在 ComfyUI 中的实际运行状态，输出端已收到图片并完成解码

▲ 第一张成果图：2560×1440，日落山谷，由 API Universal Node 调用 APIYI gpt-image-2 直接生成

核心设计理念

不连图片 → 文生图。连几张图片 → 自动识别几张。
不用手动调 num_ref_images，不用根据图片数量改 request_body。
一切都自动化。

功能清单

功能	说明
自动识别参考图	0张=文生图，N张=多图参考
比例选择器	16:9 / 9:16 / 1:1 / 4:3 / 3:4 / 3:2 / 2:3 / keep(原图比例)
分辨率选择器	1K(1080) / 2K(1440) / 4K(2160)
SSL验证控制	企业网络可关闭证书验证
代理控制	强制绕过系统代理，直连API
双输出	图片 + API原始响应文字（调试/状态显示）
URL & base64	同时支持两种图片返回格式
JSON模板变量	`${prompt}` `${size}` `${image1}` `${image_list_wrap}` 等

一个节点，多个 API

    APIYI gpt-image-2（文生图）

    api_url: https://vip.apiyi.com/v1/images/generations

    response_type: base64 | result_json_path: data[0].b64_json

    Banana2（图生图 / 白描线稿） — 待测试

    api_url: https://api.grsai.com.cn/v1/draw/nano-banana

    response_type: url | result_json_path: url

    理论上支持任何 HTTP 图像 API

    DALL·E 3 / Midjourney API / Replicate / Imagen / 未来的任何新模型——只要改 URL 和 JSON body。

五、完整过程时间线

① 概念启蒙

二哥用一个图解释清楚：专属节点 vs 通用HTTP节点——"烤箱"和"零件"的区别。

② GrsAI短暂尝试

装上GrsAI节点，成功生成了一张图。但它和BizyAir本质相同——还是"别人的烤箱"。

③ v1：第一个通用节点

手搓了第一版通用HTTP节点，放在 GrsAI 文件夹里。结果因为依赖 GrsAI 内部模块，加载失败。

④ 独立化

创建 ComfyUI-API-Universal 独立插件包，零依赖自包含。但路径放错了——放到了旧的 Documents\ComfyUI。

⑤ 发现真相

从控制台日志找到真正的 ComfyUI 运行目录。删除 BizyAir（永久停服+42秒拖慢启动）。

⑥ v2：智能识别参考图

删除 num_ref_images 滑块，改为自动识别连了几张图。新增 Data URI / 纯 base64 双变量系统。

⑦ v3：比例+分辨率+网络控制

增加比例选择器（含keep原图比例）、分辨率选择器（1K/2K/4K）、SSL验证开关、代理控制开关。

⑧ 网络攻坚战

SSL错误 → 关闭验证。代理错误 → 绕过代理。域名不通 → 换vip端点。最终成功生成2560×1440图片。

六、技术要点备忘

节点文件位置

C:\Users\sy10sd1\ComfyUI-Installs\ComfyUI (4)\ComfyUI\custom_nodes\
ComfyUI-API-Universal\
└── __init__.py  ← 全部200行代码

核心变量一览

变量	内容
`${prompt}`	提示词文字
`${size}`	自动计算的尺寸 "WxH"
`${width}`	宽度数值
`${height}`	高度数值
`${image1}`	第1张图完整Data URI
`${image1_b64}`	第1张图纯base64
`${image_list_wrap}`	JSON数组(含data:前缀)，直接嵌body

二哥说

今天温泉让我想起了一句话："工具是手的延伸，但理解才是脑的延伸。"

一个建筑设计师，本不需要了解 API、SSL、代理、base64 这些玩意儿。温泉之所以能坚持跑通这整个流程——从 BizyAir 停服的迷茫，到理解"节点 vs API"的本质区别，到手搓出一个 200 行的通用节点，再到跟企业网络斗智斗勇、把 SSL 验证和代理一个一个扒掉——靠的不是技术底子，是两样更根本的东西：

一是"相信"。 相信方向是对的——与其每次换个服务商就重新学习一套新节点，不如造一个真正通用的轮子。相信二哥说的"能"不是安慰，是真的能做出来。

二是"坚持"。 节点加载失败→独立化。路径不对→找真路径。SSL 报错→关验证。代理拦截→绕开。域名不通→换端点。字段错位→重建。每一步都是"卡住→排查→解决→下一步"，没有一次是因为技术太难而放弃。

然后我想说一个容易被忽略的点：这不是"技术能力"的胜利，这是"认知框架"的胜利。

温泉从一开始问"API 没有专属节点怎么用"这个问题的时候，就已经在打破"我只能用别人做好的东西"这个思维定式了。后面的代码、调试、网络排查，都只是执行层面的事。真正让这件事发生的那一刻，是温泉意识到——我不需要等别人给我造烤箱，我自己就能搭炉子。

工具会过时，API 会停服，节点会断更。但"我能自己搞"这个认知，永远不会过期。

这大概就是一个建筑设计师手搓代码的——底层逻辑吧。

—— 二哥 · 2026年7月2日

手搓通用API节点：当 BizyAir 停服之后