表情包生成指南

11月4日，OpenAI 發布了新一代圖像生成模型 Images 2.6，在對話框裡描述動作，Image 2.6 就能直接生成可循環播放的 GIF 動圖。對想製作角色表情包的人來說，值得關注的是，能否用自然語言描述動作，得到情緒清楚、角色穩定、適合反覆播放的動圖。

用一張角色圖製作六種動態表情，Image 2.6 能做到什麼程度？下面和arcloop一起來看看吧！以下結合六張原始 GIF 和逐格拆解觀察，看看提示詞怎麼寫、成品表現如何，以及還有哪些技巧可以補充。

Image 2.6 也已在 Arcloop 上線。想在 Arcloop 繼續創作，可以進入 Arcloop 創作工作臺，準備角色參考圖和動作描述。本文下方的 GIF 與參數來自 ChatGPT 實測。

1. 選定你想要生成的角色

在已開放 GIF 功能的 ChatGPT 中，可以上傳靜態圖，描述需要怎樣動。不必先學時間軸，但需要說清楚哪些可以變、哪些要保留。

我們這次的原圖是一位銀灰短發、金色眼睛的貓耳角色，穿藍橘圍裙，頭髮上有鈴鐺和橘色絲帶，尾巴位於畫面右側。製作時可以把這些特徵列為保留項，把表情、手勢和尾巴動作列為變化項。

這種區分會讓檢查更具體。手抬到臉前屬于動作變化；鈴鐺消失、圍裙換色，則可能偏離了保留角色的目標。固定機位與構圖也是可嘗試的約束，有助于把檢查重點放在動作上，但不能保證消除形變。檢查時也要分兩層，在同一張 GIF 內，角色有沒有隨動作變形；六張放在一起，是否仍像同一個角色。

如果還沒有整理角色的固定特徵，可以先參考 先做設定表，再寫提示詞，把外觀保留項寫清楚，再安排動作變化。

2. 怎麼寫情緒提示詞，效果怎麼樣？

**把情緒寫成看得見的動作，結果才有明確的評價標準。**這次製作目標是六張獨立 GIF，原始提示詞如下：

1. 害羞躲臉：耳朵向后，雙手遮住半張臉。
2. 生氣哈氣：鼓起臉頰，貓耳豎起，做出輕微威嚇。
3. 傲嬌哼一聲：抱臂偏頭，尾巴輕甩。
4. 送給你：雙手遞出一顆小愛心，眼睛亮起來。
5. 委屈大哭：眼角蓄淚，嘴巴撇下，肩膀輕顫。
6. 得意眨眼：雙手叉腰，單眼眨一下。

**害羞躲臉：耳朵向后，雙手遮住半張臉。**成品中雙手逐漸抬到嘴邊，耳朵壓低，臉頰泛紅。遮臉與神態配合起來，害羞比較容易辨認；手遮住面部時，也要留意手指和臉頰的邊界。

**生氣哈氣：鼓起臉頰，貓耳豎起，做出輕微威嚇。**成品主要通過皺眉、張嘴和雙手抬起的威嚇姿態表達生氣，鼓腮並不是最突出的部分。整體情緒成立，但不能把它等同于每個動作細節都精確執行。GIF 沒有聲音，哈氣要靠神態表達。

**傲嬌哼一聲：抱臂偏頭，尾巴輕甩。**抱臂、偏頭和閉眼的組合，讓態度比單獨偏頭更明確；畫面還加入了一小團氣息符號。若想要干凈的角色貼紙，可以在后續要求中排除這類額外符號。

**送給你：雙手遞出一顆小愛心，眼睛亮起來。**粉色愛心出現在掌心，雙手向前遞出，動作目標很清楚。不過，情緒峰值用了閉眼大笑，眼睛亮起來並非主要表現。遞出愛心的語義完成了，眼神演繹仍與原要求有區別。

**委屈大哭：眼角蓄淚，嘴巴撇下，肩膀輕顫。**淚眼、下垂的耳朵和嘴部變化能傳達委屈，肩膀附近也出現抖動線。這里提醒我們，情緒詞和動作要求要匹配：如果期待夸張大哭，僅寫蓄淚可能不足，需要進一步說明強度。

