企业 AI 项目 Wiki · 需求与业务场景

业务场景

也常写作Business scenario · 业务使用场景 · 业务情景 · 业务操作场景

定义

业务场景是在明确业务上下文中，一个或多个角色为达到可识别结果而执行任务的有边界叙述。它从触发事件和前置条件开始，说明人员、系统与第三方怎样使用信息、作出判断、交接和处理例外，直到进入一个可确认的结束状态，并记录适用范围、频率、规模、风险和限制。

业务场景描述的是一次有上下文的业务任务，不是一个功能名

“合同审核”“知识问答”“库存管理”只标出了业务领域，没有说明谁在什么情况下要完成什么，也没有说明完成后业务进入什么状态。系统可以拥有同名功能，却因角色、数据、时间、规则或后续责任不同，支持完全不同的场景。

场景把静态需求放回真实工作。它既描述用户与系统的交互，也要看交互之前的业务状态、同时参与的其他岗位、外部系统和交互之后仍需完成的工作。这样团队才能判断需要哪些页面、数据、接口、权限、规则、人工判断和记录。

业务场景可以描述当前做法，也可以描述目标做法。两者应明确标注：当前场景用于发现问题、限制和已有责任，目标场景用于定义项目要形成的行为。把理想流程当成现状，会低估迁移、培训和组织变化；把现状直接照搬，又可能把不合理步骤固化进系统。

一个可用于项目的业务场景由什么组成

业务场景的价值，是让没在现场的人也能看懂一件工作为什么开始、怎样推进、何时结束。只列角色和步骤还不够，触发条件、所用资料、异常分支与最终记录要连在一起，才能据此判断系统该做什么、人仍要负责什么。

场景名称与业务目标

用角色可识别的任务和结果命名，例如“采购负责人确认超预算申请”，而不是“审批模块”。说明它支持的业务结果和不包含的相邻任务。

参与角色与责任

列出发起人、主要处理人、批准人、被通知人、运营支持和受结果影响的人；角色表示责任，不等于系统账号名称或具体个人。

触发事件

说明什么事件、时间、状态或外部消息启动场景。只有满足触发条件才产生一次场景实例，避免用“用户进入页面”代替真实业务原因。

前置状态与适用条件

写清开始前已经存在的订单、合同、身份、权限、数据、时间窗口、上游决定和规则版本，以及场景适用于哪些组织、产品或金额区间。

输入与信息来源

列出人员输入、业务记录、文件、接口数据、规则和外部证明，标明来源、必填性、有效期、权限和资料不足时的处理。

正常处理路径

按业务先后说明人员、系统和第三方的关键动作、判断、状态变化与交接。保留影响需求的业务语义，不把场景写成每一次点击。

替代、异常与停止路径

覆盖资料缺失、规则不适用、权限不足、重复提交、接口失败、超时、冲突、用户撤回和需要人工判断等重要偏离，说明恢复、补充、拒绝或终止结果。

结束状态与输出

定义成功、未通过、取消、转人工、等待补充等可能结束状态，以及产生的决定、数据变化、通知、文件或后续任务。结束不是“页面显示成功”，而是业务责任已到达明确位置。

业务记录与可追溯性

说明需要保留的输入版本、决定依据、操作人、时间、状态变化、外部响应和例外理由，以及谁可以查看、保存多久。

运行特征与限制

记录大致频率、峰值、并发、时限、批量、季节性、重要性、允许停机、敏感程度和地域语言等条件；这些会直接改变架构、费用和验收。

业务场景应该写到多大、多细

场景太大，会变成“完成客户服务”这类无法报价的口号；场景太细，又会退化成一次点击或一个接口调用，看不见业务结果。合适的粒度通常能让一个角色在明确条件下完成一项可确认的任务，同时保留关键异常和人工分支。

是否围绕一个可识别结果？
一个场景可以包含多个角色和系统，但应在一次业务任务进入明确结束状态时收束。
检查：名称、触发、目标和结束状态可以连成一句话。
是否保留了关键上下文？
角色、适用条件或规则变化会改变结果时，应拆成子场景或明确分支，不能只写“其他情况类似”。
检查：适用范围、规则版本和分支条件。
是否避免页面级碎片？
登录、打开列表、点击按钮通常是步骤，不是独立业务场景；除非它本身完成身份确认、授权或其他业务结果。
检查：每个场景是否有独立业务价值和结束状态。
是否避免把多个目标塞在一起？
申请、审批、履约、结算可能属于同一业务旅程，但责任、时间和规则不同，常需分成相互关联的场景。
检查：一个场景是否出现多个无共同结束条件的目标。
是否区分摘要与详细层级？
高层场景用于范围和沟通，详细场景用于需求、设计和测试；两者通过稳定编号关联，不要求一份文本同时承担所有细节。
检查：父场景、子场景和相关需求可双向追踪。
是否按风险决定细节？
高频、高金额、不可逆、敏感数据或受监管场景需要更完整的例外、授权和证据；低风险场景可采用较轻记录。
检查：场景风险等级和需要展开的条件。

