2026 AI 精靈圖產生器比較評測：同一個角色，實測 6 款工具

AI 預覽裡的角色看起來不錯，放進遊戲前卻可能還要處理不少問題：跑步開頭有一段站姿，攻擊到一半劍身消失，透明匯出保住了角色，卻改變了原本想要的像素畫風。

我們把同一張像素女劍士交給 AutoSprite、Ludo.ai、Spriteflow、PixelLab、Sprite AI 和 AnimGen，分別產生待機、原地跑和一次揮劍。其中四款工具還測試了同一張手繪風格的橙色機器人。PixelLab 和 Ludo 的 Forge Pixel 輸出更接近低解析度像素製作流程；機器人組則用來觀察幅度較大的動作，以及從產生結果中選取片段的空間。

本文作者是 AnimGen 團隊。首輪測試在 2026 年 10 月 17–18 日完成。修復輸入構圖問題後，我們於 10 月 20 日重新產生了 AnimGen 的三條女劍士動畫，跑動和攻擊使用了 Expand Canvas。影片中標出了這批新結果，其他工具沒有重測。原始輸出和失敗嘗試的費用都保留在測試記錄中。

本次比較評測覆蓋 30 個「角色 × 動作」測試項。最初的七款工具名單還包括 Retro Diffusion，但其評測用途條款是否適用於本次測試尚未確認，因此跳過，未參與評分。

用同一個角色測試，具體怎麼做

共同輸入是一張 96 × 139、16 個可見顏色的透明 PNG：女劍士朝右，呈三分之四側視，手持長劍。補充測試用的機器人是 1254 × 1254 的透明 PNG。兩張圖都是我們的自有素材，各工具均接受了分配給它的原圖，沒有另畫替代角色。

小圖中的劍已經很接近畫面邊緣，能不能留出動作空間會直接影響結果。AutoSprite 開啟了 Auto Padding；Ludo 的像素角色使用 Auto Margin 和 True Size。AnimGen 的 10 月 20 日複測中，待機採用自適應構圖，沒有開啟 Expand Canvas；跑動使用主體佔比 67% 的方形畫布；攻擊使用主體佔比 50% 的橫向畫布，並把角色放在偏左位置。這些構圖選擇也是工作流程的一部分，影片比較無法單獨歸因於模型品質。

動作、參數與嘗試次數

下面保留六條動作提示詞的英文原文。每條之後都附有固定要求：保持角色、鏡頭角度和朝右方向，固定鏡頭，讓完整角色留在畫面內。像素版本還要求保留同一把劍、像素風格和像素網格。

AutoSprite 的首次待機使用推薦的 Idle 預設，第二次機器人待機及其餘動作使用文字提示詞。Spriteflow 的 Pro Mode 中，提示詞增強開關處於開啟且無法修改的狀態；我們記錄了提交文字，但無法核對內部增強後的版本。PixelLab 的待機文字在編輯器輸入時少了一個冒號，其餘任務措辭保留。

最初規定每個任務最多嘗試兩次，也就是允許一次重試。大多數任務只產生了一次，AutoSprite 的機器人待機用了兩次，共形成 31 次基線產生記錄。隨後 AnimGen 做了五次額外構圖實驗，再加上 10 月 20 日的三次複測，完整記錄共 39 次嘗試。現在的主對比以標註日期的複測替換 AnimGen 原來的三條像素結果。各工具實際獲得的嘗試次數不同，讀者看到的是更新後的流程對比。

怎樣才算可用候選

我們保留的動畫需要滿足這些條件：能認出輸入角色，動作能看清，主要運動過程完整，透明影格可以在測試場景中播放。迴圈動作要能取出可重複的一輪；攻擊要包含出招和收招。允許保留輕微色邊或視角變化，但會在對應結果旁說明。武器斷裂、主要攻擊過程出畫的片段不選用。

結果分為 直接可用、整理後可用、未選用。角色一致性、動作、迴圈或收尾、邊緣這四項先看未經編輯的輸出；第五項記錄匯入和播放所需的準備工作。原始逐次記錄和 10 月 20 日複測記錄包含評分與挑選影格資訊，沒有再合成一個總冠軍分數。

