D14 一季五集：批量产出、作品集包装与短剧生产线面试专题

今日目标

能用一次运行产出一季五集，并说清跨集一致性是怎么保住的
能把这个项目包装成一份别人三分钟能看懂的作品集材料
能面对追问讲清这条线的架构取舍、成本控制与失败处理

前十三天你把一条线从零搭到了能发行。今天做两件事：让它一次跑出一季，然后把它变成别人能看懂、你能讲清楚的东西。读完回到页面顶部把上面三条勾掉。

小白版讲解

从一集到一季：靠档案，不靠记性

剧组杀青那天有个固定动作叫「对场记本」。整部戏拍了几十天，谁在哪一场穿了哪件衣服、道具放在桌子的左边还是右边，全靠那本子。没有人靠记性维持连贯，靠的是一份所有人都认的档案。

跨集一致性也是同一件事。很多人第一次做多集生成时的做法是：把第一集的提示词复制到第二集，手改几个词，再复制到第三集。前两集看着还行，到第四集主角的外套就变了颜色，第五集连发型都换了。原因不神秘——每复制一次，就多一次人为改动的机会，五集之后误差已经攒到肉眼可见。

正确做法是 D2 建立的那份世界观档案：人物卡、风格词、场景表，全部只存一份。然后立一条硬规矩：

每一镜的提示词，只能由「档案 + 本镜的分镜描述」拼出来，不允许手写。

这条规矩把「保持一致」从一件需要自律的事变成了一件结构上做不到不一致的事。人物外貌逐字取自档案里的 appearance 字段，风格词逐条附加在每一条提示词末尾，音色从人物卡的 voiceId 取——只要拼装函数只认档案，第五集的主角就不可能换外套。

prompt.js

// 提示词只从档案里拼：外貌逐字取 cast，风格词逐条附加，不允许手写
function imagePrompt(world, shot) {
  const who = shot.characters
    .map((id) => world.cast.find((c) => c.id === id))
    .filter(Boolean)
    .map((c) => `${c.name}（${c.appearance}）`)
    .join('，')
  return [shot.visual, who, `${shot.shotSize} 景别`, ...world.styleTokens]
    .filter(Boolean)
    .join('，')
}
 
// 集间钩子：第 N 集的 hook 必须逐字等于第 N+1 集的 pickUp
function checkHookChain(season) {
  const broken = []
  for (let i = 0; i < season.length - 1; i += 1) {
    if (season[i + 1].pickUp !== season[i].hook) {
      broken.push(`E${season[i].n} → E${season[i + 1].n}`)
    }
  }
  return { pass: broken.length === 0, broken }
}

prompt.py

def image_prompt(world, shot):
    """提示词只从档案里拼：外貌逐字取 cast，风格词逐条附加，不允许手写。"""
    by_id = {c["id"]: c for c in world["cast"]}
    who = "，".join(
        f"{by_id[cid]['name']}（{by_id[cid]['appearance']}）"
        for cid in shot["characters"]
        if cid in by_id
    )
    parts = [shot["visual"], who, f"{shot['shot_size']} 景别", *world["style_tokens"]]
    return "，".join(p for p in parts if p)
 
 
def check_hook_chain(season):
    """集间钩子：第 N 集的 hook 必须逐字等于第 N+1 集的 pickUp。"""
    broken = [
        f"E{cur['n']} → E{nxt['n']}"
        for cur, nxt in zip(season, season[1:])
        if nxt["pick_up"] != cur["hook"]
    ]
    return {"pass": not broken, "broken": broken}

一季比一集多出来的第二样东西是集间钩子。单集是完整的，一季要让人追下去，所以每集结尾要留一个问题，下一集开头要接住它。这件事也别靠记性：在每集的计划里写死 hook 与 pickUp 两个字段，第 N 集的 hook 必须逐字等于第 N+1 集的 pickUp，程序开跑前先校验一遍。断链了就报错，别等五集都生成完才发现第三集和第四集接不上。

实验里的一致性检查一共五条，全部只看输入不看画面：角色都在档案里、音色跨集不变、外貌描述逐字来自档案、风格词每一镜都带上了、集间钩子首尾相接。为什么只看输入？因为画面好不好是 D11 机器审片的职责，这一天查的是「输入有没有漂」——输入不漂，输出才有可能不漂。这两道检查是互补的，谁也替代不了谁。

