簡介大模型與AI視頻生成技術的成熟讓內容生產的自動化程度不斷提升。在實際工程中將劇本創作、分鏡設計、畫面生成、配音字幕等環節串聯為一條完整的自動化流水線是提高內容產出效率的關鍵。本地部署配合私有化數據處理能夠有效保障創意資產安全避免敏感內容外泄。seedance2作為新一代視頻生成引擎在中文指令理解與鏡頭連貫性上表現突出為短劇和漫劇的穩定生成提供了有力支撐。本文從技術選型、組件協同、任務調度到常見問題系統介紹一套可落地運行的本地AI短劇工作流方案幫助開發者在保證數據私密性的前提下高效完成從故事到成片的完整生產閉環。 做AI短劇這件事圈子里最近討論最多的已經不是“能不能生成”而是“怎么把生成過程組織起來”。我花了一周時間把一套開源本地AI短劇和漫劇生成工具跑通了并且成功接入了seedance2作為視頻生成引擎。整條鏈路從故事文本開始到分鏡、畫面、配音、字幕、成片剪輯所有過程都在本機完成數據不出本機短劇工作流管理也統一在一個項目里。這篇文章就把我自己的接入過程、選型邏輯和踩坑記錄完整寫出來給同樣在折騰本地AI短劇的兄弟一個參考。先交代一下我為什么一定要折騰本地化。做短劇內容的人應該都有體會劇本和分鏡腳本是最大的資產但市面上的AI視頻工具基本都是網頁版素材傳上去之后自己心里沒底。尤其是有商業項目、有版權風險的內容放在別人服務器上始終是個問題。所以當看到有開源方案能實現“從故事到成片一站式完成、數據不出本機”的時候我幾乎是第一時間就開始搭。這套東西本質上不是單一軟件而是一個以本地大模型為核心的工作流系統seedance2的接入讓視頻生成這塊補上了最后一塊短板。1. 先把本地短劇工作流拆開它到底解決了什么問題很多朋友一聽到“AI短劇生成工具”第一反應是“這不就是輸入一句話然后吐出一個視頻嗎”。實際做過的都知道這句話被嚴重低估了。真正能用的短劇工作流面對的不是一條提示詞而是一整個制作流程。1.1 從故事到成片中間藏著多少環節我習慣把鏈路分成六個階段劇本、分鏡、角色與場景設定、單鏡畫面生成、視頻片段生成、后期合成。任何一個環節斷開后面都沒法做。劇本階段需要大模型根據故事梗概擴寫完整劇本還要輸出對白分鏡階段要把劇本切成一個個鏡頭每個鏡頭包含景別、運鏡、畫面描述、對白、時長角色和場景設定階段要保證同一個角色在多個鏡頭里長得一樣同一個場景在不同時間光照下保持一致單鏡畫面生成就是把分鏡里的畫面描述變成一張或一組參考圖視頻片段生成則是把參考圖加上運動描述變成幾秒鐘的視頻最后一步后期把視頻片段按順序拼起來加上字幕、配音和背景音樂。這套流程如果全部手動操作一個3分鐘短劇可能要折騰兩三天。而且每個環節之間要傳遞素材版本一多特別容易亂。我見過有人把AI視頻生成做成了文件夾災難最終版_v3_真的最終版.mp4這種命名到處都是。工作流管理要解決的正是這個問題。1.2 數據不出本機不只是隱私潔癖我強調“數據不出本機”很多人以為是純隱私潔癖其實不是。對于做商業短劇的人來說劇本和創意是不能外泄的核心資產。一本短劇劇本如果提前泄露整個項目基本就廢了。本地部署的意義在于只有視頻生成那一步會把文字提示詞發送到模型服務如果連模型都是本地部署的開源視頻模型那整條鏈路可以完全不依賴外網。即使接入了seedance2這種云端模型也只是發送經過脫敏處理的提示詞和畫面描述劇本原文、項目結構、角色設定、素材資源全都留在本機。這個邊界先搞清楚后面選型才不糾結。2. seedance2在這個工具里的定位不是替換一切而是補上最后一公里視頻模型是這套工作流里最有技術含量、也最燒錢的環節。我在接入之前對比過好幾家視頻生成方案最終把seedance2作為主引擎原因不只是生成效果更是因為它適合做短劇這種“強劇情、多鏡頭連續”的內容。2.1 seedance2和seedance2.5到底強在哪seedance2這一代最大的變化是它對中文指令的理解比以前好了很多尤其適合描述中國短劇里的場景、動作和情緒。比如你寫“女主角推開門看到窗邊有人在彈吉他她愣了一下”它生成出來的鏡頭邏輯基本是對的不會出現角色穿模或者動作完全對不上的情況。seedance2.5是后續的版本迭代在動作連貫性和多鏡頭一致性上做了增強。很多剛開始接觸的人問“這倆到底一起是干啥用的”我的理解是2負責單鏡頭內的畫面生成2.5負責跨鏡頭的角色一致性和長鏡頭拼接。實際接入時兩個版本共用一個接口規范這給工作流整合帶來了很大的便利。2.2 接入方式不要直接拼API加一個本地網關統一調度很多初學接入的人喜歡在業務代碼里直接拼官方API今天用seedance2就寫個seedance2的調用明天換方案就再改一版。這種做法在單次測試里沒問題放到完整工作流里就會很痛苦因為視頻生成只是整條鏈路的一環上游的提示詞格式、下游的素材歸檔都要跟隨變化。我的做法是加了一個本地視頻引擎網關所有請求先到這個網關由網關決定分發給哪個provider。seedance2只是其中一個provider。這樣以后想換其他視頻模型只需要在網關里加一個適配器業務層完全不用動。本地網關本質上就是一個轉譯層把工作流發來的統一視頻生成請求翻譯成seedance2接口能識別的參數格式。我給這個網關起名叫video_bridge用FastAPI寫的幾行代碼就能跑起來。2.3 一個最小可用的接入配置下面是我在項目里實際使用的seedance2接入配置我把它放在一個YAML文件里統一管理。video_engine: provider: seedance version: 2 endpoint: http://127.0.0.1:8321/v1 model_name: seedance-2 fallback_provider: local_ltxv timeout_seconds: 300 default_params: resolution: 1080p duration_seconds: 5 fps: 30 cfg_scale: 6.5 motion_strength: 4 negative_prompt: 低質量, 模糊, 變形, 多余肢體, 水印, 文字重點看幾個參數endpoint填的是本地網關地址不是直接對接seedance2官方如果網關轉發失敗或者超時自動fallback到本地的開源視頻模型保證工作流不會因為單點故障中斷motion_strength控制運動強度短劇對白場景我一般調到2到4動作戲才調到7以上。有一個容易踩的坑negative_prompt里如果寫“文字、字幕、水印”部分視頻模型會理解為“畫面里不能出現任何字符”導致生成的畫面里連路牌、招牌上的字都會消失。所以我把negative_prompt的范圍收窄只保留“水印、多余肢體、變形、模糊”這類畫面質量問題文字相關的留給后期字幕層處理。3. 搭建環境Ollama、Dify、ComfyUI這些組件各管什么整套工作流不是只有一個軟件而是多個本地組件各司其職。我參考開源項目my_ai_town的做法把組件之間的邊界劃得很清楚每個組件只做一件事組件之間通過標準JSON格式通信。3.1 各組件分工表我先用一張表說明每個組件在這個工作流里的職責方便后面分頭搭建。組件職責為什么用它Ollama本地運行大語言模型負責劇本擴寫、分鏡拆分、提示詞生成一條命令啟動模型管理方便Dify編排多步AI流程管理對話、知識庫和工具調用可視化配置適合把劇本到分鏡的流程固化ComfyUI生成角色設定圖和場景參考圖節點式工作流可復現性最強video_bridge統一視頻生成網關對接seedance2等引擎隔離上游提示詞格式和下游參數差異SQLite 文件目錄存儲項目元數據和素材文件零依賴數據全部在本地這里說一句選型邏輯Ollama和Dify不是非用不可但這兩個工具在國內社區里的資料最多出了問題容易搜到答案。ComfyUI雖然上手比WebUI難一些但它的節點式工作流可以導出成json文件同一個角色設定圖可以復用到多個鏡頭里這個特性在做短劇時非常關鍵。3.2 本地大模型與seedance2如何配合短劇工作流里Ollama跑的本地大模型負責“想”seedance2負責“拍”。本地模型不直接生成視頻而是生成視頻所需的提示詞和分鏡腳本。舉個例子我讓本地模型把一段小說原文擴寫成一集短劇劇本它會輸出場景、對白、人物動作和心理活動。然后我再讓本地模型把劇本拆成鏡頭列表每個鏡頭輸出一個結構化JSON。這個JSON經過Dify里的文本處理節點變成seedance2能接受的提示詞。整個過程視頻模型感知到的只是“第幾秒做什么動作、鏡頭怎么運動”根本接觸不到原始劇本。這種分工的好處是即使你換一個視頻引擎上游的劇本和分鏡完全不用重新做。我后來測試seedance2.5的時候只是改了一下video_bridge里provider的版本號整條鏈路就通了。3.3 角色一致性不能只靠提示詞短劇里最怕的一件事是同一個角色在這一集里長一個樣下一集換個演員。靠文字提示詞解決角色一致性問題基本不現實seedance2再強也沒法靠一段描述精確還原人臉。我的方案是分兩步先在ComfyUI里用固定種子和IP-Adapter參考圖生成角色的標準設定圖然后把這張設定圖作為seedance2生成視頻時的首幀參考。這樣角色的五官、服裝、發型就有了穩定的錨點。實際操作時我給每個角色建一個目錄里面放三樣東西標準正面照、半身照、全身照。工作流在生成每個鏡頭前會自動根據鏡頭景別選擇對應參考圖。特寫鏡頭用正面照中景用半身照遠景用全身照。這個細節讓我生成的短劇素材角色一致性比純提示詞高了一個量級。4. seedance2接入實戰從分鏡腳本到成片的完整流程現在進入最核心的部分分鏡腳本是怎么一步步變成成片的。我會把關鍵的代碼結構和調用過程完整寫出來你照著搭就能跑通一個最小版本。4.1 分鏡腳本的JSON格式約定為了讓本地大模型輸出的分鏡能被工作流穩定解析我定義了一套固定格式。每個鏡頭包含以下字段{ shot_id: S01_03, scene: 辦公室夜景, characters: [林晚, 陳默], camera: 中景, 緩慢推近, action: 林晚推開門走進辦公室看到陳默站在窗前, dialogue: 陳默你怎么來了, duration_seconds: 5, reference_image: characters/林晚/half_body.png }這套格式有兩個關鍵設計。第一shot_id包含集數和鏡頭序號比如S01_03表示第一集第三個鏡頭整個工作流靠這個ID做素材歸檔和排序第二reference_image字段直接從項目根目錄取相對路徑視頻網關拿到這個路徑后會主動把圖片讀取出來并編碼成base64傳給seedance2避免在提示詞里寫一堆根本描述不清的視覺細節。4.2 視頻生成網關的核心調用邏輯video_bridge的核心邏輯不復雜我把簡化版寫出來方便你理解整個調用流程。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class VideoRequest(BaseModel): prompt: str reference_image: str | None None duration: int 5 resolution: str 1080p motion_strength: int 4 class VideoResponse(BaseModel): task_id: str status: str video_path: str | None None app.post(/v1/generate, response_modelVideoResponse) async def generate(req: VideoRequest): # 1. 讀取參考圖并編碼 ref_b64 None if req.reference_image: with open(req.reference_image, rb) as f: import base64 ref_b64 base64.b64encode(f.read()).decode(utf-8) # 2. 構造seedance2接口的請求體 payload { model: seedance-2, prompt: req.prompt, image_root: ref_b64, # 作為首幀參考 duration: req.duration, resolution: req.resolution, motion_strength: req.motion_strength } # 3. 通過HTTP調用seedance2服務本地或云端 try: result await call_seedance(payload) return VideoResponse( task_idresult[task_id], statussucceeded, video_pathresult[video_path] ) except Exception as e: # 4. 失敗時自動切換備用模型 fallback_result await call_local_model(payload) return VideoResponse( task_idfallback_result[task_id], statussucceeded, video_pathfallback_result[video_path] )這里最值得注意的地方是失敗回退fallback邏輯。視頻生成經常會出現服務端超時、任務排隊太久、模型生成失敗等問題如果工作流不處理異常整個批量任務就會卡死。我加了一個規則seedance2請求超過300秒沒返回就切換到本地的備用視頻模型。雖然本地模型的畫面質量略遜一籌但至少工作流不會中斷后面審核素材時再單獨重生成質量不夠的鏡頭就行。4.3 批量生成把鏡頭列表自動變成視頻分鏡腳本一般有幾十個鏡頭不太可能一個個手動調用接口。我寫了一個批量調度腳本流程如下讀取分鏡JSON文件按shot_id排序對每個鏡頭自動拼接提示詞景別 場景 角色動作 對白情緒檢查對應鏡頭是否已生成視頻已生成則跳過斷點續跑創建視頻生成任務寫入SQLite任務表輪詢任務狀態更新進度。提示詞的拼接邏輯是這樣的def build_prompt(shot): camera shot[camera] scene shot[scene] action shot[action] dialogue shot.get(dialogue, ) prompt f{camera}{scene}。{action}。 if dialogue: prompt f人物說出對白{dialogue} return prompt實際拼出來的效果類似“中景, 緩慢推近辦公室夜景。林晚推開門走進辦公室看到陳默站在窗前。人物說出對白你怎么來了”注意我在提示詞里沒有寫任何“高質量、8k、電影感”之類的形容詞。原因很直接seedance2這類模型對畫面質量本身就內置了優化再反復疊加這些詞反而會引入過飽和、銳化過度的問題生成的畫面看起來很不自然。你要相信模型的基礎能力把提示詞的空間留給劇情和動作描述。4.4 素材歸檔規范視頻生成完成后所有素材統一歸檔到項目目錄下結構如下project_name/ ├── scripts/ │ ├── 01_story.md # 原始故事 │ ├── 02_script.json # 劇本 │ └── 03_storyboard.json # 分鏡 ├── characters/ │ ├── 林晚_front.png │ ├── 林晚_half.png │ ├── 林晚_full.png │ └── 陳默_front.png ├── scenes/ │ ├── 辦公室夜景.png │ └── 天臺日景.png ├── shots/ │ ├── S01_01/ │ │ ├── prompt.txt │ │ ├── ref.png │ │ └── output.mp4 │ └── S01_02/ │ ├── prompt.txt │ ├── ref.png │ └── output.mp4 ├── subtitles/ │ ├── S01.srt │ └── S02.srt └── project.db這個目錄結構不是隨便定的。每生成一個鏡頭我不僅保存視頻文件還把提示詞和參考圖放進同一個目錄。這樣回頭想查“這個鏡頭當時是怎么生成的”所有信息都在一個文件夾里不需要再去翻數據庫。對短劇這種高頻修改、長期迭代的項目來說這個習慣能省下大量時間。5. 短劇工作流管理任務調度和版本控制的思路有了素材以后真正的短劇生產還差最后一步把素材按照劇情順序組織成一個完整作品并且方便做多集管理。這也是標題里“短劇工作流管理”這個關鍵詞的分量所在。5.1 SQLite任務表讓每個生成鏡頭可追蹤批量生成下來會有幾十個視頻片段哪個生成失敗哪個還在排隊哪個已經完成全都要有記錄。我在SQLite里建了一張任務表CREATE TABLE video_tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, shot_id TEXT NOT NULL, status TEXT DEFAULT pending, -- pending/running/succeeded/failed retry_count INTEGER DEFAULT 0, provider TEXT DEFAULT seedance2, video_path TEXT, error_message TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP );shot_id是主索引每個鏡頭在一個項目里只會有一個任務。如果失敗了重試時不是新建一條記錄而是更新原記錄的狀態和重試次數這樣整個生成歷史是完整連續的。我還給任務表加了一個provider字段記錄這個鏡頭最終是由seedance2生成的還是由本地備用模型生成的。這個字段看著不起眼實際上很重要后期審片時如果發現某個鏡頭畫風不統一一查就知道這個鏡頭是備用模型生成的直接重生成就行。5.2 多集串聯自動拼接和字幕單集短劇通常有多個鏡頭多集短劇則是一套素材管理邏輯。工作流里我按S01_01到S01_N的順序讀取所有已完成的視頻片段用FFmpeg按順序拼接成完整一集。這里的重點是自動從分鏡JSON里提取每個鏡頭的時間表借助拼接時間軸數據生成一個完整的字幕文件。實現上很簡單先計算每個鏡頭在總時間軸上的起點再把分鏡里的對白和起點時間對應起來寫進SRT字幕文件。我用了一個腳本完成拼接和字幕生成ffmpeg -f concat -safe 0 -i concat_list.txt -c copy S01_final.mp4concat_list.txt里是已完成鏡頭的視頻文件路徑按shot_id排序后寫入。這個方法比在剪輯軟件里手動拖素材快得多。拼接后我還會用FFmpeg做一次一鍵加字幕ffmpeg -i S01_final.mp4 -vf subtitlesS01.srt S01_captioned.mp4這套流程一旦跑通新的一集只需要把分鏡JSON更新好就能在十幾分鐘內出片。做AI漫劇和AI短劇的效率差距就是在這里拉開的。5.3 進度可視化一個簡單的生成狀態面板管理幾十個鏡頭的生成任務光靠命令行看日志實在太痛苦。我寫了一個簡單的HTML狀態頁面通過讀取SQLite任務表把每個鏡頭的狀態用色塊顯示出來綠色是完成黃色是生成中紅色是失敗。整個頁面不依賴任何前端框架就是一個自動刷新的HTML文件。這個狀態面板最大的價值是讓我能在批量生成過程中一眼看出哪個鏡頭出了問題及時干預。有一次批量生成到第17個鏡頭時連續失敗了三次我看面板發現失敗原因都是“參考圖路徑不存在”——角色目錄被更名了導致參考圖讀取失敗。如果沒有這個面板整個任務可能要在失敗后白跑很久才能發現。6. 踩坑記錄本地化生成短劇最容易翻車的地方最后一部分我把實測中踩得最深、最典型的幾個坑寫出來。這些都是文檔里不會寫、但實際轉換中一定會遇到的問題。6.1 顯存和內存的分配是“看不見的瓶頸”本地工作流最大的限制是硬件資源。一臺機器要同時跑Ollama劇本生成、ComfyUI參考圖生成、video_bridge視頻生成網關顯存和內存非常緊張。我的經驗是把不同組件放到不同的機器上運行。比如Ollama跑在Mac Studio上ComfyUI和視頻生成跑在Windows雙卡工作站上通過主機名互相訪問。這樣不僅資源不沖突而且在批量生成時還能并行工作。如果你的機器只有一張顯卡建議把Ollama換成一個輕量模型比如4B、7B量級的模型專門負責提示詞生成。不要試圖在同一個顯卡上同時跑13B模型和視頻生成那樣兩者都會慢到懷疑人生而且一旦顯存溢出整個工作流都會崩。6.2 單鏡頭時長和分辨率的限制seedance2這類視頻模型對單次生成的時長有上限通常一次生成5到10秒。我的經驗是短劇鏡頭盡量控制在4到5秒超過這個時長畫面后半段的動作連貫性會明顯下降人物容易出現輕微的抖動和形變。處理長鏡頭時不要指望一次生成十幾秒的視頻更合理的做法是拆成多個短鏡頭在后期拼接時用轉場銜接。比如“角色從進門到坐下”這個動作拆成“推門進入3秒”和“走到桌邊坐下4秒”兩個鏡頭利用剪輯節奏感來掩蓋拼接痕跡。分辨率方面優先選1080p而不是2K、4K。視頻生成模型的推理耗時和顯存占用會隨分辨率顯著增長而短劇最終的傳播場景大多是手機豎屏觀看1080p已經足夠。生成后如果需要更高分辨率用后期放大工具處理就行沒必要在生成階段死磕。6.3 風格漂移同一個場景換個鏡頭就“變味”做漫劇和短劇時經常會遇到這個問題第一個鏡頭的場景很有氛圍感第二個鏡頭再生成時雖然提示詞寫得一樣但光影、色調、構圖全變了。這其實就是風格漂移。我的補救方案有兩步。第一步在ComfyUI里先確定每個場景的標準參考圖所有涉及該場景的鏡頭都使用同一張參考圖作為首幀第二步在視頻生成參數里把運動強度調低motion_strength控制在2到4之間因為視頻模型在運動幅度大的情況下為了保持運動連貫性往往會重繪靜態背景導致風格偏離。方案不復雜但能解決八成的風格漂移問題。剩下兩成老實說只能靠多生成幾個角度、從中挑一個最接近的來用。6.4 中文文件名和路徑編碼問題本地工作流里大量使用中文角色名和場景名這在Windows的NTFS文件系統下沒太大問題但在Linux環境或者跨平臺共享目錄時經常會出現編碼或路徑讀取失敗的問題。我的視頻生成網關曾經碰到過一個很隱蔽的bug提示詞里的中文沒問題但參考圖路徑里的中文讀不出來導致生成任務白白浪費了幾次重試。最終我的處理方式是所有項目目錄一律使用英文或數字命名角色ID使用拼音或縮寫比如linwan_front.png代替林晚_front.png。角色的中文名只存在于分鏡JSON的characters字段里用于描述和提示詞拼接涉及實際文件讀寫路徑時全部用ASCII字符。最后分享一點我自己折騰這套工作流的體會如果你也開始搭本地AI短劇工具我建議不要一上來就想生成一整個完整劇集。先拿一個3分鐘的單集做測試確認分鏡、參考圖、視頻生成、拼接、字幕這條主線能跑通再加配角和復雜場景。我實測下來第一次跑通的時間大概需要一天但跑通之后從故事到成片的整個流程會變得非常可控。seedance2的接入只是一個開始。真正常態化使用之后你會慢慢把精力從“怎么生成”轉移到“生成什么內容”上這就是工作流沉淀下來的價值。如果你也在這條路上遇到具體問題歡迎在評論區交流。本文還有配套的精品資源點擊獲取 本地AI短劇工作流實戰：seedance2接入與全流程踩坑記錄
簡介大模型與AI視頻生成技術的成熟讓內容生產的自動化程度不斷提升。在實際工程中將劇本創作、分鏡設計、畫面生成、配音字幕等環節串聯為一條完整的自動化流水線是提高內容產出效率的關鍵。本地部署配合私有化數據處理能夠有效保障創意資產安全避免敏感內容外泄。seedance2作為新一代視頻生成引擎在中文指令理解與鏡頭連貫性上表現突出為短劇和漫劇的穩定生成提供了有力支撐。本文從技術選型、組件協同、任務調度到常見問題系統介紹一套可落地運行的本地AI短劇工作流方案幫助開發者在保證數據私密性的前提下高效完成從故事到成片的完整生產閉環。 做AI短劇這件事圈子里最近討論最多的已經不是“能不能生成”而是“怎么把生成過程組織起來”。我花了一周時間把一套開源本地AI短劇和漫劇生成工具跑通了并且成功接入了seedance2作為視頻生成引擎。整條鏈路從故事文本開始到分鏡、畫面、配音、字幕、成片剪輯所有過程都在本機完成數據不出本機短劇工作流管理也統一在一個項目里。這篇文章就把我自己的接入過程、選型邏輯和踩坑記錄完整寫出來給同樣在折騰本地AI短劇的兄弟一個參考。先交代一下我為什么一定要折騰本地化。做短劇內容的人應該都有體會劇本和分鏡腳本是最大的資產但市面上的AI視頻工具基本都是網頁版素材傳上去之后自己心里沒底。尤其是有商業項目、有版權風險的內容放在別人服務器上始終是個問題。所以當看到有開源方案能實現“從故事到成片一站式完成、數據不出本機”的時候我幾乎是第一時間就開始搭。這套東西本質上不是單一軟件而是一個以本地大模型為核心的工作流系統seedance2的接入讓視頻生成這塊補上了最后一塊短板。1. 先把本地短劇工作流拆開它到底解決了什么問題很多朋友一聽到“AI短劇生成工具”第一反應是“這不就是輸入一句話然后吐出一個視頻嗎”。實際做過的都知道這句話被嚴重低估了。真正能用的短劇工作流面對的不是一條提示詞而是一整個制作流程。1.1 從故事到成片中間藏著多少環節我習慣把鏈路分成六個階段劇本、分鏡、角色與場景設定、單鏡畫面生成、視頻片段生成、后期合成。任何一個環節斷開后面都沒法做。劇本階段需要大模型根據故事梗概擴寫完整劇本還要輸出對白分鏡階段要把劇本切成一個個鏡頭每個鏡頭包含景別、運鏡、畫面描述、對白、時長角色和場景設定階段要保證同一個角色在多個鏡頭里長得一樣同一個場景在不同時間光照下保持一致單鏡畫面生成就是把分鏡里的畫面描述變成一張或一組參考圖視頻片段生成則是把參考圖加上運動描述變成幾秒鐘的視頻最后一步后期把視頻片段按順序拼起來加上字幕、配音和背景音樂。這套流程如果全部手動操作一個3分鐘短劇可能要折騰兩三天。而且每個環節之間要傳遞素材版本一多特別容易亂。我見過有人把AI視頻生成做成了文件夾災難最終版_v3_真的最終版.mp4這種命名到處都是。工作流管理要解決的正是這個問題。1.2 數據不出本機不只是隱私潔癖我強調“數據不出本機”很多人以為是純隱私潔癖其實不是。對于做商業短劇的人來說劇本和創意是不能外泄的核心資產。一本短劇劇本如果提前泄露整個項目基本就廢了。本地部署的意義在于只有視頻生成那一步會把文字提示詞發送到模型服務如果連模型都是本地部署的開源視頻模型那整條鏈路可以完全不依賴外網。即使接入了seedance2這種云端模型也只是發送經過脫敏處理的提示詞和畫面描述劇本原文、項目結構、角色設定、素材資源全都留在本機。這個邊界先搞清楚后面選型才不糾結。2. seedance2在這個工具里的定位不是替換一切而是補上最后一公里視頻模型是這套工作流里最有技術含量、也最燒錢的環節。我在接入之前對比過好幾家視頻生成方案最終把seedance2作為主引擎原因不只是生成效果更是因為它適合做短劇這種“強劇情、多鏡頭連續”的內容。2.1 seedance2和seedance2.5到底強在哪seedance2這一代最大的變化是它對中文指令的理解比以前好了很多尤其適合描述中國短劇里的場景、動作和情緒。比如你寫“女主角推開門看到窗邊有人在彈吉他她愣了一下”它生成出來的鏡頭邏輯基本是對的不會出現角色穿模或者動作完全對不上的情況。seedance2.5是后續的版本迭代在動作連貫性和多鏡頭一致性上做了增強。很多剛開始接觸的人問“這倆到底一起是干啥用的”我的理解是2負責單鏡頭內的畫面生成2.5負責跨鏡頭的角色一致性和長鏡頭拼接。實際接入時兩個版本共用一個接口規范這給工作流整合帶來了很大的便利。2.2 接入方式不要直接拼API加一個本地網關統一調度很多初學接入的人喜歡在業務代碼里直接拼官方API今天用seedance2就寫個seedance2的調用明天換方案就再改一版。這種做法在單次測試里沒問題放到完整工作流里就會很痛苦因為視頻生成只是整條鏈路的一環上游的提示詞格式、下游的素材歸檔都要跟隨變化。我的做法是加了一個本地視頻引擎網關所有請求先到這個網關由網關決定分發給哪個provider。seedance2只是其中一個provider。這樣以后想換其他視頻模型只需要在網關里加一個適配器業務層完全不用動。本地網關本質上就是一個轉譯層把工作流發來的統一視頻生成請求翻譯成seedance2接口能識別的參數格式。我給這個網關起名叫video_bridge用FastAPI寫的幾行代碼就能跑起來。2.3 一個最小可用的接入配置下面是我在項目里實際使用的seedance2接入配置我把它放在一個YAML文件里統一管理。video_engine: provider: seedance version: 2 endpoint: http://127.0.0.1:8321/v1 model_name: seedance-2 fallback_provider: local_ltxv timeout_seconds: 300 default_params: resolution: 1080p duration_seconds: 5 fps: 30 cfg_scale: 6.5 motion_strength: 4 negative_prompt: 低質量, 模糊, 變形, 多余肢體, 水印, 文字重點看幾個參數endpoint填的是本地網關地址不是直接對接seedance2官方如果網關轉發失敗或者超時自動fallback到本地的開源視頻模型保證工作流不會因為單點故障中斷motion_strength控制運動強度短劇對白場景我一般調到2到4動作戲才調到7以上。有一個容易踩的坑negative_prompt里如果寫“文字、字幕、水印”部分視頻模型會理解為“畫面里不能出現任何字符”導致生成的畫面里連路牌、招牌上的字都會消失。所以我把negative_prompt的范圍收窄只保留“水印、多余肢體、變形、模糊”這類畫面質量問題文字相關的留給后期字幕層處理。3. 搭建環境Ollama、Dify、ComfyUI這些組件各管什么整套工作流不是只有一個軟件而是多個本地組件各司其職。我參考開源項目my_ai_town的做法把組件之間的邊界劃得很清楚每個組件只做一件事組件之間通過標準JSON格式通信。3.1 各組件分工表我先用一張表說明每個組件在這個工作流里的職責方便后面分頭搭建。組件職責為什么用它Ollama本地運行大語言模型負責劇本擴寫、分鏡拆分、提示詞生成一條命令啟動模型管理方便Dify編排多步AI流程管理對話、知識庫和工具調用可視化配置適合把劇本到分鏡的流程固化ComfyUI生成角色設定圖和場景參考圖節點式工作流可復現性最強video_bridge統一視頻生成網關對接seedance2等引擎隔離上游提示詞格式和下游參數差異SQLite 文件目錄存儲項目元數據和素材文件零依賴數據全部在本地這里說一句選型邏輯Ollama和Dify不是非用不可但這兩個工具在國內社區里的資料最多出了問題容易搜到答案。ComfyUI雖然上手比WebUI難一些但它的節點式工作流可以導出成json文件同一個角色設定圖可以復用到多個鏡頭里這個特性在做短劇時非常關鍵。3.2 本地大模型與seedance2如何配合短劇工作流里Ollama跑的本地大模型負責“想”seedance2負責“拍”。本地模型不直接生成視頻而是生成視頻所需的提示詞和分鏡腳本。舉個例子我讓本地模型把一段小說原文擴寫成一集短劇劇本它會輸出場景、對白、人物動作和心理活動。然后我再讓本地模型把劇本拆成鏡頭列表每個鏡頭輸出一個結構化JSON。這個JSON經過Dify里的文本處理節點變成seedance2能接受的提示詞。整個過程視頻模型感知到的只是“第幾秒做什么動作、鏡頭怎么運動”根本接觸不到原始劇本。這種分工的好處是即使你換一個視頻引擎上游的劇本和分鏡完全不用重新做。我后來測試seedance2.5的時候只是改了一下video_bridge里provider的版本號整條鏈路就通了。3.3 角色一致性不能只靠提示詞短劇里最怕的一件事是同一個角色在這一集里長一個樣下一集換個演員。靠文字提示詞解決角色一致性問題基本不現實seedance2再強也沒法靠一段描述精確還原人臉。我的方案是分兩步先在ComfyUI里用固定種子和IP-Adapter參考圖生成角色的標準設定圖然后把這張設定圖作為seedance2生成視頻時的首幀參考。這樣角色的五官、服裝、發型就有了穩定的錨點。實際操作時我給每個角色建一個目錄里面放三樣東西標準正面照、半身照、全身照。工作流在生成每個鏡頭前會自動根據鏡頭景別選擇對應參考圖。特寫鏡頭用正面照中景用半身照遠景用全身照。這個細節讓我生成的短劇素材角色一致性比純提示詞高了一個量級。4. seedance2接入實戰從分鏡腳本到成片的完整流程現在進入最核心的部分分鏡腳本是怎么一步步變成成片的。我會把關鍵的代碼結構和調用過程完整寫出來你照著搭就能跑通一個最小版本。4.1 分鏡腳本的JSON格式約定為了讓本地大模型輸出的分鏡能被工作流穩定解析我定義了一套固定格式。每個鏡頭包含以下字段{ shot_id: S01_03, scene: 辦公室夜景, characters: [林晚, 陳默], camera: 中景, 緩慢推近, action: 林晚推開門走進辦公室看到陳默站在窗前, dialogue: 陳默你怎么來了, duration_seconds: 5, reference_image: characters/林晚/half_body.png }這套格式有兩個關鍵設計。第一shot_id包含集數和鏡頭序號比如S01_03表示第一集第三個鏡頭整個工作流靠這個ID做素材歸檔和排序第二reference_image字段直接從項目根目錄取相對路徑視頻網關拿到這個路徑后會主動把圖片讀取出來并編碼成base64傳給seedance2避免在提示詞里寫一堆根本描述不清的視覺細節。4.2 視頻生成網關的核心調用邏輯video_bridge的核心邏輯不復雜我把簡化版寫出來方便你理解整個調用流程。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class VideoRequest(BaseModel): prompt: str reference_image: str | None None duration: int 5 resolution: str 1080p motion_strength: int 4 class VideoResponse(BaseModel): task_id: str status: str video_path: str | None None app.post(/v1/generate, response_modelVideoResponse) async def generate(req: VideoRequest): # 1. 讀取參考圖并編碼 ref_b64 None if req.reference_image: with open(req.reference_image, rb) as f: import base64 ref_b64 base64.b64encode(f.read()).decode(utf-8) # 2. 構造seedance2接口的請求體 payload { model: seedance-2, prompt: req.prompt, image_root: ref_b64, # 作為首幀參考 duration: req.duration, resolution: req.resolution, motion_strength: req.motion_strength } # 3. 通過HTTP調用seedance2服務本地或云端 try: result await call_seedance(payload) return VideoResponse( task_idresult[task_id], statussucceeded, video_pathresult[video_path] ) except Exception as e: # 4. 失敗時自動切換備用模型 fallback_result await call_local_model(payload) return VideoResponse( task_idfallback_result[task_id], statussucceeded, video_pathfallback_result[video_path] )這里最值得注意的地方是失敗回退fallback邏輯。視頻生成經常會出現服務端超時、任務排隊太久、模型生成失敗等問題如果工作流不處理異常整個批量任務就會卡死。我加了一個規則seedance2請求超過300秒沒返回就切換到本地的備用視頻模型。雖然本地模型的畫面質量略遜一籌但至少工作流不會中斷后面審核素材時再單獨重生成質量不夠的鏡頭就行。4.3 批量生成把鏡頭列表自動變成視頻分鏡腳本一般有幾十個鏡頭不太可能一個個手動調用接口。我寫了一個批量調度腳本流程如下讀取分鏡JSON文件按shot_id排序對每個鏡頭自動拼接提示詞景別 場景 角色動作 對白情緒檢查對應鏡頭是否已生成視頻已生成則跳過斷點續跑創建視頻生成任務寫入SQLite任務表輪詢任務狀態更新進度。提示詞的拼接邏輯是這樣的def build_prompt(shot): camera shot[camera] scene shot[scene] action shot[action] dialogue shot.get(dialogue, ) prompt f{camera}{scene}。{action}。 if dialogue: prompt f人物說出對白{dialogue} return prompt實際拼出來的效果類似“中景, 緩慢推近辦公室夜景。林晚推開門走進辦公室看到陳默站在窗前。人物說出對白你怎么來了”注意我在提示詞里沒有寫任何“高質量、8k、電影感”之類的形容詞。原因很直接seedance2這類模型對畫面質量本身就內置了優化再反復疊加這些詞反而會引入過飽和、銳化過度的問題生成的畫面看起來很不自然。你要相信模型的基礎能力把提示詞的空間留給劇情和動作描述。4.4 素材歸檔規范視頻生成完成后所有素材統一歸檔到項目目錄下結構如下project_name/ ├── scripts/ │ ├── 01_story.md # 原始故事 │ ├── 02_script.json # 劇本 │ └── 03_storyboard.json # 分鏡 ├── characters/ │ ├── 林晚_front.png │ ├── 林晚_half.png │ ├── 林晚_full.png │ └── 陳默_front.png ├── scenes/ │ ├── 辦公室夜景.png │ └── 天臺日景.png ├── shots/ │ ├── S01_01/ │ │ ├── prompt.txt │ │ ├── ref.png │ │ └── output.mp4 │ └── S01_02/ │ ├── prompt.txt │ ├── ref.png │ └── output.mp4 ├── subtitles/ │ ├── S01.srt │ └── S02.srt └── project.db這個目錄結構不是隨便定的。每生成一個鏡頭我不僅保存視頻文件還把提示詞和參考圖放進同一個目錄。這樣回頭想查“這個鏡頭當時是怎么生成的”所有信息都在一個文件夾里不需要再去翻數據庫。對短劇這種高頻修改、長期迭代的項目來說這個習慣能省下大量時間。5. 短劇工作流管理任務調度和版本控制的思路有了素材以后真正的短劇生產還差最后一步把素材按照劇情順序組織成一個完整作品并且方便做多集管理。這也是標題里“短劇工作流管理”這個關鍵詞的分量所在。5.1 SQLite任務表讓每個生成鏡頭可追蹤批量生成下來會有幾十個視頻片段哪個生成失敗哪個還在排隊哪個已經完成全都要有記錄。我在SQLite里建了一張任務表CREATE TABLE video_tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, shot_id TEXT NOT NULL, status TEXT DEFAULT pending, -- pending/running/succeeded/failed retry_count INTEGER DEFAULT 0, provider TEXT DEFAULT seedance2, video_path TEXT, error_message TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP );shot_id是主索引每個鏡頭在一個項目里只會有一個任務。如果失敗了重試時不是新建一條記錄而是更新原記錄的狀態和重試次數這樣整個生成歷史是完整連續的。我還給任務表加了一個provider字段記錄這個鏡頭最終是由seedance2生成的還是由本地備用模型生成的。這個字段看著不起眼實際上很重要后期審片時如果發現某個鏡頭畫風不統一一查就知道這個鏡頭是備用模型生成的直接重生成就行。5.2 多集串聯自動拼接和字幕單集短劇通常有多個鏡頭多集短劇則是一套素材管理邏輯。工作流里我按S01_01到S01_N的順序讀取所有已完成的視頻片段用FFmpeg按順序拼接成完整一集。這里的重點是自動從分鏡JSON里提取每個鏡頭的時間表借助拼接時間軸數據生成一個完整的字幕文件。實現上很簡單先計算每個鏡頭在總時間軸上的起點再把分鏡里的對白和起點時間對應起來寫進SRT字幕文件。我用了一個腳本完成拼接和字幕生成ffmpeg -f concat -safe 0 -i concat_list.txt -c copy S01_final.mp4concat_list.txt里是已完成鏡頭的視頻文件路徑按shot_id排序后寫入。這個方法比在剪輯軟件里手動拖素材快得多。拼接后我還會用FFmpeg做一次一鍵加字幕ffmpeg -i S01_final.mp4 -vf subtitlesS01.srt S01_captioned.mp4這套流程一旦跑通新的一集只需要把分鏡JSON更新好就能在十幾分鐘內出片。做AI漫劇和AI短劇的效率差距就是在這里拉開的。5.3 進度可視化一個簡單的生成狀態面板管理幾十個鏡頭的生成任務光靠命令行看日志實在太痛苦。我寫了一個簡單的HTML狀態頁面通過讀取SQLite任務表把每個鏡頭的狀態用色塊顯示出來綠色是完成黃色是生成中紅色是失敗。整個頁面不依賴任何前端框架就是一個自動刷新的HTML文件。這個狀態面板最大的價值是讓我能在批量生成過程中一眼看出哪個鏡頭出了問題及時干預。有一次批量生成到第17個鏡頭時連續失敗了三次我看面板發現失敗原因都是“參考圖路徑不存在”——角色目錄被更名了導致參考圖讀取失敗。如果沒有這個面板整個任務可能要在失敗后白跑很久才能發現。6. 踩坑記錄本地化生成短劇最容易翻車的地方最后一部分我把實測中踩得最深、最典型的幾個坑寫出來。這些都是文檔里不會寫、但實際轉換中一定會遇到的問題。6.1 顯存和內存的分配是“看不見的瓶頸”本地工作流最大的限制是硬件資源。一臺機器要同時跑Ollama劇本生成、ComfyUI參考圖生成、video_bridge視頻生成網關顯存和內存非常緊張。我的經驗是把不同組件放到不同的機器上運行。比如Ollama跑在Mac Studio上ComfyUI和視頻生成跑在Windows雙卡工作站上通過主機名互相訪問。這樣不僅資源不沖突而且在批量生成時還能并行工作。如果你的機器只有一張顯卡建議把Ollama換成一個輕量模型比如4B、7B量級的模型專門負責提示詞生成。不要試圖在同一個顯卡上同時跑13B模型和視頻生成那樣兩者都會慢到懷疑人生而且一旦顯存溢出整個工作流都會崩。6.2 單鏡頭時長和分辨率的限制seedance2這類視頻模型對單次生成的時長有上限通常一次生成5到10秒。我的經驗是短劇鏡頭盡量控制在4到5秒超過這個時長畫面后半段的動作連貫性會明顯下降人物容易出現輕微的抖動和形變。處理長鏡頭時不要指望一次生成十幾秒的視頻更合理的做法是拆成多個短鏡頭在后期拼接時用轉場銜接。比如“角色從進門到坐下”這個動作拆成“推門進入3秒”和“走到桌邊坐下4秒”兩個鏡頭利用剪輯節奏感來掩蓋拼接痕跡。分辨率方面優先選1080p而不是2K、4K。視頻生成模型的推理耗時和顯存占用會隨分辨率顯著增長而短劇最終的傳播場景大多是手機豎屏觀看1080p已經足夠。生成后如果需要更高分辨率用后期放大工具處理就行沒必要在生成階段死磕。6.3 風格漂移同一個場景換個鏡頭就“變味”做漫劇和短劇時經常會遇到這個問題第一個鏡頭的場景很有氛圍感第二個鏡頭再生成時雖然提示詞寫得一樣但光影、色調、構圖全變了。這其實就是風格漂移。我的補救方案有兩步。第一步在ComfyUI里先確定每個場景的標準參考圖所有涉及該場景的鏡頭都使用同一張參考圖作為首幀第二步在視頻生成參數里把運動強度調低motion_strength控制在2到4之間因為視頻模型在運動幅度大的情況下為了保持運動連貫性往往會重繪靜態背景導致風格偏離。方案不復雜但能解決八成的風格漂移問題。剩下兩成老實說只能靠多生成幾個角度、從中挑一個最接近的來用。6.4 中文文件名和路徑編碼問題本地工作流里大量使用中文角色名和場景名這在Windows的NTFS文件系統下沒太大問題但在Linux環境或者跨平臺共享目錄時經常會出現編碼或路徑讀取失敗的問題。我的視頻生成網關曾經碰到過一個很隱蔽的bug提示詞里的中文沒問題但參考圖路徑里的中文讀不出來導致生成任務白白浪費了幾次重試。最終我的處理方式是所有項目目錄一律使用英文或數字命名角色ID使用拼音或縮寫比如linwan_front.png代替林晚_front.png。角色的中文名只存在于分鏡JSON的characters字段里用于描述和提示詞拼接涉及實際文件讀寫路徑時全部用ASCII字符。最后分享一點我自己折騰這套工作流的體會如果你也開始搭本地AI短劇工具我建議不要一上來就想生成一整個完整劇集。先拿一個3分鐘的單集做測試確認分鏡、參考圖、視頻生成、拼接、字幕這條主線能跑通再加配角和復雜場景。我實測下來第一次跑通的時間大概需要一天但跑通之后從故事到成片的整個流程會變得非常可控。seedance2的接入只是一個開始。真正常態化使用之后你會慢慢把精力從“怎么生成”轉移到“生成什么內容”上這就是工作流沉淀下來的價值。如果你也在這條路上遇到具體問題歡迎在評論區交流。本文還有配套的精品資源點擊獲取