企业官网建设流程全解析

画流程图这件事，看起来门槛不高，真正动手却很耗时间。节点越多，箭头越乱；分支一改，整条线路要重新排；如果还要统一颜色、子图、分组，手工调整的成本会直接翻倍。这次我们来看一个思路完全不同的做法：手搓一个 skill，把“画流程图”这件事从手动排版变成自然语言描述，AI 直接输出标准的 Mermaid 流程图源码。你不用再关心方框放哪、箭头怎么连，只需要把流程讲清楚，剩下的交给 skill。

这个 skill 不是什么新模型，也不是重型本地服务。它是一套带示例库和语法约束的提示词工程产物，按 Agent Skills 的目录规范组织，放进支持该机制的 AI 工具里就能生效。核心能力包括：算法流程图、业务流程图、系统模块流程图、时序图和状态图；输入是自然语言，输出是可直接复制的 Mermaid 代码；不依赖本地 GPU，也不需要安装额外运行时。要预览结果，可以粘贴到 Mermaid Live Editor、Draw.io、Typora、Obsidian 等支持 Mermaid 的环境。

这篇文章会带大家完整过一遍：skill 的文件结构长什么样、怎么安装、怎么用不同场景的提示词生成流程图、怎么把生成结果渲染到常用工具，以及最容易踩的语法坑。如果你是经常要给方法写文档、给模块画流程、给算法补图示的开发者，这篇可以直接收藏，后面照着步骤做就行。

1. 核心能力速览

先给一个总体判断：这是一个轻量的 AI Agent Skill，不是完整软件。它把“画图经验”固化成规则和示例，让 AI 工具在生成流程图时不再自由发挥，而是按固定格式输出。因为不涉及模型训练和本地推理，所以硬件门槛基本为零，关键在 AI 工具本身是否支持自定义 Skill 目录。

从表格可以看出来，这个 skill 的定位不是替代 Draw.io 或 ProcessOn，而是把“从 0 到 1 出初稿”的环节压缩掉。你负责描述，它负责排版和语法。后面所有复杂逻辑，包括循环回边、菱形判断、子图划分，都可以靠一份描述文本直接生成。

2. skill 解决了什么问题

先说说为什么需要这样一个 skill。早期画流程图，大家习惯用 ProcessOn、Draw.io、Visio 这类工具，手动拖拽确实直观，但有两个很现实的问题。第一是排版成本高：节点一旦超过十个，对齐、连线、避让就非常麻烦，经常调整一个分支之后，整张图都变得凌乱。第二是维护成本高：流程图会随需求变化不断修改，每次改动都要重新拖拽，久而久之，代码里的逻辑已经更新了，文档里的流程图却还停留在旧版本。

用自然语言驱动生成的方式，正好把这两个问题绕过去。AI 输出的 Mermaid 源码本质是文本，文本的修改成本远低于拖拽画布。改动一个分支条件，只需要改一行代码，再重新渲染。而且 Mermaid 语法本身是开源标准，GitHub、飞书、Obsidian、Typora 都有支持，不需要绑定某个商业画图软件。把这个逻辑固化到 skill 之后，AI 输出的格式会保持稳定，不会一会给你 Graphviz 语法，一会给你 ASCII 字符画。

这个 skill 解决的核心问题，可以归纳为三点：

• 降低起点：不熟悉流程工具的人，也能用自然语言画出结构清晰的流程图。
• 统一格式：所有输出固定为 Mermaid，团队协作时不会出现格式混战。
• 快速迭代：改文案等于改代码，改完即渲染，适合文档和代码同步维护。

需要提醒的是，skill 不解决“流程设计本身”的问题。如果你自己都没想清楚流程有几个分支、异常怎么处理，AI 也没办法替你做业务决策。它擅长的是把已经明确的结构翻译成图，而不是替你凭空定义业务规则。

3. skill 的设计思路与文件结构

这个 skill 的设计思路可以概括为“约束优先”。AI 生成流程图时最常见的问题不是不会写 Mermaid，而是写得太随意：节点命名不规范、判断条件不写分支标签、循环用错方向、子图层级混乱。所以 skill 的核心并不是给 AI 讲解 Mermaid 全部语法，而是把一套“生成流程图的默认规则”写进指令里。

一个典型目录结构如下：

mermaid-flow-builder/ ├── SKILL.md ├── examples/ │ ├── algorithm-flow.mmd │ ├── business-flow.mmd │ └── system-flow.mmd ├── references/ │ └── mermaid-syntax.md └── templates/ └── flowchart-template.md

