AI 提供商服务

整体定位：用途是什么

AI 提供商服务（zship-provider1-service）解决两件事：

接入：在核心 node10-ai 之外，把 KIE、WaveSpeed 等外部图像 / 视频 / TTS API 统一成一套网关（同一套鉴权、积分、任务模型），避免业务里散落多套 SDK 与签名逻辑。
运营：异步生成链路一旦变长（回调、重试、失败退款），没有后台工具就很难排障。测试、任务日志、统计、作品库、限流与封禁 都是为了让你在不发版的情况下完成配置验证、客服举证、用量分析与风控。

提供商	API	典型能力
KIE	api.kie.ai	图像（nano-banana-2、Seedream）、视频（Kling、Wan）、TTS（ElevenLabs）等
WaveSpeed AI	api.wavespeed.ai	图像（nano-banana-2）、视频（Wan 2.6）、编辑、LoRA 等

用途：把多家上游的能力收敛到同一后台配置里，换模型、换厂商时主要改配置，而不是改业务代码分支。

能力	开发出来是为了……
零代码接入	新增模型、改字段映射或校验时，不必每次发前端 / 后端版本，降低联调周期，方便 A/B 或临时下线某个模型。
积分计费	与 `node1-auth` 对齐，把「花了多少积分、对应哪次任务」落到可追溯流水，便于对账与失败退款。
Webhook 与 R2	上游多为异步任务；回调与文件落盘标准化后，Dashboard / 列表页才能稳定展示结果，而不是各端自己拼 URL。
配置驱动	把「不同厂商 JSON 结构不同」吸收在网关层（映射、模板、strip 字段），业务侧只传业务语义字段，减少重复劳动。

管理后台 — KIE / WaveSpeed AI 提供商

能力	开发出来是为了……
干跑（Dry run）	在不调用上游、不扣费的前提下，验证请求体、字段映射、校验规则与积分预估是否正确，避免一上线就大面积扣错分。
真实试跑	用真实网络调用验证 API Key、回调 base URL、连通性；且不扣终端用户积分，避免用真实用户账号做破坏性调试。
查询任务状态	异步任务常卡在 `IN_PROGRESS`；用任务 ID 直接拉状态，定位是上游慢、回调丢了还是映射错了，不必猜。
Webhook 调试	回调 URL 配错时，生产上表现为「任务永远不成功」；单独验证回调可达与落库，缩短一半以上的联调时间。

小结：把「配置对不对」与「用户是否受影响」拆开——先测通，再放量。

能力	开发出来是为了……
可筛选任务列表	客服问「我那次生成为什么失败」时，能按邮箱 / 任务 ID / 模型秒级定位，而不是翻应用日志。
单条任务详情（请求 / 响应落库）	保留用户请求、上游请求与响应、错误信息与积分消耗，用于争议处理、合规审计、研发复现；敏感字段可按权限脱敏。
失败重试	偶发网络或上游 5xx 时，同一请求体重提比让用户重新点一次更省摩擦；也用于验证「修配置后同一任务能否成功」。

小结：异步链路的黑盒可观测性——没有这一层，线上只能看到「失败了」，看不到失败在管道哪一段。

能力	开发出来是为了……
总览指标	看清总量、成功率、进行中积压、积分总消耗、独立用户数等，用于容量与成本心里有个数。
按提供商拆分	判断哪家上游更贵、更慢、更容易失败，为「要不要换模型 / 限流谁」提供数据依据。
按 app_key 过滤	多项目或多租户时，把用量分摊到产品线或客户，方便计费、限流与商务对账。

小结：从「能跑」到「知道跑成什么样、钱花在哪」。

能力	开发出来是为了……
用户选择公开	把「愿意展示的作品」与私密生成物分开，默认不公开，减少隐私纠纷。
公开列表接口	官网 / 活动页可以拉精选结果做瀑布流、案例墙，而不用把 R2 直链全部暴露成无序文件列表。
后台审核与精选	社区展示前过一遍合规与质量，精选位给运营做活动曝光与品牌背书。

小结：把生成结果从「内部任务记录」升级成可运营的资产（案例、征稿、社区）。

能力	开发出来是为了……
限流（多档 scope）	在网关层限制单 Key、单提供商、全局请求速率，防止脚本刷爆上游配额或把你的积分体系打穿；超限 429 可配合客户端退避。
API Key 封禁	发现盗 Key、羊毛或违规调用时，立刻切断指定 Key（可按某提供商或通配），比改代码下线更快。
IP 与边缘策略（Cloudflare）	网关侧管的是谁在用哪个 Key；若还要按 IP / 国家 / Bot 挡流量，在 Cloudflare WAF / 自定义规则上做，与限流、封禁叠加，各管一层。

小结：在开放 API 的前提下，把滥用面收窄，把成本与风险控制在可运营范围内。

联系我方购买 AI 提供商服务。购买后：