让AI自动生成流程图：从手搓到Skill封装实战

在日常开发和方案设计里，流程图往往是先于代码出现的第一份资料。很多开发者对画流程图这件事并不陌生，但真正动起手来，却常常卡在“图形绘制”环节：逻辑其实已经想清楚了，可打开绘图工具后，方框、箭头、对齐、配色却要反复折腾，需求一变，整张图又要重新拖一遍。本文要解决的问题，就是把“画流程图”这一重复性工作封装成 AI skill，让 AI 根据一段需求描述直接生成结构清晰、规范统一的流程图代码，再通过渲染工具快速出图，从源头上摆脱手搓流程图的烦恼。

1. 为什么画流程图还在“手搓”

1.1 手动画流程图的三类典型痛点

第一个痛点是“工具成本”。很多绘图工具虽然功能完整，但入门门槛并不低。用户需要先理解画布、图层、连线、组合这些基础概念，才能画出像样的流程图。对于那些只是偶尔画图、临时整理逻辑的开发者来说，学习成本完全是用在非核心工作上。第二个痛点是“修改成本”。流程图最怕改动，一个分支条件变了，后续所有箭头都要重新梳理。尤其是业务流程复杂时，手动维护节点之间的关系非常容易漏改。第三个痛点是“规范不一致”。同一个团队里，不同人画出来的流程图风格差异很大，有的用箭头表示数据流，有的用箭头表示执行顺序；有人喜欢用菱形判断，有人直接用矩形加文字。图不统一，协作时就需要额外解释，严重降低了沟通效率。

这三个痛点说明一个事实：画流程图的难点不在于“逻辑设计”，而在于“从逻辑到图形的转换”。如果能把这个转换过程自动化，把画图变成写需求描述，生产效率自然会明显提升。

1.2 从“手绘图形”到“让 AI 生成流程图代码”

随着 AI 编程助手和 AI Agent 的普及，流程图的生产方式正在发生变化。现在的做法是：不让 AI 直接画图片，而是让 AI 生成流程图的描述代码。流程图领域已经有了成熟的文本化表达方式，其中最典型的是 Mermaid 和 PlantUML。它们都遵循“用代码描述图形”的思路，节点、连线、分支条件都可以用纯文本表达。开发者把这段文本交给渲染工具，就能得到一张符合预期的矢量图。

相比手动拖拽，文本化流程图有几个明显好处：便于版本管理、便于自动生成、便于批量修改。更重要的是，AI 对文本的理解和生成能力已经足够强，它能够阅读一段需求描述，把其中的业务节点、判断条件、分支路径抽取出来，整理成规范的流程图代码。于是，核心问题就从“你能不能画图”变成了“AI 能不能稳定地按你的规范输出流程图代码”。而保证这种稳定性的手段，正是本文要介绍的 skill。

2. skill 是什么，能解决什么问题

2.1 skill 的基本概念

在 AI Agent 和 AI 编程工具越来越流行的背景下，skill 这个词出现的频率越来越高。它并不是某个产品独有的概念，而是一种通用化的能力封装方式。简单来说，skill 就是一个可以被 AI 读取和执行的“能力包”，里面通常包含一份指令文件、若干参考示例，以及可选的处理脚本。当用户向 AI 提出某个任务时，AI 会先判断这个任务是否匹配某个 skill，如果匹配，就按照 skill 中定义的规则和流程来完成任务。

以“流程图生成”场景为例，如果每次都在对话中手动输入一大段提示词，既不稳定也不高效。用户这周写的规则，下周可能就忘了。而 skill 可以将“流程图应该怎么画、节点怎么命名、分支怎么表达、输出什么格式”等规则固定下来，保存为一个文件。这样每次需要流程图时，只需要简单描述业务场景，AI 就会自动加载该 skill，按照预定规范输出结果。这个思路在 Codex、Claude Code 以及一些支持自定义技能的 AI 工具中都有体现，具体实现和文件名可能不同，但核心思想是一致的：把模型能力之外的领域知识、输出规范和示例，沉淀成可复用的资产。

