企业官网建设流程全解析

如果你最近也在和流程图死磕，尤其是在图形画布上反复拖连线、挪节点、调箭头，那你一定要看看现在社区里讨论度很高的那类“流程图Skill”。我前阵子刚好被用户管理模块的流程图折磨到崩溃，改一个权限分支，整张图的布局全乱了。后来照着这个思路，把流程图的维护彻底“降维”到文字层面，才算是真正解脱。这篇文章就把我折腾下来的完整过程、Skill设计逻辑、接入方式和踩过的坑都写出来，给同样被画图折磨的朋友一个参考。

1. 画布上的一次次改图事故，到底坑在哪

1.1 一次改到崩溃的真实经历

前阵子我在整理用户管理模块的流程图，需求是先画一张从账号登录到角色分流的图。刚开始用免费的绘图软件，几分钟拖出来第一版：开始节点、账号密码输入、校验判断、角色判断、进入不同首页。看着整整齐齐，还挺满意。

结果产品经理过来说，要加一个“连续输错5次锁定账号”的逻辑。我当时想，这不就是在一个判断后面加个分支吗，小事。结果真正动手时才发现，画布上的连线不会自动避让，更不会智能重排。我把新节点拖进去之后，原本三根清晰的箭头全部缠在一起，布局彻底乱掉。我花了二十多分钟去对齐、绕线、调整位置，最后的效果还是很丑，甚至有一条线直接从三个节点中间穿过去。

最后没办法，我把整张图删掉，重新画了第二版。第二版刚画完，产品经理又补了一句：“管理员登录后需要能看到重置密码入口。”那一刻我内心的崩溃感直接拉满，因为我大概能预见到，这张图马上又要重画了。

我相信画过流程图的人都有类似的经历：改一个节点、动一条线、加一个分支，整张图垮掉。不是绘图软件不够好，draw.io、ProcessOn这些工具已经很成熟了，真正的问题在于，图形化编辑这种交互方式，天然就不适合高频修改逻辑的场景。

1.2 崩溃的本质：逻辑和布局被强行绑在一起

一张流程图，本质上包含两件事：一是“业务逻辑”，也就是节点之间有序的依赖、分支、循环关系；二是“视觉布局”，也就是每个节点放在画布的哪个坐标位置、线条怎么绕、图形尺寸是否统一。

在传统绘图工具里，这两件事被混合记录在同一张画布上。你修改逻辑时，布局不会自动跟随重建，它只会把原本整齐的东西打乱。于是，“增加一个分支”这种在逻辑上只需要几秒的操作，落到画布上往往需要十分钟来收拾残局。

更崩溃的是，就算你这次把布局调好了，下次再改的时候，之前的微调又会作废。我见过很多同事，包括我自己，最后都选择“推倒重画”而不是在旧图上继续改。这说明图形化编辑的容错性太低了，它把最重要的逻辑变更，跟最不稳定的视觉参数耦合在一起。

换一个角度看，流程图的底层信息完全可以只靠文本描述：

1. 开始 2. 输入账号密码 3. 校验账号密码 通过 -> 4 失败 -> 3.1 3.1 失败次数 + 1 如果次数 >= 5 -> 锁定账号，结束 否则 -> 回到 2 4. 判断角色 管理员 -> 5 普通用户 -> 6 5. 进入管理员首页 6. 进入普通用户首页

看，这段文本完整表达了逻辑，却没有一个坐标参数。无论图怎么渲染，这段文字的维护成本都极低。这其实就是“让修改回到文字里”的底层逻辑。

1.3 文本化不是新鲜事，但Skill把它变成了日常操作

文本化绘图的想法其实早就有了，Mermaid、PlantUML这些方案已经存在很多年。但过去它们有个门槛：你得学语法、记关键字，本质上还是在改代码。很多业务同学看到graph TD这类代码就头疼，最后还是回到拖拽画图。

而最近社区里讨论度很高的那类“流程图Skill”，把这一步往前推了一大截：你不需要自己写语法，AI负责把你的口语化描述转成结构化文本，再根据文本渲染成图。你要做的只是改一句人话，比如“锁定的条件从5次改成3次”，AI会自动更新文本清单里的判断条件，然后重新生成图。

这也正是我决定自己落地一个Skill的原因。手动拖拽太累，直接写语法有门槛，而让AI在文字层面替我维护流程，刚刚好。

2. 这个热门Skill做了什么：把改图变成改话