那一季跑完之后，你手里到底有了什么？这就要看账。

一次真实运行的复盘：四个数字

复盘只看一个总时长或者一句「跑通了」是没用的。一次运行至少要留下四个数字：耗时、花费、失败率、人工介入次数。 少一个，这条线在别人眼里就还是个黑盒。

四个数字各自回答一个不同的问题：

耗时回答「能不能按时交」。它决定你敢不敢接一周五集的活。
花费回答「能不能赚钱」。单集成本乘以集数，就是你的成本底线。
失败率回答「稳不稳」。注意分母要是调用次数而不是集数——一集里有二十次调用，其中一次失败重试，失败率是 5% 而不是 20%。实验默认不注入失败，加上 INJECT=taskfail 再跑一次，就能看到失败那一列真的动起来。
人工介入次数回答「能不能扩」。这个数字最容易被忽略，也最重要：如果一集需要三次人工介入，那么这条线一周最多产出多少集，取决于人的时间而不是机器的时间。

实验跑完打印的整季账单长这样：

TextText

── 整季账单 ──
   集  标题        耗时      图  视频秒  语音字  调用  失败  人工  花费(估算)
   E1  捡到         1257ms   2       8      18     6     0     0  ¥4.0563
   E2  讣告         1270ms   2       8      22     6     0     0  ¥4.0577
   E3  父亲的表       1171ms   2       8      24     7     1     0  ¥4.0584
   E4  同一只表       1154ms   2       8      16     6     0     1  ¥4.0556
   E5  关机         1144ms   2       8      13     6     0     0  ¥4.0545
   合计 5 集，6.0 秒，调用 31 次，失败 1 次（失败率 3.2%），人工介入 1 次
   花费（估算）¥20.2825，单集 ¥4.0565

有两处口径要交代清楚，它们直接决定这份账单可不可信。

第一，失败的调用也要进账单。一次失败重试占用了时间和配额，只是可能不扣费。不记进去，你算出来的「单集调用次数」会偏低，容量规划全错——按 D9 那张速率限制表推算并发时，用错的分母算出来的结论会让你在真实环境里一头撞上限流。

第二，花费仍然是估算，而且三档单价的可信度并不一样。图像 ¥0.025 一张是官方直接标价；语音官方只公开资源包价，每字符单价是折算的；视频那一档最微妙——按量付费页给的是几个清晰度档位的按秒单价，而本课用的视频接口在官方是走视频点数扣减的，两套口径不通用，所以代码里那个每秒常量只是台账演示值，不挂到任何具体模型 id 上（D12 展开讲过这件事）。这三句话要原样写进作品集文档，别让读的人误以为你贴了一张真实账单。

顺带说个数字上的观察：整季 ¥20.28，其中视频依然占九成以上。十四天下来，这条线上的成本结构从来没变过。 这也是 D12 那个判断的最好注脚——所有工程设计都围着「怎么少调一次视频接口」转，不是因为它优雅，是因为账就是这么算的。

ledger.js

function summarize(records) {
  const attempts = records.reduce((s, r) => s + r.attempts, 0)
  const failures = records.reduce((s, r) => s + r.failures, 0)
  const totalCny = Number(records.reduce((s, r) => s + r.estimatedCny, 0).toFixed(4))
  return {
    episodes: records.length,
    totalMs: records.reduce((s, r) => s + r.ms, 0),
    totalCny,
    perEpisodeCny: records.length ? Number((totalCny / records.length).toFixed(4)) : 0,
    // 分母是调用次数，不是集数——用错分母的失败率会让容量规划整体偏乐观
    failureRate: attempts ? Number((failures / attempts).toFixed(4)) : 0,
    // 这个数字决定这条线能不能扩：它受限于人的时间，不是机器的时间
    manualTouches: records.reduce((s, r) => s + r.manualTouches, 0),
  }
}

ledger.py

def summarize(records):
    attempts = sum(r["attempts"] for r in records)
    failures = sum(r["failures"] for r in records)
    total_cny = round(sum(r["estimated_cny"] for r in records), 4)
    n = len(records)
    return {
        "episodes": n,
        "total_ms": sum(r["ms"] for r in records),
        "total_cny": total_cny,
        "per_episode_cny": round(total_cny / n, 4) if n else 0,
        # 分母是调用次数，不是集数——用错分母的失败率会让容量规划整体偏乐观
        "failure_rate": round(failures / attempts, 4) if attempts else 0,
        # 这个数字决定这条线能不能扩：它受限于人的时间，不是机器的时间
        "manual_touches": sum(r["manual_touches"] for r in records),
    }

