企业官网建设流程全解析

网页里的文生图功能看起来通常只有三步：输入提示词、选择比例、点击生成。但从工程实现看，这三个控件背后至少存在三套不能混在一起的状态：当前能力、任务执行和结果验收。

如果前端把模型、比例和分辨率写成固定配置，后端能力一变，页面就会提交失效组合；如果只用一个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只表示技术任务结束，不等于结果已经适合使用。预览页需要给用户足够大的画面，并保留下载、重新生成和继续编辑等不同路径。

我通常按以下顺序检查结果：

1. 主体、动作和场景是否符合提示词；
2. 构图是否适合目标画幅；
3. 人脸、手部、文字和标志是否异常；
4. 边缘、阴影、反射和重复纹理是否连贯；
5. 是否出现未要求的对象或潜在权利风险。

如果整体方向正确，只修改一个提示词变量再生成；如果结果已经可用但需要局部调整，则进入编辑流程。只有通过人工验收的图片才应进入最终下载或生产素材链路。

免费入口也要表达准确

“免注册”不能被实现成一个永久布尔值。更准确的产品逻辑是：当前支持访客使用的模型可以用免费信用点开始生成；某些高级模型、账户信用点、较长保留期和创作历史可能要求登录。模型名称、成本、登录门槛和规格都应由当前能力返回，而不是写进长期文案。

同样，最高 4K 只能描述为兼容模型与设置组合中的可选分辨率，不能暗示每个模型、比例和任务都支持。生成时间、提示词遵循程度和无瑕疵输出也不应作保证。

小结

可靠的文生图页面不是“提示词输入框加一个按钮”，而是一条带边界的状态链：先校验当前能力，再通过异步任务承接执行，最后把人工审核放在下载之前。三道校验各自解决不同问题，也让失败和修改路径更容易解释。

这套流程可以在我维护的浏览器文本生图页面中作为具体案例查看：在线 AI 图片生成器。