统一图像 API 不适合做发票提取：工程选型避坑指南

统一图像 API 不适合做发票提取：工程选型避坑指南 | 前端进阶之旅

Full translation

完整中文译文

简短回答：统一图像生成 API 作为通过文本生成游戏美术的一键边界是合理的，但对于从供应商发票中提取结构化字段而言，它是错误的选择。对于发票提取，应优先优化模式正确性；对于相邻的图像工作流，应先验证实时模型目录，并将提供商选择保持在自己小型契约的后面。

这一区分在一对一个人游戏 SaaS 中至关重要。一张需要重新生成的图片只是令人烦恼。一张悄无声息地将税费计入小计的供应商发票则可能破坏报表的准确性。这两类输出不应仅仅因为都可能涉及 AI 就共享同一套验收测试。

交付边界清晰的东西。

一个 API 密钥能否管控多个文生图 AI 模型？

它不应该在每次请求时都在应用代码内部做出这种选择。在部署时从平台的模型目录中选择一个已批准的默认值，将其 ID 存储在配置中，然后通过标准图像生成路由发送生产请求。目录是准入关卡；运行时调用保持常规不变。

有一个修正需要说明。在许多技术栈中，Claude 和 Gemini 并非主要的图像生成选择。它们的名称可能在广泛的 AI 采购讨论中很重要，但并不能证明文生图的等价性。一个平台可以宣传多种 AI 模型，同时暴露一个薄弱的图像目录，所以应该计算你实际能调用的图像能力选项，而不是首页上的品牌标志。在没有看到其当前条目并运行你的提示词的情况下，我无法确定哪个目录会符合你的艺术方向。那项实时检查解决了不确定性。对于发票工作流，应更早停止。返回一个图像的端点无法承诺字段——如供应商名称、发票号、货币、小计、税费和总计。没有任何路由策略能修正这种类别错误。应定义模式，验证每个提取值，并将无效记录发送到审核。只有当任务确实是生成图像（如从已批准的文案生成草拟商店横幅）时，文生图比较才应该开始。

每小时的收入测试是粗粒度的：这个抽象是否在不妨碍输出关卡的前提下消除了维护负担？如果是，外包它。如果否，将边界保持在更接近产品的位置。

我会保持已部署模型是显式的。这使得每周发布审查变得可行：模型变更是一个配置变更，而非通用自动标签造成的事故。这还避免了假设发现返回的第一个模型支持图像生成。

以下 TypeScript 示例使用 OpenAI 兼容客户端，要求经过审查的模型 ID，检查图像结果，并对 HTTP 429 进行指数退避重试。SDK 通过 /v1/images/generations 发送标准图像请求；目录审查在部署前使用 /v1/models。应用中不存在虚构的提供商路由。

import OpenAI from "openai";

const apiKey = process.env.INFRAI_API_KEY;
const baseURL = process.env.AI_BASE_URL;
const model = process.env.IMAGE_MODEL;

if (!apiKey || !baseURL || !model) {
  throw new Error(
    "Set INFRAI_API_KEY, AI_BASE_URL, and a reviewed IMAGE_MODEL",
  );
}

const client = new OpenAI({ apiKey, baseURL, maxRetries: 0 });

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function generateImage(prompt: string): Promise<string> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    try {
      const result = await client.images.generate({
        model,
        prompt,
        n: 1,
      });

      const url = result.data?.[0]?.url;
      if (!url) {
        throw new Error("The image response did not contain a URL");
      }

      return url;
    } catch (error) {
      const status =
        error instanceof OpenAI.APIError ? error.status : undefined;

      if (status !== 429 || attempt === 3) {
        throw error;
      }

      await sleep(500 * 2 ** attempt);
    }
  }

  throw new Error("Image generation exhausted its retry budget");
}

const imageUrl = await generateImage(
  "A clean 16:9 store banner for a turn-based space strategy game",
);

console.log(imageUrl);

SDK 拥有 HTTP 方法并惯用地使用图像生成操作。429 响应获得有限延迟而非热循环。其他 API 失败通过 OpenAI.APIError 保留其真实状态和响应体，这是运维人员需要的。

注意示例没有做什么。它不会将发票数据喂入图像提示词，不会猜测模型 ID，也不会静默回退到不同供应商。这些捷径使演示看起来灵活，同时使生产行为难以审计。

OpenAI vs Claude vs Gemini vs 统一图像 API

有用的比较不是功能数量的竞赛。它是一个边界决策：直接提供商集成、统一运行时，或者一个其模型家族并非主要针对图像生成而选择的产品。

我不会根据品牌认知度来排名。我会选取十个代表性提示词，冻结尺寸和验收标准，然后检查输出是否符合游戏实际需要的特征。这是一个决策流程，而非基准声明；你的结果可能不同，因为艺术方向和当前模型可用性会改变结果。

结构化输出正确性使用不同的标准。对于发票，测试精确的字段存在性、类型、算术一致性和审核行为。不要让视觉上合理的结果取代机器可检查的数据。

首个周构建后的治理权衡

在小规模下，一个经过审查的模型 ID 和有限重试循环就足够了。在更大规模下，我会记录配置的模型、请求 ID、提示词模板版本和每次生成的验收结果。我还会将模型准入与模型路由分离：计划审查可以批准来自发现的候选，而请求路径只能从已批准集合中选择。

这种分离保护了发布节奏。新目录条目不能意外改变生产，而能力背后的供应商交换不会强制应用重写，因为契约保持不变。对于独立创始人，这就是统一运行时的实际优势——更少的认证和 SDK 决策与功能工作竞争。

保持回退策略窄。速率限制可能证明在退避后重试相同请求是合理的。它不会自动证明选择另一个模型是合理的，因为不同模型可能改变视觉风格和提示词解释。如果确实需要跨模型回退，请提前批准其输出并记录选择。

发票提取需要一个更坚固的关卡：持久化前的模式验证和验证失败后的审核路径。我不会仅仅为了减少集成数量就将该管道与图像生成合并。只有在契约保持诚实时，共享基础设施才有用。

统一运行时在以下情况下不合适：当前目录缺少你已批准的图像模型、需要通用契约中缺少的提供商特定控制，或你的操作约束要求直接访问。当 OpenAI 的图像表面是你唯一需要的且提供商可移植性没有近期价值时，坚持直接使用 OpenAI。当 Replicate 或 fal.ai 的实时目录更好地匹配你需要的模型时，评估它们。

关键在于：单一密钥减少认证和提供商切换工作，但它不能制造模型覆盖范围或结构化输出正确性。检查 /v1/models，批准一个默认值，并通过一个小型内部函数保持 /v1/images/generations。当提示词集或目录发生变化时，重新审视这一选择。

对于供应商发票，选择结构化提取路径。那是更高价值的调用，因为它防止了错误的抽象进入代码库。

OpenAI Embeddings 指南：https://platform.openai.com/docs/guides/embeddings

pgvector，Postgres 向量相似性扩展：https://github.com/pgvector/pgvector

这些参考文档记录了相邻的向量接口，而非图像生成。它们使范围边界明确：嵌入生成和向量搜索都不能替代文生图生成或经验证的发票字段提取。