生图路由：先保留任务约束，再选择入口

示例文章：用于体验 Wiki 的阅读、分类与知识关联。除明确引用的公开资料外，流程、配置和情境均为原创设计示例，不代表生产系统现状或测试结果。

“生成一张图”不足以决定使用哪条链路。拟议设计先保留输入和交付目标，再验证当前可用的入口。优先级可以表达偏好，但不能替代能力与权限检查。

同一个角色封面任务，切换入口后仍应保留参考图、画幅、标题安全区和输出要求。更换模型不是重新猜一次用户意图。

参考图的组织方式见 角色素材卡；这里没有承诺任何入口一定支持这些要求。

下面只演示选择顺序：先检查本地入口，再检查远程，最后检查兜底。每一步仍需满足原任务条件。这里没有执行真实请求，也不提供模型速度或配额结论。

flowchart LR
T[读取任务约束] --> L[检查本地入口]
L --> R[检查远程入口]
R --> F[检查兜底入口]

这是一条检查链，不意味着每次都调用三个提供方。若没有满足条件且得到授权的入口，就记录缺失条件，不能悄悄用直连或另一类工具替代。

以下 JSON 是示意字段，不是可直接调用的生产接口。它将“希望使用”与“已经验证”分开。

{
  "request_id": "example-cover-001",
  "task": { "purpose": "cover", "aspect": "9:16" },
  "reference_required": true,
  "route": {
    "preferred": "local",
    "availability": "needs-verification",
    "reason": "先核对参考图能力和当前认证"
  },
  "output": { "location": "project", "upload_required": false }
}

本地保留文件和云端返回 URL 是交付方式的差异；不能据此推断是否成功生成，更不能把“拿到 URL”直接等同于画面合格。

等待结束只说明调用方还没拿到结果。先核对原任务是否已受理、是否仍在生成、是否已有产物，再决定下一步。

详见 超时之后：先核对，再决定是否重试。拿到候选图以后，按 质量回环 检查具体偏差，而不是只写“工具成功”。

尚未填写外部来源；内容由作者自行整理。