企业官网建设流程全解析

简介：面向 ComfyUI 平台上的 Wan2.2 模型，这套基于智能关键词驱动的图像超分与视频生成工作流配置，可为开发者与 AIGC 爱好者提供快速复现与二次开发的现成方案，尤其适合希望在本地环境验证图像增强与视频生成效果、对节点编排感兴趣的中高级用户。压缩包共包含 2 个文件，均为 JSON 格式的工作流定义文件，总大小约 23KB，体积轻量、导入便捷，可在 ComfyUI 中直接加载复用，适用于快速验证与效果调参。目前已有120人浏览学习，属于轻量实用的配置型资源。通过这两个 JSON 文件，用户可以直观了解 Wan2.2 在关键词引导下图像超分和视频生成的节点组织方式、参数设置与模块连接逻辑，有效缩短从零构建工作流的调试时间，也适合后续做二次开发参考与效果对比实验，对理解 ComfyUI 工作流的模块化设计亦有帮助，是上手 Wan2.2 系列工作流的参考样例。

1. 一键出片背后的真实链路：Wan2.2、关键词与超分谁在起作用

如果你手头只有一张糊得看不清细节的老照片，也想让它变成一段高清、能被人刷到的动态视频，那这个标题里的每个词都不是摆件。ComfyUI 是承载整套流程的工作台，Wan2.2 负责把静止帧推成可动可演的视频，图像超分则在两个环节暗中抬高清晰度上限，而“智能关键词驱动”听起来像是模型自己会读心——真正落地的做法，却是把提示词按模型的理解习惯拆成几段。这套组合最大的价值在于：老照片复活、商品动图、短视频素材这类需求，不必再等云端排队，本地一台 N 卡机器就能批量产出。适合谁？愿意为出片质量折腾节点、又不想被在线工具按秒收费的从业者。最大的劝退点也先讲清楚：显存不够时它确实能让你出片，但前提是先过内存爆炸这一关。

2. 从零搭 Wan2.2 生成链路：模型选型、放置路径与最小工作流

2.1 先定路线：I2V 还是 T2V，全精度还是 GGUF 量化

Wan2.2 这个系列里其实有两条完全不同的入口。T2V 是纯文本生成视频，输入只有一句话，适合没有参考图、只要“概念级”动态的场景；I2V 是图像生成视频，输入一张图加一句话，模型会尽量保住这张图的构图、颜色和主体身份，只在画面里引入运动。标题里写着“图像超分视频生成”，所以 I2V 是主线：你先有一张图，不管是老照片还是渲染图，让它动起来。T2V 在需要从零生成分镜素材时才值得切过去。

选完入口还要选权重精度。全精度 BF16 的 14B 权重质量最高，但加载就要接近 30GB 显存，大多数人的机器直接出局。社区最常见的做法是两条路：一是官方 FP8 版，质量和显存折中，适合 20GB 以上的卡；二是 GGUF 量化版，Q4 到 Q8 可选，配合量化加载器能把 14B 压进 12GB 甚至 8GB 显存。我的建议是别一上来追 14B，先把 5B 的 I2V 跑通出片，确认你的提示词习惯没问题，再决定要不要上更大的模型。

2.2 ComfyUI 环境与 Wan 模型放置：基础库版本第一坑

先说环境。如果你是第一次装 ComfyUI，秋叶整合包是目前最省事的底子，Python、PyTorch、CUDA 都给你配好了，装完直接能拉节点开干。但这里有个坑：整合包里的 ComfyUI 核心通常不是最新版，而 Wan2.2 依赖较新的模型加载逻辑和采样调度，所以拿到整合包的第一件事是把 ComfyUI 核心升到支持 Wan2.2 的版本，再装对应的 Wan 系列封装节点。

模型放置路径是第二个高频翻车点。Wan2.2 需要三类权重：扩散模型本体、文本编码器、VAE，三者不能混放。常见做法是分别放到 ComfyUI 的models/diffusion_models、models/text_encoders、models/vae目录下。GGUF 量化版有些封装要求放进models/unet，具体以你安装的节点包说明为准，但目录结构可以先搭好：

mkdir -p models/diffusion_models models/text_encoders models/vae huggingface-cli download <Wan2.2-I2V权重仓库> --local-dir models/wan2_2_i2v # 下载完成后，把对应的 safetensors / gguf 文件按类型复制到上面三个目录

这里有个我踩过的教训：下载后不核对文件就直接开跑，结果模型加载器报“找不到键值对”，折腾半天发现是权重文件本身没下完整，safetensors 损坏。huggingface-cli下载完先看一眼有没有.cache目录残留，或者直接对文件大小做一次核对，再复制过去。文本编码器尤其容易漏，Wan2.2 用的是 UMT5-XXL 级别的编码器，没有它提示词完全不进模型，生成出来的视频会跟提示词毫无关系。

