AI编程利器：用Skill自动生成流程图，告别手搓

做技术这么多年，我越来越觉得，画流程图这件事，快成了开发者的“时间黑洞”。

为什么这么说？你可以回忆一下：接到一个需求，代码逻辑其实想清楚了，但leader让你“先画个流程图确认一下”；系统出了故障，你追了三天日志终于定位到问题，复盘时要补一张调用链路图;新人入职，你要把核心业务链路讲清楚，PPT 里少不了一张流程图。

大多数人的选择是打开 Visio、draw.io、ProcessOn，把一个个方框拖到画布上，再用箭头连起来。等你把箭头摆正、把颜色调好、把文字填完，半小时已经过去了。如果中途发现逻辑画错了，又要重新拖、重新连、重新排版。

这是我在实际项目里感受最深的一类低效劳动：画图的动作，并不等于思考的过程。真正有价值的是那张图背后的逻辑梳理，而不是鼠标拖动框线的操作。

所以当我看到“skill”这个概念在 AI 编程工具里火起来的时候，第一个反应就是：最适合做成 skill 的场景，恰恰就是“根据一段描述自动生成流程图”。这篇文章就来聊聊，怎么用流程图生成 skill终结“手搓流程图”的日常，以及如何把它接入到你的 AI 编码工具里。

在往下看之前，先给你一个判断：如果你日常工作里至少每周要画一次流程图，或者你的团队经常需要输出架构图、业务时序图、状态流转图，那这个 skill 值得你花半小时配好。它不复杂，核心就是一个规范化的指令集加一个目录结构，但用对之后，出图效率提升的不是一点半点。

1. 这篇文章真正要解决的问题

先不急着讲概念，我们先把问题讲透。

1.1 手工画流程图的四个痛点

第一个痛点是排版耗时。哪怕是只有七八个节点的简单流程，想画得整齐也要花不少时间。框的大小要统一，箭头要对齐，文字要放得下，太多嵌套还要考虑布局。这些工作不产生任何技术价值，但你不能不做。

第二个痛点是改稿困难。产品经理告诉你“这里要加一个判断”，你以为只是加一个菱形框，结果发现加了之后整条线都要重画。一次改稿，半小时起步。

第三个痛点是沟通失真。很多人画图不遵循统一规范，同一个“延期处理”，有人用圆角矩形，有人用菱形，有人用普通矩形加注释。图是画出来了，但团队里每个人理解都不一样。

第四个痛点是图与代码脱节。代码改了，流程图没更新。半年后回头看，那张图描述的已经是另一个系统了。

这四个痛点背后其实指向同一个本质：我们把“绘制”这个动作，错当成了“设计”这个动作。流程图真正的价值在于逻辑可视化，而绘制本身是机械劳动。

1.2 Skill 方案能改变什么

用 skill 生成流程图，变化发生在产出链路层：

传统链路： 梳理逻辑 -> 打开绘图工具 -> 手动排版 -> 反复调整 -> 导出图片 Skill链路： 描述逻辑 -> 调用技能 -> 生成结构文本 -> 一键渲染 -> 导出图片

传统链路里，你的大量时间消耗在“调整”上；skill 链路里，你只需要把逻辑描述清楚，剩下的结构化和排版交给 AI 完成。

这篇文章会带你从零搭建一个流程图生成 skill，你可以把它用在支持 skill 机制的 AI 编程工具中。文章会覆盖：

• skill 到底是什么，和普通提示词有什么区别；
• 怎么设计一个流程图生成技能的目录结构和指令文件；
• 怎么用一段业务描述生成 Mermaid 流程图；
• 怎么验证生成的图是否正确；
• 实际项目中需要注意哪些坑。

2. Skill 的核心概念：它不只是“一段 Prompt”

2.1 Skill 是什么

Skill 是 AI 编程工具（如 Claude Code、Cursor 等支持技能机制的 Agent 工具）中的一种能力封装机制。它通常由一个文件夹和若干文件组成，核心入口是一个SKILL.md文件。

SKILL.md里写什么？简单说，它像是给 AI 的一本“操作手册”。手册里会定义：

• 这个技能解决什么问题；
• AI 应该遵循什么步骤；
• 输出应该符合什么格式；
• 有哪些可复用的模板或示例。

你可以把 skill 理解成“可复用的专业流程”。普通对话里，你每次都要重新告诉 AI“请用 Mermaid 语法画流程图，节点要拆分，逻辑要清晰”；有了 skill，你只需要说“用流程图技能描述一下下单流程”，AI 会自己按照手册里的规范去执行。

