一、三版，一版比一版短

三个版本砍了 17% 的时长，成本跟着砍。每一刀都砍在场景上，不是砍在参数上。 第二版解决的是「画面比声音长」——压到 7.2 秒，正好对齐口播。 第三版解决的是「收尾太散」——最后两句本来就是一回事，并成一镜少一个镜头。

二、两个动作的顺序不能反

先合并，再压秒。反过来先压秒，被合并的那两句就撑不住了——两个 5 秒的镜头，并起来也只有一个话题。 压秒伤的是节奏，合并伤的是信息。 两个都得做的时候，先做伤信息那个，因为信息少了你能看出来， 节奏乱了你不一定看出来。 这条经验不只在做视频时成立。任何「删内容」和「改参数」同时做的时候，先删内容。

三、跑不通的时候，先看哪一步

四种症状对应四个不同的位置。从症状倒推位置，比从头看一遍快得多。 第三种最阴：镜头数被平台静默截断，不报错，只是少了几秒。必须数一遍，不能信返回的「成功」。 这种「静默失败」最难查，因为它不走错误分支。凡是数得出来的东西，都该数一遍再信。

四、调试的顺序

四步里第三步最容易被跳过。它验的不是「能不能做出来」，是「做不出来时怎么办」。 不验这一步，上线第一次超限就出事——而且是没人知道为什么的那种。 第四步要看两个数：总时长和成本。两个都要和预估对得上，对不上就是哪一步算错了。

五、这一章最容易翻车的三处

三处都不是「写错了」，是「没算」。这一章的技术难度最低，算术密度最高。 一条 60 秒的新闻视频，涉及的字数、秒数、镜头数、单价，加起来七八个数。 这七八个数里错一个，出来的东西就是错的，而且不一定报错。

六、项目小结：这一章和上一章是同一种形状

两章的结构完全一样：提交、等待、取货，外加一个「先拦后生成」。换的是外壳，不是骨架。 所以第 14 章那三条教训在这里照样成立：先拦后生成、异步要分状态、结果是链接不是任务号。 认得出「这是同一种形状」，比记住十个案例的细节有用。 第 16 章会把这句话推到更远的地方—— 连智能体本身都能当零件。

七、动手 Demo：调试：先跑通，再调短

先算三版的时长和成本，再看四种症状各对应哪一步，最后定调试顺序。

def run(n_shot, shot_s, vid_p=0.6, tts_p=0.02):
    video = n_shot * shot_s
    words = int(video / 60.0 * RATE)
    cost  = video * vid_p + words * tts_p
    return video, words, cost

run(6, 8.0)   # 48.0 秒, 32.64 元
run(5, 8.0)   # 40.0 秒, 27.20 元

实跑输出：

--------------------------------------------------------------------
调试：先跑通，再调短
--------------------------------------------------------------------


  ① 三版，一版比一版短
  --------------------------------------------------------------------

| 版本 | 镜头数 | 每镜秒 | 总时长 | 口播字数 | 成本（元） |
|---|---:|---:|---:|---:|---:|
| 第一版 | 6 | 8.0 | 48.0 | 192 | 32.64 |
| 第二版 | 6 | 7.2 | 43.2 | 172 | 29.36 |
| 第三版 | 5 | 8.0 | 40.0 | 160 | 27.20 |

  第一版 48 秒、32.64 元；第三版 40 秒、27.20 元。时长砍了 17%，成本跟着砍。
  两个动作：先把每镜从 8 秒压到 7.2 秒，对齐口播；再把收尾两句并成一个镜头，少一镜。
  注意顺序：先合并，再压秒。 反过来先压秒，被合并的那两句就撑不住了。

  ② 跑不通的时候，先看哪一步
  --------------------------------------------------------------------

| 症状 | 多半是 | 先查什么 |
|---|---|---|
| 视频是黑的 | 图片那一步没给素材 | 看图片模块的输出条数 |
| 没声音 | 配音没接上音轨 | 看合并节点的输入端口 |
| 少了最后一段 | 镜头数超了上限被截断 | 数镜头数 |
| 整条卡住 | 生成那一步在等 | 看单镜耗时 |

  四种症状对应四个不同的位置。从症状倒推位置，比从头看一遍快得多。
  第三种最阴：镜头数被平台静默截断，不报错，只是少了几秒。必须数一遍。

  ③ 调试的顺序
  --------------------------------------------------------------------

| 步 | 跑什么 | 验什么 |
|---:|---|---|
| 1 | 只跑一个镜头 | 确认单镜能出片 |
| 2 | 跑三个镜头 | 确认拼接没问题 |
| 3 | 跑全量，时长设 15 秒 | 确认被截断时行为正常 |
| 4 | 跑全量，正式时长 | 看成本和总时长 |

  四步里第三步最容易被跳过。它验的是「超限时怎么办」——不验，上线第一次超限就出事。
  第 15.4 节的顺序和第 14 章一样：先用最小输入跑通，再全量。
  反过来，出了问题你不知道是哪一段的错。

  ④ 这一章最容易翻车的三处
  --------------------------------------------------------------------

| 翻车点 | 表现 | 怎么躲 |
|---|---|---|
| 画面比声音长 | 尾部几秒没声音 | 生成前按音轨算总时长 |
| 镜头被截断 | 少最后一段，不报错 | 数镜头数，别信返回的成功 |
| 竖屏横屏搞混 | 整条重生成 | 生成前把比例定死 |

  三处都不是「写错了」，是「没算」。这一章的技术难度最低，算术密度最高。
  ! 一条 60 秒的新闻视频，涉及的字数、秒数、镜头数、单价，加起来七八个数。
  这七八个数里错一个，出来的东西就是错的，而且不一定报错。

①三版对比：48 / 43.2 / 40 秒，成本 32.64 / 29.36 / 27.20 元，砍了 17%。 ②两个动作的顺序：先合并伤信息，再压秒伤节奏。 ③四种症状对应四个位置，从症状倒推最快。 ④调试四步：单镜、三镜、全量限时、全量正式。 ⑤三处翻车都不是写错，是没算。这章算术密度最高。

30 秒实验

1. 把你的片子按 8 秒和 7.2 秒各算一次成本。差多少？值不值得为这个差额改生成参数？
2. 跑一次「限时 15 秒」的测试，看它在超限时是报错还是静默截断。
3. 把你这章算过的所有数（字数、秒数、镜头数、单价）列成一张表，逐个核对来源。

常见误区

1. 「先压秒再合并。」先压秒，被合并的两句就撑不住了。先删内容，再改参数。
2. 「返回成功就是成功了。」镜头数会被静默截断。数得出来的东西都该数一遍。
3. 「限时测试没必要。」它验的是超限时怎么办。不验，上线第一次超限就出事。

八个单 Agent 案例完了。下一章换一种做法：把智能体也当零件，一个主 Agent 带三个专家。

• ☐ （本篇完，下一篇 16.1 认识多 Agent）

相关笔记

• 工作流核心模块配置：上一节连五段
• 应用优化与质量控制要点：上一章的调试与质量
• 认识多 Agent：下一章进入多 Agent
• 🐦 扣子开发 AI Agent · 索引