先把证据等级摆在架构图之前
这次选题来自 NodeLoc 上关于“免费生图和生视频”的讨论，但社区帖子只能说明一个真实需求正在出现：用户希望把网页端 AI 能力接入自己的客户端或自动化流程。帖子给出的仓库链接指向 lza6/creen-2api，因此社区材料适合做选题雷达和问题样本，不适合单独证明接口、模型、稳定性或授权关系。
更高等级的证据是项目自身的 GitHub 仓库。仓库 README 自述：Creen-2API 将 creen.ai 的图像和视频生成能力封装为本地 OpenAI 兼容 API 网关，采用 Bun 运行时、单进程、零依赖，并包含账号池轮换、协议直连等能力；仓库还将前端编译产物、源码分析文档、抓取验证数据、逆向工具链和网关实现分开保存。README 同时声称覆盖 60 个模型、31 个前端 chunk、30 份分析文档和 208 个 API 端点。
这些数字是项目公开说明中的声明，不应在没有逐项复核源码、抓包和运行结果时升级为“生产能力证明”。本文因此采用两层表达：凡是仓库明确写出的内容，标为“项目自述”；凡是从目录组织和网关常见分层推导出的工程方法，明确标为“分析框架”。这一区分很重要，因为逆向项目最容易把“曾经观察到”误写成“长期支持”。
真正的核心不是转发，而是建立证据链
一个网页 AI 适配器通常被想象成下面这条链路：客户端发送 OpenAI 风格请求，适配器将模型名和参数转换为上游格式，携带会话信息调用网页端接口，再把响应转换回来。这个描述只覆盖了最后一跳，无法解释为什么同一个接口今天可用、明天失效，也无法解释图像和视频任务为什么比普通文本请求更难维护。
更可靠的分析方法是把链路拆成五层。
第一层是入口契约。需要明确客户端究竟发送什么：模型名、消息结构、流式开关、图片输入、尺寸、时长、回调或轮询参数。所谓“OpenAI 兼容”不能只看 URL 是否相似，还要验证错误格式、状态码、流式分片、异步任务和二进制结果是否符合调用方预期。兼容层越宽，转换代码越容易出现隐式默认值。
第二层是能力目录。网页前端往往不会把模型能力直接呈现为一张稳定的 API 表。模型名称、输入类型、质量档位、视频时长、图片尺寸和积分消耗可能分散在前端 chunk、配置接口和任务提交接口中。Creen-2API 将“前端编译产物”和“模型分析文档”单独归档，这种目录结构本身就是一个可复用的工程启示：先保存原始材料，再保存解释结果，避免分析结论覆盖原始证据。
第三层是认证与会话。网页端调用可能依赖登录会话、短期令牌、设备信息、风控挑战或一次性任务凭据。这里不能把“拿到一个 token”当作认证模型已经被理解。应记录令牌的来源、有效期、绑定范围、刷新方式和失败响应，并将敏感值脱敏后保存。项目 README 提到“账号池轮换”，但这只是能力声明；它并不自动证明账号来源合规，也不证明轮换可以绕过上游风控。
第四层是任务状态。图像或视频生成往往不是同步返回最终结果，而是经历创建、排队、生成、失败、过期和下载几个阶段。适配器若只把一次 HTTP 响应包装成 chat.completion，调用方可能收到一个看似成功、实际尚未完成的任务。工程上应给每个上游任务建立内部状态机，并区分“已接受”“生成中”“已完成”“可下载”“下载失败”和“上游拒绝”。
第五层是证据与回归。仓库中存在“抓取验证”和 _evidence 目录，说明项目至少把验证材料作为独立部分组织。无论具体实现如何，适配器都应保存请求摘要、响应状态、字段映射、时间戳和失败类别，而不是只保留一条“成功调用”的截图。只有这样，上游字段变化时才能定位是认证失效、模型下线、参数不兼容，还是本地转换逻辑出错。
从仓库结构重建可审计的工作流
下面是一套不依赖具体业务账号的检查流程。它的目标不是自动化注册、绕过验证或批量消耗上游资源，而是让工程人员在阅读项目时先判断边界，再决定是否运行。
先固定源码版本和工作目录：
git clone https://github.com/lza6/creen-2api.gitcd creen-2apigit log --oneline --decorate -n 10find . -maxdepth 2 -type d | sort第一步看原始材料是否和解释材料分离：
find 01-源代码 02-源码分析文档 03-抓取验证 04-逆向工具链 05-网关实现 -maxdepth 2 -type f | sort如果一个项目只有实现代码，没有原始响应、字段说明或版本记录，后续很难区分“代码猜测”和“实际观察”。反过来，材料很多也不等于可信，仍需检查每份文档是否有采集时间、请求上下文和脱敏规则。
第二步建立端点索引，但不要把字符串搜索结果直接当作可调用接口：
rg -n --hidden -g '!*.map' -g '!node_modules' 'https?://|/api/|fetch\(|axios|Authorization|Bearer' .每个候选端点至少记录六项：请求方法、路径、认证来源、必填字段、响应形态、失败样例。对图像和视频接口，还应额外记录任务是否异步、结果是否需要二次下载、下载地址是否短期有效。所谓“208 个 API 端点”只有在能对应到这些字段时，才具备工程价值；单纯的前端字符串数量不能代表稳定 API 面积。
第三步检查模型映射是否集中管理：
rg -n --hidden 'model|image|video|width|height|duration|quality|stream' 05-网关实现 02-源码分析文档 03-抓取验证模型名最好使用显式映射表，而不是把客户端传入值直接拼接到上游路径。映射表应包含能力、参数转换、是否异步、失败重试策略和最后验证时间。对于一个已经失效或不再返回的模型，系统应返回清晰的“不支持”或“上游不可用”，而不是静默回退到另一个模型，避免用户在不知情的情况下得到不同结果或产生额外费用。
第四步确认运行时和依赖边界。README 的项目自述是“Bun 运行时、单进程、零依赖”，但“零依赖”不应理解为没有供应链风险。仍需检查运行时版本要求、脚本入口、环境变量和启动参数：
rg -n --hidden 'package.json|bun|env|PORT|HOST|TOKEN|KEY|SECRET' README.md . 2>/dev/nullfind . -maxdepth 2 \( -name 'package.json' -o -name 'bun.lockb' -o -name 'bun.lock' -o -name '.env.example' \) -print只有在确认入口、依赖和配置后，才考虑在隔离环境中启动。不要把真实账号、长期令牌或生产网络直接放进未知的逆向代码；先使用无权限测试账号或静态分析，限制出站网络，并为日志做密钥遮罩。
OpenAI 兼容层最容易失败的地方
“兼容”至少有三种含义：路径兼容、请求结构兼容、语义兼容。很多网关只能做到前两种。
路径兼容是客户端把 base_url 指向本地网关，请求能够进入。请求结构兼容是网关接受 messages、model 或类似字段，并返回客户端认识的 JSON。语义兼容则要求模型能力、流式行为、错误重试、任务完成时机和输出内容都符合调用方预期。图像和视频生成尤其容易停留在前两层：请求返回 200，不代表内容已经生成，也不代表下载链接可以长期访问。
流式接口还存在边界问题。客户端可能期待按事件逐块接收文本，而上游只返回任务进度或最终 JSON；如果适配器把进度事件伪装成普通文本，调用方会误判结果。正确做法是先声明支持范围：文本流式、图像异步任务、视频轮询分别验证，不要因为一个接口成功就宣传“全协议兼容”。
错误处理同样不能依赖统一的 500。认证过期、额度不足、模型不存在、参数非法、上游排队、结果下载失败和本地超时，应有不同的错误码或至少有稳定的错误类型。这样客户端才能决定是刷新会话、降低并发、修改参数还是停止重试。没有错误分类的自动重试，会把一次上游异常放大成账号池耗尽或 IP 被限流。
账号池不是可用性的免费午餐
项目 README 将账号池轮换列为能力之一。工程上，账号池至少包含账号状态、最近成功时间、连续失败次数、冷却截止时间、能力标签和凭据版本。调度器不能只做“轮流取下一个账号”，而应根据任务类型和账号可用性选择，并在认证失败后立即隔离账号，避免同一个失效凭据被高并发重复使用。
但账号池解决的是局部容量问题，不是上游信任问题。多个账号可能共享 IP、设备指纹、支付关系或行为模式；轮换还会让故障定位变得更困难。若请求日志只记录“网关成功”，而不记录脱敏后的上游账号标识和失败类别，就无法判断是单账号失效还是整个出口被限制。
更稳妥的设计是把账号池当作有限资源，而不是无限扩容手段：设置并发上限、单账号冷却、全局速率限制和熔断；在达到失败阈值时停止自动切换，向调用方返回明确错误；将所有账号操作限定在服务条款和授权范围内。对于需要绕过验证码、地区限制或风控的做法，本文不将其视为可交付的工程能力。
如何定义“真的可用”
对这类项目，最小验收清单不应是“能不能生成一张图”，而应覆盖以下五类结果。
一是契约测试。用固定请求验证模型名、必填参数、错误参数和未知模型，确认状态码和错误结构稳定。二是任务测试。分别验证同步响应、异步创建、轮询、超时、取消和结果下载，不把 HTTP 200 当作任务完成。三是认证测试。使用过期、缺失和错误凭据，确认网关不会把认证失败包装成空结果。四是回归测试。将关键上游响应脱敏后固化为样本，每次修改字段映射都重放，避免前端更新后静默损坏。五是运营测试。限制并发并观察队列、内存、日志体积和失败重试，确认单个上游故障不会拖垮整个进程。
可以把结果写成一张简单的能力矩阵：模型、输入类型、同步或异步、流式支持、认证要求、最近验证日期、失败类别和风险备注。矩阵中的“未知”必须保留，不能用“理论支持”填空。尤其是项目声明覆盖 60 个模型时，应逐模型确认，而不是从模型列表数量推导稳定性。
工程取舍：单进程适合验证，不等于适合规模化
单进程和零依赖的优点很明确：部署路径短、调试成本低、源码审计范围小，适合快速验证协议和搭建个人实验环境。它也带来明显边界：一个进程同时承担入口、认证、调度、任务状态、下载和日志，任何阻塞操作都可能影响其他请求；进程重启还可能丢失内存中的任务状态和账号冷却信息。
因此，若目标只是验证一个模型接口，单进程设计可能是合理取舍；若目标是长期服务多个用户，则至少要把任务状态持久化、日志集中化、并发控制和凭据管理单独考虑。是否拆成多个服务，不应由“微服务更先进”决定，而应由故障隔离需求决定：下载大文件是否会阻塞提交请求，某个账号是否会拖累全局，重启后是否需要恢复任务，这些问题比部署组件数量更重要。
我的结论是：网页 AI 到 API 的难点从来不是把路径改成 /v1，而是把不稳定的网页能力转换成可验证、可回归、可解释的服务契约。Creen-2API 的公开目录至少展示了一种值得学习的材料组织方式：原始前端、分析文档、抓取证据、工具链和网关实现分层保存。至于它所声明的模型数量、账号池和协议能力，则必须沿着端点索引、认证样本、任务状态和失败回归逐项验证。只有当“能调用”与“为何成功、何时失败、如何回滚”同时有证据时，一个逆向适配器才真正接近工程系统，而不是一次性的接口演示。
参考资料
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时