2.3 最小 I2V 工作流的五个环节与关键参数

把节点图拆开看，Wan2.2 I2V 的生成链路可以压缩成五个环节：读入图片、编码提示词、模型加载与条件注入、采样、VAE 解码输出视频。ComfyUI 的封装版本不同，节点名字可能叫WanImageToVideo或社区改名的采样器节点，但逻辑是同一套。第一版工作流不需要任何花活，把下面这份配置对进去：

{ "load_model": { "type": "wan_i2v", "precision": "fp8" }, "prompt": "一位穿红色风衣的女人站在雨夜街头，发丝被风吹起", "negative_prompt": "模糊, 变形, 闪烁, 低质量", "resolution": { "width": 832, "height": 480 }, "frames": 81, "cfg": 5.0, "shift": 12.0, "steps": 20, "vae_decode": "tiled" }

这里的参数都不是随便填的。Wan2.2 的推荐起步分辨率是 832×480，也就是常见的 480p 横向画幅，长边和短边比例接近 16:9；直接拉高到 1080p 会让采样器跑得非常吃力，显存不够时最先爆的就是这一步。frames: 81是 Wan2.2 比较舒服的帧数，再往上走内存压力会非线性上涨。cfg: 5.0是我常用的起点，Wan 系模型对 CFG 很敏感，超过 6 会出现明显的过饱和和运动僵硬，低于 4 画面又容易失去控制。shift: 12.0是采样调度用的偏移量，社区默认值在 8 到 12 之间，分辨率越高 shift 要适当调大。最后，vae_decode: "tiled"是从第一版就该养成的习惯，Wan2.2 的视频 latent 解出来非常大，不分块解码很容易在最后一步爆显存。

2.4 第一次成片验证：先别急着调超分

跑通之后不要立刻去接超分流程，先确认生成本身是健康的。我的做法是生成一遍后打开输出视频，盯三个地方：主体是否保持了一致性，比如人脸不会中途变成另一个人；运动是否真实，风吹动头发应该是连续摆动而不是跳变；背景有没有闪烁。另外开一个终端跑nvidia-smi看峰值显存，这一步记录的数值就是后面加超分时的预算依据。

如果画面几乎不动，优先把cfg降到 4 到 4.5，同时把提示词里的动作动词写得更大胆。如果人物五官在运动过程中糊掉，先别怪超分，回头检查首帧图片本身是否清晰，Wan2.2 I2V 对首帧质量的依赖比很多视频模型更重。判断“跑通”的标准不是成功导出 mp4，而是你愿意把这段视频放进剪辑软件里当作可用素材。到这一步，再开始考虑关键词怎么写得更好，以及超分该插在哪一环。

3. 智能关键词驱动：把一句人话翻译成 Wan2.2 听得懂的提示词

3.1 关键词并不是“智能”的：它进入模型的是一条文本向量条件

“智能关键词驱动”这个说法容易让人产生错觉，以为随便写几个词模型就能自己脑补。实际上 Wan2.2 里的提示词要经过文本编码器转成向量，再通过注意力机制注入到采样过程里。它不读人话，它读的是向量分布。这也解释了为什么有些人写“神秘的、梦幻的、有氛围感的”这种抽象词组，生成出来的画面常常只有光晕没有实质动态——因为抽象形容词在文本向量空间里的对应区域太宽泛，模型不知道往哪个方向拉。

真正起作用的是动词和名词，尤其是带方向、幅度、速度的动作描述。模型生成视频时，运动信息主要来自提示词里动词短语与图像内容的交叉注意力激活。所以“智能”不是模型聪明，而是你的提示词符合它的读取规则。另外要明确一条边界：提示词只能影响 Wan2.2 的生成阶段，后面的超分网络是纯像素操作，不吃文本。想把“更多细节”写进提示词再期望超分模型照做，是行不通的。

3.2 五段式提示词模板：主体、动作、镜头、光照、画质

我习惯把 Wan2.2 的提示词拆成五段：主体描述、动作描述、镜头描述、光照环境、画质词。这个结构不是玄学，而是让文本编码器在每个语义维度上都能找到明确锚点。写成 Python 模板就是下面这个样子：