2.2 Skill 与普通 Prompt 的区别

很多新手会问：这不就是一个预先写好的 Prompt 吗？

有相似之处，但差别很明显。我们用下面这个表格对比：

这个差异在生成流程图时特别明显。生成一张合格的流程图，你需要约束的东西很多：节点怎么命名、分支怎么表达、判断条件放哪里、异常流程要不要覆盖。如果这些约束写在 Prompt 里，几轮对话后 AI 很容易“忘了”；写在 skill 里，它每次都会按规范执行。

2.3 为什么流程图是最适合做 Skill 的场景之一

流程图有一个天然优势：它可以被结构化成文本。

无论是 Mermaid 还是 PlantUML，都用一种可读的文本来描述图形结构。这意味着“画图”不再是鼠标拖拽，而是“生成结构化文本”的过程。而结构化文本，恰恰是 AI 最擅长产出的内容。

所以流程图生成技能的核心，不是让 AI 学会“画图”，而是让 AI学会把业务逻辑翻译成结构化的图形描述语言。

3. 环境准备与前置条件

在动手之前，先确认你的环境。

3.1 需要一个支持 Skill 机制的 AI 编程工具

目前主流 AI 编程工具对“技能”的支持程度不一样。有的原生支持SKILL.md，有的需要通过插件或第三方方案实现。本文讲的目录结构和SKILL.md编写方式，是当前业界比较通用的做法，你可以根据自己使用的工具，把目录放到对应的技能加载位置。

版本差异不用纠结。你只要记住一个原则：你的工具需要能把一个文件夹里的SKILL.md和配套资源作为上下文加载给 AI 使用即可。

3.2 需要一个支持 Mermaid 渲染的环境

我们的 skill 输出使用 Mermaid 语法。Mermaid 是一个用文本定义图表的开源工具，支持流程图、时序图、状态图、甘特图等几十种图形。

如果你想在本地方便查看，推荐以下任选其一：

• VS Code 安装Markdown Preview Mermaid Support插件；
• Typora 软件直接支持 Mermaid 渲染；
• 在线编辑器mermaid.live；
• 支持 Mermaid 的笔记软件，如 Obsidian；
• 文档平台，如语雀、飞书、GitLab/GitHub 的 Markdown 预览。

推荐至少准备一种渲染方式。因为 skill 生成的是文本格式的流程图，你要把它渲染成图片才能用于文档、评审和汇报。

3.3 一个测试用业务场景

准备一个你熟悉的业务逻辑。本文后面会用一个“用户下单”的流程做演示。你可以先想好一个自己项目里的真实场景，稍后把它喂给 skill 做验证。

4. 从零设计：流程图生成 Skill 的完整结构

在写代码之前，我想先带你拆解一下这个 skill 应该长什么样。

4.1 Skill 目录结构建议

一个标准的流程图生成 skill，目录结构可以设计成这样：

flowchart-skill/ ├── SKILL.md # 技能主文件，定义技能行为 ├── references/ │ ├── mermaid-guide.md # Mermaid 语法速查 │ └── examples.md # 典型流程图示例 └── assets/ └── templates/ └── basic-flowchart.md # 兜底的通用模板

说明一下每个部分的作用：

• SKILL.md：技能入口。AI 被唤起时首先读取这个文件，它会告诉 AI 这个技能的目标、适用范围、工作流程、输出规范。
• references/mermaid-guide.md：参考手册。AI 在生成语法不太确定的内容时可以查阅，降低语法错误率。
• references/examples.md：示例库。存放一些常见流程图的 Mermaid 示例，供 AI 借鉴格式。
• assets/templates/basic-flowchart.md：兜底模板。如果用户描述的场景比较模糊，AI 可以基于模板向用户提问或补全。

4.2 SKILL.md 里到底写什么

这是整个 skill 的灵魂。很多技能效果不佳，问题就出在这里：要么写得像作文，AI 抓不住重点；要么写得像代码规范，AI 不知道怎么用到具体场景。

我建议SKILL.md按五个区块来写：

第一块：是什么（name + description）

说明技能名字和一句话能力描述。AI 会根据这段描述判断是否应该唤起这个技能。

第二块：用在什么场景（when to use）

明确技能的适用范围。例如：生成业务流程、系统流程、状态流转、消息时序、用户操作流程。同时要写明不适用范围，比如不适用于生成 UI 原型图。

