企业官网建设流程全解析

第一次在消费级显卡上尝试本地动画生成时，很多人都会遇到一个门槛：好不容易把 ComfyUI 搭好，模型也放进去了，结果一跑就爆显存，或者出图速度慢到让人怀疑视频渲染本来就该等几个小时。最近社区里讨论度很高的 MiniMax H3 同样绕不开这个话题。

好消息是，针对 MiniMax H3 的整合包、加速插件和低显存优化方案已经开始出现。8G 显存不再只是“能加载模型”，而是可以比较流畅地跑动画生成流程。这篇文章会从概念讲起，带你把一键整合包部署起来，配置加速插件，并且解决低显存显卡最容易遇到的报错问题。无论你是第一次接触 ComfyUI 的新手，还是已经玩了很久 ComfyUI 但被显存卡住的老手，都能从里面找到能直接照做的内容。

文章不会只贴命令，还会解释每个步骤的意义，帮助你建立自己的判断力，而不是换个环境就不知道怎么改。

1. MiniMax H3 是什么，为什么本地部署值得关注

1.1 动画生成场景下的 MiniMax H3

MiniMax H3 本身是一个频繁出现在社区讨论中的模型代称。在动画生成场景里，它通常和 ComfyUI 工作流绑定在一起，用于把文本提示词、图像参考或镜头脚本转换成连续的动画序列。

你可以把它理解成一套“导演+分镜”能力：先告诉模型“画面里有什么、主体怎么运动、镜头怎么推拉”，模型再根据提示词生成多帧内容。和传统关键帧动画不同，这种方式更适合快速验证创意，比如广告动画分镜、短视频素材预演、角色动作概念展示。

不过，这种灵活性的代价是计算量很大。动画和单张图片不同，图片生成只需要处理一张图的空间特征，而动画要同时处理多帧内容，还要尽量保证前后帧的一致性。显存需求往往会成倍增加。这也是为什么很多用户第一次看到模型文件时，会误以为“只要能加载进 16G 显存就能跑”，实际运行起来却发现连中间过程的临时数据都能把显存占满。

1.2 一键整合包、加速插件和低显存方案各自解决什么问题

先做一个简单的概念区分，后面读文章会轻松很多：

• MiniMax H3 模型：负责生成内容的权重文件，决定动画质量和风格。
• ComfyUI：节点式图形界面，用来调度模型、VAE、采样器、提示词等模块。
• 一键整合包：把 Python 环境、ComfyUI、依赖库、模型文件、启动脚本、常用插件打包在一起的发行版，目的是让使用者不用手动折腾环境。
• 加速插件：针对模型推理过程做优化，例如缓存复用、显存调度调整、算子融合等，目标是减少单次生成耗时，而不是改变画面质量。
• 低显存方案：通过量化权重、分段加载、降低中间精度、控制单批生成数量等方式，让 8G 显存也能完成更长的动画生成任务。

这篇文章里提到的加速插件，指模型推理层面的优化，和“网络下载加速”没关系。稍后在常见问题部分，我会说明下载依赖很慢时怎么办。

1.3 适合哪些读者

如果你是以下三类人，这篇教程会比较有用：

• 对 AI 动画生成感兴趣，但只有 RTX 4060、RTX 3060 这类 8G 显存显卡。
• 已经在使用 ComfyUI，但始终无法在低显存条件下流畅运行 MiniMax H3 相关流程。
• 想优化动画生成耗时，希望把单次等待时间从“几分钟一帧”压缩到“几分钟一段”。

阅读本文不需要你把模型原理吃透，也不涉及训练环节。你只需要具备基本的 Windows 操作能力，会解压压缩包，能运行一个 bat 脚本，就能跟上后面的步骤。

2. 环境准备与版本说明

2.1 硬件建议

教程默认使用 Windows + NVIDIA 显卡，因为 MiniMax H3 的动画生成流程在 CUDA 环境下兼容性最稳定。

显卡显存建议不低于 8G。8G 显存可以跑，但需要在启动参数、模型精度和工作流设计上做一些取舍。如果你有 12G、16G 甚至更高显存，操作会更从容，但下面的加速插件和低显存模式同样适用。

内存方面建议至少 16G，32G 更好。很多人只盯着显存，却忽略了内存。实际上，模型在加载阶段会先把权重读入内存，再逐渐搬到显存，内存不够时会形成大量换页操作，导致启动速度变得很慢。

