What an AI Short-Drama Production Pipeline Looks Like: Breaking Down the Stages, a Task-Graph Architecture, and Choosing Among Four Categories of Generation Models

Today's Goals

1. Name the stages an episode of vertical short drama passes through from concept to finished cut, and which of them a model can genuinely handle today
2. Draw the production flow as a directed acyclic graph, and point out which nodes can run in parallel and which must run in sequence
3. Write one unified generation-provider interface layer that lets the same business code switch between an offline placeholder and a real provider

This course assumes you write TypeScript and requires no film knowledge and no other agent course. Fourteen days do one thing: turn one sentence into an episode of vertical short drama fit to publish, then grow that script into a production line that runs in parallel, can be reviewed, and controls its cost. Today writes no script and generates no images and builds the skeleton — come back and tick off the three goals.

Plain-Language Walkthrough

The crew's ledger: which cell on this line the money goes into

Establish an analogy first, and every day of this course returns to it: what you are building is not a script but a film crew.

Before a real crew starts, the producer issues two things: a call sheet (what time, where, which scenes, who is needed) and a process chart (the script locks before storyboards, storyboards lock before sets are dressed, sets are built before cameras roll, and shooting finishes before editing). The former manages resources and the latter order — the same things as a scheduler and a task graph in backend engineering, arrived at a century earlier.

An episode of vertical short drama, translated into our language, is six stages: script → character and scene assets → a first frame per shot → shot video → voiceover → editing and assembly. Those six are this course's first six days and the six nodes in today's lab's graph.

How many people and days each stage takes a traditional crew varies widely between productions and we will not guess. The AI side's ledger can be worked out on the spot. At MiniMax's official pay-as-you-go prices in yuan: images at ¥0.025 each; video by the second at ¥0.50 for 768P, ¥0.80 for 2K, and ¥0.33 for 480P; and speech published only as a resource pack (an HD package at ¥630 for two million characters), converting to a little over three yuan per ten thousand characters — a converted figure, not an official list price.

For one episode of forty shots at six seconds each:

video   40 shots × 6 s × ¥0.50/s          = ¥120.00
images  40 first frames + 10 look tests × ¥0.025 = ¥1.25
speech  about 800 characters at a converted ¥3 per 10k = ¥0.24
text    tens of thousands of tokens for script and review, under one yuan
                                            total about ¥122

One number in that ledger dominates: video is 98%, and it is simultaneously the slowest step (an asynchronous task, queued and polled) and the likeliest to fail (content review, rate limiting, timeouts).

So this course has one judgment running through it, to be remembered now and returned to every day:

The most expensive, slowest, and most failure-prone thing on this line is video generation, so the whole engineering design revolves around calling the video endpoint one fewer time.

Idempotence, caching, reference image reuse, draft and final tiers, the budget circuit breaker — everything in week two that sounds like engineering is a corollary of that sentence. Somebody who only wants to string AI together cannot write them, because they do not know what they are saving.

Drawing the stages as a graph: why it is not a chain of sequential waits

A first version of a pipeline like this is nearly always a chain of awaits: write the script, wait; generate images, wait; generate video, wait; record voice, wait. It runs, and three problems appear together on the first real run.

First, it queues things that could happen at once: voiceover depends only on the lines and not on the visuals, and yet it waits half an hour behind forty videos. Second, it has no checkpoint — the thirty-seventh video times out and thirty-six results sit in memory, gone the moment the process exits. Third, it cannot say which step it is stuck at.

A crew solved that long ago: a process chart is not a straight line but a graph with dependencies. Set dressing and costume tests run at the same time because both depend only on the script; and rolling camera waits for both. That structure is a task graph (a directed acyclic graph), and its three words each govern one thing: directed is who comes before whom, acyclic is no looping back, and graph is more than one path.

Today's graph looks like this:

graph LR
  script[Script and character cards] --> assets[Character reference sheets]
  assets --> frames[First frame per shot]
  frames --> clips[Shot video]
  script --> voice[Line voiceover]
  clips --> timeline[Timeline]
  voice --> timeline

Note the voice branch: it comes straight off script, bypassing the whole visual chain. That is the first thing a graph gives over a queue — parallelism is expressed by the structure directly and needs no manual judgment in code.

Executing that graph needs one algorithm: topological sort, ordering nodes so each comes after all of its dependencies, raising an error on a cycle along the way. Acyclic is not an adjective but a guarantee this code provides:

export type TaskNode = { id: string; deps: string[]; run: () => Promise<string[]> }
 
