如何建设盈利网站,创建一个自己的网站的步骤,网站优化 图片,网站服务公司案例不会写代码#xff1f;用DeepSeekMermaid画专业流程图/甘特图#xff08;含APP开发案例#xff09; 最近和几个产品经理朋友聊天#xff0c;发现他们最头疼的不是需求分析#xff0c;也不是原型设计#xff0c;而是怎么把脑子里的流程和计划清晰地呈现给团队。一位在互联…不会写代码用DeepSeekMermaid画专业流程图/甘特图含APP开发案例最近和几个产品经理朋友聊天发现他们最头疼的不是需求分析也不是原型设计而是怎么把脑子里的流程和计划清晰地呈现给团队。一位在互联网公司做了五年产品总监的朋友吐槽“每次开项目启动会我都得花大半天时间在Visio或者ProcessOn上拖拽各种图形调整箭头位置对齐文本框……明明逻辑很清楚画出来却总觉得差点意思。”我问他为什么不试试AI工具他一脸茫然“AI能画图不是只能写文案吗”这让我意识到很多非技术背景的项目管理者、产品经理甚至运营同学其实并不知道现在的AI已经能帮他们解决可视化难题了。你不需要懂编程不需要学复杂的绘图软件只需要用自然语言描述你的想法就能得到专业的流程图、甘特图、架构图。今天我就以移动应用开发全流程为例手把手教你如何用DeepSeek配合Mermaid从零开始创建一套完整的项目可视化文档。我会带你走完“需求分析-原型设计-开发测试”的完整生命周期特别演示如何通过迭代优化提示词让AI理解你复杂的业务逻辑生成精准的分支判断和合理的时间轴设置。1. 为什么选择DeepSeekMermaid这个组合在开始具体操作之前我们先聊聊为什么这个组合特别适合非技术背景的职场人。DeepSeek作为目前最强大的中文AI助手之一它的优势在于对中文语境的理解深度。你不需要用“程序员思维”去描述需求可以用大白话说“我们要做一个电商APP用户先登录然后浏览商品可以加入购物车最后下单支付。”DeepSeek能理解这种自然语言描述并转化为结构化的逻辑。Mermaid则是一个基于JavaScript的图表库它的语法简单到像写Markdown。你不需要拖拽图形只需要用文本描述关系它就能自动渲染成美观的图表。最关键的是Mermaid支持多种图表类型流程图Flowchart展示流程步骤和决策分支时序图Sequence Diagram显示对象之间的交互顺序甘特图Gantt Chart项目时间规划和进度跟踪类图Class Diagram面向对象设计的类关系状态图State Diagram系统状态转换用户旅程图User Journey Map用户体验路径饼图/柱状图基础数据可视化对于产品经理和项目经理来说最实用的就是流程图和甘特图。前者帮你理清业务逻辑后者帮你规划项目进度。1.1 准备工作你需要什么开始之前确保你有以下三样东西DeepSeek账号访问官网注册即可目前完全免费Mermaid在线编辑器推荐使用 mermaid.live 或 mermaid.js.org一个具体的项目案例我们以“社区团购APP”开发为例如果你担心网络访问问题国内也有替代的Mermaid编辑器比如一些支持Mermaid语法的笔记软件如Typora、Obsidian或在线工具。不过我个人测试下来官方的mermaid.live最稳定渲染效果也最好。注意DeepSeek本身不直接生成图像它生成的是Mermaid代码。你需要把这段代码复制到Mermaid编辑器中才能看到可视化结果。这听起来多了一步但实际上比传统绘图软件快得多——修改逻辑时你只需要调整文字描述不需要手动调整图形位置。2. 从零开始用自然语言生成第一个流程图让我们从一个最简单的场景开始用户登录流程。2.1 基础提示词描述你的业务流程打开DeepSeek输入以下内容请帮我创建一个用户登录流程的Mermaid流程图。 流程描述 1. 用户打开APP进入登录页面 2. 用户输入手机号和密码 3. 系统验证手机号格式是否正确 4. 如果格式错误提示“手机号格式不正确” 5. 如果格式正确验证密码 6. 密码错误则提示“密码错误”允许重试 7. 密码正确则跳转到首页 8. 如果用户忘记密码可以点击“忘记密码”进入找回流程这是我实际测试时用的第一个版本提示词。你会发现虽然描述得很详细但AI生成的结果可能不够结构化。我们来看看DeepSeek的第一次回复graph TD A[用户打开APP] -- B[进入登录页面] B -- C[输入手机号和密码] C -- D{手机号格式验证} D --|格式错误| E[提示“手机号格式不正确”] D --|格式正确| F{密码验证} F --|密码错误| G[提示“密码错误”] G -- C F --|密码正确| H[跳转到首页] B -- I[点击“忘记密码”] I -- J[进入密码找回流程]这个流程图基本正确但有几个问题“忘记密码”的入口应该在输入密码之前还是之后密码错误后是回到登录页面还是只清空密码框缺少验证码登录的备选方案2.2 优化提示词增加细节和约束条件现在我们来优化提示词让AI理解更复杂的业务逻辑请创建一个详细的用户登录系统Mermaid流程图包含以下功能点 主要登录流程 1. 用户进入登录页有两个选项密码登录和验证码登录 2. 选择密码登录后 - 输入手机号实时验证格式11位数字 - 格式错误立即提示无法进入下一步 - 格式正确则显示密码输入框 - 输入密码后点击登录按钮 - 系统验证账号密码错误则提示并保留已输入信息 - 连续错误5次后锁定账号30分钟 3. 选择验证码登录后 - 输入手机号点击“获取验证码” - 60秒内可重发验证码有效期5分钟 - 输入验证码后验证 4. 两个登录方式都有“忘记密码”入口点击后进入手机验证流程 5. 登录成功后根据用户身份跳转 - 普通用户 - 首页 - 新用户首次登录- 完善资料页面 - 团长用户 - 团长管理后台 技术要求 - 使用graph TD方向从上到下 - 决策节点用菱形{}表示 - 每个步骤用方框[]表示 - 连接线用箭头--条件用|文本|标注 - 适当分组使用subgraph区分不同模块这次DeepSeek生成的代码就专业多了graph TD A[用户打开APP] -- B[登录页面] subgraph 登录方式选择 B -- C{选择登录方式} C --|密码登录| D C --|验证码登录| E end subgraph 密码登录流程 D[输入手机号] -- F{格式验证} F --|格式错误| G[实时提示错误] G -- D F --|格式正确| H[显示密码输入框] H -- I[输入密码] I -- J[点击登录] J -- K{系统验证} K --|密码错误| L[提示错误并计数] L -- M{错误次数≥5?} M --|是| N[锁定账号30分钟] M --|否| I K --|密码正确| O[登录成功] end subgraph 验证码登录流程 E[输入手机号] -- P[点击获取验证码] P -- Q[60秒倒计时] Q -- R[输入验证码] R -- S{验证码验证} S --|错误| T[提示验证码错误] T -- R S --|正确| O end subgraph 公共功能 B -- U[忘记密码] U -- V[手机号验证] V -- W[设置新密码] W -- B end subgraph 登录后跳转 O -- X{用户身份判断} X --|普通用户| Y[跳转首页] X --|新用户| Z[跳转完善资料] X --|团长用户| AA[跳转管理后台] end这个流程图已经相当专业了包含了清晰的子流程分组subgraph完整的错误处理逻辑业务规则5次锁定、60秒重发多角色跳转逻辑2.3 高级技巧处理复杂分支和循环在实际项目中流程往往更复杂。比如用户可能从多个入口进入登录页登录后可能有各种拦截条件账号冻结、需要实名认证等。这时候你需要教会AI理解“异常流”和“主流程”的区别。我常用的一个技巧是分层次描述请创建一个包含异常处理的登录流程图分为三个层次 1. 主成功流程绿色路径 2. 常规异常流黄色路径如输入错误 3. 系统异常流红色路径如网络错误、服务器异常 具体要求 - 主流程用实线箭头 - 常规异常用虚线箭头 - 系统异常用点线箭头 - 每个节点标注预计处理时间 - 添加注释说明业务规则DeepSeek对这类结构化描述理解得很好它会生成带有样式定义的代码graph TD %% 样式定义 linkStyle 0 stroke:#2E7D32,stroke-width:2px linkStyle 1 stroke:#2E7D32,stroke-width:2px linkStyle 2 stroke:#2E7D32,stroke-width:2px linkStyle 3 stroke:#2E7D32,stroke-width:2px linkStyle 4 stroke:#F57C00,stroke-width:1.5px,stroke-dasharray:5 linkStyle 5 stroke:#F57C00,stroke-width:1.5px,stroke-dasharray:5 linkStyle 6 stroke:#D32F2F,stroke-width:1px,stroke-dasharray:3 linkStyle 7 stroke:#D32F2F,stroke-width:1px,stroke-dasharray:3 A[开始登录] -- B[输入凭证] B -- C{凭证验证} %% 主流程 C --|验证通过| D[生成Token] D -- E[获取用户信息] E -- F[检查权限] F -- G[登录成功br/耗时: 200-500ms] %% 常规异常 C --|密码错误| H[提示错误br/允许重试] H -- B C --|账号锁定| I[提示锁定信息br/显示解锁时间] %% 系统异常 C --|网络超时| J[显示重试按钮] J -- B E --|服务器错误| K[降级处理br/使用缓存数据] K -- F F --|权限获取失败| L[跳转权限申请页]通过这种方式你不仅得到了流程图还得到了一个带有业务说明和技术指标的完整文档。3. 实战案例社区团购APP全流程可视化现在让我们进入正题用一个完整的移动应用开发案例演示如何用DeepSeekMermaid覆盖产品开发的全生命周期。3.1 第一阶段需求分析与功能拆解产品经理拿到一个模糊的需求“做一个社区团购APP类似美团优选”。你需要把这个需求拆解成具体的功能模块。给DeepSeek的提示词作为产品经理我需要将“社区团购APP”需求拆解为功能模块并用Mermaid思维导图形式呈现。 请按以下结构组织 1. 核心角色消费者、团长、供应商、平台管理员 2. 消费者端功能 - 商品浏览与搜索 - 下单与支付 - 订单管理 - 售后与退款 - 个人中心 3. 团长端功能 - 团点管理 - 订单处理 - 佣金结算 - 客户服务 4. 供应商端功能 - 商品管理 - 库存管理 - 订单处理 - 结算对账 5. 管理后台功能 - 用户管理 - 商品审核 - 订单监控 - 财务结算 - 数据统计 要求 - 使用mindmap图表类型 - 层级清晰最多4级 - 关键功能用**加粗** - 技术难点用*斜体*标注DeepSeek生成的思维导图代码mindmap root((社区团购APP)) 核心角色 消费者 注册登录 浏览商品 **下单支付** 订单管理 售后维权 个人中心 团长 团点管理 *地理位置审核* 订单处理 **批量操作** 佣金结算 提现申请 结算明细 客户服务 消息通知 纠纷处理 供应商 商品管理 上架审核 价格调整 库存管理 *实时同步* 订单处理 批量发货 结算对账 对账单 发票管理 平台管理员 系统配置 权限管理 数据监控 消费者端功能 商品模块 分类浏览 搜索筛选 *智能推荐* 商品详情 图文展示 用户评价 交易模块 购物车 **合并支付** 订单流程 选择团点 选择时段 支付方式 支付集成 微信支付 支付宝 余额支付 订单模块 待付款 待提货 已完成 退款/售后 个人中心 我的地址 我的收藏 优惠券 余额/积分 团长端功能 团点管理 地址设置 营业时间 承载能力 订单管理 今日订单 历史订单 订单打印 佣金管理 可提现 已结算 明细查询 客户沟通 群发通知 消息回复 技术架构要点 前端技术栈 React Native 小程序兼容 *性能优化* 后端架构 微服务拆分 用户服务 商品服务 订单服务 支付服务 数据库设计 MySQL主从 Redis缓存 *分库分表* 运维部署 容器化 监控告警 日志分析这个思维导图的价值在于全局视角一眼看清整个项目的功能范围职责划分明确不同角色的功能边界技术预判提前识别可能的技术难点优先级排序核心功能加粗便于排期3.2 第二阶段用户下单流程详细设计有了功能模块接下来需要设计核心业务流程。用户下单是社区团购最关键的流程涉及多个系统交互。给DeepSeek的详细需求设计一个完整的社区团购用户下单流程图包含以下业务规则 前置条件 1. 用户必须已登录且完成实名认证 2. 用户所在区域必须有团长开通服务 3. 商品必须在售且有库存 下单流程 1. 用户从商品详情页点击“立即购买”或从购物车点击“结算” 2. 系统检查用户信息完整性收货地址、手机号 3. 选择提货方式到团点自提或团长配送限3公里内 4. 选择提货时间当天或次日具体时段如14:00-18:00 5. 选择优惠券系统自动计算最优组合 6. 确认订单信息包括 - 商品清单名称、规格、单价、数量 - 商品总价 - 配送费满59元免配送费 - 优惠抵扣 - 实付金额 7. 选择支付方式微信支付、支付宝、余额支付 8. 支付成功后 - 扣减库存 - 生成订单号 - 通知团长新订单 - 给用户发送下单成功通知 9. 支付失败处理 - 显示失败原因 - 保留订单15分钟 - 引导重新支付或取消 异常情况 1. 库存不足提示用户并推荐相似商品 2. 团长休息提示“该团点今日休息请选择其他团点” 3. 地址超出配送范围提示修改地址或选择自提 4. 优惠券过期自动移除并提示 技术要求 - 使用graph LR从左到右布局 - 使用不同颜色区分正常流程和异常流程 - 关键业务规则用注释说明 - 包含系统交互节点如“调用支付接口”DeepSeek生成的流程图代码相当详细graph LR %% 样式定义 classDef normal fill:#e1f5fe,stroke:#01579b,stroke-width:2px classDef check fill:#fff3e0,stroke:#ef6c00,stroke-width:2px classDef action fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px classDef error fill:#ffebee,stroke:#c62828,stroke-width:2px classDef system fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px A[用户点击购买] -- B{检查登录状态} B --|未登录| C[跳转登录页面] C -- D[登录成功] D -- B B --|已登录| E{检查实名认证} E --|未认证| F[跳转实名认证] F -- G[认证完成] G -- E E --|已认证| H{检查用户信息完整性} H --|信息不全| I[补全收货地址/手机号] I -- H H --|信息完整| J[进入订单确认页] subgraph 订单信息确认 J -- K{选择提货方式} K --|到店自提| L[选择团点] K --|团长配送| M[验证配送范围] M --|超出范围| N[提示超出配送范围] N -- K M --|在范围内| O[选择配送时间] L -- P[选择提货时间] O -- Q{检查团长营业状态} P -- Q Q --|团长休息| R[提示更换团点] R -- K Q --|正常营业| S[选择优惠券] end S -- T{系统计算最优优惠} T -- U[显示订单明细] U -- V[确认订单] subgraph 支付流程 V -- W[调用支付接口] W -- X{支付结果} X --|成功| Y[支付成功处理] X --|失败| Z[支付失败处理] end Y -- AA[扣减库存] AA -- AB[生成订单号] AB -- AC[通知团长] AC -- AD[发送用户通知] AD -- AE[订单创建完成] Z -- AF[显示失败原因] AF -- AG{失败类型} AG --|余额不足| AH[引导充值] AG --|网络超时| AI[重试支付] AG --|其他错误| AJ[联系客服] AH -- W AI -- W %% 库存检查异常 U -- AK{实时库存检查} AK --|库存不足| AL[提示库存不足] AL -- AM[推荐相似商品] AM -- AN[用户选择] AN --|更换商品| U AN --|取消订单| AO[返回商品页] %% 应用样式 class A,B,C,D,E,F,G,H,I,J normal class K,L,M,N,O,P,Q,R,S check class T,U,V,W,X,Y,Z,AA,AB,AC,AD,AE action class AF,AG,AH,AI,AJ,AK,AL,AM,AN,AO error class W,X system %% 业务规则注释 linkStyle 23 stroke:#ff6f00,stroke-width:2px linkStyle 24 stroke:#ff6f00,stroke-width:2px style AL fill:#ffebee,stroke:#c62828这个流程图的价值在于完整覆盖从点击购买到订单完成的所有步骤异常处理考虑了各种边界情况业务规则可视化满免配送费、团长休息等规则清晰可见技术交互点标明了系统调用环节3.3 第三阶段开发任务分解与甘特图有了详细的设计接下来需要将工作分解为具体的开发任务并制定时间计划。这是项目经理的核心工作。给DeepSeek的提示词需要包含时间估算和依赖关系基于社区团购APP的需求创建一个详细的开发甘特图包含以下信息 项目时间2024年6月1日启动总工期12周 阶段划分 1. 需求与设计阶段2周 - 需求评审与确认3天 - 原型设计5天 - UI视觉设计5天 - 技术方案设计3天 2. 基础架构开发2周 - 后端微服务框架搭建5天 - 数据库设计与搭建3天 - 用户认证系统3天 - 支付接口对接3天 3. 核心功能开发5周 - 消费者端功能3周 * 商品模块5天 * 购物车与订单5天 * 支付集成3天 * 个人中心3天 - 团长端功能2周 * 团点管理4天 * 订单处理3天 * 佣金系统3天 - 供应商端功能1周 * 商品管理3天 * 库存同步2天 - 管理后台1周 * 数据看板2天 * 审核功能2天 4. 测试与上线3周 - 单元测试5天 - 集成测试5天 - UAT用户测试5天 - 上线准备与发布3天 依赖关系 - 需求确认后才能开始原型设计 - 技术方案设计完成后才能开始架构开发 - 基础架构完成后才能开始功能开发 - 所有功能开发完成后才能开始集成测试 - 消费者端和团长端可以并行开发 里程碑 - 需求确认完成2024-06-05 - 技术方案评审通过2024-06-14 - 基础架构完成2024-06-28 - 核心功能开发完成2024-08-02 - 测试完成2024-08-23 - 正式上线2024-08-30 要求 - 使用gantt图表类型 - 显示关键路径 - 里程碑用milestone标记 - 不同阶段用section分组 - 周末自动排除不考虑加班DeepSeek生成的甘特图代码gantt title 社区团购APP开发项目甘特图 dateFormat YYYY-MM-DD axisFormat %m/%d excludes weekends section 需求与设计阶段 需求评审与确认 :crit, a1, 2024-06-01, 3d 原型设计 :a2, after a1, 5d UI视觉设计 :a3, after a2, 5d 技术方案设计 :a4, after a3, 3d section 基础架构开发 后端微服务框架搭建 :crit, b1, after a4, 5d 数据库设计与搭建 :b2, after b1, 3d 用户认证系统 :b3, after b2, 3d 支付接口对接 :b4, after b3, 3d section 消费者端功能 商品模块开发 :crit, c1, after b1, 5d 购物车与订单 :c2, after c1, 5d 支付集成 :c3, after c2, 3d 个人中心 :c4, after c3, 3d section 团长端功能 团点管理 :d1, after b1, 4d 订单处理 :d2, after d1, 3d 佣金系统 :d3, after d2, 3d section 供应商端功能 商品管理 :e1, after b1, 3d 库存同步 :e2, after e1, 2d section 管理后台 数据看板 :f1, after b1, 2d 审核功能 :f2, after f1, 2d section 测试与上线 单元测试 :crit, g1, after c4, 5d 集成测试 :g2, after g1, 5d UAT用户测试 :g3, after g2, 5d 上线准备与发布 :g4, after g3, 3d %% 里程碑 需求确认完成 :milestone, m1, 2024-06-05, 0d 技术方案评审通过 :milestone, m2, 2024-06-14, 0d 基础架构完成 :milestone, m3, 2024-06-28, 0d 核心功能开发完成 :milestone, m4, 2024-08-02, 0d 测试完成 :milestone, m5, 2024-08-23, 0d 正式上线 :milestone, m6, 2024-08-30, 0d %% 依赖关系 a2 -- a1 a3 -- a2 a4 -- a3 b1 -- a4 b2 -- b1 b3 -- b2 b4 -- b3 c1 -- b1 c2 -- c1 c3 -- c2 c4 -- c3 d1 -- b1 d2 -- d1 d3 -- d2 e1 -- b1 e2 -- e1 f1 -- b1 f2 -- f1 g1 -- c4 g2 -- g1 g3 -- g2 g4 -- g3这个甘特图的专业之处在于关键路径标识用crit标记了影响总工期的关键任务依赖关系明确清晰地展示了任务之间的前后关系时间安排合理考虑了周末休息工作日安排紧凑里程碑清晰重要节点一目了然并行任务优化消费者端、团长端、供应商端可以同时开发3.4 第四阶段数据库ER图设计对于技术评审或与开发团队沟通数据库设计图是必不可少的。虽然产品经理不需要深入技术细节但了解核心表结构有助于评估开发复杂度。给DeepSeek的提示词为社区团购APP设计数据库ER图包含以下核心实体 1. 用户相关 - 用户表usersid, 手机号, 密码, 昵称, 头像, 注册时间 - 用户地址表user_addressesid, user_id, 收货人, 手机号, 详细地址 - 用户实名认证表user_verificationsid, user_id, 真实姓名, 身份证号, 状态 2. 商品相关 - 商品分类表categoriesid, 名称, 父级ID, 排序 - 商品表productsid, 名称, 描述, 价格, 库存, 状态 - 商品图片表product_imagesid, product_id, 图片URL, 排序 - 商品规格表product_skusid, product_id, 规格名称, 价格, 库存 3. 订单相关 - 订单表ordersid, 订单号, user_id, 总金额, 状态, 创建时间 - 订单商品表order_itemsid, order_id, product_id, sku_id, 数量, 单价 - 订单物流表order_logisticsid, order_id, 配送方式, 团点ID, 配送时间 4. 团长相关 - 团长表leadersid, user_id, 团点名称, 地址, 经纬度, 状态 - 团点服务范围表leader_areasid, leader_id, 区域编码 5. 支付相关 - 支付记录表paymentsid, order_id, 支付方式, 支付金额, 状态 - 退款记录表refundsid, payment_id, 退款金额, 原因, 状态 6. 运营相关 - 优惠券表couponsid, 名称, 类型, 面值, 使用条件, 有效期 - 用户优惠券表user_couponsid, user_id, coupon_id, 使用状态 关系说明 - 一个用户可以有多个地址但只有一个默认地址 - 一个商品可以有多个规格SKU - 一个订单包含多个商品 - 一个用户可以成为团长一对一 - 一个团长可以服务多个区域 - 一个订单对应一个支付记录但可以有多个退款记录 - 用户可以领取多张优惠券 要求 - 使用erDiagram图表类型 - 标注主键和外键关系 - 包含字段类型如varchar, int, datetime等 - 使用中文表名和字段名 - 显示基数关系1对11对多多对多DeepSeek生成的ER图代码erDiagram %% 用户相关表 users { bigint id PK 主键 varchar phone 手机号 varchar password 密码 varchar nickname 昵称 varchar avatar 头像 datetime created_at 注册时间 } user_addresses { bigint id PK 主键 bigint user_id FK 用户ID varchar receiver 收货人 varchar phone 手机号 varchar address 详细地址 boolean is_default 是否默认 } user_verifications { bigint id PK 主键 bigint user_id FK 用户ID varchar real_name 真实姓名 varchar id_card 身份证号 tinyint status 状态 datetime verified_at 认证时间 } %% 商品相关表 categories { bigint id PK 主键 varchar name 分类名称 bigint parent_id FK 父级ID int sort 排序 } products { bigint id PK 主键 varchar name 商品名称 text description 商品描述 decimal price 价格 int stock 库存 tinyint status 状态 bigint category_id FK 分类ID } product_images { bigint id PK 主键 bigint product_id FK 商品ID varchar image_url 图片URL int sort 排序 } product_skus { bigint id PK 主键 bigint product_id FK 商品ID varchar spec_name 规格名称 decimal price 价格 int stock 库存 } %% 订单相关表 orders { bigint id PK 主键 varchar order_no 订单号 bigint user_id FK 用户ID decimal total_amount 总金额 tinyint status 状态 datetime created_at 创建时间 bigint leader_id FK 团长ID } order_items { bigint id PK 主键 bigint order_id FK 订单ID bigint product_id FK 商品ID bigint sku_id FK 规格ID int quantity 数量 decimal price 单价 } order_logistics { bigint id PK 主键 bigint order_id FK 订单ID tinyint delivery_type 配送方式 bigint leader_id FK 团长ID datetime delivery_time 配送时间 varchar pickup_code 提货码 } %% 团长相关表 leaders { bigint id PK 主键 bigint user_id FK 用户ID varchar shop_name 团点名称 varchar address 地址 decimal longitude 经度 decimal latitude 纬度 tinyint status 状态 } leader_areas { bigint id PK 主键 bigint leader_id FK 团长ID varchar area_code 区域编码 } %% 支付相关表 payments { bigint id PK 主键 bigint order_id FK 订单ID varchar payment_method 支付方式 decimal amount 支付金额 tinyint status 状态 datetime paid_at 支付时间 } refunds { bigint id PK 主键 bigint payment_id FK 支付记录ID decimal amount 退款金额 varchar reason 退款原因 tinyint status 状态 datetime created_at 申请时间 } %% 运营相关表 coupons { bigint id PK 主键 varchar name 优惠券名称 tinyint type 类型 decimal value 面值 decimal min_amount 最低消费 date start_date 开始日期 date end_date 结束日期 } user_coupons { bigint id PK 主键 bigint user_id FK 用户ID bigint coupon_id FK 优惠券ID tinyint status 使用状态 datetime used_at 使用时间 bigint order_id FK 订单ID } %% 关系定义 users ||--o{ user_addresses : 拥有 users ||--|| user_verifications : 认证 users ||--|| leaders : 成为 categories ||--o{ products : 包含 products ||--o{ product_images : 拥有图片 products ||--o{ product_skus : 包含规格 users ||--o{ orders : 创建 orders ||--o{ order_items : 包含商品 orders ||--|| order_logistics : 配送信息 leaders ||--o{ orders : 负责 orders ||--|| payments : 支付 payments ||--o{ refunds : 退款 coupons ||--o{ user_coupons : 被领取 users ||--o{ user_coupons : 领取 user_coupons }o--|| orders : 使用于 leaders ||--o{ leader_areas : 服务范围这个ER图的专业价值表结构清晰所有核心业务实体都有对应表关系明确使用||--o{等符号表示1对多、1对1关系字段详细包含类型和注释开发可以直接使用符合规范使用英文表名中文注释便于团队协作4. 高级技巧提示词优化与迭代通过上面的案例你可能已经发现好的结果来自于好的提示词。下面我总结了一些提示词优化的经验。4.1 结构化描述法不要一次性描述所有需求而是分层描述第一层总体目标 “创建一个电商订单系统的状态流转图” 第二层核心状态 “包含以下状态待支付、已支付、待发货、已发货、已收货、已完成、已取消、退款中、已退款” 第三层状态转换条件 “状态转换需要满足的条件支付超时30分钟自动取消、发货后3天自动确认收货、收货后7天自动完成” 第四层异常情况 “异常流程用户申请退款、商家拒绝退款、客服介入处理” 第五层可视化要求 “使用stateDiagram-v2类型状态用矩形转换用箭头条件用文本标注”4.2 示例引导法如果你不确定AI能否理解你的需求可以先给一个简单示例请参考下面的简单示例创建一个更复杂的版本 简单示例 mermaid graph TD A[开始] -- B{条件判断} B --|是| C[执行操作] B --|否| D[结束]请创建一个用户注册流程包含手机号验证短信验证码密码设置协议同意注册成功后的跳转### 4.3 约束条件法 明确告诉AI什么不能做什么必须做创建一个项目进度跟踪的甘特图要求必须使用gantt类型必须包含section分组必须显示关键路径crit必须排除周末必须包含至少3个里程碑不能使用默认颜色要自定义颜色时间格式必须是YYYY-MM-DD任务名称必须用中文### 4.4 迭代优化法 很少有需求能一次说清楚所以迭代优化是关键第一轮生成基础版本 “创建一个用户登录流程图”第二轮增加细节 “在刚才的流程图中加入忘记密码流程”第三轮优化样式 “修改颜色主流程用绿色异常流程用红色”第四轮添加注释 “在每个决策节点添加业务规则注释”第五轮调整布局 “改为从左到右的布局并调整节点间距”## 5. 实际工作中的应用场景 掌握了这些技巧后你可以在哪些实际工作中应用呢 ### 5.1 产品需求文档PRD可视化 传统的PRD是大段文字开发同学看着头疼。现在你可以在PRD中嵌入Mermaid图表3.2 订单取消流程业务流程描述用户下单后在特定条件下可以取消订单...流程图graph LR A[用户申请取消] -- B{订单状态检查} B --|未支付| C[直接取消] B --|已支付未发货| D[发起退款] B --|已发货| E[拒绝取消] C -- F[释放库存] D -- G[退款审核] G -- H[退款成功]业务规则未支付订单可直接取消无违约金已支付未发货可取消全额退款已发货不可取消需走售后流程### 5.2 项目进度汇报 每周项目例会用甘特图展示进度 mermaid gantt title 项目进度跟踪第8周 dateFormat YYYY-MM-DD axisFormat %m/%d section 已完成 需求评审 :done, 2024-06-01, 3d 原型设计 :done, 2024-06-04, 5d 技术方案设计 :done, 2024-06-11, 3d section 进行中 后端开发 :active, 2024-06-14, 10d 前端开发 :active, 2024-06-17, 8d section 待开始 测试阶段 :2024-06-28, 7d 上线部署 :2024-07-07, 3d %% 里程碑 原型确认 :milestone, 2024-06-08, 0d 技术评审通过 :milestone, 2024-06-14, 0d 提测 :milestone, 2024-06-28, 0d5.3 技术方案评审用序列图展示系统交互sequenceDiagram participant 用户 participant 前端 participant 网关 participant 订单服务 participant 支付服务 participant 库存服务 用户-前端: 提交订单 前端-网关: 创建订单请求 网关-订单服务: 创建订单 订单服务-库存服务: 预扣库存 库存服务--订单服务: 库存锁定成功 订单服务--网关: 订单创建成功 网关--前端: 返回订单信息 前端--用户: 显示支付页面 用户-前端: 确认支付 前端-网关: 支付请求 网关-支付服务: 调用支付接口 支付服务--网关: 支付成功 网关-订单服务: 更新订单状态 订单服务-库存服务: 确认扣减库存 库存服务--订单服务: 库存扣减完成 订单服务--网关: 订单支付完成 网关--前端: 支付成功 前端--用户: 显示支付成功5.4 运营数据分析报告用统计图表展示数据趋势虽然Mermaid的统计图表功能相对简单但对于基础的数据展示已经足够xychart-beta title 月度销售额趋势 x-axis [1月, 2月, 3月, 4月, 5月, 6月] y-axis 销售额万元 0 -- 100 bar [45, 52, 68, 74, 82, 90] line [45, 52, 68, 74, 82, 90]6. 常见问题与解决方案在实际使用中你可能会遇到一些问题。这里我整理了一些常见问题的解决方法。6.1 生成的图表不符合预期问题AI理解错了你的需求生成的图表逻辑错误。解决方案更详细的描述不要只说“做一个登录流程”要描述具体的步骤和规则分步骤描述先描述整体框架再细化每个部分提供示例给一个类似的简单示例让AI模仿多次迭代不要期望一次成功通过对话逐步修正6.2 图表样式不够美观问题功能正确但样式太丑。解决方案自定义样式在Mermaid代码中添加样式定义使用主题Mermaid支持多种主题如theme: forest、theme: dark调整布局尝试不同的方向TD、LR、BT、RL节点形状根据内容选择合适的形状[]矩形、{}菱形、()圆形、非对称6.3 复杂图表性能问题问题图表太复杂渲染慢或卡顿。解决方案分拆图表一个复杂流程拆成多个简单图表简化细节非关键细节可以省略或合并使用子图用subgraph分组提高可读性增量加载先显示主干再逐步展开细节6.4 团队协作问题问题团队成员不会用Mermaid或者编辑困难。解决方案导出为图片Mermaid编辑器都支持导出PNG/SVG嵌入文档直接复制Mermaid代码到支持渲染的平台如GitHub、GitLab、Notion制作模板创建常用图表的模板团队成员复制修改培训分享组织简单的培训教大家基础语法7. 工具链整合让工作流更顺畅单独使用DeepSeek和Mermaid已经能解决大部分问题但如果能整合到你的工作流中效率会更高。7.1 与文档工具结合Notion直接粘贴Mermaid代码自动渲染语雀支持Mermaid语法Typora本地Markdown编辑器实时预览VS Code安装Mermaid插件在代码中直接编写7.2 与项目管理工具结合GitHub/GitLab在Issue、PR描述中使用MermaidJira通过插件支持MermaidConfluence安装Mermaid插件飞书/钉钉文档部分支持或可通过代码块显示7.3 自动化工作流如果你经常需要生成类似图表可以创建模板# 流程图模板 mermaid graph TD A[开始] -- B{条件判断} B --|条件1| C[操作1] B --|条件2| D[操作2] C -- E[结束] D -- E甘特图模板gantt title 项目计划 dateFormat YYYY-MM-DD section 阶段1 任务1 :a1, 2024-01-01, 5d 任务2 :a2, after a1, 3d section 阶段2 任务3 :a3, after a2, 4d把这些模板保存下来每次需要时复制粘贴修改具体内容即可。7.4 高级技巧使用变量和函数对于需要重复使用的图表可以使用变量graph TD %% 定义样式 classDef start fill:#90ee90,stroke:#333,stroke-width:2px classDef process fill:#add8e6,stroke:#333,stroke-width:2px classDef decision fill:#ffcccb,stroke:#333,stroke-width:2px classDef end fill:#ffb6c1,stroke:#333,stroke-width:2px %% 定义节点 START[开始] -- INPUT[输入数据] INPUT -- VALIDATE{数据验证} VALIDATE --|有效| PROCESS[处理数据] VALIDATE --|无效| ERROR[错误处理] PROCESS -- OUTPUT[输出结果] OUTPUT -- FINISH[结束] ERROR -- FINISH %% 应用样式 class START start class INPUT,PROCESS,OUTPUT,ERROR process class VALIDATE decision class FINISH end8. 从流程图到代码与开发团队的高效协作作为产品经理你的最终目标不是画出漂亮的图而是让开发团队准确理解需求。Mermaid图表可以成为你和开发之间的“通用语言”。8.1 技术评审时的应用在技术评审会上一张清晰的架构图比十页文档更有说服力graph TB subgraph 客户端 A1[Web前端] -- A2[移动端APP] A1 -- A3[小程序] end subgraph 网关层 B1[API网关] B2[负载均衡] B3[限流熔断] end subgraph 业务服务层 C1[用户服务] C2[商品服务] C3[订单服务] C4[支付服务] C5[库存服务] end subgraph 数据层 D1[MySQL主从] D2[Redis缓存] D3[Elasticsearch搜索] D4[MongoDB日志] end subgraph 基础设施 E1[Docker容器] E2[K8s集群] E3[监控告警] E4[日志收集] end A1 -- B1 A2 -- B1 A3 -- B1 B1 -- C1 B1 -- C2 B1 -- C3 B1 -- C4 B1 -- C5 C1 -- D1 C2 -- D1 C3 -- D1 C4 -- D1 C5 -- D1 C2 -- D3 C1 -- D2 C3 -- D2 C1 -- E1 C2 -- E1 C3 -- E1 C4 -- E1 C5 -- E1 E1 -- E28.2 接口文档辅助在API文档中用序列图展示调用流程sequenceDiagram participant C as Client participant G as Gateway participant A as AuthService participant O as OrderService participant P as PaymentService C-G: POST /api/orders Note over G: 鉴权拦截 G-A: 验证Token A--G: 用户信息 G-O: 创建订单 O-O: 库存检查 O-O: 价格计算 O--G: 订单详情 G--C: 返回订单信息 C-G: POST /api/orders/{id}/pay G-P: 发起支付 P-P: 调用支付渠道 P--G: 支付参数 G--C: 返回支付信息 C-第三方支付: 调起支付 第三方支付--C: 支付结果 C-G: POST /api/payments/callback G-P: 支付回调 P-O: 更新订单状态 O--P: 更新成功 P--G: 回调成功 G--C: 支付完成8.3 数据库变更沟通表结构变更时用ER图清晰展示erDiagram %% 原有表结构 users { bigint id PK varchar username varchar password } orders { bigint id PK bigint user_id FK decimal amount } users ||--o{ orders : 创建 %% 新增表 user_profiles { bigint id PK bigint user_id FK varchar real_name varchar id_card varchar avatar } %% 新增关系 users ||--|| user_profiles : 补充信息 %% 字段变更说明 note right of users 新增字段 - phone: varchar(11) - email: varchar(100) - status: tinyint end note note right of orders 新增字段 - order_no: varchar(32) - payment_method: varchar(20) - delivery_address: text end note9. 超越基础创意可视化应用掌握了基础用法后你可以尝试一些更有创意的应用。9.1 用户旅程地图journey title 用户购买旅程 section 认知阶段 看到广告: 5: 用户 搜索产品: 4: 用户 浏览官网: 3: 用户 section 考虑阶段 比较竞品: 4: 用户 查看评价: 5: 用户 咨询客服: 3: 用户 section 决策阶段 加入购物车: 4: 用户 犹豫比价: 2: 用户 最终下单: 5: 用户 section 售后阶段 等待收货: 3: 用户 使用产品: 5: 用户 发表评价: 4: 用户9.2 四象限分析图quadrantChart title 产品功能优先级评估 x-axis 低实施成本 -- 高实施成本 y-axis 低业务价值 -- 高业务价值 quadrant-1 快速取胜 quadrant-2 战略投资 quadrant-3 避免或外包 quadrant-4 谨慎选择 登录优化: [0.2, 0.8] 推荐算法: [0.8, 0.9] 界面美化: [0.3, 0.4] 数据大屏: [0.7, 0.6] 客服机器人: [0.6, 0.3] 社交分享: [0.4, 0.5]9.3 时间线图timeline title 产品发展历程 section 2023年 第一季度 : MVP版本上线 : 核心交易功能 第二季度 : 用户突破10万 : 启动A轮融资 第三季度 : 引入团长体系 : 覆盖3个城市 第四季度 : 完成A轮融资 : 团队扩张至50人 section 2024年 第一季度 : 推出供应商平台 : 日订单破万 第二季度 : 启动城市扩张 : 进入10个新城市 第三季度 : 技术架构升级 : 微服务改造 第四季度 : 筹备B轮融资 : 探索新业务线9.4 饼图展示数据分布pie title 2024年Q1销售额占比 华东地区 : 35.2 华南地区 : 28.7 华北地区 : 18.5 西南地区 : 9.8 其他地区 : 7.810. 实战经验分享我在实际项目中用这套方法已经半年多了总结了一些实用经验第一从简单开始。不要一开始就尝试画复杂的系统架构图先从单个功能的小流程图开始。比如先画“用户注册流程”再画“下单流程”最后组合成完整的业务流程图。第二建立模板库。把常用的图表保存为模板比如“用户状态流转图”、“订单生命周期图”、“项目甘特图模板”。下次需要时直接复制修改效率提升十倍不止。第三与团队共享。在团队内部推广这种方法建立统一的图表规范。我们团队现在要求所有技术方案必须包含Mermaid流程图所有项目计划必须用Mermaid甘特图。沟通效率明显提升。第四持续优化提示词。我建立了一个提示词库按场景分类简单流程图提示词复杂状态图提示词项目甘特图提示词系统架构图提示词数据库ER图提示词每次有新的优化就更新到库里现在生成一个专业图表平均只需要2-3轮对话。第五结合其他工具。Mermaid适合画结构图但数据可视化还是需要专业工具。我的工作流是用DeepSeekMermaid画流程和架构用PythonMatplotlib做数据分析图表用ECharts做交互式报表。各取所长。最近我在规划一个新项目时用了一个下午就完成了过去需要两天的工作需求脑图、用户旅程图、业务流程图、系统架构图、开发甘特图、数据库ER图。团队评审时技术负责人说这是他们见过最清晰的需求文档。最让我意外的是开发同学看到这些图表后主动来找我讨论技术细节——这在以前是很少见的。因为图表比文字更直观他们能更快理解业务逻辑甚至提前发现了一些设计上的问题。现在我不再害怕画图了。相反我享受用自然语言“描述”图表的过程看着AI把我模糊的想法变成清晰的图形这种体验真的很奇妙。如果你也是非技术背景的产品或项目管理者我强烈建议你试试这个方法。它不会让你变成程序员但能让你和技术团队沟通时不再有那种“鸡同鸭讲”的无力感。毕竟在这个AI时代最大的竞争力不是你会什么工具而是你知道如何用AI放大你的能力。DeepSeekMermaid这个组合就是产品经理的“翻译官”——把业务语言翻译成技术语言把模糊想法翻译成清晰图表。