磁盘方面，整合包解压后通常需要几十 GB 的空间，模型文件也可能继续占用不少空间。不要只给 C 盘留 10G 就动手，建议预留足够空间，并使用 SSD。

2.2 软件与驱动

需要准备的内容包括：

• Windows 10 或 Windows 11。
• NVIDIA 显卡驱动，建议保持在一个比较新的版本，但不需要追最新测试版。
• 浏览器，用于访问 ComfyUI 的 Web 界面。
• 解压软件，例如 7-Zip。
• 如果之后要自己用 git 安装插件，可以安装一个 Git for Windows。

不需要手动安装 Python。绝大多数一键整合包都会内置独立 Python 环境，避免与系统全局 Python 冲突。手动安装 Python 反而可能让启动脚本找错解释器，所以我建议先跟着整合包走，不要额外折腾。

版本说明要提醒你：ComfyUI 和各类插件的更新速度非常快，本文示例整合包目录结构以常见封装方式为例，具体版本要按你下载的整合包 README 为准。不要盲目照搬别人的启动参数，因为同一个模型在不同整合包里可能会有不同封装形式。

2.3 目录和路径规范

先记住一个原则：安装目录不要出现中文、空格和特殊符号。

这一点非常重要。ComfyUI 内部会调用很多 Python 脚本，Python 在处理中文路径时常出现编码问题。问题现象通常非常奇怪，可能是 VAE 加载不了，也可能是节点报错找不到模型文件，但原因其实只是路径里有一个“新文件夹（2）”。

建议把整合包放在一个简洁路径下，例如D:\ComfyUI_MiniMaxH3_8G。后面所有命令示例都基于这个路径，如果你的路径不同，需要同步修改。

3. MiniMax H3 一键整合包部署与启动

3.1 下载与安全校验

一键整合包通常不会只包含 ComfyUI，它还会把 MiniMax H3 运行所需的模型权重、VAE 文件、示例工作流、启动脚本和部分自定义节点打进去。这意味着解压后基本可以直接运行，用户体验比从零安装好很多。

但正因为模型权重体积不小，你在下载时要注意两点：

1. 尽量从模型作者、插件作者或整合包发布者认可渠道获取文件，避免下载到被改动过的模型权重。
2. 如果发布者给出了 SHA256 或 MD5 校验值，建议校验后再使用。

校验文件在 Windows 上可以通过 PowerShell 完成。打开 PowerShell，进入文件所在目录，执行：

Get-FileHash .\MiniMaxH3_整合包.zip -Algorithm SHA256

把输出的哈希值和发布者提供的值对比，一致说明文件完整。

下载过程中如果速度很慢，可以看看发布页面是否提供了国内镜像网盘。不要轻易使用来路不明的“高速下载工具”，很多工具会捆绑额外软件，甚至篡改下载内容。

3.2 解压后理解目录结构

解压完成后，先不要急着双击运行。先打开目录看一眼，常见的整合包结构大致如下：

ComfyUI_MiniMaxH3_8G ├─ ComfyUI │ ├─ custom_nodes // 自定义节点插件目录 │ ├─ models // 模型权重目录 │ │ ├─ vae // VAE 文件 │ │ ├─ diffusion_models // 主模型文件 │ │ └─ ... │ ├─ user // 用户工作流和配置 │ └─ main.py // ComfyUI 主程序入口 ├─ python_embeded // 内置 Python 环境 ├─ 启动ComfyUI.bat └─ README.txt

不同整合包的目录可能有差异，比如有的把模型单独放在models/checkpoints，有的放在models/diffusion_models。不要死记路径，打开 README 确认。

图示中的python_embeded是整合包内置的 Python，不要去系统 Python 环境里安装依赖。启动脚本运行时，会自动选择内置 Python。

3.3 第一次启动

启动整包含最简单的方式是双击启动ComfyUI.bat。如果这个脚本不存在，或者你想手动启动，可以按下面的思路创建一个启动脚本。

在整合包根目录新建start_8g.bat，内容如下：

@echo off cd /d %~dp0ComfyUI ..\python_embeded\python.exe main.py --lowvram --auto-launch pause

这个脚本做了三件事：

