把 X2.0 的链路走通，关键不在接口调通那一瞬间，而在动手之前先判断：你的场景是一次性生成，还是交互式改写。前者把素材和指令一次给全，出结果即交付；后者需要基于上一版反复局部修正，每一轮都依赖上一轮的状态。两类场景共用同一套链路，但对状态、回传和日志的要求不同。判断错方向，最常见的表现就是拿一次性生成去应付连续改动，每改一处就整段重跑，画面不稳定，时间也耗在重复调用上。
判断要不要走交互式，看场景里是否存在“必须基于上一版继续改”的步骤；存在就保留状态并固定会话，不存在就走一次性生成，别为了省事把两者混在一条链路上。链路统一拆成输入、状态、出画面、回传四段，每段都要有可观察的输入输出字段，靠同一 trace 标识串起日志来定位卡点。边界规则建议写成判断表固定在接入文档里，避免每次改动都重新讨论走哪条路。需要结合具体环境的限流、会话保活和素材大小另行确认。
列出自己场景里哪些步骤必须连续改动
先别选接口，先把业务流程按步骤摊开，逐步标注可变性。判断标准很朴素：这一步的结果如果被下游否定后需要“在原图上改一点”，就属于边看边改；如果被否定后是整段推翻重来，就属于一次定稿。把清单写下来，比在脑子里判断可靠得多。
| 步骤示例 | 可变性标注 | 判断依据 |
|---|---|---|
| 按文案生成首版画面 | 一次定稿 | 指令一次给全，失败可整段重跑 |
| 按评审意见调整局部元素 | 边看边改 | 改的是上一版的具体位置，整重跑会丢已认可部分 |
| 批量出同风格不同文案的图 | 一次定稿 | 各条互不依赖，可并行，无会话需求 |
| 同一画面多轮叠加修改 | 边看边改 | 需要保持画面主体一致，依赖上一轮状态 |
| 定稿后导出交付 | 一次定稿 | 只取最终产物，无回改需求 |
清单里只要出现一个“边看边改”步骤，整条链路就要按交互式的要求准备状态保存；如果全部是一次定稿，硬上会话只会增加状态维护和清理成本。混合场景可以拆成两段链路处理，但不要在一条请求里既要求一次给全、又要求基于上一版改。
把链路画成输入、状态、出画面、回传四段
四段划分的目的是让每一段都有明确的输入字段和输出字段，失败时能直接指到是哪一段没走通，而不是笼统地说“没出图”。下面这张表可作为接入时的字段定义底稿，具体字段名以你实际对接的接口为准，占位处按环境替换。
| 段 | 输入字段 | 输出字段 | 典型失败表现 |
|---|---|---|---|
| 输入 | 本轮指令、素材引用、模式标识、参数占位 | 校验通过的请求体、trace 标识 | 素材引用无效或参数越界，请求在进入处理前即被拒 |
| 状态 | 会话标识、版本号、上一轮产物句柄 | 可用状态快照、版本号递增结果 | 会话过期或版本号对不上，回退成从零开始 |
| 出画面 | 状态快照、本轮指令、输出格式要求 | 产物句柄或地址、本轮版本号 | 产物为空、格式不符，或返回的版本号与预期不一致 |
| 回传 | 产物句柄、交付目标、回写字段 | 交付记录、落库或落盘结果 | 产物已生成但未回写到业务侧，前端拿到空链接 |
最容易被忽略的是状态段和回传段。状态段的失败往往不报错，只是静默退化成一次全新生成，表现为“改了半天没变化”；回传段的失败常出现在产物已生成、业务侧却拿不到的场景，排查时应从回写字段和存储位置查起，而不是反复怀疑生成质量。
用最小调用骨架跑通一次完整链路
先用一条最小请求把四段串起来，不要一上来就接业务逻辑。下面的骨架是通用形态，接口地址、参数名、鉴权方式都用占位符，落到你的环境时需要替换成实际值。
POST {BASE_URL}/v2/{resource}/turn
Content-Type: application/json
Authorization: Bearer {TOKEN}
{
"mode": "one_shot | interactive",
"input": {
"prompt": "<本轮指令文本>",
"assets": ["<素材引用，可为空>"]
},
"state": {
"session_id": "<会话标识，一次性生成可为空>",
"revision": 0
},
"render": {
"format": "<输出格式>",
"size": "<尺寸占位>"
}
}请求发出去后，重点不是看返回是否 200，而是看四段是否都留下了可检索的痕迹。建议在每段打一条结构化日志，字段至少包含 trace 标识、段名、模式、版本号和关键句柄，四段共用同一个 trace 标识。
{"trace_id":"<ID>","stage":"input","mode":"interactive","revision":0}
{"trace_id":"<ID>","stage":"state","session_id":"<SID>","revision":0,"snapshot":"<句柄>"}
{"trace_id":"<ID>","stage":"render","handle":"<产物句柄>","revision":1}
{"trace_id":"<ID>","stage":"return","delivered":true,"revision":1}验证方式就一条：用 trace 标识过滤日志，确认四个段名都出现了。命令可以这样写，把占位符替换成实际值：
grep '<trace_id>' app.log | grep -o '"stage":"[a-z]*"' | sort -u如果只出现 input 和 render，说明状态段没有真正参与，链路很可能退化成了一次性生成；如果出现 input、state、render 但没有 return，问题在回写环节。四段齐全之后，再用同一个 session_id 发第二轮、把 revision 增一，观察第二轮返回的版本号和产物句柄是否与第一轮关联，这是交互式链路是否真的连着的最直接证据。
按边界决定走一次性生成还是交互式改写
把判断固化成规则，写进接入说明里，下次有人问“能不能实时改”时直接对表，不用重新讨论。下表是建议的判断条件，具体阈值需结合自己的调用额度、素材大小和会话保活时长确认。
| 选择 | 满足条件 | 成本观察点 |
|---|---|---|
| 一次性生成 | 步骤全部为一次定稿；指令和素材一次可给全；失败可接受整段重跑；输出直接交付或进入下一独立环节 | 单次调用量、整体轮次数、因重跑带来的重复消耗、产物是否需要长期保存 |
| 交互式改写 | 存在至少一个边看边改步骤；改动基于上一版局部；需要保持画面主体一致；多人交替在同一产物上操作 | 会话保活时长与过期策略、状态存储占用、每轮增量调用的次数、状态复用是否真的生效 |
两类都不完全满足时，常见做法是先走一次性生成确定基调，再切到交互式做局部修正，但两条链路的产物句柄和版本号要显式衔接，否则又会被排查成“改了没效果”。另外，交互式的成本主要不在生成本身，而在状态保存和过期清理，如果业务侧只需要最终结果，把会话保活时间设短一些通常更省心，这一点需要结合自己的调用频率确认。
走通 X2.0 链路的顺序建议是：先列可变性清单定方向，再把四段字段定义写清楚，然后用最小骨架跑一遍并确认日志四段齐全，最后把判断规则固定下来防止回退。任何一步的判断，都应以日志和页面行为能观察到的事实为准，观察不到的部分先当成没走通。