AI线稿转矢量：39个产品实战复盘与防驳技巧

为什么AI生成的线稿总是跟你作对

当你用AI图像模型生成线稿时，得到的通常是一张1024×1024的PNG位图，边缘带有抗锯齿效果。而抗锯齿恰恰是干净矢量描摹的天敌。预览图里看起来一条自信的三像素粗线，实际上是从纯黑到近乎白色的灰度渐变像素带。

我试过的每一款描摹工具，包括大多数人用的默认设置，都会把这个渐变解读为多条嵌套路径。结果就是，一条粗描边最终被描成了两三条细如发丝的同心轮廓线。在100%缩放的屏幕上根本看不出来，但到了印刷尺寸，或者审核员放大检查时，问题就暴露无遗。

我收到的第一封拒绝邮件就来自Adobe Stock，一次性驳回了11个线稿矢量文件，理由全都是同一条：线宽与预览不符。那批文件花了我六个小时制作，被拒只用了大约四分钟。

最有效的修复不需要任何成本：在描摹之前对图像做阈值处理。我先转为灰度图，然后在128附近做二值化，让每个像素非黑即白。没有渐变，就没有嵌套路径。仅这一步就把我的线稿驳回率从大部分批次降到几乎为零。

抗锯齿（Anti-aliasing） 是渲染引擎为减少锯齿边缘而故意引入的平滑技术：它在图形边界处按覆盖率混合前景色与背景色，生成中间灰度的像素过渡带。这一机制让屏幕上的曲线看起来更自然，却给矢量描摹带来结构性困难。

位图与矢量的本质差异在于：位图用像素网格记录颜色，放大后像素随之放大，边缘渐变带也被放大成可见的模糊；矢量用数学路径描述形状，可无限缩放。描摹算法试图从位图像素反推出数学路径，当遇到抗锯齿形成的灰度渐变时，常见的做法是按等值线（iso-value）提取轮廓——不同的灰度阈值就会截出不同位置的轮廓线，于是一条带渐变的粗线被解读为多层嵌套路径。

二值化（Thresholding） 正是对此的针对性预处理：将所有像素强制归为纯黑或纯白两类，消除中间灰度，使描摹算法只面对一条明确的边界，从而输出单层、干净的路径。阈值取128是常见起点，因为它是8位灰度范围（0–255）的中点。

分辨率比描摹参数更重要

我犯的第二个错误是直接从1024像素的输出进行描摹。1024像素的图像转成矢量后，任何曲线都会出现明显的拐角伪影。我现在的做法是先上采样到2048像素再做二值化，这样能平滑锯齿，又不会凭空捏造模型根本没画的细节。超过2048像素后我观察不到更多改善，只是描摹时间更长而已。

在1核CPU、2GB内存的服务器上，这一点很关键。上采样加描摹一张2048像素的图像，根据路径数量不同，内存峰值大约在400到600MB之间。这刚好放得下。两个并行就放不下了，OOM Killer会随机杀掉其中一个进程。所以流水线一次只处理一张图，每处理完一个资源就调用gc.collect()，同时通过resource.getrusage(RUSAGE_SELF).ru_maxrss监控真实的内存上限，而不是凭感觉猜。重型渲染步骤每个文件单独起一个子进程，确保内存真正归还给操作系统。

上采样（Upsampling） 指通过插值算法提高图像像素分辨率，例如从1024像素放大到2048像素。它并不创造新的真实细节，但能改变像素网格与曲线边界的对齐关系，使原本粗粝的锯齿在更高密度下被重新采样为更平滑的过渡，描摹算法由此更容易拟合出连续曲线而非折线。

OOM Killer 是Linux内核的内存溢出保护机制：当系统物理内存与交换空间耗尽时，内核会依据 oom_score 选择并强制终止某个进程以保全系统。它杀哪个进程带有随机性，因此“两个并行任务刚好撑爆内存”会导致不可预测的生产中断。

ru_maxrss 是 resource.getrusage(RUSAGE_SELF) 返回的峰值常驻内存（resident set size）字段，单位为KB（Linux）。用它监控进程峰值内存比观察 top 的瞬时值更可靠，因为后者会错过短时的高峰。Python的 gc.collect() 只能回收循环引用对象，将内存交还给分配器，而操作系统不一定立即收回；因此重型步骤放入独立子进程，进程退出时内存才能被操作系统彻底回收。

描边宽度是主动决策，不是意外结果