2.2 skill 与插件、MCP 的区别

很多初学者会把 skill 与插件、MCP 混为一谈，但它们在技术层次上是有明显区别的。skill 偏向于“提示词工程 + 流程规范”层面的封装，它不依赖外部 API，也不一定需要执行代码，主要作用是约束 AI 的思考方式和输出格式。插件则更偏向功能扩展，一般会有具体的代码入口，比如浏览器插件、编辑器插件，它可以调用系统能力、读取文件、操作界面。MCP 是一种标准化协议，用于让 AI 客户端与外部工具或数据源进行交互，重点解决“AI 如何调用外部服务”的接口问题。

下面用一个表格来对比三者的定位差异：

从这张表可以看出，三者的关系不是互斥的。实际使用时，一个 skill 内部可能包含小段脚本，也可以通过 MCP 协议调用外部渲染服务。但在本文的“流程图生成”场景中，最核心的仍是 skill 中的规范与示例部分。

2.3 为什么“画流程图”适合做成 skill

流程图生成非常适合用 skill 来封装，因为它同时满足三个条件。第一，规则明确。流程图虽然有多种画法，但基本要素是固定的，比如开始节点、结束节点、处理步骤、判断分支。只要把这些要素的写法定下来，AI 就能稳定输出。第二，重复性强。无论是方案设计、代码讲解还是业务梳理，几乎所有软件项目都会反复用到流程图。第三，个人经验容易沉淀。很多开发者心里都有一套“怎么画清楚流程图”的判断标准，这些标准很难用语言快速说清，但可以写进 skill 的规范和示例中，让 AI 去执行。

换句话说，skill 的核心价值不是“让 AI 更聪明”，而是“让 AI 更规范”。它把个人或团队的绘图经验固化成机器可执行的指令，减少每次对话中的重复解释，也提高了输出的稳定性。

3. 环境准备与项目结构

3.1 运行环境说明

在开始编写 skill 之前，需要准备一个支持自定义 skill 的 AI Agent 环境。由于不同工具的功能存在差异，本文不绑定具体产品，而是以通用目录结构为例展开说明。如果你使用的是 Codex CLI、Claude Code、或者其他支持 skill 机制的 AI 编程工具，都可以参考同样的思路。版本需要根据你的实际环境调整，本文示例以常见情况为主，重点演示配置思路。

建议准备一个独立目录来存放所有 skill，例如~/skills目录。一个完整的 skill 是一个独立子目录，目录名应当能直观表达 Skill 的用途。后续如果需要团队共享，也可以把该目录纳入 Git 仓库统一管理，方便成员拉取和同步更新。

3.2 推荐目录结构

下面是一个用于“流程图生成”的 skill 目录结构，它是后续所有示例的基础。

flowchart-master/ ├── SKILL.md ├── assets/ │ └── examples/ │ ├── order-refund.mmd │ └── login-flow.md ├── references/ │ └── style-guide.md └── scripts/ └── check_flow.py

各目录职责如下：

• SKILL.md：skill 的主指令文件，负责说明使用场景、工作步骤、输出规范。
• assets/examples/：存放典型示例，AI 可以参考这些示例来理解用户要求。
• references/：存放补充参考资料，例如绘图风格指南、命名规范等。
• scripts/：存放可选的辅助脚本，用于校验、转换或渲染流程图。

这种结构并不是唯一的，你可以根据实际需要调整。但把“指令、示例、脚本”分开存放会更容易维护，也让 AI 在读取 skill 时更快定位到需要的资料。

4. 编写一个“流程图专家”skill

4.1 创建目录与初始文件

先通过命令行创建项目目录：

mkdir -p flowchart-master/assets/examples mkdir -p flowchart-master/references mkdir -p flowchart-master/scripts

创建好之后，目录结构就是上一节展示的结构。接下来，我们依次填充各个文件。

4.2 编写 SKILL.md 主指令文件

