做过十年以上外包和甲方对接的人，大概都经历过同一个尴尬时刻：你花一个下午生成了十二张漂亮的 AI 配图，客户看着很满意，第二天丢回来一句”能不能把背景那三个小方块改成我们品牌蓝，再把这组图标复制一套放 PPT 里”。于是你打开源文件，发现拿到的是 2048×2048 的 PNG。改色要重新描，复制要重新画，最后那张所谓的”AI 设计稿”变成了贴在画布上的底图，设计师成了抠图工。
这不是生成质量的问题。今天的文生图模型在构图、光影、质感上早已越过”像不像”的门槛，真正的瓶颈在我们很少认真讨论的一环——交付格式。一张图是像素还是矢量，是扁平位图还是带分组层级的结构化对象，决定了它在产业链里是一次性消耗品，还是可复用资产。这也是我写这篇文章的原因：把 Recraft 的原生 SVG 生成，和 Next AI Draw.io 的自然语言架构图这两条路径放在一起看，你会发现它们解决的是同一个问题的两个侧面——让 AI 产出的东西直接可编辑。
下文分上下两篇。上半篇讲 Recraft 的原生矢量：怎么验证真假矢量、怎么批量出图标套件、怎么用 Brand Kit 锁死品牌色、长文本怎么排、SVG 落到 Illustrator 和 Figma 里还能做什么，以及什么时候你反而应该老实回去用位图模型。下半篇讲 Next AI Draw.io：怎么部署、提示词怎么结构化、手绘白板怎么复刻、draw.io XML 为什么比 PNG 更适合工程协作。最后有一张分工表和一张交付格式选择表，可以直接拿走用。
一、AI 设计的真正瓶颈不是生成质量，而是交付格式
2026 年的文生图模型，随手一跑就能出杂志级封面。但你在商业项目里交付的东西，要经过的工序远不止”生成”这一步：客户要改 Logo 颜色，运营要把它塞进 Banner 的不同尺寸，开发要把它做成页面上的图标组件，产品要把它放进 PRD 里配图说明系统架构。每一道工序都在问同一个问题——你能给我什么格式？
PNG 是终点站。它只有一层信息：像素的颜色。你给不出笔画，给不出层级，给不出字体。想改一个图标的描边粗细，没有捷径。JPG 更糟，还带压缩噪点。而 SVG 是中途站，展开是一份可读的 XML，里面有 <path> 的贝塞尔控制点、有 <g> 分组、有 fill 和 stroke 的明确声明。这些信息意味着下游任何一个环节都能以结构化的方式继续修改，而不是以视觉近似的方式重新创作。
我见过太多团队把”AI 生成”当成一次性玩具，原因就在这里：他们拿到的永远是像素稿，于是 AI 在流程里只能待在”灵感参考”这个角落，进不了正式交付。而当生成模型能直接给你原生 SVG，AI 的位置就从”参考图工具”挪到了”生产工具”。这个位置的转换，比模型参数涨多少都重要。
1.1 为什么”可编辑”比”好看”更值钱
算笔账。一个 SaaS 产品要做一套 40 枚功能图标，传统流程是设计师画 2 天，或者买一套图标库授权 300 到 800 美元，然后遇到第 41 个新功能又要重新找。用 AI 生成位图，你要挨个抠图重绘，等于没省。用 AI 生成原生 SVG，40 枚图标生成、挑、改色、整理分组，一个下午能收工，而且每一枚都能立刻在 Figma 里改描边、在 Illustrator 里改锚点。可编辑性直接换算成工时，这就是它值钱的地方。
更进一步，可编辑意味着可复用。同一枚图标，在官网是 24px 线性版，在 App 里是 20px 面性版，在印刷物料上是 3mm 描边版。有原生 SVG，这些变体是参数调整；只有 PNG，这些变体是三次重做。长期看，资产的可编辑程度决定了它的折旧速度。
二、Recraft：把”原生矢量”当作第一性原理的模型
Recraft 是少数从一开始就把矢量当核心输出的模型，而不是把位图生成完再”矢量化”一遍。它的版本节奏值得记：V4 在 2026 年 2 月发布，V4.1 在 2026 年 5 月 14 日更新，重点提升了照片真实感、渐变渲染和短提示理解——这三点看着像常规迭代，但对做商用素材的人来说很关键，短提示理解变好意味着你不用再堆砌一长串修饰词，一句话就能拿到可用构图。
V4.1 同期新增了两个变体：Utility 与 Utility Pro。这两个变体的定位很有意思，平光、正面构图、简洁受控场景，天然适合做样机展示和产品图，因为它们的画面没有被戏剧性光影干扰，后期合成时更容易处理。而 Utility Pro 在 Artificial Analysis 的榜单上，是除 Google 和 OpenAI 之外排名最高的文生图模型，这个成绩单说明它在综合生成质量上已经进入第一梯队，不是只靠”能出矢量”这一条腿走路。
但对我们这些关心交付的人来说，Recraft 最值钱的能力只有一个：它输出的 SVG 是真 SVG，不是把位图包一层标签的伪矢量。这一点必须展开讲，因为市面上混淆视听的产品太多了。
三、原生矢量 vs 伪矢量：三步验证法
你会在很多工具的介绍页看到”导出 SVG”四个字。但导出 SVG 和生成矢量是两回事。前者只是把一张位图塞进 <image> 标签，再用 SVG 外壳包起来；后者才是把画面拆成一条条路径、一个个几何基元。
3.1 第一步：看文件体积与内部结构
把 SVG 拖进文本编辑器，或者浏览器里看源码。如果里面只有一个 <image xlink:href="data:image/png;base64,...">，恭喜你，你拿到的是一张换皮的 PNG，文件体积通常大得离谱（几百 KB 到几 MB 的 base64 字符串），而且这在 Illustrator 里点选时只会有”一个对象”。真正的原生 SVG 打开来看，是密密麻麻但结构清晰的 <path d="M ... C ... Z">、<rect>、<circle>、<ellipse>，体积通常只有几 KB 到几十 KB。
3.2 第二步：在 Illustrator 里点选一个元素
这是最直观的验证方式。用 Illustrator 打开，选择工具点一下画面里某个色块，看它是被单独选中，还是整个画面一起选中。原生 SVG 里，每个色块、每条描边都是独立对象，你可以拖动、可以改 fill、可以单独给某个分组加图层名。伪矢量只能整体选中，改色等于把整张图的色调拉一遍。
在 Figma 里同理：导入 SVG 后，右侧图层树会展开成多个 vector 图层，每个都能单独调填充。如果只有一个 image 图层，那就是伪矢量。
3.3 第三步：拔掉位图引用，看画面是否还在
技术流做法：在代码里把 <image> 标签整段删掉，或者把 base64 换成空。真矢量会毫发无损——路径数据不依赖任何外部资源。伪矢量会瞬间变成空白，因为它的视觉信息全在那串 base64 里。这一招我称之为”拔管测试”，百试百灵。
原生 SVG 的内部还包含明确的分组层级：一组描边通常被包在一个 <g> 里，一个图标套件的多个图形按语义归类。带明确的填充与描边声明、含贝塞尔曲线、直线、圆弧、矩形和圆形基元——这句话听着像参数说明，实际上是矢量文件能不能被逐元素编辑的技术前提。没有这些，下游的改色、缩放、组件化都是空谈。
3.4 一个需要诚实说明的边界
原生 SVG 并不是万能的。Recraft 在简单几何构图上出图最干净——图标、扁平插画、少色 Logo，这些画面由几十到几百条路径构成，结构清晰，改起来顺畅。但如果你要生成一张照片级的复杂场景，路径数量会膨胀到几千上万条，很多是 AI 推算出来的色块拼接，虽然理论上仍然可编辑，实际上复杂到没人愿意手动调。所以我的经验是：需要用矢量交付的，就让提示词引导到扁平、几何、少色的方向；需要照片质感的，老老实实用位图模型，别强求矢量。这个判断能省掉大量返工。
四、Recraft 图标套件的批量生成方法与提示词模板
图标是原生 SVG 最典型的高价值场景，因为它的结构简单、可编辑性强、复用率高。但直接一句”generate a set of icons”通常拿到的是风格不统一、描边粗细不一致的一堆散件。要做成一套可交付的图标库，提示词必须锁三样东西：风格框架、构图约束、输出方式。
4.1 为什么批量生成必须锁风格
AI 对”风格”的理解是概率性的。你说”线性图标”，它可能给你 1.5px 描边，也可能给你 3px 描边；可能圆角端点，也可能方角端点。一套图标里混两种描边，视觉上立刻散架。解决办法是把这些参数显式写进提示词：描边像素值、端点形状、圆角半径、网格尺寸、留白比例。写成清单，模型就收敛了。
另一个容易被忽略的点是画布一致性。24×24 的统一画布，图标主体居中，四周留 2px 安全边距，这样在 Figma 里排成组件时对齐不会歪。这个约束必须写进提示词，否则每张图的构图比例都不一样。
4.2 可直接复用的提示词模板
下面是我在项目中反复调过的一套模板，按功能分组生成，一组 6 到 8 枚，最后再统一整理成一套。分组生成的好处是每组内风格一致性最好，缺点是需要多跑几次——所以额度规划要提前做。
【Recraft 图标套件生成模板 · 线性风格】
Style preset: Icon set / Vector art（输出原生 SVG）
Canvas: 24×24 px, 统一网格, 主体居中, 四周 2px 安全留白
风格框架（必须逐项锁定）：
- 线性图标, 描边宽度 2px, 圆角端点(round cap), 圆角连接(round join)
- 统一使用 #2B2B2B 作为描边色, 不使用渐变
- 几何极简, 禁止阴影、禁止高光、禁止纹理
- 图形主体占画布 20×20 区域, 视觉重心居中
本轮生成主题（电商后台图标组）：
1. 订单列表 2. 库存仓库 3. 物流卡车 4. 退款箭头
5. 优惠券 6. 数据分析图表 7. 客户头像群 8. 设置齿轮
输出要求：
- 每个图标独立成图, 保持同一视觉重量
- 仅输出矢量, 不输出位图
- 全部图形可逐元素编辑, 保持分组层级跑完一组后，不要急着全量生成剩下的。先把这 8 枚导入 Figma，检查描边是否真的都是 2px，端点是否一致，视觉重量是否均匀。确认风格稳定后，再接下一组。如果第一组就偏了，改提示词重跑比后面批量返工便宜得多。
4.2.1 面性图标与双色调图标的变体写法
面性图标（solid）的把描边改成填充，stroke 换 fill，并增加”禁止内部镂空线条”的约束，否则模型会在实心图形上画回描边细节，导致路径冗余。双色调（duotone）则要在提示词里指定两个颜色角色：主色和辅助色，比如主色 #1A56DB 覆盖 70% 面积，辅助色 #BFD3F8 覆盖 30%。双色调图标在原生 SVG 里最好整理，因为每个色块天然是一个分组，批量改品牌色时替换一个色值就行。
4.2.1.1 关于”是否给每枚图标单独命名”这件事
Recraft 生成的 SVG 里，图层名通常是自动生成的。真正要做的整理工作发生在前端或 Figma 里——导入后用图标语义重命名每个组件（icon-order-list、icon-stock-warehouse）。这看着像杂活，但决定了三个月后新来的设计师能不能在组件库里搜到东西。可编辑交付物的价值，有一半在命名。
五、Brand Kit：把品牌色锁进生成流程
跨团队协作最耗时的不是创意，而是对齐颜色。市场部要 #1A56DB，产品部用了 #2563EB，运营物料又来个 #1E40AF，三个蓝色放在一起开会时能吵半小时。Recraft 的 Brand Kit 就是解决这个问题的机制：把企业的 RGB 色值、插画规范、Logo 规则预先内置，之后所有生成都受这套约束。
它的实际价值在”批量一致性”上。当你有 30 枚图标、5 张插画、1 个 Logo 变体要出的时候，手工逐张调色是灾难。Brand Kit 锁定后，生成的图标套件、插画、Logo 都带着同一套品牌色和同一套线宽规范，视觉上天然统一。这是我见过的、在 AI 工作流里最实用的一项团队功能，因为它把”品牌规范”从一份 PDF 文档变成了生成时的硬约束。
5.1 Brand Kit 应该锁哪几项
我的建议是锁四个层次：主色与辅助色（RGB 值精确到个位）、描边宽度规范（比如线性图标统一 2px）、圆角半径（统一 2px 或 4px）、以及插画的视觉语言（扁平有无投影、是否有纹理）。前两项对图标套件最关键，后两项对插画和海报类素材最关键。Logo 单独建一个规则集，因为 Logo 对安全边距和最小尺寸有额外要求。
锁完之后要注意一点：Brand Kit 约束的是”可用的颜色池”，不是”必须用的颜色”。提示词里仍然要明确指定这枚图标用主色还是辅助色，否则模型会在色池里随机挑，出来一套颜色乱跳的图标。
六、长文本渲染：为什么大多数模型做不到，Recraft 怎么做到了
文生图里最难的部分之一不是画，是写字。绝大多数模型渲染文字只能应付一两个单词的海报标题，一长就变鬼画符。这对做商业物料的人是致命的，因为海报、Banner、信息图里都有成段的文字。
Recraft 在这块的策略不太一样：它支持长文本渲染，不止一两个词；可以指定字号与位置；接入了 1500 多个 Google Fonts 字体；可控字重、行高、字距、颜色、对齐。这几个参数组合起来，意味着你能让它生成一张”排版基本成立”的图，而不是一堆乱码需要后期全抹掉重排。
6.1 长文本提示词的写法
关键在于把排版信息结构化。不要写”一张促销海报，上面写着醒目的文字”，要写成”主标题 XX，字号 72，粗体，居左；副标题 XX，字号 24，常规，居左，行高 1.5；底部标签 XX，字号 14，全大写，字距 +2″。把字号、字重、行高、字距、对齐逐项列出来，模型才有据可依。字体名可以直接指定 Google Fonts 里的具体字体，比如 Inter、Noto Sans SC、Playfair Display。
另一个经验：中文长文本比英文更容易翻车。如果物料是中文，尽量把文字量控制在一两句，长段落文案还是留给后期排版软件处理——AI 生成的原生 SVG 里文字可能是路径化的，虽然视觉上正确，但改字要重新生成，不如在 Illustrator 里排。
七、SVG 导出后的二次编辑：Illustrator 与 Figma 实操
生成只是上半场，导出到设计工具里怎么用才是下半场。Recraft 导出 SVG 后，进入 Illustrator 和 Figma 的编辑路径略有不同，但核心逻辑一样：把 AI 生成的图形当作素材，而不是成品。
7.1 Illustrator 里的清理三步
第一步，打开 SVG 后执行”对象 → 路径 → 清理”，去掉多余的孤立点和重复锚点，AI 生成的路径常有微小冗余。第二步，用”释放复合路径”处理带孔洞的图形，确认孔洞是真正的复合路径而不是叠了两个色块。第三步，整理图层和分组，按语义重命名。这三步做完，SVG 才能进组件库。
改品牌色时，用”编辑 → 编辑颜色 → 重新着色图稿”可以一次性把所有同色系的路径映射到新的品牌色，比逐个点选快得多。前提是前面的分组整理做好了。
7.2 Figma 里的组件化路径
Figma 导入 SVG 后会自动变成 vector 图层，可以直接用布尔运算合并、用”轮廓化描边”把描边转成填充（这对最终产物很重要，因为描边在不同渲染引擎里的表现会有差异）。接着把它做成组件，建立尺寸变体（16/20/24/32），再用颜色变量控制填充色，这样切换品牌主题时整个图标库一起变。
这套流程跑通之后，AI 生成的图标和设计师手绘的图标在组件库里没有任何区别——这才是”可编辑交付物”的终点：不是”AI 出的图能改”，而是”AI 出的图和人工产物一样标准”。
7.3 SVG 导出的参数选择
导出时尽量选”优化过的 SVG”或”保留图层结构”，避免”扁平化”。如果工具有”是否转曲文字”的选项，看用途：要做图标就转曲（避免字体缺失），要做可编辑模板就保留文字。
八、什么时候你反而应该回去用位图模型
我见过最大的误区是把”原生 SVG”当成政治正确，什么图都想出矢量。这会导致严重的质量问题。以下几种情况，请老实回到位图模型（Midjourney、Flux、Recraft 的照片模式都可以）：
8.1 照片级写实场景
产品实拍、人物肖像、场景氛围图。这类画面信息密度太高，矢量化的结果是路径爆炸，文件几十 MB，改一个细节要动几百个锚点，没有人会真的去编辑，那矢量就失去了意义。这种情况下 PNG/JPG 更实在，因为下游根本不需要改结构，只需要用图。
8.2 复杂光照与材质表现
金属反光、玻璃折射、布料纹理、烟雾水花。矢量擅长的是纯色和渐变，不擅长表现材质的细节层次。强求矢量化只会得到一堆色块拼接，远看还行近看崩。
8.3 需要 AI 生成后直接投放的广告图
如果这张图的下游是直接投放，中间没有人会编辑它，那 PNG 就够了，省下的时间可以多做几版。判断标准很简单：这张图在交付后的 30 天内会被改几次？不会被改，就用位图；会被反复改，就用矢量。
九、Recraft 定价与选型：从免费档到企业版
定价这块建议算清楚再选，因为免费档有一个容易被忽略的限制：不授予商用权。这意味着你用它做客户项目、做产品素材、做对外发布的任何东西，都是有风险的。免费档每日大约 30 次生成额度，适合学习和试水，不适合产出交付物。
| 档位 | 价格 | 额度与核心权益 | 适合谁 |
|---|---|---|---|
| Free | 0 | 每日约 30 次生成；不含商用权 | 个人试水、学习手感、临时参考图 |
| Pro | 年付约 $10/月 | 含商用权；额度大幅提升；解锁更多模型变体 | 自由设计师、独立开发者、小工作室 |
| Teams | $55/席/月 | 共享工作区；共享额度；团队级 Brand Kit 管理 | 3 人以上设计团队，需要统一品牌资产 |
| Enterprise | 定制报价 | API 接入、SSO 单点登录、审计日志 | 中大型企业，需接入自有系统或合规审查 |
选型逻辑很清楚：单人做商用，Pro 年付 $10/月性价比最高，一天几毛钱换掉一个图标的绘制工时。团队只要超过三个人，Teams 的共享工作区和共享额度就值回票价，因为品牌资产分散在每个人账号里是典型的协作灾难。企业要接自有系统、要过安全合规，直接看 Enterprise 的 API 和 SSO。
还有一个常被忽略的账：Pro 的商用权意味着你能把生成的 SVG 放进客户交付包里。没有商用权的素材，严格意义上不能出现在客户项目中——这个风险成本远比 $10 高。
9.1 上半篇小结：原生 SVG 改变了什么
Recraft 这一侧的核心贡献，是把”AI 生成”从视觉终点挪到了工序起点。原生 SVG、Brand Kit、长文本渲染、1500+ 字体，这几项能力拼起来，得到的是一个能直接进设计系统的素材源，而不是一堆需要重画的参考图。但图标、插画、Logo 只是设计交付的一部分。产品、研发、架构这三类人真正需要可编辑的东西，是另一类——架构图。这就引出下半篇。
十、Next AI Draw.io：让架构图也能用自然语言生成
架构图是技术团队最常画、也最容易过期的文档。一张系统架构图从画完到失效，往往只有一个月。原因不是图画得不好，而是画的成本太高：打开工具、拖组件、拉线、对齐、调色，一个下午就没了。于是图画得越少，文档就越落后。
Next AI Draw.io 的思路是把这层成本砍掉。它是一个基于 Next.js 的开源项目（github.com/DayuanJiang/next-ai-draw-io），是 draw.io 的 AI 增强版，深度集成了 diagrams.net 的完整渲染能力。你用自然语言描述系统结构，它生成标准的 draw.io XML 并在网页上渲染出来。你可以在画布里继续拖拽调整，也可以直接导出 diff 友好的 XML 进版本库。
这个组合的关键在于下半句：输出的是标准 draw.io XML，而不是一张图片。这跟 Recraft 的原生 SVG 是同一个逻辑的两个实例——交付物要可编辑，而且是在目标工具里可编辑。
10.1 为什么”能渲染”还不够，”能导出 XML”才是重点
很多 AI 画图工具能出一张看起来不错的架构图，但导出的是 PNG。这等于把图钉死在某个时间点。系统迭代后，你要么重画，要么在图上贴补丁。而 XML 是可读的结构化数据，节点、连线、标签都是独立对象，改动是增量式的。
这才是”可编辑交付物”在工程语境下的真正含义：不只是人能编辑，工具链也能编辑。
十一、部署三选一：Vercel、Railway 与 Docker 自托管
开源项目的第一道门槛永远是部署。Next AI Draw.io 支持三种路径，选哪条取决于你的团队有没有数据和网络的顾虑。
11.1 Vercel 一键部署：最快上手
仓库里带 Vercel 部署按钮，点一下、绑定账号、填几个环境变量，几分钟就有公网地址。适合个人或小团队快速试用。注意要配一个支持视觉理解的模型 API Key，因为手绘草图复刻这个功能需要模型能”看图”。
11.2 Railway 部署：省心但有成本
Railway 的部署体验类似 Vercel，容器化更彻底一些，适合需要长期运行的场景。费用按用量计，小团队一个月通常几美元到十几美元。
11.3 Docker 自托管：数据不出内网
如果架构图涉及系统拓扑、内网域名、数据库结构，这些属于敏感信息，很多公司的安全策略不允许上传到公网服务。这时候 Docker 自托管是唯一选择。下面是一份可直接用的 docker-compose.yml 配置，我按生产可用标准写了健康检查、重启策略和资源限制。
# docker-compose.yml —— Next AI Draw.io 自托管配置
version: "3.9"
services:
next-ai-drawio:
image: ghcr.io/dayuanjiang/next-ai-draw-io:latest
container_name: next-ai-drawio
restart: unless-stopped
ports:
- "3000:3000"
environment:
# 模型 API Key（OpenAI 兼容接口，也支持 Anthropic / Google 等）
- AI_PROVIDER=openai
- AI_MODEL=gpt-4o
- OPENAI_API_KEY=${OPENAI_API_KEY}
# 如使用兼容网关，改成自有地址
- OPENAI_BASE_URL=${OPENAI_BASE_URL:-https://api.openai.com/v1}
# 站点访问控制（可选）
- ACCESS_CODE=${ACCESS_CODE:-}
- NODE_ENV=production
healthcheck:
test: ["CMD", "wget", "--spider", "-q", "http://localhost:3000/"]
interval: 30s
timeout: 5s
retries: 3
start_period: 40s
deploy:
resources:
limits:
cpus: "2.0"
memory: 2G
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
配套的 .env 文件里只放密钥，不要提交进 Git。启动命令是 docker compose up -d，日志用 docker compose logs -f 看。如果前面挂 Nginx 反向代理，记得把上传草图的大小上限放开到 10MB 以上，否则手绘照片会传不上去。
11.3.1 自托管的两个运维细节
一是模型选择。架构图对模型的要求不是”画得漂亮”，而是”输出结构化的 XML 正确”，所以优先选代码能力强、结构化输出稳定的模型，而不是视觉生成模型。二是并发。多人同时打开页面时，每个请求都在调模型，所以要给模型 Key 设速率上限，避免费用失控。
十二、自然语言画架构图：提示词的结构
很多人第一次用 Next AI Draw.io 会觉得效果一般，问题多半在提示词。写架构图提示词和写文生图提示词完全不是一回事：后者描述视觉，前者描述结构。结构说得越清楚，出来的图越准。
12.1 提示词的四段式结构
我的经验是分成四段：分层结构、组件清单、连接关系、视觉规范。分层结构告诉它系统分成几层（客户端、网关、服务、数据）；组件清单把每层里的具体组件列出来，用云厂商的标准叫法（AWS 的 ALB、S3，或阿里云的 SLB、OSS）；连接关系说明谁调用谁、数据往哪个方向流；视觉规范指定布局方向和配色，避免它随机发挥。
12.2 可复用的架构图提示词模板
【Next AI Draw.io 架构图提示词模板】
请生成一张电商系统的架构图，使用 AWS 官方图标风格，
布局为从左到右的四层结构。
分层与组件：
1. 客户端层：Web 前端（React）、移动 App（iOS/Android）
2. 接入层：CloudFront CDN、Application Load Balancer、API Gateway
3. 应用层：用户服务、商品服务、订单服务、支付服务（均为容器化部署，
运行在 ECS Fargate 上）、消息队列 SQS
4. 数据层：RDS PostgreSQL（主从）、Redis 缓存、S3 对象存储、OpenSearch
连接关系：
- 客户端 → CloudFront → ALB → API Gateway
- API Gateway → 各业务服务（同步 REST 调用）
- 订单服务 → SQS → 支付服务（异步）
- 所有业务服务 → RDS / Redis
- 商品图片 → S3，搜索 → OpenSearch
视觉规范：
- 数据流向用实线箭头，异步消息用虚线箭头
- 分层用浅灰底框包裹，每层左上角标注层名
- 主色 #2563EB，背景白色，文字黑色
- 节点内保留图标 + 组件名 + 一行规格说明（如 2 vCPU / 4G）
输出要求：
- 生成标准 draw.io XML
- 保持分组可编辑，便于后续手动调整这个模板之所以有效，是因为它把 AI 最容易出错的三件事都锁住了：组件叫法不统一（它可能造出”数据库服务器”这种非标准组件）、连接关系缺失（只画盒子不画线）、布局随机（垂直堆叠成一张高图）。
12.3 迭代比一次生成更重要
第一版出来不要追求完美，直接接着对话改：”把支付服务移到最右边””给数据层加一个读写分离的标注””把 SQS 改成 EventBridge”。因为输出是 XML，每次修改都是在原结构上做增量，不会重画整张图。这个交互方式比传统拖拽快得多，而且思路不中断。
十三、手绘白板草图复刻：把会议记录变成正式文档
这是 Next AI Draw.io 最有意思的功能，也最贴合真实工作场景。很多架构决策是在白板上画出来的：开会时随手勾几个框、拉几条线、写几个缩写，拍张照就散会了。这些照片通常躺在相册里再也不会被打开，因为把它重新画成正式图太麻烦。
这个工具支持上传手绘白板草图照片，AI 识别其中的框、线、文字，用标准云厂商图标复刻美化。实操中有几点要注意：拍摄时尽量正对白板、光线均匀、字迹清晰；在提示词里说明”请识别白板上的组件并替换为 AWS 标准图标”；对识别错的组件，直接对话纠正比重新上传快。
13.1 复刻的边界
AI 能识别清晰的方框、箭头和文字标签，但对潦草的连笔字、多层嵌套的复杂结构、被擦改过的痕迹，识别率会下降。我的建议是：草图复刻适合”结构已经想清楚了只是没画好”的场景，不适合”边画边想”的半成品。如果你的白板图本身逻辑混乱，复刻出来的图也会混乱，还是要人来理一遍结构。
13.2 这一步真正省的是什么
省的不是绘图时间，是决策到文档的时间差。会议结束时花十分钟把草图变成正式图，比一周后凭记忆重画要准确得多。文档时效性的问题，很多时候不是人不愿意写，是写的成本太高。
13.3 图片是只读的，XML 是可写的
顺着这个话题往下走，就绕不开 draw.io XML 本身的价值。这是我最想展开的一点：它解释了为什么技术团队的文档总是过期——答案不在人身上，在格式上。
PNG 架构图对工程师来说是一张图片
PNG 架构图对工程师来说是一张图片，只能看，不能改。想改要找到原始工程文件，找到原图作者，走一遍沟通。这个链路太长，于是所有人都选择”不改”。而 XML 是文本，任何人打开都能看见结构：<mxCell> 节点、<mxGeometry> 坐标、<mxCell edge="1"> 连线。改一个节点名字，是改一行文本的事。这个摩擦力的差异，决定了文档会不会被维护。
13.4 diff 友好：改动可追溯
XML 能进 Git。系统加了一个服务，架构图就是一个 commit，diff 里能看到新增了哪个节点、连了哪条线。评审时可以把图变更和代码变更放在同一个 PR 里审。这是 PNG 永远做不到的——二进制文件在 Git 里没有一个字节意义，只能显示”二进制文件已更改”。
13.5 环境无关：进 Confluence、Notion、IDE 都能改
draw.io XML 的生态覆盖很广。Confluence 有 draw.io 插件，Notion 可以直接嵌 draw.io 文件，VS Code 有 draw.io 扩展可以直接打开编辑，GitLab、GitHub 也能渲染。同一个 XML 文件，在文档系统、知识库、IDE 里都能打开并继续改。这意味着架构图不再是某个工具里的孤岛，而是一份跟着代码走的资产。
与 draw.io 原生文件互通是另一层保障：你在 diagrams.net 里画的原图，导出 XML 后也能进这个工具继续改，反之亦然。不存在锁定问题。
13.5.1 一个具体的协作场景
后端团队在 GitHub 里维护一个 docs/architecture.xml。产品经理在 Notion 里嵌入这个文件，看到的是最新渲染结果。工程师在 VS Code 里改了服务依赖，顺手更新 XML 并提交。三天后架构评审，大家看到的图就是最新的。整个链路里没有”发图给人”这个动作，因为图就是文件，文件就是代码的一部分。
十四、交付格式选择表：SVG、PDF、XML、PNG 各用在哪
这是实操中最容易出错的一环。交付格式选错了，上游做得再好也白搭。下面按使用场景拆开讲。
| 格式 | 本质 | 最适合 | 不适合 | 注意事项 |
|---|---|---|---|---|
| SVG | 结构化矢量 XML | 图标、Logo、扁平插画、网页内嵌图形 | 照片、复杂渐变场景 | 注意字体是否转曲；确认是真矢量非位图包裹 |
| 矢量页面描述 | 印刷物料、提案文件、给客户的定稿交付 | 需要分图层编辑的场景 | 导出时选保留矢量；嵌入字体；CMYK 色彩模式 | |
| XML | draw.io 结构数据 | 架构图、流程图、系统拓扑 | 视觉表现型物料 | 进 Git 管理；文件命名带版本；避免多人同时改同一文件 |
| PNG | 位图像素 | 社交投图、文档配图、PPT 插图 | 需要二次编辑的任何场景 | 导出 2x 以上；透明底需求选 PNG-24 |
| JPG | 有损位图 | 照片、体积敏感的网页图片 | 图标、文字块、线条图 | 压缩后有锯齿，文字边缘尤其明显 |
14.1 一个简单的判断流程
先问”下游会不会改这个文件”。不会改，看用途：网页用 SVG 或压缩过的 JPG，印刷用 PDF，社交用 PNG。会改，再问”谁会改”：设计师改（改颜色、改描边、改锚点）用 SVG；工程师改（改节点、改连线、改标注）用 XML；客户改（改文字、改版式）用 PDF 或源文件。这个流程能覆盖 90% 的交付决策。
14.2 一个容易被忽略的坑：PDF 丢失图层
很多人以为 PDF 和 SVG 一样可编辑。实际上，从设计工具导出 PDF 时如果选了”扁平化”或”合并图层”，PDF 就变成了一页矢量”画”出来的图，虽然放大不模糊，但没有分组、没有图层，改起来很痛苦。给印刷厂用没问题，给客户做可编辑交付就会挨骂。要保留可编辑性，源文件（AI、Figma、SVG）和 PDF 一起给。
十五、分工表：两个工具各自守哪块阵地
把这两个工具混着用会出错，比如拿 Recraft 画架构图，拿 Next AI Draw.io 做海报。下面这张表是我在实际项目里的分工逻辑。
| 维度 | Recraft（原生 SVG） | Next AI Draw.io（draw.io XML） |
|---|---|---|
| 核心产出 | 原生 SVG 矢量图形 | 标准 draw.io XML 架构图 |
| 最擅长 | 图标套件、扁平插画、Logo、少色几何图形 | 系统架构图、流程图、网络拓扑、时序关系 |
| 输入方式 | 文本提示词 + 风格预设 + Brand Kit | 自然语言描述 + 白板草图照片 |
| 品牌一致性 | Brand Kit 锁 RGB 与线宽规范 | 配色靠提示词指定，逐图控制 |
| 下游工具 | Illustrator、Figma、前端组件库 | Confluence、Notion、VS Code、Git |
| 协作方式 | 设计资产库、组件变体 | XML 进版本库、PR 评审、diff 追溯 |
| 典型使用者 | 品牌设计师、UI 设计师、运营 | 后端工程师、架构师、技术文档、产品经理 |
| 不该用于 | 照片级写实场景 | 需要精细视觉表现的海报与插画 |
一句话总结分工：Recraft 管”视觉资产”，Next AI Draw.io 管”结构信息”。前者解决的是品牌一致性，后者解决的是文档时效性。两者共同点只有一个，但这一点很关键：交付物都是结构化的、可直接编辑的格式。
十六、从生成到交付的完整工作流建议
最后给一套我实际在用的流程，覆盖从需求到交付的全链路。
16.1 视觉资产线
先在 Recraft 里建 Brand Kit，锁住主色、描边规范、圆角半径；再按分组跑图标套件，每组生成后用 Figma 检查一致性；确认风格后批量生成剩余分组；导出原生 SVG 并按语义整理分组；进 Figma 做成组件，建尺寸变体和颜色变量；最后按交付格式表输出 SVG（给开发）、PDF（给印刷）、PNG 2x（给文档）。
16.2 结构文档线
用四段式提示词生成第一版架构图 XML；对话迭代三到五轮，把组件、连线、分层调准；导出 XML 提交进仓库；在 Confluence 或 Notion 里嵌入，保证所有人看到的是最新版；后续架构变更时，XML 跟着代码一起改并走 PR 评审。
16.3 两条线的汇合点
这两条线在”产品文档”这个场景汇合：PRD 里的系统架构图来自 XML，界面示意图的图标来自 SVG。整个文档里没有一个像素级的死图，每一张都能追溯、能修改、能复用。这才是我理解的”交付物直接可编辑”。
十七、FAQ：六个常见问题
17.1 Recraft 导出的 SVG 能在 Figma 里正常编辑吗？
可以。导入后 Figma 会把它解析成 vector 图层，支持改填充、改描边、布尔运算、轮廓化。需要注意两点：一是文字如果被转成了路径，就不能再改字，需要保留原文字副本；二是路径点较多的复杂图形，Figma 编辑起来会略卡，建议先简化再导入。
17.2 免费档生成的图能用在客户项目里吗？
不能。Recraft 免费档不授予商用权，只有 Pro 及以上档位才包含商用权。Pro 年付约 $10/月，包含商用权和更多额度，这笔钱在任何一个真实项目里都是最划算的投入。用免费档的图做客户物料属于权属风险，不建议冒。
17.3 Next AI Draw.io 必须联网使用吗？
工具本身可以 Docker 自托管在内网，但生成过程要调用模型 API。如果你用公有云的模型接口，架构描述还是会离开内网。对敏感度极高的场景，可以把模型换成内网署的开源多模态模型，接口保持 OpenAI 兼容格式即可，配置里改 OPENAI_BASE_URL 就行。
17.4 生成的原生 SVG 为什么有些图形改不了颜色？
常见原因是该图形用了渐变填充或者描边继承了父级样式。在 Illustrator 里检查该路径的 fill 属性，如果是渐变，需要先展开为纯色；如果是继承，用”编辑颜色 → 重新着色”批量处理。另一个原因是图形被编组并锁定了，解除锁定后即可编辑。
17.5 架构图生成的组件图标不是我们用的云厂商怎么办？
在提示词里明确指定云厂商和图标风格，比如”使用 AWS 官方图标风格”或”使用阿里云标准图标”，效果会明显改善。如果仍不准确，可以在生成后手动替换少数几个节点图标，因为输出是 XML，替换是局部操作，不影响整张图。
17.6 这两类工具能组合用在一个项目里吗？
能，而且推荐。典型组合是：用 Recraft 生成产品界面配图、图标套件和品牌插画，用 Next AI Draw.io 生成系统架构图和技术流程图，两者输出的都是结构化可编辑格式，能同时进入设计系统和工程文档。它们的分工边界就是”视觉资产”与”结构信息”。
回到开头那个尴尬时刻。如果客户第二天说”改背景那三个小方块，再复制一套图标”，而你手里是原生 SVG，这活五分钟就干完了。AI 设计真正的分水岭，从来不是模型能不能画出更漂亮的图，而是它交出来的东西，能不能被下一个人接着改。像素稿在小红书里很好看，在项目里很难用；能直接编辑的交付物，才是能进流程的生产资料。
暂无评论内容