第三块：怎么用（workflow）

给出 AI 执行任务时必须遵守的步骤。这一段要具体到“先做什么、再做什么、最后做什么”。比如：识别意图 -> 明确流程边界 -> 选择图形类型 -> 套用模板 -> 输出 Mermaid 代码 -> 请求验证。

第四块：输出规范（output rules）

定义 AI 输出结果的格式要求。包括：必须用 Mermaid 语法；节点命名要符合命名规范；判断条件要写在节点描述中；必须有开始和结束节点；尽量用中文；代码块必须标注语言。

第五块：示例（examples）

给出一个完整的输入输出示例。AI 在执行时可以参考这个示例的格式。

5. 完整示例：流程生成 Skill 的代码实现

下面我们直接写一个可用的最小实现。以下所有的文件路径、目录结构，你都可以直接复制到自己的 skill 目录里。

5.1 创建技能目录和 SKILL.md

先在你的技能目录下新建flowchart-skill/SKILL.md，内容如下：

--- name: flowchart-generator description: 根据用户提供的业务流程描述，生成结构清晰、规范可渲染的 Mermaid 流程图。适用于业务流程、系统流程、状态流转、算法流程、时序交互等场景。 --- # 流程图生成技能 ## 目标 将用户的自然语言流程描述转换为规范、可渲染、结构清晰的 Mermaid 流程图代码，并附带必要的使用说明。 ## 适用场景 - 业务流程：订单处理、审批流、支付流程等。 - 系统流程：接口调用、服务启动、异常处理流程等。 - 状态流转：订单状态机、任务状态机。 - 算法/逻辑流程：推荐策略、规则引擎判断。 - 时序交互：多系统之间的调用顺序。 ## 不适用场景 - UI 页面原型图。 - 架构拓扑图（应使用架构图专门的表达方式）。 - 甘特图、饼图、雷达图等非流程图类型。 ## 工作流程 当用户请求生成流程图时，按以下步骤执行： 1. **识别流程类型**：判断该流程属于业务流程、系统流程、状态流转还是时序交互。 2. **明确流程边界**：如果用户描述中存在歧义或缺失信息，先列出需要用户补充的关键问题，不要直接猜测。 3. **选择图形语法**： - 普通业务/系统流程：使用 `flowchart TD` 或 `flowchart LR`。 - 状态流转：使用 `stateDiagram-v2`。 - 时序交互：使用 `sequenceDiagram`。 4. **套用模板**：参考 `assets/templates/basic-flowchart.md` 和 `references/examples.md` 中的结构。 5. **生成 Mermaid 代码**：将流程逻辑翻译为 Mermaid 语法，注意控制节点数量，超过 20 个节点时应主动拆分。 6. **输出说明**：在 Mermaid 代码块之后，用简短文字说明该图的阅读顺序和关键分支。 ## 输出规范 1. 必须使用 Markdown 代码块，并标注语言为 `mermaid`。 2. 节点命名使用语义化名称，例如 `[处理支付]`、`[校验库存]`、`{库存充足?}`。 3. 每个流程图都必须包含明确的开始节点和结束节点。 4. 判断节点使用菱形 `{}`，普通操作使用矩形 `[]`，起止节点使用圆角矩形 `([ ])`。 5. 节点文字默认使用中文。 6. 分支条件要尽量写在连线上，例如 `-- 是-->`、`-- 否-->`。 7. 不要输出无法渲染的复杂表达式，不要使用 Mermaid 不支持的语法。 8. 如果流程复杂，建议拆分为多个子图 `subgraph`。 ## 输出结构模板 ```mermaid flowchart TD A([开始]) --> B[步骤1] B --> C{判断条件?} C -- 是 --> D[步骤2] C -- 否 --> E[步骤3] D --> Z([结束]) E --> Z

示例

用户输入：请描述用户下单的流程

AI 输出：

flowchart TD A([开始]) --> B[用户选择商品] B --> C[提交订单] C --> D{库存是否充足?} D -- 否 --> E[提示库存不足] E --> A D -- 是 --> F[创建订单] F --> G[跳转支付] G --> H{支付是否成功?} H -- 否 --> I[订单标记为待支付] I --> J[用户可继续支付或取消] H -- 是 --> K[订单确认] K --> L[通知仓库发货] L --> Z([结束])

注意

• 如果用户没有指定图形方向，默认使用TD（从上到下）。
• 当流程节点超过 15 个时，建议用subgraph进行分组。
• 不要生成多余的解释性文字，除非用户明确要求。

