AI自动生成类库节点、流程图最大的价值不是帮你省下十几分钟画图时间而是让代码结构图和业务流程图能跟着代码一起更新。以前手工维护类库结构图代码一变图就过期手工画流程图流程一改图就要重来。现在可以借助AI把“解析、提取、生成、渲染”这条链路自动跑起来类库节点、类之间关系、模块依赖、业务流程分支都能从原始代码或一段流程描述里直接转成可编辑的图表文件。这套方案适合谁看后端开发、架构师、IT产品经理以及经常要给旧项目补文档、给新人做导航图的人。最值得关注的点不是“AI能不能画出好看的图”而是它能不能输出结构准确、格式稳定、渲染通过的中间文件。下面按实际落地顺序拆一遍先跑通最小链路再做批量最后讲参数和排查。1. 先搞清楚它解决的是“画图”问题还是“维护”问题1.1 手动画图的真实痛点很多项目不是没有图而是图活不过第一个版本。类库结构变动频繁新增一个基类、调整一次接口继承、拆分一个工具模块手工维护的UML图就过期了。业务流程图更麻烦审批环节多了、异常分支改了、子流程拆出去图表一旦没有同步更新反而会误导看文档的人。手写类库节点图还有一个隐性成本它不是画一次就结束而是每次代码评审、每次新人培训、每次方案汇报都要重新确认图对不对。你说“这个图我一会儿更新”实际上大多数人没有那个“一会儿”。1.2 这类AI方案的三个能力层次第一层给AI一段自然语言描述让它生成流程图。这个最容易实现适合活动安排、流程梳理、方案说明。第二层给AI真实代码让它解析出类、方法、继承关系、模块依赖再生成类库节点图。这个要求AI或脚本具备代码解析能力不能只靠“猜”。第三层让AI感知代码变更在CI或提交阶段自动更新对应图表。这不是单纯的画图工具而是一套文档自动化流程。判断一项工具或方案值不值得用不要只看第一层效果要看它拿到真实代码库后能不能准确解析出继承关系、接口实现、方法调用和模块边界。如果它连AST解析都没有只靠大模型读源码文本结果会很随机。1.3 判断标准图能不能跟上代码变更我一般会先做一个五分钟验证拿一个真实模块的源码让方案生成类库节点图然后手动改一个类名、加一个方法、删一个继承关系再看它重新生成后图表是否同步更新。如果改完后需要人工反复提醒才能更新那它只是“画图辅助”不是“自动生成”。自动生成的意义在于每次运行都能得到与当前代码一致的输出而不是一套好看但过期的图。2. 核心链路从代码到可视化图的四个处理环节2.1 拆解核心处理链路一次完整的“AI自动生成类库节点、流程图”处理通常包含四段代码解析读取源码文件使用AST抽象语法树、编译器API、反射机制或语言工具包把类名、方法名、属性、继承关系、接口实现和依赖关系提取出来。信息结构化把解析结果整理成JSON、YAML或表格这一步是为了让后续生成环节能稳定读取数据而不是每次都去重新读源码。图表语法生成把结构化信息转成Mermaid、PlantUML、Graphviz DOT、Draw.io或自定义JSON等中间格式。渲染输出用Mermaid CLI、PlantUML、Graphviz或在线渲染服务把中间格式转成PNG、SVG图片或嵌入文档站。很多方案失败不是大模型不够强而是在第三段或第四段断了。要么生成的Mermaid语法有错误要么渲染工具没有正确安装要么中间格式不含关键关系。2.2 环境与前置条件以最常见的一组工具组合为例Python环境用于写解析脚本。Python 3.8以上通常够用AST模块是内置的不需要额外安装。解析Java或TypeScript则需要对应语言的解析库比如tree-sitter或各语言自己的编译器API。渲染环境至少选一种图表渲染工具。Mermaid CLI需要Node环境PlantUML需要Java环境和依赖包Graphviz是独立二进制。如果你机器里暂时没有Node也没有Java可以先选Graphviz安装相对直接。大模型API或本地大模型用于把自然语言流程描述转成结构化节点或者把JSON结构转成图表语法。如果只是从确定结构生成Mermaid也可以不依赖大模型用脚本拼接即可。网络条件不是必须的但如果你使用在线API就需要确认请求可以正常发出。完全离线时可以改用本地模型处理文本转换代码解析和渲染本来就不需要联网。2.3 输入、输出和验证入口输入分为两类源码类输入源码文件路径、目录、Git仓库地址或粘贴的代码片段。常见格式有.py、.java、.ts、.go、.js等不同语言用不同解析器。描述类输入一段流程文字比如“用户提交订单后先检查库存再扣减余额如果余额不足则返回失败成功后发送通知”。AI需要把这段文字转成流程图节点和连线。输出也分两层中间文件.mmdMermaid、.pumlPlantUML、.dotGraphviz、.drawio等。最终图片PNG或SVGSVG更适合嵌入网页和文档。验证入口就是“渲染是否成功”和“信息是否齐全”。能生成图片不代表内容准确我每次都要打开图对照源码数一数类和箭头数量。3. 最小可运行用一个小项目生成类库节点图3.1 不要一上来就扫全仓库拿到一个新方案我建议第一步先不碰整个项目。随便找两三个有继承关系的文件或者一个小模块先把它跑通。这样做的原因是问题越少越好排查。如果解析全仓失败你分不清是语法不支持、路径问题还是某些文件编码异常。我会准备一个小目录大概长这样demo_lib/ __init__.py base.py order.py user.pybase.py里定义一个BaseModelorder.py里定义Order继承BaseModeluser.py里定义User继承BaseModel再让Order里引用User。规模很小但能测试继承、跨模块引用和方法提取。3.2 用AST解析类结构解析脚本的思想很简单读源码遍历AST找出ClassDef节点提取类名、基类、方法列表。下面是Python语法的示例思路import ast def extract_classes(source_code: str): tree ast.parse(source_code) result [] for node in ast.walk(tree): if isinstance(node, ast.ClassDef): bases [] for base in node.bases: if isinstance(base, ast.Name): bases.append(base.id) elif isinstance(base, ast.Attribute): bases.append(base.attr) methods [] for item in node.body: if isinstance(item, ast.FunctionDef) and not item.name.startswith(_): methods.append(item.name) result.append({ name: node.name, bases: bases, methods: methods, file: demo_lib/order.py }) return result这段代码只是示例思路实际项目中还要处理多级继承、泛型、装饰器、接口、抽象类、模块路径等。先跑通小样例再逐步增加规则。提取到的结果建议先打印成JSON看一下[ { name: BaseModel, bases: [], methods: [save, delete], file: demo_lib/base.py }, { name: Order, bases: [BaseModel], methods: [create_order, cancel_order], file: demo_lib/order.py } ]看到这段JSON后确认所有需要的类都在再进入下一步。不要跳过这一步直接生成图否则很容易把解析错误当成渲染错误。3.3 把结构化信息转成Mermaid类图拿到结构化JSON后有两种转法一种是直接写脚本拼接图表语法。适合结构固定、输出格式稳定的场景。另一种是把JSON交给大模型让模型转成Mermaid或PlantUML。适合类库庞大、注释多、类名和关系复杂、你希望模型帮忙整理可读性更好的场景。Mermaid的类图语法示例大概是这样classDiagram class BaseModel { save() delete() } class Order { create_order() cancel_order() } class User { login() get_profile() } BaseModel |-- Order BaseModel |-- User Order -- User : uses注意如果类非常多我不建议把所有内容放进一张图。整张图超过五十个节点后信息密度太高阅读价值会大幅下降。更合理的输出方式是按模块拆分每个模块一张图再用索引图串联。3.4 渲染成图后的验证清单渲染成功后打开图片检查五点类名是否完整是否出现截断或乱码。继承箭头是否正确继承关系方向是不是从子类指向基类。方法列表是否与源码一致注意有没有漏掉公开方法有没有把私有方法混进来。是否存在多余节点AI有时会把不存在的类补进来。中文注释或中文类名是否正常显示这个问题经常出现在字体或编码环节。如果以上任何一点不对先回退到上一步检查JSON再检查中间文件。报错不一定是模型问题也不一定是渲染工具问题更常见的是解析阶段数据错了。4. 流程图生成从自然语言描述到可编辑图表4.1 先了解流程图的形状规范很多人容易忽略流程图不是随意画框。形状有约定俗成的含义。圆角矩形或椭圆一般表示开始和结束。矩形表示处理步骤。菱形表示判断或分支。平行四边形表示输入输出。箭头表示控制流方向。大模型生成流程图时如果不约束这些规范它可能把判断节点也画成矩形把开始节点画成普通步骤导致图形语义混乱。所以提示词里必须写明形状要求。4.2 给大模型写提示词的四个约束想让AI稳定生成流程图提示词至少包含四个信息流程类型是顺序流程、审批流程、算法流程还是业务时序。输出语法指定Mermaid flowchart TD或PlantUML activity diagram。不要让它自由发挥。节点规范明确“判断用菱形处理步骤用矩形开始结束用圆角矩形”。分支说明明确分支条件比如“若余额充足走A否则走B”。示例提示词“请把下面这段流程描述转成Mermaid flowchart TD代码。要求开始和结束使用椭圆节点处理步骤使用矩形判断节点使用菱形分支条件写在连线上输出只给Mermaid代码块不要附加解释。流程描述用户提交订单后先检查库存如果库存不足则返回失败如果库存充足则扣减库存并支付支付成功后发送通知流程结束。”约束越多输出越稳定。这里最关键的是“输出只给代码块”没有这句话模型经常会在代码外面加一堆解释导致你还要手动清洗。4.3 用反向传播算法流程做测试样例如果你要验证AI生成流程图的能力我建议用一个有循环、有分支、有明确计算步骤的算法来测试。“用流程图说明反向传播算法的工作原理”就是一个很好的测试题。反向传播流程大概可以拆成这样输入样本进行前向传播逐层计算输出。计算损失函数得到当前模型输出与真实标签的误差。判断是否满足停止条件比如达到最大轮次或损失小于阈值。如果不满足进入反向传播逐层计算梯度更新权重参数。回到前向传播继续下一轮训练。如果满足停止条件输出模型参数结束训练。把这个流程交给AI时注意循环回路在Mermaid里的写法。Mermaid flowchart不是天然支持回边通常需要给循环块设置专属节点名然后从结束点画一个箭头回到开始点。这个细节最容易出错。4.4 多个分支和子流程怎么展示一个流程里某个环节有多个分支子流程这是流程图里最容易画乱的场景。我的处理原则是主流程尽量保持一条主线分支子流程拆出去。具体做法有三种使用Mermaid subgraph把同一组节点框在一起适合不超过两层的分组。把每个分支子流程拆成独立的图在主流程的对应节点上放置链接或引用。使用PlantUML的activity分区把不同角色或不同模块的步骤放在不同泳道。注意subgraph不要嵌套太深。嵌套超过两层渲染效果和阅读体验都会明显下降。如果分支逻辑确实复杂宁可拆成多个图也不要硬塞进一张图里。5. 项目级使用批量扫描、文件命名和增量更新5.1 批量任务的关键不是“批量”而是可追踪单独跑通一张图后下一步才是批量。批量不等于遍历文件后机械执行它还要求你清楚每张图的输入是什么、输出去了哪里、哪张图失败、失败原因是什么。我建议先按模块或包维度组织任务而不是按文件逐个执行。一个模块一张图层级关系更清楚。5.2 遍历与分组输出批量处理的伪流程大致是遍历项目目录筛选出目标语言源文件。按照模块或包名对文件分组。每组分别解析生成结构化JSON。每组生成一张中间格式图文件。批量渲染为PNG或SVG。输出文件名建议按模块路径生成例如output/ demo_lib.base.mmd demo_lib.base.svg demo_lib.order.mmd demo_lib.order.svg这样每次运行不会互相覆盖而且能根据文件名直接定位到源码模块。5.3 失败跳过与日志批量任务一定会遇到失败。常见失败包括单个文件语法存在兼容问题、编码不是UTF-8、某些框架生成代码里含有AST无法识别的高级语法、类名冲突等。正确的处理方式是记录失败日志跳过当前文件继续处理后续文件。不要让一个文件卡死整个批次。日志至少要包含三样信息失败的输入文件名。失败发生在哪个环节解析、转换、渲染。失败的具体报错摘要。我在项目级运行时会额外生成一个summary.txt列出成功数量、失败数量、耗时和失败文件列表。这样后续排查不需要重新翻日志。5.4 增量更新思路项目大了以后全量生成会越来越慢。增量更新是更务实的方案。思路很简单先通过git diff或文件修改时间判断哪些源码文件有变化只重新解析和生成这些文件关联的模块图。如果某个模块的依赖没有变化即使它自身没变也可以不重新生成。增量更新需要额外保存一份“模块与依赖”的映射关系。第一次全量生成时缓存下来后续更新只刷新受影响的部分。5.5 与draw.io、文档站、PR评审联动生成SVG后不只是保存成图片。更实用的联动方式有三个文档站把SVG嵌入Markdown或Confluence每次重新生成后覆盖图片文件文档站自动展示最新图。代码评审在PR描述里直接贴更新后的Mermaid代码或图片链接评审人不用打开工具看图。draw.io如果团队习惯用draw.io改图可以把导出的中间格式转换成drawio文件或直接把SVG导入draw.io做二次标注。这里容易踩坑draw.io和Mermaid对流程图节点的兼容性不完全一致。导入后可能需要微调布局。如果只是纯阅读场景直接用SVG就够了不要为了“可编辑”强行导入draw.io。6. 参数、质量判断标准与常见坑点6.1 解析阶段的三个参数层级深度默认值可以设为“当前目录下的类和直接继承关系”。如果你要展示跨模块依赖再打开两到三层。层数越大图越复杂运行时间也越长。过滤规则建议默认忽略测试目录、第三方包、构建产物。很多仓库里test目录的类会污染类库图。也可以设置忽略文件名只提取真正需要展示的模块。可见性过滤类库节点图一般只展示公开方法私有方法会让图显得非常拥挤。如果团队需要查看实现细节可以单独生成另一种细化图。6.2 大模型生成阶段的关键参数如果你用大模型API做转换需要注意三个参数temperature图表生成任务建议调到0.2以下越低输出越稳定。温度过高时同一个输入每次生成的结果可能差异很大。max_tokens类库很大或流程描述长时要给足输出上限。Mermaid代码在类很多时会非常长默认的几百个token可能不够。输出格式约束在提示词里要求“只输出合法的代码块”不要输出解释。这样便于脚本直接提取。另外注意如果源码很长不要把整个文件原样丢给模型。先做AST压缩提取类名、方法名、继承关系再构造成结构化文本喂给模型。模型不需要看懂所有实现代码只需要根据结构化信息生成图。6.3 质量判断标准表判断维度具体标准结构完整性解析出的类、接口、方法数量与源码一致关系准确性继承、实现、依赖箭头方向正确可读性节点命名清晰不截断、不重复、不乱码渲染成功率中间文件能一次性被渲染工具识别不报语法错误稳定性同一输入连续运行多次输出结果差异越小越好如果输出质量不稳定不要急着怀疑AI能力不够先固定输入数据再逐步调整参数。同一份JSON重复生成两次如果两次相差很大说明temperature太高或提示词约束不够。6.4 无输出或报错时的排查顺序遇到卡住、无输出、渲染失败我一般按这个顺序排查先看现象是解析没输出还是输出为空还是渲染工具报错。再看输入文件路径是否正确文件编码是否UTF-8源码是否完整目录权限是否可读。再看解析结果打印JSON确认类和关系是否被正确提取。再看中间文件用文本编辑器打开看是否有多余字符、缺失分号、节点名包含非法符号。再看渲染日志Mermaid CLI或Graphviz一般会给出具体报错位置对照修改。最后再看依赖版本是否兼容Node或Java环境是否正常字体是否存在。大多数情况下问题出在路径、编码和依赖版本而不是AI画图能力。7. 边界、替代方案和长期落地建议7.1 边界AI生成不等于架构决策必须承认AI自动生成类库节点图有一个天然限制它表达的是代码现状而不是设计意图。如果代码本身结构混乱生成出来的图也会混乱。它会把一个设计糟糕的模块关系如实呈现但不会帮你判断这个设计好不好。流程图也一样。AI能把你描述的业务流程转成规范图形但流程本身的合理性需要人来判断。它不会告诉你某个审批分支是否冗余某个判断顺序是否会导致死循环。所以这类方案适合“记录现状”“辅助沟通”“快速作图”不适合替代架构评审和流程设计决策。7.2 哪些场景适合哪些不建议适合 AI 生成的场景旧项目补文档代码可读性差先出图帮新人建立整体认知。代码评审时快速生成模块关系展示本次改动影响范围。方案文档、专利辅助材料需要配图但时间紧张。日常流程图绘制只要描述清楚生成后人工微调。不建议 AI 生成的场景架构演进设计阶段需要表达目标状态而非现状。有严格排版规范的交付物AI生成后仍需大量手动调整。流程图极其复杂包含多级审批、嵌套子流程、大量异常分支此时手画更可控。7.3 长期方案把生成脚本纳入文档流水线如果你的团队愿意接受这套方式最好是把它做成固定脚本而不是每次手动执行。一个可持续运行的方案通常包括一个解析模块负责读取源码并输出结构化JSON。一个生成模块负责把JSON转成图表中间格式。一个渲染模块负责把中间格式渲染成图片。一个输出目录稳定存放生成结果。进入CI后可以在每次提交或合并请求时自动跑一遍把最新SVG推到文档站。这样图和代码之间最短的延迟就是流水线运行时间不再依赖某个人手动更新。7.4 最后想强调的一件事这类方案真正落地时最该盯住的不是AI画得多快而是解析准不准、中间格式稳不稳定、渲染环节是否统一。先把三条链路跑通再考虑批量、自动化和CI。我个人的建议是第一次尝试时找一个小模块用最简单的方式完成“解析到渲染”全过程确认每个环节的输出都能打开、都能验证。之后再扩大范围逐步加入大模型转换、批量处理和增量更新。这样踩坑最少也最容易判断哪个环节真正需要升级。 AI自动生成类库节点与流程图：从代码解析到渲染的落地实践
AI自动生成类库节点、流程图最大的价值不是帮你省下十几分钟画图时间而是让代码结构图和业务流程图能跟着代码一起更新。以前手工维护类库结构图代码一变图就过期手工画流程图流程一改图就要重来。现在可以借助AI把“解析、提取、生成、渲染”这条链路自动跑起来类库节点、类之间关系、模块依赖、业务流程分支都能从原始代码或一段流程描述里直接转成可编辑的图表文件。这套方案适合谁看后端开发、架构师、IT产品经理以及经常要给旧项目补文档、给新人做导航图的人。最值得关注的点不是“AI能不能画出好看的图”而是它能不能输出结构准确、格式稳定、渲染通过的中间文件。下面按实际落地顺序拆一遍先跑通最小链路再做批量最后讲参数和排查。1. 先搞清楚它解决的是“画图”问题还是“维护”问题1.1 手动画图的真实痛点很多项目不是没有图而是图活不过第一个版本。类库结构变动频繁新增一个基类、调整一次接口继承、拆分一个工具模块手工维护的UML图就过期了。业务流程图更麻烦审批环节多了、异常分支改了、子流程拆出去图表一旦没有同步更新反而会误导看文档的人。手写类库节点图还有一个隐性成本它不是画一次就结束而是每次代码评审、每次新人培训、每次方案汇报都要重新确认图对不对。你说“这个图我一会儿更新”实际上大多数人没有那个“一会儿”。1.2 这类AI方案的三个能力层次第一层给AI一段自然语言描述让它生成流程图。这个最容易实现适合活动安排、流程梳理、方案说明。第二层给AI真实代码让它解析出类、方法、继承关系、模块依赖再生成类库节点图。这个要求AI或脚本具备代码解析能力不能只靠“猜”。第三层让AI感知代码变更在CI或提交阶段自动更新对应图表。这不是单纯的画图工具而是一套文档自动化流程。判断一项工具或方案值不值得用不要只看第一层效果要看它拿到真实代码库后能不能准确解析出继承关系、接口实现、方法调用和模块边界。如果它连AST解析都没有只靠大模型读源码文本结果会很随机。1.3 判断标准图能不能跟上代码变更我一般会先做一个五分钟验证拿一个真实模块的源码让方案生成类库节点图然后手动改一个类名、加一个方法、删一个继承关系再看它重新生成后图表是否同步更新。如果改完后需要人工反复提醒才能更新那它只是“画图辅助”不是“自动生成”。自动生成的意义在于每次运行都能得到与当前代码一致的输出而不是一套好看但过期的图。2. 核心链路从代码到可视化图的四个处理环节2.1 拆解核心处理链路一次完整的“AI自动生成类库节点、流程图”处理通常包含四段代码解析读取源码文件使用AST抽象语法树、编译器API、反射机制或语言工具包把类名、方法名、属性、继承关系、接口实现和依赖关系提取出来。信息结构化把解析结果整理成JSON、YAML或表格这一步是为了让后续生成环节能稳定读取数据而不是每次都去重新读源码。图表语法生成把结构化信息转成Mermaid、PlantUML、Graphviz DOT、Draw.io或自定义JSON等中间格式。渲染输出用Mermaid CLI、PlantUML、Graphviz或在线渲染服务把中间格式转成PNG、SVG图片或嵌入文档站。很多方案失败不是大模型不够强而是在第三段或第四段断了。要么生成的Mermaid语法有错误要么渲染工具没有正确安装要么中间格式不含关键关系。2.2 环境与前置条件以最常见的一组工具组合为例Python环境用于写解析脚本。Python 3.8以上通常够用AST模块是内置的不需要额外安装。解析Java或TypeScript则需要对应语言的解析库比如tree-sitter或各语言自己的编译器API。渲染环境至少选一种图表渲染工具。Mermaid CLI需要Node环境PlantUML需要Java环境和依赖包Graphviz是独立二进制。如果你机器里暂时没有Node也没有Java可以先选Graphviz安装相对直接。大模型API或本地大模型用于把自然语言流程描述转成结构化节点或者把JSON结构转成图表语法。如果只是从确定结构生成Mermaid也可以不依赖大模型用脚本拼接即可。网络条件不是必须的但如果你使用在线API就需要确认请求可以正常发出。完全离线时可以改用本地模型处理文本转换代码解析和渲染本来就不需要联网。2.3 输入、输出和验证入口输入分为两类源码类输入源码文件路径、目录、Git仓库地址或粘贴的代码片段。常见格式有.py、.java、.ts、.go、.js等不同语言用不同解析器。描述类输入一段流程文字比如“用户提交订单后先检查库存再扣减余额如果余额不足则返回失败成功后发送通知”。AI需要把这段文字转成流程图节点和连线。输出也分两层中间文件.mmdMermaid、.pumlPlantUML、.dotGraphviz、.drawio等。最终图片PNG或SVGSVG更适合嵌入网页和文档。验证入口就是“渲染是否成功”和“信息是否齐全”。能生成图片不代表内容准确我每次都要打开图对照源码数一数类和箭头数量。3. 最小可运行用一个小项目生成类库节点图3.1 不要一上来就扫全仓库拿到一个新方案我建议第一步先不碰整个项目。随便找两三个有继承关系的文件或者一个小模块先把它跑通。这样做的原因是问题越少越好排查。如果解析全仓失败你分不清是语法不支持、路径问题还是某些文件编码异常。我会准备一个小目录大概长这样demo_lib/ __init__.py base.py order.py user.pybase.py里定义一个BaseModelorder.py里定义Order继承BaseModeluser.py里定义User继承BaseModel再让Order里引用User。规模很小但能测试继承、跨模块引用和方法提取。3.2 用AST解析类结构解析脚本的思想很简单读源码遍历AST找出ClassDef节点提取类名、基类、方法列表。下面是Python语法的示例思路import ast def extract_classes(source_code: str): tree ast.parse(source_code) result [] for node in ast.walk(tree): if isinstance(node, ast.ClassDef): bases [] for base in node.bases: if isinstance(base, ast.Name): bases.append(base.id) elif isinstance(base, ast.Attribute): bases.append(base.attr) methods [] for item in node.body: if isinstance(item, ast.FunctionDef) and not item.name.startswith(_): methods.append(item.name) result.append({ name: node.name, bases: bases, methods: methods, file: demo_lib/order.py }) return result这段代码只是示例思路实际项目中还要处理多级继承、泛型、装饰器、接口、抽象类、模块路径等。先跑通小样例再逐步增加规则。提取到的结果建议先打印成JSON看一下[ { name: BaseModel, bases: [], methods: [save, delete], file: demo_lib/base.py }, { name: Order, bases: [BaseModel], methods: [create_order, cancel_order], file: demo_lib/order.py } ]看到这段JSON后确认所有需要的类都在再进入下一步。不要跳过这一步直接生成图否则很容易把解析错误当成渲染错误。3.3 把结构化信息转成Mermaid类图拿到结构化JSON后有两种转法一种是直接写脚本拼接图表语法。适合结构固定、输出格式稳定的场景。另一种是把JSON交给大模型让模型转成Mermaid或PlantUML。适合类库庞大、注释多、类名和关系复杂、你希望模型帮忙整理可读性更好的场景。Mermaid的类图语法示例大概是这样classDiagram class BaseModel { save() delete() } class Order { create_order() cancel_order() } class User { login() get_profile() } BaseModel |-- Order BaseModel |-- User Order -- User : uses注意如果类非常多我不建议把所有内容放进一张图。整张图超过五十个节点后信息密度太高阅读价值会大幅下降。更合理的输出方式是按模块拆分每个模块一张图再用索引图串联。3.4 渲染成图后的验证清单渲染成功后打开图片检查五点类名是否完整是否出现截断或乱码。继承箭头是否正确继承关系方向是不是从子类指向基类。方法列表是否与源码一致注意有没有漏掉公开方法有没有把私有方法混进来。是否存在多余节点AI有时会把不存在的类补进来。中文注释或中文类名是否正常显示这个问题经常出现在字体或编码环节。如果以上任何一点不对先回退到上一步检查JSON再检查中间文件。报错不一定是模型问题也不一定是渲染工具问题更常见的是解析阶段数据错了。4. 流程图生成从自然语言描述到可编辑图表4.1 先了解流程图的形状规范很多人容易忽略流程图不是随意画框。形状有约定俗成的含义。圆角矩形或椭圆一般表示开始和结束。矩形表示处理步骤。菱形表示判断或分支。平行四边形表示输入输出。箭头表示控制流方向。大模型生成流程图时如果不约束这些规范它可能把判断节点也画成矩形把开始节点画成普通步骤导致图形语义混乱。所以提示词里必须写明形状要求。4.2 给大模型写提示词的四个约束想让AI稳定生成流程图提示词至少包含四个信息流程类型是顺序流程、审批流程、算法流程还是业务时序。输出语法指定Mermaid flowchart TD或PlantUML activity diagram。不要让它自由发挥。节点规范明确“判断用菱形处理步骤用矩形开始结束用圆角矩形”。分支说明明确分支条件比如“若余额充足走A否则走B”。示例提示词“请把下面这段流程描述转成Mermaid flowchart TD代码。要求开始和结束使用椭圆节点处理步骤使用矩形判断节点使用菱形分支条件写在连线上输出只给Mermaid代码块不要附加解释。流程描述用户提交订单后先检查库存如果库存不足则返回失败如果库存充足则扣减库存并支付支付成功后发送通知流程结束。”约束越多输出越稳定。这里最关键的是“输出只给代码块”没有这句话模型经常会在代码外面加一堆解释导致你还要手动清洗。4.3 用反向传播算法流程做测试样例如果你要验证AI生成流程图的能力我建议用一个有循环、有分支、有明确计算步骤的算法来测试。“用流程图说明反向传播算法的工作原理”就是一个很好的测试题。反向传播流程大概可以拆成这样输入样本进行前向传播逐层计算输出。计算损失函数得到当前模型输出与真实标签的误差。判断是否满足停止条件比如达到最大轮次或损失小于阈值。如果不满足进入反向传播逐层计算梯度更新权重参数。回到前向传播继续下一轮训练。如果满足停止条件输出模型参数结束训练。把这个流程交给AI时注意循环回路在Mermaid里的写法。Mermaid flowchart不是天然支持回边通常需要给循环块设置专属节点名然后从结束点画一个箭头回到开始点。这个细节最容易出错。4.4 多个分支和子流程怎么展示一个流程里某个环节有多个分支子流程这是流程图里最容易画乱的场景。我的处理原则是主流程尽量保持一条主线分支子流程拆出去。具体做法有三种使用Mermaid subgraph把同一组节点框在一起适合不超过两层的分组。把每个分支子流程拆成独立的图在主流程的对应节点上放置链接或引用。使用PlantUML的activity分区把不同角色或不同模块的步骤放在不同泳道。注意subgraph不要嵌套太深。嵌套超过两层渲染效果和阅读体验都会明显下降。如果分支逻辑确实复杂宁可拆成多个图也不要硬塞进一张图里。5. 项目级使用批量扫描、文件命名和增量更新5.1 批量任务的关键不是“批量”而是可追踪单独跑通一张图后下一步才是批量。批量不等于遍历文件后机械执行它还要求你清楚每张图的输入是什么、输出去了哪里、哪张图失败、失败原因是什么。我建议先按模块或包维度组织任务而不是按文件逐个执行。一个模块一张图层级关系更清楚。5.2 遍历与分组输出批量处理的伪流程大致是遍历项目目录筛选出目标语言源文件。按照模块或包名对文件分组。每组分别解析生成结构化JSON。每组生成一张中间格式图文件。批量渲染为PNG或SVG。输出文件名建议按模块路径生成例如output/ demo_lib.base.mmd demo_lib.base.svg demo_lib.order.mmd demo_lib.order.svg这样每次运行不会互相覆盖而且能根据文件名直接定位到源码模块。5.3 失败跳过与日志批量任务一定会遇到失败。常见失败包括单个文件语法存在兼容问题、编码不是UTF-8、某些框架生成代码里含有AST无法识别的高级语法、类名冲突等。正确的处理方式是记录失败日志跳过当前文件继续处理后续文件。不要让一个文件卡死整个批次。日志至少要包含三样信息失败的输入文件名。失败发生在哪个环节解析、转换、渲染。失败的具体报错摘要。我在项目级运行时会额外生成一个summary.txt列出成功数量、失败数量、耗时和失败文件列表。这样后续排查不需要重新翻日志。5.4 增量更新思路项目大了以后全量生成会越来越慢。增量更新是更务实的方案。思路很简单先通过git diff或文件修改时间判断哪些源码文件有变化只重新解析和生成这些文件关联的模块图。如果某个模块的依赖没有变化即使它自身没变也可以不重新生成。增量更新需要额外保存一份“模块与依赖”的映射关系。第一次全量生成时缓存下来后续更新只刷新受影响的部分。5.5 与draw.io、文档站、PR评审联动生成SVG后不只是保存成图片。更实用的联动方式有三个文档站把SVG嵌入Markdown或Confluence每次重新生成后覆盖图片文件文档站自动展示最新图。代码评审在PR描述里直接贴更新后的Mermaid代码或图片链接评审人不用打开工具看图。draw.io如果团队习惯用draw.io改图可以把导出的中间格式转换成drawio文件或直接把SVG导入draw.io做二次标注。这里容易踩坑draw.io和Mermaid对流程图节点的兼容性不完全一致。导入后可能需要微调布局。如果只是纯阅读场景直接用SVG就够了不要为了“可编辑”强行导入draw.io。6. 参数、质量判断标准与常见坑点6.1 解析阶段的三个参数层级深度默认值可以设为“当前目录下的类和直接继承关系”。如果你要展示跨模块依赖再打开两到三层。层数越大图越复杂运行时间也越长。过滤规则建议默认忽略测试目录、第三方包、构建产物。很多仓库里test目录的类会污染类库图。也可以设置忽略文件名只提取真正需要展示的模块。可见性过滤类库节点图一般只展示公开方法私有方法会让图显得非常拥挤。如果团队需要查看实现细节可以单独生成另一种细化图。6.2 大模型生成阶段的关键参数如果你用大模型API做转换需要注意三个参数temperature图表生成任务建议调到0.2以下越低输出越稳定。温度过高时同一个输入每次生成的结果可能差异很大。max_tokens类库很大或流程描述长时要给足输出上限。Mermaid代码在类很多时会非常长默认的几百个token可能不够。输出格式约束在提示词里要求“只输出合法的代码块”不要输出解释。这样便于脚本直接提取。另外注意如果源码很长不要把整个文件原样丢给模型。先做AST压缩提取类名、方法名、继承关系再构造成结构化文本喂给模型。模型不需要看懂所有实现代码只需要根据结构化信息生成图。6.3 质量判断标准表判断维度具体标准结构完整性解析出的类、接口、方法数量与源码一致关系准确性继承、实现、依赖箭头方向正确可读性节点命名清晰不截断、不重复、不乱码渲染成功率中间文件能一次性被渲染工具识别不报语法错误稳定性同一输入连续运行多次输出结果差异越小越好如果输出质量不稳定不要急着怀疑AI能力不够先固定输入数据再逐步调整参数。同一份JSON重复生成两次如果两次相差很大说明temperature太高或提示词约束不够。6.4 无输出或报错时的排查顺序遇到卡住、无输出、渲染失败我一般按这个顺序排查先看现象是解析没输出还是输出为空还是渲染工具报错。再看输入文件路径是否正确文件编码是否UTF-8源码是否完整目录权限是否可读。再看解析结果打印JSON确认类和关系是否被正确提取。再看中间文件用文本编辑器打开看是否有多余字符、缺失分号、节点名包含非法符号。再看渲染日志Mermaid CLI或Graphviz一般会给出具体报错位置对照修改。最后再看依赖版本是否兼容Node或Java环境是否正常字体是否存在。大多数情况下问题出在路径、编码和依赖版本而不是AI画图能力。7. 边界、替代方案和长期落地建议7.1 边界AI生成不等于架构决策必须承认AI自动生成类库节点图有一个天然限制它表达的是代码现状而不是设计意图。如果代码本身结构混乱生成出来的图也会混乱。它会把一个设计糟糕的模块关系如实呈现但不会帮你判断这个设计好不好。流程图也一样。AI能把你描述的业务流程转成规范图形但流程本身的合理性需要人来判断。它不会告诉你某个审批分支是否冗余某个判断顺序是否会导致死循环。所以这类方案适合“记录现状”“辅助沟通”“快速作图”不适合替代架构评审和流程设计决策。7.2 哪些场景适合哪些不建议适合 AI 生成的场景旧项目补文档代码可读性差先出图帮新人建立整体认知。代码评审时快速生成模块关系展示本次改动影响范围。方案文档、专利辅助材料需要配图但时间紧张。日常流程图绘制只要描述清楚生成后人工微调。不建议 AI 生成的场景架构演进设计阶段需要表达目标状态而非现状。有严格排版规范的交付物AI生成后仍需大量手动调整。流程图极其复杂包含多级审批、嵌套子流程、大量异常分支此时手画更可控。7.3 长期方案把生成脚本纳入文档流水线如果你的团队愿意接受这套方式最好是把它做成固定脚本而不是每次手动执行。一个可持续运行的方案通常包括一个解析模块负责读取源码并输出结构化JSON。一个生成模块负责把JSON转成图表中间格式。一个渲染模块负责把中间格式渲染成图片。一个输出目录稳定存放生成结果。进入CI后可以在每次提交或合并请求时自动跑一遍把最新SVG推到文档站。这样图和代码之间最短的延迟就是流水线运行时间不再依赖某个人手动更新。7.4 最后想强调的一件事这类方案真正落地时最该盯住的不是AI画得多快而是解析准不准、中间格式稳不稳定、渲染环节是否统一。先把三条链路跑通再考虑批量、自动化和CI。我个人的建议是第一次尝试时找一个小模块用最简单的方式完成“解析到渲染”全过程确认每个环节的输出都能打开、都能验证。之后再扩大范围逐步加入大模型转换、批量处理和增量更新。这样踩坑最少也最容易判断哪个环节真正需要升级。