私有图像生成的开发者指南

私有图像生成并不是一个功能。它是一连串的选择。

从请求开始。将提示词（prompts）、源图像（source images）、遮罩（masks）、参考图像（reference images）、生成结果（generated outputs）以及密钥（keys）都视为用户内容。这意味着它们应该比普通遥测（telemetry）走更窄的路径。它们不应被随意出现在日志、分析、仪表盘或客户支持界面中。

接着，将授权与内容分离。系统需要知道该账号是否可以运行任务以及是否需要为其付费。这并不意味着计费层需要提示词。内容不可见的计费（content-blind billing）在恰到好处的程度上“无聊”：它只记录发生了使用，但不记录生成了什么。

然后让处理保持短生命周期。生成会话（Generation Session）应当存在于处理任务并返回结果，而不是成为持久化的工作区。作业运行期间可能需要临时文件。它们不应在任务结束后变成产品状态（product state）。

保持可观测性（observability）内容不可见。你仍然需要指标：队列时间（queue time）、模型性能（model performance）、失败类型（failure type）、容量（capacity）、成本（cost）以及健康状况（health）。在大多数运维事件中，你不需要原始用户内容。如果你觉得需要，先问问自己是在调试系统，还是在囤积客户上下文——因为后者更容易。

小心重试。失败的任务不应把提示词泄露到日志中，也不应在源图像上留下痕迹。重试系统很有用，但它们必须像成功任务一样遵守相同的内容边界。

决定你是否提供历史记录。如果你提供画廊（gallery），就要说明。如果你不提供，那就把它作为一个功能。无画廊（no-gallery）的架构更容易与“零保留（zero-retention）承诺”对齐，因为输出会返回给用户，而不是被保留。

为非专家编写文档。“封闭请求（sealed request）”只有在用户能理解它保护了什么、不能保护什么时才有用。说明内容会去哪里、会保留什么、以及运维人员能看到什么。

开发者指南的核心其实就一句话：减少私有图像内容可能驻留的地点数量，然后让剩余路径变得容易解释。

延伸阅读：入门指南、Unexposed 如何工作 和 Unexposed 数据存储。