// Depth-first with three states: unvisited / visiting / done.
// Reaching a "visiting" node again means the dependencies looped back to it, which is a cycle.
export function topoSort(nodes: TaskNode[]): TaskNode[] {
  const byId = new Map(nodes.map((n) => [n.id, n]))
  const state = new Map<string, 'visiting' | 'done'>()
  const order: TaskNode[] = []
 
  const visit = (id: string, trail: string[]) => {
    if (state.get(id) === 'done') return
    if (state.get(id) === 'visiting') throw new Error(`the task graph has a cycle: ${[...trail, id].join(' -> ')}`)
    const node = byId.get(id)
    if (!node) throw new Error(`node ${id} depends on a node that does not exist`) // a silently skipped step is far harder to diagnose than an error
    state.set(id, 'visiting')
    for (const dep of node.deps) visit(dep, [...trail, id])
    state.set(id, 'done')
    order.push(node)
  }
 
  for (const n of nodes) visit(n.id, [])
  return order
}

from dataclasses import dataclass
from typing import Awaitable, Callable
 
 
@dataclass
class TaskNode:
    id: str
    deps: list[str]
    run: Callable[[], Awaitable[list[str]]]
 
 
# Depth-first with three states: unvisited / visiting / done.
# Reaching a "visiting" node again means the dependencies looped back to it, which is a cycle.
def topo_sort(nodes: list[TaskNode]) -> list[TaskNode]:
    by_id = {n.id: n for n in nodes}
    state: dict[str, str] = {}
    order: list[TaskNode] = []
 
    def visit(node_id: str, trail: list[str]) -> None:
        if state.get(node_id) == "done":
            return
        if state.get(node_id) == "visiting":
            raise ValueError("the task graph has a cycle: " + " -> ".join([*trail, node_id]))
        node = by_id.get(node_id)
        if node is None:
            raise ValueError(f"node {node_id} depends on a node that does not exist")
        state[node_id] = "visiting"
        for dep in node.deps:
            visit(dep, [*trail, node_id])
        state[node_id] = "done"
        order.append(node)
 
    for n in nodes:
        visit(n.id, [])
    return order

The engineering cost must be stated too: a task graph is not free. Each node needs a clear definition of which artifacts are its input and which its output, or it is only a pretty dependency declaration. Today does run-the-graph only, leaving idempotence, resumption, and concurrency to days 8 and 9 — all of which rest on today's premise that artifacts are written to fixed locations on disk.

A map of the four generation model categories: which cell of the line each occupies

Short drama production uses four categories of generation model, each matching one stage:

This course's first-priority vendor is MiniMax, for a very practical reason: one vendor covers all four categories, so one key runs the whole line for real without opening four accounts for a course. Authentication is one header: Authorization: Bearer plus your key, along with Content-Type: application/json — that GroupId query parameter in older tutorials is historical and absent from today's OpenAPI, so do not copy it.

Three of the four return in one request, and only video is an asynchronous task. That path takes four steps: submit and receive a task_id, poll GET /v1/query/video_generation with it (the enum is capitalized: Preparing, Queueing, Processing, Success, Fail), obtain a file_id on success, and exchange it via GET /v1/files/retrieve for a download_url before downloading. Break any step and all you hold is a task id. Incidentally, the same vendor also runs another version of the video interface with a different path, different status enum, and different collection method — this course's code uses only the one above, which previews the next section.

Three more potholes are guaranteed if not written down:

• Image links expire after 24 hours, and video download links have no documented expiry and are likewise temporary. So downloading to disk is not optional but part of the flow.
• The speech endpoint's data.audio is a hex string by default, not base64. In Node that is Buffer.from(json.data.audio, "hex"), and decoding it as base64 gives you noise.
• The video endpoint's prompt_optimizer defaults to true: your prompt is rewritten by the vendor before reaching the model. That is an invisible variable for character consistency, covered on day 3.

Other vendors — Alibaba Cloud, Kuaishou, Volcano Engine, Google, Runway — get form comparison only, with no implementation and no specific model version numbers (generation models iterate very fast, and hard-coding a version plants a point that must expire; a batch of older models was measurably retired in September 2026).

What is worth remembering are four shape differences that do not change with versions, all measured:

Note the last column especially: none of these four differences is about capability — all four categories exist everywhere — and all of them are about shape. That fact alone decides the next section's necessity.

A thin provider interface: keeping vendor differences behind a door

The previous section already said half of it: capabilities are alike everywhere and the shapes differ entirely. Business code written against any one vendor gets marinated in that vendor's shape — the number of auth headers, the casing of the status enum, how long links live, how reference images are passed — and once those seep into business logic, switching vendors is not writing one more implementation class but rereading all the business code.

