业务流程图一键生成

解决了什么问题

需求评审会上，大家用文字描述了「客户下单→风控审核→仓储发货→物流签收」，散在聊天记录和会议纪要里。两周后，后端、运营、风控三方对「审核不通过时订单去哪了」的理解仍然不一致——文字天然无法清晰表达分支、角色边界和状态流转。

手绘流程图同样是体力活：打开画图工具、拖节点、调连线、标方向，再导出图片贴进 Wiki。需求改一次就得重画一遍，而且图片没法 grep、没法 diff、没法走 code review。

这个技能把「从一段自然语言到一张可执行、可版本化的流程图」压缩成一步。

技能如何工作

1. 先补齐业务要素，再动笔画图。 技能首先确认四类输入：参与角色（客户、业务人员、系统、审核人等）、输入与输出、规则条件、结果状态。角色边界不清晰时会先追问，而不是直接套一个通用模板。

2. 用 Mermaid 原生语法建模，而不是套 ASCII 图。 关键约定：

• 角色或系统边界用 subgraph 表达，箭头表示责任交接——谁在哪个框里干活，一眼可见
• 审批、校验、风控节点用 {} 菱形节点，成功、驳回、取消、异常四条路径必须显式写出，不允许出现「→ 结束」式的偷懒分支
• 对订单、申请、工单这类有生命周期的对象，配合 stateDiagram-v2 单独表达状态迁移，避免把状态机塞进普通流程图导致结构混乱

3. 渲染前先做环境检查。 技能会确认本机 mmdc（Mermaid CLI）是否可用、版本是否可用。渲染失败时会区分两类原因：Mermaid 语法错误，还是 Puppeteer 浏览器依赖缺失——前者改图，后者修环境，不让排查方向跑偏。

4. 交付物可追溯。 默认把 .mmd 源码和导出文件写入当前项目的 docs/mermaid/ 目录（不存在则先创建，用户指定路径时按用户要求保存）。交付时附源码与导出文件的绝对路径，以及本机 mmdc 版本号，方便复现。

适用边界与注意点

• 技能不替代建模判断。它擅长把已经想清楚的规则画成图；如果需求本身逻辑不完整、规则自相矛盾，输出的流程图只会把混乱固化下来。
• 依赖本机环境：Mermaid CLI 及其渲染链路需要在本地就绪，技能只做检测和提示，不会在未获明确授权时替你安装或升级。
• 版本策略是「先问再动」：本机 mmdc 落后 npm 最新版本超过 3 个发布版本时，技能会先询问升级还是继续用旧版，而不是擅自升级。
• 适合结构化业务流程（审批流、订单生命周期、工单流转）；如果「流程」本质上是一段算法，直接写代码更合适。
• 流程图默认中文输出，业务对象名、角色名建议与系统内叫法保持一致，避免图和代码对不上。