场景定义

「场景」一词在艺术理论中的源头可追溯至古希腊戏剧的舞台术语「σκηνή」（skene），该词经晚期拉丁语「scaene」演变为英语「scene」，最初指舞台后方供演员化妆、换装并存放道具的棚屋或帐篷。^{66ULIANA POLTINKINA（溥毓麟）：论电影化场景的词源与定义 - Формасловformasloff.ru前往参考资料 ↓在新标签页中打开}

随着古希腊戏剧的发展，公元前三世纪出现了高度约三米、较窄的新型舞台结构，以便观众看清演员；罗马工程师维特鲁威（Vitruvius）将这种结构译作「scaene」，该词由此进一步与舞台建筑和演出空间绑定。^{66ULIANA POLTINKINA（溥毓麟）：论电影化场景的词源与定义 - Формасловformasloff.ru前往参考资料 ↓在新标签页中打开}

在现代用法中，「scene」至少承载多重含义：作品中的事件、戏剧中的场与场面、情景与地点、表演场地、戏剧艺术家的生活、小说与剧作中的片段、事件或案例，以及说清关系的谈话等。^{66ULIANA POLTINKINA（溥毓麟）：论电影化场景的词源与定义 - Формасловformasloff.ru前往参考资料 ↓在新标签页中打开}

中文语境中的「场景」是一个较新的术语，主要经由电影艺术引入，但其词义范围很广，既指路上的情景、案例，也指艺术作品的场面与布景，并延伸出场景音乐、绘画场景、小说场景以及营销中的用户场景、产品场景等用法。^{66ULIANA POLTINKINA（溥毓麟）：论电影化场景的词源与定义 - Формасловformasloff.ru前往参考资料 ↓在新标签页中打开}

在电影学中，场景被视为电影结构的一部分，与「场」「场面」等概念共同承担叙事单元的功能；尽管多种艺术门类都使用「场景」一词，但专门以场景为对象的系统文献相对匮乏。^{66ULIANA POLTINKINA（溥毓麟）：论电影化场景的词源与定义 - Формасловformasloff.ru前往参考资料 ↓在新标签页中打开}

「场景」一词最初来自影视学，指某个事件发生时所处的环境状况；这一用法强调事件与其发生环境之间的整体关联，而非孤立的背景布景。^{77装饰收录-学术期刊-斟知数据平台data.zhenzhi.com前往参考资料 ↓在新标签页中打开}

20 世纪 80 年代，场景概念被引入社会学领域，从描述影像中的环境状况扩展为分析社会行动发生的情境条件。这一跨学科迁移为后来设计学借用场景概念提供了语汇基础。^{77装饰收录-学术期刊-斟知数据平台data.zhenzhi.com前往参考资料 ↓在新标签页中打开}

在设计学领域，场景与场景创新已成为高频词汇，其兴起被视为设计发展阶段的必然结果：设计的重要动力之一是服务于商业竞争，而竞争形态的演变推动设计关注点从外观识别性，转向形式与制造工艺的整体把握，再转向对产品性能、形式、宣传、服务乃至全生命周期的系统化思考。^{77装饰收录-学术期刊-斟知数据平台data.zhenzhi.com前往参考资料 ↓在新标签页中打开}

按上述设计史脉络，在产能饱和阶段，单靠形式已不足以打动消费者，需要一个「思虑周全的故事」来承载产品与服务的整体价值；场景正是这类叙事得以组织的载体，这也是场景概念被设计学大量借用的直接动因之一。^{77装饰收录-学术期刊-斟知数据平台data.zhenzhi.com前往参考资料 ↓在新标签页中打开}

场景概念从影视学经社会学进入设计学，是一条跨学科的概念迁移路径，而非设计学内部自生的术语；理解这一点有助于区分「场景」与「情境」「用户旅程」等相邻概念在来源上的差异。^{77装饰收录-学术期刊-斟知数据平台data.zhenzhi.com前往参考资料 ↓在新标签页中打开}

在场景定义中，用户不是抽象的“平均人”，而是被具体情境约束的行动者：其目标、能力、先验知识与当下环境共同决定了他在某一时刻需要什么、能做什么。因此场景定义中的“用户”要素至少要交代三件事——谁（角色与特征）、想达成什么（目标与动机）、在什么条件下行动（环境与限制）。^{88Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|99Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开}

ISO 9241-210 把“用户”定义为“与系统、产品或服务交互的人”，并把人本设计的原则落在对用户需求、任务与使用情境的明确理解上；该标准同时把“使用情境（context of use）”单列为用户、任务、设备与物理社会环境四类要素，这为场景定义中把“用户”与“情境”分开描述提供了标准化依据。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

在场景（scenario）方法中，用户通常以“角色（persona）”或“行动者（actor）”的形式被显式建模：角色刻画目标、行为模式与技能水平，行动者则强调在特定场景中执行动作、做出决策的主体。二者共同的作用是把“用户”从人口统计标签转化为可推演行为的主体。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|1212The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanitypearson.com前往参考资料 ↓在新标签页中打开}

用户要素的核心是“目标”而非“任务”：任务是达成目标的手段，目标相对稳定而任务随情境变化。场景定义若只罗列任务步骤而不交代用户想达成的目标，就无法判断场景是否被满足，也无法在情境变化时重新组织任务。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

用户的能力与限制是场景定义中的约束条件，包括感知与认知负荷、领域知识、操作技能、身体条件以及可达性需求。忽略这些约束，场景就会退化为“理想用户”的演示脚本，无法暴露真实使用中的失败点。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开|1313The Design of Everyday Things: Revised and Expanded Editionbasicbooks.com前往参考资料 ↓在新标签页中打开}

用户要素还必须交代“用户所处的社会与组织角色”：同一人在不同场景中可能同时是操作者、被服务者、监督者或旁观者，其权限、责任与信息需求随之不同。场景定义中若不区分这些角色，容易把不同利益相关者的需求混为一谈。^{99Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开|1414Scenario-based designinteraction-design.org前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶的场景定义中，“用户”已从驾驶员扩展为驾驶员、乘客、远程操作员与行人等多类道路使用者；联合国 WP.29 关于自动驾驶框架的文件明确要求考虑“用户”与“其他道路使用者”的交互，这使场景中的用户要素必须覆盖车内与车外两类主体。^{1515Framework document on automated/autonomous vehicles (ECE/TRANS/WP.29/2019/34/Rev.2)unece.org前往参考资料 ↓在新标签页中打开}

用户要素的常见误区是把“用户画像”等同于“场景中的用户”：画像描述的是跨情境的稳定特征，而场景中的用户是特定情境下的具体行动者。只给画像不给情境，场景定义就缺少可推演的行为约束。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|1212The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanitypearson.com前往参考资料 ↓在新标签页中打开}

在场景定义文档中，用户要素通常以结构化字段记录：角色名称、目标、关键特征与能力、环境与限制、成功判据。这种字段化写法便于在后续场景分类与测试用例生成中复用。^{99Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开|1414Scenario-based designinteraction-design.org前往参考资料 ↓在新标签页中打开}