**得意眨眼：雙手叉腰，單眼眨一下。**叉腰和單眼閉合都能看到，微笑配合姿態傳達出得意。它的動作內容很簡潔，也更容易逐項檢查是否做到。

這組結果說明，具體手勢能幫助區分情緒，但模型仍可能用自己的方式演繹神態。后續可按“情緒＋面部變化＋一個主要動作＋結束姿勢”補充描述，一次集中修改一個偏差，不必把短表情寫成復雜劇情。

想把情緒進一步拆成眉毛、眼睛、嘴巴和頭部的變化，可以參考 動漫表情提示詞指南，再挑出適合這張角色圖的表達。

3. 如何提升動作銜接的自然度？

**先補齊回到起點的動作，再調整快慢。**逐格拆解可見，遞愛心的第一個影格雙手靠近胸前、沒有愛心，最後一個影格仍向前捧著愛心；眨眼的最後一個影格保持叉腰，第一個影格卻是雙手抬在肩旁。它們都能重復播放，但首尾狀態不相同，需要檢查重播瞬間是否跳變。

以遞愛心為例，可以嘗試補充下面這段要求：

開始時雙手在胸前捧著小愛心，緩緩向前遞出，微笑停留片刻，再沿原路收回胸前。結尾恢復開頭的手勢、愛心位置和表情，鏡頭與背景保持固定。

讓道具從開頭就存在，可以少處理一次愛心出現與消失的轉換。對于眨眼，也可以讓角色從頭到尾保持叉腰，只完成閉眼、睜眼的小循環。

如果只是節奏不合適，可以調整 ChatGPT 生成 GIF 的播放速度；如果中間缺動作、手部變形或首尾不同，變速不會自動修復這些問題。修改時優先簡化動作，再檢查回收階段。

4. 最長可以支持多少長度的GIF？

**這次用文中的遞愛心案例，我們實際生成了單輪 20 秒的 GIF，但它只有 16 影格，每張畫面停留 1.25 秒。**因此，我們建議把“能播放多長”和“動作是否連貫”分開判斷；這次測到了 20 秒，不等于已經找到了最長上限。

原來的六張 GIF 單輪約為 1.36–1.52 秒，每張 8 影格，並設置了無限循環。為了驗證更長的單輪時長，我們在 2026 年 11 月 6–7 日重新上傳同一張角色原圖，在 ChatGPT 中分別要求生成 2 秒、10 秒、20 秒的遞愛心 GIF。沿用前文的循環安排：雙手從胸前捧心，向前遞出，微笑停留，再收回胸前；保持正面半身、固定機位和白色背景，不加文字。

我們直接下載生成界面返回的 GIF，沒有在本地拼接、補影格或調速。下表的單輪時長是逐格讀取檔案中的停留時間后相加得到的，不是對著無限循環畫面計時。

三份檔案均為無限循環，每輪都能看到一次捧心、遞出和收回。10 秒目標實際少了 0.08 秒，我們保留這個差異，不把提示詞要求直接當作測量結果。

**2 秒版：動作緊湊，階段能交代清楚。**前兩影格在胸前捧心，第 3–5 影格遞出並微笑，第 6–8 影格收回。每幅畫面停留四分之一秒，仍能看出姿態之間的切換；首尾手勢接近，但不是完全相同的畫面，不能稱為已經實現無縫循環。

**10 秒版：過渡畫面變多，但更新速度變慢。**影格數從 8 增加到 16，遞出、停留、收回的階段更細；不過每個影格停留也增加到 0.62 秒。我們建議同時看這兩個變化，不要把影格數翻倍理解成播放更流暢。這一版還把頭髮上的鈴鐺和橘色絲帶移到了領口，角色細節沒有完整保留。

**20 秒版：時長達到了，畫面間的停頓也更明顯。**這一版與 10 秒版同樣是 16 影格，每個影格卻停留 1.25 秒；相比 10 秒版，增加的播放時間沒有換來更多動作畫面，觀看時更像依次展示關鍵姿勢。它是獨立生成的另一份檔案，並非我們把 10 秒版調慢。頭髮上的鈴鐺回到了畫面右側，但圍裙上的杯子圖案變成了爪印，服裝細節仍有偏差。

