先整理活动，再决定图形
本篇用原创的社区展厅设备借用流程说明如何从纪要生成图：申请人提交用途，值班员检查库存，管理员按规则确认，交接时登记设备，归还后检查状态。案例不是已经上线的审批制度。目标是活动表、角色清楚的泳道图、可编辑源文件及能与源文件对应的展示版，而不是只有一张漂亮截图。
先确定流程边界、读者、起点、终点和规则来源。把纪要中的事实、建议和待确认问题分开。例如“紧急时可先借”如果只是讨论意见，不能直接成为绕过审批的箭头。给每条活动保存稳定编号、负责人、输入、动作、输出及下一条件。遗漏的信息列问题，不由 Agent 补写业务政策。
场景一：纪要变成可检查的活动草稿
先抽取申请、检查、批准、交接、归还与检查六类动作，再确认每个动作由谁负责。一个节点尽量表达一个可以检查的动作，不把整段纪要塞进框里。角色名称统一，区分申请人、值班员和管理员，避免同一角色在不同段落被误当成两个人。
条件必须有可解释出口。库存不足回到改期或取消，材料不全回到补充，归还损坏进入异常处理；不要只画顺利通过的路线。为取消、超时和重复申请明确处理方式，不确定时标为待确认。本例不自行设定具体时限或赔偿金额，那些需要真实制度依据。
请流程负责人按活动编号走一遍正常路径和两个失败路径，再生成图。每一步问“谁知道已完成、产物在哪里、下一步何时开始”。若发现一个角色同时既申请又批准，应核对是否允许，不把图形画法当成制度判断。产物是活动表、问题清单及版本记录，后面所有图形都来自这个经过审阅的结构。
场景二：泳道、审批与项目视图分别表达什么
泳道主要表达责任交接，横向或纵向取决于阅读场景和复杂度。把动作放在实际执行者的泳道内，跨道箭头标明交接内容。并行检查与先后审批不同，汇合时说明需要全部完成还是任一条件成立。审批结果用清楚的分支文字，拒绝不能只用红色表达。
设备借用图可以把申请和补充材料放在申请人道，库存检查和实物交接放在值班员道，规则确认放在管理员道。归还检查后的正常关闭与异常处理分开。节点编号与活动表一致，修改负责人时可以查到所有受影响的箭头。泳道位置不能代替授权说明，图也不证明系统真的执行这些规则。
项目时间线适合说明阶段和日期，甘特图需要真实起止与依赖，不能从活动顺序随意推算工期。乌龟图可用于梳理过程输入、输出、资源、方法与衡量方式，它不是审批路线的等价替代。架构图、时序图、状态图和 ER 图分别回答组件、消息、状态及数据关系问题，先选问题再选模板，不把所有图都堆进一张流程图。
需要拖拽维护时可评估 diagrams.net 的可编辑文档；使用 .drawio 或 XML 源文件时，应在目标编辑器实际打开、检查节点和连接，再保存复开。图片与 SVG 通常只是展示资产，不能一概当作可还原的原生流程源文件。保留源文件、展示输出及对应版本，后续不必凭截图重新画。
场景三：Mermaid 源码与汇报版一起维护
Mermaid 适合把结构化图源码放在文档或版本库中。先使用目标渲染器支持的基本语法，给节点稳定 ID、给标签清楚文本，再逐步增加分组和样式。subgraph 可帮助分组，但不能保证形成严格固定的泳道布局；外部连接还可能影响子图方向。版式需求严格时应选择支持该布局的编辑流程，而不是承诺一句话必然得到指定坐标。
生成后先在真实交付平台渲染，检查语法、中文字体、长标签、分支和箭头。GitHub 或某文档站支持 Mermaid，不代表所有 Markdown 查看器或版本都支持同样能力。某些环境只显示代码，需要插件或导出展示图；不能承诺不需要任何环境准备。把渲染器版本和导出方式写进维护说明。
汇报版优先保证信息层次：统一动作、判断、开始结束的视觉表达，缩短标签，把详细规则放在编号说明中。用线型、文字和位置表达区别，不只依赖颜色；检查黑白打印与窄屏是否仍能阅读。阴影和品牌配色不能修复错误箭头，也不应让读者看不见异常路线。
例如把“管理员确认”移到库存检查之后，先更新活动表和条件，再更新源图，最后重新导出展示版。检查回退路径是否仍指向正确节点，不能只移动一个方框而留下旧关系。交付记录应说明改了什么规则、哪些节点受影响及谁复核，避免第五版图仍引用第三版说明。
Skill 的实际用途与前提
本次目录搜索返回的 Mermaid 相关条目偏向代码 Wiki、网站打包和特定 Wiki 转换，并未核实原文五个通用流程绘图 Skill，因此不猜测安装链接。主体图形按 Mermaid 或 diagrams.net 官方文档和实际目标环境制作。公开 Mermaid 项目接口与文档清楚，适合源码图工作流，但仍要核对版本、许可和布局限制，不能以流行程度代替功能匹配。
Writing Guidelines 适合活动说明和维护文档的技术表达审阅：角色命名、步骤、条件、产物与具体文件引用。需要待审文件及其规则来源。它不自动生成 Draw.io、验证业务政策或运行 Mermaid。来源许可核验、静态扫描与实际执行是不同证据，不能从详情页可访问推断已全面测试。
实操请求与验收方法
可以请求：“把提供的设备借用纪要整理为活动表，列出角色、输入、输出和每个分支；未确认规则单独列出。先审阅活动表，再生成可编辑图源码与展示版。覆盖库存不足、补充材料、取消和归还异常，不编造时限或金额。保留节点编号，说明目标渲染环境和未验证事项。”这比只要求高颜值更容易验收。
验收分成逻辑与文件两层。逻辑上检查每个开始能到达合适终点、每个判断出口有名称、交接有负责人、异常不会无故消失。文件上打开源文件，修改一个标签并保存复开，确认仍可编辑；对照展示版检查内容一致、文字无截断、字体可读。没有实际进行的操作写为计划，不当成已通过。
排错、FAQ 与来源
语法失败先缩到最小图，检查引号、特殊字符和不支持的功能；布局混乱先减少跨组长连接，再考虑拆图。某平台显示代码而不是图，检查其渲染支持，不反复修改业务逻辑。图与纪要冲突时回到规则来源，不能由最后生成的版本自动获胜。
能编辑吗？取决于保留的源格式和目标工具，不能仅凭文件扩展名保证。复杂流程会画错吗？可能，活动表审阅与路径走查必须保留。是否一定需要安装软件？浏览器编辑器也有文件与访问前提，离线或企业环境可能需要其他配置。自然语言修改后算完成吗？还应重新渲染并检查受影响路径。
本篇参考 Mermaid 官方流程图文档与 diagrams.net 编辑资料，原文中英文来源配对保留。社区展厅是原创教学案例，没有虚构用户证言、安装量或绘图执行。交付应包含活动表、未决规则、可编辑源码、展示版和实际复核记录，流程变化时同步更新这些产物。