2.1 Skill就是给AI写的一份“岗位说明书”

如果你用过Claude Code、Cursor或者Codex这类AI编程助手，可能已经接触过“Skill”这个概念。它本质上是一个可复用的技能包：一个文件夹，里面放一份规范的指令文件，告诉AI在特定场景下应该按什么顺序、什么格式、什么原则来完成工作。

Skill可以理解为给AI写的一份“岗位说明书”。Agent是那个执行任务的人，Skill则是一本操作手册。没有技能包时，AI像一个什么都懂一点但很随意的实习生；加载了技能包之后，它就有了明确的工作流程和输出标准。

一个标准的流程图Skill，至少包含一个SKILL.md文件。这个文件头部有frontmatter，里面写名字和描述，正文部分则是详细的工作规则。AI助手会扫描这些描述，当用户任务匹配时，自动把技能包里的规范加载到上下文里。这也是Skill比普通Prompt高级的地方：它是文件化的、可命中触发的、可版本管理的。

2.2 一个流程图Skill的典型工作流

我实际用下来，这类Skill的工作流可以拆成四步：

1. 用户用自然语言描述需求，比如“帮我画一张用户管理模块的流程图”。
2. Skill让AI先输出结构化的流程文本，使用缩进表达分支和嵌套，不直接生成图形代码。
3. AI再基于这份文本，按用户指定的渲染语法（比如Mermaid或PlantUML）生成图表代码。
4. 用户后续要求修改时，Skill强制AI先更新结构化文本，再重新生成代码。

整个过程相当于把“菜谱”和“成品菜”分开。菜谱是那串文本，成品图是渲染出来的结果。你要调整口味，改菜谱就行，不用重新炒一盘菜去摆盘。

这里有个容易被忽略的设计点：先有文本，后有代码。很多AI在没有约束的情况下，会直接生成一大段图表代码，用户改起来还是像在读天书。而Skill通过行为规范，强制AI把逻辑沉淀成人类可读的文本，这样后续每一次修改都变得可追踪。

2.3 它解决的不只是“改”，还有“一致性”

过去在画布里改图，改完一次，往往文档里的旧截图、PPT里的旧版本、需求文档里的描述全都不一致。而文字化的流程文本可以作为“唯一事实源”，一份文本可以被反复渲染成图，放进设计文档、PPT、Wiki甚至代码注释里。

团队成员也能通过Git对流程文本做代码评审。谁改了哪个分支、为什么去掉了一个判断，都能在diff里清楚看到。这是传统绘图软件完全做不到的。也正因为这一点，越来越多的开发团队愿意把流程类Skill纳入工作流，而不只是把它当成画图的玩具。

3. 手写一个流程图Skill：从零搭一个能用版本

3.1 最小的Skill目录长什么样

我不建议直接找一个闭源或黑盒的远程Skill来用，自己动手写一个反而能彻底理解它的原理。下面是最小的目录结构：

flowchart-skill/ ├── SKILL.md └── templates/ └── flow-template.txt

SKILL.md是整个技能包的核心。我写了一个精简但完整的版本，你可以直接参考：

--- name: flowchart-text description: 将任意业务、系统或算法流程转化为结构化文本，并根据用户要求对文本进行增量修订，然后输出可渲染的图表描述。适用于用户管理流程、业务审批流、算法逻辑图等场景。 --- # 工作方式 当用户请求与流程图相关时，必须按以下顺序执行： 1. 将需求整理成结构化流程文本。 - 使用数字编号表示节点。 - 使用缩进表示嵌套分支。 - 分支条件写在节点行内，用“如果/否则”表达。 2. 在文本之后，按用户指定格式输出可渲染图表代码。 - 如果用户未指定，默认使用 Mermaid。 - 如果用户指定 BPMN，则输出 BPMN 结构描述。 3. 用户提出修改时： - 先基于上一次的完整文本做增量更新。 - 在回复开头用“变更点：”列明本次修改了哪些节点。 - 输出完整的更新后文本，而不是只输出差异片段。 4. 当流程超过 20 个节点时，使用“子流程”拆分。 - 子流程用“详见 [节点编号]”的方式引用。

这样一个文件，就足以让AI在多数编程助手里被触发。frontmatter里的name是技能包唯一标识，description决定了模型在什么情况下加载它，所以描述一定要写清楚适用范围，越具体命中率越高。

3.2 核心设计：先文本，后渲染