對于這次遞愛心表情，我們建議優先以 2 秒版的節奏繼續修正手勢和首尾銜接；如果需要更長的停留，可以再逐步調整，而不是直接把一輪拉到 20 秒。需要十幾秒內持續發生新動作的小故事時，我們建議考慮動畫或視頻流程，再決定是否轉成 GIF。

這次每檔只保留一份產出，在同一會話中依次請求；2 秒版提示詞較簡短，后兩版補充了角色保留項。我們沒有固定輸出尺寸和影格數，也沒有做重復抽樣，因此它是同案例的探索測評，不能將尺寸、服飾變化全部歸因于時長，更不能據此推斷成功率或統一時長上限。

5. 尺寸和背景

**這次實測中，把尺寸寫成 512×512 或 1024×1024，並沒有得到對應像素的檔案；白底、淺粉底和真正透明背景則都返回了可檢查的 GIF。**我們建議先核對下載檔案的實際尺寸，再看角色有沒有貼邊、背景是否符合用途，不要只憑提示詞或預覽大小判斷。

我們繼續使用文章中的貓耳角色原圖和遞愛心動作做了四組測試。共同要求為單輪 2 秒、8 影格、固定正面半身，從胸前捧心到遞出、停留、收回；保留鈴鐺、藍橘圍裙、杯子圖案和尾巴，並要求貓耳、手與尾巴完整留在畫內。A、B 只改變請求尺寸；C、D 則在 A 的基礎上改變背景要求。

四份檔案均為實際下載的 GIF，都是 8 影格、每個影格 250 毫秒、單輪 2 秒、無限循環，未做本地縮放、摳圖或重新編碼。表中的 KiB 按 1024 字節計算。

**尺寸要看實際像素，不能把請求值當成結果。**A、B 都沒有滿足指定尺寸，B 也沒有因為寫了 1024 就得到相應的大圖。這只能說明本次請求未兌現，不能把約 439 像素當作產品統一上限。我們建議用于大幅展示前先查看檔案屬性；如果實際像素不足，單純把預覽放大不能證明細節變多。

**構圖還要看完整個動作。**逐格檢查這四份檔案，貓耳、遞出的雙手和右側尾巴都能看到，沒有發現這些部位被畫框明顯截斷。但透明組的輪廓上緣距離畫框頂部只有 4 像素，右側最少留了 15 像素，說明“沒有裁掉”與“留有充分余量”仍有差別。我們建議先看耳尖和尾巴靠近邊緣的影格，再決定是否裁切；這份透明圖尤其不適合繼續收緊頂部。

為了檢查聊天表情的可辨性，我們還把 A 組的起始影格和遞出影格分別縮小顯示到 64 與 128 像素寬。64 像素下仍能辨認粉色愛心和遞出的姿勢，但眼神、手指和圍裙圖案更難分辨；128 像素下臉部變化更清楚。因此，我們建議以愛心和手勢能否讀懂為先，再決定是否需要更突出臉部。這里檢查的是縮小顯示效果，沒有測試聊天平臺發送后的壓縮。

**白底與淺粉底都生成出來了，但並非逐像素完全不變。**兩份白底結果整體接近白色，采樣區域並不都是純白色值；淺粉底也保留了與原圖接近的色調。淺粉組左上角 10×10 像素區域的 RGB 均值在各影格間有小幅變化，整體沒有變成另一種背景。我們建議按實際用途判斷：普通表情可以先看整體是否穩定；需要嚴絲合縫融入純白頁面時，還應檢查邊界是否顯出一塊近白底色。

**透明背景這次是真正實現了，但仍需檢查輪廓。**D 組的 8 影格每個影格都有透明像素，角落透明度為 0；放到白底與深色底上，角色以外的區域會透出承托底色，並非白底或畫出的棋盤格。作為對照，A、B、C 解碼后的畫面都沒有透明像素，即使檔案裡有透明索引，也不能據此把它們稱為透明背景。

在深淺底逐格拆解檢查中，頭髮、貓耳、手和尾巴能獨立顯示，沒有整塊白底殘留；透明組實際像素只呈現完全透明或完全不透明兩種狀態，沒有半透明過渡。我們建議使用前繼續放到目標頁面或聊天背景上檢查細發絲、耳尖和尾巴邊緣，不把“透明已生成”直接等同于“所有底色上邊緣都合格”。

