用 Claude Code 與 MCP 自動化短劇分鏡：從大纲劇本到畫布鏡頭的 AI Agent 管線

短劇制作中 Claude Code 與 MCP 自動化的核心價值

本文由 Say Action 團隊撰寫。推薦與工作流指南基於短劇制作中劇本、分鏡、MCP 工具調用與逐鏡影片生成的實操經驗，不代表獨立第三方基準測試。 隨著豎屏微短劇制作從獨立創作者試水快速演變為專業影視工作室的高頻量產，前期策划與分鏡筹備環節最沉重的產能瓶颈，便是“劇本拆解與分鏡表錄入”。一部 60 至 90 秒的單集短劇通常包含 10 到 14 個快節奏鏡頭，整部 50 集劇集對應數百個緊密咬合的分鏡。若單純依赖人工在文字處理軟件中逐句拆解臺詞、反複複制粘贴提示詞，並手動標註鏡頭機位與景別，不僅耗費巨大人力，而且極易在多集並發時出現場次錯漏、人物臺詞串行或敘事張力斷裂等嚴重失誤。

為了打破這一重複性工程壁垒，新一代技術型短劇編導正在將 Anthropic 的 Claude Code 與 OpenAI Codex 引入工業管線，通過 MCP（Model Context Protocol）標準協議實現自動化拆鏡。MCP 是一套開放的連接規範，它允許大語言模型（LLM）Agent 跳出封閉的對話窗口，直接調用外部工具和創作工作臺。當創作者向 Agent 交付全集劇本後，它並非簡單輸出文本概括，而是依據豎屏短劇特有的快節奏開場原則與情緒起伏，將劇本拆解為可執行的結構化分鏡數據。

尤其當 Claude Code 與 Say Action 遠程 MCP 服務直接連接後，Agent 僅憑終端命令行即可在畫布上建立對應劇集工程，並將標準分鏡行自動批量寫入分鏡表格中。Agent 承擔了機械式的數據分發與鏡頭運動語法規範化工作，導演則可將全部精力聚焦於無限畫布上的視聽連貫性审核與演員表演神態把控。這種人機協作不僅顯著壓縮了短劇前期筹備周期，更有助於保持整季短劇的工業化交付質量。

Say Action MCP 服務架構與安全權限邊界

Say Action 的 MCP 體系依托遠程 Streamable HTTP 端點 https://isayaction.com/api/mcp 運行。它舍棄了依赖瀏覽器會話的 Cookie 機制，全面採用具備精細權限控制的個人訪問密鑰（Access Key）與 Bearer 鉴權憑證，便於在本地終端或持續集成流水線中建立安全通信。開發者只需在系統環境變量中寫入 export ISAYACTION_API_KEY="yc_live_..."，並在終端運行 claude mcp add --transport http isayaction "https://isayaction.com/api/mcp" --header "Authorization: Bearer $ISAYACTION_API_KEY"，Claude Code 即可秒級發現並註冊 Say Action 的官方工具集。

在短劇分鏡任務中，Say Action 的 MCP 工具遵循清晰的分層調用逻輯。首先通過 get_account 與 list_models 查詢當前賬戶點數餘額及已接入的影片模型清單；接着調用 create_project 初始化專屬的 9:16 豎屏畫布專案；隨後執行 import_script、batch_add_storyboard_cards 或 set_unit_shots，將劇本解析出的鏡號（Shot ID）、角色標簽、臺詞文本、景別與機位提示詞批量註入畫布分鏡表的對應行中。若切換至專家模式（?profile=expert），Agent 還可直接讀取畫布已有角色參考節點的 ID 並掛載至各分鏡行。

該架構最核心的設計準則是“坚固的安全權限邊界（Permission Boundary）”。Claude Code 拥有拆解劇本、生成分鏡行和配置文字提示詞的完整能力，但平臺對高額消耗算力的影片生成（Generate Video）進行了顯式隔離，禁止 Agent 自行批量觸發生成。這種權限隔離有助於防止因 Agent 解析逻輯死循環或理解偏差導致瞬間發起數十個影片渲染任務而耗盡點數的風險。所有最終影片生成必須由人類導演在網頁畫布上核驗畫面構圖與模型配置後手動確認發起，形成更可控的雙重確認機制。

