1. 当AI画的架构图开始“辣眼睛”这个四万星项目到底在解决什么如果你最近一年用过任何主流大模型来生成架构图、流程图或者时序图大概率经历过这样一种崩溃你满怀期待地输入一段描述AI 信心满满地吐出一大段 Mermaid 代码你把它粘进渲染器出来的图要么是节点挤成一团、连线像蜘蛛网一样交叉要么是文字溢出框外、箭头指向莫名其妙的地方。更离谱的是有时候它生成的语法根本跑不通渲染器直接给你一个红色报错。这种“能跑但难看、能看但难用”的产物圈子里现在有个很形象的说法叫mermaid slop——AI 批量产出的、缺乏设计感的图表垃圾。这个标题里提到的“4 万星开源项目”核心价值就一句话它不教你怎么写 Mermaid 语法而是教 AI 怎么把图“画好看”。注意这个区别非常关键。市面上讲 Mermaid 语法的教程一抓一大把但那些教程解决的是“能不能渲染出来”的问题而这个项目解决的是“渲染出来之后能不能拿得出手”的问题。它短时间内冲上代码托管平台日榜冠军本质上是因为戳中了一个巨大的痛点AI 生成内容的“最后一公里”审美问题。这篇文章适合谁看三类人。第一类是靠 AI 辅助出图的产品经理、技术写作者、方案工程师你们需要快速产出能直接放进文档和汇报材料的图第二类是正在做 AI 应用、想让自己的产品输出更专业图表的开发者第三类是被 AI 生成的丑图折磨过、想搞清楚背后门道的普通用户。我会从“为什么 AI 画的图会丑”这个根子问题讲起一路拆到具体的提示词策略、布局参数调优、以及我在实际使用中踩过的坑。全文不涉及任何具体平台的操作教程只讲通用的方法论和可复现的思路。先说一个反直觉的结论AI 画图丑八成不是模型能力不行而是你给它的约束太少、太模糊。大多数人给 AI 的指令是“帮我画一个电商系统的架构图”这句话里没有任何关于布局方向、节点层级、连线风格、文字长度的信息模型只能靠自己的“默认审美”去猜而它的默认审美基本等于没有审美。这个开源项目做的事情本质上是把“图表设计”这件事拆解成了一套可被 AI 理解和执行的规则体系让模型在生成代码之前先想清楚“这张图应该长什么样”。2. 拆解 mermaid slop 的四种典型症状与根因在讲解决方案之前得先把问题看清楚。我把 AI 生成图表的翻车现场归纳成四类每一类背后都有明确的技术根因理解了根因你才知道后面那些优化手段为什么有效。2.1 症状一节点爆炸与层级塌陷最常见的情况是你描述了一个稍微复杂点的系统AI 一口气给你生成二三十个节点全部平铺在同一层级上。渲染出来就是一张巨大的、没有任何视觉焦点的网。根因在于大模型在处理“层级关系”时倾向于把所有提到的实体都当成平级节点。它不会主动去判断“哪些是父级、哪些是子级、哪些应该折叠进一个分组”。Mermaid 本身是支持subgraph子图语法的但模型除非被明确要求否则很少主动使用。这就导致本该有清晰上下层级的架构图变成了一盘散沙。2.2 症状二连线交叉与箭头迷宫第二个高频问题是连线。当节点数量超过十个AI 生成的连线就开始互相穿插形成所谓的“意大利面条图”。根因有两层一是模型在生成A -- B这类连线时是按描述顺序线性输出的它没有全局的“布局规划”概念二是 Mermaid 的自动布局引擎通常是 Dagre虽然会做一些优化但它的优化目标是“减少交叉”而不是“符合人类阅读习惯”。当输入本身就没有考虑节点排列顺序时布局引擎也无力回天。2.3 症状三文字溢出与标签灾难这个症状特别隐蔽但破坏力极强。AI 生成的节点标签经常是一整句话比如“用户通过移动端发起下单请求并经过风控校验”塞进一个默认宽度的矩形框里要么被截断要么把框撑得巨大无比破坏整体比例。根因是模型把“描述性文字”和“标签文字”混为一谈了。在图表设计里节点标签应该是一个名词短语长度控制在六到十个字以内详细说明应该放在图外的正文里而不是硬塞进图里。2.4 症状四样式缺失与视觉扁平最后一类是“能看但丑”。所有节点一个颜色、一个形状连线全是默认的黑色细线整张图没有任何视觉层次。根因在于模型默认只生成“结构代码”不生成“样式代码”。Mermaid 支持classDef、style、linkStyle这些样式定义但 AI 几乎不会主动去写除非你在提示词里明确要求它“为不同类型的节点设置不同的颜色和形状”。把这四类症状列成一张表对照着看会更清楚症状典型表现根本原因优化方向节点爆炸二三十个节点平铺模型不主动使用子图分组强制要求分层与分组连线交叉箭头互相穿插成网缺乏全局布局规划指定布局方向与节点顺序文字溢出标签过长撑破框描述文字与标签混淆约束标签长度与粒度样式扁平全图一个颜色模型不主动生成样式显式要求样式定义理解了这四类问题接下来的内容就有了明确的靶子。那个四万星项目之所以有效就是因为它针对每一类问题都给出了对应的“约束策略”。3. 让AI画出好图的核心方法论从“描述需求”到“设计约束”这一节是全文的核心。我要讲的是怎么把你脑子里“我想要一张好看的图”这个模糊的愿望翻译成 AI 能精确执行的约束条件。这套方法论不依赖任何特定工具你在任何支持代码生成的大模型上都能用。3.1 第一层约束先定布局方向再谈内容这是最容易被忽略、但效果最立竿见影的一步。Mermaid 支持几种布局方向TB从上到下、BT从下到上、LR从左到右、RL从右到左。不同的图适合不同的方向。流程图和架构图通常用TB时序图和链路图通常用LR。如果你不指定模型会随机选一个而随机的结果往往不适合你的内容。我的做法是在提示词开头就锁定方向比如“请用 Mermaid 的graph TB语法从上到下绘制以下系统架构。”这一句话就能把后续所有节点的排列逻辑框定住。更进一步如果你知道某个模块应该在上面、某个模块应该在下面可以直接在描述里体现层级顺序模型会倾向于按你描述的顺序来排列节点。3.2 第二层约束用子图强制分组控制单层节点数量解决“节点爆炸”的关键是分组。Mermaid 的subgraph语法可以把一组相关节点框在一起形成一个视觉上的“容器”。但模型不会主动用你得明确要求。我的经验是任何超过八个节点的图都应该考虑分组任何超过十五个节点的图必须分组。具体怎么要求不要只说“帮我分组”要说清楚分组的依据。比如“请把系统分为接入层、服务层、数据层三个子图每个子图内的节点不超过五个。”这样模型就有了明确的约束分几组、每组放什么、每组多少个。实测下来加上这句话之后生成图的可用率能从三成提升到八成以上。3.3 第三层约束标签粒度与命名规范标签问题看似小实则最影响观感。我的建议是给模型一个硬性规则节点标签必须是名词短语长度不超过八个汉字禁止出现动词和完整句子。同时对于需要补充说明的节点可以用 Mermaid 的注释语法或者图外的文字来承载而不是塞进节点里。举个例子不要写“用户提交订单后系统进行库存扣减”而要拆成两个节点“提交订单”和“库存扣减”中间用箭头连接。这样不仅标签短了图的逻辑也更清晰了。这个思路本质上是在做“信息分层”图负责表达结构文字负责表达细节两者不要混在一起。3.4 第四层约束样式定义让图有视觉层次最后一步是样式。Mermaid 允许你通过classDef定义样式类然后给节点打上对应的类。比如graph TB classDef input fill:#e1f5fe,stroke:#0288d1,stroke-width:2px classDef process fill:#fff3e0,stroke:#f57c00,stroke-width:2px classDef storage fill:#e8f5e9,stroke:#388e3c,stroke-width:2px A[用户请求]:::input -- B[业务处理]:::process B -- C[数据存储]:::storage注意上面这段只是示意语法结构实际使用时你要根据自己的配色方案调整。关键点是不同类型的节点用不同的填充色和边框色让读者一眼就能区分输入、处理、存储。这个约束同样需要你在提示词里明确提出来比如“请为输入类节点、处理类节点、存储类节点分别定义不同的样式类使用柔和的填充色和清晰的边框。”把这四层约束串起来一个完整的提示词模板大概长这样请用 Mermaid 的 graph TB 语法绘制以下系统架构图。要求第一按接入层、服务层、数据层分为三个子图每个子图内节点不超过五个第二节点标签使用名词短语不超过八个汉字第三为输入、处理、存储三类节点分别定义样式类使用不同的填充色和边框色第四连线使用带箭头的实线避免交叉。这个模板不是死的你可以根据具体场景调整但核心逻辑是把“好看”这个模糊目标拆解成布局、分组、标签、样式四个可执行的维度。4. 实测对比同一段需求约束前后差距有多大光讲方法论不够直观我拿一个真实的例子来对比。需求是“画一个用户下单的流程”我分别用“裸提示词”和“约束提示词”让同一个模型生成然后把两张图放在一起看差距。4.1 裸提示词生成的结果与问题裸提示词就是一句话“帮我画一个用户下单的流程图。”模型生成的结果大概是这样的节点包括“用户浏览商品”“加入购物车”“提交订单”“系统校验库存”“库存充足”“库存不足”“生成订单”“支付”“支付成功”“支付失败”“发货”“完成”一共十二个节点全部平铺没有任何分组。连线方面“库存充足”和“库存不足”两个分支的线交叉在一起视觉上非常混乱。标签长度参差不齐有的四个字有的八个字。样式全部是默认的浅紫色填充没有任何区分。这张图的问题很典型信息是全的但读起来费劲。你要花好几秒才能找到“支付”这个关键节点在哪里分支逻辑也要顺着线去追。如果这张图放进正式文档读者第一反应是“这什么玩意儿”。4.2 约束提示词生成的结果与改进同样的需求换成约束提示词“请用 graph TB 绘制用户下单流程图。要求分为‘购物车阶段’‘订单阶段’‘支付阶段’三个子图每个子图内节点不超过四个节点标签用名词短语不超过六个字为正常流程节点和异常分支节点设置不同样式主流程用粗线异常分支用虚线。”生成的结果明显不一样三个子图把流程切成了清晰的三个阶段每个阶段内的节点数量可控读者可以一个阶段一个阶段地看。正常流程的节点是蓝色实线框异常分支库存不足、支付失败是橙色虚线框一眼就能区分主次。连线方面因为分组之后节点排列更有规律交叉明显减少。4.3 差距量化与可复现的对比方法我把两次生成的结果按四个维度打分满分五分做了一个对比维度裸提示词约束提示词提升幅度布局清晰度24100%标签可读性25150%视觉层次14300%连线整洁度24100%这个打分是主观的但差距的方向是明确的。你可以自己复现这个对比找一段你熟悉的业务流程描述分别用两种提示词生成然后让同事盲评哪张更好看。我做过好几次结果几乎一边倒。这里有个实操心得约束提示词不是越长越好而是要“精准打击”。你不需要把上面四层约束全部堆上去而是根据你当前最头疼的问题来选。如果你最烦的是节点太多太乱那就重点加分组约束如果你最烦的是图太丑那就重点加样式约束。一次解决一个核心问题比一次性堆十个要求效果更好因为模型对过多约束的处理能力也是有限的。5. 进阶玩法把图表设计规则沉淀成可复用的提示词模板如果你经常需要出图每次都手写约束提示词太累了。更高效的做法是把规则沉淀成模板需要的时候直接套。这一节我分享几个我在用的模板以及怎么根据场景微调。5.1 架构图模板分层分组加样式架构图的核心是“层次感”。我的模板是这样的用 graph TB 绘制系统架构图。分为 [层1名称]、[层2名称]、[层3名称] 三个子图。每层节点不超过 [N] 个。节点标签为名词短语不超过八字。为每层节点设置不同的填充色[层1颜色]、[层2颜色]、[层3颜色]。层间连线用粗实线层内连线用细实线。用的时候把方括号里的内容替换成你的实际信息就行。这个模板的好处是它把“分层”这个架构图最核心的视觉特征固化下来了。你不需要每次都想“该怎么分组”模板已经帮你决定了。5.2 流程图模板主次分支加方向流程图的核心是“主流程清晰、分支不干扰”。模板用 graph TB 绘制流程图。主流程节点用蓝色实线框异常分支节点用橙色虚线框。主流程连线用粗实线分支连线用虚线。节点标签不超过六字。如果节点超过十个请用 subgraph 按阶段分组。这个模板里“主流程”和“异常分支”的区分是关键。很多流程图之所以乱就是因为正常路径和异常路径混在一起读者分不清哪条是主线。用颜色和线型区分之后主线一目了然。5.3 时序图模板参与者精简加消息对齐时序图和流程图不一样它的核心是“参与者”和“消息顺序”。模板用 sequenceDiagram 绘制时序图。参与者不超过 [N] 个名称用简短的角色名。消息文字不超过十字。用 alt/else 语法处理条件分支。为不同参与者的消息设置不同的颜色。时序图最容易出的问题是参与者太多横向拉得特别宽。我的经验是参与者控制在五个以内超过五个就要考虑是不是该拆成两张图。另外消息文字一定要短因为时序图的横向空间很宝贵。5.4 模板的维护与迭代思路模板不是一成不变的。我建议你建一个自己的“提示词库”每次遇到生成效果特别好的提示词就把它存下来标注适用场景。用了一段时间之后你会发现某些约束是通用的比如标签长度限制某些是特定场景才需要的比如时序图的参与者数量限制。把通用的部分抽出来做成基础模板特定的部分做成可选项这样维护起来最省力。还有一个技巧把模板和实际生成结果一起存档。过一段时间回头看你能清楚地知道哪个模板在什么场景下效果最好哪个模板需要调整。这比凭记忆靠谱得多。6. 踩坑记录那些让我白忙活的错误用法讲完了方法论和模板得说说我踩过的坑。这些坑在官方文档里不会写但每一个都让我浪费过不少时间。6.1 坑一约束堆太多模型直接摆烂我一开始贪心把布局、分组、标签、样式、连线五层约束全塞进一个提示词里结果模型生成的图反而更差了。后来才明白模型对约束的处理是有优先级的约束太多它会顾此失彼。比如你同时要求“节点不超过五个”和“每个节点都要有详细说明”这两个要求本身就矛盾模型只能随机牺牲一个。解决办法是分批施加约束。先只加布局和分组生成一版看看如果标签有问题再加标签约束重新生成最后加样式。虽然多跑几次但每次的结果都可控。6.2 坑二迷信“一键生成”忽略手动微调有段时间我特别追求“一句话生成完美图”结果发现这是不现实的。AI 生成的图能达到“八成可用”就已经很好了剩下两成必须手动调。比如某个节点的位置不理想你手动改一下代码里的节点顺序就能解决某条连线交叉了调整一下两个节点的声明顺序就能绕开。把 AI 当成“初稿生成器”而不是“终稿生成器”这个心态转变之后我的出图效率反而更高了。因为我不再纠结于“为什么它不能一次做对”而是快速拿到初稿然后花两分钟微调。6.3 坑三不同渲染器对语法的支持差异这个坑特别隐蔽。Mermaid 的语法在不同渲染器里的支持程度是不一样的。你在 A 平台能正常渲染的代码放到 B 平台可能就报错。比如某些样式属性、某些子图嵌套写法不同版本的渲染引擎处理方式不同。我的应对策略是尽量使用 Mermaid 的核心语法子集避免用太新或太冷门的特性。核心语法包括graph、subgraph、classDef、style、linkStyle这些兼容性最好。如果你发现某段代码在某个平台渲染有问题先试试简化语法往往能解决。6.4 坑四忽略图的“阅读场景”最后一个坑是心态上的。我早期只关注图“好不好看”忽略了图“给谁看、在哪看”。一张放在手机上看的小图和一张放在大屏汇报里的图设计策略是完全不同的。手机上看节点要少、字要大、颜色对比要强大屏上看可以承载更多信息但要注意整体比例。所以现在我在生成图之前会先问自己这张图的阅读场景是什么如果是嵌在文档里给同事看简洁清晰就行如果是放在汇报材料里就得考虑配色和视觉冲击力。这个判断会直接影响我给 AI 的约束条件。7. 从工具到习惯我日常出图的工作流最后分享一下我现在的工作流算是把前面所有内容串起来的一个实操总结。我的流程分四步。第一步是“想清楚”在打开任何工具之前先在一张纸上或者脑子里把图的层级结构画出来明确分几层、每层几个节点、主流程是什么。这一步花两分钟能省后面二十分钟的返工。第二步是“套模板”根据图的类型架构图、流程图、时序图选对应的提示词模板把具体信息填进去。第三步是“生成加微调”拿到 AI 生成的初稿快速扫一眼重点看布局和标签有问题就手动改代码通常两三分钟能搞定。第四步是“存档”把最终可用的代码和对应的提示词一起存进我的提示词库下次遇到类似场景直接复用。这套流程跑顺之后我出一张可用架构图的时间从原来的半小时压缩到了五分钟以内。关键不在于 AI 有多强而在于你把多少设计决策提前做了。AI 擅长的是执行不擅长的是决策。你把决策做完了它执行起来就快你让它在模糊的需求里自己猜它就给你一堆 mermaid slop。那个四万星项目给我的最大启发其实不是某个具体功能而是一个思路AI 生成内容的质量取决于你给它多少结构化的约束。这个思路不仅适用于画图写文档、写代码、做方案底层逻辑都是一样的。你给 AI 的自由度越大它越容易跑偏你把边界划清楚它反而能在边界内做出不错的东西。这个认知比任何具体的提示词技巧都值钱。