Something that shapes the code, in passing: MiniMax has no official Node SDK for application code, so today's provider layer is written with bare fetch. That is not laziness — having no SDK makes the boundary clearer: the only network exit is those few lines of fetch of your own.

Scatter vendor calls across a dozen business files and you lose three things at once, and those three are the three reasons for this abstraction.

Reason one: it runs offline. With no balance, no network, and inside CI, the pipeline should still run to completion and produce files. That means collapsing the network exit to one place so the offline and real implementations share one interface.

Reason two: switching vendors and running several. Video through MiniMax today and another vendor tomorrow for a particular shot's camera movement. Because the difference is shape rather than capability, as long as business code says one generation action rather than one vendor's four steps, switching is writing one more implementation class — the enum's casing, the extra header, reference image or subject id, all shut inside that class.

Reason three: metering converges. What each call cost must be recorded in one place, and calls scattered across business code never produce a complete ledger. Day 12's whole chapter rests on that convergence.

What should the interface look like? The key is defining it by business action rather than by a vendor's HTTP request. Those four video steps are one action to business code: give me a clip. So the interface has one generate:

export interface VideoProvider {
  readonly name: string
  readonly model: string
  /** Asynchronous: submits, polls, collects, and downloads internally, appearing to the caller as one await */
  generate(input: {
    prompt: string
    outPath: string
    durationSec: number
    firstFrame?: string
    resolution?: string
    onProgress?: (stage: string) => void // a status callback, so the caller can print progress without knowing the protocol
  }): Promise<{ path: string; costCny: number }>
}
 
// The only selection point. Business code imports only this function and never a vendor implementation.
export function createProviders(): Providers {
  return process.env.MOCK === '1' ? createMockProviders() : createMiniMaxProviders()
}

import os
from typing import Callable, Protocol, TypedDict
 
 
class VideoResult(TypedDict):
    path: str
    cost_cny: float
 
 
class VideoProvider(Protocol):
    name: str
    model: str
 
    # Asynchronous: submits, polls, collects, and downloads internally, appearing as one await
    async def generate(
        self,
        prompt: str,
        out_path: str,
        duration_sec: int,
        first_frame: str | None = None,
        resolution: str | None = None,
        on_progress: Callable[[str], None] | None = None,  # print progress without knowing the protocol
    ) -> VideoResult: ...
 
 
# The only selection point. Business code imports only this function and never a vendor implementation.
def create_providers() -> Providers:
    return create_mock_providers() if os.getenv("MOCK") == "1" else create_minimax_providers()

Note outPath: the interface requires the implementation to land the file at a given path rather than returning a URL or a buffer. That design was forced by the previous section's expiring links — writing landing into the contract means no implementation can forget it.

This abstraction's cost must be stated too, or it becomes the platitude that abstraction is always good: you sand off each vendor's unique capabilities. One supports first and last frames together, another supports structured camera parameters, and a common interface cannot hold them. The remedy is not widening the interface but leaving an optional passthrough field used explicitly where needed — explicitly admitting that this one place is bound to one vendor.

It must run offline too: placeholder assets are not a shortcut

"Wire up the real endpoint first and add the mock once it works" is the habit this course most wants you to drop.

The reason concerns debugging rhythm. One complete run of this line calls the video endpoint over forty times, taking tens of minutes and over a hundred yuan for real. Get one index wrong in the timeline and seeing it takes half an hour and a hundred yuan — after three of those you stop wanting to touch that code.

Offline mode compresses that loop to seconds. Today's lab's offline implementation returns no fake JSON and genuinely generates files with ffmpeg: a placeholder image is a solid vertical frame whose color is hashed from the shot description, a placeholder video is a test pattern with an audio track, and a placeholder voiceover is a sine wave whose duration is estimated from the line's character count (0.22 seconds per Chinese character across the course).

// The stub is only at the network exit: no fetch here, and what comes out is a real file.
class MockImageProvider implements ImageProvider {
  async generate(input: { prompt: string; outPath: string; seed?: number }) {
    // The color comes from an input hash — change the sentence and the image changes color, proving the logic ran
    const key = `${input.prompt}|${input.seed ?? ''}`
    await ffmpeg(['-f', 'lavfi', '-i', `color=c=${colorOf(key)}:s=1080x1920`, '-frames:v', '1', input.outPath])
    return { path: input.outPath, costCny: 0 }
  }
}