• SKILL.md：skill 的说明文件，负责告诉 AI 何时启用、按什么规则输出。
• examples/：放几个典型流程图的 Mermaid 示例，让 AI 照葫芦画瓢。
• references/：放常用语法速查，防止 AI 在复杂场景下用错节点形状。
• templates/：放一个空白的流程描述模板，让用户按统一结构填写需求。

SKILL.md的内容可以理解成一套“行为准则”，核心要求是输出前先拆解流程，再生成代码。一个极简版如下：

--- name: mermaid-flow-builder description: 根据用户的自然语言描述，生成结构清晰、语法正确的 Mermaid 流程图。适合算法流程、业务流程、模块流程和文档配图。 --- # 工作流程 1. 将用户描述拆解为：开始节点、处理节点、判断节点、结束节点。 2. 判断是否存在循环，如果有，使用连回上一节点的有向边表示。 3. 所有判断分支必须给出明确的标签，例如“是 / 否”“成功 / 失败”。 4. 输出统一使用 Mermaid 语法，不输出 Graphviz 或其他格式。 5. 代码块语言标注为 mermaid，方便用户直接复制。

这里不需要写太长。Skill 的机制和普通提示词的区别在于：它把“经验”集中放在文件里，每次对话自动加载。文件写得好不好，直接决定输出质量。写完SKILL.md之后，还要配一到两个示例文件，让 AI 知道什么叫“合格输出”。

4. 安装与配置

安装方式取决于你使用的 AI 工具。以支持 Agent Skills 目录规范的常见工具为例，一般有全局目录和项目目录两种放法。全局目录对所有项目生效，项目目录只对当前工作区生效。下面是创建目录的示例命令：

# 以全局目录为例，具体路径需要按工具文档调整 mkdir -p ~/.claude/skills/mermaid-flow-builder/examples mkdir -p ~/.claude/skills/mermaid-flow-builder/references mkdir -p ~/.claude/skills/mermaid-flow-builder/templates

创建完目录之后，把SKILL.md写入根目录。这里给一个可以直接复制的简易版本：

cat > ~/.claude/skills/mermaid-flow-builder/SKILL.md <<'EOF' --- name: mermaid-flow-builder description: 把自然语言描述的流程结构转换为标准 Mermaid 流程图，适合算法、业务、系统模块等场景。 --- # 输出规范 - 使用 graph TD 或 graph LR，根据节点数量自动选择方向。 - 处理节点用 [ ]，判断节点用 { }，开始结束节点用 ( )。 - 每个判断节点必须有分支标签。 - 循环使用回边，指向循环开始节点。 - 输出前先检查 mermaid 语法是否完整闭合。 EOF

如果你想逐个文件创建，也可以在编辑器里新建SKILL.md、examples/algorithm-flow.mmd等文件，内容按自己习惯组织。skill 的名称可以自定义，不一定叫mermaid-flow-builder，但目录名和SKILL.md里的name字段最好保持一致。

如果你的工具不支持目录式 Skill，还有一种替代方案：把“工作流程”这部分规则直接复制到系统提示词或者对话提示词里。虽然不如目录式 Skill 方便，但功能上也能实现大部分效果。用之前先在对话里测试一句“请把下面的流程描述生成 Mermaid 流程图”，能跑通再继续。

安装完成后，通常需要重启一次 AI 工具客户端，让 skill 被识别。如果工具支持技能列表查看，在列表里能看到mermaid-flow-builder就说明加载成功。如果看不到，优先检查目录深浅是否正确，很多工具要求 skill 必须是skills/目录下的直接子目录，不能多套一层。

5. 功能测试与效果验证

安装完成之后，不要急着做复杂图。先用几个经典场景验证 skill 是否正常工作。下面按“需求描述、预期输出、验证标准”三部分给出测试用例。

5.1 算法流程图：反向传播

给 AI 的描述：

请把反向传播算法的训练过程画成 Mermaid 流程图。输入训练样本，前向传播计算输出，计算损失，判断损失是否收敛。如果收敛就结束，不收敛就计算输出层梯度，再逐层反向传播梯度，更新权重偏置，然后回到前向传播继续迭代。

预期输出：

graph TD A[输入训练样本] --> B[前向传播计算各层输出] B --> C[计算损失] C --> D{损失是否收敛} D -->|是| E[训练结束] D -->|否| F[计算输出层梯度] F --> G[从后往前逐层传播梯度] G --> H[更新权重与偏置] H --> B