### 5.2 创建 Mermaid 语法速查文件 为降低 AI 生成错误语法的概率，准备一个速查文件 `references/mermaid-guide.md`： ```markdown # Mermaid 流程图语法速查 ## 基本形状 - 矩形（普通步骤）：`A[步骤名称]` - 圆角矩形（开始/结束）：`A([开始])` - 菱形（判断）：`A{条件?}` - 圆柱形（数据库/存储）：`A[(数据库)]` - 子图（分组）：`subgraph 分组名 ... end` ## 箭头与连线 - 默认箭头：`A --> B` - 带文字箭头：`A -- 是 --> B` - 虚线箭头：`A -.-> B` - 粗箭头：`A ==> B` ## 子图示例 ```mermaid flowchart TD subgraph 用户端 A[用户] --> B[提交请求] end subgraph 服务端 C[接收请求] --> D[处理逻辑] end B --> C

常用指令

• flowchart TD：从上到下布局
• flowchart LR：从左到右布局
• stateDiagram-v2：状态图
• sequenceDiagram：时序图

### 5.3 创建示例文件 再准备一个 `references/examples.md`，放两个典型示例，作为 AI 的少量参考： ```markdown # 流程图示例 ## 示例一：审批流程 ```mermaid flowchart TD A([发起申请]) --> B[填写申请单] B --> C[提交审批] C --> D{部门经理审批} D -- 驳回 --> E[退回修改] E --> B D -- 通过 --> F{总监审批} F -- 驳回 --> E F -- 通过 --> G[审批完成] G --> Z([结束])

示例二：订单超时关闭

stateDiagram-v2 [*] --> 待支付 待支付 --> 已支付: 支付成功 待支付 --> 已取消: 用户取消 待支付 --> 已关闭: 超时未支付 已支付 --> 已完成: 确认收货 已取消 --> [*] 已关闭 --> [*] 已完成 --> [*]

### 5.4 创建兜底模板 `assets/templates/basic-flowchart.md` 内容如下： ```markdown # 基础流程图模板 适用于用户描述不够完整、需要快速输出一个基础框架的场景。 ```mermaid flowchart TD A([开始]) --> B[输入场景步骤1] B --> C{是否需要判断?} C -- 是 --> D[分支处理1] C -- 否 --> E[分支处理2] D --> F[后续步骤] E --> F F --> Z([结束])

如果用户场景描述信息不足，优先使用此模板，并向用户提问：

1. 流程的起点和终点分别是什么？
2. 哪些环节存在分支判断？
3. 是否需要区分正常流程和异常流程？

## 6. 实际调用：让 Skill 生成真实流程图 ### 6.1 在 AI 工具中激活并调用 把上面整个 `flowchart-skill` 目录放到你的 AI 工具对应的技能目录后，就可以直接对话。 触发方式一般有两种： - 直接说“使用流程图生成技能，帮我画一个……”； - 或者直接描述“帮我用流程图梳理一下用户下单的流程”，工具会根据 `SKILL.md` 中的 description 自动匹配。 ### 6.2 演示：从业务描述到流程图 我们用一段业务描述来测试： > 用户在小程序里选择商品后提交订单，系统先校验库存。库存不足则提示用户，流程结束。库存充足则创建订单，跳转支付。用户支付成功，订单状态变为已支付，系统通知仓库发货；如果支付失败或超时，订单在 30 分钟后自动关闭。 skill 生成的结果大致如下： ```mermaid flowchart TD A([开始]) --> B[用户选择商品] B --> C[提交订单] C --> D{库存校验} D -- 不通过 --> E[提示库存不足] E --> Z([结束]) D -- 通过 --> F[创建订单] F --> G[跳转支付] G --> H{支付结果} H -- 成功 --> I[订单已支付] I --> J[通知仓库发货] J --> Z H -- 失败/超时 --> K[等待30分钟] K --> L[订单自动关闭] L --> Z

注意看，skill 生成的流程有几个特点：

• 节点命名是语义化的，不是node1、node2；
• 判断分支都标了条件；
• 正常流程和异常流程都覆盖了；
• 开始和结束节点明确。

这就是SKILL.md里输出规范起作用的结果。如果你只是随便让一个 AI 画图，它大概率也会画，但节点的命名、分支的表达、异常分支的覆盖都不可控。

6.3 渲染与验证