驱動 Claude Code 拆解 12 鏡短劇分鏡的結構化提示詞模版

想要讓 Claude Code 拆解出符合豎屏移動端觀影節奏的分鏡表，必須在指令中明確約定 60 秒短劇特有的“12 鏡節奏定律”，而非套用傳統橫屏電影的漫長铺墊模式。移動端觀眾往往在開場短時間內即決定是否划走，因此第 1 至 2 鏡建議設計為具有視覺衝擊力的特寫懸念（Hook）；第 3 至 7 鏡採用雙人對白過肩反打（OTS）推進核心衝突；第 8 至 10 鏡安排情緒爆發或劇烈肢體對抗的高潮段落；第 11 至 12 鏡則以危機爆發的冷峻懸念神態（Cliffhanger）收尾，吸引觀眾點擊下一集。

在 Claude Code 終端中執行的標準 12 鏡分鏡拆解指令如下：“使用 Say Action 工具，將《財阀之爭》第 1 集劇本拆解為 12 鏡 9:16 豎屏分鏡表。第 1 鏡為 2 秒內的極致面部特寫懸念開場（Hook）；第 2 至 7 鏡安排男女主角的交錯快速對白；第 8 至 10 鏡為摔落文件的衝突高潮；第 11 至 12 鏡定格為意味深長的懸念特寫。為每個鏡頭分配唯一的幂等鍵（idempotencyKey），完整保留臺詞原文，嚴格解耦運鏡與主體動作描述，並寫入畫布分鏡表。切勿觸發影片生成接口。”

提示詞編寫中至關重要的工程細節是“運鏡指示詞與人物動作的嚴格解耦”。當影片生成模型同時接收攝影機移動與人物躯體位移指令時，往往會產生嚴重的畫面形變與人物五官模糊。因此需強制要求 Claude Code 採用結構化標記分隔，例如“Dolly In 45mm Lens / Subject Min-jun turns his head sharply”。將推拉摇移（Dolly, Pan, Tilt, Roll, Tracking）等光學控制與演員表演物理動作解耦，下游影片模型才能精準計算攝像機運動矢量，有助於保持人物面部結構的穩定。

接收到指令後，Claude Code 會通過 Say Action MCP 的 batch_add_storyboard_cards 接口批量創建 Shot_01 至 Shot_12 的分鏡行。每一行均精細綁定鏡號、預估時長（如 2.5 秒、4 秒）、劇本對白、角色頭像標簽以及英文視覺運動提示詞。終端會實時打印每次工具調用的狀態日志並返回經過鉴權的畫布直達鏈接，導演在瀏覽器中展開頁面即可直觀审閱完整的單集分鏡矩陣。

人機協同複核（Human-in-the-Loop）與關鍵幀圖像預演

無論大語言模型的文本理解多麼出色，僅憑純文字提示詞也难以精準還原導演心中對於特定光影基調、微妙微表情與現場道具質感的視聽設想。因此，在 Agent 完成分鏡表铺設後，由專業導演介入的人機協同複核（Human-in-the-Loop）是保持成片品質的關鍵環節。Say Action 的無限畫布將 Agent 寫入的所有分鏡行以圖形化節點直觀展開，導演可以使用鼠標流畅拖拽、點擊修改，從容校驗整場戲的情感起伏與機位逻輯。

在發起最終影片生成前，導演團隊建議參考如下“三步複核清單”：第一步：角色與臺詞完整度核對。確認劇本臺詞無遺漏截斷，且分鏡行的人物標簽與畫布左側的角色設定參考節點（Character Sheet）精準對應。第二步：運鏡動線衝突排查。檢查單個鏡頭中是否存在相互矛盾的運鏡動詞（如同時要求快速推進又向左橫移），將其提炼為單一連貫的光學軌跡。第三步：靜止關鍵幀預演。在消耗較多點數渲染影片前，先調用 Say Action 畫布內支援的 Nano Banana 或 GPT Image 圖像節點，為每個分鏡行各渲染 1 張起始關鍵幀，在低成本下肉眼確認全集 12 鏡的色調、布光與人物長相是否保持良好的一致性。

