上线前开发者应先问的图像生成 API 问题

图像生成 API 的危险之处并不在于端点名称。而在于端点在无人关注时悄悄做了什么。

开发者可以在一个下午把模型调用接起来。这就是现代 AI 基础设施的美妙之处，也是略微令人不安的地方。演示能跑。图片出现了。按钮发光。创始人露出那种特定的微笑——仿佛暂时忘记了数据保护法律的存在。

上线之前，先问：什么会进入 API。提示（prompts）是内容。源图像是内容。蒙版（masks）是内容。参考图像是内容。生成结果也是内容。密钥（keys）可能会解锁内容。如果这些对象被当作普通的请求元数据来处理，产品就已经在不知不觉中走向麻烦。

再问：这些内容会被送到哪里。会打到你的应用服务器？队列？对象存储？模型提供方？CDN？日志处理器？错误跟踪器？支持看板？质量评审工具？把路径画出来。如果路径看起来像是在偏头痛发作时设计的地铁线路图，那就别等客户使用前才简化。

再问：哪些内容会被持久存储。一个有用的 API 可能需要账户记录、计费记录、任务状态、模型名称、时间戳以及运维事件。但它并不自动需要原始提示、源图像、生成结果或生成密钥。保留运维层面的事实。除非产品明确承诺保存历史，否则不要保留创作证据。

再问：失败时会发生什么。失败的任务往往会让团队变得粗心，因为调试看起来很紧急。不要把请求正文转储到日志里。不要为了“以后”而保留源图像。不要把私密提示发送给错误处理工具。并不顺利的那条路仍然是产品的一部分。

再问：删除如何实现。如果用户可以删除上传内容或输出内容，那么需要明确这在原始文件、输出、缩略图、缓存和画廊之间分别意味着什么。如果由于备份或法律义务，某些内容无法立即移除，就要解释清楚。如果系统被设计为避免持久存储内容，那么删除就会更容易描述。

再问：谁能看到客户内容。支持访问权限是一个产品决策，而不仅仅是内部政策。如果运维人员无法看到提示和图像——因为这些对象并未保留在面向支持的系统中——那比“我们的团队接受过培训”要更有力。培训当然很好，但架构更不容易忘记。

上线前的提问并不是“这个 API 能生成好看的图片吗？”而是“我们能否在不冒汗的情况下解释数据路径？”

延伸阅读：图像生成 API 开发者需要什么，Unexposed 数据存储，以及 OpenAI 的API 数据控制。