很多人会问，为什么不让AI直接生成Mermaid代码，省一道步骤？我的经验是：Mermaid代码本质上是一行压缩过的字符串，如果直接改它，模型很容易把某个箭头写错，而且diff可读性极差。

结构化文本则友好得多。每次修改都是针对节点编号、分支条件和缩进关系进行更新，出错时一眼就能看出来。渲染代码反而应该被视为“产物”，每次由AI重新生成，不需要人工维护。

这里也涉及一个技术选择：渲染语法用什么。社区流行的是Mermaid，因为GitHub、Notion、各类文档系统都原生支持，零成本呈现。如果你的团队在用企业级BPMN工具，那Skill的模板里可以换成BPMN XML结构描述，原理是一样的。

3.3 一个容易忽略的细节：模型必须输出“完整文本”

我在第一次写Skill时没有强调“输出完整文本”，结果AI每次都只返回“这次改好了，看第3条”。它以为用户能记住上一版，但上下文一长就乱了，而且后续如果用户复制这段去渲染，拿到的是残缺内容。

所以我在技能规范里强制加了一条：每次修改后，必须输出完整更新文本。这看起来浪费一点输出字数，但换来了极高的可操作性。你可以直接复制整段文字，也可以把整段文字交给下一个模型去继续处理，不会因为上下文截断或者复制遗漏而出错。

4. 三个实战场景：从用户管理模块到算法作业再到BPMN

4.1 案例一：用户管理模块的分支流程

我最初就是为了解决这个场景才建Skill的。把开头那个“锁号逻辑”写成文本后，修改两个字的成本约等于零。产品经理说“5次改成3次”，我只需要让AI把文本里的>= 5改成>= 3，图就自动更新了。

后来产品还要加“管理员可重置密码”的功能。我在流程文本的角色判断分支后面补了一条：

4. 判断角色 管理员 -> 4.1 普通用户 -> 5 4.1 管理员操作菜单 是否重置密码？ 是 -> 重置流程 否 -> 进入管理员首页

这就是一段文字，不用连一条线，不用调一个坐标。AI收到这句话后，能自动把4.1节点以及相关分支全部重建。整套操作从半小时缩短到一分钟。

4.2 案例二：算法作业里的“老三样”流程图

社区热词里出现了一堆典型的算法作业题：输入十个数找最大值、判断一个数能否同时被3和5整除、求两个数m和n的最大公约数、输入abc比较大小。这类题目特别适合用文字化流程来表达，因为算法本身就是“步骤+条件”。

举一个求最大公约数的例子：

1. 输入 m, n 2. 如果 m % n == 0 -> 输出 n，结束 3. 否则: r = m % n m = n n = r -> 回到 2

这个文本版的流程图，教学时可以直接贴在作业里，老师一眼能看懂逻辑。而且学生改起来心里负担小很多，不像图形工具那样需要在画布上重做。

我自己实际体验是，只要Skill被正确触发，这类算法流程几乎不会出错。模型本身对算法逻辑的理解力很强，Skill只需要提供一个稳定的输出框架，剩下的都是模型的基本功。

4.3 案例三：从采购到销售的业务流程与BPMN网关

业务场景比算法场景复杂一些，比如热词里那个“从采购到PS到销售”的SAP流程。这类流程通常涉及多个部门、多个系统，还有BPMN里的排他网关、并行网关。

文字化方案在这里的价值更大。你可以用角色标签代替泳道，用网关标记表达分支：

1. [采购部] 创建采购申请 2. [排他网关] 库存是否充足？ 是 -> 直接创建采购订单 否 -> 走审批流程，审批通过后创建采购订单 3. [计划部] 确认到货计划（PS节点） 4. [销售部] 根据到货计划创建销售订单 5. [并行网关] 同时触发财务开票和物流发运

看到没有，泳道、网关、并行分支，全部通过文本标记表达。需要转成BPMN建模工具里的图时，AI可以基于这段文本生成对应的BPMN结构描述，再导入建模工具。对SAP顾问或者业务分析师来说，这意味着他们可以在不打开重型建模软件的情况下，先在文字层面把流程聊清楚。

4.4 一个小提醒：不要上来就追求完美排版

使用这类Skill时，我的经验是前几版不要关注图的样式、颜色、布局，先把节点和分支逻辑跑通。文本化流程最大的优势是逻辑本身，排版是渲染阶段的事情。很多初学者会花大量时间去调箭头颜色，结果业务逻辑还没理清楚，完全本末倒置。