怎样从真实工作中发现和确认业务场景

业务场景最好从真实工作里找，而不是坐在会议室里根据系统菜单想象。观察一线人员怎样接收信息、绕过障碍、补录数据和请人确认，往往比问“你想要哪些功能”更容易发现真正需要承接的流程。

先找真实任务和结果
访谈并观察实际使用者、处理人员和支持岗位，查看他们要完成什么、现在怎样完成、哪里停住，而不是从待开发功能表反推假想场景。
收集现有证据
核对表单、制度、工单、日志、报表、邮件模板、接口、培训资料和异常记录，区分正式规则、实际做法与个人经验。
确定触发、边界和结束
为每个候选场景标出开始事件、前置状态、主要结果和不在其中的上下游任务，使相邻场景能够衔接而不重叠。
走一遍正常线程
让负责岗位使用一份有代表性的输入从头说明人员、系统、判断、交接、数据变化和记录，标出每一步依据。
主动追问非正常情况
从资料不足、错误、重复、冲突、超时、撤回、无权限、外部失败和人工例外逐项询问，不能等到上线后才发现隐藏规则。
补充运行量和风险
确认频率、峰值、时限、批量、敏感数据、金额、影响对象和错误后果，避免用单个顺利样本代表真实运行。
由多角色共同回放
让业务负责人、实际用户、技术、数据、安全、运营和测试按风险参与，用同一场景复述责任和结果；分歧要记录并作决定。
编号、批准并持续维护
为场景分配稳定标识，记录当前版、适用范围、来源和确认人；业务规则或系统边界变化时评估受影响的需求、设计、测试和验收。

一个业务场景记录可以长什么样

下面用独立构造、与任何客户无关的内容展示一条场景记录怎样连贯地读下来。实际项目可以使用表格、叙述或流程模型，形式不是重点；重点是读者能从中还原任务、边界、异常和责任。

SC-012：采购负责人处理超预算申请

目标是让具有授权的采购负责人依据当前预算与采购规则，决定申请通过、退回补充或拒绝；不包含供应商签约和付款。

角色与触发

申请人提交完整采购申请，系统确认金额超过其部门可直接批准额度后触发；采购负责人主责，预算负责人可能会签，申请人接收结果。

前置状态与输入

申请人、部门、成本中心和审批权限有效；采购规则版本可识别；申请包含用途、金额、供应商、报价附件和期望日期。

正常路径

系统读取剩余预算和适用规则，显示申请与依据；采购负责人核对并决定，若超过其权限则转预算负责人；最终状态、理由和通知写回申请。

重要偏离

预算数据不可用时停止自动判断并转人工；报价缺失时退回补充；重复申请标记后不得再次占用预算；审批人是申请人时改由替代授权人处理。

结束与记录

以批准、退回、拒绝或转人工结束，记录输入版本、规则与预算快照、查看和决定人员、时间、理由、状态变化及通知结果。

运行条件

项目还要确认日常数量、月末峰值、决定时限、金额等级、数据敏感度、接口可用性和历史记录保留要求，才能据此估算和验收。

业务场景怎样连接范围、需求、设计和验收

同一条业务场景会被不同角色用在不同地方：范围用它决定本期是否覆盖，需求把它拆成系统行为，设计安排实现路径，验收再回到最初任务检查结果。只要中间任何一层失去这条连接，项目就容易出现“功能做了，但工作没有真正跑通”。

范围

用场景标识说明本期包含哪些真实任务、角色、地区和数据边界；排除项也可引用明确场景，避免范围只剩功能名称。

需求

从角色动作、信息、判断、状态和例外派生功能、数据、权限、接口和非功能需求，并保留场景到需求的双向追踪。

产品与交互设计

根据任务顺序、上下文切换、批量操作、可见信息、决定风险和辅助需求设计界面，而不是让组织结构或数据库表直接决定页面。

架构与集成

场景的调用量、时限、一致性、依赖、外部失败和恢复条件，为接口方式、异步处理、容量、缓存、审计与弹性提供输入。

权限与安全