验证标准：流程图是否包含循环回边；判断节点是否标出“是 / 否”；是否形成从“更新权重”回到“前向传播”的闭环。如果 AI 输出的是从上往下的直线结构，没有回到B节点，说明循环表达没生效，需要补充提示词“循环要画成回边”。

5.2 Python for 循环流程图

给 AI 的描述：

画一个 Python for 循环结构的流程图。初始化变量 i 为 0，判断 i 是否小于 n。如果小于 n，执行循环体，每次执行完让 i 加 1，再回到判断；如果不小于 n，继续执行循环后的代码。

预期输出：

graph TD A[初始化变量 i = 0] --> B{i < n} B -->|否| C[继续执行循环后的代码] B -->|是| D[执行循环体] D --> E[i += 1] E --> B

验证标准：重点看循环回边是否指向判断节点B，而不是指到A。这是新手画循环最容易错的地方。同时分支标签必须用“是 / 否”而不是“真 / 假”，否则部分渲染器里显示会不直观。

5.3 用户管理模块流程图

给 AI 的描述：

画出用户管理模块的流程图。进入页面先判断是否登录，没登录就跳转登录页。登录后加载用户列表，用户可以选择新增、编辑、删除或查询。新增和编辑都要打开表单并校验输入，校验失败提示错误，校验通过调用保存接口。删除需要弹窗确认，确认后调用删除接口。所有操作完成后刷新列表。

预期输出：

graph TD A[进入用户管理页] --> B{是否已登录} B -->|否| C[跳转登录页] B -->|是| D[加载用户列表] D --> E[选择操作] E -->|新增| F[打开新增表单] E -->|编辑| G[打开编辑表单] E -->|删除| H[弹窗确认] F --> I[校验表单] G --> I I -->|不通过| J[提示错误信息] I -->|通过| K[调用保存接口] H -->|确认| L[调用删除接口] H -->|取消| D K --> M[刷新列表] L --> M M --> D

验证标准：这张图涉及多个分支汇合，重点看E节点是否有四个分支标签；取消删除后是否能回到用户列表；保存成功后是否统一刷新列表。如果线条过多，建议后续用子图把“新增流程”和“编辑流程”分组，但这属于优化阶段。

5.4 订单业务流程图

给 AI 的描述：

生成一个订单处理的业务流程图。用户提交订单后进入支付页面，判断支付是否成功。失败则订单取消，成功则通知商家备货，商家发货后进入物流配送，用户确认收货后订单完成。

预期输出：

graph TD A[用户提交订单] --> B[支付页面] B --> C{支付是否成功} C -->|否| D[订单取消] C -->|是| E[通知商家备货] E --> F[商家发货] F --> G[物流配送] G --> H[用户确认收货] H --> I[订单完成]

验证标准：这个例子相对简单，主要看判断节点的分支是否完整表达。如果业务里还有“超时未支付”“退款”“售后”等异常分支，可以继续追加描述，skill 会把这些异常节点补进图中。

5.5 大语言模型训练流程图

给 AI 的描述：

画一个大语言模型训练阶段流程图。从数据收集与清洗开始，做分词和数据构建，进入预训练，再进行监督微调 SFT，然后训练奖励模型，最后做 RLHF 对齐。完成之后进入自动评估，如果达标就发布上线，不达标就回到训练阶段继续调优。

预期输出：

graph TD A[数据收集与清洗] --> B[分词与数据构建] B --> C[预训练] C --> D[监督微调 SFT] D --> E[奖励模型训练] E --> F[RLHF 对齐] F --> G[自动评估] G --> H{是否达标} H -->|否| I[继续调优] I --> C H -->|是| J[发布上线]

验证标准：重点看“继续调优”的回边是否指向预训练阶段。实际训练流程中可能还有数据配比调整、评测集切换等细节，但在初稿阶段，这样的输出已经足够支撑文档配图。所有分支条件和阶段顺序可以继续用追加描述的方式让 AI 补充。

6. 提示词技巧与流程描述规范

把流程描述得越清晰，skill 输出越稳定。这里不是让你写长篇大论，而是把流程拆成固定几块：起点、步骤、判断、分支、循环、终点。一段完整描述通常包含这些要素：

从 X 开始，先做 A，然后判断 C。 如果 C 满足，执行 D； 如果 C 不满足，执行 E。 D 完成之后回到 A，循环直到 C 满足。 最终进入 F 结束。

具体有以下技巧可以参考：