關鍵幀預演通過後，再依據各鏡頭的敘事需求靈活路由至最佳的影片模型。在 Say Action 畫布中，不同分鏡行可按需配置不同的上游影片模型：對於強調人物細微眼神與對白口型的近景特寫，可路由至 MiniMax Hailuo 模型；對於包含激烈肢體動作、快節奏運鏡的高潮鏡頭，可指定 Kling v3 文字生影片或 Kling v3 Turbo 文字生影片；而對於需要宏大場景調度與電影級空間透視的鏡頭，則可調度 Seedance 2.0/2.5 或 Wan 3.0（wan3.0-*）模型。即便某一鏡頭的動態不盡如人意，導演也只需單獨重試該鏡頭的影片節點，其餘滿意片段毫發無損。

Agent Token 成本與畫布點數安全邊界

在搭建 Claude Code 與 MCP 自動化流水線時，創作者需要了解“雙重成本架構（Dual Cost Architecture）”。使用 Claude Code 拆解劇本、梳理分鏡消耗的是 Anthropic 的大語言模型 Token，而後續在畫布中生成圖像關鍵幀與影片渲染消耗的則是 Say Action 平臺的計算點數。文本層面的 Token 開銷極低，因此在劇本前期與 Claude Code 多輪對話磨合、反複润色出最理想的 12 鏡分鏡表後再進入視覺渲染，是控制整部短劇制作預算的最有效手段。

自動化流程中最令人擔忧的風險是代碼死循環或 Agent 失控帶來的賬單失控。為防範這一風險，Say Action 在 /access-keys 頁面為每個 API Key 提供了“累計消費上限（Cumulative Spending Limit）”設定。創作者可為自動化密鑰配置 200、500 或 1000 點數的封頂額度，一旦 Agent 調用達到該閾值，系統將自動拒絕任何新增扣費請求。此外，所有 MCP 接口請求均強制要求攜帶 8 至 128 位的幂等鍵（idempotencyKey），即便遭遇網絡闪斷發生客戶端重試，服務端也會識別已有任務，有助於防止重複扣費或生成冗餘節點。

平臺套餐、點數預估與退款規則均遵循官方產品定義。在影片生成過程中，若模型供應商接口明確返回失敗，系統將自動退回預留點數。針對拥有自購 API 密鑰或高並發需求的工作室團隊，可通過 BYOK 機制接入自有渠道，避免平臺點數消耗。平臺計費與自有渠道的費用邊界請以產品文案為準：點數按渠道定價預估；實際扣除以後臺配置的價格檔為準。 影片按秒計費為按請求秒數預授權；若上游實際產出時長超出請求，可能產生少量讓利差額。 服務費用於工作臺，不包含模型用量；第三方 API 費用另付。 上游明確返回失敗時會退回預留點數；網絡狀態不明確的任務先保留待核對狀態，避免重複結算。 BYOK 支援配置自有 API 地址、模型密鑰和自定義 Header。使用 OneAPI、NewAPI 等中轉站時，需要選擇與其實際接口匹配的 OpenAI、Gemini 或 Claude 協議，並核對模型 ID 及圖像、影片接口支援情况；不是所有中轉站和私有協議都能直接使用。BYOK 模型調用不加收平臺模型費用、不扣平臺生成點數，但工作空間服務和上游模型費用仍分別收取。

串接自帶模型與第三方中轉站

在模型管道設定中填入 Base URL 和 API Key，依供應商文件設定協定、模型 ID 與所需 Header。先確認文字生圖、圖片轉影片等功能，再開始生成；介面路徑、解析度與首尾影格參數以實際管道為準。尚未支援的管道可提出適配申請，申請不代表已完成相容。

BYOK 支援自訂 API 網址、模型金鑰與 Header。使用 OneAPI、NewAPI 等中轉站時，需選擇與實際介面相符的 OpenAI、Gemini 或 Claude 協定，並核對模型 ID 及圖片、影片介面的支援情況；並非所有中轉站或私有協定都能直接使用。BYOK 模型呼叫不加收平台模型費用，也不扣平台生成點數；工作空間服務與上游模型費用仍分別收取。

只串接你信任的管道，正式環境使用 HTTPS。自訂請求會經登入後的後端轉送；必要的提示詞、參考素材與憑證會參與請求。不要將 API Key、密碼或含金鑰的 Header 放進公開畫布、截圖或客服申請。