全部 31 份基線輸出都在 macOS 上同一個本地 Godot 4.7.2 場景中播放，使用圖集轉接程式，並切換淺色和深色背景。拆出的 1,222 個來源影格與原始 RGBA 像素一致；20 個初始候選在整理後再次檢查。AnimGen 新增的三條原片及其三條選用版也通過了這個場景，291 個原始影格、85 個選用影格均保留源像素和時序。這裡使用的是我們自己的圖集匯入流程，沒有逐家驗證它們的原生引擎包。

AnimGen 新的劍類動作可以用作前刺，但沒有完成提示詞要求的橫斬。我們把它作為經挑選影格的攻擊候選展示，同時另算排除它之後的嚴格口徑成本。其他工具的三條邊界跑動案例也會標明，不直接當作完全符合要求。

把動畫放在一起看

對比影片使用相同背景，角色等比縮放到相近的視覺大小。各工具保留記錄下來的原始時序。合成影片的容器影格率為 60 FPS，只按需要重複源畫面，沒有產生額外運動影格。標記為 RAW 的區域展示未經編輯的完整輸出。AnimGen 的像素單元標記為「Oct 20 retest」，其他五家保留第一次產生結果。攻擊重播之間有帶標籤的停頓。

影片中的英文標籤沿用原始對比素材：RAW 為原始輸出，DIRECT 為直接使用，EDITED 為整理後使用，Oct 20 retest 為 10 月 20 日複測。

像素角色的待機、跑動和攻擊

這張輸入最難保留的是長劍。首輪六條攻擊中，沒有一條完整橫斬達到我們的選用要求。新的 AnimGen 片段經過裁剪後得到了一次可用前刺，劍身和收招都在畫面內。如果戰鬥設計必須使用橫斬，這組樣本仍未完成該任務。

「邊界候選」適合對動作要求較寬鬆的短步幅慢跑場景。Ludo 的像素跑動仍觸及邊界，PixelLab 的跑動在調速後也仍是小步慢跑。費用部分分別計算了納入和排除這些結果的情況。表裡被選中的動作，也不代表一定保留了像素網格。

手繪機器人與挑選影格後的變化

機器人不用保留細長劍身，四肢周圍也有更多空間。四款工具各自的三個動作都選出了候選，其中 AutoSprite 的待機採用第二次結果。Ludo 的機器人慢跑是第三個邊界案例。

機器人原始待機、原始跑動和整理後的跑動對比展示了另外兩項任務。機器人結果沿用 10 月 18 日的版本。可以根據動作表現和所需編輯判斷是否適合專案；這點樣本還不足以給出普遍的成功率排名。

各款工具做得怎麼樣

AutoSprite：先確認預設視角是否適合你的專案

AutoSprite 的操作流程裡，除了動作，還要選擇遊戲視角。官方產品介紹列出了橫版、等距視角、預設與自訂動作，以及參考影片和動作庫控制。本次使用的是 2D → Side-scroller → Turbo，搭配預設或自訂文字。動作參考和 3D 流程沒有測試，2D 產生的內部實現也未核實。

有了現成角色圖後，這個視角選擇會直接影響結果。原始機器人是三分之四視角，第一次 Idle 預設讓雙拳放下，變成放鬆站姿。第二次提交完整格鬥待機提示詞，其中明確要求保持輸入視角；拳頭保持抬起了，身體卻更接近純側面。兩名角色的跑動也都有視角變化，擷取較短迴圈後仍保留部分擺動。機器人原始待機和跑動裡可以看到這些差異。

如果正在做一個新的橫版遊戲原型，希望儘快得到側向角色和清楚的步態，這樣的結果可能很合適。AutoSprite 接受兩張原圖，輸出規則的透明 5 × 5 圖集，兩名角色都能選出較短的跑動迴圈。只要輸出視角符合專案需求，接下來就可以花較少的檔案整理時間，把它放進場景裡試用。

如果專案已有一套三分之四視角的角色動作，這種角度變化就可能增加返工。待機和跑動的軀幹朝向不同，切換狀態時會顯得不連貫；武器在畫面中的伸出方向、腳底落點，也要與現有素材一起檢查。本次跑動被選為動畫候選，能否接入已有動作集還要看視角是否匹配。要求保持原圖視角的專案，適合先檢查待機到跑動的切換——這批結果中，提示詞裡的固定視角要求沒有完全生效。這裡描述的是本次 Side-scroller 樣本，其他視角模式沒有測試。

