企业官网建设流程全解析

Midjourney 出图最让人头疼的从来不是“好不好看”，而是“好看但细节碎了”。手指多一根、手指粘连成块、脚趾糊在一起、衣服边缘像融了一样、眼睛位置跑偏——这些问题你重新整图生成吧，构图和神态全变了；用局部重绘吧，又得对着破碎区域写一大段“修复 prompt”，写完模型还可能根本不听。

这次要讲的 ComfyUI 工作流，思路是反过来的：免提示词修复。把 Midjourney 崩掉细节的图拖进 ComfyUI，手动或自动圈出破碎区域，用低 denoise 的局部重绘让模型基于“原图上下文”自动重建细节，全程不需要输入perfect fingers、fix hand这类修复提示词。

这篇文章先讲清楚原理：Midjourney 细节为什么会破碎、denoise 和 mask 在修复里到底扮演什么角色、为什么这套局部重绘可以免提示词。然后是完整实操：ComfyUI 环境准备、节点插件安装、手动 mask 和自动 mask 两条工作流搭建、ControlNet 什么时候必须加、以及如何通过 ComfyUI API 把这套修复流程变成批量任务。

适合读者：被 Midjourney 局部细节整崩溃过的出图用户，想在 ComfyUI 里搭一套“修复流水线”的人，以及想真正搞懂局部重绘原理而不是只会点按钮的玩家。

1. 核心能力速览

先用一张表说清楚这套工作流的定位和门槛。

这里要提醒一句：上面这些能力不是“必须全部满足才能用”。最基础的手动 mask + 局部重绘，只需要 ComfyUI 默认节点就能完成；自动检测和批量 API 是进阶选项。

2. 原理讲解：Midjourney 细节为什么碎，拆解局部重绘的修复逻辑

2.1 破碎细节是怎么产生的

Midjourney 这类扩散模型在生成图片时，优先满足的是整体构图、风格、光影和语义一致性。生成过程相当于从一个纯噪声张量开始，逐步去噪还原图像，每一步都在“猜”全局结构。对于手部、脚趾、文字、物体交界这些高频细节，模型需要有很强的局部约束才能保证结构正确，而这恰恰是扩散生成最容易偷懒的地方。

所以你会看到一种常见现象：整张图氛围拉满，但手部区域有三根手指黏在一起，或者手指弯曲角度违背人体结构。这不是 Midjourney 故意搞破坏，而是生成模型在全局语义和局部几何之间权衡后的典型失败模式。

2.2 为什么二次整图生成不可行

很多人遇到细节破碎后，第一反应是重新生成一张。问题在于 Midjourney 的随机性很强，即使你复制同一段提示词、同一组参数，新图在构图、光线、人物神态上也会有明显差异。为了修一根手指丢掉整张图的构图，成本和风险都很高。

更合理的方式是“局部重绘”：只对破碎区域重新采样，保留周围完好的像素作为强约束。这也是 ComfyUI 工作流的核心。

2.3 denoise 和 mask：修复工作的两个核心旋钮

局部重绘在 ComfyUI 里并不复杂，关键只有两个概念：mask 和 denoise。

mask 决定了“哪些区域需要重绘”。mask 之外的图像区域会原样保留，mask 内部会被注入噪声并重新采样。denoise 决定了“注入噪声的比例”。denoise 越高，重绘区域越自由，越可能生成新的结构，但也越容易偏离原图；denoise 越低，重绘区域越接近原图，修复幅度越克制。

实操里的常用区间大概是 0.3 到 0.5。这个区间既能让模型对破碎区域做出结构修复，又不会把原来的衣服、肤色、光照完全洗掉。具体数值需要根据图的分辨率、底模风格、破碎严重程度反复试。

2.4 为什么局部重绘可以“免提示词”

这是整套工作流最关键的地方。

很多人以为局部重绘必须写清楚“修复什么”，但扩散模型的实际运行逻辑是：采样器在重建被遮住的区域时，主要依据是未遮区域提供的上下文信息，而不是 prompt 里的文字描述。如果你把一张手的图遮住手指部分，周围的手指、手掌、衣袖、光影已经把结构先验给得差不多了，模型完全可以通过这些上下文推断出“这里大概应该是一根正常的手指”。

这也是免提示词能成立的基础：对于小块破碎区域，原图本身就是最好的提示词。我们只需要把 denoise 控制在一个合理的范围，模型就能基于原图结构自然补齐细节。