• 先描述主干，再补充分支。主干清晰之后，再让 AI 加入异常分支，避免一开始就把图搞乱。
• 判断条件明确给答案。例如“判断支付是否成功”，分支写“成功 / 失败”，不要只说“根据状态判断”。
• 循环要说清回边位置。描述里加一句“完成后回到判断节点”比让 AI 自己推断更可靠。
• 节点数量多时主动要求子图。例如“把登录模块单独放一个 subgraph”，skill 会按需生成子图结构。
• 指定方向。默认graph TD适合大多数场景，但如果流程图横向更长，可以追加“用从左到右方向”。

如果对输出不满意，不要重新描述整个需求。直接指出“把第 3 个判断改成菱形”“给新增分支补充异常链路”，AI 会在原图基础上修改，比整图重画效率更高。

7. 流程图渲染与发布

拿到 Mermaid 源码之后，下一步是预览和发布。这里列出几个常见环境：

如果你用的是飞书，热搜里很多人问“装什么插件才能解析 markdown 里的 mermaid”，实际结论要分版本看。飞书文档的插件市场更新较快，最稳妥的做法是在本地编辑器渲染成图片后再粘贴，或者将skill产物粘贴到支持 Mermaid 的在线编辑器导出图片，再上传到飞书，这样不依赖某个特定插件是否可用。

在 Draw.io 里导入 Mermaid 时要注意版本兼容。老版本 Draw.io 对 Mermaid 的支持并不完整，可能出现“导入后样式丢失”或者“方向不对”的情况。遇到这种问题，建议先用 Mermaid Live Editor 确认源码没有语法错误，再导入到 Draw.io。还有一点，Mermaid 节点文本中的括号和引号容易导致渲染异常。如果节点文字里必须写函数名或数组，可以把整个文本用双引号包起来，或者改用()写法，减少特殊字符干扰。

8. 常见问题与排查方法

skill 用多了，总会遇到一些固定问题。下面把高频现象和排查思路整理成表格：

排查时先做最小化验证：只画三个节点，确认能跑通，再逐步增加分支和回边。大多数渲染问题都能靠“减少节点、检查特殊字符、核对标签”解决。

9. 最佳实践与使用建议

这个 skill 真正能提升效率，是在把它变成团队协作工具的之后。规则越明确，输出越稳定。我自己使用时会把 skill 的约束写得比 SKILL.md 示例更细，例如固定节点命名只允许“动词 + 宾语”，固定判断节点必须加分支标签。这样生成的图风格统一，多人协作时不需要反复调整格式。

建议从这几个方面入手：

• 第一次使用先小规模验证。只画一个“登录判断”的流程，跑通之后再画完整业务。
• 保留一套最小可运行的 skill 配置。不要一上来就堆几十个示例文件，先让最基本的功能稳定。
• 把输入素材、生成代码、最终图片分目录管理。例如docs/input.md存放流程描述，docs/output/存放生成结果，方便后续迭代。
• 批量生成时按描述文件 -> 生成代码 -> 渲染图片的流程逐步推进，而不是把几十个需求一次性塞给 AI，避免输出不稳定。
• 对生成结果做人工复核，尤其是涉及判断条件、异常分支、跳出循环等关键节点。AI 出的是初稿，不是最终结论。

如果有条件，可以把 skill 的示例库做成团队内部公共资产。每个业务模块沉淀一份标准流程图，后续新成员只需要改描述，就能快速得到风格一致的图表。这比让每个人从空白画布开始拖拽高效得多。

10. 总结与下一步

这个 skill 最值得试的一点，是把“画图”的交互方式从拖拽改成了打字。对于已经有明确流程结构的人来说，生成初稿的效率会明显提升。建议第一次使用时先验证最基本的“判断 + 分支 + 循环回边”能力，跑通之后再扩展到用户管理、订单处理、算法训练这些复杂场景。

最容易踩的坑是提示词描述不完整，尤其是循环回边和分支标签。AI 不知道你要循环到哪一步，所以描述里必须说清楚“回到判断节点”还是“回到流程开始”。另外一个常见坑是飞书不支持直接渲染 Mermaid，发布前提前想好是截图还是装插件，不要等图做好了才到处找方案。

后续可以继续扩展的方向包括：把 skill 接入到文档生成流程里，让流程图随文档版本一起更新；把输出结果直接上传到对象存储生成图片链接，方便在内部系统里引用；也可以把流程描述写进代码仓库，每次业务变更时同步更新流程图，让文档和代码保持同步。

画流程图这件事，从“手搓”到“说清楚就行”，中间只差一个定义良好的 skill。如果你也经常被流程图排版折磨，建议先把这套方法跑起来，再根据自己的业务习惯慢慢调整规则。