兩次機器人待機和兩次解鎖都計入了成本。出拳結果重複了兩遍，選用第 3–12 影格後得到一次出拳和收拳。劍類攻擊主要是抬起再放下武器，沒有形成要求的揮斬。

Turbo 還把像素角色重新繪製成 256 × 256，帶有平滑明暗和混色。專案接受這種視覺變化時可以繼續使用，但它沒有保留原來的 96 × 139 像素網格。批次製作動作前，最好把視角和像素表現一起確認好。

Ludo.ai：像素尺寸控制明確，機器人出拳完整

Ludo 的 Forge Pixel / True Size 組合把女劍士保持在 96 × 139，透明邊緣清晰。待機仍能認出原角色；Hydra 產生的機器人出拳包含一次清楚的打擊和恢復防守，不需要另外擷取更短動作。

True Size 也保留了劍周圍有限的畫布空間。像素跑動的部分畫面碰到邊緣，攻擊中的手和劍刃則離開了畫面。機器人跑動更像小步慢跑，身體角度還有變化。我們將它加速 25% 後作為邊界候選保留。

免費匯出的每影格上都有浮水印。升級到 Indie 後，通過官方匯出入口重新下載已有結果，就拿到了無浮水印版本，無須重新產生。這與 Ludo 的精靈圖產生器文件描述一致。帶浮水印的原始檔案沒有進入視覺品質對比。

Spriteflow：站姿穩定，匯出時序明確

Spriteflow 的 Pro Mode 輸出 512 × 512 影格，manifest 中寫明 8 FPS。角色外觀和站姿總體穩定，下載包提供了重現播放所需的時序，無須靠預覽猜測。

機器人出拳在關閉 Loop 後仍重複了兩次，我們保留第 4–13 影格作為一次動作。跑動需要去掉前後站立段。像素跑動中能看到一些綠色殘留和腿部軟化細節；劍類攻擊則在右邊緣截掉了劍刃。這些問題在原始對比中保留可見。

像素輸入變成了更高解析度、明暗平滑的角色。專案適合手繪外觀時可以考慮這條流程；如果要與嚴格的低解析度像素素材放在一起，還需要進一步處理。

PixelLab：低解析度原生像素，可以繼續在專案裡編輯

如果接下來要在低解析度像素編輯器裡繼續製作，PixelLab 在這次測試中銜接最直接。v3 流程返回 96 × 139 影格，透明通道只有完全透明和不透明兩種值；除了 PNG 圖集，我們還保留了原生 Pixelorama 專案。測試使用官方編輯器的試用入口，單獨的 Creator 動畫頁面則顯示付費限制。v3 文件介紹了這個編輯器流程。

匯出在產生影格之前包含兩份輸入圖副本。去掉之後，待機剩下四影格，跑動剩下八影格。待機保留編輯器預設的 6 FPS，跑動改為 12 FPS。跑動仍是短步幅慢跑，因此留在邊界候選組。

劍刃的表現不如身體穩定。攻擊把劍抬到接近水平的位置後收回，揮斬幅度較弱，細節也有破損。要讓這條攻擊可用，僅刪除參考影格還不夠。產生顏色也超出了輸入的 16 色調色盤。

Sprite AI：輸出緊湊，這個樣本的武器細節沒保住

Sprite AI 返回八影格圖集，明確記錄每影格 125 ms，透明度為二值，整體保持緊湊的像素外觀。身體動作能看清，三條完整匯出都讓角色留在畫面內。

但待機、跑動和攻擊中的細劍刃均出現缺口，或變成不完整的線條。我們分別在淺色和深色背景上檢視過，確認並非淺色劍刃在白底上看不見。修復需要畫進影格內，因此這三條輸出都沒有選用。

檔案本身容易解析和播放，這個角色的武器細節卻沒達到本次視覺要求。我們沒有擴大角色樣本，也沒有追加嘗試去判斷這種情況出現的頻率。

AnimGen：連續的 24 FPS 動作，方便從長片段裡選出短動作

AnimGen 的機器人在連續的 24 FPS 動作中保持可辨認。先產生影片的流程提供了足夠影格數，可以選跑步迴圈，也可以刪除出拳停頓來調整節奏。我們選出了 15 影格跑動和 25 影格出拳，原始待機可以直接使用。