实际操作中，可以把正向 prompt 节点接一个空文本，或者输入一个中性词，同时把 CFG 调到较低值，比如 1.5 到 3 之间。这样做是为了降低全局语义对局部重建的干扰，让模型更专心地“读图”，而不是被 prompt 带偏去生成一堆想象中的内容。

这里也说明一个边界：所谓“免提示词”，不是让你把 ComfyUI 里的文本编码节点整个删掉，而是指“不针对修复目标写描述性 prompt，也不依赖 prompt 信息来引导修复”。这在大多数 ComfyUI 局部重绘场景里是可以成立的。

3. 适用场景与使用边界

这套工作流适合几种情况：

• Midjourney 出图后手部、脚部、物体边缘破碎，但整体构图满意，不想重画。
• 图片已经经过放大、高清化等流程，只有个别细节需要修补。
• 需要批量修复大量 Midjourney 出图，人工点局部重绘太慢，想通过工作流 + API 自动化。

不适合的情况也要说清楚：

• 整张图构图本身就有严重问题，比如主体缺失、透视完全错乱，局部重绘救不回来，建议重新生成或者从头重画。
• 破碎区域非常大，比如半张脸都没了，单个 mask 盖住后，免提示词的效果会明显下降，模型需要的信息不够，结果容易崩。
• 只想保留原图完全不动、只做轻微优化，那应该走“放大 + 细节增强”路线，而不是局部重绘。

合规方面需要特别注意：Midjourney 生成图片的商用授权、使用边界以你当前的订阅条款和服务协议为准，不同套餐的授权范围不同。涉及人脸、品牌 Logo、他人作品、特定人物肖像时，修复、发布、商用前必须确认有没有获得对应授权。AI 修复不等于可以规避授权，这一点不要心存侥幸。

4. 环境准备与前置条件

4.1 基础硬件与系统

首先要有一台能跑 ComfyUI 的电脑。系统推荐 Windows 10/11 或 Ubuntu 20.04 以上。显卡优先 N 卡，因为 ComfyUI 的 PyTorch/CUDA 生态在 N 卡上最省心；A 卡和核显也能跑，但驱动、显存、算子支持都更折腾，不建议新手碰。

显存方面，如果你用 SD1.5 底模做中低分辨率局部重绘，4G 到 6G 显存有机会跑，但步骤数、分辨率、是否开启 ControlNet 都会影响实际占用；如果你用 SDXL 底模，或者原图分辨率很高，建议 8G 显存以上。具体占用要按你的本机环境测试，不能只靠别人的截图判断。

磁盘空间方面，ComfyUI 本体很小，真正占空间的是底模。SD1.5 模型大约 2 到 4GB，SDXL 大约 6 到 7GB，外加检测器权重和 ControlNet 权重，建议预留 30GB 以上空间。

4.2 ComfyUI 的两种安装路线

新手建议直接用秋叶整合包。它把 Python、PyTorch、ComfyUI 本体、常用插件和内置模型管理都打包好了，解压后通过启动脚本启动，省掉大量环境折腾时间。整合包安装时注意：解压路径不要带中文和空格，否则部分插件会报路径错误。

有一定经验的用户可以直接拉官方仓库命令部署，主要步骤是准备 Python 虚拟环境、安装 PyTorch、安装 requirements 里的依赖。下面是一个通用命令流程，实际路径和版本需要根据项目文档调整：

# 示例：官方包克隆与依赖安装，路径按实际项目调整 git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txt python main.py --listen 127.0.0.1 --port 8188

启动后浏览器访问http://127.0.0.1:8188，能看到 ComfyUI 的节点画布就说明环境没问题。

4.3 节点插件：修复工作流需要装什么

如果只做手动 mask 修复，ComfyUI 内置节点就够，不需要额外装插件。但如果要做“自动圈出破碎区域”，需要安装社区插件，常见的有：

• ComfyUI Impact Pack：提供与 Segment Anything、物体检测相关的节点，用于自动生成 mask。
• ComfyUI ControlNet Aux：包含手部检测、深度估计、姿态估计等辅助节点，可用于生成检测 mask 或结构约束。
• ComfyUI Manager：管理插件的安装、更新、卸载，避免手动丢文件。

