Test Environment · Rewrite Quality

初稿防止模板化，扩写不要牺牲自然度

这条初稿出现两次 どんどん，单看未必不自然；真正明显的问题，是扩写把它放大到六次。建议轻量校正初始写作偏好，重点加强扩写，并让所有文本在进入 TTS 前通过质量检查。

核对时间：2026-07-21 CST · 范围：Ignis Test / Tobatsu combo runner

Initial Script 2 次

两处语义不同，不能仅凭次数直接判错。

Final Script 6 次

时长扩写又新增 4 次，最终被正常接受。

Rewritten 7 / 7

本次所有分段都进入了时长改写。

Quality Gate 0 道

当前没有独立的自然度或整稿重复检查。

01 · Diagnosis

初稿问题较轻，扩写问题更明确

已经做得好的部分

  • 逐段生成 TTS，并测量实际时长。
  • 轻微偏差可用小幅语速调整。
  • 偏差较大时返回 needs_rewrite。
  • 保存历次文本、时长和秒数差。
  • 只重跑改过的分段，其余走缓存。
  • 单段最多改写 5 次，避免无限重试。

现在缺少的部分

  • 没有整篇脚本的重复表达检查。
  • 没有目标语言自然度检查。
  • 没有判断新增文字是否带来有效信息。
  • 没有独立审核扩写前后的语义变化。
  • 没有把共性写作要求带进扩写。
  • 时长合适后，文本就可以继续下游制作。

这条初稿不能直接判错。需要治理的是长期模板化偏好，以及扩写只顾填满时间、没有守住整稿质量。

02 · Evidence

这条任务如何从 2 次变成 6 次

分段 初稿情况 扩写动作 结果
segment 1 已有 1 次 扩写时再补 1 次 同一分段出现 2 次
segment 2 没有 新增“どんどん強化” 新增 1 次
segment 3 没有 新增“どんどん高く” 新增 1 次
segment 4 已有 1 次 保留原表达并继续加口头语 保留 1 次
segment 5 没有 新增“どんどん拠点を” 新增 1 次

few-shot 中最相近的捕鱼案例只自然使用了 1 次。初稿需要轻量校正写作偏好；扩写新增 4 次，是本次更直接的质量问题。

03 · Ownership

要改两层，不能只更新 Seedance Skill

Ignis Skill

  • 负责初始脚本和任务参数。
  • 加入柔性的整稿写作要求。
  • 初稿进入 TTS 前做一次轻量检查。
  • few-shot 继续提供玩法表达参考。
  • 不限制具体词，也不建立黑名单。
  • 标准 UE 与 Seedance 保持一致。

Tobatsu 扩写流程

  • 负责 needs_rewrite 后的扩写和缩写。
  • 把完整脚本和前后文交给改写者。
  • 新增文本质量检查。
  • 质量通过后，再生成并测量 TTS。

04 · Proposed Flow

建议用两道检查，而不是混成一个判断

CHECK PASS QUALITY FAIL DURATION FAIL CANDIDATE 扩写候选 带整稿与秒数反馈 GATE 01 文本质量检查 自然 · 不重复 · 不改意 PROVIDER 生成分段 TTS 只重跑改过的段 GATE 02 时长检查 秒数 · 语速 · 时间窗 ACCEPT 接受该分段 进入整稿复核 LEGEND 必须通过的检查 付费生成节点 失败后返回改写
同一道文本质量检查可以复用于初稿和扩写候选。它放在 TTS 之前，先挡住明显问题；任何文本变化仍要重新测时长，因此不会绕过现有时间判断。

05 · Work Packages

初稿轻量优化，扩写重点治理

优先级 修改项 改哪里 复杂度 完成标准
P0-L 校正初始写作偏好 Ignis Skill / 初始写作提示 低 整稿检查表达多样性，不限制具体词语。
P0 增强扩写要求 WORKFLOW.md 与 handoff 内容 低 扩写优先补具体动作，不靠副词填时长。
P0 提供完整脚本 needs-rewrite.json 低至中 改写者能看到整稿、前后文和已重复表达。
P0 加入文本质量检查 combo runner 新增独立步骤 中 质量不通过时，不调用 TTS。
P0 质量优先回退 改写次数与 fallback 选择 中 自然文本可用停顿或小幅变速，不继续灌口头语。
P1 整稿复核 所有分段通过后、数字人生成前 中 跨段重复和语气漂移能被发现。
P1 本地化回归集 runner tests / prompt fixtures 中 覆盖“原句正常、扩写后变差”的真实案例。

06 · Quality Check

质量检查先做轻量规则，再加语言审核

程序先查

  • 跨段重复副词和短语。
  • 连续相同句首和句型。
  • 人称、游戏名和术语变化。
  • 新增内容是否只有口头语。

模型再判断

  • 目标语言是否自然。
  • 是否保持原句事实。
  • 是否符合完整脚本语气。
  • 新增内容是否贴合画面。

整稿最后看

  • 多个分段是否互相重复。
  • 修改后是否出现语气漂移。
  • 是否还有机械填充痕迹。
  • 只重跑最后改过的分段。

重复检测是复核信号，不是词语黑名单。どんどん 自然出现一次没有问题。

07 · Data Contract

建议扩充 needs-rewrite 的信息

{
  "status": "needs_rewrite",
  "reason_types": ["duration", "quality"],
  "language": "ja",
  "full_script": ["全部分段当前文本"],
  "quality_context": {
    "duplicate_hits": ["どんどん"],
    "common_writing_rules": ["自然、具体、避免跨段重复"]
  },
  "segments": [{
    "segment_index": 2,
    "direction": "lengthen",
    "current_script": "...",
    "target_duration_seconds": 8.0,
    "gap_seconds": 1.4,
    "previous_segment": "...",
    "next_segment": "..."
  }]
}

如果不改数据结构，只补一句“避免重复”，改写者仍然不知道其他分段已经用了什么。

08 · Time Control

质量修改会影响时长，但现有缓存足够承接

质量结果 时长结果 下一步
通过 通过 接受分段。
通过 不通过 带秒数差重新改写，再走质量检查。
不通过 尚未生成 先改文本，不调用付费 TTS。
不通过 此前通过 文本变化后缓存失效，仅重跑该段 TTS。
多轮无法同时通过 接近目标 优先保留自然文本，用停顿或小幅变速补差。

最终选择应是“自然且基本合时长”，不是“时长完美但文案最差”。

09 · Delivery Plan

推荐分两期上线，先降低风险

PHASE 01

先校正初稿偏好，增强扩写上下文

初稿增加柔性整稿检查；扩写加入完整脚本、前后文、重复提示和共性写作要求。先用程序发现明显问题。

PHASE 02

再加入结构化语言审核

只审核被改写的分段，并查看完整脚本。质量未通过时不生成 TTS。

PHASE 03

最后补整稿复核和真实回归集

用本地化反馈验证日语、韩语、德语等语言，观察质量、时长、成本和重试次数。

10 · Acceptance

验收不要只看任务成功，要看扩写是否变差

文案

  • 扩写不显著增加重复表达。
  • 新增内容对应动作、变化或结果。
  • 人称、术语和产品事实不漂移。

时长

  • 所有文本变化都重新测量。
  • 只重跑受影响分段。
  • 达到上限后采用质量优先回退。

成本

  • 明显质量问题在 TTS 前被挡住。
  • 记录质量失败与时长失败次数。
  • 对比上线前后的重试和生成费用。