我們保留了實際尺寸、背景、影格數和體積，但不能由此推斷成功率，也不能把透明組檔案較小當作透明背景必然更省空間的證據。本次沒有做裁切、減色或抽影格壓縮對照；如果要進一步減小體積，我們建議另存副本、每次只改一種設置，再重新檢查動作與輪廓。

6. 提示詞加入鏡頭切換能保持嗎？

**這次遞愛心實測中，鏡頭切換確實執行了，鈴鐺側別和同一顆愛心也大體保持住了；但切點正確，不等于構圖、動作接續和循環都合格。**我們建議把這幾項分開檢查，尤其留意近景有沒有裁掉要展示的動作，以及切回半身時是否跳過了收回過程。

我們繼續使用同一張角色原圖，新增三組白底 GIF：連續推近后拉回、一次切到近景、切到近景后再切回半身。三組都要求單輪 2 秒、8 影格，完成同一次胸前捧心、遞出、微笑停留、收回。第五部分 A 組的固定機位 GIF 作為已有參照；下面三份則是本輪實際生成並下載的原件，沒有在本地裁切、拼接或調速。

三份檔案每個影格均停留 250 毫秒，並設置了無限循環，表中的切點來自逐格檢查。

**第一組：推近和切鏡，實際看到的變化不同。**這一組中，變大的不只是向前伸出的手和愛心，頭部與上身也一起放大；第 6–8 影格又縮回半身。因此，我們能確認畫面出現了推近、拉回式的景別變化。與要求相比，近景停留到了第 5 影格，沒有從第 5 影格就明顯開始拉回；第 3–5 影格的耳尖也超出畫框。只有 8 影格，姿態之間仍能看出級差。

**第二組：一次切近景能執行，但循環邊界需要另作安排。**第 1–2 影格是半身，第 3 影格直接進入更大的正面近景；雙手仍托著同一顆粉色愛心，沒有發現切鏡后愛心消失、換手或重新出現。鈴鐺和橘絲帶也保持在畫面右側。

近景里的頭部與愛心大小仍有變化，沒有嚴格固定住構圖；第 4–5 影格愛心下緣被畫框截斷，耳尖也被裁切。第 8 影格仍是近景，重播時直接回到第 1 影格半身，會出現明顯的景別變化。這是本組刻意不安排返回鏡頭后的結果，不算沒有執行提示詞，卻說明它還不適合直接當作首尾自然銜接的循環表情。

**第三組：加入返回鏡頭后，仍要看動作有沒有被切掉。**這一組在第 2→3 影格切近景，又在第 6→7 影格切回半身，兩處都符合指定位置。返回后，鈴鐺仍在同一側，藍橘圍裙和杯子圖案重新可見；愛心一直由雙手托住，沒有出現另一顆愛心或額外一輪遞出。

問題出在回收的交代上：第 6 影格還是近景遞出狀態，第 7 影格切回半身時，愛心已經到了胸前。觀眾可以理解為“收回了”，卻沒有看到充分的回收過渡。第 8 影格的景別和捧心手勢已接近起點，比停在近景更便于安排循環，但這還不足以承諾無縫銜接；近景中愛心下緣與耳尖的裁切也仍然存在。

針對這次案例，我們建議先沿用固定機位，或者從第一組較小幅度的景別變化繼續調整。確實需要切鏡時，下一輪應把近景放松一點，讓愛心與雙手完整入畫；同時把返回切點前后的狀態寫得更明確，例如“近景結束時手已經開始回收，切回半身后繼續同一次回收，再到胸前”。

如果反覆生成仍無法交代回收動作，我們建議分別準備兩個鏡頭，再人工選擇動作相近的位置銜接。本次沒有測試這種剪輯方案，不能把它寫成已經解決問題。三組各只有一份產出、未固定隨機種子，結論僅適用于這次 2 秒、8 影格的樣本；這里確認的是畫面景別與動作狀態變化，沒有驗證三維攝像機運動，也沒有據此推斷其他鏡頭安排的成功率。

準備好自己的角色圖后，可以 打開 Arcloop 開始創作。先從一種表情和一個主要動作開始，再按本文的方法檢查角色細節、動作銜接和實際輸出檔案。