安装方式通常是到ComfyUI/custom_nodes目录下 clone 插件仓库，然后重启 ComfyUI。用 ComfyUI Manager 的话，可以在界面里搜索插件名直接安装，更省心。

安装完成后，在节点搜索框输入SAM、Detection、MediaPipe、Bbox等关键词，能看到相关节点就说明插件加载成功。首次使用检测器节点时会下载对应权重，这个过程可能比较慢，也可能因为网络原因失败。下载失败时，优先检查网络连通性，或者手动把权重文件放到插件指定的目录。

5. 安装与启动：把工作流跑起来

5.1 一键启动流程

秋叶整合包解压后，找到启动脚本或桌面入口，按提示启动。启动后会看到一个命令行窗口显示 URL，比如http://127.0.0.1:8188，浏览器打开即可。

官方包则通过命令行启动，如果想开放局域网访问或让 API 被其他机器调用，可以增加--listen 0.0.0.0。注意开放到局域网后，端口默认没有鉴权，任何人都可能提交任务，生产环境需要做好访问控制。

# 示例：局域网访问时用 listen 0.0.0.0 python main.py --listen 0.0.0.0 --port 8188

启动完成后，把别人分享的workflow.json文件拖进 ComfyUI 画布，就可以加载工作流。加载后如果报“Missing Node”错误，通常是缺少对应插件或插件版本过低。

5.2 工作流最小链路

先记住这条最核心的节点链路，所有修复工作流都基于它：

Load Image -> VAE Encode for Inpaint -> KSampler -> VAE Decode -> Save Image

其中VAE Encode for Inpaint这个节点负责“告诉你哪些区域要被重绘”，它需要三个输入：原图像素、VAE、mask。mask 可以来自手动绘制，也可以来自后接的检测器节点。

6. 工作流搭建：手动 mask 与自动 mask 两条路径

6.1 手动 mask 路径：最快跑通整条链路

这是推荐新手第一次先跑的路径，不需要额外模型和插件，只需要原图和画笔。

准备一张 Midjourney 生成、手部明显破碎的图。拖进 ComfyUI 后，按下面步骤操作：

第一步：加载图片。使用Load Image节点，选择目标图片。

第二步：生成 mask。在 ComfyUI 里，可以直接在Load Image节点显示图片后，用画布/遮罩编辑功能绘制 mask，也可以通过Mask相关节点读取外部 mask 图。mask 的覆盖范围要比破碎区域稍微大一圈，但不要大到把正常的手指和手指间隙都盖住。

第三步：重绘前编码。把图片、VAE 和 mask 接到VAE Encode for Inpaint节点。这个节点会把 mask 区域的信息编码到潜空间，并告知采样器哪些位置要重点重建。

第四步：设置采样参数。KSampler节点是修复的核心。建议先试这组参数：

• steps：20 到 30
• cfg：1.5 到 3
• denoise：0.35 左右
• sampler_name：euler 或 dpmpp_2m
• scheduler：normal 或 karras

正向 prompt 节点可以不写修复描述，直接留空或写一个中性词best quality，负向 prompt 可以留空或写lowres, bad anatomy, bad hand, extra fingers这类通用负向词。

第五步：解码保存。采样结果通过VAE Decode解码，再接Save Image输出。添加一个Preview Image节点可以即时预览，避免每次都写文件。

这套流程的意义在于：用最少节点验证 denoise 对修复效果的影响。如果 denoise 0.35 改不动，就升到 0.45；如果改过头导致手指形状变了，就降回 0.3。

6.2 自动 mask 路径：靠检测器圈出破碎区域

手动 mask 要一张张图去涂抹，不适合批量。自动 mask 的思路是用检测器模型先识别出需要修复的部位，自动生成 mask，再接同样的VAE Encode for Inpaint链路。

以手部修复为例，常见的自动 mask 来源有几种：

• 人手关键点检测模型，输出手部 bounding box 或骨骼关键点，把关键点区域转成 mask。
• Segment Anything / SAM 模型，通过点提示或框提示分割出手部区域，生成精细 mask。
• 目标检测模型，直接检测手部、脸部、人体等类别，输出 bbox 再扩展为 mask。

节点链路大致是：

Load Image -> 手部/人脸检测节点 or SAM 分割节点 -> Mask 后处理（膨胀/羽化） -> VAE Encode for Inpaint -> KSampler -> VAE Decode -> Save Image

