這篇稿子是我自己的 AI 短劇 Agent 0.0.1 版本測試記錄。測試題材用了短視頻里常見的女性逆襲加商戰套路《72小時的反擊看姐重奪公司控制權》。先給結論這個版本能在有限條件下跑通主題解析、人物拆解、分集大綱和單集臺本生成但輸出遠沒到“可以直接拍短劇”的程度。如果你正在搭 AI 短劇創作管線或者在選 Agent 開發框架這篇的重點可以放在哪些環節被自動化了哪些環節還必須人工介入以及 0.0.1 版本里最容易踩的坑是什么。1. 先弄清楚“AI短劇Agent 0.0.1版本”到底在測什么普通的“AI生成短劇”通常是你丟一個提示詞幫我寫一個重生短劇。模型給你一段文字。這只能算一次文本生成任務。Agent 的區別是把事情拆成多步。以短劇為例主題理解、故事梗概、人物小傳、分集大綱、單集臺本、分鏡提示詞、旁白文本、配音文本這些環節不再一次性吐出來而是由 Agent 調度多個步驟完成。0.0.1版本的主要意義就是驗證這套多步鏈路能不能穩定跑起來。那么為什么要用短劇題材因為短劇套路成熟、結構清晰、人物關系簡單。主角、反派、助攻、情感線、反轉點都比較固定。這類結構化的內容特別適合交給 Agent 拆解和生成。如果連短劇這種強套路文本都做不穩那更復雜的任務先別談。0.0.1版本最該關注三件事能不能跑通。主題進文案出中間不要斷。輸出結構是否穩定。腳本、大綱、分鏡是否分離是否方便后續接配音和剪輯工具。失敗能不能定位?？ㄗ?、空結果、重復內容日志里能不能看到原因。很多人一上來就要求生成成品短劇甚至要求畫面一致、配音自然、剪輯成片。這個目標沒有錯但對于0.0.1版本來說標準應該降級先把文字生產鏈路跑穩再談畫面和成片。我測試時沒有把“效果驚艷”當作目標只關注一件事同一個劇本題材用同一套 Prompt 和參數連續跑幾輪輸出會不會失控。如果第一輪輸出很好、第二輪直接跑偏那后面接批量任務就完全沒有可靠性。這里還要強調一個邊界0.0.1版本不涉及視頻渲染不保證畫質不負責最終剪輯工程?！癆gent”這個詞容易被神化實際在0.0.1階段它就是一套帶狀態、帶步驟、帶輸出約束的文本生成流程。你可以在里面接不同模型、不同提示詞模板甚至接外部工具但核心邏輯還是“拆任務、分步執行、匯總結果”。1.1 它和普通AI生成短劇有什么區別普通AI生成短劇是“一人一段式”你輸入主題模型輸出一段完整劇本或某個角色臺詞。缺點是沒有人物一致性角色名字可能中途變化。沒有分集結構故事高潮亂放。沒有旁白和分鏡提示詞拿到文本后還需大量人工拆解。AI短劇Agent更像一個“小型生產流水線”。它不會一次性把所有東西都生成完而是先解析主題輸出人物關系和主線沖突。生成故事梗概。拆分集數大綱。按集生成臺本。再從臺本里抽取旁白、動作、畫面描述。這樣每一層都有獨立任務也方便你對中間結果做檢查和替換。比如說如果你對人物小傳不滿意可以只修改人物部分再讓后續步驟繼續而不是整段重新生成。這個能力對做長劇很重要因為短劇通常20集起步一次性生成20集文本一是超長上下文容易崩二是你無法逐段審核。我一開始以為這類Agent只是“套了一層提示詞模板的模型調用”實際跑下來發現不是。它需要處理任務狀態、上下文拼接、分步輸出、失敗重試。這些邏輯比單純寫提示詞復雜得多但也是它能批量生產短劇文本的基礎。1.2 0.0.1版本最該關注的三件事第一能不能形成穩定的結構化輸出。我在測試初期遇到最多的問題不是模型不會寫而是它偶爾會把“人物小傳”和“分集大綱”混在一起或者返回非 JSON 格式導致后一步解析失敗。所以0.0.1版本里最該盯住的就是輸出格式是否穩定。第二任務中間狀態是否可見。Agent 跑的時候最好能輸出每一步的日志比如“正在生成人物小傳”“正在生成第3集臺本”。如果任務卡住至少知道卡在哪一步。0.0.1版本里我會在每步前后加一條日志記錄該步開始時間、結束時間、輸出長度不然排查起來全靠猜。第三失敗重試是否可控制。短劇Agent生成過程中API超時、單次返回過長、文本里帶有非法字符這些都是常見問題。比較好的做法是讓Agent在失敗時把原始返回記錄下來并允許人工判斷后重試。不要做無腦重跑因為無腦重跑可能把本來正常的數據也覆蓋掉。注意0.0.1版本的定位是“驗證路線”不是“交付成品”。如果測試時發現某個環節不穩定應該先停下來處理這個環節而不是繼續往后堆功能。2. 用《72小時的反擊》當測試用例跑出第一版結果我這次測試用的題材是“72小時的反擊看姐重奪公司控制權”。這種題材在短劇里屬于“女性逆襲商戰”的經典組合人物克制、反轉密集很適合作為Agent的第一批測試用例。2.1 測試輸入怎么設計我沒有直接讓它“隨便寫一部短劇”而是給了明確的結構化輸入。因為Agent和普通模型不一樣它需要知道按什么順序拆解任務。實際輸入類似下面這份需求卡主題72小時的反擊看姐重奪公司控制權 題材都市商戰、女性逆襲 劇集20集每集文案長度約60到90秒 風格開場即沖突、每集留鉤子、臺詞信息密度高 人物姐姐為主角反派是爭奪控制權的對手另有1到2個關鍵助攻 限制不要出現真實公司名、真實人名這里沒有填具體的人物名我想看Agent能不能自己穩定生成名字并保持一致。測試下來0.0.1版本在第一次生成時基本能做到但它自己在后續生成單集臺本時偶爾會更換稱呼比如主角從“林晚”變成“姐姐”再變成“林總”。這對于人去讀問題不大但如果要提取角色名做配音標注就會出現不一致。所以建議在輸入里把關鍵角色的固定稱呼單獨寫清例如“主角林晚全劇統一稱呼為林晚或林總口吻一致”。這一步能省很多后續修改時間。2.2 第一次單集生成結果長什么樣Agent跑完第一輪后返回的不是一個文件而是分層的文本結果故事梗概。人物小傳。分集大綱。第1集臺本。第1集旁白提示詞。第1集分鏡提示詞。我截取第1集的內容來看它基本符合預期開頭直接交代林晚發現公司股權被轉移必須在72小時內找到證據否則會被踢出董事會。這個開場足夠快符合短劇“三秒鉤子”的習慣。但單集臺本里也有明顯問題。比如有一句旁白是“她看著窗外的城市眼神里是別人看不懂的堅定”這種表達寫成小說可以寫成短劇旁白就太書面了配音演員念出來會很慢。短劇的旁白講究口語化、節奏快應該改成類似“林晚站在窗前沒有慌。時間只有72小時她必須找到翻盤的牌。”0.0.1版本能生成“像劇本”的東西但不代表它天然懂“短劇語言”。你在Agent的提示詞里需要加一句約束旁白使用短句少用長句和抒情性描述像解說一樣推進劇情。加上這句之后輸出會穩很多。2.3 多集連續生成的完整度測試單集生成只是第一步。短劇的核心問題是第1集到第20集能不能連起來。第一次測試時我連續讓它生成5集結果出現了兩個典型問題第2集開始人物對話的語氣略有變化。主角上一集還有很強控制感下一集遇到對手時顯得過于被動。第3集出現了重復信息。角色在對話里把自己已經查到的證據又解釋了一遍明顯是在填充時間。這類問題不是模型不會寫而是分步生成時上下文流失。Agent生成的每一集都要帶著“全局設定”和“前情摘要”一起喂給模型不能只告訴它“你負責寫第3集”。我后來在任務鏈里加入了一個“每集前情摘要”步驟效果改善很多。測試結果可以簡單記錄成表格測試項判斷標準第一輪表現故事梗概閉環72小時危機、目標、結果是否清晰通過人物動機一致角色行為和身份不發生沖突基本通過稱呼有漂移分集銜接每集結尾有鉤子下集能承接部分通過單集臺本可用度去掉重復內容后可直接配音需要1輪人工修正整體來看0.0.1版本“能跑通”但“跑得穩”還談不上。如果你拿這個版本來做正式項目建議把人工審核環節放在分集大綱之后而不是等所有分集都生成完再審核。大綱錯了后面生成得越多返工越重。3. 輸出質量怎么判斷從劇情閉環到角色一致性短劇文本不是寫出來就行它有一套自己的質量判斷標準。我這里用了四個維度劇情邏輯、角色一致性、節奏鉤子、文本落地性。3.1 劇情邏輯是否閉環短劇再狗血也需要有基本邏輯。以“72小時的反擊”為例我判斷核心邏輯是否成立就看三件事為什么是72小時。72小時是一個倒計時它是推動女主行動的動力不是裝飾。女主靠什么翻盤。是隱藏股權、關鍵錄音、秘密賬本還是外部盟友必須有一個可被兌現的手段。對手為什么會被翻盤。不能讓對手第19集突然智商下線而是女主用關鍵籌碼擊中了對手的軟肋。0.0.1版本在梗概生成時基本能帶上這些點但在分集展開時容易丟失。比如第12集女主已經開始反擊到第13集又回到被動局面中間缺少合理解釋。這個時候不要急著懷疑模型能力先回頭檢查分集大綱和當前集號的前情摘要大概率是信息沒傳遞過去。3.2 人物設定是否漂移人物一致性是短劇Agent最容易被忽視的問題。角色出現漂移不只是名字變化還包括性格行為漂移一個果斷的姐姐在關鍵時刻優柔寡斷。語言風格漂移主角一會兒說“你等著”一會兒說“這件事恐怕還需從長計議”。關系線漂移上一集還是敵對下一集突然變成盟友中間沒有鋪墊。解決思路不是靠模型記性好而是把“角色信息卡”單獨固定下來。每次生成單集前把角色卡和前幾集的關鍵事件摘要一起傳入。角色卡里寫清楚姓名、身份、核心目標、性格關鍵詞、常用口吻、禁止行為。比如“林晚語氣冷靜但壓迫感強說話少用感嘆號不會當眾情緒失控”。0.0.1版本對角色卡的依賴非常高。如果你準備做自己的AI短劇Agent第一件事不是優化模型而是先做好角色卡模板。角色卡越具體生成的穩定性越高。3.3 每集鉤子和節奏是否達標短劇按秒算第1秒到第3秒必須有人物、沖突、信息量。第10秒左右要有一個小反轉或信息爆點。每集結尾還要留一個懸念讓用戶愿意看下一集。我在測試里設計了一個鉤子檢查項讀取每集最后三句判斷是否包含“未解決的問題”。例如第1集結尾“林晚把協議翻到最后一頁發現簽名日期是今天?！边@是一個鉤子。第1集結尾“林晚深吸一口氣決定開始調查?！边@不是一個強鉤子信息量不夠。0.0.1版本能寫出鉤子但常常寫得太平。此時需要給Agent提供一個“鉤子句式庫”懸念型、身份反轉型、倒計時加碼型、籌碼曝光型。讓它基于這些模板生成而不是自由發揮。3.4 文本落地性短劇文字最終要交給配音、字幕、分鏡和剪輯。所以文本落地性要看是否方便下游工具使用臺詞是否適合口播句子太長要拆。旁白是否和畫面對應。動作描述是否寫成了可拍畫面而不是心理描寫。是否有明確的分鐘數和場次。0.0.1版本在分鏡提示詞上會輸出場景、人物動作、鏡頭方向等但比較粗糙。比如它會寫“林晚走進辦公室鏡頭緩慢推進”但不會寫“這是室內日景畫面左側有落地窗人物從右向左走”。后者對AI視頻生成或人工拍攝都更友好。如果你不只做文本后續還要接AI視頻生成就必須在Agent的分鏡提示詞模板里加入“畫面組成要素”。否則拿到分鏡提示詞后還是要人工補很多內容。4. 單條任務跑通之后再處理批量生成短劇的現實是20集起步甚至60集。單集跑通只是第一步真正考驗Agent的是批量任務的穩定性。4.1 從單集擴展到十集先拆輸入清單不要直接發一條超長指令讓它“寫十集”模型容易丟失信息。更穩的做法是準備一個輸入清單每一行是一個獨立生成任務。project_id,series_no,title,main_clue,characters revenge72,S01E01,發現股權被轉移,林晚發現股權轉移協議,林晚;對手;助理 revenge72,S01E02,72小時倒計時開始,董事會改選通知,林晚;對手;律師我把這個清單塞給Agent它按順序依次生成。關鍵點是清單里不要只寫集數還要寫“本集要推進的主線線索”和“出場角色”這樣模型知道每集的邊界不會把第2集的內容寫到第1集。4.2 輸出目錄和文件命名要提前規劃批量生成后如果文件名不統一后期合并整理會非常痛苦。我在測試時用的目錄結構是project_revenge72/ script/ # 最終合并劇本 outline/ # 分集大綱 episodes/ # 單集臺本用 S01E01 命名 storyboard/ # 分鏡提示詞 tts/ # 配音文本 fail/ # 失敗任務輸出文件名格式固定為{項目ID}_{集數}_v{版本號}.md。比如revenge72_S01E03_v0.1.md。這樣做的好處是無論任務跑了幾次都能通過版本號找到是新版還是舊版不會覆蓋重要內容。4.3 失敗重試和斷點續跑不能省批量跑10集很難保證10集全部成功。我遇到的失敗原因主要是三個模型接口超時。單集輸出過長半路被截斷。返回格式不對JSON解析失敗。0.0.1版本里需要做三件事每個任務寫失敗日志記錄集數、失敗階段、原始返回片段。自動重試時保留前一次輸出避免覆蓋。支持從失敗集數繼續跑而不是重新跑全部。很多人一跑批量就著急并發想一次開10個線程。實際上0.0.1版本不建議這么干。先順序跑一輪看穩定性和耗時再嘗試2到3路并發。并發上來后接口限流、超時、日志混亂等問題都會放大。注意批量任務最怕的不是跑得慢而是跑完了才發現輸出不一致。每跑完5集花兩分鐘抽查一下集與集之間的人物稱呼、時間線、事件連續性比最后統一檢查省時間。5. 0.0.1版本的價值邊界和落地建議5.1 哪些場景可以先試用盡管0.0.1版本不夠成熟但已經有一些場景可以先用起來選題腦暴輸入一個“主角目標期限”生成多個短劇梗概用來篩選題材。分集大綱初稿把想要的反轉和走向給Agent讓它排出20集結構。人物小傳和關系線快速生成角色卡然后人工修改。分鏡提示詞的初稿如果要接AI視頻工具先用它生成畫面描述再人工調整。這些場景的共同特點是“生成內容要做二次加工”不需要一步到位。0.0.1版本能幫人把空白文檔填滿加快構思速度但不會直接替代編劇和剪輯。5.2 哪些場景不要急著依賴不要一上來就用它做完整短劇的最終成片。尤其是這些環節演員形象一致性。目前文本Agent管不到人物形象一致需要靠AI視頻工具或固定人物參考圖解決這是另一套鏈路。成片剪輯節奏。Agent生成的單集臺本不能直接映射成剪輯節奏必須人工看一遍。大規模穩定生產。0.0.1版本幾乎沒有調度優化連續跑幾十集時如果沒做好任務隊列和重試失敗率會很高。如果項目目標是“從故事到成片全自動”那0.0.1版本只是第一步里的第一步后面還有配音、畫面、字幕、剪輯、合成等多個環節。盲目套用Agent反而會讓流程更難排查。5.3 對Agent開發路線有參考價值的經驗短劇Agent這個例子很適合用來練習Agent開發因為它的任務邊界清楚反饋速度快。你可以通過它學著怎么設計多步任務、怎么控制模型輸出格式、怎么處理長上下文、怎么做任務隊列。實際開發里我建議把Agent的每一步都設計成獨立函數并在輸入輸出中定義固定結構。比如“生成分集大綱”這一步輸入是主題和人物卡輸出是一個 JSON 數組。后續“生成單集臺本”的輸入就是分集大綱里的某一集。{ serie: 1, title: 發現股權被轉移, hook: 協議簽名日期是今天, scene: [林晚辦公室, 會議室], characters: [林晚, 對手, 助理] }定義好這種結構之后你可以任意替換模型、增加檢查步驟都不會把整個流程打亂。這是我從0.0.1版本測試里收獲最大的一點。6. 常見報錯和排查順序如果做到這里還是出了問題下面是我在實際測試中用的排查順序。6.1 任務卡住或中斷先看日志最后一行確定卡在哪個階段。常見原因接口超時短劇文本生成單次要輸出較長很容易超過默認超時時間。對策把單集臺本拆成“場景1、場景2”或者調大超時參數。輸出過長被截斷0.0.1版本沒有做文本續寫一旦截斷后面全部為空。對策限制單集字數或者做“自動續寫”。外部工具沒啟動如果Agent接了數據庫、文件服務先確認真的是否在運行。這里最忌諱直接重跑整個任務。先看卡在哪個環節再決定是補跑還是清緩存。6.2 輸出為空或重復輸出為空通常是解析失敗。模型返回了文本但Agent按JSON解析結果失敗。對策讓Agent在解析失敗時把原始文本存到fail/目錄并保留一條錯誤提示“格式不是JSON請人工查看”。輸出重復通常和溫度參數有關。溫度調太高模型容易發散調太低又容易重復。通用做法是先把 temperature 設到 0.7 左右TopP 0.9再根據結果微調。如果還是重復優先檢查是不是前情摘要寫得和當前集太接近而不是先改參數。6.3 角色名字和身份漂移漂移的解決不靠模型靠輸入結構。我在測試中加入了兩層保護全局角色卡每集生成時都帶上包含姓名、身份、口吻。每集約束字段在輸入JSON中明確本集出場角色、禁用行為。如果還有漂移懷疑是上下文被覆蓋。0.0.1版本在設計時可能把當前正在生成的內容放進了系統提示詞而系統提示詞長度有限就會把角色卡擠掉。排查時先看當前給模型的完整上下文是什么再決定怎么精簡。6.4 資源占用過高短劇Agent如果是本地運行主要資源消耗在模型加載和并發請求上。文本生成階段顯存占用不會像視頻生成那么高但長上下文和并發請求依然會拖慢機器。0.0.1版本建議先把并發降到1確認單任務內存占用穩定后再逐步加。如果CPU或內存一直居高不下先檢查是不是任務日志寫太多、文件句柄沒釋放或者把無用的大對象保存在內存里了。批量跑的時候每處理完一集就釋放一次上下文緩存。這不是優化技巧是0.0.1版本能穩定跑完的基礎前提。最后留個建議如果你是新手先拿3集短劇跑通整個鏈路別一上來就是20集。劇本生成只是Agent在短劇生產里的第一站后面還有配音、畫面、剪輯這些更硬的骨頭。0.0.1版本能告訴你這套流程走不走得通但要把短劇真正做成成品還得靠你在每個環節補上人工判斷和工程優化。