def build_wan_prompt(subject: str, motion: str, camera: str, lighting: str, quality: str = "电影级光影, 高细节, 8k") -> str: return f"{subject}, {motion}, {camera} shot, {lighting} lighting, {quality}" # 实例：老照片里的旗袍女子 prompt = build_wan_prompt( subject="一位穿青色旗袍的年轻女子站在老式理发店门口", motion="她抬起左手轻轻拨动耳边的碎发，眼神缓缓转向镜头", camera="镜头缓慢推进", lighting="午后暖阳透过木质窗棂洒落，灰尘在光柱中漂浮", quality="电影级光影, 高细节, 8k" )

注意画质词放在句尾，文本编码器对句末 token 的响应权重比较高，写“高细节、8k”这类词有助于让注意力往纹理细节方向偏移。motion这一段是整个模板的灵魂，动词密度要足够，比如“抬起”“拨动”“转向”就是三个连续动作；如果你只写“她很好看”，模型大概率给你一张静态图。

3.3 负面提示词与首尾帧：两条容易被忽略的输入通道

正面提示词写得好只算一半功夫，负面提示词在视频生成里承担着防崩坏的作用。Wan2.2 的常见负面词库我一般固定挂一组：模糊、变形、闪烁、鬼影、肢体错位、低质量。这里面“闪烁”对后续超分尤其重要，生成阶段就压制闪烁，比后期去闪省力得多。

另一个容易被忽略的是首尾帧控制。Wan2.2 原生 I2V 的输入是首帧图，它不会主动遵守你想要的“结尾画面”。如果你需要严格的终帧约束，社区常见的做法是把首帧和尾帧拼进同一张图里，用分隔线或构图切割让模型理解“左起右止”，或者改用支持首尾帧的封装节点。这里顺便提一句，LTX 2.3 这类模型原生就能吃首尾帧，如果项目需求是强约束的转场动画，两边的取舍并不一样。MiniMax 这类在线工具则是另一套策略，它的提示词长度上限更敏感，写三到五个动态短句往往比一整段抒情描述更有效。本地模型没有字数焦虑，但也别因此写成小作文，动作密度比字数重要。

3.4 三组提示词出片对比：抽象形容词 vs 具体动词

我自己固定 seed 跑过几种写法的对比，观感差异很明显，列出来供参考。

第一组的失败不是模型不行，而是提示词没有给出可执行的运动向量。第二组是大多数场景的稳妥起点。第三组在生成阶段就为后面的超分打了底：超分模型擅长放大已有细节，而不是凭空创造细节。生成阶段能得到更多高频纹理，超分后的观感会显著提升。所以提示词工程和超分不是两个孤立环节，关键词驱动要服务的对象不只是生成，还包括给超分留口粮。

4. 图像超分与视频生成的两种衔接路径：超在生成前，还是修在生成后

4.1 路径A：生成前放大首帧，锁定构图细节

第一种做法是在进入 Wan2.2 之前，先把首帧图超分放大，再让它生成视频。好处很明显：Wan2.2 I2V 会保留首帧的大量细节，首帧越清晰，生成视频的纹理基线就越高，人物脸部、服装花纹这类高频信息在运动过程中更不容易崩。这里有一个参数细节：不要把首帧超分到 4K 再塞给 Wan，模型生成的内部分辨率也有上限，推荐的做法是把首帧放大到与生成分辨率一致的尺寸，比如目标 832×480，原图 640×480 就放大 1.3 倍并做轻微裁剪，让输入符合模型的标准尺寸。

路径A的风险是首帧超分会“脑补”细节。超分模型会凭空生成一些原本不存在的纹理，比如把墙上的灰尘纹理画成裂纹。这些脑补出来的细节会被 Wan2.2 当作真实结构保留下来，生成出“假细节”的视频。所以路径A更适合原图质量本身就不错、只是尺寸偏小的情况；如果原图已经糊成一片，先做修复类超分再送生成，容易把错误固化。

4.2 路径B：生成后逐帧超分，可控但容易闪

第二种做法是先用 Wan2.2 生成一段普通分辨率视频，导出帧序列，再用超分模型逐帧放大，最后合成新视频。这是最直接的控制链路——超分发生在生成之后，Wan2.2 的输出是确定的，你可以反复调超分参数而不用重新跑生成。参考脚本如下：

import cv2, os, glob from realesrgan import RealESRGANer from basicsr.archs.rrdbnet_arch import RRDBNet # 构造 4x 超分模型，权重文件自己下载后放入 weights 目录 model = RRDBNet(num_in_ch=3, num_out_ch=3, num_feat=64, num_block=23, num_grow_ch=32, scale=4) upsampler = RealESRGANer( scale=4, model_path="weights/RealESRGAN_x4plus.pth", model=model, tile=256, # 每次只处理 256x256 的块，防止显存溢出 tile_pad=10, # 块与块之间的重叠像素，减少拼接痕迹 half=True, # 半精度推理，显存不够时改 False ) os.makedirs("hi_frames", exist_ok=True) for path in sorted(glob.glob("frames/*.png")): img = cv2.imread(path) out, _ = upsampler.enhance(img, outscale=2) # 放大 2 倍而非 4 倍 cv2.imwrite(f"hi_frames/{os.path.basename(path)}", out)