检测器生成 mask 后，通常要做两步后处理：膨胀和羽化。膨胀是为了让 mask 覆盖到破碎边缘之外，避免修复痕迹生硬；羽化是为了让 mask 边缘过渡自然，避免出现明显的颜色断层。ComfyUI 中这两个操作一般通过 Mask 后处理节点完成，比如GrowMask、Blur等。

自动 mask 的优势是批量，但缺点也很明显：检测器不一定能准确覆盖所有破碎区域，尤其是严重坏手、多只手重叠时，检测结果可能漏检或误检。所以第一次运行自动 mask 时，建议加上一个Preview Image节点，先看 mask 覆盖是否合理，再进入采样。

6.3 ControlNet 结构约束路径：破碎区域太大时再考虑

如果破碎区域不大，免提示词 + 局部重绘就够。如果破碎区域很大，或者结构错乱严重，比如手指交叉、整段肢体弯曲角度异常，纯靠原图上下文可能撑不住。这时建议叠加 ControlNet 做结构约束。

常用组合是：

• ControlNet Tile：把原图采集成 tile 特征，让重绘过程保持原图纹理和结构。
• ControlNet Inpaint：专门为局部重绘设计的 ControlNet 类型，能更好地利用 mask 信息。
• ControlNet Depth / OpenPose：如果破碎区域涉及人体姿态，可以先用姿态估计提取原图结构，再约束采样器不能偏离结构。

加了 ControlNet 后，denoise 可以适当提高到 0.45 到 0.6，因为结构已经被 ControlNet 锁住了，采样器有更大空间重建细节，不容易跑偏。

需要注意：ControlNet 不是越多越好。每加一个 ControlNet，显存占用和推理耗时都会上升，节点报错概率也更高。建议先跑通手动 mask + 低 denoise 的最小链路，再按需加 ControlNet。

7. 功能测试与效果验证

7.1 测试素材准备

准备三组测试图：

1. 一张手部破碎图（手指多指、粘连、扭曲）。
2. 一张脸部崩坏图（眼睛位置、嘴部结构怪异）。
3. 一张物体边缘破碎图（比如衣服边缘融化、物品接缝断裂）。

每组图都手动生成一个覆盖破碎区域的 mask 备用。

7.2 手动 mask 测试步骤

操作流程：

1. 载入手部破碎图。
2. 手动绘制 mask，覆盖所有破碎手指区域。
3. 设置 denoise = 0.35，steps = 25，cfg = 1.8，正向 prompt 留空。
4. 执行工作流。
5. 重复三次，每次观察输出。

预期结果：手指数量回归正常，手指之间自然分离，手部整体颜色和原图一致，构图、背景、人物衣服没有明显变化。

判断成功的标准是：破碎区域被修复，但原图非 mask 区域几乎不变。如果非 mask 区域出现明显变化，说明 denoise 太高，或者 mask 没有真正限制住重绘区域。

7.3 免提示词对比实验

这个实验用来验证“免提示词”是否真的可行。

做法是把同一个 mask 跑两组：

• 第一组：正向 prompt 为空文本，cfg = 1.8，denoise = 0.35。
• 第二组：正向 prompt 写perfect hand, detailed fingers，cfg = 7，denoise = 0.35。

对比两组输出。如果第一组也能修复手指结构，说明修复主要依赖原图上下文，提示词不是必需品；如果第一组完全没变化，可能是 denoise 太低或 mask 太大，需要调整参数。

这个实验也说明了一个事实：“免提示词”不等于“零参数”。你仍然需要关注 denoise、mask、cfg 这些核心参数。

7.4 自动 mask 测试步骤

在加入自动检测器后，先跑一次“只输出 mask 不采样”的工作流分支，目视检查检测结果：

1. 检测器是否框住了所有破碎部位。
2. 检测框是否过小，没覆盖到破碎边缘。
3. 是否误检了别的区域。

如果漏检，可以调低检测阈值；如果误检，则要调高阈值，或者后续人工补充 mask。自动 mask 是提高效率的辅助，不是“绝对准确”。批量任务里如果出现某张图明显漏检，就应当把这张图抽出来走手动 mask 路径。

7.5 批量测试

批量测试建议用 ComfyUI API 来做，下一章详细展开。先在 UI 里跑通 3 张图，再扩展到 10 张，最后再考虑 100 张。批量时一定要给每张输出图设置不同的filename_prefix，否则输出文件会相互覆盖。