SKILL.md是整个 skill 的核心。它需要告诉 AI 三件事：这个 skill 是干什么的、在什么场景下启用、按照什么规范输出结果。

下面是一个可以直接使用的模板：

--- name: flowchart-master description: 根据用户描述自动生成清晰、规范、可直接渲染的流程图，支持 Mermaid、PlantUML 和纯文本 ASCII 流程图。 --- # flowchart-master 根据用户描述自动生成流程图代码，帮助开发者在方案设计、代码讲解和业务梳理中快速得到可用图表。 ## 适用场景 - 业务流程梳理 - 系统模块交互 - 算法逻辑讲解 - 用户操作路径 - 数据流转过程 ## 工作步骤 1. 理解用户需求，提取关键节点、处理动作和判断条件。 2. 确定流程图类型：业务流程图、算法流程图、状态图或时序图。 3. 按输出规范生成对应格式的流程图代码。 4. 如果用户有额外要求，补充必要的文字说明。 ## 输出规范 - 默认使用 Mermaid 语法；如果用户要求 PlantUML，则切换为 PlantUML。 - 节点命名使用简洁且有意义的驼峰命名。 - 流程必须包含开始节点和结束节点。 - 判断节点必须使用菱形，并同时标注“是/否”或“成功/失败”。 - 分支路径上的文字需要清楚表达分支语义。 - 单图节点数量控制在 10 到 20 个，层级不超过 5 层。 - 如果生成的是 Mermaid 代码，使用 `text` 代码块输出，方便用户复制到渲染工具。 - 如果用户明确要求“不要代码”，则输出纯文本 ASCII 流程图。 ## 参考示例 可以参考 `assets/examples/` 目录下的示例文件。

这段内容的关键在于“输出规范”。如果没有这些约束，AI 生成的流程图可能五花八门。通过硬性规定节点类型、分支写法、节点数量，就把流程图的风格限定在了一个相对稳定的范围内，既便于阅读，也便于后续渲染。

4.3 输出规范：先定标准再写提示词

为什么要把输出规范单独拿出来强调？因为在 AI 对话中，“画一个流程图”这句话本身包含的信息量太少了，AI 会按自己的默认理解发挥。而每个团队对流程图的偏好不同，有人喜欢自上而下，有人喜欢从左到右；有人喜欢把判断条件写在边上，有人喜欢直接写在节点里。这些差异如果不提前定义，输出结果就很难统一。

我建议在 skill 中至少定义以下四个层面的标准。

第一个层面是“格式标准”，明确默认输出格式是 Mermaid、PlantUML 还是其他文本格式。第二个层面是“结构标准”，规定开始节点、处理节点、判断节点、结束节点如何表达。第三个层面是“语义标准”，明确分支条件如何命名，例如使用“是/否”，而不是有时写“满足条件”有时写“条件成立”。第四个层面是“复杂度标准”，对节点数量、层级深度做限制，避免 AI 把一张图画成蜘蛛网。

下面用一个表格来对比常见文本化流程图格式的特点：

定义好这些规范后，AI 的输出就有了明确的参考标准。即使你用的是没有预置 skill 能力的普通 AI 工具，也可以把这套规范直接粘贴到系统提示词里，效果会明显改善。

4.4 添加参考示例

AI 的学习能力很强，但有时仅靠文字规则还不够，需要给它“看”几个典型示例。我们在assets/examples/目录下准备两个示例。

第一个示例是订单售后流程图，使用 Mermaid 语法：

flowchart TD A[用户提交退款申请] --> B{是否满足退款条件} B -- 否 --> C[拒绝退款并说明原因] B -- 是 --> D[人工审核] D --> E{审核结果} E -- 通过 --> F[原路退款] E -- 拒绝 --> G[通知用户拒绝原因] F --> H[发送退款成功通知] G --> H

第二个示例是登录流程的 ASCII 流程图，适合在不需要图形渲染的场景中使用：