在场景（scenario）的定义中，环境指场景发生时人物所处的外部条件总和，包括物理空间、时间、气候、光照、噪声、设备与网络状态等可被观测和描述的客观要素；它是场景区别于单纯用户任务或用户画像的关键维度之一。^{1616Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

ISO 9241-11 将「使用情境」（context of use）界定为用户、任务、设备以及使用产品的物理与社会环境；其中环境被明确列为影响可用性的独立构成部分，而非任务的附属属性。^{1717ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开}

在基于场景的设计（scenario-based design）传统中，Carroll 把场景描述为「关于人与环境交互的、具体而聚焦的故事」，环境在此被理解为人物行动所依托的设定，而非可随意省略的背景板。^{1818Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

Rosson 与 Carroll 在《Usability Engineering: Scenario-Based Development of Human-Computer Interaction》中提出，场景应包含人物、目标、环境设定与行动序列等要素；环境设定为行动提供约束与机会，是判断场景是否完整的基本检查项。^{1919Usability Engineering: Scenario-Based Development of Human-Computer Interactionsciencedirect.com前往参考资料 ↓在新标签页中打开}

在自动驾驶领域，ISO 34501 将「场景」（scenario）定义为描述驾驶环境与车辆动态的时序发展，并把环境要素（道路、天气、光照、交通参与者等）作为场景描述的核心组成；这说明在工程语境中环境不是场景的修饰语，而是场景本体的组成部分。^{2020ISO 34501:2022 Road vehicles — Test scenarios for automated driving systems — Vocabularyiso.org前往参考资料 ↓在新标签页中打开}

PEGASUS 项目提出的六层场景模型把场景环境拆分为道路层、交通设施层、临时操控层、对象层、环境层与数字信息层，其中环境层专门承载天气、光照与路面状况等条件；该分层已成为把环境要素结构化、可枚举化的代表性方法。^{2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在服务设计与用户体验实践中，环境常被进一步区分为物理环境、社会环境与信息/技术环境三类；这一区分有助于在场景描述中避免只记录空间而遗漏社会规范、他人存在与系统状态等同样影响行为的条件。^{2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

环境要素在场景定义中承担约束功能：同一人物与目标在不同环境条件下会触发不同的行动路径，因此环境描述必须具体到可判别程度（如「雨天夜间、城市快速路、有前车」），否则场景无法用于设计推演或测试用例生成。^{2020ISO 34501:2022 Road vehicles — Test scenarios for automated driving systems — Vocabularyiso.org前往参考资料 ↓在新标签页中打开|2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在智能座舱与车载交互研究中，环境被作为影响驾驶员分心与交互模态选择的自变量，光照、噪声、振动与交通密度等条件会改变视觉、语音与触觉通道的可用性；因此座舱场景定义通常要求对环境条件做显式标注。^{2323A Literature Review on the Influence of Environmental Factors on Driver Distraction and In-Vehicle Interactionmdpi.com前往参考资料 ↓在新标签页中打开}

环境要素的边界在场景定义实践中存在宽窄两种处理：一种把环境限定为物理与时间条件，另一种把社会文化规范、组织情境与数字信息环境也纳入其中；两种做法在各自领域内均有使用，差异主要来自应用目的而非事实分歧。^{1717ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开|2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在场景定义中，“任务”指用户（或系统）在特定场景下试图达成的具体目标或需要完成的活动单元；它是连接抽象场景与具体交互行为的中间层，通常以动词短语描述，如“查找附近加油站”“在会议中静音通知”。^{2424Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|2525Scenario-Based Designinteraction-design.org前往参考资料 ↓在新标签页中打开}

任务与场景的关系可概括为：场景提供“谁、何时、何地、为何”的上下文，任务则回答“做什么”；一个场景通常包含一个或多个任务，而同一任务可能出现在不同场景中，因此任务分析必须结合场景上下文才有意义。^{2424Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|2626Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

在基于场景的设计（Scenario-Based Design）中，任务被视作场景脚本的核心成分：场景以叙事方式描述“行动者—目标—任务—环境”的序列，任务分解（task decomposition）则把高层目标拆解为可观察、可评估的子任务。^{2525Scenario-Based Designinteraction-design.org前往参考资料 ↓在新标签页中打开|2727Human-Computer Interaction（第3版）pearson.com前往参考资料 ↓在新标签页中打开}

任务定义需要明确四个要素：任务目标（完成标准）、触发条件（何时开始）、执行主体（人还是系统）、以及成功/失败判据；缺少任一要素，任务描述就难以用于后续的交互设计或系统验证。^{2626Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开|1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，任务常被进一步区分为驾驶主任务与非驾驶次任务（NDRT），场景定义要求明确主次任务的分工与切换条件，以评估分心风险与接管需求。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开|2929NHTSA Driver Distraction Guidelinesnhtsa.gov前往参考资料 ↓在新标签页中打开}

任务与“用户目标”不同：目标是期望达成的状态（如“保持联系”），任务是达成该目标的具体活动（如“发送一条语音消息”）；场景定义中若混淆二者，容易导致任务粒度过粗或过细。^{2424Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

任务分析（task analysis）为场景定义提供结构化输入，常见方法包括层次任务分析（HTA）、GOMS 模型和认知工作分析（CWA），它们帮助识别任务步骤、决策点与信息需求，从而支撑场景的完整描述。^{2727Human-Computer Interaction（第3版）pearson.com前往参考资料 ↓在新标签页中打开|3030Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Worktaylorfrancis.com前往参考资料 ↓在新标签页中打开}

在服务设计与商业创新中，任务被置于“用户待办任务”（jobs-to-be-done）框架下理解：用户“雇佣”产品或服务来完成某项任务，场景定义因此需要同时刻画功能任务、情感任务与社会任务。^{3131Know Your Customers' "Jobs to Be Done"hbr.org前往参考资料 ↓在新标签页中打开}

任务描述应避免将解决方案混入任务本身：例如“用手机 App 扫码支付”把手段写进了任务，而更中性的表述是“完成一笔支付”；保持任务与解决方案的分离，才能在场景定义阶段保留设计空间。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|3131Know Your Customers' "Jobs to Be Done"hbr.org前往参考资料 ↓在新标签页中打开}

在场景模板中，任务通常与“目标”“痛点”“期望”并列填写，并标注优先级与频率，以便在后续设计中区分核心任务与边缘任务。^{2626Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

在场景定义的诸要素中，目标是场景的指向性要素：它回答“这个场景要达成什么”，把主体、时间、空间、事件等描述性要素组织成一个有意图的整体，而不是若干要素的简单并列。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

场景与需求相伴而生，需求通过场景来实现和激发；因此场景定义中的目标，本质上是对需求的一种收敛表达——把弥散的需求转写为可在特定主体、时间、空间与事件中检验的具体目标。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

一种常见的场景要素划分把场景拆为主体（法人或自然人）、时间、空间、事件四个要素；在这一划分下，目标并不作为独立要素列出，而是隐含在“事件”所承载的意图之中，这提示目标在场景定义中既可以显式声明，也可以从事件描述中反推。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

场景目标具有双向性：一方面，既有需求通过场景被满足，目标表现为对现有痛点的消解；另一方面，场景本身会激发新的需求，目标因而还包含对需求增量的引导与承接。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

在数字化改革的语境下，场景目标被表述为针对经济社会发展中的新痛点新需求，运用数字化思维、认知、技术、方法找到解决痛点、满足需求、提升体验的路径，并对之进行场景化技术重构与制度重塑。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

场景目标可以具有层次性：单一场景的目标往往指向局部问题的解决，而多跨场景的目标则指向跨部门、跨层级、广覆盖、高频次、体验良好的整体效果，后者被视为数字化改革区别于一般数字化转型的本质特征。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

场景目标不是一次性给定的，而是在场景迭代中不断被重新界定：老场景在竞争迭代中优胜劣汰，保留下来的是最能满足需求的最佳场景，这意味着目标是否达成要由场景的实际运行效果来检验，而非在定义阶段一次性判定。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

目标在场景定义中承担筛选功能：当同一组主体、时间、空间与事件可以指向多个不同目标时，明确目标才能决定哪些要素被纳入场景边界、哪些被排除，从而避免场景描述沦为无边界的背景铺陈。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

用户画像（persona）是交互设计中用以代表一类目标用户的虚构人物档案，通常包含人口统计特征、目标、行为模式与痛点；它回答的是「为谁设计」，而不是「在什么条件下使用」。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

场景（scenario）描述的是特定用户在特定时间、地点、动机与环境下完成目标的一段具体过程，强调情境要素的组合与变化；它回答的是「在什么情况下如何发生」。^{3333Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

在方法来源上，用户画像主要承袭自库珀（Alan Cooper）的目标导向设计传统，把用户抽象为具名角色以约束设计决策；场景方法则更多来自卡罗尔（John M. Carroll）等人的场景式设计（scenario-based design）与使用案例（use case）传统，把设计焦点放在行动序列与情境脉络上。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|3333Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

两者的抽象层级不同：用户画像是对一类用户相对静态、跨情境的概括，一个画像可对应多个场景；场景是对一次具体使用情境的动态描述，同一画像在不同场景中会呈现不同的需求与行为。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|3333Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

在证据基础上，用户画像常依赖访谈、问卷、日志分析等对人群属性的归纳，容易因样本与合成方式而失真；场景则更依赖对真实使用过程的观察、任务分析与情境要素的枚举，其有效性取决于情境要素是否被完整覆盖。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|3333Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，场景定义通常以「场景库」形式组织，按道路、天气、交通参与者、驾驶员状态等维度切分；用户画像在此类工程实践中较少作为独立交付物，更多被压缩为驾驶员/乘客的群体标签，作为场景参数的一部分。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

二者在实践中常被组合使用：先用用户画像锁定目标人群，再为该人群枚举关键场景，最后以场景驱动需求与功能定义；把画像直接当作场景使用，会遗漏时间、地点、环境与触发条件等情境变量，导致需求描述无法落地为可验证的设计条件。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|3333Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

在服务设计与商业创新中，用户画像常与用户旅程图配合，画像提供「谁」，旅程图与场景提供「何时何地发生什么」，三者构成从人群到情境的连续描述链条。^{2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

用户旅程地图（User Journey Map）是一种以时间顺序呈现用户为达成某一目标而经历的各阶段、触点、行为、想法与情绪起伏的体验可视化方法，其分析单位是「一段旅程」，通常围绕一个用户角色（persona）和一个具体目标展开。^{3434Journey Mapping 101nngroup.com前往参考资料 ↓在新标签页中打开|3535When and How to Create Customer Journey Mapsnngroup.com前往参考资料 ↓在新标签页中打开}

场景（scenario）在交互设计与需求工程中的通行理解，是对「谁、在什么情境下、为了什么目的、如何与系统交互」的一次具体化描述，强调情境条件（环境、设备、社会因素、用户状态）对行为与需求的约束；它可以是单一时点的情境切片，也可以是一段有前因后果的事件序列。^{3636Scenario-Based Design: Envisioning Work and Technology in System Developmentdl.acm.org前往参考资料 ↓在新标签页中打开|3737Scenarios, Stories, Use Cases: Through the Systems Development Life-Cyclewiley.com前往参考资料 ↓在新标签页中打开}

两者的核心区别在于抽象层次与分析单位：场景通常聚焦于一个或少数几个具体情境下的行为与需求，粒度细、可枚举、可直接驱动设计决策；用户旅程地图则跨越多个阶段与触点，粒度粗、覆盖端到端流程，用于揭示跨阶段的体验断点与情绪变化。^{3434Journey Mapping 101nngroup.com前往参考资料 ↓在新标签页中打开|3838Customer Journey Mapping vs. Scenario Mapping: What's the Difference?interaction-design.org前往参考资料 ↓在新标签页中打开}

在方法定位上，场景常被用作需求分析与设计推演的工具（如场景化设计、用例场景、情境剧本），其产出偏向「设计约束与方案假设」；用户旅程地图则更多被用作体验诊断与共识对齐的工具，其产出偏向「问题清单与机会点」，二者在项目中的使用时机与目的不同。^{3535When and How to Create Customer Journey Mapsnngroup.com前往参考资料 ↓在新标签页中打开|3939Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagramsoreilly.com前往参考资料 ↓在新标签页中打开}

二者并非互斥而是互补：实践中常见做法是先以旅程地图识别关键阶段与痛点，再针对痛点所在阶段展开细粒度的场景描述与设计推演，形成「旅程定位问题、场景深化方案」的衔接关系。^{3838Customer Journey Mapping vs. Scenario Mapping: What's the Difference?interaction-design.org前往参考资料 ↓在新标签页中打开|3939Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagramsoreilly.com前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，场景（scenario）一词更多指向可被形式化描述、可被复现与测试的行驶情境（如场景库、场景要素、ODD 边界内的运行条件），这与用户体验研究中偏叙事化的场景概念存在语义差异，混用容易造成沟通歧义。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

在软件与系统工程的语境中，用例（use case）被定义为系统与其外部参与者（actor）之间一系列交互的集合，用以达成某个对参与者有价值的目标；它描述的是“系统应当为谁做什么”，而不是“系统内部如何实现”。^{4040UML 2.5 Specification (formal/2015-03-01), Clause 18: Use Casesomg.org前往参考资料 ↓在新标签页中打开}

场景（scenario）在交互设计与需求工程中通常被理解为对“某一类使用情境”的具体化叙述，包含人物、目标、环境条件与事件序列；它既可以用于描述现状（as-is），也可以用于描述设想中的未来（to-be），并常以故事、视频或原型的形式呈现。^{4141Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

用例与场景的核心区别在于抽象层次与目的：用例是面向系统边界的、相对稳定的功能契约，强调“系统提供什么服务”；场景是面向情境的、可变的叙述，强调“在什么条件下、由谁、以何种方式使用”。因此用例通常作为需求规格的一部分被正式管理，而场景更多作为设计探索与沟通的媒介。^{4040UML 2.5 Specification (formal/2015-03-01), Clause 18: Use Casesomg.org前往参考资料 ↓在新标签页中打开|4141Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

在统一建模语言（UML）中，用例图通过参与者、用例及其关联来表达系统功能范围，而场景则常以用例规约中的主成功场景与扩展场景（或活动图、序列图）来细化；换言之，场景可以视为用例内部的具体路径描述，但并非所有场景都必须隶属于某个用例。^{4040UML 2.5 Specification (formal/2015-03-01), Clause 18: Use Casesomg.org前往参考资料 ↓在新标签页中打开|4242Writing Effective Use Casespearson.com前往参考资料 ↓在新标签页中打开}

在以人为本的设计（HCD）传统中，场景被用作设计过程中的核心工件：ISO 9241-210 将“使用情境”（context of use）列为理解与指定用户需求的关键输入，包括用户、任务、设备与环境；场景则是对这些要素在具体时间线上的编排，用于评估设计方案的适用性。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

用例与场景在敏捷实践中常被混用，但二者在粒度与生命周期上仍有差别：用户故事（user story）作为用例的轻量替代，强调对话与增量交付；场景则常以“给定—当—则”（Given-When-Then）的验收标准形式出现，用于把用户故事锚定到可验证的行为上。^{4343User Stories Applied: For Agile Software Developmentpearson.com前往参考资料 ↓在新标签页中打开|4444Specification by Examplemanning.com前往参考资料 ↓在新标签页中打开}

在自动驾驶与智能座舱领域，“场景”被进一步操作化为可枚举、可参数化的测试与设计对象（如场景库、逻辑场景与具体场景），这与传统软件工程中作为叙述性描述的用例形成对照：前者追求覆盖度与可复现性，后者追求需求沟通与范围界定。^{2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

场景调研与观察是场景定义流程的起点性环节，其目标不是验证已有假设，而是尽可能完整地收集目标用户在真实环境中的行为、动机、环境条件与干扰因素，为后续的场景提炼与描述提供经验素材。^{4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开|4646Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

在交互设计与人机交互领域，场景调研通常采用实地研究（field study）方法，包括上下文访谈、直接观察、影子跟踪（shadowing）和日记研究（diary study），以捕捉用户在实际使用情境中的行为而非实验室中的自述。^{4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开|4747Plans and Situated Actions: The Problem of Human-Machine Communicationcambridge.org前往参考资料 ↓在新标签页中打开}

上下文访谈（contextual inquiry）由 Beyer 与 Holtzblatt 提出，强调在用户实际工作或生活现场进行访谈与观察的结合，遵循「上下文、协作、解释、聚焦」四条原则，是场景调研中被广泛引用的结构化方法。^{4646Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

文化探针（cultural probes）由 Gaver、Dunne 与 Pacenti 于 1999 年提出，通过让参与者自行记录照片、日记与任务卡来收集其生活情境中的感性材料，适用于难以直接观察或研究者难以长期驻场的场景调研。^{4848Cultural Probesdl.acm.org前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，场景调研与观察除传统人种志方法外，还大量依赖自然驾驶研究（naturalistic driving study）与实车路测数据采集，通过车载传感器、视频与驾驶员行为记录来还原真实驾驶情境。^{4949Naturalistic Driving Studies: A Review of the Literaturejournals.sagepub.com前往参考资料 ↓在新标签页中打开}

场景调研强调「在情境中」收集数据，而非依赖问卷或焦点小组中的回溯性自述；这一取向与 Suchman 对「情境行动」（situated action）的论述一脉相承，即人的行动意义依赖于具体情境，脱离情境的抽象描述会丢失关键信息。^{4747Plans and Situated Actions: The Problem of Human-Machine Communicationcambridge.org前往参考资料 ↓在新标签页中打开|5050Human-Machine Reconfigurations: Plans and Situated Actions (2nd Edition)cambridge.org前往参考资料 ↓在新标签页中打开}

观察法在场景调研中需区分「参与式观察」与「非参与式观察」：前者研究者融入被观察活动以获取内部视角，后者保持距离以减少干扰，两者在数据丰富度与生态效度上各有取舍。^{4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开|5151Ethnography and Virtual Worlds: A Handbook of Methodpress.princeton.edu前往参考资料 ↓在新标签页中打开}

场景调研的数据分析常采用亲和图（affinity diagram）与情境模型（contextual models）对观察记录进行归纳，将零散的行为片段聚类为可复用的场景要素。^{4646Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

在服务设计与商业创新中，场景调研常与「服务蓝图」的前期研究结合，通过顾客旅程观察（customer journey observation）与神秘顾客（mystery shopping）方法记录服务接触点上的真实体验。^{5252Service Design: From Insight to Implementationrosenfeldmedia.com前往参考资料 ↓在新标签页中打开}

场景调研与观察存在样本量与代表性之间的张力：深度实地研究通常样本较小，其结论的可推广性依赖理论饱和而非统计推断，这与大规模问卷或日志分析形成方法上的互补。^{4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开|5151Ethnography and Virtual Worlds: A Handbook of Methodpress.princeton.edu前往参考资料 ↓在新标签页中打开}

场景描述与故事化是场景定义流程中的关键步骤，其核心是将抽象的场景要素转化为具体、可感知的叙事，以便团队理解用户所处的情境与需求。^{5353Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

在交互设计领域，场景描述常采用「场景剧本」（scenario）的形式，通过描述用户、目标、环境与行动序列来呈现设计问题。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

故事化方法强调以叙事结构（如人物、情节、冲突、解决）组织场景信息，有助于揭示用户情感与隐性需求。^{5454Storytelling in Design: Principles and Tools for UX Designersoreilly.com前往参考资料 ↓在新标签页中打开}

在服务设计与商业创新中，故事化常用于客户旅程地图的构建，通过叙述用户经历来识别服务触点与痛点。^{2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

故事化场景描述在智能座舱与自动驾驶领域用于模拟驾驶情境，帮助评估系统在复杂环境中的表现。^{5555Scenario-based safety assessment for automated drivinglink.springer.com前往参考资料 ↓在新标签页中打开}

场景验证的核心不是确认“场景描述写得对不对”，而是检验基于场景定义做出的设计决策在真实使用情境中是否成立；因此验证必须回到用户、任务、环境三要素的实际组合中去观察，而不能停留在文档评审层面。^{5656Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

在基于场景的设计（Scenario-Based Design, SBD）中，卡罗尔（John M. Carroll）主张场景是“设计的中介物”，场景的演进应当贯穿需求分析、设计、原型与评估全过程，验证与迭代不是设计末尾的一次性检查，而是场景本身被不断重写的过程。^{5757Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

以人为中心的设计标准 ISO 9241-210 把“基于用户需求与要求的迭代设计”列为四项核心活动之一，并明确要求设计过程包含“评估设计”环节，评估结果用于反向修正对使用情境（context of use）的理解——这为场景验证与迭代提供了标准化依据。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

ISO 9241-210 将“使用情境”（context of use）界定为用户、任务、设备以及物理与社会环境的组合，场景验证因此需要覆盖这四类要素，而不仅是用户与任务两项。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

可用性测试是场景验证最常用的手段之一：让真实用户在贴近场景设定的任务上操作原型，通过任务完成率、错误类型与出声思维记录，判断场景假设是否被证伪，并据此修订场景描述与设计。^{5858Usability Testing Essentials: Ready, Set...Test!sciencedirect.com前往参考资料 ↓在新标签页中打开}

尼尔森（Jakob Nielsen）提出的启发式评估由少量评估者依据可用性原则独立检查界面，可在无真实用户的早期阶段快速暴露场景覆盖不足的问题，常与用户测试配合作为场景验证的低成本前置手段。^{99Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开}

在自动驾驶领域，场景验证已从实车道路测试扩展为“基于场景的测试”（scenario-based testing）：把场景定义为可参数化、可复现的测试用例，通过仿真、封闭场地与道路测试的组合来覆盖长尾危险情形，验证结果反过来驱动场景库的扩充与迭代。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

PEGASUS 项目提出了自动驾驶功能测试的六层模型，把场景从“功能场景—逻辑场景—具体场景”逐层细化，使场景可被量化描述并用于仿真与实车验证，这一分层已成为场景验证与场景库迭代的常用框架。^{5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

ISO 34501 等标准对自动驾驶场景的术语与描述方式作出规范，使不同团队产出的场景可以互相比对与复用，从而支撑场景库在验证—迭代循环中的积累。^{6060ISO 34501:2022 Road vehicles — Test scenarios for automated driving systems — Vocabularyiso.org前往参考资料 ↓在新标签页中打开}

敏捷与精益实践把场景验证嵌入短周期迭代：以场景为单位编写验收条件，在每个迭代结束时用可运行的增量对照场景进行检验，未通过则进入下一轮迭代，形成“场景—构建—验证—修订”的闭环。^{6161Agile Software Development with Scrumpearson.com前往参考资料 ↓在新标签页中打开}

行为规格说明（behaviour-driven development）用“给定—当—那么”（Given-When-Then）结构把场景写成可执行验收标准，使场景定义与自动化测试直接对应，验证结果可重复且可回归。^{4444Specification by Examplemanning.com前往参考资料 ↓在新标签页中打开}

场景验证需要区分“场景是否真实发生”与“设计在该场景下是否有效”两个问题：前者靠数据与观察确认场景的现实性，后者靠原型测试确认设计的有效性，二者混同会导致用测试结果去否定本应保留的边缘场景。^{5656Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|5858Usability Testing Essentials: Ready, Set...Test!sciencedirect.com前往参考资料 ↓在新标签页中打开}

场景迭代应保留版本与变更理由：记录每个场景的触发条件、参与角色、环境约束及修订依据，可使后续团队判断某条场景是来自真实观察、专家推演还是仿真生成，避免场景库在反复迭代中失去可追溯性。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开|5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

场景验证的常见失败模式是“只验证主路径”：团队倾向于用顺利走通的典型场景证明设计可用，而忽略异常、中断与多任务并发的场景，导致上线后在边缘情形下集中暴露问题。^{5858Usability Testing Essentials: Ready, Set...Test!sciencedirect.com前往参考资料 ↓在新标签页中打开|99Usability Engineeringsciencedirect.com前往参考资料 ↓在新标签页中打开}

对场景定义质量的评估本身也需要方法：可请未参与定义的评审者仅凭场景描述复现任务与环境设定，若无法复现或理解出现分歧，说明场景描述存在歧义，应先修订场景再进入设计验证。^{5757Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

在场景研究的经典分类中，按使用情境划分场景，通常区分“日常使用情境”与“极端/边缘使用情境”两类：前者指产品在典型、高频、可预期的环境与任务中被使用的情形，后者指偏离常态但真实可能发生的压力条件（如恶劣环境、误操作、设备故障、特殊人群使用）。这一二分法被广泛用于需求工程与以人为中心的设计实践，用以避免只针对“理想用户、理想环境”做设计。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开|4646Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开}

ISO 9241-210 将以人为中心的设计描述为贯穿系统生命周期的活动，明确要求识别“预期的使用情境”（context of use），包括用户、任务、设备以及物理与社会环境；该标准把使用情境的识别作为需求规格的前置步骤，这为“按使用情境分类场景”提供了标准化依据。^{1717ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开}

在交互设计与可用性工程中，场景常按情境的“正常—异常”维度进一步细分为正常情境、异常情境与临界情境：正常情境覆盖主流任务流，异常情境覆盖错误、中断与恢复，临界情境覆盖资源紧张、网络不稳、权限受限等边界状态。这种三分法在可用性测试与场景化设计中用于组织测试用例与设计对策。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开|6262Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

按使用情境分类时，物理环境（光照、噪声、温度、振动、空间约束）与社会环境（他人在场、协作、隐私要求）常被作为两个独立的分类维度，而非合并为笼统的“环境”一项；这一拆分在移动与车载等“环境强影响”产品的场景分析中尤为常见。^{1717ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开|1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

在汽车人机交互与自动驾驶领域，使用情境的分类被制度化：驾驶场景按道路类型、交通状况、天气与光照、驾驶员状态等情境要素分层描述，并区分正常驾驶、系统降级与接管、故障与事故等情境类别，用于界定系统能力边界与安全论证。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开|6363PEGASUS Project: Project for the Establishment of Generally Accepted quality criteria, tools and methods as well as Scenarios and Situations for the Release of highly-automated driving functionspegasusprojekt.de前往参考资料 ↓在新标签页中打开}

服务设计与商业创新中的情境分类更强调“触点情境”与“旅程阶段”：同一服务在认知、购买、使用、售后等不同阶段构成不同使用情境，各情境下的用户目标、信息需求与情绪状态不同，因而需要分别定义场景。^{2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

按使用情境分类的一个常见争议是分类粒度：粒度过粗会掩盖关键差异，粒度过细则场景数量爆炸、难以维护。实践中通常以“情境要素是否显著改变用户目标或系统行为”作为切分判据，而非追求穷举。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开|6262Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

按用户类型对场景分类，是指以场景中承担主要活动、需求或目标的主体身份作为划分依据，把场景区分为面向个人消费者、面向组织或机构、面向特定职业角色等类别；其分类逻辑不是场景发生的物理空间或技术媒介，而是「谁在使用、为谁设计」。^{4646Contextual Design: Defining Customer-Centered Systemssciencedirect.com前往参考资料 ↓在新标签页中打开|1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

在交互设计与可用性工程传统中，按用户类型划分场景与「用户画像（persona）」方法直接相关：Alan Cooper 提出以目标导向的用户角色来组织设计场景，把场景视为特定用户角色在特定动机下完成目标的过程，因此用户类型成为场景分类的第一层切分维度。^{6464The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanitypearson.com前往参考资料 ↓在新标签页中打开}

ISO 9241-210 将「用户（user）」定义为与系统交互的个人，并把「用户群体」与「使用情境（context of use）」并列为以人为中心设计的关键分析对象，这为按用户类型切分场景提供了标准化依据：不同用户群体对应不同的使用情境与需求约束。^{1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，按用户类型分类的典型做法是区分驾驶员（driver）与乘客（passenger），并进一步区分不同座位位置的乘员；由于驾驶任务的安全责任与注意力要求不同，驾驶员场景与乘客场景在人机交互设计上被区别对待。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

按用户类型分类的一个常见做法是先按「直接使用者／间接受影响者／决策与购买者」三层区分，再在每层内部按人口统计、能力、经验水平细分；这种分层能避免把「付费的人」与「使用的人」混为同一场景主体。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开}

按用户类型分类也存在边界模糊的问题：同一人在不同时刻可能同时是操作者与旁观者，或从新手变为专家，因此用户类型划分通常需要与「用户状态／熟练度」维度交叉使用，而非作为唯一分类轴。^{6464The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanitypearson.com前往参考资料 ↓在新标签页中打开|1010ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systemsiso.org前往参考资料 ↓在新标签页中打开}

按任务复杂度分类，场景通常被划分为简单场景、复合场景与复杂场景三个层级：简单场景只包含单一任务与单一目标，复合场景由若干可分解的子任务串接而成，复杂场景则同时涉及多个目标、多个参与主体与动态变化的环境条件。^{5353Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

在可用性工程中，任务复杂度常以任务步骤数、涉及的操作对象数量与决策分支数量来衡量，CIF（Common Industry Format）可用性测试报告标准把任务描述与任务成功、任务时间等度量绑定，使任务复杂度成为可比较的场景属性。^{6565ISO/IEC 25062:2006 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reportsiso.org前往参考资料 ↓在新标签页中打开}

在自动驾驶领域，场景复杂度常按静态要素与动态要素的组合来分级：仅含道路几何与交通标志等静态要素的为简单场景，加入其他交通参与者与天气光照变化后构成复杂场景，这一划分直接服务于场景库的覆盖度评估。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

PEGASUS 项目提出的六层场景模型把场景拆为道路层、交通设施层、临时操作层、对象层、环境层与数字信息层，层数越多、层间交互越强，场景的任务复杂度越高，这一模型为按复杂度组织场景库提供了可操作的分解框架。^{2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

按任务复杂度分类的价值在于匹配设计与测试投入：简单场景适合做基线验证与回归测试，复杂场景适合做边界探索与失效发现，二者在场景库中的配比决定了测试或设计评审的覆盖效率。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开|2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

任务复杂度与场景复杂度并不等同：同一任务在不同环境下复杂度可能差异很大，因此按任务复杂度分类时通常需要同时标注环境约束，否则分类结果不可复现。^{5353Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开|2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在服务设计领域，场景常按接触点数量与参与角色数量区分复杂度，单一接触点、单角色的场景被视为简单场景，跨渠道、多角色协同的场景被视为复杂场景，这一划分用于判断服务蓝图的绘制粒度。^{2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

按任务复杂度分类存在主观性风险：复杂度阈值缺乏统一标准，不同团队对同一场景可能给出不同分级，因此实践中常辅以步骤数、参与角色数等可计数指标来降低分歧。^{6565ISO/IEC 25062:2006 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reportsiso.org前往参考资料 ↓在新标签页中打开|2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

在交互设计中，场景常被用于产品迭代的需求阶段与设计阶段，作为产品从产生到设计的依据；两个阶段的侧重点不同：需求阶段关注「用户是谁、需求是什么、要做什么事」，设计阶段关注「基于某目标，用户使用产品的情况」。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

需求分析阶段使用的场景可称为「用户需求场景」，它是对用户需求的扩展与细化，补充描述需求涉及的多个关键要素；若只给出简单描述的需求，对产品设计的指导容易出现偏差。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

用户需求场景的典型写法是把时间、地点、人物、需求、产品与行为后果串成一个具体情境，例如「周四下午，小波回家出地铁口（场景），想吃菠萝（需求），看到有个卖菠萝的摊位，上去看了看，都是没有削皮的菠萝（产品），地铁口人流量大，小波不想等没买菠萝就走了」；这种写法把抽象需求落到可判断的具体条件上。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

「场景」一词在交互设计语境中并无统一定义，不同出处给出的解释涵盖的对象与要素各不相同：有书籍把场景描述为「用户如何使用产品实现具体目标的故事」，有课程把场景拆为「场」（时间、空间）与「景」（情景、交互），也有行业大会案例把场景解释为「人+场+事+物」，而百科类定义仍停留在戏剧、电影等艺术作品中的场面并泛指情景。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

在需求评审、设计沟通与开发方案交流中，「场景」是高频词，常以「用户在什么场景需要这个功能」「这么设计依据的场景是什么」「有没有考虑过这个使用场景」等形式出现；但由于定义模糊，沟通中各方对同一场景的理解容易不一致。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

结合场景，设计师可以更精确地了解用户需求，进而推动产品的升级迭代与体验优化，实现精细化设计；这是把场景引入需求分析阶段的主要动机。^{22场景理解模糊？看完这篇就够了！_手机网易网m.163.com前往参考资料 ↓在新标签页中打开}

在应用程序原型设计的语境中，场景被定义为应用运行期间可能发生的一系列交互或事件的详细描述，它刻画用户如何潜在使用应用的不同功能与组件，从而探索功能并识别设计与用户体验中的潜在问题。^{6767场景（术语表）appmaster.io前往参考资料 ↓在新标签页中打开}

场景在原型设计阶段的作用是帮助设计师、开发人员与利益相关者共同设想用户交互与应用行为的各个方面，使最终产品满足预期目的并提供连贯体验；因此场景被视为创建有效原型的关键输入。^{6767场景（术语表）appmaster.io前往参考资料 ↓在新标签页中打开}

构建原型阶段使用的场景通常包含三类要素：用户画像（可能与产品交互的不同类型用户）、目标与任务（每类用户希望借功能完成的事情）、上下文与触发器（交互发生的物理或数字环境，以及可能影响用户行为的外部因素或事件）。^{6767场景（术语表）appmaster.io前往参考资料 ↓在新标签页中打开}

场景的书写粒度应同时覆盖典型用例与边缘情况：以在线购物应用为例，一条场景可依次描述搜索商品、浏览列表、加入购物车、进入结账、完成交易，并额外考虑配送与支付偏好、缺货商品或促销优惠等分支条件。^{6767场景（术语表）appmaster.io前往参考资料 ↓在新标签页中打开}

场景定义完成后可被转化为可执行、可测试的原型，再经测试、改进与迭代以对齐预期用户体验与业务目标；在无代码平台上，这一转化可由可视化数据建模、业务流程与 API 设计功能配合自动生成源代码来完成。^{6767场景（术语表）appmaster.io前往参考资料 ↓在新标签页中打开}

基于场景的设计被交互设计从业者视为打造良好用户体验的方法之一，并与用户体验历程映射等实践并列使用；Google 高级互动设计师 Brendan Kearns 在 Google for Developers 的播客中介绍了创意原型设计方法以及基于场景的设计如何帮助打造出色的用户体验。^{6666Brendan Kearns 介绍富有创意的原型设计和场景设计 | Chrome, Web Dev Libraries, and Guides - Google for Developersdevelopers.google.com前往参考资料 ↓在新标签页中打开}

在原型设计阶段，场景还承担沟通职能：把设计意图以具体使用情境的形式表达出来，使表明意向与通知开发者这两件事得以区分，减少跨职能协作中的理解偏差。^{6666Brendan Kearns 介绍富有创意的原型设计和场景设计 | Chrome, Web Dev Libraries, and Guides - Google for Developersdevelopers.google.com前往参考资料 ↓在新标签页中打开}

在可用性测试阶段，场景定义的核心作用是把抽象的测试任务转化为带有具体用户身份、目标、环境条件与约束的叙事化任务，使被试在测试中面对的任务更接近真实使用情境，从而提高测试结果的外部效度。^{6868Usability Testing 101nngroup.com前往参考资料 ↓在新标签页中打开|6969Interaction Design: Beyond Human-Computer Interaction (5th ed.)wiley.com前往参考资料 ↓在新标签页中打开}

ISO 9241-11 将可用性定义为「特定用户在特定使用情境下，为达成特定目标而使用系统时所表现出的有效性、效率与满意度」，其中「使用情境（context of use）」明确包含用户、任务、设备以及物理与社会环境，这为可用性测试中以场景承载使用情境提供了标准化依据。^{1717ISO 9241-11:2018 Ergonomics of human-system interaction — Part 11: Usability: Definitions and conceptsiso.org前往参考资料 ↓在新标签页中打开}

尼尔森（Jakob Nielsen）在可用性工程方法中主张测试任务应源于对真实用户工作场景的观察，而非由设计者凭空构造；他同时指出，可用性测试中只需少量被试（通常约 5 名）即可发现大部分可用性问题，而任务场景的代表性直接决定这些发现能否迁移到真实使用中。^{7070Usability Engineeringnngroup.com前往参考资料 ↓在新标签页中打开}

在可用性测试的实务操作中，场景通常以「人物角色 + 目标 + 情境 + 任务步骤」的结构书写，并在测试脚本中作为任务指导语呈现，同时配合测试前的情境铺垫与测试后的回溯提问，以避免被试仅按字面执行操作而脱离真实动机。^{6868Usability Testing 101nngroup.com前往参考资料 ↓在新标签页中打开|4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开}

以场景驱动的可用性测试存在一个被广泛讨论的方法论张力：场景越贴近真实，测试情境的控制度与可重复性越低；场景越标准化，则越可能遗漏真实使用中的环境干扰与多任务切换。实务上通常通过在受控环境中引入情境化道具与角色扮演来折中。^{6969Interaction Design: Beyond Human-Computer Interaction (5th ed.)wiley.com前往参考资料 ↓在新标签页中打开|4545Observing the User Experience: A Practitioner's Guide to User Research (2nd Edition)sciencedirect.com前往参考资料 ↓在新标签页中打开}

可用性测试中的场景定义还需覆盖异常与边缘场景（如网络中断、权限不足、输入错误），仅测试理想路径会系统性低估真实使用中的问题发生率。^{7070Usability Engineeringnngroup.com前往参考资料 ↓在新标签页中打开|7171Remote Usability Testing: A Practical Guidenngroup.com前往参考资料 ↓在新标签页中打开}

在远程与无主持可用性测试中，场景定义承担了原本由主持人现场引导的职能，因此需要更完整地写明背景、目标与成功判据，否则被试容易误解任务边界，导致任务完成率数据失真。^{7171Remote Usability Testing: A Practical Guidenngroup.com前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶领域，驾驶场景与非驾驶场景的区分首先以车辆是否处于动态行驶任务中为基本判据：驾驶场景指车辆处于行驶、泊车或自动驾驶系统承担动态驾驶任务的状态，非驾驶场景则指车辆静止、驻车或由人完全接管且不涉及动态驾驶任务的状态。^{2828Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles (J3016)sae.org前往参考资料 ↓在新标签页中打开}

ISO 34503:2023 为自动驾驶系统的运行设计域（ODD）定义了标准化属性分类，其中「场景」被区分为涉及动态驾驶任务的道路场景与不涉及动态驾驶任务的非行驶相关场景，这一标准为驾驶/非驾驶场景的划分提供了可操作的属性框架。^{7272ISO 34503:2023 Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domainiso.org前往参考资料 ↓在新标签页中打开}

在智能座舱交互设计中，驾驶场景与非驾驶场景的区分直接决定交互通道的分配：驾驶场景下优先采用语音、方向盘按键、HUD 等低视觉负荷通道，非驾驶场景下则可启用触屏、视频、游戏等高注意力占用的交互形式。^{7373Human Factors in Automotive User Interfaces: A Review of Driver Distraction and Interaction Modalitymdpi.com前往参考资料 ↓在新标签页中打开}

美国国家公路交通安全管理局（NHTSA）发布的驾驶员分心指南将「视觉-手动」交互与「视觉-触屏」交互列为驾驶场景中应限制使用的交互类型，并建议在车辆行驶时锁定或简化复杂触屏操作，这构成了驾驶场景下座舱交互设计的监管依据。^{7474Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devicesnhtsa.gov前往参考资料 ↓在新标签页中打开}

中国国家标准 GB/T 40429-2021《汽车驾驶自动化分级》将驾驶自动化分为 0 至 5 级，并明确在 3 级及以上系统中由系统承担动态驾驶任务、驾驶员转为后备接管角色，这一分级直接改变了驾驶场景中「谁在驾驶」的场景定义要素。^{7575GB/T 40429-2021 汽车驾驶自动化分级openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

在自动驾驶场景库构建实践中，驾驶场景通常按「功能场景—逻辑场景—具体场景」三层抽象进行描述，其中功能场景以自然语言描述、逻辑场景以参数范围描述、具体场景以具体参数值描述，非驾驶场景（如驻车、充电、上下客）则常被单独归入「非行驶任务场景」类别。^{2121PEGASUS Method: Scenario Description and Six-Layer Modelpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

PEGASUS 项目提出的 6 层场景模型（道路层、交通设施层、临时操作层、对象层、环境层、数字信息层）主要面向驾驶场景的描述与测试，并未覆盖驻车、充电、车内乘员交互等非驾驶场景，说明现有场景描述框架在驾驶/非驾驶场景覆盖上存在不对称。^{7676The PEGASUS 6-Layer Model for Scenario Descriptionpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

欧盟《通用安全法规》（EU 2019/2144）要求自 2024 年起新车型配备智能速度辅助、驾驶员疲劳与注意力预警等系统，这些系统在驾驶场景中持续监测驾驶员状态，而在非驾驶场景（如驻车）下则降低监测频率或关闭，体现了法规层面对两类场景的差异化处理。^{7878Regulation (EU) 2019/2144 on type-approval requirements for motor vehicles with respect to their general safetyeur-lex.europa.eu前往参考资料 ↓在新标签页中打开}

在座舱场景引擎的产品实现中，驾驶/非驾驶场景的判定通常综合车速信号、挡位信号、驻车制动状态与驾驶员监控系统（DMS）输出等多源信号，而非单一依赖车速，以降低误判导致的交互策略切换风险。^{7979Context-Aware Interaction in Intelligent Cockpits: Scene Engine Design and Implementationieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在智能座舱与自动驾驶的语境中，典型行驶场景分类通常以道路结构、交通参与者、环境条件与驾驶任务四个维度为骨架，把连续的行车过程切分为可枚举、可复现的场景单元，作为功能定义、测试用例生成与安全论证的共同参照。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

按道路类型划分是最基础的切分方式，一般区分高速公路、城市快速路、城市普通道路、乡村道路、停车场与封闭园区等类别；不同道路类型对应不同的限速、交通流特征与接管频率预期，因而在场景库中往往作为一级标签使用。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

按交通参与者划分的场景关注自车与周围车辆、行人、骑行者、大型车辆以及施工人员之间的交互关系，典型子场景包括前车急减速、相邻车道切入、路口对向直行、行人横穿与骑行者占道等。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

按环境条件划分的场景覆盖光照、天气与路面状态，例如白天与夜间、晴天与雨雪雾、干燥与湿滑积水路面；这类条件会显著改变传感器感知性能与车辆动力学边界，因此在场景描述中通常与道路和参与者维度交叉组合。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

按驾驶任务划分的场景则从车辆行为出发，区分跟车、换道、超车、汇入与驶出匝道、路口通行、掉头、泊车入位与靠边停车等任务类型，便于把场景与具体功能模块和评价指标对应起来。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

专利文献中出现了以场景描述数据解析出场景参数、进而构建虚拟行驶场景的做法，说明场景分类结果在工程上常被进一步参数化，用于仿真环境的批量生成与回归测试，而不仅停留在文字分类层面。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

在智能座舱侧，行驶场景分类还承担着把外部路况映射为座舱内提示、告警与交互策略的作用，例如在高速巡航、拥堵跟车与泊车入位之间切换信息呈现的密度与模态，因此同一套场景分类往往同时服务于自动驾驶功能与座舱体验两条链路。^{8080CN116737525A 自动驾驶的数据处理方法、装置、设备及存储介质patents.google.com前往参考资料 ↓在新标签页中打开}

ISO 26262《道路车辆 功能安全》把「场景」作为危害分析与风险评估（HARA）的输入基础：标准要求先定义车辆的使用场景与运行条件，再据此识别危害事件并评定 ASIL 等级。^{8181ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 26262 第 3 部分给出了「运行模式」「使用场景」等术语，并要求在相关项定义（item definition）阶段描述系统的功能、边界、环境条件与已知使用场景，这使场景定义成为功能安全流程的起点性文档工作。^{8181ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

在 HARA 中，危害事件由「车辆状态或运行场景」与「故障行为」的组合构成，因此场景定义直接决定 S（严重度）、E（暴露度）、C（可控性）三个参数的取值，进而决定 ASIL 等级。^{8181ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

ISO 21448《道路车辆 预期功能安全》（SOTIF）把场景定义扩展到「无系统故障但性能受限」的情形，要求识别已知危险场景与未知危险场景，并通过场景库、仿真与实车测试降低未知风险。^{8282ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开}

SOTIF 把场景划分为已知安全、已知不安全、未知不安全等区域，场景定义与场景库建设因此成为证明「剩余风险可接受」的核心手段，而不仅是功能安全流程的辅助输入。^{8282ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开}

UN R157《自动车道保持系统（ALKS）》以场景条件界定系统可激活的运行范围（如高速公路、车速上限、驾驶员可用性），是法规层面把场景定义直接写入型式批准要求的典型例子。^{8383UN Regulation No. 157 — Automated Lane Keeping Systems (ALKS)unece.org前往参考资料 ↓在新标签页中打开}

UN R157 要求制造商识别并记录 ALKS 的「运行设计域」（ODD），并在用户手册中说明系统边界与退出条件，这使 ODD 的场景描述成为可审查的合规文件。^{8383UN Regulation No. 157 — Automated Lane Keeping Systems (ALKS)unece.org前往参考资料 ↓在新标签页中打开}

ISO 34503 定义了自动驾驶系统运行设计域（ODD）的规范格式，把场景要素拆分为道路、环境、交通、车辆状态等类别，为场景定义提供可交换的结构化词汇。^{7272ISO 34503:2023 Road Vehicles — Test scenarios for automated driving systems — Specification for operational design domainiso.org前往参考资料 ↓在新标签页中打开}

ASAM OpenSCENARIO 与 OpenDRIVE 等标准把场景描述为可执行的仿真文件，使功能安全与 SOTIF 中定义的抽象场景能够转化为可重复运行的测试用例。^{8484ASAM OpenSCENARIOasam.net前往参考资料 ↓在新标签页中打开}

PEGASUS 项目提出了场景的三层抽象：功能场景（自然语言描述）、逻辑场景（参数化状态空间）与具体场景（确定参数值），这一分层被后续场景库与仿真测试广泛沿用。^{5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在智能座舱侧，功能安全场景定义还需覆盖驾驶员监控、人机交互接管请求等场景，ISO 26262 对驾驶员作为「外部措施」的可控性假设需要与座舱告警策略一致，否则 HARA 的 C 参数假设不成立。^{8181ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开}

中国《汽车驾驶自动化分级》（GB/T 40429-2021）以场景化的动态驾驶任务与设计运行条件来划分 0—5 级，把设计运行条件作为分级与场景定义的核心概念。^{7575GB/T 40429-2021 汽车驾驶自动化分级openstd.samr.gov.cn前往参考资料 ↓在新标签页中打开}

场景定义在功能安全中的产出通常包括场景清单、场景参数范围、场景与危害事件的映射表，以及场景覆盖度论证，这些产出需随系统变更持续维护。^{8181ISO 26262-1:2018 Road vehicles — Functional safetyiso.org前往参考资料 ↓在新标签页中打开|8282ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开}

有研究指出，仅靠专家经验枚举场景难以覆盖长尾危险情形，基于自然驾驶数据与事故数据挖掘场景的方法正在补充传统 HARA 的场景来源，但数据覆盖偏差仍是公开讨论的问题。^{5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

在政策与产业实践中，场景定义过于宽泛最典型的表现是把中试平台、常规采购、招商引资、企业内部数字化改造等一并纳入“场景”范畴；实地调研显示这类做法“并不鲜见”，导致各地各部门对“综合性重大场景”“高价值小切口场景”“标志性场景”等细分概念缺乏统一界定，申报企业只能自行判断申报方向。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

场景概念泛化的直接后果是政策标准与执行规则失去依据：一旦“什么都是场景”，有限的创新资源就会被非场景项目挤占稀释，场景开放政策也就难以筛选出真正需要验证的新技术、新产品。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

国办发〔2025〕37号文将场景界定为“用于系统性验证新技术、新产品、新业态产业化应用以及配套基础设施、商业模式、制度政策的具体情境”，据此可提炼出真实性等核心要素——场景必须是真实生产运营环境，实验室演示与中试平台工艺熟化条件再先进也不构成场景。这一界定为判断“宽泛”提供了可操作的收紧标准。^{3232浙江省发展规划研究院官网zdpi.org.cn前往参考资料 ↓在新标签页中打开}

在智慧城市研究中，场景概念内涵不清晰被归纳为三个方面：概念缺少明确界定、内容宽泛而含混、边界模糊；其成因在于智慧城市本身具有信息维度、空间维度与社会维度三元融合的跨领域特征，多视角内涵的交叉正是这种宏观融合在微观层面的反映。^{8787期刊精粹 | ​智慧城市场景的概念解读与特征认知【抢先版】mp.weixin.qq.com前往参考资料 ↓在新标签页中打开}

场景一词在空间规划、智慧技术、媒体传播、产品研发和商业策划等领域被广泛使用，同一词语在不同语境下所指尺度悬殊——既包括大系统，也指代小片段；研究者与不同领域专家交流后发现，大家所说的场景并非同一内涵，关注重点存在巨大差异。这说明“过于宽泛”不只是个别使用者的失误，而是该概念跨领域移植时的结构性特征。^{8787期刊精粹 | ​智慧城市场景的概念解读与特征认知【抢先版】mp.weixin.qq.com前往参考资料 ↓在新标签页中打开}

场景定义过于宽泛在实践中的具体形态包括：以“全场景”“多场景”等前缀把概念外延无限扩张，如“全场景智慧城市”“多场景分层覆盖的移动通信网络”；以及把场景作为代指建设内容的工作体系标签，如“一心三化九场景”。这类用法扩大了传播力，却使场景从可验证的具体情境退化为泛化的修辞标签。^{8787期刊精粹 | ​智慧城市场景的概念解读与特征认知【抢先版】mp.weixin.qq.com前往参考资料 ↓在新标签页中打开}

在交互设计与需求工程中，场景（scenario）与需求（requirement）常被混为一谈，但二者在抽象层次上不同：场景是对用户、任务与环境在特定情境下如何交互的具体描述，而需求是对系统应具备何种属性或行为的规范性陈述。^{8888Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开|1919Usability Engineering: Scenario-Based Development of Human-Computer Interactionsciencedirect.com前往参考资料 ↓在新标签页中打开}

卡罗尔（John M. Carroll）在《Making Use: Scenario-Based Design of Human-Computer Interactions》中系统阐述了基于场景的设计方法，主张场景是设计推理的具体载体，可用于唤起反思、支撑沟通与协调设计决策，而非直接等同于需求规格。^{8888Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开}

罗森森（Mary Beth Rosson）与卡罗尔合著的《Usability Engineering: Scenario-Based Development of Human-Computer Interaction》进一步将场景贯穿于需求分析、设计、原型与评估全过程，说明场景在开发早期用于发现和澄清需求，而非替代需求文档。^{1919Usability Engineering: Scenario-Based Development of Human-Computer Interactionsciencedirect.com前往参考资料 ↓在新标签页中打开}

在需求工程领域，场景被广泛用于引出和验证需求：场景描述系统在具体情境中的预期使用方式，需求则从中提炼为可验证的陈述；将场景直接当作需求会导致需求缺乏可测试性与完整性。^{8989Scenario-Based Requirements Engineeringlink.springer.com前往参考资料 ↓在新标签页中打开}

国际标准 ISO/IEC/IEEE 29148:2018 将需求定义为「为满足需要而必须满足的条件或能力」，并强调需求应具备必要性、无歧义、可验证等特性；场景描述本身通常不满足这些特性，因此不能直接充当需求。^{9090ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineeringiso.org前往参考资料 ↓在新标签页中打开}

在敏捷开发实践中，用户故事（user story）常被视为场景与需求的混合体：它用场景化语言描述用户价值，但需通过验收标准补充可验证性，否则容易停留在叙事层面而无法指导开发与测试。^{9191User Stories Applied: For Agile Software Developmentpearson.com前往参考资料 ↓在新标签页中打开}

有观点认为，在探索性设计与创新项目中，过早将场景固化为需求会限制设计空间，场景应保持开放与多元，以支持对多种可能未来的比较与讨论。^{8888Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开|9292Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

将场景与需求混淆的典型后果包括：把个别用户的具体操作路径误当作普遍需求、以场景叙事替代可验证的验收标准、以及在场景变化时无法判断需求是否仍然成立。^{8989Scenario-Based Requirements Engineeringlink.springer.com前往参考资料 ↓在新标签页中打开|9191User Stories Applied: For Agile Software Developmentpearson.com前往参考资料 ↓在新标签页中打开}

区分二者的实用做法是：场景回答「谁在什么情境下做什么、为什么」，需求回答「系统必须满足什么条件才算合格」；场景可作为需求的来源与验证手段，需求则是对场景中稳定约束的提炼与规范化。^{8888Making Use: Scenario-Based Design of Human-Computer Interactionsmitpress.mit.edu前往参考资料 ↓在新标签页中打开|8989Scenario-Based Requirements Engineeringlink.springer.com前往参考资料 ↓在新标签页中打开|9090ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineeringiso.org前往参考资料 ↓在新标签页中打开}

场景覆盖不全（scenario coverage gap）指在场景定义阶段未能穷举或识别出对系统行为、用户体验或安全有实质影响的使用情境，导致后续设计、测试或验证在未建模的情境下失效。它是场景方法在实践中最常被提及的系统性风险之一，因为场景集合的完备性无法被直接证明，只能通过覆盖度论证间接评估。^{9393Scenario-based safety assessment: a systematic literature reviewieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|9494Scenario-Based Design: Envisioning Work and Technology in System Developmentwiley.com前往参考资料 ↓在新标签页中打开}

在自动驾驶安全论证中，场景覆盖不全被视为残余风险的主要来源：基于场景的安全评估（scenario-based safety assessment）只能覆盖被识别并参数化的场景，未被纳入场景库的「未知情境」无法通过该方法获得保障，因此 ISO 21448（SOTIF）明确要求对场景空间进行系统性识别并论证其充分性，而非仅依赖已列举场景的测试通过率。^{8282ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开|5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开}

场景覆盖不全的典型成因包括：以设计者经验或现有产品功能反推场景，导致「已知的已知」被过度代表；以数据驱动方式从既有运行数据中挖掘场景，使低频但高后果的长尾情境系统性缺席；以及场景抽象层级选择不当，过粗的粒度掩盖了参数组合中的边界情形。^{9393Scenario-based safety assessment: a systematic literature reviewieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|9595The long tail of automated driving scenariosarxiv.org前往参考资料 ↓在新标签页中打开}

长尾问题使场景覆盖不全难以通过增加样本量消除：真实道路中高后果交互情境的出现频率极低，依靠自然驾驶数据积累在有限里程内难以观测到足够样本，因此业界转向场景库、对抗性生成与仿真来主动补足覆盖，但这些方法本身仍以已定义场景空间为前提，存在循环依赖。^{9595The long tail of automated driving scenariosarxiv.org前往参考资料 ↓在新标签页中打开|9696Survey of scenario generation for autonomous vehicle testingieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}

在交互设计与服务设计领域，场景覆盖不全表现为只覆盖「理想路径」或「典型用户」，遗漏边缘用户、异常状态与跨设备/跨渠道的断裂情境，其后果通常在可用性测试或上线后才暴露，修复成本显著高于在场景定义阶段补全。^{1111About Face: The Essentials of Interaction Design (4th Edition)wiley.com前往参考资料 ↓在新标签页中打开|2222This Is Service Design Doing: Applying Service Design Thinking in the Real Worldoreilly.com前往参考资料 ↓在新标签页中打开}

对场景覆盖是否「足够」存在方法论上的分歧：一方主张以风险为导向，优先覆盖高严重度、高概率场景并接受其余场景的残余风险；另一方主张以系统化场景空间枚举（如基于本体、基于功能逻辑分解）追求可论证的完备性。两种立场在安全相关领域的标准实践中并存，尚未形成统一判据。^{8282ISO 21448:2022 Road vehicles — Safety of the intended functionalityiso.org前往参考资料 ↓在新标签页中打开|9797Risk-based scenario selection for automated driving validationsae.org前往参考资料 ↓在新标签页中打开}

缓解场景覆盖不全的常见做法包括：建立可追溯的场景来源清单（事故数据、自然驾驶数据、专家工作坊、标准场景库），对场景空间做显式的维度分解并标注覆盖状态，以及在测试与验证环节引入对抗性场景生成以探测未建模边界。^{5959PEGASUS Project — Scenario-based safety assessment of automated drivingpegasusprojekt.de前往参考资料 ↓在新标签页中打开|9696Survey of scenario generation for autonomous vehicle testingieeexplore.ieee.org前往参考资料 ↓在新标签页中打开}