1. 切换到ComfyUI目录。
2. 使用整合包内置 Python 运行main.py，并开启--lowvram低显存模式。
3. 通过--auto-launch自动打开浏览器。

如果你的整合包结构不是这样，请以解压目录中的实际启动脚本为准。部分整合包会在启动脚本里加入--windows-standalone-build，这是为了兼容没有单独安装 CUDA 运行时的环境，保留即可。

双击运行后，控制台会滚动输出各种日志。看到类似下面的内容，说明启动成功：

Starting server To see the GUI go to: http://127.0.0.1:8188

浏览器会自动打开 ComfyUI 界面。如果浏览器没有打开，也不用担心，手动访问http://127.0.0.1:8188即可。

3.4 确认模型与插件已经加载

打开 ComfyUI 后，不要急着执行工作流。先看控制台日志中是否有报错，例如“Cannot import module”“No module named xxx”。如果出现这类错误，通常说明某个自定义节点缺少依赖。

再进入到模型目录确认 MiniMax H3 模型和 VAE 文件是否完整。只听别人说“整合包里什么都准备好了”是不够的，实际检查一遍能省下很多排查时间。

你可以在 ComfyUI 界面中新建一个“Load Checkpoint”之类的节点（具体节点名取决于整合包工作流），打开模型下拉框，看看里面是否有 MiniMax H3 相关模型。如果能看到模型和 VAE，说明模型路径正常。如果没有，需要检查模型文件是否被放在了正确目录中。

4. 接入首个 MiniMax H3 推理加速插件

4.1 加速插件到底做了哪些事情

动画生成耗时往往体现在几个环节：文本条件编码、多次采样迭代、VAE 解码、帧序列重建。MiniMax H3 刚出现时，很多工作流是按照通用节点流程搭建的，中间会有大量不必要的重复计算，低显存显卡还会频繁把中间结果从显存搬到内存再搬回来，时间消耗非常大。

推理加速插件的核心思路通常包括：

• 缓存复用：如果提示词中的某个模块没有变化，就把中间结果缓存起来，避免每次采样都重复计算。
• 显存调度优化：根据当前可用显存自动卸载不参与计算的模型片段，需要时再重新加载。
• 采样步数优化：在不明显影响质量的前提下，减少无效采样步数。
• 精度控制：在允许范围内使用半精度或混合精度运算，降低显存占用并提升计算速度。

因此，所谓“加速插件”并不是让显卡本身变快，而是让工作流少做无用功、更聪明地使用显存。

4.2 安装推理加速插件

如果你的整合包里已经预置了加速插件，可以跳过安装步骤，直接进入配置阶段。如果没有，需要先安装。

插件的安装方式通常有两种。

方式一：通过 git clone 安装。打开命令行，进入ComfyUI/custom_nodes目录，然后把插件仓库克隆到本地：

cd /d D:\ComfyUI_MiniMaxH3_8G\ComfyUI\custom_nodes git clone https://github.com/这里替换为插件作者仓库/加速插件仓库名.git

命令中的仓库地址只是一个占位示例，实际地址要替换成插件发布页面中的地址。不要因为我这里写了一串链接就当成标准地址。

方式二：手动下载压缩包。进入插件仓库页面，点击 Code -> Download ZIP，解压后把整个文件夹移动到custom_nodes目录。

安装完成后，一个容易忽视的问题是：插件文件夹名必须符合规范，不要改成中文名，否则 Python 导入模块时可能找不到包。通常建议保留仓库原始文件夹名，或者按 README 说明重命名。

4.3 让提速效果真正生效

安装插件后，需要重启 ComfyUI，让它重新扫描custom_nodes目录。重启后，观察控制台日志，确认插件已经成功导入。

启用推理加速插件时，要注意几点：

1. 并不是启用插件就自动生效，很多加速插件要求你在工作流中替换某个节点，或者在节点参数里勾选“enable acceleration”。
2. 一些插件会要求在生成前执行一次预热（warmup），把常用算子提前编译好。第一次运行可能比平时还慢，这是正常现象，第二次会明显加快。
3. 如果同时启用多个加速插件，不一定能叠加提速，反而可能因为底层算子冲突导致报错。建议先单独测试每个插件，确认稳定后再考虑组合使用。