+------------------+ | 用户输入账号密码 | +------------------+ | v +------------------+ | 校验用户名是否存在 | +------------------+ | +----+----+ | | 否 是 | | v v +--------+ +------------------+ | 提示错误 | | 校验密码是否正确 | +--------+ +------------------+ | | 否 是 | | v v +-------+ +-------------+ | 提示错误| | 登录成功 | +-------+ +-------------+

参考示例的作用有两个。一方面，它让 AI 在看到用户输入时能够联想到“大概是这个风格”；另一方面，当规则文字描述不够清晰时，示例可以补充细节，减少歧义。

4.5 添加辅助校验脚本

如果 AI 生成的流程图代码经常出现问题，比如节点数量太少、缺少结束节点，可以在 skill 中增加一个简单脚本来做结构校验。下面是一个用 Python 编写的轻量检查脚本，它读取 Mermaid 文件，统计节点数量和连线数量。

# 文件路径：flowchart-master/scripts/check_flow.py import re import sys def check_flow(file_path): with open(file_path, encoding="utf-8") as f: content = f.read() node_count = len(re.findall(r"[\w\u4e00-\u9fa5]+\s*[\[\]{}]", content)) edge_count = len(re.findall(r"-->", content)) has_start = "flowchart" in content print(f"节点数量：{node_count}") print(f"连线数量：{edge_count}") print(f"是否包含流程图声明：{has_start}") if node_count < 3: print("警告：节点数量过少，流程可能不完整。") if edge_count < 2: print("警告：连线数量过少，建议检查分支是否遗漏。") if __name__ == "__main__": if len(sys.argv) != 2: print("用法：python check_flow.py <流程图文件>") sys.exit(1) check_flow(sys.argv[1])

这个脚本并不复杂，但它体现了一个工程思路：skill 不只是写给 AI 看的提示词，也可以包含可执行的工程工具。通过自动校验，可以在流程图进入文档之前就发现明显问题，减少后期手动检查的成本。

5. 实战：在不同场景中让 AI 自动产出流程图

5.1 业务流程图：订单售后流程

先看一个最典型的业务场景。在电商项目中，订单售后流程经常需要画图。普通做法是打开绘图工具，手动画用户申请、条件判断、人工审核、退款处理等节点；有了 flowchart-master 之后，整个过程简化为一次自然语言描述。

用户输入提示词：

使用 flowchart-master skill，帮我画一个订单售后流程图。 场景：用户申请退款，需要判断订单是否发货、是否在退货期内、商品是否影响二次销售， 最后给出退款或拒绝的处理结果。

AI 加载 skill 后，可能会输出如下 Mermaid 代码：

flowchart TD A[用户提交售后申请] --> B{订单是否已发货} B -- 否 --> C[自动退款] B -- 是 --> D{是否在7天无理由退货期内} D -- 否 --> E[转人工审核] D -- 是 --> F[普通退货流程] F --> G{商品是否影响二次销售} G -- 否 --> H[同意退货] G -- 是 --> I[拒绝退货并说明理由] E --> I C --> J[售后完成] H --> J I --> J

把这段代码复制到 Mermaid 渲染工具中，就能立刻得到一张结构化流程图。整个过程只需要几秒钟，业务逻辑的表达靠的是 AI 对需求文字的理解，而不是手动拖拽。相比手搓，省下的时间非常可观。

5.2 算法流程图：用流程图讲清一个算法

流程图在算法讲解中同样重要，尤其是神经网络、机器学习这类概念较抽象的主题。例如有开发者想用流程图解释反向传播算法的工作原理，可以输入：

使用 flowchart-master skill，画一个反向传播算法的工作原理流程图。 要求体现前向传播、损失计算、链式求导、参数更新这几个关键环节。

AI 可能会输出下面这样的简化流程：

flowchart TD A[输入训练样本] --> B[前向传播计算输出] B --> C[计算损失函数值] C --> D{损失是否满足要求} D -- 是 --> E[训练结束] D -- 否 --> F[链式求导计算各层梯度] F --> G[按梯度更新权重和偏置] G --> B