作品集怎么包：三样东西对应三种读者

代码写完不等于作品集做完。一个只有仓库链接的项目，在别人眼里就是「跑了个脚本」——因为没人会为了看懂你的项目去读源码。

作品集要出三样东西，它们对应三种完全不同的读者：

一段演示片花，给三分钟就走的人。 招聘经理、猎头、非技术的面试官，他们不会跑你的代码。三十秒的片花把「一句话进、一季成片出」这件事直接演出来，比一千字的说明有用。实验里的做法是每集抽第一镜，流复制拼成一条——注意这里也不重编码，同一套编码参数拼接用 -c copy 就够了，一季五集加片花要拼六次，每次都重压一遍既慢又掉画质。

一张架构图，给技术面试官。 图的作用不是好看，是让对方在三十秒内知道该往哪儿提问。所以图上要有的不只是流程，还得有那几个横向的基础设施块——工作流引擎、并发闸门、成本熔断、审核台——因为它们才是这个项目和「调了几个 API」的分界线。

Mermaid 源码

mermaidmermaid

flowchart TD
  idea[一句话选题] --> script[剧本 Agent 结构化分镜与自动评审]
  world[(世界观档案 人物 风格 钩子)] --> script
  script --> assets[角色与场景资产]
  assets --> frames[每镜首帧]
  frames --> clips[镜头视频 异步任务轮询]
  script --> voice[配音与字幕]
  clips --> compose[ffmpeg 合成 竖屏成片]
  voice --> compose
  compose --> qc[质检与合规]
  qc --> release[多平台发行 一次渲染多次封装]
  engine[工作流引擎 幂等与断点续跑] --- clips
  gate[并发闸门与配额] --- clips
  budget[成本路由与预算熔断] --- clips
  console[人机协作审核台] --- qc
  release --> data[数据回收 留存曲线映射回环节]
  data --> script

一份说明文档，给会认真读完的人。 它要在开头就回答三个问题：这是什么、跑一次的真实数字是多少、代码怎么跑起来。实验会把整季账单的数字自动填进这份文档，所以你交出去的不是一份模板，是一份带着真实运行结果的报告。

三样东西缺一样，效果就会打折：只有片花，技术面试官觉得你在做视频；只有架构图，非技术的人看不懂；只有文档，没人有耐心读完。

还有一条容易被忽略的：这三样都要能在没有你在场的情况下自己说清楚。 作品集最常见的用法是被转发出去——招聘经理发给技术负责人，技术负责人扫一眼架构图再决定要不要约你。所以片花开头三秒要交代这是什么，架构图上的每个块都要有名字而不是缩写，文档第一段就要给出规模与数字。任何一样需要你在旁边补一句「这里其实是……」，它在转发链上就断了。

面试怎么讲：三个技术故事

最后一段留给面试。这个项目能讲的东西太多，而面试时间只有几十分钟，所以要先收敛成三个故事，每个故事两分钟能讲完，且各自命中一类不同的考点。

故事一：整套工程设计都围着一条判断。 开头先给数字——视频占单集成本九成以上，且最慢最容易失败。然后把幂等键、产物缓存、参考图复用、草稿档路由、预算熔断一条条挂上去，说明它们全是这条判断的推论。这个故事考的是你有没有系统性的取舍能力，而不是会不会用某个库。它的杀伤力在于：面试官问任何一个组件的时候，你都能把话头引回同一条主线。

故事二：异步任务的客户端怎么写才不会把自己拖死。 提交、轮询、取件、下载四步，每一步都会失败，而失败还分能重试与不能重试两类。状态机加指数退避，加超时放弃，加按错误码分类，再加上「失败与被安全审核拦下的调用不扣费」这类计费口径。这个故事考的是工程细节的密度，也是最容易展开追问的一个——准备好回答「重试几次」「退避到多久」「超时怎么定」。

故事三：人该站在流水线的哪一格。 全自动会产出一堆没人看的片子，全人工又跑不动量。审核台把人放在「质检之后、发行之前」这一格，并且把「改一句台词」翻译成「哪些下游节点需要重算」。这个故事考的是产品感，也是多数候选人答不出来的一类——它证明你想过这个系统是给人用的。