10 月 20 日的女劍士複測保留了白襯衣和可辨認的角色比例。跑動有交替邁步，劍身留在擴展後的方形畫布內，我們選出了一輪 12 影格迴圈。攻擊中的武器留在橫向畫布內，動作結束後回到準備姿勢；去掉長停頓後，得到更短的一次可用前刺。

它仍有一些取捨。前刺沒有遵循橫斬要求，手腳可見少量拖影和混色；從影片得到的大尺寸影格也沒有保留輸入像素網格。待機的構圖依然緊，跑動和攻擊則受益於事先為角色留出的活動空間。

在這組測試裡，AnimGen 更適合重視連續運動、需要從長片段中選擇影格段的情況。如果專案嚴格要求低解析度網格，就要另外檢查畫風。它目前不能從文字建立角色，也不產生成套協調的多方向檢視。角色動畫流程（英文）和精靈圖匯出指南介紹了提供圖片之後的製作步驟。

像素畫要分別檢查尺寸、邊緣和調色盤

Ludo 的像素流程和 PixelLab 保留了原始單影格尺寸。Sprite AI 使用 139 × 139 的方形影格，保持緊湊的像素外觀。我們測試的 AutoSprite、Spriteflow 和 AnimGen 模式則產生了更大、更平滑的版本。

尺寸一致不會自動鎖定調色盤，也無法阻止劍身變形。PixelLab 的新影格在本次測試中有 36–46 個可見顏色，輸入只有 16 個。Sprite AI 的影格約為 14–18 色，但劍刃仍然破損。顏色數量只作為輔助檢查資料，不直接代表動畫品質。

如果遊戲依賴固定像素網格，可以先以整數倍放大檢視劍、手和輪廓，再縮回遊戲尺寸觀察動作。最近鄰顯示能看清已有像素，但無法還原已經被高解析度重繪改變的網格。

挑選影格改善了什麼，又修不了什麼

整理後的對比保留每影格像素及原有順序，只選擇更短的區間。僅兩條做了調速：Ludo 機器人跑動加速到 1.25×，PixelLab 跑動從 6 改成 12 FPS。其餘片段，包括 10 月 20 日複測，都保留原始逐影格時長。

當有用的動作已經產生出來，挑選影格能改善節奏。但它補不回缺失的劍刃，也找不回發生在畫外的攻擊。因此那些片段仍未進入候選。完整挑選影格範圍和速度倍率記錄在媒體證據中。

本次沒有完整、可靠地計時所有人工編輯工作。雖然記錄了指令碼編碼耗時，但其中不包含審閱影格、選擇剪輯點和準備引擎場景的時間，因此不能據此判斷哪款工具最省人工。

AnimGen 複測：構圖、活動空間與攻擊節奏

最初的 AnimGen 跑動和攻擊截掉了角色或劍。排查發現，舊版輸入構圖流程在匹配模型尺寸時裁切了這張高窄圖片。修復後，我們使用原來的動作提示詞，將女劍士的三個動作各產生一次。複測還通過 Expand Canvas增加活動空間：跑動採用方形畫布、主體佔比 67%；攻擊採用橫向畫布、主體佔比 50%、水平位置 35%。

新跑動的 97 影格和新攻擊的 97 影格都留在畫面內。待機保留原圖較緊的構圖，靴子貼近底邊；僅僅觸及邊界，不能據此判斷肢體被截斷。

完整攻擊在出招前有等待，伸劍後又保持了接近一秒。我們選取 35–46 和 64–73 影格，保留進入攻擊的過渡、前刺及其拖尾、短暫停留和恢復準備姿勢。按匯出的原始毫秒時長相加，最終 22 影格為 0.916 秒。編輯過程中沒有修補或產生劍身像素。

原始攻擊對比和之前的畫布實驗記錄繼續保留。10 月 20 日這批消耗 108 點數，匯出沒有扣費；下方目前版本的成本採用這批結果。舊版的八次產生與構圖實驗只保留為歷史記錄，不計入新版本成本。其他工具沒有重測，因此不能用新結果宣稱各家在同等嘗試機會下的成功率。

得到一段可用動畫，實際消耗多少

不同平台的一點額度，價格相差很大。這裡統一按下方列出的入門月付套餐折算美元成本，假設套餐內額度能夠用完。表中是按套餐分攤的估算值，沒有把它寫成測試帳號已經支付的帳單金額；免費贈送、年付折扣和帳號專屬優惠不用於壓低主表的付費估算。