社区中关于 MiniMax H3 的讨论里，比较常见的参考结论是：加速插件可以让单段动画的生成耗时从 500s 量级降到 200s 量级。但这个数据会受到显卡型号、显存大小、采样步数、视频帧数、提示词复杂度等多方面影响，不要把它理解成绝对参数。你只需要记录自己加速前后的实际耗时，对比纵向数据即可。

4.4 如何判断提速效果

在 ComfyUI 控制台或前端页面里，通常会显示每一步采样的耗时，以及队列执行总耗时。更准确的做法是使用显卡监控工具。

打开一个新的命令行窗口，执行：

nvidia-smi

这条命令可以查看当前显卡占用、显存使用量和 GPU 利用率。执行：

nvidia-smi -l 2

可以每 2 秒刷新一次监控信息，方便你在生成过程中实时观察显存峰值。

对比测试时，建议固定同一个工作流、同一次提示词、同一个随机种子。只改变“是否启用加速插件”这一个变量，生成两次。记录两次耗时和显存峰值，就能得到相对可靠的结论。

5. 8G 显存下流畅跑 MiniMax H3 的实战流程

5.1 选择合适的工作流

不要从零搭建工作流，直接使用整合包提供的 MiniMax H3 示例工作流是最快的办法。

示例工作流通常已经配置好了模型加载节点、VAE 节点、文本编码器、采样器和输出节点。你只需要重点关注 3 个位置：

• 模型加载节点：确认选择的是 MiniMax H3 模型，而不是其他模型。
• VAE 节点：确认 VAE 文件被正确加载。
• 最终输出节点：确认输出格式是动画序列，还是单帧图像。

如果你下载的工作流是用旧版 ComfyUI 保存的，打开时可能会出现节点缺失或连线断裂。这时不要强行执行，先把缺失节点补上。

5.2 低显存显卡启动参数调整

默认情况下，ComfyUI 会根据显卡情况做一些基础适配，但 8G 显存跑动画模型时，我更推荐显式指定低显存启动参数。

在启动脚本start_8g.bat中，可以调整为：

@echo off set PYTORCH_CUDA_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:128 cd /d %~dp0ComfyUI ..\python_embeded\python.exe main.py --lowvram --auto-launch pause

解释一下这行环境变量：

PYTORCH_CUDA_ALLOC_CONF=garbage_collection_threshold:0.9,max_split_size_mb:128

这是 PyTorch 的显存分配策略配置。garbage_collection_threshold:0.9表示显存占用达到 90% 时触发缓存回收，max_split_size_mb:128表示把显存分配块控制在合理大小，降低碎片化风险。

如果你的显卡是 12G 或 16G，但依然感觉卡顿，可以改用--medvram而不是--lowvram：

..\python_embeded\python.exe main.py --medvram --auto-launch

--medvram会保留更多显存用于计算，适合显存不算特别小但仍然紧张的场景；--lowvram会更激进地卸载模型层，适合 8G 这种极限场景。注意不要同时使用--medvram和--lowvram，它们是互斥的两种策略。

5.3 工作流中的显存优化设置

启动参数只是第一步，更重要的工作是调整工作流本身的参数。

如果你在整合包里看到了多个模型精度版本，例如 fp16、fp32、量化版，在不影响质量要求的前提下，优先选择低精度版本。低精度权重占用显存更少，计算也更快。不过，有些模型作者会明确要求使用 fp32 VAE，因为低精度可能导致色彩条纹或画面瑕疵。所以要先阅读模型说明，再决定是否压缩精度。

关于 VAE 文件，名字里的 fp32 已经说明了它的数据精度。8G 显存下，如果作者同时提供了更低的精度版本，可以优先尝试；如果没有，就不要强行把 fp32 文件转换成其他格式，因为 VAE 的精度转换并不像改后缀那样简单。

此外，工作流中往往有一个控制“一次处理多少帧”或“批次大小”的参数。低显存用户可以把批次值调小，让模型分段生成动画。每次只生成少量帧，等显存释放后再处理下一批，虽然总耗时可能会增加，但至少不会在生成到一半时爆显存。

5.4 生成过程的显存观测

点击 ComfyUI 界面中的 Queue 按钮后，生成任务就会开始。此时可以通过nvidia-smi观察显存变化。

当看到类似这样的输出时：