三个故事对应三类考点：系统取舍、工程细节、产品判断。讲的时候有两条通用规矩：每个故事都要有一个具体数字（九成、四步、一格），数字是可信度的来源；每个故事都要留一个可被追问的钩子，主动把面试官引到你准备最充分的地方去。

至于「如果重做一遍会怎么改」这类问题，诚实回答比编一个完美方案好。这条线上真正值得改的地方就摆在那儿：审核台的重算范围现在是按节点依赖算的，粒度还可以更细；成本估算表里那几个折算单价，接了真实账单之后应该换成实测值。说得出自己方案的边界，比说得出方案本身更能证明你真的做过。

这条线还能往哪走

十四天结束了，但这条线还有一个自然的下一步：把流程里反复用到的判断，从代码里提出来。

你现在的项目里，有一批东西既不是通用代码也不是业务数据，而是「经验」：分镜该怎么切、提示词该怎么拼、失败该怎么分类、什么情况该叫人。它们现在散落在函数里、注释里、常量表里。换一个题材、换一家厂商，这批经验大部分仍然成立，但你得重新在新代码里把它们摊一遍。

把这批经验沉淀成一份可复用的能力包，是很自然的下一步——平台上的 Agent Skill 那门课讲的就是这件事：怎么把「作业指导书」从代码里分离出来，让同一套经验在不同项目里被反复加载。如果你打算把这条线继续往产品方向做，那是个合适的接续点。

源码导读

动手实验

🧪 D14 实验：一次运行产出一季五集的批量脚本与一份作品集材料

代码位置：labs/ai-drama-pipeline/day-14-season-portfolio

验收标准：

一次运行产出五集，output/ 下有 episode-1.mp4 到 episode-5.mp4
跨集一致性检查五项全绿；把某一集的 hook 改掉，「集间钩子首尾相接」立刻变红
整季账单打印出每集的耗时、图像张数、视频秒数、语音字数、调用次数、失败次数、人工介入次数与估算花费；加上 INJECT=taskfail 重跑，合计行的失败率从 0.0% 变成 3.2%
output/portfolio/demo.mp4 由五集各抽第一镜流复制拼成，日志里看不到重编码的痕迹
output/portfolio/README.md 里的数字与本次运行的账单一致，三个技术故事的骨架已经写好

动手之前先想清楚一件事：这个实验的产出不只是代码，还有那份 portfolio/README.md。程序会把数字填好、骨架搭好，剩下三个技术故事的血肉要你自己补——那才是这一天真正的交付物。

先原样跑一遍 starter，对着一致性检查的红叉和账单里的零，判断哪几处逻辑还没实现。
把提示词改成只从档案里拼，重跑确认「外貌逐字来自档案」与「风格词每一镜都带上了」两项转绿。
补上集间钩子的比对，然后故意改掉某一集的 hook，确认这一项当场变红。
实现花费估算与流复制拼接，确认账单不再全是零、且日志里看不到重编码；再用 INJECT=taskfail 跑一次，确认失败列与失败率跟着变。
打开生成出来的 portfolio/README.md，把三个技术故事各扩写成两分钟能讲完的版本，再对着面试追问清单自答一遍，标出还答不上来的地方。

面试题

今天 3 道题在下方题库区，侧重跨集一致性的工程手段、项目讲述的结构、以及这条线的整体架构取舍。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。标注「国内高频 / 海外高频」方便按目标市场取舍。

检查清单与明日预告

能用一次运行产出一季五集，并说清跨集一致性是怎么保住的
能把这个项目包装成一份别人三分钟能看懂的作品集材料
能面对追问讲清这条线的架构取舍、成本控制与失败处理
能说出一次运行必须留下的四个数字，以及失败率的分母为什么是调用次数
三个技术故事都能在两分钟内讲完，且各自带一个具体数字
实验的 5 条验收标准全部通过
3 道面试题不看要点也能答出至少 2 道

结课与下一步。没有第 15 天了，这门课到这里结束——回头看第 1 天那张任务图，你现在写的东西比它多了幂等、并发、审核、质检、成本、发行和一季批量。接下来两件事值得做：一是拿你自己的题材把这条线真跑一遍，把作品集里的数字换成真实运行的；二是顺着上面「还能往哪走」那一节，把这条线里的经验沉淀成可复用的能力包。祝拍摄顺利。

一季五集：批量产出、作品集包装与短剧生产线面试专题