网页里的文生图功能看起来通常只有三步输入提示词、选择比例、点击生成。但从工程实现看这三个控件背后至少存在三套不能混在一起的状态当前能力、任务执行和结果验收。如果前端把模型、比例和分辨率写成固定配置后端能力一变页面就会提交失效组合如果只用一个loading表示整个生成过程刷新页面后就很难恢复任务如果把completed直接等同于“可下载使用”模型返回的文字错误、边缘伪影或构图偏差就会被忽略。校验一提交前确认当前能力模型能力不是永久常量。不同模型可能有不同的提示词限制、登录要求、信用点成本、宽高比和分辨率组合。页面应从能力接口读取当前快照再据此生成选项而不是在组件里维护一张长期不变的表。前端过滤只负责减少误操作服务端仍需在创建任务时重新校验。可以把请求抽象成如下结构{mode:text_to_image,prompt:subject, composition, lighting, color, setting, mood,model:current-model-id,aspect_ratio:current-compatible-ratio,resolution:current-compatible-resolution,input_images:[]}这里input_images为空是为了明确区分纯文本生成与参考图编辑。服务端收到请求后应检查模型仍可用、提示词未超限、规格属于同一份能力集合并验证当前会话是否满足该模型的登录和信用点要求。不要静默替换用户选择因为静默降级会让最终结果无法解释。提示词也需要结构化检查提示词不必存成复杂对象但在编辑阶段最好按维度组织主体、风格、构图、光线、色彩、环境和情绪。这样做的目的不是追求模板化而是让下一轮修改有明确变量。例如主体正确、画面过满时只改构图和留白整体氛围不对时只调整光线与色彩。一次重写全部描述虽然省事却会丢失“哪项变化产生了效果”的信息。提交前至少检查空提示词、当前模型的长度边界以及规格兼容性。通过这些检查只能说明请求合法不能承诺输出一定准确、唯一或没有瑕疵。校验二用异步任务表达生成过程图像生成不适合让一次浏览器请求持续等待。更稳妥的方式是先创建任务并返回任务 ID再由前端查询状态或接收进度更新。用户界面至少要区分四个阶段queued请求已接受尚未开始running生成进行中结果不可下载completed已有结果可以进入预览failed没有得到可用结果应显示可行动的原因。任务 ID 还承担恢复职责。页面刷新或网络短暂中断后前端可以读取最近任务而不是直接创建重复请求。失败信息也应区分输入不合法、规格不兼容、登录或信用点不足、上游失败等类型因为它们对应的修复动作完全不同。校验三把完成和通过审核分开completed只表示技术任务结束不等于结果已经适合使用。预览页需要给用户足够大的画面并保留下载、重新生成和继续编辑等不同路径。我通常按以下顺序检查结果主体、动作和场景是否符合提示词构图是否适合目标画幅人脸、手部、文字和标志是否异常边缘、阴影、反射和重复纹理是否连贯是否出现未要求的对象或潜在权利风险。如果整体方向正确只修改一个提示词变量再生成如果结果已经可用但需要局部调整则进入编辑流程。只有通过人工验收的图片才应进入最终下载或生产素材链路。免费入口也要表达准确“免注册”不能被实现成一个永久布尔值。更准确的产品逻辑是当前支持访客使用的模型可以用免费信用点开始生成某些高级模型、账户信用点、较长保留期和创作历史可能要求登录。模型名称、成本、登录门槛和规格都应由当前能力返回而不是写进长期文案。同样最高 4K 只能描述为兼容模型与设置组合中的可选分辨率不能暗示每个模型、比例和任务都支持。生成时间、提示词遵循程度和无瑕疵输出也不应作保证。小结可靠的文生图页面不是“提示词输入框加一个按钮”而是一条带边界的状态链先校验当前能力再通过异步任务承接执行最后把人工审核放在下载之前。三道校验各自解决不同问题也让失败和修改路径更容易解释。这套流程可以在我维护的浏览器文本生图页面中作为具体案例查看在线 AI 图片生成器。