这张图虽然简化了反向传播中的数学细节，但把它放在文档开头作为全局示意非常合适。读者先通过流程图理解整体训练闭环，再进入公式推导，理解成本会低很多。由此可见，skill 不仅能画业务流程图，也可以用于算法原理的可视化表达。

5.3 用户管理模块流程图

再来看一个开发中常见的系统模块案例。用户管理模块是后台系统的标配功能，其流程通常包含登录认证、权限校验、用户增删改查等步骤。使用 skill 的提示词可以这样写：

使用 flowchart-master skill，画一个用户管理模块流程图。 包含登录认证、权限校验、新增用户、修改用户、删除用户、查询用户等环节。

AI 可能输出的流程图代码如下：

flowchart TD A[用户登录] --> B[身份认证] B -- 失败 --> C[返回登录页并提示错误] B -- 成功 --> D[读取用户权限] D --> E[进入用户管理模块] E --> F{选择操作} F -- 新增 --> G[校验参数并添加用户] F -- 修改 --> H[读取用户信息并更新] F -- 删除 --> I[二次确认后删除用户] F -- 查询 --> J[按条件查询用户列表] G --> K[记录操作日志] H --> K I --> K J --> K K --> E

可以看到，AI 在 skill 的约束下，会自动为每个操作补充“记录操作日志”这样的工程细节，这是很多新手手绘流程图时容易遗漏的部分。流程图的价值就在于此：它不只是一种图形表达，更是对系统行为的全面梳理。

5.4 把生成的流程图代码渲染为图片

生成 Mermaid 代码只是第一步，最终目的是得到可视化的流程图。这里介绍几种常见的渲染方式。

第一种是使用在线编辑器。Mermaid Live Editor 提供了网页端的实时渲染能力，把代码粘贴到左侧，右侧会立即显示流程图，可以导出为 PNG 或 SVG。第二种是使用本地编辑器插件。VS Code 中有多款支持 Mermaid 预览的 Markdown 插件，安装后可以直接在.md文件中编写 Mermaid 代码并预览，适合日常文档写作。第三种是使用 Typora 这类支持 Mermaid 的 Markdown 编辑器，写文档时可以内嵌流程图，形成“文档即图表”的效果。第四种是使用 Draw.io。Draw.io 桌面版支持将 Mermaid 代码导入为图形，导入后还可以继续手动调整，适合在自动生成基础上做精细修改。第五种是飞书文档等协作工具，其对 Mermaid 的支持程度会随平台版本变化，使用时建议先以官方说明为准。

如果你所在项目中统一使用 Mermaid，还可以把渲染流程放进 CI/CD 脚本中，在文档构建时自动生成流程图图片。这样既能保证图表和代码同步更新，也能减少本地环境的依赖问题。

6. 常见问题与排查思路

在实际使用 skill 生成流程图时，可能会遇到各种问题。下面先整理一张问题速查表，再针对几个高频问题详细展开。

关于“AI 不自动加载 skill”的问题，最常见的原因其实不是 AI 能力不足，而是 skill 的入口描述不够明确。很多 skill 框架会通过文件头部description字段来判断是否启用该 skill，所以需要在 description 中覆盖可能的用户表达。例如，只写“生成流程图”可能不够，最好扩展为“根据需求生成流程图、流程图代码、Mermaid 图、业务流程图、算法流程图、状态图”。

关于“Mermaid 渲染报错”，多数情况是节点文本中出现了引号或特殊符号。比如节点里写“错误："必须转义”，就很容易破坏 Mermaid 语法。解决方式是在 skill 规范中明确，节点文本不允许包含英文引号，必要时使用中文引号替代，或者用#quot;等转义方式。也可以在渲染前先通过脚本检查，将常见特殊字符替换掉。

