ComfyUI Spaces 工作流：部署与验收流程

流程依赖核对

先把现有节点图当作一份依赖清单，而不是直接上传文件。你需要确认每个节点的作用、输入类型、输出类型，以及它依赖的模型、插件和自定义资源。

资料包只确认相关公开文章讨论了在 Hugging Face Spaces 中运行 ComfyUI 工作流，不能据此推断某个当前方案一定拥有固定显存、配额或启动参数。把这些项目标成“待验证”，避免部署时把猜测当成配置结论。

输入输出字段

在线应用需要让使用者知道哪些值可以修改，哪些值必须固定。建议先建立一份字段表，再决定页面控件。

1. 将提示词、负面提示词、参考图、宽度、高度、步数、随机种子等候选参数列出。
2. 标记每个参数的类型、是否必填、默认值、可接受范围和对应节点。
3. 把模型名称、采样器、调度方式等容易造成结果变化的配置单独记录。
4. 明确输出是单张图片、图片列表还是带状态信息的结果对象。
5. 为每次运行保存任务标识、输入摘要、参数版本、状态、错误信息和输出文件路径。

输入字段不宜直接暴露整张节点图的所有参数。新手界面只保留确实需要调整的项目，其余配置固定在版本文件中，便于团队复现。

Spaces 应用结构

应用目录至少应能区分界面入口、工作流配置、模型与其他资源、输出目录和运行记录。具体文件名可按项目约定调整，重点是职责清楚。

• 入口文件：负责启动应用和连接界面事件。
• 工作流配置：保存节点连接、默认参数和输出节点信息。
• 依赖清单：记录运行环境需要安装的包与自定义节点。
• 资源目录：区分模型、参考图、LoRA、控制图等文件。
• 输出目录：保存生成文件和必要的元数据。
• 日志记录：保留启动状态、运行状态、失败原因和复测结果。

部署前先做一次最小化整理：只保留一条能生成样本图的路径、一个固定提示词和一份小尺寸输出。等最小流程稳定后，再逐步加入放大、风格适配或多分支节点。

固定样本运行

不要一开始就让团队输入各自的复杂需求。先准备一个固定样本，用来判断问题发生在流程、资源、输入还是输出保存阶段。

1. 选择一条已经在本地成功运行过的节点路径。
2. 固定提示词、负面提示词、随机种子、尺寸和输出格式。
3. 在 Spaces 页面提交一次最小请求，并记录开始时间、结束时间和运行状态。
4. 检查界面是否能显示处理中、成功或失败等明确状态。
5. 下载输出文件，记录文件名、尺寸、格式和对应参数版本。
6. 重复运行一次，比较是否出现资源不足、节点缺失或输出路径变化。

示例：一条最小图像任务记录

这里的状态名称只是记录模板，实际状态字段要以应用和运行框架返回的值为准。不要因为界面显示了图片，就省略任务状态和参数记录。

常见故障排查

排错时一次只改一个变量，并保留失败记录。下面按常见现象、可能原因和修正动作处理。

• 应用无法启动：可能是依赖包、入口配置或自定义节点不兼容。先查看构建与启动日志，删除非必要依赖，再用最小流程启动。
• 节点显示缺失：可能是插件没有安装、目录不对或版本不匹配。核对节点来源和安装状态，暂时替换为基础节点并重新导出流程。
• 模型加载失败：可能是文件未上传、路径错误或资源未完成下载。检查文件名、目录和权限，不要只修改提示词。
• 运行中断或显存不足：可能是尺寸、批量数、分支数量或模型组合过重。先降低输出尺寸和批量数，关闭非必要分支，再逐项恢复。
• 任务显示成功但没有图片：可能是输出节点未连接、保存目录不一致或应用没有读取返回结果。检查输出节点、实际文件路径和界面绑定关系。
• 图片能生成但结果不一致：可能是随机种子、模型版本、提示词或采样配置没有固定。保存完整参数，重新运行固定样本后再比较。

成图与版本验收

验收不只看图片是否好看，还要确认别人能否按同样输入得到可交付结果。发布前逐项检查：

1. 流程中的节点都能找到，必要模型和插件已有明确来源。
2. 输入字段名称、类型、默认值和必填规则与实际处理函数一致。
3. 固定样本至少成功运行一次，并保存对应参数和输出文件。
4. 失败时页面能显示可定位的状态或错误记录，而不是静默结束。
5. 输出图片能够正常打开，格式、宽高、色彩和文件大小符合项目要求。
6. 主体、构图、风格、细节和画面缺陷经过人工复核。
7. 输出文件名能关联任务、流程版本和生成时间。
8. 不需要公开的密钥、内部路径和调试信息没有出现在界面或日志中。
9. 当前可复用版本已单独保存，并记录已知限制和回退方式。

完成验收后再分享应用入口。后续修改节点、模型或页面字段时，继续使用同一组固定样本做回归检查，避免“能运行”与“可交付”被混为一谈。