流程图这件事，放在几年前是典型的“看起来简单，做起来烦”。画一个方框、拉一条线、调整对齐、改字体、重新排版，半小时就没了。更别提把一段文字描述转成图，或者把别人口述的业务流程落成一张清晰的图。很多人试过用 AI 画流程图，但体验往往很一般：要么生成的节点逻辑不对，要么 Mermaid 语法报错，要么画出来的图还得手动改半天。
我不是说 AI 画图能力不行，而是过去的用法有问题。传统做法是打开一个对话窗口，输入“帮我画一个用户登录流程图”，然后就等结果。AI 确实能返给你一段 Mermaid 代码，或者一张图片，但你没有给它明确的约束：节点怎么命名、分支条件怎么表达、风格要简洁还是详细、输出格式是什么。结果就是每次都要重新表述需求，每次生成的质量都不稳定。
这就引出了最近越来越热的一个词：Skill。我看到的那个标题说“有了这个 skill，画流程图再也不用手搓了”，这背后的逻辑不是 AI 突然变聪明了，而是 AI 工具的使用方式变了。我自己的体验是，真正让流程图这件事变得省力的，不是某一个画图工具，而是把“画流程图”这件事本身做成一个可复用的脚本、模板或者说一套标准流程。
这篇文章我想从一次实际体验说起，讲清楚 Skill 到底改变了什么、和普通 Prompt 有什么区别、以及怎么把它落地到日常工作中。不是为了追逐热词，而是因为这件事确实值得认真聊聊。
1. 为什么画流程图这种事，特别适合交给 Skill
很多人第一次接触流程图，都是从 Word 里的文本框和箭头开始的。画一个框，填上文字，再拉一条线，调整位置。一旦流程分支超过三四个，排版就变得非常痛苦。后来有人用 Visio、ProcessOn、draw.io，体验好一些，但核心问题没变：你要手动维护每一个图形的坐标、连线和样式。
流程图本质上是一种结构化表达，它和代码很像。一个流程包含节点、分支、循环、结束条件，这些元素用文字描述出来往往很长，但用图表达出来就很直观。而 AI 模型特别擅长处理这类结构化任务，前提是你给它清晰的约束。
这就是为什么流程图会成为 Skill 天生的适用场景。Skill 本质上是一套预先定义好的指令集，它告诉 AI 应该按什么步骤、什么规范来处理一类任务。当你告诉它“请按 Mermaid 语法生成一个流程图，节点用中文，分支条件写清楚，所有节点不要超过 12 个”，它的输出质量会比“帮我画个图”稳定得多。
1.1 过去的流程图生产流程，断层在哪里
我复盘过自己过去画流程图的完整过程：
- 先在脑子里或者纸上梳理流程，列出步骤。
- 打开画图工具，新建画布。
- 逐个添加节点，调整位置。
- 连接线条，标注分支条件。
- 处理交叉线、重叠文本、对齐问题。
- 导出图片，发给同事，然后基于反馈改一遍。
这个过程最耗时间的不是动脑，而是操作。特别是步骤多、分支多的时候，几乎所有时间都花在调整图形上。你说这是创作吗？不太算，更像是体力活。AI 介入之后，这些体力活完全可以被替代，但前提是它知道你想要的流程是什么。
普通 Prompt 做不到这一点。因为普通 Prompt 只有一个需求描述，没有规范、没有格式要求、没有判断标准。Skill 则不同，它把后三者都写进了指令里。
1.2 流程图为什么可以标准化
流程图之所以适合做成 Skill，是因为它的表达方式高度标准化。
- Mermaid 语法已经定义了节点、线条、子图、注释的写法。
- 流程图的逻辑结构无非是顺序、分支、循环。
- 节点文字通常可以对应为一个动词短语。
- 判断节点必须有一个明确的条件，通常用菱形表示。
这就意味着，你可以把“画流程图”这件事定义成一套模板。AI 拿到模板之后，只需要根据用户输入的具体场景，把流程步骤映射成对应节点，然后输出 Mermaid 代码。这样既降低了出错的概率，也让输出结果具有一致性。反观 Word 或 Visio，它们的表达能力更强，但每一步都依赖手动操作，本质上仍然是“手搓”。
用 Skill 画流程图，价值不只是省时间，而是把“画图”从一次性的操作变成了可复用的生产流程。这是我后来反复体会到的一点。
2. 当我们在讨论 Skill 时，讨论的到底是什么
“Skill”这个词最近在 AI 圈子里出现的频率很高，但很多人对它的理解还停留在“提示词模板”。这不完全对。Skill 确实和提示词有重叠，但它的核心差异在于结构化和可复用性。
简单说，一份 Skill 通常包含两个东西：一个描述该能力用途的说明文件，以及一个包含具体指令、规范、示例和流程的提示文件。以 Claude 的 Skill 机制为例，一个 Skill 可以放在项目目录中，让 Claude 在需要时自动发现并加载它。这样，你不需要每次把那些细节重新输入一遍。
2.1 Skill 与 Prompt 的本质区别
普通 Prompt 是给 AI 的一次性指令，例如“请用 Mermaid 画一个下单流程的流程图，包含库存检查、支付、发货三个环节”。
Skill 则更像一份作业指导书。它不只告诉 AI 要画图，还告诉它画图的规则：
- 节点数量控制在 8 到 15 个之间。
- 如果流程超过 15 个节点，拆分为子图。
- 每个节点用“动词+宾语”的格式。
- 判断节点用菱形，并给出“是/否”分支标签。
- 输出 Mermaid 代码块，并在代码块后附上一句流程说明。
你会发现，普通 Prompt 是一次对话，Skill 是形成了一套约定。这套约定可以反复使用，不用每次重新讲一遍。对于画流程图这种重复性很高的任务，这种约定非常有用。
2.2 Skill 和 MCP 是什么关系
很多人在接触 Skill 时会同时听到另一个概念：MCP。两者容易混淆，因为它们都能扩展 AI 的能力。但它们的层次不同。
MCP（Model Context Protocol）是让 AI 能够调用外部工具和数据源的协议。它可以连接文件系统、数据库、外部 API、浏览器等。MCP 解决的是“AI 能不能做到这件事”的问题，例如能不能读取一个 Excel 文件、能不能把一个文件保存到指定目录。
Skill 解决的是“AI 能不能把这件事做得符合预期”的问题。它不引入新的工具能力，而是约束 AI 如何使用已有的能力。换句话说，MCP 负责扩展能力边界，Skill 负责规范执行过程。
放到画流程图这个场景里，MCP 可能负责读写文件，Skill 则负责告诉 AI 按照什么规范来画图。两者不是竞争关系，而是配合关系。AI 工具的使用方式正在从“对话灌需求”走向“能力模块化”，Skill 就是这个趋势里的关键一环。
2.3 为什么 Skill 会突然火起来
Skill 概念并不是最近才出现的。早在 AI Agent 相关讨论变热时，就有人尝试把 Prompt 模块化。但真正让它火起来的，是几款主流编程工具的落地。
Claude Code、Codex CLI、OpenCode 这类工具，面向的是开发者。开发者天然对“把指令封装成可复用模块”这件事有需求。你在终端里反复让 AI 处理同一类任务，比如写单元测试、做代码审查、生成接口文档，每次都重复描述需求很烦。Skill 把这类高频任务做成指令包，一句话就能触发。
流程图 Skill 之所以成为代表性案例，原因也在这里。画流程图的场景足够高频，需求足够明确，而且输出格式可以标准化。当有人做出一个好用的流程图 Skill 并分享出来后，其他人复制过去就能用，效果立竿见影。于是“AI 画流程图”这个议题在社交媒体上一波接一波地刷屏。
3. 实操：手写一个画流程图的 Skill
讲完概念，接下来是实操环节。我会基于目前比较常见的 Skill 设计方式，手写一个流程图 Skills 的完整示例。这里要说明的是，不同工具的 Skill 加载机制略有差异，但总体结构是相通的。
3.1 基本目录结构
从 Claude Code 等工具的 Skill 机制来看，一个 Skill 通常放在独立目录中，目录下至少包含一个描述文件。目录命名建议用英文，便于跨平台兼容。例如：
skills/ └── flowchart-creator/ ├── SKILL.md └── examples/ ├── user-login.mmd └── order-flow.mmdSKILL.md是核心文件，负责定义这个 Skill 的能力说明、使用方式和输出规范。examples目录用于存放示例 Mermaid 代码，方便 AI 参考输出格式。
3.2 编写 SKILL.md 的核心要点
一份合格的流程图 Skill 描述文件，需要包含几个关键模块：
第一，能力声明。要写清楚这个 Skill 是用来做什么的，例如“根据业务描述生成 Mermaid 流程图”。这句话可以帮助 AI 在遇到画图需求时判断是否应该调用它。
第二，使用规则。需要说明在接收到什么类型的请求时调用该 Skill。例如“当用户要求绘制流程图、流程示意、业务流转图、算法逻辑图时”。
第三，输出规范。这是 Skill 质量高低的分水岭。你需要规定节点命名规则、分支条件写法、Mermaid 语法使用范围、节点数量上限等。
第四，示例参考。给出至少两个完整的示例，让 AI 能通过少样本学习来理解输出格式。
下面是一份简化版的SKILL.md示例结构：
# Flowchart Creator Skill ## Description 根据用户描述的业务流程或算法逻辑，生成结构清晰、语义准确的 Mermaid 流程图。 ## When to Use - 用户请求生成流程图、流程示意图、业务流转图。 - 用户提供一段流程描述，要求转成图形化表达。 - 用户需要梳理分支条件或循环逻辑。 ## Output Rules 1. 输出格式为 Mermaid 的 flow chart 语法（graph TD 或 graph LR）。 2. 每个节点使用简洁的“动词+宾语”表达，不超过 12 个字。 3. 判断节点必须标注分支条件：是 / 否。 4. 节点总数控制在 20 以内。超过时使用 subgraph 拆分。 5. 如果用户明确要求图片格式，只生成 Mermaid 代码，并说明可用 mermaid.live 渲染。 6. 代码块后附一句流程概述，不超过 50 字。 ## Example 1: 用户登录 graph TD A[开始] --> B[输入用户名和密码] B --> C{信息校验} C -- 是 --> D[登录成功] C -- 否 --> E[提示错误并返回] E --> B D --> F[进入首页] F --> G[结束]注意示例中体现了几个规范：每个节点都是动词短语、判断节点使用菱形、分支标签清晰、流程语序通顺。AI 收到这份 Skill 后，会按这个风格生成新的流程图，而不是自由发挥。
3.3 实际使用中的关键操作
当 Skill 文件就位后，使用方式非常简单。你要做的不是输入一段 Long Prompt，而是告诉 AI 你想要什么流程，例如：
“请用流程图 Skill，生成一个电商售后处理的流程图。流程包括：用户申请售后、客服审核、审核是否通过、通过进入退货退款、不通过通知用户补充材料。”
AI 会读取 Skill，按规范输出 Mermaid 代码。你只需要把它复制到支持 Mermaid 的渲染工具里，就能看到成品图。
这里有个很容易被忽略的点：不是让 AI 生成图片，而是让 AI 生成代码，再由渲染工具转成图片。这个分工很重要。AI 在生成 Mermaid 代码时的出错率要远低于直接绘制位图，而且代码可以版本管理、可以修改、可以重新渲染。你修改一个节点文字时，只需要改一行代码，而不是重新画一张图。
3.4 半自动方案：Skill 加脚本配合
如果你用 Mermaid 的频率比较高，可以考虑再加一步自动化：写一个脚本，监控某个目录下的.mmd文件，检测到变化就自动调用 Mermaid CLI 渲染成 SVG 或 PNG。这样你只需要让 AI 输出代码，保存到指定目录，图片就会自动更新。
mmdc -i flowchart.mmd -o flowchart.svg这个命令是 Mermaid CLI 的常见用法。把它接到文件监控脚本里，就能实现“修改代码即更新图片”。在实际项目里，我通常会结合 Git 提交来管理流程文档的版本，流程图改动也会留痕。这种工作流一旦跑通，整个“画流程图”的体验会再上一个台阶。
4. 为什么单次跑通不等于能稳定批量使用
我见过不少人第一次用 Skill 生成流程图时很兴奋，觉得“太神奇了”，但用了几天后就发现效果不稳定。有时候生成得很规范，有时候又跑偏。这不是 Skill 本身没有用，而是没有做好边界管理。
4.1 输入的质量直接决定输出质量
Skill 能约束 AI 的输出格式，但不能凭空创造信息。如果用户给的流程描述本身就是模糊的，AI 只能根据自己的理解补全，这就会出现偏差。
举例说明。你说“帮我画一个审批流程”，AI 会画出请假审批、采购审批、报销审批中的哪一种？它的经验可能偏向请假审批。如果你要的是采购审批，就得在请求里写清楚“采购申请审批流程，包含采购员申请、部门主管审批、财务复核、总经理审批”。
所以使用 Skill 时，一个非常重要的习惯是：把流程的关键步骤提前列出来。哪怕只是口头列几个步骤，也能显著提升结果准确率。这其实不是在“教”AI，而是把需求表达清楚。很多流程图 AI 画得不准，问题不在 AI，而在需求表达不完整。
4.2 复杂流程会不会被 Skill 限制住
有人担心，Skill 的规范会不会太死板，遇到特别复杂的流程就不好用了。这个担心有一定道理，但也容易解决。
Mermaid 本身支持子图，可以把复杂流程拆分成模块。Skill 的规则里如果写明“超过 20 个节点使用 subgraph 拆分”，那么复杂场景也能处理。关键在于拆分粒度要合理：每个子图内部的复杂度适中，子图之间的连接关系清晰。
举个实际例子，一个完整的电商交易流程可能包含几十个节点：下单、库存锁定、支付、风控校验、物流分发、售后等。硬画成一张图会非常拥挤。合理做法是把主流程节点控制在 15 个左右，再为支付或风控单独画子图。Skill 的作用就是强制你做这种拆分，从结果上看反而让流程图更易读了。
4.3 什么时候需要微调输出
不可否认，AI 生成的流程图并不能保证 100% 正确。业务规则复杂时，AI 可能会漏掉某个判断分支，或者把循环条件写错。这种情况下，与其重新生成，不如直接修改 Mermaid 代码。Mermaid 语法的学习成本很低，花十分钟熟悉基本语法，就能手动修图。
我对 Skill 的定位是：把 80% 的重复劳动解决掉，剩下 20% 的定制化调整留给人。这比从头开始手搓高效得多，也比完全依赖 AI 可靠得多。
5. 流程图的真正门槛不在画，而在梳理清楚
讲到这儿，我想跳出工具层面，聊一个更大的判断。
Skill 让画流程图的动作变得更省力了，但流程图的真正难点从来不是“画”。真正的难点是“理清楚流程本身”。如果你连流程有哪些步骤、分支条件是什么、异常情况怎么处理都没想清楚，那无论用 Visio 手搓，还是用 AI Skill 自动生成，得到的结果都不会令人满意。
这也是为什么我觉得，画流程图 Skill 的价值不在于“把你变懒”，而在于让你把精力从画图操作中解放出来，放回到流程设计本身。
5.1 用 Skill 生成流程图，最大的收益是帮你发现逻辑漏洞
AI 生成流程图时，它不会像人一样不好意思追问。它会基于你提供的描述，把流程画出来。如果你的描述里没有异常处理分支，生成的流程图里就没有异常处理。当你看到成品图时，第一反应往往是：“哎，这里如果支付失败怎么办？”——这时候，流程图的价值就出现了。
它把你的流程假设可视化，逼你看清楚哪些环节缺失了。从这个角度看，Skill 不只是画图工具，更是一种“流程梳理的加速器”。它让你很快看到一个可批评、可修改的版本，而不是面对一张白纸。
5.2 从“画图”到“维护图”
很多流程图一次性画完就再也不更新了。原因很现实：改图的成本太高。Word 里改一张复杂的流程图，可能比重新画还麻烦。久而久之，流程图就变成“历史遗留文档”，与实际流程脱节。
Skill 加 Mermaid 的工作流，最大的变化是把流程图的维护成本降到几乎为零。流程变更时，直接让 AI 基于原图修改，或者手动改几行代码，重新渲染即可。这意味着你愿意频繁更新流程文档了，流程文档也才能真正反映业务现状。
5.3 好的流程图，本质上是沟通工具
流程图不是艺术品，画得漂亮不是目的。它的目的是让看的人快速理解一套流程。所以判断一张流程图好坏，标准不是样式多精美，而是：
- 阅读者能否在 30 秒内看明白主流程。
- 分支条件是否清楚。
- 异常路径是否完整。
- 节点命名是否没有歧义。
- 图的规模是否适合当前使用场景。
Skill 真正能帮上忙的，是把后面四项标准化。节点命名、分支写法、复杂度控制，这些都是可以通过指令约束的。统一规范之后，团队里不同人画出的流程图风格一致，沟通成本也会下降。
6. 落地边界：什么人适合用，什么场景不必用
Skill 不是万能的。画流程图这件事，用 Skill 有明确适合的场景，也有不太合适的情况。我把判断标准整理成一了一份表，供参考。
6.1 适合用 Skill 的场景
- 流程是多步骤的，有明确顺序和分支，比如登录验证、订单处理、审批流。
- 输出格式适合用 Mermaid 表达，例如算法流程图、业务流转图、状态机图。
- 需要反复修改、迭代，或者多个流程图要保持风格一致。
- 团队需要共享流程文档，并且希望流程文档能版本管理。
- 你想快速验证一个流程设计是否完整，先看草稿再精修。
6.2 不太适合用 Skill 的场景
- 需要精美排版、色彩丰富、面向客户演示的高保真示意图。这类需求适合用专业绘图工具手动调整。
- 流程非常模糊，还没有梳理清楚思路。这时候先用文字、表格把事情理清，再考虑画图。
- 组织架构图、网络拓扑图、系统架构图等非流程类图形。这类图有专门工具和专门的 Skill 或脚本，用流程图 Skill 去画容易不伦不类。
- 离线环境、对数据敏感、不允许把内部流程描述发送给外部服务。这类情况需要本地部署模型来配合 Skill，门槛会高不少。
6.3 长期使用还需要补什么
如果你决定把流程图 Skill 纳入日常工具链，我建议从三个阶段推进：
第一阶段，先用现成 Skill，重点练习需求描述能力。把一次流程需求拆成“开始、步骤、分支、结束”四类信息，描述给 AI。这一步决定了后续生成质量。
第二阶段，学会读 Mermaid 代码。不需要精通，但至少要能看懂节点和连线，能手动修改小问题。这是从依赖 AI 到掌控 AI 的关键一步。
第三阶段，把流程文档纳入版本管理。用 Git 管理.mmd文件，流程变更时能看清历史差异。再通过脚本自动渲染成图片，配合文档系统发布。
三个阶段走下来，你会发现流程图的产生方式已经从“手搓”变成了“编辑代码加自动渲染”，效率提升非常明显。更重要的是，流程图会成为你愿意持续更新的文档，而不是画完就扔的摆设。
7. 回到更大的画面：Skill 是一种知识封装方式
做一个画流程图的 Skill，操作上并不复杂。但让我花一整篇文章讨论它，原因不是这个 Skill 本身有多厉害，而是它代表了一种新的工作方式。
过去我们使用工具软件，每个软件都是一个封闭的盒子。你要在脑子里学会它的菜单、按钮、快捷键，所有操作都受限于这个盒子的设计。遇到盒子没有的功能，就只能换工具或者手工绕过。
AI Skill 带来了一个变化：**能力本身就是可编程的指令。**你不需要写一套复杂的画图引擎，只需要定义规则，AI 就能按规则执行。这相当于把“能力”变成了可以写、可以改、可以分享的文档。任何一个人，只要愿意花时间把一次操作中的经验和规范总结成指令，就能把这次操作复制无数次。
画流程图 Skill，只是这个逻辑的一个缩影。写代码审查、写接口文档、做数据分析、生成周报，所有重复性工作都可以按这个模式封装。区别只在于你有没有花时间去沉淀那套规则。
这也是我判断 Skill 不会只是一阵风的原因。它不是某个厂商搞出来的新概念，而是人机协作方式的一次自然演进。早期的人用命令行控制电脑，后来用图形界面，现在用语言描述任务，接下来就是让人用一套规范去定义任务。谁先把某类任务的定义做得清晰、做得可复用，谁就能在工作流里节省最多的时间。
所以，你可以不关心“Skill”这个热词本身，但值得认真考虑一件事：在你自己的工作里，有哪些重复性的动作可以封装成“规则”交给 AI 去执行。一旦你开始用这个视角看问题，AI 工具的使用体验会完全不同。
回到画流程图这件事，我认为核心变化就一句话：AI 没有替代你的思考，它替代的是你反复调整方框和线条的那只手。把精力留在梳理流程本身，剩下的操作交给 Skill。这套组合，就是当前我见过最舒服的流程图生产方式。