# The stub is only at the network exit: no httpx here, and what comes out is a real file.
class MockImageProvider:
    async def generate(self, prompt: str, out_path: str, seed: int | None = None) -> ImageResult:
        # The color comes from an input hash — change the sentence and the image changes color
        key = f"{prompt}|{seed if seed is not None else ''}"
        await ffmpeg(["-f", "lavfi", "-i", f"color=c={color_of(key)}:s=1080x1920", "-frames:v", "1", out_path])
        return {"path": out_path, "cost_cny": 0.0}

Judging an offline implementation has one standard: change an input and the output must change. Change a sentence and the placeholder color changes, the placeholder audio's duration changes, the timeline's total changes — showing the business logic in between (state machines, timeline arithmetic, ffmpeg argument assembly) genuinely ran. If the artifacts are identical whatever the input, what you validated is that the program did not crash.

So the stub's position has a hard rule: only at the four providers' network exits, with not one if (process.env.MOCK) in business code — once business logic branches, what you validate offline is a different program.

A glance at the end state: what this line becomes in week two

Finally, two minutes on these fourteen days' shape, which makes today's foundation clearer.

Week one produces one episode: D2 structures the script, D3 the character and scene assets, D4 the shot videos, D5 voiceover and subtitles, D6 editing and assembly, D7 stringing them into a line that runs end to end. Week two turns that script into a production line: D8 a workflow engine, D9 concurrency and quotas, D10 a review console, D11 QC and compliance, D12 cost and model routing, D13 multi-platform distribution, D14 five episodes plus a portfolio.

Look back at the first section's judgment — the most expensive, slowest, most failure-prone thing is video — and every day of week two is its corollary: D8's idempotence exists so a failure does not regenerate video, D9's quota gate exists so hitting a rate limit does not burn allowance, D12's draft tier exists so tuning runs on the cheap tier, and D3's asset reuse exists so one reference sheet serves forty shots.

The course order follows the same reasoning. Writing the provider interface before the script is because once the interface is settled, the other thirteen days fill content into it; make it work, then make it good, then make it many, stable, and cheap — reverse that and you optimize something that does not yet exist.

Source Reading

Hands-On Lab

Confirm ffmpeg is installed before starting (ffmpeg -version produces output) and use MOCK=1 throughout — no key is needed today. starter/ runs to completion as-is with acceptance criteria 3 through 6 unmet, one per numbered exercise; when stuck, compare against solution/'s file of the same name.

1. Run the solution's MOCK=1 pnpm start once, read the terminal output alongside the artifact directory, and get a mental picture of what done looks like.
2. Back in the starter, open src/index.ts and see how the six nodes' deps connect, drawing the graph on paper and marking each node's input and output artifacts.
3. Do exercises 1 and 2: complete the offline image and video ffmpeg arguments, then use ffprobe to confirm a clip is 1080x1920, 6 seconds, with an audio track, and that the three first frames differ in color.
4. Do exercise 3: implement topological sort and cycle detection, and the "topoSort is not implemented" warning should disappear; then deliberately create a cycle and confirm it errors and exits.
5. Do exercise 4: compute the timeline's start and end milliseconds, open the timeline JSON and confirm the three shots are end to end; finally swap in a sentence of your own and rerun, confirming the placeholder assets genuinely changed with it.

Interview Questions

Today's 3 questions are in the question bank below, weighted toward the pipeline's layering and decoupling, the provider abstraction's boundary, and why running offline is an engineering requirement rather than a toy. Expand each one and read the analysis before the key points — practicing the derivation beats memorizing bullets. The high-frequency labels for the domestic and overseas markets are there so you can pick by target market.

Checklist and Tomorrow

• Name the stages an episode of vertical short drama passes through from concept to finished cut, and which of them a model can genuinely handle today
• Draw the production flow as a directed acyclic graph, and point out which nodes can run in parallel and which must run in sequence
• Write one unified generation-provider interface layer that lets the same business code switch between an offline placeholder and a real provider
• Say without notes which cell of this line the money mainly goes into, and which engineering designs that fact implies
• Say which four extra steps the video interface has over the other three, and why landing files belongs in the interface contract
• All 6 acceptance criteria of the lab pass
• Answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D2) we enter the writers' room: having the model turn one sentence into structured data of character cards, scenes, and shots rather than a stretch of prose. Why that order? Because on today's graph, all five nodes other than the script take their input from fields of the shot data — visual into the image prompt, camera into the video prompt, dialogue into the voiceover, durationSec into the timeline. Without a structured script, the next five steps have nothing to eat. D2 also adds a reviewer role to the script agent so drafts improve in a loop, and distils cross-episode settings into a world bible — a document used right through to day 14's five-episode season.