表情包生成指南

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 开始创作。先从一种表情和一个主要动作开始，再按本文的方法检查角色细节、动作衔接和实际输出文件。