7.6 失败模式速查

8. 接口 API 与批量修复流程

ComfyUI 本身带有 API，可以把工作流从界面交互变成 HTTP 请求，这是做批量修复的基础。

8.1 启动 API 服务

启动 ComfyUI 时不加--listen 127.0.0.1限制，或者明确指定监听地址，就可以通过 HTTP API 提交任务。默认端口是 8188，提交任务的接口是POST /prompt，查询任务状态是GET /history/{prompt_id}。

# 启动时开启局域网访问 python main.py --listen 0.0.0.0 --port 8188

注意：--listen 0.0.0.0意味着局域网内其他机器也能访问你的 ComfyUI，如果你只是本机测试，建议保留--listen 127.0.0.1。

8.2 导出 API 格式工作流

在 ComfyUI 界面完成工作流搭建后，需要把工作流导出为 API 格式。导出后得到的是一个 JSON 文件，里面每个节点都有独立的class_type和inputs。API 提交时，我们提交的就是这个 JSON 结构。

如何让工作流变成可复用批量任务？关键是把“输入图片”和“输出前缀”设置成变量。比如LoadImage节点的image字段直接填文件名，每次批量任务替换这张图的名字，就能处理不同图片。

8.3 Python 调用示例

下面是一个通用 Python 调用模板。注意：workflow里的节点结构必须替换为你自己导出的 API 格式，不能直接复制运行。

import requests import time import json server = "http://127.0.0.1:8188" # 从 ComfyUI 导出的 API 格式工作流，真实使用时需要完整替换 workflow = { "1": { "class_type": "LoadImage", "inputs": { "image": "broken_hand.png" } }, "2": { "class_type": "VAEEncodeForInpaint", "inputs": { "pixels": ["1", 0], "vae": ["vae_node", 0], "mask": ["mask_input_node", 0] } }, "3": { "class_type": "KSampler", "inputs": { "model": ["model_loader_node", 0], "positive": ["positive_text_node", 0], "negative": ["negative_text_node", 0], "latent_image": ["2", 0], "steps": 25, "cfg": 1.8, "denoise": 0.35 } } } def submit_and_wait(workflow, client_id="batch-repair"): resp = requests.post( f"{server}/prompt", json={"prompt": workflow, "client_id": client_id} ) data = resp.json() if "prompt_id" not in data: print("提交失败:", data) return None prompt_id = data["prompt_id"] print("已提交任务:", prompt_id) while True: time.sleep(2) hist = requests.get(f"{server}/history/{prompt_id}").json() if prompt_id in hist: status = hist[prompt_id].get("status", {}) print("任务状态:", status) return prompt_id submit_and_wait(workflow)

8.4 JSON 请求负载示意

如果你不想写 Python，也可以直接用 curl 提交。下面是一个请求体示意，真实使用时需要按导出的工作流替换节点内容：

{ "prompt": { "1": { "class_type": "LoadImage", "inputs": { "image": "broken_hand.png" } } }, "client_id": "batch-repair-001" }

这条请求只是示意，实际提交必须带完整的节点链，否则 ComfyUI 会因为缺少输入而报错。

8.5 批量任务队列设计

批量修复不建议前端界面一张张点。建议这样做：

• 输入目录统一放原图，文件名有规律，比如mj_001.png、mj_002.png。
• 写一个 Python 脚本，遍历输入目录，把每个文件名填入工作流的LoadImage节点，提交到 ComfyUI。
• 保存所有prompt_id和对应图片名到日志文件，定时查询GET /history，确认哪些成功、哪些失败。
• 失败任务重试时，直接用同一个文件再次提交，但输出前缀要加retry_，避免覆盖原结果。
• 如果批量任务量大，控制并发提交数量，比如同时只保持 2 到 3 个任务在队列里，防止显存爆炸。

批量修复最容易踩的坑不是单张修复效果，而是“一张崩了影响后续全部”。所以脚本一定要有日志和失败隔离，不能因为某一张图的检测器漏检就中断整个任务。

9. 资源占用与性能观察

9.1 怎么观察显存占用

ComfyUI 运行局部重绘时，显存占用主要取决于三个因素：底模大小、分辨率、是否启用 ControlNet。SD1.5 底模的占用明显低于 SDXL，局部重绘如果只改了 mask 区域，整体 latent 计算范围不会缩小太多，所以显存压力仍然和整图分辨率成正比。

