在日常开发和方案设计里流程图往往是先于代码出现的第一份资料。很多开发者对画流程图这件事并不陌生但真正动起手来却常常卡在“图形绘制”环节逻辑其实已经想清楚了可打开绘图工具后方框、箭头、对齐、配色却要反复折腾需求一变整张图又要重新拖一遍。本文要解决的问题就是把“画流程图”这一重复性工作封装成 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本质指令 示例 可选脚本可执行的功能模块外部工具通信协议主要作用约束 AI 的输入输出行为扩展宿主应用能力统一 AI 与外部工具交互方式是否依赖代码可选必需必需典型示例流程图生成 skillVS Code 代码补全插件让 AI 调用搜索 API从这张表可以看出三者的关系不是互斥的。实际使用时一个 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.mdskill 的主指令文件负责说明使用场景、工作步骤、输出规范。assets/examples/存放典型示例AI 可以参考这些示例来理解用户要求。references/存放补充参考资料例如绘图风格指南、命名规范等。scripts/存放可选的辅助脚本用于校验、转换或渲染流程图。这种结构并不是唯一的你可以根据实际需要调整。但把“指令、示例、脚本”分开存放会更容易维护也让 AI 在读取 skill 时更快定位到需要的资料。4. 编写一个“流程图专家”skill4.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 把一张图画成蜘蛛网。下面用一个表格来对比常见文本化流程图格式的特点格式特点适用场景Mermaid语法简洁、渲染友好、工具生态丰富日常文档、方案设计、Markdown 文档内嵌PlantUML类 Java 语法适合 UML 类图、时序图UML 建模、统一建模语言场景ASCII 流程图纯文本、不依赖渲染工具代码注释、命令行输出、快速沟通定义好这些规范后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, encodingutf-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 没有自动加载 skillskill 的 description 没有覆盖用户意图在 description 中写清楚触发场景和关键词输出的 Mermaid 代码渲染报错节点文本包含未转义的特殊字符规范节点文本避免中文括号和引号混用流程图层级过深难以阅读场景复杂但未做拆分在 skill 中限制单图深度拆分子流程分支条件表达不统一规范中缺少分支语义说明在输出规范中强制使用“是/否”“成功/失败”skill 提示词与系统提示词冲突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 扩展到另一种图表类型比如时序图、状态图或架构图把同样的思路复用到更多文档场景中。