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，就像把材料递给一个读过大量案例的新同事。