5. 把Skill接入主流AI编程助手：路径、验证与边界

5.1 三个主流环境下的Skill放入路径

下面是我目前知道的几种常用接入方式，不同工具版本可能有差异，建议以官方文档为准：

5.2 接入后的第一个验证用例

装完之后，我建议拿一个最简单的需求验证Skill是否生效。比如直接输入：“画一张图，输入10个数，输出其中最大的数。”

如果AI只是随手画了一个非常普通的图，没有任何先文本后代码的流程，说明Skill没有被识别。如果AI先给出一份编号清晰、分支明确的文本，再基于文本输出可渲染代码，说明技能包正常加载了。

这个验证很关键，因为很多人装完Skill后根本不知道有没有生效，就开始问复杂业务问题，最后只能用普通Prompt硬跑，效果自然不稳定。

5.3 Skill与普通Prompt的本质区别

很多时候，团队问我到底要不要花时间做Skill，直接写Prompt不行吗？我一般这样解释：

普通Prompt是一次性的口头叮嘱，说完就忘了。Skill是固化的标准作业程序，放在项目仓库里，人人都可以复用。普通Prompt遇到复杂场景时很容易漏关键约束，Skill则把关键约束写死在文件里，每次加载都会自动带上。

从协作角度看，Skill也更像一个可以评审、测试、迭代的“代码资产”。这个资产可以进Git，可以打标签，可以通过PR更新，有问题时能快速回滚。普通Prompt在这些事情上完全无法管理。

6. 我调试这个Skill时踩过的四个坑和最终解法

6.1 坑一：模型“不听话”，直接甩一大段渲染代码

我第一版Skill运行得很差，原因是我只在正文里写了“建议按文本输出”，但模型往往直接生成完整图表代码。后来我把规则从“建议”改成“必须”，并且在前言里写明了强制性的处理顺序。效果立刻不一样。

这背后其实是模型对指令优先级的问题。你需要清楚告诉模型：技能包里的规则在这个场景下优先于默认行为。换句话说，写Skill时语气要像在写代码约束，而不是写建议文档。

6.2 坑二：分支条件挤在一行，渲染混乱

早期版本我把分支写成这样：“判断角色，如果是管理员就进首页，如果不是就返回登录。”AI在生成图表时常常分不清条件和动作的边界，渲染结果乱套。

后来我在Skill里严格定义了分支格式：条件写在节点行内，后面用->指向跳转目标，目标和分支都用缩进方式排列。模型对固定格式的遵循程度远高于自由发挥，这点非常关键。

6.3 坑三：复杂流程超过20个节点后完全失控

有一次我处理跨部门流程，一口气写了30多个节点。AI在生成图表时先是漏掉了两个节点，然后又出现重复的箭头。我意识到，对模型来说，长流程的直接渲染是容易出错的。

我的解法是在Skill里加入“子流程拆分”规则：超过20个节点就拆成子流程，用编号引用。主流程只保留骨架，细节统一放子流程里。这样既减轻了模型的认知负担，也让整体结构更清晰。

6.4 坑四：多人协作时各改各的，版本一团乱

团队里几个人同时用同一个Skill，但各自有各自的偏好，有人喜欢中文节点，有人用英文ID，改出来的图五花八门。后来我在Skill里加了输出规范：节点ID一律用数字编号，标签一律用中文，分支状态在条件里明确写出。

规范定死之后，所有人的产物风格一致，Git diff看起来清晰很多，评审效率也上来了。这其实也说明了一个道理：Skill的维护和更新，跟代码里定规范一样，需要持续投入。

7. 这套文本化流程图的思路，后来还帮我做了这些事

用顺了这个流程图Skill之后，我发现“逻辑先文本化，渲染交给工具”的思路，其实能推广到更多地方。比如我把它扩展成了“状态机文本化”和“时序图文本化”，做法几乎一样：描述状态和事件，AI生成文案，再让工具渲染成图。

现在我在写设计文档时，也习惯先写一段结构化文本描述模块边界，再贴进文档站点，自动出图。甚至在代码评审的时候，我会用一小段流程文本说明调用链路，评审人员不用看一大坨代码就能理解设计意图。这套方法那些“图改着改着就崩了”的问题，算是彻底告别了。如果你也天天被流程图折磨，真心建议你今天花半小时写一个自己的Skill，然后把画布关掉。