摘要：方框和箭头画完，流程一变又得重排。Mermaid Architect把流程描述、图表源稿和后续修改放到一起，适合那些需要反复解释和维护的工作。
流程图最让人累的时刻，往往出现在“终于画完”以后。
有人说，审批还要加一个人。有人补充，退款失败不能直接结束。你拖动方框、重新接线，把一张原本整齐的图改得越来越挤。
更麻烦的是，一周后回头看，大家记住了图的大概样子，却说不清某条箭头为什么通向这里。
如果流程本身可以保留成文字，修改时先改规则，再更新图形，事情就会轻一些。Mermaid采用的就是用文本描述图表的方式，而Mermaid Architect把选择图型、组织说明和处理图表的步骤整理成了一个Skill。
在NanoSkill营销类榜单截至2026年9月19日的近7个UTC日窗口里，这个项目新增4,092次安装，排在第三位。
先想清楚，你究竟要讲哪件事
Mermaid Architect原仓库支持从文字或代码整理图表，并提供流程、架构、时序等指南，以及提取、检查、导出图表的工具。
第一次添加时，可以直接看项目的安装说明，按自己使用的助手准备对应目录和环境。
对普通使用者来说，第一个价值就藏在“选择图型”里。
想说明售后申请经过哪些步骤，可以画流程图。想解释客户、客服和仓库之间谁先通知谁，更适合画时序图。想介绍一个系统由哪些部分组成，又是另一种表达任务。
把这几件事硬塞进同一张图，很容易出现一种奇怪结果：每个方框都认识，整张图却读不懂。
我建议每次先补完一句话：“看完这张图，对方应该能回答……”
是知道轮到自己时要做什么，还是理解几个部门之间的关系？答案明确，图的范围就会小下来。
让AI先挑出流程里的空白
拿一个虚构的售后流程举例。初始描述可能只有一句：客户提交申请，客服审核，仓库收货，然后退款。
这句话已经足够让AI画出四个方框。但实际执行中，审核不通过怎么办？寄回的商品不符合条件怎么办？退款失败以后由谁处理？
图画得越快，这些没有说明的部分越容易被藏起来。
一张能用的流程图，应该把已知规则画清楚，也把尚未确定的问题留下来。
第一轮任务可以这样写：
请用Mermaid Architect整理以下虚构售后流程。先列出参与角色、触发条件、正常路径和异常分支。缺少的规则先提问，不自行补成业务规定。得到明确规则后，再生成适合新人阅读的流程图，并保留可修改的文本源稿。
这会把AI的工作从“帮忙画图”推进到“帮助整理表达”。你给它的规则越准确，后面的图越有用。
如果暂时无法确认异常情况，可以把对应节点写成“待确认”，单独交给负责人处理。内部讨论稿允许有未决问题，最怕的是未知内容被画成已经批准的标准流程。
图片负责展示，源稿负责下一次修改
用这类技能时，值得养成一个很小的习惯：图片和文本源稿一起留。
仓库中的图表示例把客户端、网关、服务和数据组件之间的关系画了出来。用到自己的项目时，要先替换成真实节点，再核对每条连接的含义。
图片方便放进文档和演示，源稿方便在规则变化后继续编辑。如果只保存一张PNG，下次换一个审核条件，还是会回到重新描述、重新生成的起点。
比如后来决定“退款失败转人工复核”，就把这条新规则明确交给AI，并要求说明改动影响了哪些节点和连接。你可以逐项核对，而不是只看新图有没有变漂亮。
图表还有两种不同的错误。一种是语法或渲染错误，文字无法正确变成图。另一种是业务错误，图能正常显示，箭头却指错了方向，或者漏掉了关键分支。
工具检查有助于发现前一种。后一种必须拿业务规则逐条对照。看到“校验通过”，不要顺手理解成“流程已经正确”。
这在向客户解释方案时尤其重要。一张规整的架构图会给人很强的确定感。如果某个系统连接只是设想，就应当在方案文字里明确表达，不能让画面替代证据。
第一张图，最好故意画小一点
我不建议第一次就扔进去一整套复杂系统，要求AI生成所有文档。
先选一个你熟悉、又确实需要向别人解释的过程。比如内容从提案到发布的审核，报名以后到收到确认的步骤，或者一条需求如何进入开发排期。
把起点和终点说清楚，限制参与角色，要求每个节点只表达一个动作。完成后找一个不了解流程的人，让他沿着箭头复述一遍。他停住的地方，通常比配色意见更值得改。
交付到不同地方，也要看实际显示方式。仓库文档能显示的Mermaid源稿，复制进其他编辑器后未必还是图。准备给同事阅读时，同时导出PNG或SVG会更方便，具体转换需要相应的渲染环境。
原项目名是design-doc-mermaid，仓库内有技能文件和使用说明。它适合愿意保留源稿、后续还会修改的团队。
等下一次有人说“这里还要多加一步”，你可以先讨论这一步为什么存在、应该接在哪里。方框怎么挪，终于可以排到后面。
