用自然语言绘制技术图需求描述、局部修改与结果校对编写技术文档时流程图、UML 类图和数据库 ER 图分别用于描述执行过程、代码结构和数据关系。借助支持自然语言输入的绘图工具可以先根据文字生成图表再继续修改节点和连线。这个过程需要解决两个问题怎样把需求描述清楚以及怎样检查生成结果。本文使用 Next-AI-Draw.io 作为操作环境介绍本地运行方法并通过几个简化示例说明提示词的编写与图表校对。示例中的业务规则仅用于演示实际项目应以已经确认的需求、代码和数据库结构为准。1. 先确定要表达什么输入提示词之前先选择图表类型。想表达的内容可以使用的图表操作步骤、判断条件和异常分支流程图类、接口及其关系UML 类图多个对象之间的调用顺序UML 时序图实体、字段及数据关系ER 图服务、存储和网络边界系统架构图同一个模块可以画成不同的图。例如“用户注册”既可以描述为操作流程也可以描述为类之间的依赖关系。如果只输入“画一个注册模块”生成结果可能与预期不同。提示词中最好交代四项内容图表类型。需要包含的对象。对象之间的关系或执行条件。本次不需要展开的内容。对于已有系统可以先整理相关说明再提交。不要让模型自行补全尚未确定的业务规则。2. 准备本地绘图环境2.1 启动应用以下示例使用 Windows 和 Docker Desktop。执行命令前需要启动 Docker并准备可以正常调用的模型 API Key。在 PowerShell 或 CMD 中执行下面的命令将your_deepseek_api_key替换为自己的密钥dockerrun-d--restartunless-stopped--namenext-ai-draw-io-p3164:3000-eAI_PROVIDERopenai-eAI_MODELdeepseek-v4-pro-eOPENAI_BASE_URLhttps://api.deepseek.com-eOPENAI_API_KEYyour_deepseek_api_key ghcr.io/dayuanjiang/next-ai-draw-io:latest这组配置使用 DeepSeek 的 OpenAI 兼容接口。参数含义如下参数含义3164:3000将本机的3164端口映射到容器的3000端口AI_PROVIDER指定模型接入方式AI_MODEL指定模型标识OPENAI_BASE_URL指定兼容接口地址OPENAI_API_KEY设置接口密钥更换模型服务时需要核对接入方式、模型名称和接口地址不能只替换密钥。首次执行需要下载镜像。可以通过下面的命令检查容器状态和启动日志dockerps-a--filternamenext-ai-draw-iodockerlogs--tail100next-ai-draw-io容器启动后在部署电脑的浏览器中访问http://localhost:3164如果3164已被其他程序占用可以修改端口映射左侧的数字并使用修改后的端口访问。2.2 验证模型调用先使用简单提示词检查配置生成一个从上到下排列的流程图包含“开始”“填写信息”“提交”“结束”四个节点按顺序连接。页面打开后仍无法生成图表时应检查模型名称、API Key、接口地址、网络和服务额度。页面可以访问与模型调用成功是两个独立的检查项。本文的应用运行在本地模型推理通过外部 API 完成。相关提示词和图表上下文会发送给模型服务使用时应先处理其中的敏感内容。接口调用也可能产生费用。本地部署不会取消模型服务本身的计费和额度限制。3. 流程图把判断条件写清楚以用户注册为例下面的提示词范围较宽生成用户注册流程图。它没有说明注册方式、校验规则或异常处理。可以改成包含明确条件的描述生成一个网站用户注册流程图从上到下排列。 本示例采用以下规则 1. 用户填写邮箱、密码和确认密码。 2. 检查三个输入项是否为空。 3. 检查邮箱格式。 4. 检查密码与确认密码是否一致。 5. 检查邮箱是否已经注册。 6. 校验通过后创建用户。 7. 创建成功后进入登录页面。 8. 校验失败时显示对应提示并允许用户修改后重新提交。 9. 创建用户失败时显示服务异常提示。 请给判断节点的分支标明条件。 暂不包含短信验证、第三方登录和找回密码。这段描述限定了输入、判断条件、成功路径和异常路径也说明了本次不涉及的功能。生成后应沿着连线逐条检查校验失败后是否仍然进入创建用户步骤。判断分支是否标注了条件。修改信息后是否能够重新提交。服务异常是否被误连到注册成功。是否出现了提示词没有要求的步骤。图表排版整齐并不能证明这些条件已经表达正确。局部修改示例如果需要补充密码长度校验可以继续输入在检查密码与确认密码是否一致之前增加密码长度校验。 本示例要求密码长度为 8 到 20 个字符。 不符合条件时返回填写页面其他流程保持原有逻辑。修改后需要重新检查受影响的路径确认新增分支没有改变其他条件。4. UML 类图先提供类的职责和关系只有“生成登录注册模块 UML 类图”这一句话时模型需要自行假设代码结构。对于已有项目这些假设可能与实际实现不一致。更具体的输入可以写成根据以下设计生成 UML 类图 UserController - 接收注册请求。 - 调用 UserService 的 register 方法。 UserService - 提供 register 方法。 - 执行注册业务校验。 - 通过 UserRepository 查询和保存用户。 UserRepository - 定义为接口。 - 提供 findByEmail 和 save 方法。 User - 包含 id、email 和 passwordHash 属性。 请区分类与接口标明依赖方向。 不要添加未列出的类、方法和继承关系。这里的类和方法属于教学示例。整理已有项目的文档时应替换为代码中的真实定义。检查类图时需要关注类、接口和方法名称是否与输入一致。方法是否放在正确的类中。依赖方向是否符合实际调用关系。是否把普通依赖画成继承关系。是否增加了没有依据的类或属性。如果要描述注册请求经过多个对象的调用顺序应另外绘制时序图。类图主要描述结构无法完整表达执行时序。5. ER 图说明实体、主外键和关系数量“生成一个小型项目数据库 ER 图”没有给出业务范围模型只能自行设计实体和字段。可以用简化的订单系统明确输入根据以下规则生成 ER 图 实体包括用户、订单、订单明细和商品。 关系 - 一个用户可以有多个订单。 - 每个订单属于一个用户。 - 一个订单包含多条订单明细。 - 每条订单明细属于一个订单。 - 每条订单明细关联一个商品。 - 一个商品可以被多条订单明细引用。 字段要求 - 每个实体都包含主键 id。 - 订单包含 user_id。 - 订单明细包含 order_id、product_id、quantity 和 unit_price。 - unit_price 表示下单时的商品单价。 请标明主键、外键和关系数量。 暂不展开支付、物流和退款相关表。生成后应检查订单与商品之间是否通过订单明细建立关联以及主外键是否与关系一致。价格字段也需要结合业务理解。示例中的订单明细保存下单时的单价用来区分历史订单价格与商品当前价格。如果项目已经存在数据库优先使用经过脱敏的表结构作为输入再对照实际约束核对结果。生成的 ER 图不能直接作为数据库结构正确的证明。6. 修改图表时说明位置和范围“优化一下”“画得专业一些”没有明确的检查标准。修改要求可以写成具体操作。调整布局将主流程改为从上到下排列。 异常分支放在右侧。 不修改节点文字和连接关系。补充条件在“支付处理中”之后增加“支付超时”分支。 超时后关闭订单。 库存处理暂不展开。修正关系将订单与用户的关系修正为 每个订单属于一个用户一个用户可以对应多个订单。 其他实体关系保持原有定义。每次围绕一个问题提出修改完成后检查对应区域。大范围修改前可以先保存或导出当前图表方便比较前后差异。7. 放入技术文档前做一次核对不同图表的检查重点不同。图表类型主要检查内容流程图分支条件、异常路径、循环出口、结束状态UML 类图类与接口定义、方法归属、关系类型、依赖方向UML 时序图调用顺序、返回结果、异常处理、对象职责ER 图主外键、关系数量、中间表、字段含义架构图服务依赖、网络边界、数据流向、实际部署情况保存图表时最好同时记录对应的需求或代码版本。后续实现发生变化需要同步检查图中的节点和关系避免文档与系统逐渐脱节。对于只有几个节点的图手动绘制通常也很直接。需要生成较多节点或反复调整结构时可以尝试文字输入再根据校对和修改的工作量判断是否适合自己的文档流程。
Next-AI-Draw.io 实测：用自然语言生成流程图、UML 和 ER 图，再通过 AI 继续修改
用自然语言绘制技术图需求描述、局部修改与结果校对编写技术文档时流程图、UML 类图和数据库 ER 图分别用于描述执行过程、代码结构和数据关系。借助支持自然语言输入的绘图工具可以先根据文字生成图表再继续修改节点和连线。这个过程需要解决两个问题怎样把需求描述清楚以及怎样检查生成结果。本文使用 Next-AI-Draw.io 作为操作环境介绍本地运行方法并通过几个简化示例说明提示词的编写与图表校对。示例中的业务规则仅用于演示实际项目应以已经确认的需求、代码和数据库结构为准。1. 先确定要表达什么输入提示词之前先选择图表类型。想表达的内容可以使用的图表操作步骤、判断条件和异常分支流程图类、接口及其关系UML 类图多个对象之间的调用顺序UML 时序图实体、字段及数据关系ER 图服务、存储和网络边界系统架构图同一个模块可以画成不同的图。例如“用户注册”既可以描述为操作流程也可以描述为类之间的依赖关系。如果只输入“画一个注册模块”生成结果可能与预期不同。提示词中最好交代四项内容图表类型。需要包含的对象。对象之间的关系或执行条件。本次不需要展开的内容。对于已有系统可以先整理相关说明再提交。不要让模型自行补全尚未确定的业务规则。2. 准备本地绘图环境2.1 启动应用以下示例使用 Windows 和 Docker Desktop。执行命令前需要启动 Docker并准备可以正常调用的模型 API Key。在 PowerShell 或 CMD 中执行下面的命令将your_deepseek_api_key替换为自己的密钥dockerrun-d--restartunless-stopped--namenext-ai-draw-io-p3164:3000-eAI_PROVIDERopenai-eAI_MODELdeepseek-v4-pro-eOPENAI_BASE_URLhttps://api.deepseek.com-eOPENAI_API_KEYyour_deepseek_api_key ghcr.io/dayuanjiang/next-ai-draw-io:latest这组配置使用 DeepSeek 的 OpenAI 兼容接口。参数含义如下参数含义3164:3000将本机的3164端口映射到容器的3000端口AI_PROVIDER指定模型接入方式AI_MODEL指定模型标识OPENAI_BASE_URL指定兼容接口地址OPENAI_API_KEY设置接口密钥更换模型服务时需要核对接入方式、模型名称和接口地址不能只替换密钥。首次执行需要下载镜像。可以通过下面的命令检查容器状态和启动日志dockerps-a--filternamenext-ai-draw-iodockerlogs--tail100next-ai-draw-io容器启动后在部署电脑的浏览器中访问http://localhost:3164如果3164已被其他程序占用可以修改端口映射左侧的数字并使用修改后的端口访问。2.2 验证模型调用先使用简单提示词检查配置生成一个从上到下排列的流程图包含“开始”“填写信息”“提交”“结束”四个节点按顺序连接。页面打开后仍无法生成图表时应检查模型名称、API Key、接口地址、网络和服务额度。页面可以访问与模型调用成功是两个独立的检查项。本文的应用运行在本地模型推理通过外部 API 完成。相关提示词和图表上下文会发送给模型服务使用时应先处理其中的敏感内容。接口调用也可能产生费用。本地部署不会取消模型服务本身的计费和额度限制。3. 流程图把判断条件写清楚以用户注册为例下面的提示词范围较宽生成用户注册流程图。它没有说明注册方式、校验规则或异常处理。可以改成包含明确条件的描述生成一个网站用户注册流程图从上到下排列。 本示例采用以下规则 1. 用户填写邮箱、密码和确认密码。 2. 检查三个输入项是否为空。 3. 检查邮箱格式。 4. 检查密码与确认密码是否一致。 5. 检查邮箱是否已经注册。 6. 校验通过后创建用户。 7. 创建成功后进入登录页面。 8. 校验失败时显示对应提示并允许用户修改后重新提交。 9. 创建用户失败时显示服务异常提示。 请给判断节点的分支标明条件。 暂不包含短信验证、第三方登录和找回密码。这段描述限定了输入、判断条件、成功路径和异常路径也说明了本次不涉及的功能。生成后应沿着连线逐条检查校验失败后是否仍然进入创建用户步骤。判断分支是否标注了条件。修改信息后是否能够重新提交。服务异常是否被误连到注册成功。是否出现了提示词没有要求的步骤。图表排版整齐并不能证明这些条件已经表达正确。局部修改示例如果需要补充密码长度校验可以继续输入在检查密码与确认密码是否一致之前增加密码长度校验。 本示例要求密码长度为 8 到 20 个字符。 不符合条件时返回填写页面其他流程保持原有逻辑。修改后需要重新检查受影响的路径确认新增分支没有改变其他条件。4. UML 类图先提供类的职责和关系只有“生成登录注册模块 UML 类图”这一句话时模型需要自行假设代码结构。对于已有项目这些假设可能与实际实现不一致。更具体的输入可以写成根据以下设计生成 UML 类图 UserController - 接收注册请求。 - 调用 UserService 的 register 方法。 UserService - 提供 register 方法。 - 执行注册业务校验。 - 通过 UserRepository 查询和保存用户。 UserRepository - 定义为接口。 - 提供 findByEmail 和 save 方法。 User - 包含 id、email 和 passwordHash 属性。 请区分类与接口标明依赖方向。 不要添加未列出的类、方法和继承关系。这里的类和方法属于教学示例。整理已有项目的文档时应替换为代码中的真实定义。检查类图时需要关注类、接口和方法名称是否与输入一致。方法是否放在正确的类中。依赖方向是否符合实际调用关系。是否把普通依赖画成继承关系。是否增加了没有依据的类或属性。如果要描述注册请求经过多个对象的调用顺序应另外绘制时序图。类图主要描述结构无法完整表达执行时序。5. ER 图说明实体、主外键和关系数量“生成一个小型项目数据库 ER 图”没有给出业务范围模型只能自行设计实体和字段。可以用简化的订单系统明确输入根据以下规则生成 ER 图 实体包括用户、订单、订单明细和商品。 关系 - 一个用户可以有多个订单。 - 每个订单属于一个用户。 - 一个订单包含多条订单明细。 - 每条订单明细属于一个订单。 - 每条订单明细关联一个商品。 - 一个商品可以被多条订单明细引用。 字段要求 - 每个实体都包含主键 id。 - 订单包含 user_id。 - 订单明细包含 order_id、product_id、quantity 和 unit_price。 - unit_price 表示下单时的商品单价。 请标明主键、外键和关系数量。 暂不展开支付、物流和退款相关表。生成后应检查订单与商品之间是否通过订单明细建立关联以及主外键是否与关系一致。价格字段也需要结合业务理解。示例中的订单明细保存下单时的单价用来区分历史订单价格与商品当前价格。如果项目已经存在数据库优先使用经过脱敏的表结构作为输入再对照实际约束核对结果。生成的 ER 图不能直接作为数据库结构正确的证明。6. 修改图表时说明位置和范围“优化一下”“画得专业一些”没有明确的检查标准。修改要求可以写成具体操作。调整布局将主流程改为从上到下排列。 异常分支放在右侧。 不修改节点文字和连接关系。补充条件在“支付处理中”之后增加“支付超时”分支。 超时后关闭订单。 库存处理暂不展开。修正关系将订单与用户的关系修正为 每个订单属于一个用户一个用户可以对应多个订单。 其他实体关系保持原有定义。每次围绕一个问题提出修改完成后检查对应区域。大范围修改前可以先保存或导出当前图表方便比较前后差异。7. 放入技术文档前做一次核对不同图表的检查重点不同。图表类型主要检查内容流程图分支条件、异常路径、循环出口、结束状态UML 类图类与接口定义、方法归属、关系类型、依赖方向UML 时序图调用顺序、返回结果、异常处理、对象职责ER 图主外键、关系数量、中间表、字段含义架构图服务依赖、网络边界、数据流向、实际部署情况保存图表时最好同时记录对应的需求或代码版本。后续实现发生变化需要同步检查图中的节点和关系避免文档与系统逐渐脱节。对于只有几个节点的图手动绘制通常也很直接。需要生成较多节点或反复调整结构时可以尝试文字输入再根据校对和修改的工作量判断是否适合自己的文档流程。
