9.3 批量生产

9.3 批量生产

本节摘要：单条走查通了、一致性有防线了，量产要回答的是另一些问题：任务从哪里来、谁调度、并行开多大、人审得过来吗、一天到底能出几条。本节先把产能目标拆解成工时口径，指出真正的瓶颈通常不在生成排队，而在人工审核带宽；然后搭一个"状态即文件"的任务队列：jobs 目录下的 JSON 文件就是任务单，worker 认领、执行、归档，两个工人天然并行且互不抢单；接着讲并行度的两条硬约束——云端 API 的并发限额与本地显存的分时复用；人工审核带宽给出抽检策略与审核台目录结构；最后落一张产能账目表：日期、条数、废片、工时、成本，让"一天 N 条"从口号变成可验证、可复盘的数字。

学习目标

• 把"一天 N 条"的产能目标拆解到各站的工时口径。
• 搭建状态即文件的任务队列：认领、执行、归档、失败重排。
• 说清并行度的两条硬约束：API 限额与本地显存。
• 设计人工审核的抽检策略与审核台目录。
• 维护产能账目表并做周复盘。

一、产能目标拆解

以第 9.1 节的六十秒短剧为基准（口径示意值）：剧本与分镜含审读约二十分钟，生成排队约四十分钟（可后台化，不占人力），音频字幕约十五分钟，全片审看与返工约三十分钟。单条人工净投入约六十分钟。若目标是一天六条，人力需求是六小时——两个人一天六条很从容，一个人就得靠并行与自动化把人工环节压下来。

一天六条的时间结构（示意）

 生成排队 40min ─▶ 后台并行跑，不占人力（受 API 限额约束）
 人工环节 60min ─▶ 唯一不可压缩项 ─▶ 六条 = 6h 人工带宽
 结论：量产瓶颈是审核带宽，不是算力
​

拆解的结论通常令人意外：大家担心的是"生成太慢"，账算下来卡脖子的是"人看得太慢"。所以本节的重心不是怎么并发调 API，而是怎么组织队列、怎么设计抽检，让有限的人工带宽花在刀刃上。

二、任务队列：状态即文件

量产的调度不需要消息中间件，一个目录就是队列：jobs/queue 里每个 JSON 是一张任务单，工人认领时把文件改名挪进 jobs/doing，完成挪进 jobs/done，失败带着错误信息挪进 jobs/failed。两个工人不会抢同一单——文件改名在文件系统层面是原子的。这套设计的全部状态肉眼可见，出问题时打开目录就能诊断，与第 8.3 节"日志与状态分离"的精神一致。

# worker.py —— 批量生产工人：认领、执行、归档（状态即文件）
import json, os, shutil, time

QUEUE, DOING, DONE, FAILED = "jobs/queue", "jobs/doing", "jobs/done", "jobs/failed"

def setup():
    for d in (QUEUE, DOING, DONE, FAILED):
        os.makedirs(d, exist_ok=True)

def claim():
    for name in sorted(os.listdir(QUEUE)):
        if name.endswith(".json"):
            os.rename(os.path.join(QUEUE, name), os.path.join(DOING, name))
            return os.path.join(DOING, name)
    return None

def run_stages(job):
    for stage in job["stages"]:
        print(f"{job['id']} / {stage} 执行中")
        # 在此接技能执行器：python run_skill.py 技能名 载荷文件（见 8.1 节）

def main():
    setup()
    while True:
        job_file = claim()
        if not job_file:
            time.sleep(10)
            continue
        job = json.load(open(job_file, encoding="utf-8"))
        try:
            run_stages(job)
            shutil.move(job_file, os.path.join(DONE, os.path.basename(job_file)))
        except Exception as exc:
            job["error"] = str(exc)
            with open(job_file, "w", encoding="utf-8") as f:
                json.dump(job, f, ensure_ascii=False, indent=2)
            shutil.move(job_file, os.path.join(FAILED, os.path.basename(job_file)))

if __name__ == "__main__":
    main()
​

任务单本身是第 9.1 节站点清单的实例化：id、一句话设定、目标平台变体、stages 列表。失败任务处置遵循第 8.3 节：幂等判据保证修好原因后直接重排同一张单，已完成的阶段自动跳过。

三、并行度：两条硬约束

并行开多大不是拍脑袋，受两条硬约束。约束一：云端 API 并发与速率限额——不同服务商、不同档位差异很大，超限轻则排队重则临时封禁，以各服务现行限额文档为准；实操上给每个 worker 配独立的重试与退避（第 10.2 节）。约束二：本地显存分时——视频生成本地跑时，一块卡同时只能服务一个任务，"并行"表现为排队吞吐而非真并发；多卡才有真并行。条级并行度等于 worker 数，镜头级并行度等于 API 限额内的并发请求数，两者相乘才是日产能的生成侧上限。

四、人工审核带宽

审核是产能的一部分，不是外挂。设计原则：全自动检查拦下限（第 10.3 节质量门禁），人工只看机器看不了的部分，且按风险分配注意力。

审核台就是三个目录加一张速览表：review/todo 里放待审条目的成片与缩略图墙，审过挪 review/pass，打回挪 review/reject 并附原因标签（原因标签直接进第 10.2 节废片台账）。打回的条目按镜头粒度定位问题，不整条重做。

五、产能账目表

账目表是量产的仪表盘，一天一行：

# daily_log.csv —— 产能账目表表头与示例行（金额为示意口径）
date,finished,reject_shots,review_hours,gen_cost_usd,note
2026-10-15,5,3,4.5,约 52 美元,雨夜系列第 3~7 条
2026-10-16,6,1,5.0,约 61 美元,新风格模板首日，全查通过
​

五列各有用途：finished 对目标；reject_shots 连着废片率（第 10.2 节）；review_hours 是人工带宽的实测值，决定你能承诺的日产能；gen_cost_usd 连着成本台账（第 10.1 节）；note 记例外——哪天换了模板、哪天服务波动，复盘时全靠它解释数字异常。周复盘看三件事：产能达成率、废片率走势、单条人工耗时走势。第三项最容易被忽略也最有价值：它下降说明自动化在进步，平台期说明下一轮优化该瞄准人工环节了。

本节要点回顾

• 产能拆解先算人工净投入：量产瓶颈通常是审核带宽，不是生成排队。
• 状态即文件的任务队列：目录可见、改名认领、失败重排、幂等续跑。
• 并行度两条硬约束：API 限额与本地显存分时，日产能是两级并行的乘积。
• 审核按风险分配注意力：首尾必查、中间抽样、新模板首条全查。
• 账目表一天一行，五列连着废片率、成本与人工带宽，周复盘看趋势。

量产跑起来之后，两个问题立刻浮出水面：每条片到底花了多少钱，废片能不能少一点。下一章把质量与成本放到同一张桌上算账。