AI 生成用例图怎么写需求：提示词模板 + 常见失败原因

整理一套可直接复用的 AI 用例图提示词模板（含角色/范围/主成功场景/异常分支），并解释 AI 生成用例图常见失败原因与修正方法。

很多人第一次用 AI 生成用例图，会遇到同一个挫败感：

画出来像流程图，连线一堆但看不出“系统要提供什么能力”
参与者（Actor）乱写：把部门、页面、按钮都当成参与者
用例名像任务清单：粒度太细或太泛，无法评审
include/extend 乱用，结果图越“专业”越难懂

问题通常不在工具，而在“你给 AI 的需求描述缺了关键字段”。下面给你一套可直接复用的提示词模板，并解释常见失败原因和修正方法。

先说结论：AI 生成用例图，最关键的 6 个字段

你给 AI 的内容里，至少要明确以下 6 件事：

系统边界（System）：这张图描述的是哪个系统/子系统？
参与者（Actors）：谁在系统外部与它交互？人/角色/外部系统分别是谁？
系统提供的能力（Use Cases）：系统对外提供哪些“可被触发、可被验证”的能力？
主成功场景（Main success）：每个用例从触发到结束的大致步骤（3–8 步即可）
异常/可选分支（Alternatives）：哪些场景要用 extend/include 表达？
粒度与范围（Scope & Granularity）：这张图是“业务级”还是“功能级”？要画到什么细？

把这 6 个字段说清楚，AI 生成的用例图基本不会太离谱。

可复制的提示词模板（推荐直接填空）

把下面整段复制给 AI，把方括号内容替换成你的项目文字即可。

模板 A：从 0 到 1 生成一张可评审的用例图

你是资深需求分析师。请基于以下信息，输出一份 UML 用例图的结构化描述，并给出 draw.io/PlantUML 友好的文本（任选其一即可）。

系统边界：[{系统名称/子系统名称}]

参与者（外部）：

人员角色：[{角色1}、{角色2}……]

外部系统：[{外部系统1}、{外部系统2}……]

业务目标：[{一句话说明系统要解决什么问题}]

范围内能力（用例候选）：

[{能力/用例1：动词+名词，如“提交报销申请”】【能力/用例2】……]

范围外（不要画进来）：[{明确写出不在本图范围的能力，如“财务打款在另一个系统完成”}]

关键规则/约束：[{权限、审批规则、金额限制、时效等}]

输出要求：

用例命名使用“动词+名词”，避免 UI 词（按钮/页面/表单）。

指出哪些用例需要 include/extend，并说明理由。

对每个用例给出 3–8 步主成功场景，以及 1–3 个常见异常分支（文字即可）。

最后给出：Actors 列表、Use Cases 列表、关系列表（关联/include/extend/泛化）。

这套模板的好处是：你不用一上来就讨论“include 还是 extend”，先把范围、角色和能力列表定住。

模板 B：已有需求文档，让 AI 帮你“抽象出用例图”

下面是一段需求说明，请你把它抽象成 UML 用例图。你要先识别系统边界、参与者、用例，再给出 include/extend 的拆分建议。需求如下：

[{粘贴需求说明：可以是 PRD 摘要、用户故事、验收标准、接口描述}]

输出要求同上，并补充：

列出你认为“像流程步骤但不应该画成用例”的条目，并说明原因。

填写示例（拿“在线预约挂号”举例）

你可以按下面这种“短而完整”的方式写：

系统边界：线上预约挂号系统（不含线下缴费、药房发药）
参与者：患者、医生、导诊台（外部系统：短信服务、支付平台）
用例候选：注册/登录、查询科室与号源、预约挂号、取消预约、支付挂号费、查看就诊记录
规则：同一患者同一科室每天最多预约 1 次；未支付 10 分钟自动取消；取消超过 3 次进入黑名单 7 天

把这些写进模板 A，AI 就能生成一份“可讨论、可修改”的用例图草案。

常见失败原因 1：把“页面/按钮/接口”当成用例

症状：用例名称像“点击提交按钮”“打开订单页面”“调用创建订单接口”。

为什么错：用例图关注的是系统对外提供的能力，而不是 UI 交互细节或实现细节。

修正方法：

把 UI 词替换成业务动作：
- “打开订单页面” → “查看订单详情”
- “点击提交按钮” → “提交订单”
把接口动作替换成业务意图：
- “调用创建订单接口” → “创建订单”

如果你不确定某条是否是用例，问自己一句：**这件事能不能写进验收标准？**能写、能验证，多半就是用例。

常见失败原因 2：系统边界不清，所有东西都被画进来

症状：图里出现财务系统、客服系统、仓储系统、BI 系统……看起来像“全公司系统地图”。

为什么会这样：你没明确“范围外”。AI 为了完整性会把相关系统都拉进来。

修正方法：在提示词里加一段“范围外（不要画进来）”，并用一句话说明交界点：

“支付由支付平台完成，本系统只负责发起支付与接收结果回调”
“发货由仓储系统完成，本系统只负责生成出库单并查询状态”

边界清晰后，参与者就会更干净：外部系统只作为 Actor 出现，不会被画成用例的一部分。

常见失败原因 3：粒度太细（把流程步骤拆成一堆用例）

症状：一个“下单”被拆成“选择商品、填写地址、选择优惠券、确认订单、提交订单、支付”六七个用例。

怎么判断粒度是否合适：

如果拆出来的每一步都必须发生，它们更像“主成功场景的步骤”，不一定要各自成为用例。
如果某一步是可选或复用的（例如“选择优惠券”可用于不同业务），它更适合成为被 include 的子用例。

推荐做法：

把主用例定为“提交订单”
把可复用、可选的部分抽成子用例：
- include：计算价格、校验库存
- extend：使用优惠券、使用积分、开具发票

常见失败原因 4：include / extend 用反了

不纠结概念也可以用一个朴素的判断：

include（包含）：主用例每次都要做、而且可以被多个用例复用的“必做子任务”。
extend（扩展）：在特定条件下才发生的“可选分支/附加行为”。

当你发现 AI 画出来“主用例依赖可选分支”，多半是 extend/include 反了。

常见失败原因 5：参与者没分清“人 vs 角色 vs 外部系统”

症状：把“张三”“财务部”“H5 页面”“数据库”当参与者。

修正方法：

人：具体人名不画，抽象成角色（患者/管理员/审计员）
部门：通常也抽象成角色（财务专员），除非它是外部组织
页面/数据库：不是参与者；数据库是系统内部组件
外部系统：短信服务、支付平台、统一登录（SSO）这类才是参与者

如果你希望 AI 不犯这个错，可以在提示词里加一句：

参与者只允许“角色”或“外部系统”，不要出现页面/按钮/数据库。

生成后怎么快速验收：一个 30 秒清单

你拿到 AI 生成的草案后，用下面清单快速扫一遍：

用例名称是否都是“动词+名词”（提交/查询/审批/导出）
是否明确了系统边界，图里没有“全家桶系统”
参与者是否都是角色或外部系统，没有 UI/数据库
include 都是必经且可复用的步骤；extend 都是可选分支
主成功场景是否能对应验收标准

发现问题就回到模板，把缺失字段补上，再让 AI 重新生成一次。通常第二版就会稳定很多。