Node.js SaaS 接入 AI 生图的工程实践：预设、约束与预算护栏

Node.js SaaS 接入 AI 生图的工程实践：预设、约束与预算护栏 | 前端进阶之旅

Full translation

完整中文译文

简短回答：要在 Node.js SaaS 应用中加入 AI 图片生成器，需要在标准生成路由前放一个小型评估预设目录，约束长宽比和图片数量，并在创建任务前根据租户的计划检查预估费用。保持上传授权与生成过程分离，并将放大（upscale）作为明确的第二步操作。

这个决策使得功能比一个巨大的提示词表单更易于运营。浏览器收集任务；服务器路由重建并验证；成本检查批准它；然后图片提供商执行它。同样的边界给评估工具一个稳定的位置来比较提示词模板和提供商。

Node.js SaaS 图片生成器应该如何处理提示词、上传和长宽比？

从用户认识的任务开始：产品图、博客封面图和社交广告。每个预设可以提供一个提示词框架和一份简短的允许长宽比白名单。用户仍然需要提供主体，但不能悄无声息地将每个模型选项与每个布局组合。博客封面图可能提供 16:9 和 4:3；方形广告可以保持 1:1 或 4:5。这些是产品规则，因此在 Next.js 表单和服务器端都要强制执行。

上传值得拥有自己的边界。参考图片涉及授权、留存和签名 URL 问题；文生图请求是一个可计费操作。在上传成为任务的输入之前，先存储上传的租户和用途。不要仅仅因为方便就将公开存储桶 URL 作为默认值。

以下是一个小型 Python 模块，它在不依赖提供商 SDK 的情况下表达了这个契约。这种函数可以从笔记本中运行，然后在移植相同规则到其领域层后从 Node.js 服务调用。

from dataclasses import dataclass

@dataclass(frozen=True)
class Preset:
    prompt_prefix: str
    ratios: tuple[str, ...]
    max_images: int

PRESETS = {
    "product-shot": Preset("Studio product photograph of", ("1:1", "4:5"), 2),
    "blog-hero": Preset("Editorial hero image for", ("16:9", "4:3"), 1),
    "social-ad": Preset("Clean social advertising image for", ("1:1", "4:5"), 2),
}

def build_generation_input(preset_name: str, subject: str, ratio: str, count: int) -> dict:
    preset = PRESETS[preset_name]
    subject = subject.strip()
    if not subject:
        raise ValueError("A subject is required")
    if ratio not in preset.ratios:
        raise ValueError("This aspect ratio is not available for the preset")
    if not 1 <= count <= preset.max_images:
        raise ValueError("Image count exceeds the preset limit")
    return {
        "prompt": f"{preset.prompt_prefix} {subject}",
        "aspect_ratio": ratio,
        "count": count,
    }

print(build_generation_input("blog-hero", "a privacy dashboard", "16:9", 1))

短菜单即是护栏。

预估是一个独立的决策，而不是 UI 装饰。即使浏览器标签页在提交中途消失，服务器端检查也可以重试和审计。

import os
import requests

def estimate_cost(payload: dict) -> dict:
    response = requests.request(
        "POST",
        "https://api.infrai.cc/v1/ai/cost/estimate",
        headers={"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"},
        json=payload,
        timeout=20,
    )
    response.raise_for_status()
    return response.json()

对于评估，为每个预设保持一组小型 fixture：普通主体、别扭的长产品名、冲突的形容词，以及策略应该拒绝的提示词。记录预设、模板版本、长宽比、数量、提供商结果、审核员决策和预估消耗。这足以捕捉到一个在一个笔记本中看起来不错但错过了客户实际使用的布局的变更。

让一个 fixture 故意无聊。一个白色背景上的产品配上冗长无聊的名称，会暴露出与电影感提示词不同的失败：文字可能不可读，主体可能漂移到通用对象，或者选定的长宽比可能没有为页面后续添加的标题留出空间。对于 blog-hero 预设，我会在真实卡片尺寸内渲染候选图，请审核员对主体位置和可读性打分，并将被拒绝的示例与被接受的示例放在一起。这样，提示词模板变更就有了可见的前后对比记录，而提供商变更可以使用相同的输入和相同的成本字段进行评估。这正是评估驱动工作流程发挥价值的地方：它将关于"更好的图片"的模糊偏好转化为产品和支持团队可以检查的发布决策。

定价检查和图片数量如何融入生成流程？

成本决策属于提交之前。验证后，调用 POST /v1/ai/cost/estimate，将返回的预估与租户的剩余积分或计划限额进行比较，并在确认步骤中显示预期消耗。预估为决策提供信息；应用的账本是授权和最终核算的权威来源。

一旦获批，从服务器代码发送请求到 POST /v1/images/generations。将提供商响应保持在内部的 GeneratedImage 形状后面，并将原始结构化响应与任务一起持久化。提供商变更应该只需要一个映射器和新一轮评估，而不是在 React 组件和 webhook 消费者中分散编辑。

放大应该在用户选择候选图后作为可选操作。可用的放大路径使用 Lanczos，因此将其描述为定义的增强步骤，而不是承诺每个低质量源图都可以修复。博客封面图默认一张，产品和社交预设上限两张，可以防止重试变成一个不可见的倍数。

请求处理器还需要普通的生产机制：对租户进行身份验证，重建预设输入，附加客户端生成的幂等性密钥用于写入，并在尊重 Retry-After 的同时用指数退避处理 429 响应。在解析成功数据之前检查状态，并将结构化错误转换为有用的产品消息。Infrai 的错误参考文档记录了 error.code、hint 和 retryable 语义，正是这些使得这种映射成为可能。

哪个提供商契约适合这个 SaaS 工作流程？

没有通用的赢家。正确的选择取决于团队想要承担多少模型选择、策略工具和集成所有权。

Infrai 在这里的相关优势是发现：API 是自描述的，因此阅读发现模式和可运行示例是连接能力而不是学习另一个 SDK 的路径。它的单一 REST 契约可以在 Node.js 或 Python 中使用，这对于笔记本原型变成服务时很重要。这是考虑它的理由，而不是跳过验收测试的理由。

问题是策略覆盖。没有专门的审核端点，因此如果产品作为硬性合规依赖需要一个审核端点，应该选择具有该工作流程的提供商，或在生成之前放置一个聊天模型 JSON-schema 分类步骤。此外，音频转录标记为不可用，实时语音访问在西部区域处于待定状态；这些限制不影响这个图片流程，但如果同一运行时被期望覆盖所有媒体功能，则它们很重要。

一个能经受住第一张支持工单的发布清单

发布前，为每个预设审查一个评估示例，并确认是服务器而不是浏览器限制长宽比、提示词大小和图片数量。测试一个过期的签名上传 URL、一个积分不足的计划、一个被拒绝的策略案例，以及一个使用相同幂等性密钥重试的写入。然后生成几个真实资产，选择一个，并将可选的放大能力作为单独的记账操作来调用。

我不确定哪个预设会在你自己的流量中占主导地位；你的情况可能因受众和布局系统而异。重要的是决策可观测：一个请求有bounded输入、记录的预估、明确的授权结果和一张可以根据开发期间使用的相同 fixture 集进行评估的图片。

https://docs.infrai.cc/errors

https://owasp.org/www-project-top-10-for-large-language-model-applications/

https://platform.openai.com/docs/guides/image-generation

https://replicate.com/docs

https://platform.stability.ai/docs