文生图页面看起来通常只有三件事：写提示词、选一个模型、点击生成。但当模型能力、提示词限制、画幅和分辨率都可能变化时，这个表单实际上承担着一份动态请求契约。
如果前端只保存一段 prompt 和一个 loading 状态，用户刷新页面后很难恢复任务，团队也无法解释一张图片究竟由哪组设置生成。更危险的是，旧页面可能继续展示已经不兼容的 4K 或画幅选项，让失败看起来像模型随机失灵。
本文以浏览器端 text-to-image 工作流为例，讨论怎样把一次生成请求做成可复现、可恢复、可审核的工程记录。
先读取能力，再渲染表单
模型名称、提示词上限、画幅和分辨率不应该散落在前端常量里。页面打开时应读取当前 capability，并根据模型选择实时收窄可用组合。
能力快照至少需要描述：当前模型是否可用、提示词长度边界、支持的画幅、允许的分辨率，以及是否存在登录或其他提交条件。前端可以缓存快照改善体验，但创建任务时，服务端仍要按当前能力重新校验。
当能力已经变化，正确做法是保留用户的提示词，指出哪一个选项失效，并要求重新确认。静默换模型、改画幅或降低分辨率虽然减少了一次错误提示，却会破坏用户对结果来源的理解。
把自然语言保留为原文，同时提取结构化意图
提示词不必变成复杂表单，但产品可以用一组轻量维度帮助用户检查输入：主体、风格、构图、光线、颜色、场景和情绪。
这组维度的价值不是替用户写“万能提示词”，而是让修改更可控。第一次结果主体正确但构图不合适时，用户可以只调整构图描述，而不是把整段文字全部重写。系统也应保留原始提示词，避免结构化辅助在后台改变真实提交内容。
请求快照可以记录：
- 原始提示词；
- 用户确认的模型、画幅和分辨率；
- 提交时采用的 capability 版本或摘要；
- 客户端生成的幂等键；
- 创建后返回的 Job ID。
这样一张结果不只是一个图片 URL，还能回到它的输入条件。
用幂等 Job 承接长任务
生成请求可能排队，也可能在浏览器响应返回前已经创建成功。若用户因为超时再次点击，而服务端没有幂等保护，就可能创建重复任务。
更稳妥的接口应快速返回 Job ID，并让任务经历 queued、running、completed 或 failed 等明确状态。相同幂等键的重试返回同一个任务；只有用户修改提示词或设置并主动开始新尝试时，才创建新的请求快照。
页面可以把 Job ID 放进本地最近任务记录。刷新或短暂断网后，用户继续查询原任务，而不是重新生成。失败也要区分输入冲突、能力变化、上游暂时不可用和内容安全检查，让用户知道应该改输入还是稍后重试。
completed 和 approved 是两个状态
模型返回图片只代表技术任务完成。结果是否符合创作意图，仍需要人在全尺寸预览中检查。
检查项可以直接对应提示词：主体是否正确，构图和光线是否匹配，文字、手部、边缘和重复纹理是否异常，画面是否包含未要求的元素。用户确认后再进入下载；不合格时保留原请求，复制成新尝试并只修改一个变量。
把 completed 与 approved 分开，能避免“API 成功”被误写成“图片质量已保证”，也让后续下载、版本比较和团队交接都有清楚依据。
分辨率必须跟随兼容组合
4K 更适合被建模为某些模型、画幅和任务组合下的可选结果，而不是产品级永久承诺。当前页面可以显示兼容选项，但文章、缓存和旧任务都不应据此推断未来仍然相同。
可用模型、提示词限制、画幅和输出分辨率会变化，4K 只适用于兼容的模型与设置组合；生成结果仍可能偏离提示词或包含文字、手部、边缘和构图瑕疵，不能把任务成功写成质量保证。
小结
可靠的文生图产品，不是把一个 prompt 转发给模型。它需要先协商当前能力，保存不可变请求快照，用幂等 Job 承接异步执行，再把全尺寸人工验收放在下载之前。
我把这套链路落在一个可以从纯文本开始的浏览器页面里，作为本文的实际案例：
页面允许从文本提示开始，无需参考图片；具体模型、提示词限制、画幅和分辨率仍以当时返回的能力为准。