以 AnimGen 為例，Basic 是 $9.99 / 1,100 點數，新批次每次產生 36 點數，折算為 36 ÷ 1,100 × $9.99 ≈ $0.33，本次透明匯出為 0 點數。使用一次性 $4.99 / 500 點數包，同樣一次產生約合 $0.36。購買時仍需支付完整的套餐或點數包價格。詳見 AnimGen 定價。

單段選用動作成本 = 本次評測批次的淨產生與匯出消耗 × 對應套餐單價 ÷ 選用動作數。 每個任務最多計一個結果；有效批次內的失敗和重試仍然計入，例如 AutoSprite 的首次機器人待機。AnimGen 像素組只採用 10 月 20 日修復後的三次產生，舊版測試不納入，也沒有當作已退款。其他工具採用 10 月 17–18 日的批次。原始用量、排除項和公式可查美元費用計算記錄。

像素組：按美元比較

AnimGen 的 $0.33 包含選用的前刺變體；如果嚴格要求橫斬，則只保留兩個動作，折算為每段 $0.49。Ludo 像素組的用量來自報價估算，因為餘額介面沒有逐項顯示小數扣量。PixelLab 本次用掉七個試用產生額度，沒有付款；對應付費 v3 流程的額度消耗尚未核實，因此沒有給出付費單段價格。

AutoSprite 使用 Starter 的無限解鎖權益折算。我們實際購買的 $5 點數包同時限制點數和五次解鎖，不能只按 $5 除以 100 點數來計算。各家美元成本對應上文展示的實際尺寸、時序與動作，沒有把它們當成相同時長、相同像素數的輸出。

機器人組：按美元比較

這裡使用原機器人批次，包含 AutoSprite 的待機重試。計算使用未四捨五入的金額，本組總價和單段成本各自保留兩位小數。

折算用哪個套餐，實際需要先付多少錢

以下依據 10 月 16–20 日的價格來源。主表統一使用公開入門月付價，Spriteflow 採用標準價格，沒有混入我們帳號看到的專屬優惠。價格和額度可能變化，購買以結算頁為準。月訂閱會續費，標明的一次性包只需購買一次；估算不含稅費與人工編輯時間。

如果按 Spriteflow 當時的 $14.90 帳號優惠計算，每段選用像素動作約 $1.12，機器人動作約 $0.75。這個優惠單列，避免把一個帳號的折扣與其他平臺的公開價格混在一起。

如果購買 AnimGen 點數包後只做這三條動畫，剩餘點數不再使用，實際支出仍是 $4.99，不能只支付已消耗點數折算的約 $1.08。其他平臺的月付套餐也一樣，沒用完的額度會提高實際單段成本。做生產預算時，還要加上檢查結果、挑選影格、修細節和放進遊戲驗證所花的時間。

根據要做的素材選擇工具

如果要做還能繼續編輯的低解析度像素角色，可以先比較 PixelLab 的原生編輯器流程與 Ludo 的 Forge Pixel / True Size 輸出。儘早檢查細長武器，並為動作留出空間。重視緊湊輸出時，也可以用自己的角色試試 Sprite AI；本次女劍士的劍刃問題讓我們沒有選用它的結果。

如果手裡是需要較大動作幅度的手繪角色，可以看機器人組的影片。AutoSprite 用較短圖集給出了清楚的步態；Ludo 提供了完整的單次出拳；Spriteflow 的站姿穩定、時序明確；AnimGen 提供了連續的 24 FPS 動作，方便從中選擇更短片段。結合畫風和專案中需要繼續處理的工作量來縮小範圍。

如果需要多方向角色套圖，這次測試無法給出優勝者。PixelLab 的官方功能頁列出了四方向和八方向檢視，Ludo 也有獨立的多方向精靈圖流程，但本輪沒有測試。做好一張朝右輸入的動畫，並不代表已經驗證了八方向角色的一致性。

訂閱前，可以先拿自己的一個角色測試最難的動作。檢視下載影格、淺深兩種背景、原始時序，以及匯入遊戲後的表現。手繪素材可以通過 AnimGen 圖片轉動畫流程產生運動；已有動畫影格則可以交給免費精靈圖製作工具打包。Godot 匯入案例提供了一個用來檢查最終播放效果的小場景。