以场景中的角色、业务对象、动作和条件形成授权规则，验证不应看见、不能执行和需要再次确认的路径，而不是只分管理员与普通用户。

测试与验收

把正常、替代、异常和非正常条件转成测试场景，绑定输入、预期结果、版本、环境和证据；业务场景本身不是测试用例，但提供测试覆盖来源。

上线与运营

用代表性场景做演练、监控和故障定位，按关键节点设计指标与告警，并让支持人员知道在哪一步接手和怎样恢复。

企业 AI 业务场景还要固定哪些上下文

AI 能处理什么，往往取决于当时掌握的资料、用户身份和允许执行的动作。同一句问题由不同岗位提出，或处在不同业务阶段，正确处理方式都可能不同。因此 AI 场景不能只保存一段对话，还要把决定回答和行动边界的上下文写进去。

先说明 AI 在这项工作里扮演什么角色

有时 AI 只是帮人找到资料或起草内容，有时它会分类、推荐，甚至调用工具改变系统状态。这些角色带来的责任完全不同。场景要明确 AI 做到哪一步、哪些业务决定不能由它承担，以及最终结果仍由谁确认和负责。

知识与证据来源

列出允许使用的资料、数据、规则、权限和有效期，说明回答需要引用什么、来源冲突或没有资料时怎样处理。

输入与上下文边界

定义用户输入、会话历史、检索片段、身份、业务对象和系统状态哪些可以交给模型，怎样避免把模型生成内容当作可信权限或事实。

可接受输出与不确定性

说明事实、完整性、格式、语气、引用和允许变化，区分可供人修改的草稿与会直接影响业务的结构化结果。

拒答、停止和人工接手

资料不足、越权、敏感、高风险、规则冲突或模型不确定时，规定拒绝、追问、转人工、阻断动作和保留上下文的方式。

工具调用与真实副作用

若 AI 能发信、写回、下单、建工单或审批，场景要写清参数来源、最低权限、确认、限额、幂等、失败补偿、审计和不可逆动作的授权。

评测与运行条件

分别准备正常、边界、异常、资料不足、恶意输入和高影响操作样本，记录模型、提示词、知识索引和工具版本，并按真实频率、延迟、成本和波动验证。

受影响的人与潜在误用

除直接用户外，识别被输出或动作影响的人、可能超出预期用途的使用方式、负面后果和反馈申诉路径，使场景不只描述理想调用。

业务场景容易与什么混淆

用户故事、用例、流程图和功能清单都能描述工作的一部分，但关注点不同。业务场景先保留一项任务所在的完整业务语境，再让后续方法选择适合的表达；它不是为了取代所有需求文档。

相关概念	与业务场景的区别
使用场景或营销场景	营销材料常用一句话说明产品适合哪里；项目业务场景需要可追踪的角色、条件、路径、结果、责任和运行边界。
UML 用例	用例从系统边界外的参与者出发，定义系统提供的一段可观察行为；业务场景可以跨越多人、多个系统、线下动作和系统尚未确定的目标工作。
用户故事	用户故事用角色、需要和目标组织一个可管理的开发单元，并可附验收标准；业务场景通常提供更完整的触发、上下文、交接、例外和结束状态，一个场景可派生多条故事。
业务流程	业务流程强调活动、事件、网关、参与者和消息的整体组织，可覆盖许多实例与场景；业务场景沿一条有界线程解释特定条件下怎样达到某个结果。
用户旅程	用户旅程从用户视角跨时间和渠道描述为更大目标经历的步骤、感受与需要；一个旅程可能包含多个组织和多个业务场景。
业务闭环	业务闭环强调输入、处理、决定、结果、记录与后续责任是否完整接上；业务场景是描述和检查其中一条具体业务线程的单位。
测试场景	测试场景为验证目的选择条件和行为，通常从业务场景、需求、风险和故障模式派生；它要进一步指定测试对象、版本、环境、输入和预期。
客户案例	客户案例陈述真实项目及结果，需要事实和公开授权；业务场景是需求模型，可以来自调研或目标设计，并不证明系统已交付或取得成效。

依据与适用边界

本文解释企业项目中用于说明真实业务任务及其上下文的业务场景。它不是行业名称、部门名称、“提高效率”这类目标、功能清单、页面原型或一句使用举例，也不等同于 UML 用例、敏捷用户故事、完整业务流程、端到端业务闭环、测试场景或客户案例。不同团队可以使用叙述、表格、泳道图、旅程图或用例模型记录场景；形式不是关键，关键是能够识别参与者、触发条件、前置状态、输入、正常与例外处理、人工和系统责任、结果与留下的记录。