观察显存最直接的办法是打开任务管理器的 GPU 面板，或者用nvidia-smi命令：

nvidia-smi

这个命令会显示当前 GPU 的显存总量、已用显存、进程占用情况。在 ComfyUI 执行修复时，把nvidia-smi放到另一个终端里循环刷新，就能看到采样阶段的峰值占用。注意，采样阶段和模型加载阶段的显存占用不同，采样阶段的峰值往往更高。

9.2 CPU 推理与 GPU 推理的差异

ComfyUI 默认会用 GPU 推理。如果机器没有 CUDA 环境，可以强制用 CPU，但速度会慢很多。测试时建议：

• 先用小图、低分辨率跑通流程，确认效果后再升高分辨率。
• SDXL 底模在 4G 显存机器上大概率会爆显存，优先考虑 SD1.5 底模。
• 如果显存不够，启动时可加--lowvram或--medvram参数，让权重按需加载，换取更低显存占用：

python main.py --lowvram

9.3 影响性能的关键参数

• 分辨率：越高显存占用越大，采样耗时越长。局部重绘时可以把原图缩到合理尺寸，修复完再放大。
• steps：步骤数越多采样越慢，但细节修复收益有限。20 到 30 步已经足够。
• denoise：denoise 大小直接影响采样时间吗？不一定，但会影响输出稳定性和重绘幅度。过高的 denoise 会让采样器跑得更远，时间更长。
• ControlNet 数量：每多一个 ControlNet，显存和计算量都会明显增加。
• 批次数：如果一次跑多张图，显存占用会线性增加。本地测试建议 batch size 保持 1。

10. 常见问题与排查方法

11. 最佳实践与使用建议

这套工作流在真正用于生产前，建议先养成几个习惯。

第一，固定一组最小可运行参数。比如 steps 25、cfg 1.8、denoise 0.35、euler + normal。每次新图先按这组参数跑，根据效果微调 denoise，而不是每次换一组完全不同参数，否则你很难判断是哪一步导致了效果变化。

第二，目录分离。原图、修复后的图、检测器生成的 mask、工作流 JSON，分类放。批量任务尤其注意输出目录，建议按日期建子目录。

第三，把工作流导出为 API 格式并保存。当你在 UI 里调出一版满意的修复流程后，立即通过 ComfyUI 的 Workflow 导出功能保存一份 API 格式，这是后续做批量任务的基础。只保存界面格式的话，API 调用时没法直接复用。

第四，批量任务必须加日志和失败重试。不要写一个没有日志的脚本跑 100 张图，否则某张图中途崩了你完全不知道卡在哪一步。

第五，修复后要人工复检。AI 修复不是绝对正确，尤其涉及人物手部时，模型可能把手指数量修对，但姿势依旧别扭。出图前逐张看一眼，比事后返工成本低得多。

第六，注意授权与隐私边界。如果你修复的 Midjourney 图会用于商用，请先确认你的 Midjourney 订阅套餐允许商用；如果图中包含真实人物、品牌 Logo、他人作品，修复前必须确认授权。自动化批量修复不会改变这张图的版权属性，只会让侵权风险扩散得更快。

12. 总结与下一步

这套免提示词修复工作流，最值得尝试的点就是“不写修复 prompt 也能修好局部细节”。它把 Midjourney 出图后最常踩的坑，变成了一个可以反复执行的 ComfyUI 本地流程。你先要验证的也不是什么高级功能，而是最基础的一条链路：Load Image 到 VAE Encode for Inpaint 到 KSampler 到 VAE Decode，denoise 卡在 0.35 左右，手动 mask 圈出手部破碎区域，跑通一次后再考虑加检测器。

最容易踩的坑有两个：一个是 denoise 控制不好，要么修不动，要么把原图洗了；另一个是 mask 覆盖不全，看起来修了，其实破碎边缘还留在外面。

后续可以扩展的方向很明确：把自动手部检测接入工作流，实现一键读图、自动圈定破碎区域、自动修复；通过 API 把修复流程接到自己的批量出图管线里；遇到结构错乱严重的图，再叠加 ControlNet Tile 或 Inpaint 约束。这套工作流搭好后，Midjourney 出图之后的“返工”环节就能省下大半。建议先收藏，下次遇到坏手图时照着搭一遍。