描摹完成后，路径是有了，但线宽完全取决于描摹算法的输出。审核员会把矢量和预览图逐一比对：如果预览显示的是一条粗壮的三像素描边，矢量渲染出来却是发丝线，那就是不匹配，直接驳回。反过来也一样，矢量太粗而预览太细，同样出局。

所以我把描边权重变成了每个产品线的一个显式参数。花卉系列用一个权重，曼陀罗系列用另一个，同一个系列里每个文件都保持一致。我在描摹后的SVG里按点（points）设置描边，并且从同一个SVG渲染预览图。预览和产品来自同一个真实来源。在这之前，我从原始PNG渲染预览，提交的矢量却用不同权重，这恰恰就是那封拒绝邮件里描述的失败原因。

还有一个我吃了亏才学会的规则：导出前把描边转为轮廓（expand strokes）。Adobe和Vecteezy对描边路径的处理方式不一致，取决于它们的预览管线如何栅格化。转为轮廓后在任何平台上渲染结果都一致。文件会大一些——我的SVG平均从大约40KB涨到了90KB——但转为轮廓的文件没有一个因为渲染差异被驳回。

描边（Stroke）与轮廓（Outline） 是矢量图形中两种不同的表达方式：描边是沿路径中心线施加的一条有宽度的线，宽度独立于路径几何；轮廓（也称展开描边、expand strokes）则是把这条有宽度的线转换成填充路径，几何边界被固化为实际形状。

区别在于渲染一致性。描边路径的最终外观由渲染引擎决定——不同的平端帽（butt cap）、圆角连接（round join）、斜接限制（miter limit）乃至半像素栅格化规则，都会导致同一条描边在不同平台上呈现不同宽度或端点形状。平台的预览管线与作者的导出环境不一致时，审核员看到的渲染结果就可能与预览不匹配。

转为轮廓后，线宽成为几何的一部分，任何引擎渲染同一填充路径都会得到相同结果。代价是路径节点和文件体积增加，因为描边每一侧的边界都需要被显式记录，这也解释了SVG从约40KB膨胀到约90KB的现象。

元数据和上传台账

让矢量文件被接受只是一半的工作，另一半是不在上传环节掉链子。我用的三个渠道都会因为CSV表头写错而瞬间拒绝：Adobe要5列，Vecteezy要4列，Dreamstime要15列。我写了make_metadata.py，从文件夹文件列表直接生成对应的表头格式，从此不再因为格式错误浪费上传次数。

更危险的失败来源是我自己。重复提交一个批次是最快被平台标记账号的方式，而在一个睡眼惺忪的早晨用重跑脚本，这种事太容易发生了。upload_tracker.py就是一个朴素的台账，记录我已经发布过的内容。重跑时会自动跳过已完成的项目，而不是重复上传。这个工具很无趣，但它保护我账号的功绩，可能比那些描摹修复加起来还大。

图库平台对CSV元数据表头有严格校验，因为上传系统通常按列索引而非列名解析。Adobe Stock要求5列（如Filename、Title、Keywords等），Vecteezy要求4列，Dreamstime要求15列且顺序固定。一旦列名拼写、数量或顺序不符，整个批次会被立即拒绝，且往往不给出详细错误，消耗的只是上传配额。

上传台账（Upload Tracker） 是一种幂等性设计：通过持久化记录已成功发布的内容（通常以文件哈希或产品ID为键），使重跑脚本时可以跳过已完成项，只处理增量。它解决的是分布式提交中典型的“至少一次”与“恰好一次”问题——网络超时或人工重试都可能造成重复提交，而图库平台通常把重复提交视为垃圾行为并触发账号风控。

md2pdf 则涉及Markdown到PDF的转换管线，常见实现是先将Markdown解析为HTML，再通过无头浏览器或排版引擎（如WeasyPrint）渲染为PDF，以便把文档包装成可出售的数字产品。

数据与工具沉淀

39个成品、约856MB打包输出，描摹步骤在同样的1核CPU机器上降到每张图大约两分钟，单进程，无GPU。线稿批次的驳回率从大部分被拒降到每百个文件只有几个。支撑这一切的母流水线大约有19000行Python代码，而这篇文里提到的规则，都是在代码层面强制执行的，不是靠我脑子里记住的。

整套系统跑在Python 3.9上，总共只用了两个第三方包。没有云账号，没有GPU，没有框架。

我本来没想写工具包。我只是想发出39个产品，这些脚本是剩下的东西：make_metadata.py负责三种CSV格式，upload_tracker.py负责台账，md2pdf.py把文档转成可出售的PDF，pack_product.py负责打包文件并附带1280×720封面和600×600缩略图。它们就是我今天仍在用的工具。