| NVIDIA-SMI Driver Version: 551.61 CUDA Version: 12.4 | | GPU Name Memory-Usage | | 0 NVIDIA GeForce RTX 4060 4070MiB / 8192MiB |

说明显存还有余量。如果看到显存占用逼近 8192MiB，说明当前工作流已经接近显存极限，下一步一旦开始 VAE 解码，很可能报 OOM（显存不足）。

此时应该停止生成，不要继续等待。可以降低分辨率、减少单次生成帧数、关闭后台正在运行的游戏或直播软件，再重新执行。

5.5 性能预期

在 RTX 4060 8G 这类显卡上，MiniMax H3 动画生成的速度会明显低于云端高性能显卡，但并非不可用。关键在于合理降低生成规模。

判断“是否流畅”不能只看单帧生成时间，还要看显存是否稳定、是否频繁发生内存交换。如果你发现生成过程中 GPU 利用率很低，但耗时很长，通常说明模型层正在频繁地从显存和内存之间搬运，这比单纯等待采样更耗时。

加速插件生效后，如果 GPU 利用率开始提升，采样每步耗时明显缩短，就说明优化到位了。

6. 动画生成工作流与提示词建议

6.1 工作流的核心结构

虽然不同整合包中的节点名称有差异，但一个完整的 MiniMax H3 动画生成流程通常包含 4 个阶段：

第 1 阶段：加载模型与 VAE。这个阶段负责把模型权重读取到显存中。加载速度慢时，优先检查磁盘是否为 SSD，以及是否在首次加载阶段把系统内存占满。

第 2 阶段：构建提示词。输入正向提示词和反向提示词。动画生成中，提示词不仅描述画面内容，还要描述动态语义，比如运动方向、镜头运动、时间变化。

第 3 阶段：采样与生成。采样器根据提示词不断降噪，生成潜空间特征。你可以调整步数、CFG、采样器名称。动画生成中步数增加会提升质量，但也会线性增加耗时。

第 4 阶段：VAE 解码与输出。潜空间数据通过 VAE 解码成真正的动画帧，最后合成为视频文件。这个阶段是显存占用的一次高峰，低显存用户容易在这一步爆显存。

6.2 把提示词写成“导演脚本”

很多人用图片生成的思路去写动画提示词，结果生成的画面单看每一帧不错，连起来却像一段没有逻辑的素材拼接。这是因为动画提示词需要把运动逻辑描述出来。

举一个正向提示词的例子：

一只橙色的狐狸从森林深处走来，镜头缓慢推进，狐狸抬头看向镜头，落叶在周围飘动，柔和晨光从树缝中洒下，画质细腻，电影感构图

这里有几个关键要素：

• 主体：橙色狐狸，明确且单一。
• 动作：从森林深处走来、抬头看向镜头，是连续动作描述。
• 镜头运动：镜头缓慢推进，让生成器理解画面不是静止构图。
• 氛围变化：柔和晨光、落叶飘动，提供时间和环境信息。
• 风格限定：画质细腻、电影感构图，约束最终画面风格。

反向提示词里则可以加入不想要的内容，例如：

低清晰度，画面抖动，帧间不连贯，文字水印，肢体扭曲，颜色溢出

需要注意，反向提示词不是越多越好。过多且相互矛盾的负面描述，可能干扰模型的语义理解。通常保留最痛恨的几个问题即可。

6.3 步数与采样批次的选择

采样步数直接决定生成质量和速度。步数过低，画面可能出现噪声残留、细节模糊；步数过高，耗时成倍增加，但质量提升可能不再明显。

想要找到适合自己的步数，可以做一个小实验：

1. 固定提示词，固定随机种子。
2. 分别使用不同步数生成同一段动画。
3. 记录每次的耗时间和画面质量。

这种实验并不复杂，但由于动画生成本身耗时，建议不要一次性测试 8 组参数，选 3 组即可。例如 20、30、40，观察差异。

随机种子对动画生成的影响也很大。相同提示词下，不同种子可能产生完全不同的构图和运动方式。找到效果好的种子后，可以固定种子，只在提示词上微调。

6.4 “导演台”式的多镜头动画处理

一些 MiniMax H3 相关整合包开始把“导演台”概念融入工作流中。“导演台”通常指一个用于管理多镜头脚本的面板，你可以把整段动画拆分成长度更短的镜头，再为每个镜头单独指定提示词、帧数、种子和转场方式。

