视频能生成、也能发出去，但成片效果时好时坏，这类问题在 Fableclip 里通常不是某一个点坏了，而是生成端和发布端的变量混在一起：提示词被微调过、素材被换过、账号掉了登录、排期时间配错，都会表现为“发出去效果不稳定”。可行的做法是把生成端和发布端当成两套独立配置来管：生成端只锁定提示词模板和素材桶，发布端只维护账号状态表和排期表；排期表里只引用 account_id，不内嵌账号信息。这样任何一次异常都能先归到某一端，再往下查具体字段。

先冻结一版生成端提示词模板（固定字段写死、可调字段只留占位符），素材按题材分桶并写明替换规则；发布端的账号状态表和排期表分两张表维护。出问题时先比对生成记录的输出规格是否与冻结版一致，再看发布记录的失败原因字段，能二分就不做全链路重跑。这套做法适合单人或有小团队、同时维护多个账号发布的情况；平台侧改版或账号规则变化时，仍需要回到两端分别确认，不能只依赖一次冻结。

在生成端把提示词模板冻结成一版

冻结的意思很具体：今天生成用的这版模板，一周后还能原样取出来重放，并且能说清中间改过什么。做法是把模板拆成固定字段和可调字段两部分，固定字段直接写进模板文件，可调字段只用占位符，不允许在生成时顺手改正文结构。

版本记录建议只记三行，写在模板文件头部的注释块里，格式固定为日期加改动点，便于和生成记录里的 prompt_version 对上：

版本: gen_template_v1
冻结日期: YYYY-MM-DD
改动点: 首次冻结；固定画幅/时长/镜头数/字幕位置/输出编码；可调字段限定为 5 项
对比基准: 之后所有异常对比都以本版输出规格为准

冻结后的第一版模板内容可以长这样，占位符用双花括号，注释只保留判断信息：

# fableclip/prompts/gen_template_v1.txt
[固定] 画幅: 9:16
[固定] 时长: 15s
[固定] 镜头数: 4
[固定] 字幕位置: 底部居中
[固定] 输出: h264 / 30fps
[可调] 题材: {{topic}}
[可调] 主体描述: {{subject}}
[可调] 场景: {{scene}}
[可调] 节奏: {{pace}}      # 慢 / 中 / 快
[可调] 结尾动作: {{ending}}

验证方式是：用同一组可调字段连续生成两次，比对两条生成记录里的输出规格字段（分辨率、时长、帧率、编码）是否一致。一致说明模板这版已经稳定，可以作为后续对比的基准；不一致说明还有隐藏变量没锁住，先别动发布端。

素材库按题材分桶并写清替换规则

素材漂移是成片风格突变的常见来源，而且很难在成片中直接看出来。分桶命名建议固定成「题材-场景-版本」三段，例如 city-night-wide-v1、food-closeup-v2，桶名直接进生成记录的 bucket_id 字段，后面排查时能对上。

每个桶的素材数量建议不少于该题材单月计划产出条数的两倍，并且同一桶里至少保留两个不同场景，避免一个题材长期只靠一条素材在轮。

替换素材时必须逐项检查三件事：

1. 新素材的时长、画幅是否落在模板固定字段允许的范围内，超出范围会直接改变输出规格。
2. 新素材是否写进了桶的索引文件（记录文件名、加入时间、替换原因），没写索引等于下次对比时找不到这次改动的来源。
3. 同一次调整是否只动了一个桶。同时换两个以上题材桶，后面出问题时无法判断是素材还是提示词的问题。

发布端把账号管理和排期表分开维护

账号和排期放在同一张表里，最常见的后果是账号一掉登录，整张表的字段都被顺手改一遍，排期本身的问题被掩盖。建议拆成两张表，排期表只引用 account_id。

# account 表（账号状态，按账号更新）
account_id | platform | nickname | session_updated_at | status | last_post_result | note
status: normal / limited / expired

# schedule 表（排期，按计划条目更新）
plan_id | account_id | asset_batch | plan_time | timezone | status | fail_code | submit_id
status: pending / scheduled / sent / failed

两张表的交叉检查顺序建议固定为：先看排期表 status，再看 account 表 status，最后回到生成记录。原因是排期表回答的是“这条本该什么时候发、有没有到点、提交返回了什么”，账号表只回答“这个账号当时能不能发”。如果一上来先看账号表，遇到临时掉登录容易直接归因到账号，把排期配错、时区填错这类问题漏掉。

出问题时按端二分排查

先把变量按端归位，再决定查哪张表：

生成记录至少要看这几个字段：run_id、prompt_version、bucket_id、输出分辨率、时长、帧率、编码、文件大小是否非零。发布记录至少要看：plan_id、account_id、提交时间、status、fail_code，以及平台返回的原文，原文比失败码更有定位价值。

判断分支可以按下面四条走：

• 输出规格与冻结版不一致：判为生成侧。先查 prompt_version 是否被改过，再查 bucket_id 是否换桶；两者都正常时，用同一模板同参数重跑一次做对照，再考虑外部模型波动。
• 输出规格一致、发布记录 status=failed：判为发布侧。看 fail_code，登录态类问题先修账号，参数类（文案、尺寸、时区）只改对应排期条目，不动模板。
• 两端记录都“正常”但效果不稳：回到可调字段和素材桶做单变量对照，一次只改题材或只换一个桶，其余保持冻结版不变。
• account.status 显示 limited 或 expired：先处理账号，排期条目暂时保持 pending 不动，避免批量提交失败把原本的失败码覆盖掉，丢失排查依据。

这套分法的边界也要说清：它只能保证变量可归位、可对比，不能保证每次生成效果一致；平台侧接口或规则调整时，需要重新确认输出规格字段是否还够用，必要时把新增字段补进生成记录的校验清单。