生成 Mermaid 代码后，把它粘贴到支持 Mermaid 渲染的编辑器中就能看到图形。

我建议的验证路径是：

1. 先复制 Mermaid 代码到mermaid.live，确认能正常渲染；
2. 对照你的业务描述，检查分支是否完整；
3. 重点确认：正常路径是否走通、异常路径是否覆盖、结束节点是否明确。

第 2 步和第 3 步其实是这个流程中最有价值的工作。AI 把草图画出来，你来判断逻辑对不对，这正好回到前面说的：人负责判断，AI 负责绘制。

6.4 如何判断技能生效

如果你执行完以上步骤，发现 AI 输出的内容明显符合规范、节点命名语义化、分支条件清晰，说明 skill 已经正确加载。如果输出结果和普通对话没有区别，那要回到技能目录的存放位置，检查是否被工具正确识别。

7. 常见问题与排查思路

在实际使用这个 skill 的过程中，下面这几个问题最常出现。

8. 最佳实践与工程建议

8.1 让 skill 的“输出规范”始终优先

一个 skill 的效果好不好，80% 取决于输出规范写得好不好。每次你发现 AI 产出的流程不符合预期，不要想着在对话里补充一句“下次注意”，那是对付不了下一次的。正确的做法是：把这次的教训写回SKILL.md的输出规范中。

比如你希望 AI 永远用“动词 + 宾语”命名节点，而不是用名词短语，那就在输出规范里加一条，并配一个正反示例。Skill 文件越用越贴合你的团队习惯。

8.2 流程拆分的三个程度

使用复杂流程时，我建议按下面这个原则拆分：

• 少于 8 个节点：一个流程图直接画。
• 8 到 20 个节点：用subgraph分块，按业务阶段分组。
• 超过 20 个节点：不要试图一个图画完。拆成主流程图 + 若干子流程图，分别生成。

不要在SKILL.md里写死“超过 20 就拆”，可以写成“超过 20 个节点时，先输出主流程概览，再按关键子模块分别输出详图”。这样的输出更适合实际评审场景。

8.3 流程图要覆盖异常路径

新手画图最容易漏掉异常分支。业务流程图里最常见的异常包括：

• 库存不足；
• 支付超时；
• 接口调用失败；
• 幂等冲突；
• 用户取消；
• 超额重试。

建议在SKILL.md的适用场景里加一条：如果用户描述中没有提到异常情形，在生成前先询问是否有异常分支需要覆盖。这样能减少后续返工。

8.4 善用 markdown 内嵌渲染

即使不用任何专业绘图软件，你的代码仓库本身就能渲染 Mermaid。把生成的流程图写进项目的docs/目录，用 Markdown 文件保存，提交到 Git 仓库后，团队里每个人都能在代码托管平台上直接查看。这比导出一张 PNG 再发到群里要清晰得多，而且天然版本可控。

我特别推荐一个实践：在每个核心业务模块的README.md中放一张主流程图。这样后来者看代码前，先看流程图建立全局认知，可以大幅减少沟通成本。

8.5 把 skill 纳入团队维护

如果整个团队都在用同一个 skill，建议把它当作代码仓库里的一个子项目来维护。变更要记录 changelog，示例要定期增补。特别是examples.md，项目里每出现一个典型的复杂流程，就把它沉淀为一个示例。时间越长，skill 对团队业务的贴合度越高。

9. 对实际项目的一点提醒

最后说几个真话。

这个 skill 不是万能的。它最擅长的是“把已经想清楚的逻辑，快速变成一张规范、美观、可维护的图”。如果你自己都没有想清楚流程，期望 AI 帮你“梳理”出逻辑，效果往往不理想。AI 能帮你确定的大多是你已经隐含表达出来的内容，它不会替你做业务决策。

另外，流程图生成 skill 生成的始终是“给别人看”的交付物。真正值钱的，永远是你对业务的判断、对边界的定义、对异常情况的覆盖。这些判断能力不是工具能代替的。

但如果你已经完成了思考，只想快点把脑子里的流程变成一张拿得出手的图，那这个 skill 能帮你把时间从半小时压缩到三分钟。

建议你现在就做三件事：

1. 把文章里的SKILL.md复制到你的 skill 目录；
2. 找一个最近刚写完的模块，用这个 skill 生成一张流程图；
3. 把SKILL.md里的示例替换成你们团队自己的业务案例。

用不了几次，你就会发现：画流程图这件事，真的可以不用“手搓”了。