处理多镜头任务时，我建议先单独生成每个镜头，确认每个镜头质量稳定后，再考虑合并。不要一开始就让工具连续渲染多个镜头，一旦中间某个镜头崩掉，前面生成的素材也可能白费。

更重要的是，多镜头动画要保持角色一致性。如果你使用参考图，确保参考图加载节点在每个镜头中都被正确连接；如果只使用文字提示词，同一主体描述尽量保持一致，不要在一个镜头里叫“橙色狐狸”，在另一个镜头里改成“棕红色毛茸茸动物”。语义差异越大，模型越容易画出不同角色。

7. 常见问题与排查思路

7.1 VAE 加载报错：value not in list

这是一个很典型的 ComfyUI 报错，错误内容类似：

Value not in list: vae_name: 'minimaxh3\minimax_h3_audio_vae_fp32.safetensors'

这个报错翻译过来的意思很直白：ComfyUI 在models/vae目录里找不到工作流记录的 VAE 文件。可能原因有两个：一是文件确实缺失；二是文件名不匹配。

处理步骤：

1. 打开 ComfyUI 的模型目录，确认minimax_h3_audio_vae_fp32.safetensors确实存在于models/vae中。
2. 返回 ComfyUI 界面，找到 VAE 加载节点，重新从下拉框中选择文件。
3. 如果下拉框里没有该文件，点击 ComfyUI 界面右侧的“刷新”按钮，或者重启 ComfyUI。

避免这个报错的最好习惯是：每次从别人的机器上复制工作流后，不要直接点运行，先检查下拉框中的模型、VAE、LoRA 有没有变成红色或报错。

7.2 生成中途报 CUDA Out of Memory

现象是生成到一半，控制台直接报CUDA out of memory，然后任务中断。

处理方法可以按优先级排列：

• 关闭其他占用显存的软件。浏览器在开启硬件加速时会占用几百兆显存，游戏录制软件也可能随时占用一部分。
• 在启动脚本中加入--lowvram，强制 ComfyUI 在显存不足时卸载部分模型层。
• 减少工作流中同时加载的模型数量。如果只是测试，可以暂时移除背景移除、超分放大等后处理节点。
• 降低分辨率。这是最有效但最影响画质的手段，放在最后使用。

如果用了低显存模式仍然报错，检查是否启用了多个显存优化插件。有时插件的显存管理策略会和 ComfyUI 内置的--lowvram冲突，导致显存释放不及时。

7.3 启动后浏览器无法访问页面

控制台已经显示To see the GUI go to: http://127.0.0.1:8188，但浏览器打不开。

解决顺序：

1. 先看控制台最后几行日志，是否出现 Python traceback。
2. 手动把地址改成http://127.0.0.1:8188再访问一次。
3. 如果端口被其他程序占用，可以在启动命令中加入--port 8190，把端口改成 8190。

7.4 插件安装后提示 No module named xxx

很多自定义插件需要额外依赖，整合包自带环境不一定包含这些依赖。

安装依赖时，不要打开系统命令行执行pip install，那样可能会把包装进全局 Python。要找到整合包内置 Python，例如：

D:\ComfyUI_MiniMaxH3_8G\python_embeded\python.exe -m pip install 依赖包名

安装后重启 ComfyUI。

如果依赖下载速度很慢，可以考虑把 pip 源切换到国内镜像源，例如清华 PyPI 镜像。这是常见的 Python 包镜像服务，和网络加速没有关系。命令示例如下：

D:\ComfyUI_MiniMaxH3_8G\python_embeded\python.exe -m pip install 依赖包名 -i https://pypi.tuna.tsinghua.edu.cn/simple

7.5 GitHub 下载插件太慢

ComfyUI 插件大量托管在 GitHub，直接 clone 可能会很慢。

解决办法不是使用任何违规加速手段，而是选择更稳妥的方式：

• 打开插件仓库主页，点击 Download ZIP 手动下载压缩包。
• 看看仓库是否提供了国内镜像地址。
• 将仓库地址中的github.com替换成可用的 GitHub 镜像域名后，再执行git clone。

这里不推荐任何特定镜像，因为镜像服务的可用性变化很快。你需要自行判断。

下载完成后，