DramaClaw：原始碼可得的 AI 短劇工業化流水線，以無限畫布、雙軌資產庫與 MCP 智慧體重構創作

一句話定位

DramaClaw 是一條“原始碼可得”的 AI 短劇生產線，由團隊自己每天使用的工業化流程開源而來。

它把劇本、分鏡、角色與場景資產、配音、成片剪輯串成一條可自託管的鏈路，並配有一塊無限畫布和一個內建智慧體。專案採用 Elastic License 2.0：可以執行、修改、用它做出的作品也可以商用，只要求介面角落保留“Powered by DramaClaw”；唯一仍然關閉的是把它包裝成託管 SaaS 提供給他人。

雙軌架構：畫布與流水線共用一個資產庫

專案的核心設計是“雙軌”。第一軌叫“蝦畫”（XiaHua），是節點式無限畫布。官方介紹提到畫布上有 18 種節點，包括上傳、影象生成與編輯、分鏡生成、劇本、節拍上下文、影片、影片合成、音訊、風格、技能、分組、360° 全景檢視、3D 世界、匯出等。每個節點保留自己的生成歷史，節點之間可以自由連線。畫布還提供標籤頁、小地圖、視口書籤、吸附對齊、細節層級渲染、修訂歷史與按畫布加鎖，面向大型工程。

第二軌叫“蝦集”（XiaJi），即系列流水線，分為匯入、規劃、生產、交付四段。匯入階段直接從小說稿或劇本（支援 Fountain 格式）建立劇集、角色與場景，不再依賴知識圖譜或向量；舊專案仍保留 Cognee 故事圖路徑。規劃階段做章節切分、節拍規劃和多集弧線，並提供“自適應、逐字、分階段”三種劇本模式，帶審閱與修復迴圈。生產階段生成分鏡與首幀、合成情感化配音。交付階段完成劇集拼接、字幕與完整素材包匯出。

兩條軌道共享同一個資產庫“蝦塘”：先在畫布上自由探索，滿意的節點可以預覽影響後提交進劇集，也可以把劇集反向投射回畫布。這是它與“只給畫布”或“只給嚮導”的工具最大的區別。

內部機制：可拆解的非同步任務

流水線的每一步都是獨立的非同步任務，擁有自己的介面，可以順序執行、跳步、從任意檢查點恢復，甚至接入自己的編排器。任務中心提供狀態、進度、日誌、取消與重試，並在入隊前校驗前置條件。架構上刻意做輕：不需要 Postgres、Redis、Celery 或 Ray，任務在程序內執行，狀態儲存在本地檔案系統（SQLite 加檔案）。因此一臺 2 vCPU、4 GB 記憶體的普通筆記本或小型 VPS 就能跑，標準流程不需要 GPU；只有可選的 world 擴充套件（體素或全景轉 3D）才需要 GPU 與 CUDA 映象。

所有模型推理都經過一個相容 OpenAI 協議的閘道器，本機不跑模型。閘道器有兩種來源：官方 RelayClaw 服務，或隨專案捆綁的 dramaclaw-gateway。後者是 New API 的分支，實現了 DramaClaw 自定義的 DC-Media 契約，用來表達影象、影片、音訊的媒體角色、參考素材和首尾幀，再轉換成各家供應商的原生 API。已提供的介面卡包括 ComfyUI、MiniMax/海螺、火山引擎豆包/Seedance、fal.ai、阿里、可靈、即夢、Vertex AI、Gemini、OpenAI/Sora 與 Suno。官方模式下，影象用 gpt-image 與 nano-banana，影片用 Seedance 1.0、1.5、2.0 系列，配音用 IndexTTS2。

空間一致性：導演世界

短劇最難的是跨鏡頭一致。DramaClaw 的“導演世界”把影象轉成 3D 高斯潑濺（Gaussian Splat）場景，並提供 scene-360 全景節點，形成可取景的虛擬佈景。

它鎖定空間結構、人物走位與機位，使用者在 3D 檢視器裡取景、截圖，再作為下一次生成的背景。這樣同一地點在不同鏡頭中保持一致，也讓“先搭景、後拍攝”的影視工作方式進入生成式流程。

智慧體與生態

內建智慧體“蝦導演”（Xia Director）目前可以瞭解專案狀態、推進劇本與鏡頭任務、檢查交付物完整度並給出下一步建議。專案還提供本地 MCP 伺服器，僅監聽迴環地址並需要顯式信任標誌，使 Claude Code、Codex 等任何 MCP 客戶端都能驅動 DramaClaw。官方在 README 中給出的演示是：一句提示詞讓蝦導演在畫布上鋪出 17 個節點、32 條邊的短片工作流，從創意簡報一路到最終剪輯。需要注意，這一“在畫布上建圖並執行”的能力仍列在“開發中”，並要求每條畫布命令先在瀏覽器裡獲批。

開發中的專案還包括：含 11 個工作流技能與 60 個配方的目錄、可跨 Hermes、OpenClaw、Claude Code、Codex 使用的 agent-kit、瀏覽器內 3D 排程的 Previz 舞臺，以及分支敘事與互動廣告。

效能、成本與證據邊界

倉庫沒有給出可復現的基準測試，沒有每集耗時或每分鐘成本的公開數字。

成本主要由所選閘道器背後的影象、影片、語音模型決定，本地開銷很低。README 中的對比表把 DramaClaw 與八個被遮蔽名稱的競品逐項比較，但那是專案方依據公開文件自行評定，應視為定位宣傳，而非獨立評測。

侷限與風險

第一，許可證是 Elastic 2.0，屬於原始碼可得而非 OSI 意義的開源，託管 SaaS 被禁止，二次商業化需要評估。第二，成片質量取決於上游影片模型，角色一致性與口型仍是生成式方案的共同難點。

第三，最有想象力的部分，即智慧體在畫布上自主建圖，尚未釋出。第四，官方模式依賴 relayclaw.cdnfg.com，隱私與穩定性需自行評估；自定義模式則要自己維護供應商通道與金鑰。

對開發者與企業的意義

對獨立創作者和小型工作室，它提供了一套可自託管、模型中立的“短劇工廠”，不必拼接十幾個孤立工具。

對工程團隊，值得關注的是它如何用 MCP 暴露能力、用統一閘道器契約遮蔽供應商差異，以及用最小基礎設施完成長流程任務的取捨。下一步觀察重點是開發中功能何時釋出，以及許可證的 SaaS 條款是否放寬。

補充觀察

從工程取捨看，DramaClaw 沒有追求自研模型，而是把力氣花在“編排”和“契約”上：用畫布承載探索，用流水線承載交付，用 DC-Media 閘道器契約承載供應商差異。

這種做法讓它能隨上游模型更新而受益，也意味著最終畫質、速度與單整合本都不由它自己決定。團隊在評估時，應先用自己的劇本跑一遍完整流程，再記錄每集耗時、失敗重試次數與模型呼叫費用，得到屬於自己的基準。