这个脚本里最关键的两个参数是tile和outscale。tile控制超分模型每次看到的画面块大小，如果不分块，一帧 1920×1080 的图直接送进去，8G 显存会立刻爆掉，这也是“comfyui生成视频时爆内存”在超分阶段最常见的表现。outscale=2是我常用的放大倍数：Wan2.2 输出的 832×480 已经不算低，放大 2 倍到 1664×960 足够大多数短视频平台使用，放大 4 倍不仅慢，还会把生成阶段的噪声一并放大。

帧序列处理完后，用 ffmpeg 合成视频并保持帧率一致：

ffmpeg -framerate 16 -i hi_frames/%04d.png -c:v libx264 -crf 18 -pix_fmt yuv420p output_sr.mp4

-framerate 16要和 Wan2.2 生成时的帧率对应，81 帧配 16fps 大约就是 5 秒；-crf 18是视觉无损的常见起点，再低只会增加文件体积。

4.3 帧间闪烁的两个实用对策：去闪滤镜与重叠块衔接

逐帧超分最大的敌人是时间闪烁：单帧画面都清晰，连起来看却像灯光在快速闪动。原因是超分模型是空间模型，处理每一帧时互相独立，同一块皮肤在不同帧里被放大出的纹理会有细微差异，人类视觉对时间维度的不连贯极其敏感。

对策一是对超分后的视频做轻量时域降噪，用 ffmpeg 的hqdn3d滤镜就能压掉大部分，不会明显降低清晰度：

ffmpeg -i output_sr.mp4 -vf hqdn3d=1.5:1.5:6:6 -c:v libx264 -crf 18 output_sr_temporal.mp4

这里面四个参数依次是亮度空间强度、色度空间强度、亮度时间强度、色度时间强度，时间强度 6 是压闪烁的主力。对策二是从源头减少闪烁：把 4.2 脚本里tile_pad从 10 加大到 20 甚至 30。相邻 tile 之间的重叠区域越大，超分模型对同一像素的推断就越趋于一致，但代价是计算量上升。两条路建议一起用，前者治本，后者治标。

4.4 超分模型选择建议：Real-ESRGAN、SwinIR 与 DAT 的取舍

我的习惯是视频帧超分直接用 Real-ESRGAN x4plus，动画内容切到 x4plus_anime。SwinIR 和 DAT 很少用于整段视频，因为逐帧处理的时间成本实在太高，除非是高端商业项目且原片深度不够。另外记住一点：超分模型没有时间一致性概念，凡是逐帧处理就一定有闪烁风险，这是模型结构决定的，不存在某个“不会闪”的模型。

5. ComfyUI/Wan2.2 视频生成爆内存的排查与规避

5.1 从 OOM 到黑屏：五条高频故障排查记录

现象一：加载模型时直接报CUDA out of memory，点了个Queue Prompt就崩。原因：Wan2.2 的全精度权重和文本编码器同时往显存里塞，14B BF16 权重加上 UMT5 编码器，起步就超过 20GB。解决：先换 GGUF 量化权重，Q8 比 BF16 省一半以上显存；还没到位就把 llama 类封装里的 offload 设置打开，让文本编码器在 CPU 上读取。优先级是量化权重优于 offload，因为 offload 开过头会拖慢整段生成。

现象二：采样过程中显存没爆，但系统内存持续上涨，最后卡死。原因：封装节点为了省显存，把部分模型层交换到了 CPU 内存，如果交换层数配置过大，CPU 端的内存就成了新瓶颈。解决：把blocks_to_swap的数值调小，只交换最重的几层，不要把所有层都丢给内存；同时确保系统内存至少 32GB，8GB 内存跑 Wan 是不现实的。

现象三：前面一切正常，到 VAE 解码阶段突然爆显存。原因：视频 latent 是一次性解码成整段画面，帧数越多，解码瞬间的显存峰值越高。解决：工作流里把普通VAEDecode节点换成VAEDecodeTiled，tile_size从 256 开始试，画面出现拼接缝隙就调大，出现 OOM 就调小。

