Moral ChoicesAI 生成用例图这件事，我一开始是持怀疑态度的。用例图在 UML 里看起来简单——几个火柴人、几个椭圆、几条实线——但真正画过的朋友都知道，把一段自然语言需求转成一份各方都认账的用例图，里面全是主观判断：粒度怎么把握、谁算参与者、include 和 extend 到底怎么分。我甚至见过同一个需求，十个分析师画出十张完全不同的图。后来我认真试了试让大模型做这件事，发现只要把提示词和输出约束设计到位，AI 完全可以把“从文本到结构化草稿”这段最耗精力的重复劳动接过去，而且质量稳定在可用水平。这篇文章想分享的，正是我在实际项目里把 AI 生成用例图跑通的全过程：底层逻辑、可复制的提示词工作流、质量陷阱，以及怎么把它嵌进需求分析的整体链路里。
1. 为什么用例图让需求分析成了“体力活”
1.1 用例图真正的价值：把需求文档变成各方都能读懂的契约
先说个很多人会忽略的事实：用例图在系统分析与设计课程里被当成 UML 入门图形，看起来地位不高，但在真实项目里，它可能是最早“冻结需求边界”的产物。产品经理写出一份 PRD，开发关注的是“哪些接口要提供”，测试关注的是“哪些场景要覆盖”，业务方关注的是“我的目标到底有没有被实现”。用例图恰好是这几方都能指着一处讨论的中间产物：参与者代表谁在用，用例代表要达成什么可感知的结果，关系代表不同目标之间的依赖和复用。
这也是为什么很多系统分析与设计的教材会把用例图放在需求分析的第一章。它不是画得好看的问题，而是能不能让非技术人员不看代码、不看冗长文档，就能指着图说“这个功能我认可，那个功能我们不需要”。如果用例图画错了，后面所有需求跟踪、测试用例设计都会跟着歪。所以它值得认真对待，但问题恰恰在于，认真画一张图的人力成本很高。
1.2 手画用例图的真实成本：从文本到图的映射之痛
画用例图最痛苦的环节不是画，而是“翻译”。给出一份自然语言需求，你需要在脑子里完成三次跳跃：第一，找出系统边界内外的人物或系统，判断哪些有资格成为参与者；第二，把每一句需求描述归纳为用户可感知的业务目标，而不是系统内部的步骤；第三，判断用例之间是相互独立，还是存在扩展、包含关系。这三步没有任何绝对客观的算法，全凭经验。
举个例子，我之前做会议室预约系统时，需求文档里有这么一句：“用户可以查看会议室状态，然后提交预约申请，系统会根据时间冲突情况自动审批。如果冲突，则进入等待队列。”这句话看起来信息量完整，但不同的人能画出完全不同的图。有人把“自动审批”当成一个用例，有人把“查看会议室状态”当成一个独立用例，还有人认为“进入等待队列”应该扩展自“提交预约申请”。谁对？其实没有标准答案，只有项目语境下的“合适答案”。而这种反复斟酌的过程非常消耗时间，一旦需求变更，整张图又要重新走一遍分析。
1.3 AI入场：它替代的不是分析师，而是“从文本到结构化草稿”的重复劳动
我在试用过多个大模型之后，得出一个比较清醒的结论：AI 生成用例图，替代的绝不应该是需求分析师的专业判断，而是“从文本到结构化草稿”这一段重复度极高的转译工作。大模型天生适合做这件事，因为它有很强的自然语言理解能力，又擅长模式化输出。
你把一段需求文本丢给 AI，它可以快速完成参与者识别、用例短语提取、关系初步归类，甚至直接生成 Mermaid 语法。这就像让一个读过大量需求文档的实习生先出一版草图，再由有经验的系统分析师去审核、修正。9 成的重复劳动被消解掉之后，分析师可以把精力集中在那些真正需要人判断的问题上：这个用例的粒度合不合适、这条 include 关系是不是被用反了。
这一认知很重要，它会影响你对整个工具链的期待——不要指望 AI 一次生成完全可用的图，而是要把它当成一个高效的第一轮输出器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 拆解 AI 生成用例图的技术底座
2.1 LLM 如何“读懂”需求文本并抽取出参与者与用例
要理解 AI 怎么生成用例图，先得知道它读到需求文本时实际在做什么。本质上，这是一个“从自然语言中做语义角色分析”的过程。参与者，通常对应文本中的施动者；用例，通常对应文本中能够被参与者观察到的完整目标。大模型在大量语料上训练得到的模式识别能力，让它能比较准确地完成这种抽取。
做一个生活化类比：你把一份需求文档递给 AI，就像把材料递给一个读过大量案例的新同事。他不会凭空创造，而是根据你的描述推断出谁在系统外面交互、交互的意图是什么。AI 并不知道你的业务领域规则，它只是在做“极大可能正确”的模式匹配。这也是后面谈到 AI 幻觉时最需要注意的地方。
实际上，你可以在提示词里给 AI 一些抽取规则来约束它的判断方向。比如：参与者必须是主动发起交互的外部角色，不能是系统内部模块；用例必须是用户可感知的目标，不能是具体的 UI 点击操作。这比笼统说“帮我生成一张用例图”要可靠得多。
2.2 从“自由文本”到“结构化 UML”的三条输出路径
AI 有自由文本，输出也能是自由文本，但如果直接让它“画图”，大部分场景都是输出一段代码或结构化描述，再由渲染工具转换成图形。我在项目里试过三条路径，各有适用场景。
| 输出路径 | 语法复杂度 | 渲染工具 | 适用场景 |
|---|---|---|---|
| Mermaid | 低，学习成本低 | 笔记软件、IDE 插件、在线渲染器 | 快速验证、日常文档、评审讨论 |
| PlantUML | 中，支持 include/extend 语义清晰 | PlantUML 服务、IDE 插件 | 需要精确控制关系、进版本管理的正式文档 |
| 结构化 JSON + 前端渲染 | 高，需二次开发 | 自己写渲染组件 | 集成到产品或需求管理平台中 |
目前我推荐的第一路径是 Mermaid。原因很简单：语法足够简单，AI 出错的概率低，渲染几乎随处可用。很多支持 Mermaid 的笔记工具都能直接渲染，适合需求评审这种快速迭代场景。
PlantUML 的优势在于语义表达更严谨，比如 extend 关系、泛化关系在语法层面有明确的关键字，不容易产生歧义。缺点是相对 Mermaid 更繁琐，AI 生成时偶尔会写出不兼容的语法。
JSON 路径适合做产品化封装。你可以让 AI 输出一个包含 actors、use_cases、relations 三个数组的 JSON，前端用任何图表库渲染。这样能把用例图的生成集成到自己的需求管理工具里，好处是可以做进一步的自动化检查。
2.3 提示词工程的几个关键约束
同样一个模型，提示词写得不专业，出来的图大概率是“看着像用例图，实际上经不起推敲”的废图。我在实践后总结出几条很关键的约束：
第一，明确角色设定。开头就要告诉模型：“你是一位资深系统分析师，精通 UML 用例图建模。”第二，指定输出格式。明确说“只输出 mermaid 代码，不要解释”，否则它会写一大段说明，反而干扰解析。第三，给出参与者、用例的定义，让它按定义抽取。第四，必须包含业务目标和系统边界，防止它把你给的需求文本之外的内容也编进来。第五，加入“不确定时就省略”的指令。这一条对减少 AI 幻觉非常重要。
注意：生成用例图不是让 AI 发挥创造力的场景，恰恰相反，提示词约束越死，输出越可靠。你不需要它“乱想”，需要它“听话”。
3. 一套可以直接照搬的 AI 生成用例图工作流
3.1 第一步：需求文本预处理（清洗与拆分）
不要直接把一份几万字的需求文档整个扔给 AI，它会“迷失焦点”。我在实际使用中强烈建议先做文本预处理：把需求文档拆成若干独立的功能场景块，一个场景对应一张用例图的容量。什么叫场景块？就是一段围绕某个业务目标、边界相对清晰的需求描述。
比如说会议室预约系统，可以把“会议室预约流程”、“会议室审批流程”、“登录与权限管理”、“与公司 OA 系统的集成”拆成四个场景块分别建模。这样做有两个好处：第一，上下文窗口可控，模型在有限文本里更容易抓准用例；第二，生成结果的粒度均衡，不会因为文档太大导致有的用例细到操作、有的用例粗到整个子系统。
清洗的时候还要顺手剔除无效内容：背景介绍、目标愿景、名词定义表这类信息，对生成用例图不仅没用，还容易干扰模型，让它把“公司希望提升效率”这种句子也翻译成用例。这些内容在设计阶段有价值，但建模时应该筛掉。
3.2 第二步：两级提示词策略——先抽角色，再抽用例
试过几次之后，我把“一次生成”改成了“两级生成”，质量提升非常明显。第一级只让 AI 提取参与者，即参与者清单。第二级再带着这个清单去提取用例和用例关系。两级的提示词可以类似这样：
text复制第一级提示词示例：
你是一位资深系统分析师。下面是会议室预约系统的需求文本。
请提取该系统的参与者（Actor）。参与者必须是主动与系统交互的外部角色，可以是人、外部系统或定时任务。
输出格式：仅输出参与者名称列表，每个一行。
[粘贴需求文本]
第二级提示词示例：
你是一位资深系统分析师。根据下面的需求文本，以及已提取的参与者列表，生成 UML 用例图。
需要遵循：
1. 用例必须表达参与者可感知的业务目标，不要写界面操作或内部实现。
2. 如果用例之间存在包含（include）关系，使用 <include-- 语法；扩展（extend）关系使用 <|--。
3. 不确定的需求描述不要臆造，省略对应内容。
输出格式：仅输出 mermaid 代码，语言为 mermaid。
参与者列表：[第一级结果]
需求文本：[粘贴需求文本]
之所以拆成两级，本质上是在模仿人类分析师的思考顺序。先确定“谁在边界外”，再确定“他们进来想达成什么”，比混在一起更容易保持逻辑清晰。而且两级提示词也能帮助模型降低上下文遗忘的概率。你可以在自己项目里实测一下，两级提示词与一次生成的差异会比想象中更大。
3.3 第三步：用 Mermaid 落地并渲染验证
有了两级提示词，再来看一个完整的案例。以下是一段我模拟的会议室预约需求文本：
text复制会议室预约系统支持员工登录后查看各会议室在指定时间段内的占用情况。
员工可以选择空闲时段提交预约申请。系统在收到申请后自动判断是否存在时间冲突，
若无冲突则预约成功；若有冲突，则进入人工审批流程。
审批人员可以查看预约详情，选择通过或驳回。
系统在审批完成后向相关员工发送系统消息通知。
把这段文本喂给两级提示词工作流之后，AI 输出了一段 Mermaid 代码，我整理出可运行的版本如下：
mermaid复制graph TD
Actor1[员工] --> UC1[查看会议室占用情况]
Actor1 --> UC2[提交预约申请]
Actor1 --> UC3[接收预约结果通知]
Actor2[审批人员] --> UC4[查看预约详情]
Actor2 --> UC5[通过或驳回预约]
Actor3[系统消息服务] --> UC3
UC2 <-- Web自动审批UC6
UC6 <-- 进入人工审批流程UC7
UC7 --> UC5
这里要说明的是，上面这段代码是我为了演示整理过的版本，实际 AI 输出往往会有语法小瑕疵，比如关系箭头方向写反或漏了节点。渲染之后，你需要在图形层面做一次快速验证。验证的方法是，把图上每个用例都翻译回一句话“用户输入了什么、系统返回了什么、用户得到了什么结果”，翻译不通的用例就是有问题的。
3.4 第四步：人工复核清单
AI 生成用例图，最“反直觉”的事实是：审核时间反而比手画一张图短。因为你不用从零开始组织信息，只需要带着一张清单去挑毛病。我的复核清单经过多轮迭代后浓缩成以下六项：
- 参与者是否都在系统边界之外？有没有把数据库、内部服务等画成参与者。
- 用例事件是否都表达了业务目标？有没有“点击按钮”“输入表单”这类操作级描述。
- 是否存在意义重叠的用例？比如“提交预约申请”和“保存预约信息”，明显是同一个目标。
- include/extend 关系是否方向正确？主用例是否真的包含公共子流程。
- 有没有 AI 凭空生成的参与者或用例？在需求文本里找不到依据的，一律删掉。
- 用例粒度是否一致？单张图里，不要同时出现“登录”和“进行财务年度审计”这种量级悬殊的目标。
提示：把这份清单直接写进提示词的系统指令里，能显著减少人工复核时的修补量。AI 每次至少能帮你避免三到四类低级错误。
4. 生成结果的质量陷阱：比 AI 幻觉更隐蔽的是用例失真
4.1 AI 在用例图上最常见的六类错误
聊到 AI 生成用例图，很多人第一反应是“AI 幻觉”——编造不存在的需求。但我在实际项目中看到更多也更隐蔽的错误，不是编造需求，而是“用例失真”。我把它归纳成六类，基本覆盖了绝大多数翻车现场。
第一，把系统内部动作当成用例。需求写“系统自动计算会议冲突”，AI 可能直接生成一个参与者叫“系统”，再生成一个用例叫“计算时间冲突”。这很糟糕，因为用例图里不画系统内部实现，正确做法是把“自动冲突检测”作为“提交预约申请”的包含子流程。第二，遗漏参与者之间的交互。第三，include 和 extend 关系方向混淆。第四，粒度忽大忽小。第五，把系统边界推广到外部，要求文本里根本没出现的角色混进来。第六，泛化关系被滥用，明明是两个完全独立的用例，硬加一个父用例。
这些错误的共性是“表面上语法正确、语义离谱”——如果不做业务核对，甚至看不出问题。而大模型的训练目标决定了它更倾向于生成“格式上极像标准答案”的内容，所以在这些点上尤其需要人工干预。
4.2 案例复盘：把一个有问题的生成结果改对
直接看一个反面案例。某次我让 AI 根据一段电商优惠券需求生成用例图，需求原文大致是“用户领券后下单，系统自动核销，若券已过期则提示不可用”。AI 生成的图里出现了三位参与者：用户、系统、运营人员。“运营人员”是需求文本里完全没提到的，属于边界外推。
更麻烦的是，它写了一个名为“校验优惠券有效性”的独立用例，挂在用户下面。乍一看没什么问题，但“校验”是系统内部动作，用户在系统里可感知的目标是“使用优惠券下单”，而不是“校验有效性”。修正方式是：将“校验优惠券有效性”改为“提交优惠券订单”的包含子用例，去掉“运营人员”参与者。整个过程只需要约两分钟，但如果人工从零画图，至少二十分钟起步。
这类复盘让我意识到一个规律：AI 生成的用例图，错误往往集中在边界和关系的抽象判断上，而不是基础的信息抽取上。这恰好佐证了它的定位——草稿生成器，把人类从转译劳动里解放出来，让人专注做抽象验证。
4.3 如何通过“双模型互检”降低失真率
如果你想进一步提高生成质量，试试“双模型互检”。方法很简单：让 A 模型生成用例图，再让 B 模型（或相同模型的低温和高温两次）担任“需求分析评审专家”，输入需求文本和 A 产出的 Mermaid 代码，要求它找出与需求不符合的地方。
这个思路灵感来自 AI 测试里的“对抗式验证”。大模型作为“评审专家”时，总会发现一些生成模型遗漏的问题，比如“该用例未在需求中找到对应依据”“参与者不应包含内部模块”。两份输出放一起，差异往往直指要害。
当然，这会增加调用成本和时间，对于时间紧的项目，我一般只在两种情况下使用：一是项目处于需求冻结前的最终确认阶段，容错率低；二是需求文本特别复杂，冗余信息多，人工核对需要花大量精力时。
5. 进阶玩法：把用例图生成嵌入需求分析与 AI 工作流
5.1 需求变更自动同步：从文档到用例图到测试用例
一旦你接受了“需求文本 + AI 提示词 = 用例图草稿”这个模式，很容易往前再走一步：把这一过程嵌进需求变更流程。过去需求一改，用例图要人肉维护；现在你只要把变更后的需求文本重新喂给工作流，生成新版本用例图，再做一次差异对比即可。
更进一步，可以把这条链路自动化为“需求文档 → 用例图 → 测试用例框架”的工作流。用例图上每一个用例，天然对应对应的功能测试场景；参与者代表了用户角色权限维度。AI 在生成用例图的同时，也可以让它根据用例清单输出测试用例的框架，比如前置条件、主流程、异常路径。这也是搜索词里 AI 测试、AI 应用开发讨论得很多的方向。我目前实际落地的阶段是文档和用例图的半自动同步，测试用例部分还在不断完善中，但整体思路是明确的。
5.2 集成到文档工具和开发环境
在实际工作中，你不需要额外搭建一个复杂平台才能用上这套工作流。很多文档工具都支持 Mermaid 渲染，你可以把提示词模板保存为常用片段，把需求文本粘贴进去，几秒后就有 Mermaid 代码，直接粘贴到文档里展示。
如果你主要在 IDE 里写代码，那更简单。现在的 AI 辅助编程插件普遍支持多行对话，你可以直接把两级提示词发过去。Pycharm 里的 AI 插件、常见 AI Coding 工具都能胜任这个任务。我的经验是，这类代码辅助工具生成 Mermaid 的稳定性甚至常高于通用聊天场景，因为它们往往内置了代码格式的偏好约束。
5.3 用 Spring AI 做一个自己的用例图生成接口
如果你想把它产品化，其实不难。参考 Spring AI 这类集成框架，你可以很轻松地封装一个 REST 接口：接收一段需求文本，返回 Mermaid 代码或 JSON 结构。所有提示词模板放到服务器端，客户端只需要提交文本。
我建议在服务端直接做两级提示词串联。伪代码流程是：先调用大模型提取参与者，再带着参与者列表调用大模型生成 Mermaid 或 JSON。响应统一包装成 { "actors": [], "use_cases": [], "relations": [], "mermaid": "" } 结构，前端拿到之后既可以渲染，也可以做格式校验。整个代码量并不大，但能将能力固化给整个团队使用，而不是每次在聊天对话框里手动操作。
5.4 学习教育与专利材料场景的实际经验
这套工作流还有一个比较实际的用途，是学习和备考场景。系统分析与设计教材里用例图是必考内容，很多学生在作业里画图往往纠结于“标准答案”，但现实中不存在唯一标准答案。我的建议是：把 AI 当成对一个“好学生草稿”的参考，然后自己解释为什么这样画、为什么不那样画。这种“先见后识”的过程，对理解用例抽象和 UML 语义反而更高效。
还有一类场景是专利辅助材料中的功能结构说明。客观地说，AI 生成用例图可以帮助你快速组织一个系统功能框架图，把方法与步骤之间的功能和结构关系可视化出来，方便后续在其他场合使用。但这里必须强调：AI 只适合做辅助整理，所有素材都应来自充足的实际方案与实践素材，人工复核并确认内容的真实性是不可省略的环节，以避免不必要的影响。
6. 落地选型与本地化部署中的一些经验
6.1 在线 API、开源模型、本地部署怎么选
聊到 AI 工具选型，必须面对的问题是：用在线 API 还是本地部署。我的判断标准很简单：如果需求文本允许发到外部服务，且你更看重生成质量，直接选主流大模型在线 API，效果最稳。这在时间有限的项目上几乎是唯一选项。
如果你面对的数据有保密要求，或者希望长期降低成本，再考虑本地部署。本地部署的最大缺点是硬件要求和模型能力的平衡。想清楚这一点的好处是，你不会在花了半天时间部署后，因为生成质量不如预期而失望。
表格对比一下：
| 方案 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| 在线大模型 API | 生成质量高，支持上下文长，无需运维 | 数据出域，调用有成本 | 早期验证、普通业务需求、快速迭代 |
| 本地开源模型 | 数据安全，可离线，按需运行 | 需要 GPU 资源，参数量小的模型结构输出不稳定 | 需求文本涉密或内网环境 |
| 混合模式 | 敏感数据走本地，普通数据走在线 | 架构复杂，需要路由逻辑 | 中大型企业或团队 |
6.2 部署到本地后的量化损失与结构化输出能力
很多人以为，本地部署一个 7B 或 13B 模型，性能下降主要体现在“语言组织”上。但实际踩坑之后我发现，对用例图生成影响最大的是“结构化输出能力”。大模型要输出 Mermaid 语法，对括号、引号、缩进有严格规范，量化后的模型很容易在这里翻车。有时候它逻辑完全正确，但代码渲染失败。
如果你不得不使用本地小参数量模型，我会建议：不要让它直接生成 Mermaid 代码，而是让它先输出 JSON 结构化数据，你再把 JSON 转换成 Mermaid 或前端图形。JSON 是极规范的格式，模型只需处理有限的键名和值，错误率远低于自由生成 Mermaid。我实测过，同一份需求文本，让它直接写 Mermaid 时可能有 30% 的渲染失败率，改成输出 JSON 再转换后失败率能降到 5% 以内。
6.3 最后的个人经验
经过这大半年折腾，我现在的日常工作流已经稳定下来：需求文本先拆场景，然后跑两级提示词，拿到 Mermaid 草稿后渲染，再按复核清单过一遍。整个过程从原来的一小时压缩到十分钟左右，分析质量没有下降，反而因为把重复劳动交给 AI，多了不少时间真正去思考“边界对不对、粒度合适不合适”。
最后想分享一个个人心得：AI 生成用例图的理想定位是“从 60 分帮你打磨到 90 分”，而不是“从 0 分直接生成 100 分”。那些把需求文本往对话框一扔、出来一张图就觉得万事大吉的做法，后面大概率要翻车。但只要你愿意保留那个“人工最终拍板”的环节，这套工作流真的能极大解放需求分析师的时间，让画用例图这件事从“体力活”变回真正的“分析活”。