关于“流程图层级过深”的问题，根因是用户一次性描述的场景太大。例如“把整个电商系统的用户全流程画出来”，节点可能超过 50 个。这种情况下，即使 AI 强行生成，渲染出来的图也会因为过于复杂而难以阅读。更合理的做法是在 skill 中规定单图节点数上限，并主动建议用户拆分场景，按“用户登录”“订单创建”“售后处理”等子模块分别成图。复杂流程可以用多个子图组合表达。

7. 最佳实践与工程建议

7.1 把 skill 当作团队资产来管理

skill 不应该只存在个人电脑里。建议把包含所有 skill 的目录纳入 Git 仓库，并在团队内部共享。这样当一位成员优化了流程图规范后，其他人拉取代码就能立即使用同一套规则，避免团队内部出现“两个人的流程图风格完全不同”的情况。与代码一样，skill 也需要版本管理。每次修改输出规范时，都应该有提交记录，方便回溯和评审。

7.2 输出规范要尽量具体且可验证

写 skill 时，规则越具体，AI 输出越稳定。与其写“流程图要清晰简洁”，不如写“节点数量控制在 10 到 20 个，层级不超过 5 层”。与其写“分支条件要清楚”，不如写“判断节点必须标注是/否”。把规则写得可验证之后，后续还可以用脚本做自动检查，形成“AI 生成 -> 脚本校验 -> 人工复核”的闭环。

7.3 让 skill 输出多种格式，适应不同场景

不要把流程图画法限制在一种格式里。文档写作场景通常使用 Mermaid，代码注释场景更适合 ASCII 流程图，UML 建模场景则可能用到 PlantUML。好的 skill 应该允许用户通过一句话切换输出格式。在SKILL.md中，可以写明“默认输出 Mermaid；如果用户要求 PlantUML，则输出 PlantUML；如果用户要求纯文本，则输出 ASCII”。这种兼容多种格式的设计，能让 skill 的适用面更大。

7.4 建立“先草图后完善”的使用习惯

虽然 skill 能快速生成流程图，但 AI 对复杂业务的理解仍然存在局限。建议在使用流程上保留一个人工确认环节：先把 AI 生成的代码渲染成图，快速确认整体结构是否符合预期，再针对细节做调整。不要期待 AI 第一次输出就完美无缺。实际上，把流程图生成拆成“快速出草图 -> 人工补充约束 -> 二次生成”两个阶段，比一次性要求完美输出更高效。

7.5 沉淀反例，持续优化 skill

当 AI 输出不符合预期时，不要只当一次偶发问题处理。可以把这次“坏输出”保存下来，并在 skill 中加入“反面示例”。例如在 references 目录中增加一个bad-examples.md文件，记录“分支条件没有标注是/否”“没有结束节点”等错误情况，并注明正确写法。AI 在读取 skill 时，看到反面示例后会更容易避开同类问题。这个持续优化的过程，才是 skill 真正超越普通提示词的地方。

8. 总结

画流程图这件事，表面上是在做图形设计，实际上是在做逻辑梳理。既然核心是逻辑，而不是图形，那就完全可以借助 AI 的文本理解和代码生成能力，把“画图”变成“描述需求”。skill 的出现，为这种工作方式提供了一套可复用、可管理、可共享的载体。本文从痛点分析开始，介绍了 skill 的基本概念，接着给出了一个完整的 flowchart-master skill 编写示例，并通过订单售后、反向传播算法、用户管理模块三个实战场景，展示了从提示词到流程图代码的完整链路。最后也整理了常见问题和工程建议。

真正需要投入精力的地方，并不是一遍遍调整 AI 的提示词，而是把绘图规范和业务逻辑打磨清楚，并持续维护 skill 这个资产。当你把第一个流程图 skill 写好后，后续每一条新业务描述都会比上一次生成得更准确。这也正是“有了 skill，画流程图再也不用手搓”的核心原因：AI 负责重复劳动，人负责判断和设计。下一步，你可以尝试把 skill 扩展到另一种图表类型，比如时序图、状态图或架构图，把同样的思路复用到更多文档场景中。