平时处理图片最容易被低估的就是“分割”这一步。不管是电商详情页要切图、UI要出切图资源、漫画汉化组要切分镜还是做训练集要把大图裁成小图图片分割看着简单实际操作里全是细节——切歪一条线、留错一个出血位、多一个白边、少一个图层都够你返工半天的。更别说要批量处理几十上百张图的时候要是全靠手动在PS里拉参考线那工作量简直让人怀疑人生。这篇内容我打算换个思路不聊那种“科普向”的泛泛而谈直接把图片分割当成一条完整的工作流来讲从怎么拆解分割需求、选定分割方案到具体操作时怎么定参数、怎么写批量脚本再到怎么把分割和压缩、重命名、打包这些上下游环节串起来最后附上我实际踩过的一些坑和排查经验。梳理完这一套你会发现图片分割不只是“把图切开”那么简单它完全可以变成一个高效的自动化流水线帮你省下大量重复劳动的时间。1. 内容整体设计与思路拆解1.1 图片分割的核心场景与需求拆解我接触到的图片分割需求基本可以分成三大类每一类的目标和约束条件都不一样。第一类是网格切图。最常见的就是电商详情页一张长图要切成若干块或者一张大合影要切成九宫格发朋友圈。这类需求的特点是规则简单就是按行列均分但偏偏对“接缝”和“边缘”有要求——如果每张子图边缘留白不一致拼接起来就会出现断线或错位。UI切图也属于这类但更强调“按需切”不是均分而是沿着设计稿里的控件边界来切而且要兼顾多倍率1x、2x、3x的输出。第二类是内容分割。典型场景是漫画分镜切割、扫描件分栏拆分、试卷题目切分。这类需求的特点是边界不规则经常要沿着画面内容的自然边界来切而且切完之后每块要能独立阅读。这时候单纯的“等分”就不够用了得先做内容识别判断哪里是可切割的缝隙哪里是必须保留的画面主体。第三类是语义分割。这是偏算法方向的比如要把图片里的前景物体和背景分开、把不同的语义区域天空、道路、行人标出来。这类需求通常是为了给模型训练准备数据集或者做图像编辑它输出的不是若干张图片文件而是一张与原始图片尺寸一致的 mask每个像素点代表一个类别。我在设计工作流的时候第一步永远是问清楚你到底要哪种分割结果这决定了后面所有的工具选型和处理逻辑。很多人一上来就找切图工具其实连自己到底要的是“像素级分割”还是“等分切块”都没想明白那后面很容易白干。1.2 为什么要把分割做成一整条工作流而不是单点操作“工作流”这个词最近特别火各种可视化编排工具层出不穷。但在我看来工作流的本质不是工具多高级而是把零散的操作步骤变成一套可复用、可批量、可交接的流程。图片分割尤其适合工作流化原因是这个场景里有大量重复性、规则性的操作。我给你算一笔账假设有200张商品图需要切割成正方形缩略图手动操作的情况下每张图平均要花40秒打开、裁剪、导出、关闭那就是8000秒接近两个半小时。如果写成脚本批量处理耗时主要花在磁盘读写上200张图可能1分钟就处理完了而且不会疲劳、不会手抖、不会出现“这张忘切了”的低级错误。工作流化的第二个好处是质量稳定。人手工操作时状态好和状态差时的输出质量完全不一样——上午切的图边缘锐利下午切的图可能就多了2像素的白边。而流程固定下来之后同一套参数跑出来的结果永远是一致的这在团队协作中尤其重要。你不需要跟队友解释“上次你是怎么切的”直接把流程文件和参数一交大家产出的东西就是统一的。第三个好处是便于排查和优化。单点操作出了问题你很难复盘是哪个环节出了问题。而一条清晰的工作流每个环节的输入输出都是明确的出了问题只要顺着链路一个节点一个节点检查就好。这也是我特别喜欢在文章里强调“链路思维”的原因——处理图片不是一个动作而是一串动作的集合。1.3 方案选型单张精修走GUI批量处理走脚本面对图片分割需求大家通常会面临一个选择用现成的图形界面工具PS、画图、各种在线切图网站还是写代码来搞定我的建议是单张精修走GUI批量处理走脚本二者同时准备不要互相替代。原因是它们的优势区间完全不同。图形界面工具的优势是直观、可控、所见即所得。当你要处理的是极其精美的设计稿需要用人眼判断分割位置时GUI 是不可替代的。PS 里的切片工具、参考线、裁剪工具配合图层结构能让你很精细地控制每一刀的位置。包括很多在线切图工具操作门槛低适合偶尔切几张图的非技术用户。脚本方案的优势是高效、精确、可重复。用 Python 的 Pillow 库或者 OpenCV你能把“第3行第2列的方块”这种行为精确到像素级别而且同样的逻辑可以在任意数量的图片上执行。脚本天然适合批量、规则明确的场景。实际工作中我往往是混合使用先用脚本做批量的、规则性的处理把几百张图粗加工成统一的规格然后在 GUI 里对其中少数“特殊分子”做微调。这个思路我后面会详细演示具体怎么做。2. 核心细节解析与实操要点2.1 网格切图的边界问题间距、出血位与命名规则网格切图看着简单最容易出问题的恰恰是边界。我处理电商详情页切图时最常遇到的一个问题是客户要求“切完拼起来跟原图一模一样”但每张子图保存时如果不小心带了压缩伪影或者颜色配置文件不同拼起来就会有色差或接缝。所以我要先定几个核心参数。间距如果你是为了“九宫格朋友圈”效果切图每张子图周围通常要留一些空白间距不然发出来会连成一大片没有那种错落感。具体留多少取决于你用的是什么平台——建议留8到12像素太小看不出区分度太大又显得松散。出血位如果是印刷用的分版或者需要做后续裁切的设计稿切图时要在边缘额外预留出血。以印刷品为例出血通常要留3毫米。这个值不是拍脑袋定的而是印刷厂装订裁切时允许的误差范围。做网页或App用图时出血位可以不加但裁切线要保留在元数据或者命名里方便后续处理。命名规则这是很多教程会略过但实战极其重要的一环。我强烈建议切图输出时用文件名_行号_列号.扩展名的命名格式比如detail_03_02.jpg。这样至少有四个好处后续拼接时能通过解析文件名自动还原顺序文件名排序自然还是原来的阅读顺序无论谁拿到这批文件按文件名就能理解每张图的来源位置排查问题时能快速定位“第3行第2列的图怎么了”我见过太多人把切完的图命名成img1.jpg、new1.jpg、未标题-1.jpg等要拼回去的时候当场傻眼。别嫌命名麻烦这是整个流程里性价比最高的一步。2.2 内容分割的关键怎么判断“切在这里”是对的漫画分镜切割、扫描件分栏这类内容分割需求难点不在“切”这个动作而在“判断切点”。我的经验是把判断标准量化为三条规则。第一条寻找“空白走廊”。大多数排版作品在设计时都会留下页边距、段间距、分栏间距这些空白区域就是天然的“切割走廊”。先用程序去扫描图片中一行像素的变化情况找到纵向和横向的“全空白行”或“接近空白行”那些位置就是优先考虑的切割线。我之前处理一个扫描版的旧书就是用“行像素方差”的办法先找出所有全白的行再结合每行的文字密度把一页纸准确分成了上下两栏效果比手动框选稳定得多。第二条避开主体元素。有些时候空白走廊不是正好的比如漫画里的跨页大图人物跨过两格。这时候就需要在候选切割线里再做一轮过滤——检查切割线附近的像素是否有高对比度边缘如果某条线上有大量“笔触”穿过说明这里是画面的核心区域不能切。这条规则相当于给切割线画了一条“安全距离”。第三条子图必须语义完整。机器是不会理解“这一格是不是表达了一个完整意思”的所以这里需要一个后置检查环节。如果是人肉检查可以快扫一遍切出来的子图如果是自动化流程可以用一些启发式规则比如子图的宽高比是否在正常范围内、画面边缘是否有半截物体等把可疑输出标记出来让人工复核。2.3 语义分割输出与普通切图的本质差异语义分割这里多聊几句。因为很多刚接触图片处理的人会把“抠图”和“语义分割”混为一谈其实它们的目的完全不同。普通切图是“切块”把大图变成小图像素本身不发生变化只是重新组织。而语义分割是“标类”输出的是和原图等大的 mask每个像素都会被标记为某个类别。比如一张街景图语义分割的结果可能是“天空”“建筑”“行人”“车辆”四个类别每个类别对应mask上一个不同的灰度值或颜色值。做语义分割工作流时重点不在“切”而在标签一致性和类别处理。你训练一个模型最怕的是标签错乱——同一张图昨天标注的人今天标注成了背景模型会学到非常诡异的东西。所以我的语义分割工作流里会专门加一个校验环节用模板自动核查标签名的完整性、类别数量是否与预期一致、mask尺寸是否与原图匹配。另外还要注意输出格式。训练用的 mask 通常是单通道的 PNG而可视化用的 mask 则是三通道的彩色图。如果混用训练时会报错或者模型效果大打折扣。工作流里要明确区分“用于训练”的输出和“用于展示”的输出分别用不同目录存放别搞混。2.4 轻量级工作流的组合逻辑把单个操作串成自动化链路这里我特别想聊一下“轻量级工作流”这个词。现在大家都在强调工作流但很多人理解的工作流是“必须上重型平台”。其实图片处理这种场景完全不需要那么重的依赖更不需要付费的平台。你完全可以只用几个免费开源工具就搭建出一条高效的图片分割流水线。我常用的组合包括Python Pillow负责切割和基础变换ImageMagick的convert和montage命令负责快速批量处理和拼接预览ExifTool负责检查和修改图片元数据。这套组合跑在命令行里轻量、稳定、可控没有任何图形界面的渲染开销做批处理时可以轻松应付上百张图片。如果你的需求涉及到更复杂的智能识别可以再加入 OpenCV 或者一个现成的模型推理框架但核心链路仍然是清晰的“输入图片 → 预处理 → 分割 → 后处理 → 输出”。为什么“轻量”这么重要我的体会是重方案往往意味着更高的维护成本和更多的不确定因素。我曾经试过把切图流程放在一个非常重的自动化平台里结果每次跑任务都要等平台的各种调度器启动出问题的概率比裸脚本高得多。对于图片分割这种输入输出明确、逻辑相对固定的场景最有效的永远是“能跑起来的简单方案”。3. 实操过程与核心环节实现3.1 环境搭建依赖安装与目录规划我们先从一套最常用的方案说起用 Python 写批量切图脚本。不管你用的是 Windows、macOS 还是 Linux这套流程都一样能跑。第一步是准备环境。如果你已经装了 Python 3.8 以上版本直接在终端里执行pip install pillowPillow 是 Python 里最主流的图像处理库对新手友好接口设计也直观。如果后面需要更复杂的图像分析可以再补一个pip install opencv-python安装好依赖之后我强烈建议你规划好目录结构。一个混乱的目录会让任何工作流效率减半。以我的习惯为例一个分割任务的目录长这样segmentation_project/ ├── input/ # 原始图片 ├── output/ # 分割结果 ├── preview/ # 拼接预览图、校验图 └── scripts/ # 处理脚本输入和输出严格分开这是工作流里最重要的一条原则。你永远不应该在原始图片所在的目录上直接做修改否则一旦操作失误原始数据可能就找不回来了。3.2 核心脚本用 Python 实现行列均分切割现在我写一个最简单的切割脚本目标是把输入目录里的所有图片按照指定的行数和列数均匀切割。from PIL import Image from pathlib import Path def split_grid(src_path, dst_dir, rows, cols, margin0): img Image.open(src_path) width, height img.size # 计算每个子图的尺寸 cell_w (width - (cols - 1) * margin) // cols cell_h (height - (rows - 1) * margin) // rows stem src_path.stem for row in range(rows): for col in range(cols): left col * (cell_w margin) upper row * (cell_h margin) box (left, upper, left cell_w, upper cell_h) cropped img.crop(box) out_path dst_dir / f{stem}_{row1:02d}_{col1:02d}.png cropped.save(out_path) print(fSaved {rows * cols} tiles for {src_path.name}) if __name__ __main__: input_dir Path(input) output_dir Path(output) output_dir.mkdir(exist_okTrue) rows, cols 3, 3 margin 0 # 子图间距九宫格场景可以设为10 for src_path in input_dir.iterdir(): if src_path.suffix.lower() in (.jpg, .jpeg, .png): split_grid(src_path, output_dir, rows, cols, margin)这段代码逻辑很直白。核心是img.crop(box)这个方法box 是一个四元组分别表示裁剪区域的左、上、右、下坐标。注意这里计算cell_w和cell_h时做了向下取整意味着如果原图尺寸不能被行列数整除边缘会有一两像素的舍入误差。如果你对精度有洁癖可以将cell_w改为向上取整或者干脆在预处理阶段先把原图缩放到“行列数的整数倍”再执行切割。我自己实践时候的几个心得用stem即不带后缀的文件名做输出文件的前缀保留原始文件名语境。文件名中的行列号建议补零对齐比如01、02这样排序时才不会出现“10”排在“2”前面的尴尬。输出统一用 PNG虽然不是所有场景都需要但 PNG 是无损格式中间产物用无损格式可以避免反复压缩带来的质量损失。3.3 进阶脚本自动寻找空白走廊并分割扫描图接下来进入有点难度但非常实用的场景把一张扫描的文档页或漫画页自动分割成多个独立内容块。核心思路是“找空白走廊”。我先说原理。一张扫描页里文字或画面的区域像素分布是密集的而页边距、分栏间隙这些位置的像素分布非常稀疏。如果把图片转成灰度图然后按行扫描计算每一行的平均像素值你会发现“内容行”的平均值偏离背景色很多“空白行”则非常接近背景色。同理可以按列扫描。基于这个原理我能写一个自动找到最佳切割位置的脚本。from PIL import Image def find_blank_lines(img, axisrows, threshold245): gray img.convert(L) width, height gray.size result [] if axis rows: for y in range(height): row [gray.getpixel((x, y)) for x in range(width)] avg sum(row) / len(row) if avg threshold: result.append(y) else: for x in range(width): col [gray.getpixel((x, y)) for y in range(height)] avg sum(col) / len(col) if avg threshold: result.append(x) return result这是个简化版。阈值 245 表示“像素平均灰度值在245以上才认为是空白”对于白底黑字/黑线的文档这个值可以用。但在真实场景里扫描件会有噪点、纸张底色可能偏黄直接跑这个算法会找到很多“假空白”。我的改进方案是先用一个简单的高斯模糊或中值滤波去掉噪点再计算均值把连续出现空白行的区间合并成一条候选切割线比如连续10行空白只算一条线设置“最短内容块高度”避免把一个小标题或页脚单独切出来切割时沿着找到的候选切割线依次执行crop即可。这一步如果看得不过瘾可以再看看 OpenCV 的投影剖面法本质思路是一样的但用了更高效的矩阵运算处理大图时速度优势很明显。3.4 处理完的后续工序压缩、校验与拼接预览分割完成后工作流还没结束至少还要做三件事。压缩。如果切出来的图要用于网络传输或上传电商平台原始大小通常是不可接受的。一个动辄几兆的详情页分段图传到平台上用户体验很差。压缩时我推荐两个方向一是转成 JPEG 并设置质量参数比如 85这个值基本看不出明显画质损失但文件能小一大半二是用Pillow的optimizeTrue参数它会在保持视觉质量的前提下优化编码参数。实测下来一张商品主图从 2.1MB 压到 300KB 是很常见的结果。校验。批量处理最大的风险是“静默失败”也就是脚本看起来跑完了但某些输出是坏的。我建议在流程里加一个自动校验检查每个输出文件是否非空、尺寸是否符合预期、文件头是否完整。可以用一行命令快速获取所有输出的尺寸信息也可以直接写一个循环做断言。拼接预览。这是给我自己用的也推荐给大家。把切分后的子图按原顺序拼接成一张带边框的预览图你只需要扫一眼预览图就能快速发现切割是否有错位、是否有白边、是否有内容缺失。ImageMagick 的montage命令是这个场景的杀手锏montage output/*.png -tile 3x3 -geometry 22 preview/montage.jpg把3x3换成你的行列数22表示每张图之间加2像素的间距。有了这张预览图检查效率比逐张打开图片高一个数量级。3.5 可视化节点式工作流ComfyUI 等工具怎么融入分割链路说到“工作流”现在很多人的第一反应是 ComfyUI、Dify、Coze 这类可视化流程工具。我必须承认这些工具把复杂逻辑编排的门槛降得非常低。在图片处理领域ComfyUI 这种节点式工具和图片分割的需求其实能结合得很好。拿 ComfyUI 举例。它本身是一个基于节点的图像生成和处理框架每个节点接收输入、处理、输出节点之间通过连线传递数据。在 ComfyUI 里你可以非常直观地搭建出一条分割流水线加载图片 → 图像预处理缩放、裁剪→ 分割可以是传统的网格裁剪节点也可以是调用深度学习模型的语义分割节点→ 后处理遮罩合成、图像保存。这套方案适合什么场景我认为是“需要频繁交互和调参”的场景。比如你在做一个智能抠图服务经常要调分割模型的阈值、调整边缘羽化的强度这时候图形化节点的优势就出来了——你不需要改代码拖一个节点、改一个参数就能立刻看到效果非常适合快速迭代。但我也要说句实在话。如果只是批量做固定规则的切图ComfyUI 反而显得笨重。每次都要打开界面、加载工作流、连节点这种固定流程的操作效率往往不如一句命令行脚本跑得快。所以我的建议很明确探索阶段用可视化节点固化阶段用脚本这才是两条腿走路。3.6 自动化批量处理定时任务与文件夹监听“高效工作流”的最终形态是连执行指令都不需要手动触发。如果你经常处理同样的分割任务可以再加一层自动化。Windows 上可以用任务计划程序macOS/Linux 上可以用 cron来定时执行已经写好的 Python 脚本。比如每天晚上自动处理当天上传到某个目录的所有图片。这种方式特别适合那些有固定流水需求的场景每天固定有多少张图片要处理、处理规则完全不变。如果你希望系统更智能一点即“一旦有新文件放入某个目录立即触发处理”可以用文件夹监听脚本。Python 里有个watchdog库专门干这个事运行一个后台服务监控文件夹变化发现新文件就立刻执行分割逻辑。pip install watchdogimport time from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class ImageHandler(FileSystemEventHandler): def on_created(self, event): if not event.is_directory: print(fNew file detected: {event.src_path}) # 在这里调用你写的分割函数 if __name__ __main__: observer Observer() observer.schedule(ImageHandler(), pathinput, recursiveFalse) observer.start() try: while True: time.sleep(1) except KeyboardInterrupt: observer.stop() observer.join()这里面最需要注意的是幂等性设计。同一个文件如果被监听到多次脚本要有能力判断“这个文件我处理过了”否则会产生重复输出。我常用的做法是在处理完图片后把文件名记录到一个日志文件或数据库中下次再遇到同名文件就跳过。4. 常见问题与排查技巧实录做图片分割这么长时间我踩过的坑、趟过的雷绝对不算少。下面这几类问题是最高频的我把成因和解决方案一并写清楚你可以直接当参考资料用。4.1 分割线模糊与边缘残影问题现象切出来的子图边缘发虚有半透明的像素残留拼接回去后原图里的清晰线条在接缝处变成了模糊的渐变色带。成因图片在保存或传输过程中经过了有损压缩比如 JPEG 在压缩时会丢失高频细节导致锐利边缘附近出现“振铃效应”或色块扩散。如果你用一个阈值判断边缘位置很容易把这圈模糊像素留进子图。解决方案分三步走。在分割之前做一次轻微锐化让边缘恢复清晰。如果有条件分割的中间过程尽量用无损格式PNG、TIFF保存不要在每次保存时都压一遍 JPEG。如果你要发到网上的最终产物是 JPEG等到所有处理完成后再统一导出为 JPEG。如果是从先前的有损文件里切可以考虑对边缘做 1 到 2 像素的内缩裁剪把模糊区域丢掉。虽然损失了极少的边缘内容但视觉上会显得干净得多。4.2 批量处理后发现个别图片切割偏移现象90% 的图片都切得整整齐齐但有个别图片的内容明显偏向一侧或者子图里有大片空白看着很不协调。成因这类问题九成出在“原图尺寸不一致”或“原图内容本身就没居中”上。比如一个批量任务里大部分图片是 1000x1000 的但混进来一张 1000x800 的按同样参数切割时下边缘的空白就会明显偏多。另外有些图片的内容本来就在画布的一侧等分切割自然会导致切出来的内容分布不均匀。解决方案批量处理前加一步“尺寸检查画像”先统计所有图片的尺寸分布把异常尺寸的图片单独拎出来处理。对需要严格居中的场景先“内容感知居中”再切。简单做法是先用边缘检测找到内容实际边界然后把内容自动平移到画布中央再执行切割。这个逻辑在 OpenCV 里几十行代码就能实现。更稳妥的做法把尺寸异常的文件单独放到input_exceptions/目录提示你人工处理而不是让它在批处理流水线里“静默出错”。4.3 色彩还原与配置文件的坑现象切出来的子图颜色感觉比原图淡了或者拼接到网页/App 上时颜色偏色。成因最常见的原因是色彩配置文件丢失或转换错误。原始图片可能内嵌了 sRGB 或 Adobe RGB 的 ICC 配置文件但切割保存时某些库默认不保留色彩配置信息同一张图片在不同设备上就被解释成了不同的颜色。另一个常见原因是 PNG 和 JPEG 对透明度、颜色空间的处理不同把带透明通道的图保存成 JPEG 时透明部分会变成黑色或白色。解决方案在输出时显式指定色彩空间。用 Pillow 处理时可以先把图片convert(RGB)再保存同时将 ICC 配置文件嵌入输出文件。如果最终产物是给 Web 用的应统一转换为 sRGB这是互联网设备的默认标准。透明图像的切割要保留 Alpha 通道时务必使用 PNG如果必须输出 JPEG先决定透明区域的底色并做“拼底”处理再保存。最后用浏览器或专业的看图软件批量预览一遍人眼这个时候比什么参数都靠谱。4.4 中间产物与最终产物混放的教训现象工作流跑完后输出目录里一堆文件有中间过程的临时图、有压缩前的原始切割结果、有最终的成品分不清哪些该交付。成因这纯粹是流程设计问题没有把中间产物和最终产物在物理上隔离开。解决方案我用了一个非常简单但有效的方法——目录后缀区分法。中间产物统一放在output/_tmp子目录最终产物统一放在output/final子目录。脚本每次运行的第一步就是把旧的_tmp清空保证不会再看到上次的残留文件。最后交付时只压缩final目录即可既不会漏也不会多。4.5 常见问题速查表这里我把上面的问题整理成一张表方便你保存和查阅问题现象首要怀疑方向快速解决动作拼接有断线/白边边缘压缩伪影切图前锐化中间过程用 PNG个别图片切歪原图尺寸不一致先统计尺寸异常文件单独处理输出颜色不一致缺少ICC配置统一转 sRGB嵌入配置文件透明区域发黑/发白透明通道处理错误用 PNG 保留 Alpha或先拼底文件名排序错乱命名未补零对齐改成01、02格式文件处理过一次又处理缺少去重逻辑加日志记录已处理文件名切出来的图空白过多内容未居中用内容感知检测并居中后再切目录里全是一堆同名文件未区分中间/最终产物分目录存放交付前清空临时目录5. 一些掏心窝子的补充说明走到这里一套图片分割的高效工作流已经完整呈现了。但我还是想再补几句实际操作中的真实感受这些是教程里不会写、但实战中真的会让你少走弯路的经验。第一工具永远是辅助明确需求才是核心。我见过太多人花了很大力气学会了一堆切图工具结果连“等分切”和“内容切”都没区分做出来的东西完全不是需求方想要的。拿到任务时先花五分钟把“目标是什么”“边界在哪”“异常怎么处理”这三个问题想清楚比什么技巧都值钱。第二自动化不是目的可控制才是。不要为了“自动化”而自动化如果你的图片每周只有三张手动处理就好没必要搭一套监听脚本。真正值得自动化的场景是那些每周几百张、规则稳定不变、异常率极低的任务。自动化上线前一定要保留手动的覆盖通道我是说万一脚本出 bug你还能靠手动把活干完不至于在交付时间点上抓瞎。第三版本管理不丢人。不仅代码要放进 Git处理脚本的依赖版本也建议固定住。图片处理库的 API 更新很快今天能跑的脚本过几个月可能因为依赖升级就跑不了了。把环境版本记录下来至少能保证半年后你还能复现今天的处理结果。最后再分享一个我自己的小习惯每次完成一个分割任务我会顺手把处理参数行列数、压缩质量、阈值、缩放比例写在一个README.md里和输出文件一起打包交付。这样做的好处是下次客户或者同事问“这批图怎么切的”我不需要去翻聊天记录直接看 README 就能把整个处理链路完整复述出来。这个习惯帮我省了非常多事后沟通的时间你也可以试试。图片分割本身不难难的是把分割这件事放到整个工作流里去思考。当你开始关注“输入是什么、输出给谁、异常怎么处理、过程怎么复用”这些环节时你已经不是在“切图”了而是在设计一套解决问题的流程。这套思维比任何具体工具都值钱得多。