现象四：生成完导出视频是全黑或纯绿画面。原因：多半是 VAE 权重与 Wan2.2 的主模型不匹配，尤其是拿 Wan2.1 或社区其他视频模型的 VAE 凑数，或者半精度推理下 VAE 数值溢出。解决：单独为 Wan2.2 建立模型目录，确认 VAE 文件来源与扩散模型一致；half选项优先关闭，让 VAE 用 FP32 解码，速度慢一点但稳。

现象五：逐帧超分时内存暴涨，甚至直接把系统资源吃满。原因：超分脚本或节点一次读入整张高分辨率图，且tile未设置或设为 0，默认不打块。解决：回到 4.2 的脚本，把tile设为 128 到 256，同时用cv2.imread读入后先降采样到合理尺寸再送进增强器，一次性不要处理超过 200 帧。

5.2 显存不够时先砍谁：显存预算表与滑窗续接思路

显存不够时，砍参数的顺序比参数本身更重要。我列一个常用预算表，按出片规模和显存做了对应，可以当成起步参考。

如果生成时 OOM，按这个顺序砍：先换更低位的量化精度，比如 Q8 换 Q4，这是掉画质最少的一步；再降分辨率，832×480 降到 768×432；然后降帧数，81 帧降到 49 帧；最后才动steps和cfg，因为这两个参数直接决定画面稳定度。顺序反过来的常见结果就是你砍了步数和 CFG，显存没省下来，画面反而先崩了。

长视频需求则是另一个坑。想直接生成 30 秒甚至更长的视频，一次性采样几乎必然爆内存。社区里像 comfyui-framepackwrapper 这类滑窗方案被反复讨论，核心思路是把长视频切成带重叠率的滑动窗口逐段生成，前一段的尾帧作为后一段的首帧条件，把内存峰值压在一个固定水平线上。这个思路同样适合 Wan2.2：把 81 帧切成长度 30 帧的小段，每段之间重叠 10 帧，重叠帧生成后手工或用节点做过渡融合。代价是运动连续性会略差，衔接处可能出现细微跳变，但总比 OOM 全军覆没好得多。“comfyui 无限生成视频”在本地实现的本质也是这个，没有人真正一次性采样几千帧。

6. 把单条视频变成稳定产线：参数化脚本、批量验证与质量检查

6.1 参数化批量出片：模板替换与固定 seed 的 AB 对比

单条出片跑顺之后，下一步是把工作流参数化。我把提示词模板拆成外部文件，用 Python 脚本批量替换动作段和光照段，每个参数组合固定同一个 seed，这样生成的差异完全来自提示词，而不是采样随机性。脚本很简单，核心就是模板字符串替换：

template = """一位{subject}，{motion}，{camera}，{lighting}，电影级光影, 高细节""" cases = [ {"subject": "穿风衣的女子", "motion": "发丝被风吹动", "camera": "中景", "lighting": "黄昏"}, {"subject": "穿风衣的女子", "motion": "转身看向镜头", "camera": "特写", "lighting": "雨夜"}, ] for i, c in enumerate(cases): prompt = template.format(**c) print(f"case_{i}: {prompt}") # 这里把 prompt 写入工作流的 JSON 模板，通过 ComfyUI API 提交

这里固定 seed 是关键，同一组提示词换 seed 出来的构图完全不同，不固定 seed 就没法做对照实验。我在批量预筛时永远一组一组跑，每组合适的提示词再换 3 个 seed 看稳定性，挑最不闪烁的一条进入后期。

6.2 成片质量检查：ffprobe 和缩略图墙一次看穿

超分后的视频在进剪辑之前，我会用两条命令把关。第一条是看参数有没有跑偏：

ffprobe -v error -select_streams v:0 -show_entries stream=width,height,r_frame_rate,duration -of csv=p=0 output_sr.mp4

正常输出像1664,960,16/1,5.06。如果帧率变成16/1.001这类带小数点的值，说明合成时的时间基没对齐。第二条是生成缩略图墙，把视频每隔 30 帧截一张图拼成网格，一次看遍全片：

ffmpeg -i output_sr.mp4 -vf "select='not(mod(n,30))',tile=4x5,scale=1920:-2" -frames:v 1 sheet.png

缩略图墙能直接暴露闪烁问题，尤其看同一物体的纹理在相邻切片里有没有忽亮忽暗；也能暴露超分块的边界，如果某个 tile 边缘有亮度跳变，就去把tile_pad调大。我自己跑这套流程，最深的体会是顺序不能乱：先跑通最小工作流，再调提示词，最后才叠超分。如果一上来就追求成品效果，同时动提示词和超分参数，翻车了你根本分不清问题出在生成阶段还是后期，只能从头排查。希望今天这些参数和思路能帮你少走一次弯路。

本文还有配套的精品资源，点击获取