MiniMaxH3 在 ComfyUI 里做人物替換最近的討論熱度確實很高。核心賣點不是傳統(tǒng)意義上的“換臉”而是動作遷移和角色替換一起做給定一段源視頻讓目標角色沿用原視頻的動作、走位和表演節(jié)奏重新生成一段新畫面。整套流程特別適合跳舞視頻轉(zhuǎn)繪、打戲翻拍和劇情名場面的角色替換。先說結(jié)論單人替換環(huán)境配好之后不算難多人替換和分鐘級長視頻轉(zhuǎn)繪才是真正卡人的地方。很多人第一次跑通單人物替換后會以為“多人替換就是復制粘貼”實際上一旦涉及兩個以上角色身份混淆、動作疊加、空間關(guān)系不穩(wěn)都會冒出來。下面按實際落地順序拆一遍先從最基礎(chǔ)的環(huán)境和模型準備說起。1. 先搞清楚 MiniMaxH3 角色替換工作流到底做了什么1.1 它解決的是“換角色不換動作”的問題傳統(tǒng)換臉方案通常只處理人臉區(qū)域動作、服裝、場景基本不變。MiniMaxH3 這類視頻生成模型不一樣它是在視頻生成框架里做角色替換輸入一段參考視頻再給一張目標角色的參考圖模型會把目標角色的外貌特征遷移到參考視頻的動作骨架和運動軌跡上。這意味著你可以讓一個完全不同的角色去跳同一支舞、打同一套動作、走同一段劇情。動作遷移和角色替換是兩條線又經(jīng)常耦合在一起。單純動作遷移可以不用指定角色單純角色替換可以不用參考視頻里的具體動作。但實際工作流里往往是兩條線一起跑所以很多人會遇到一個問題角色是換上了但動作也跟著變了或者動作保住了角色臉又崩了。這類工作流的實際價值不只是“換個人這么簡單”而是把“表演”本身保留下來。對想做二創(chuàng)、短視頻分鏡、游戲角色演示、虛擬主播內(nèi)容的人來說這個能力比單張圖的局部重繪有用得多。1.2 為什么這條工作流會在 ComfyUI 里火起來ComfyUI 的節(jié)點式編排天然適合把“模型加載、視頻輸入、提示詞控制、采樣、輸出保存”拆成一塊塊獨立組件。 MiniMaxH3 能被社區(qū)拿來搭建角色替換工作流主要原因有三個一是節(jié)點可復現(xiàn)。別人分享的工作流文件導入后只要環(huán)境一致結(jié)果基本能對齊。二是參數(shù)可調(diào)整。提示詞權(quán)重、參考圖強度、采樣步數(shù)、分辨率、時長都能逐項改方便針對不同視頻素材做調(diào)試。三是生態(tài)補齊得快。模型文件、自定義節(jié)點、示例工作流社區(qū)分享速度很快不需要從零寫代碼。但這也是坑的來源。ComfyUI 本身只是框架真正決定工作流能不能跑起來的是模型文件、自定義節(jié)點和依賴包。很多人導入工作流后看到那句“請安裝缺失的包以使用此工作流”就開始到處找包卻不先確認模型文件有沒有放對位置。2. 跑通之前先把環(huán)境、模型、工作流三件事排干凈2.1 確認你的機器能承載多重的任務(wù)MiniMaxH3 角色替換工作流最核心的硬件瓶頸是 GPU 顯存。如果你只是處理一段 5 秒到 10 秒的短視頻分辨率控制在 720p 左右批量數(shù)不開太大那么 8GB 到 12GB 顯存有希望跑通但速度會比較慢。處理 20 秒以上的長視頻或者分辨率拉到 1080p顯存很容易不夠用。如果機器顯存只有 6GB建議先把分辨率降到 512 或 640幀數(shù)也砍短先用小樣驗證流程。這里有一個容易被忽略的點顯存占用不只看模型體積還看“視頻長度 × 分辨率 × 批量數(shù)”。視頻越長單次要處理的幀越多顯存壓力越大分辨率越高特征圖越大同樣吃顯存批量數(shù)一旦大于 1顯存占用會成倍往上走。我的建議是第一次跑先用 2 秒到 3 秒的短片分辨率不要超過 640這樣能快速暴露環(huán)境問題而不是一上來就被 OOM 卡住。內(nèi)存建議 16GB 起步32GB 更穩(wěn)。磁盤空間需要預留模型文件加上 ComfyUI 本身的依賴幾十 GB 是常見的。如果你的磁盤剩余不足 50GB安裝前要先清理。2.2 安裝 ComfyUI整合包還是手動部署新手優(yōu)先考慮整合包省去很多依賴編譯的麻煩。社區(qū)流行的秋葉整合包之類好處是自帶 Python 環(huán)境、常用節(jié)點和啟動器鼠標點幾下就能啟動。有經(jīng)驗的人可以手動部署流程大致是安裝 Python、克隆 ComfyUI 倉庫、創(chuàng)建虛擬環(huán)境、安裝依賴、啟動。手動部署的好處是靈活不會被迫使用整合包預置的固定版本壞處是依賴沖突比較多尤其是不同自定義節(jié)點對 torch 版本要求不一致的時候。如果你之前已經(jīng)裝了 ComfyUI并且導入工作流時報缺失節(jié)點不要急著重裝整個 ComfyUI。先看缺失的是哪些節(jié)點再用 ComfyUI Manager 或者命令行補裝對應依賴。有一點要特別提醒整合包里自帶 Python 環(huán)境和依賴如果你同時有系統(tǒng)級 Python 或 Anaconda進入 ComfyUI 所在虛擬環(huán)境后再執(zhí)行 pip install避免裝錯環(huán)境。2.3 模型和自定義節(jié)點怎么放MiniMaxH3 工作流要正常運行至少需要三類文件文件類型常見放置位置作用MiniMaxH3 模型文件ComfyUI/models/checkpoints 或指定子目錄生成視頻時真正調(diào)用的核心模型文本編碼器/輔助模型ComfyUI/models/text_encoders 等處理提示詞和參考圖語義自定義節(jié)點ComfyUI/custom_nodes提供加載、采樣、輸出等節(jié)點能力具體路徑會因為工作流作者封裝方式不同而有差異不能一概而論。我建議導入工作流后先逐個雙擊節(jié)點看它引用的文件名和路徑前綴再對著目錄去檢查。這里最容易踩的坑是模型文件名對不上。明明下載了模型但工作流里寫死了另一個文件名加載時照樣報錯。處理方法很簡單把模型文件名改成工作流引用的名字或者用節(jié)點里新的文件選擇器重新指定。如果你下載的是別人打包好的“整合包級”工作流里面可能自帶模型文件路徑說明這時候先按說明放。沒有說明的話不要亂猜目錄。3. 單人替換先從最小樣例開始3.1 最小工作流的完整鏈路不要一上來就導入那種十幾個甚至幾十個節(jié)點的大工作流。建議先用最小鏈路跑通加載參考視頻、加載目標角色參考圖、加載 MiniMaxH3 模型、輸入提示詞、設(shè)置采樣參數(shù)、輸出視頻。大致節(jié)點順序如下具體節(jié)點名稱因工作流而異加載參考視頻 - 拆分/采樣視頻幀 加載目標角色參考圖 - 編碼圖像特征 加載 MiniMaxH3 模型 - 模型加載節(jié)點 提示詞輸入 - 文本編碼 采樣器 - 生成視頻幀 VAE 解碼 - 輸出視頻這套鏈路的核心思路是模型同時接收視頻幀、角色參考圖和文本提示詞然后在潛在空間里完成動作保留和角色替換。第一次跑的時候提示詞不要寫復雜。比如“保留參考視頻的動作和鏡頭運動將視頻中的人物替換為參考圖中的角色保持動作一致。”像“光影、氛圍、服裝質(zhì)感、背景細節(jié)”這類描述可以先不寫等主流程穩(wěn)定了再加。如果你下載的工作流里包含了“導演臺”“Skill”這類額外節(jié)點不要過分依賴它們。它們通常是幫你管理提示詞或角色描述用的不是核心生成鏈路的一部分。先跳過這些附加節(jié)點用最小鏈路拿到輸出再回頭看附加節(jié)點到底做了什么。3.2 核心參數(shù)怎么看同樣的工作流參數(shù)設(shè)置不同結(jié)果差距很大。下面列幾個最容易影響的參數(shù)給的是通用判斷口徑具體數(shù)值以你下載的工作流的默認值為準。參數(shù)影響建議分辨率越高質(zhì)量越好但顯存占用直線上升第一次用 512 或 640別直接上 1080視頻長度/幀數(shù)越長越難保持時序一致第一次控制在 2 到 3 秒批量數(shù)影響并行生成的片段數(shù)量默認 1先不要開大采樣步數(shù)越高細節(jié)越充分但速度越慢一般 20 到 30 步比較常見提示詞權(quán)重控制文本對生成結(jié)果的影響強度權(quán)重過高容易壓制參考視頻動作隨機種子控制生成隨機性固定種子便于復現(xiàn)和排錯很多人一上來就把分辨率拉滿然后遇到 OOM以為是模型跑不動。實際上不一定是顯存不夠而是“分辨率 × 批量數(shù) × 視頻長度”三個因素疊在一起導致的。先把這三個值降到最低能跑通再逐步往上加。3.3 跑通之后先驗收三件事輸出視頻拿到手之后不要只看“像不像”要看三點第一動作有沒有被保留。原視頻里的轉(zhuǎn)身、抬手、步伐、節(jié)奏是否一致。如果動作被改得面目全非說明參考視頻的控制力不夠或者提示詞里對動作的描述和目標角色參數(shù)沖突。第二角色是不是一致。角色臉部、發(fā)型、服裝在視頻不同幀里是否穩(wěn)定。如果同一個角色在不同幀里長相不一樣說明參考圖的約束不夠或者視頻長度太長導致時序漂移。第三幀間閃爍嚴不嚴重。背景和角色的邊緣有沒有高頻抖動。嚴重閃爍通常不是模型能力不行而是分辨率太低、視頻長度太長或者參考視頻本身畫質(zhì)不穩(wěn)定。如果三個標準都能過再進入動作遷移和多人場景。如果連單人替換都穩(wěn)不住先不要急著搞多人不然翻車之后你都不知道該改哪個參數(shù)。4. 動作遷移把一個人的動作完整搬給另一個角色4.1 動作遷移和單人替換的差別單人替換可以簡單理解成“用新角色重新演繹源視頻動作”而動作遷移更強調(diào)“動作本身是主角”。同一個角色替換工作流當你把提示詞從“替換人物”改成“保留動作、改變角色”時其實就已經(jīng)在做動作遷移了。兩者真正的差別在于控制重點替換角色主要靠參考圖的約束力遷移動作主要靠參考視頻的約束力。實操里經(jīng)常出現(xiàn)一種情況參考視頻里的人物動作被弱化了新角色做出來的動作像“情緒表演”而不是“原動作復現(xiàn)”。這時候優(yōu)先檢查參考視頻的處理方式。有些工作流會對視頻抽幀并把每一幀圖片傳入模型如果你導入的視頻幀率或分辨率太低模型根本看不清動作細節(jié)。4.2 輸入材料的處理源視頻、目標角色參考圖、提示詞源視頻不是越清晰越好而是“動作清晰”最好。一段背景亂、人物小、鏡頭狂抖的視頻模型提取動作特征的難度很高。我建議準備源視頻時先做一次簡單裁剪把人物放在畫面中心偏上的位置避免頻繁出畫去掉開頭結(jié)尾多余的黑場和字幕如果原視頻有攝像機大幅運動考慮先做穩(wěn)定處理同一段視頻不要反復轉(zhuǎn)碼盡量用原始畫質(zhì)目標角色參考圖同樣關(guān)鍵。參考圖要滿足正臉清晰、五官可見、光線均勻、背景簡單。不要用那種臉部被頭發(fā)遮擋、側(cè)面大角度、分辨率極低、濾鏡嚴重的圖。提示詞這塊我建議使用“動作描述 角色描述 畫面風格描述”三段式寫法。拿跳舞視頻舉例提示詞示例 保持參考視頻中的舞蹈動作和節(jié)奏。 角色外貌以參考圖為準臉部特征、發(fā)型、服裝保持一致。 畫面風格自然寫實光線和背景盡量接近原視頻。如果工作流里支持負面提示詞可以寫“角色面部扭曲、肢體不自然、閃爍、鬼影、兩個角色同時出現(xiàn)”這類描述。但負面提示詞權(quán)重不要一次拉得太高不然容易把整個畫面細節(jié)都壓掉。4.3 動作為什么會崩動作崩掉有好幾種表現(xiàn)成因不一樣。表現(xiàn)一動作幅度變小很多動作被“平滑”掉了。這種通常是因為參考視頻的幀率過低或者采樣步數(shù)不夠動作軌跡沒有完全被編碼。表現(xiàn)二動作整體保留但角色像“貼”在動作上看起來不自然。這可能是因為目標角色參考圖和源視頻中人物的體型、鏡頭視角相差太大模型無法把動作精確映射到新角色上。表現(xiàn)三動作做了幾秒之后開始漂移后半段角色偏離原視頻中的人物位置。這種大概率是視頻太長超出了模型穩(wěn)定生成的安全長度。先切短視頻分兩段處理。還有一個非常常見的低級錯誤參考視頻里的“人物動作”和“鏡頭運動”被混為一談。如果原視頻鏡頭快速平移或縮放模型可能把鏡頭運動當成動作的一部分導致新角色也跟著鏡頭做出一堆奇怪的小動作。遇到這種情況可以單獨寫一句“保持鏡頭運動不變?nèi)宋飫幼髋c參考視頻一致”。5. 多人場景第二式的核心難點為什么是“穩(wěn)住”5.1 多人替換會翻車的幾個典型原因單人替換的流程可以概括為“一個參考視頻 一個參考角色圖”。到了多人場景輸入就變成“一個參考視頻 多個不同角色參考圖”。問題在于模型需要同時區(qū)分不同人物的外貌特征、空間位置和動作分配難度不是翻一倍而是非線性上升。翻車表現(xiàn)最多的有三種第一身份混淆。兩個角色互相“串臉”A 的臉跑到 B 身上或者 AB 五官混合在一起。這說明工作流對多個參考角色沒有做足夠的錨定。第二動作疊加。A 的動作和 B 的動作互相“傳染”畫面里出現(xiàn)類似雙人同步動作的詭異效果。這是因為模型分不清哪段動作屬于哪個角色。第三空間關(guān)系不穩(wěn)。原視頻里 A 站在左邊、B 站在右邊替換后兩人位置漂移甚至交錯。這種通常需要顯式指定空間位置和人物相對關(guān)系。5.2 更穩(wěn)的做法逐個錨定即使工作流支持多人替換我也不建議一上來就同時替換三個人。更穩(wěn)的順序是第一次測試替換主角保留其他角色不變確認主角位置和動作穩(wěn)定。第二次測試再加入一個角色兩個角色參考圖分開提示詞里分別描述兩人的身份和位置。確認雙人穩(wěn)定后再逐步增加第三人、第四人。如果工作流支持“角色分節(jié)點”的設(shè)定讓每個角色單獨走一條參考圖分支那就盡量分開。不要把幾個角色的參考圖拼成一張大圖再傳進模型那樣模型很難分離不同特征。提示詞也要拆開寫優(yōu)先級從主角開始降序排列?？梢赃@樣組織第一角色參考左側(cè)參考圖位置在畫面左側(cè)負責主要動作。 第二角色參考右側(cè)參考圖位置在畫面右側(cè)動作保持與源視頻一致。 兩人始終保持相對位置不變不互相遮擋。這里的關(guān)鍵是“把角色的外貌、位置、動作分成三個維度來控”。有些工作流會把位置信息直接寫進節(jié)點參數(shù)里不需要靠提示詞有些則需要你通過區(qū)域控制節(jié)點來實現(xiàn)。具體怎么實現(xiàn)取決于工作流作者如何封裝。5.3 多人替換的驗收標準和參數(shù)微調(diào)方向多人替換的驗收標準要比單人替換多兩條每個角色各自的身份是否從頭到尾一致角色間的相對空間位置是否穩(wěn)定每個角色是否都保留了自己的動作有沒有發(fā)生“動作傳染”同一個鏡頭里是否出現(xiàn)重疊、穿模、鬼影如果角色互相“串臉”優(yōu)先檢查參考圖分支是否獨立提示詞里的角色描述有無歧義。如果動作疊加先降低提示詞總權(quán)重再把各個角色的動作描述寫得更具體。如果位置漂移看看工作流有沒有位置參數(shù)或區(qū)域控制節(jié)點把它顯式固定下來。多人替換里最常見的錯誤是一次性把所有角色參考圖都塞進同一個“參考圖像”輸入口。輸入口不是不能放多張圖而是模型需要明確區(qū)分“哪張圖對應哪個角色的什么位置”如果你的工作流沒有這個機制就等著翻車。6. 分鐘級長視頻轉(zhuǎn)繪跳舞、打戲和劇情名場面的實戰(zhàn)思路6.1 “分鐘級”真正的門檻不是模型而是顯存和一致性標題里提到的“分鐘級”轉(zhuǎn)繪很多人都理解成“讓模型直接生成一分鐘長視頻”。實際上單次直接生成一分鐘視頻對顯存的要求非常高大多數(shù)普通顯卡撐不住。更常見的做法是分段生成再把片段拼接起來。但分段生成會帶來一個新問題一致性。前一段視頻里角色穿的是紅衣服下一段生成時可能就變成了藍衣服。上一段里角色臉型偏瘦下一段里可能就偏圓了。這是因為每個片段都是獨立生成模型沒有“記住”上一段視頻里的中間狀態(tài)。解決思路有兩個層面一是工具層面。有些工作流會把前一幀或前幾幀作為下一段的輸入條件幫助模型延續(xù)上文。你下載的工作流如果帶有“首尾幀銜接”或“視頻延展”類節(jié)點優(yōu)先使用這類邏輯。二是素材層面。把原視頻切成片段后每個片段的首幀畫面盡量選在動作變化不大的位置不要在劇烈動作中間切。片段切換點越平滑拼接時越不容易出現(xiàn)跳變。6.2 分段轉(zhuǎn)繪與斷點續(xù)跑分段轉(zhuǎn)繪的具體順序可以這樣把原視頻按 5 秒到 10 秒切成片段每個片段保留 1 到 2 秒的重疊對每個片段獨立做角色替換或動作遷移檢查每個片段的角色身份、服裝、發(fā)型是否一致用剪輯工具把片段按時間順序拼接拼接處如果出現(xiàn)跳變用轉(zhuǎn)場或過渡節(jié)點輕微模糊處理如果你的顯卡顯存只有 8GB 左右單段視頻建議從 5 秒以內(nèi)開始嘗試。先看單段輸出是否穩(wěn)定再逐步增加單段時長。分段處理還有一個潛在好處便于斷點續(xù)跑。長視頻如果一次性處理中途 OOM 一次前面所有結(jié)果就全丟了。分段處理時每段輸出單獨命名哪一段失敗就重算哪一段不用整條重跑。輸出文件命名建議用“序號_片段起點_片段終點”的格式。比如clip_01_0000_0005.mp4這樣即使處理到第 8 段也不會因為文件名混亂不知道哪段是新的。6.3 跳舞、打戲、劇情名場面三類場景的差異三類場景看起來都是視頻實際難點的側(cè)重完全不一樣。跳舞視頻的主要難點是節(jié)奏和韻律。動作是連貫的一旦某個片段生成結(jié)果在拍點上偏了整個舞蹈看起來就不對。調(diào)參時更關(guān)注動作連續(xù)性參考視頻的幀率和運動軌跡質(zhì)量比畫質(zhì)更關(guān)鍵。打戲的難點是大幅度動作、快速位移和遮擋。拳頭、腿、刀劍這些運動物體容易出現(xiàn)模糊或殘影角色之間的遮擋關(guān)系也可能處理不好。遇到這類素材不要追求一步到位先把分辨率降下來跑通再逐段優(yōu)化。劇情名場面的難點是鏡頭多、景別多、角色多。一個鏡頭是近景下個鏡頭是全景再下個鏡頭可能切到背影。不同景別下角色的臉部特征、服裝細節(jié)要保持一致。處理劇情類素材時先整理一份“鏡頭清單”每個鏡頭單獨跑而不是把整段長視頻丟進去一次性生成。如果做的是“轉(zhuǎn)繪”而不是“實拍視頻角色替換”還要額外考慮畫風一致性。原視頻如果是動漫目標角色也應該是動漫畫風如果是寫實視頻就別用二次元參考圖。畫風差異太大時模型會試圖“融合”兩種風格結(jié)果就是既不寫實也不二次元。7. 報錯和現(xiàn)象排查先看日志再改參數(shù)7.1 最常見的一批問題根據(jù)社區(qū)里大量工作流分享的反饋下面幾類問題出現(xiàn)頻率最高缺包缺節(jié)點導入工作流后提示找不到某個自定義節(jié)點或 Python 包。這種問題一般在啟動 ComfyUI 時會在控制臺打出缺失列表。補裝之后重啟再重新加載工作流。模型文件路徑或名稱錯誤節(jié)點顯示紅色提示找不到某個模型文件。雙擊節(jié)點看引用的具體路徑再到對應目錄核對文件名。顯存不足 OOM采樣過程中直接報 CUDA out of memory。先降低分辨率、減少幀數(shù)、把批處理數(shù)改為 1再看是否還有問題。輸出黑屏或純靜態(tài)幀生成出的視頻是黑屏或者只有一幀畫面在動。先檢查輸入視頻有沒有正確傳到模型節(jié)點再檢查 VAE 解碼和輸出節(jié)點路徑。速度極慢單次生成耗時很長。先看分辨率、步數(shù)、批量數(shù)再看是否在同一個工作流里加載了多個大模型很多工作流會把不必要的模型一起加載。7.2 排查鏈路遇到問題時我建議按這個順序排查不要一上來就改模型參數(shù)。順序檢查對象看什么1現(xiàn)象是報錯、卡住、輸出黑屏還是輸出質(zhì)量差2輸入視頻幀率、分辨率、格式、路徑參考圖是否清晰3環(huán)境依賴版本、模型文件是否齊全、顯存和內(nèi)存占用4參數(shù)分辨率、批量數(shù)、視頻長度、采樣步數(shù)、提示詞權(quán)重5工作流本身節(jié)點連線是否正確、是否有冗余節(jié)點、版本是否匹配這個順序的核心邏輯是先用成本最低的方式排除大概率問題再進入耗時較高的參數(shù)調(diào)試。7.3 輸出不理想的調(diào)整順序如果輸出視頻能生成但效果不滿意不建議同時改所有參數(shù)。一次只改一個變量然后對比前后輸出。按個人經(jīng)驗優(yōu)先調(diào)整順序是第一先確認輸入。原視頻動作是否清晰、參考圖是否規(guī)范。很多效果差是輸入材料本身不合格不是模型參數(shù)問題。第二再改提示詞。把角色外貌、動作、鏡頭、風格拆成四條分別調(diào)整權(quán)重。第三改采樣步數(shù)和分辨率。步數(shù)從 20 往 30 加分辨率從 640 往 768 加看畫質(zhì)是否有明顯提升。第四調(diào)整視頻長度。如果 8 秒以上的片段開始出現(xiàn)漂移果斷切成 5 秒一段。如果所有參數(shù)都試過后還是不理想就要考慮工作流版本或模型文件是否匹配。有些工作流是針對某個 MiniMaxH3 版本做的換了模型文件后行為差異很大這個很難通過調(diào)參解決只能換回匹配版本。8. 真正落地時最該盯住的是資源占用和失敗重試跑了幾輪之后會發(fā)現(xiàn)MiniMaxH3 角色替換工作流最核心的競爭力確實是“動作遷移 角色替換”的組合能力但真正要做生產(chǎn)化使用單條跑通只是第一步。如果你只是個人學習默認參數(shù)、短片段、單人物替換已經(jīng)夠用。如果你是想處理批量視頻或者想把工作流接到更穩(wěn)定的流程里需要額外考慮幾件事。第一日志要有時間、片段號和輸出文件路徑。一次批量轉(zhuǎn)繪十幾個片段時沒有日志根本不知道哪段卡住了。第二輸出命名必須規(guī)則化。不要用默認的 timestamp 文件名否則失敗重試時很難判斷新舊文件。第三任務(wù)隊列要提前規(guī)劃。不要用人工盯屏的方式處理長視頻分段任務(wù)最好通過隊列依次執(zhí)行減少顯存釋放不干凈導致的資源浪費。另外批量處理時不要把所有任務(wù)一次性丟進去跑。之前我試過連續(xù)跑 10 段視頻前三段正常第四段開始幀率變化、角色漂移。不是模型壞了而是連續(xù)高強度計算后顯存溫度升高、資源沒有完全釋放。我建議每處理 5 到 6 段后重啟一次 ComfyUI或者至少清空一次模型緩存再繼續(xù)下一批。踩過幾次坑之后我的體感是很多問題不是 MiniMaxH3 本身能力不夠而是輸入材料和前置環(huán)境沒有處理干凈。你給它一段動作不清晰的參考視頻它只能還你一段動作混亂的輸出你給它一張臉部模糊的角色參考圖它能生成的也就只有模糊的角色臉。先把輸入質(zhì)量提上來參數(shù)調(diào)試才有意義。如果你正準備入坑這套工作流我的建議是先不要看那些幾十個節(jié)點、一堆附加功能的“全能大工作流”從最小可運行鏈路開始跑通單人短片段再加動作遷移再嘗試多人最后才挑戰(zhàn)分鐘級長視頻。每一步都確認穩(wěn)定了再往下一層走。這樣看起來慢反而是到最終目標最快的路。