第2章：场景边界定义与评审：用户意图、使用场景、非预期场景、边界条件清单
场景边界定义是AI产品评审中确认“黑盒”与“白盒”分界线的关键环节。评审团队需在需求阶段系统梳理用户意图、使用场景、非预期场景及边界条件，形成可审计的清单，防止模型在实际部署中因输入偏移或环境突变导致失效。
核心原则：边界清单不是一次性产物，应伴随需求迭代至少更新3次——需求冻结、开发中期、预发布前。
1. 适用场景
- AI产品功能需求从“模糊意向”向“可验证边界”转化的阶段
- 跨职能评审：产品经理、算法工程师、测试工程师、合规专员共同参与
- 模型输入维度复杂（多模态、多语种、实时流）或输出存在风险分级
- 需要为后续测试用例设计提供场景覆盖率基线
2. 前置条件
- 已完成用户故事地图或功能列表定稿
- 产品原型或PRD至少进入V0.5（内部审阅版）
- 风险分类目录（如伦理、安全、法律、隐私）已发布
- 至少配备1名具备场景工程经验的评审员
3. 操作步骤
| 步骤 | 活动 | 关键产出 |
|---|---|---|
| 1 | 用户意图提取：从PRD、用户调研、日志中提取至少20条原始用户意图，采用“主语+动词+对象”结构描述 | 意图列表（含优先级） |
| 2 | 使用场景分层：将意图归类为“核心场景”“扩展场景”“边缘场景”，并标注触发条件（正常/异常/极端） | 场景分层矩阵 |
| 3 | 非预期场景识别：基于反模式库（如对抗攻击、数据投毒、权限绕过）和业务领域知识，枚举至少5个非预期场景 | 非预期场景列表 |
| 4 | 边界条件清单编制：对每个场景提炼出输入维度（数据类型、取值范围、频率、并发量、时间窗口等）的边界值 | 边界条件清单（含判定条件） |
| 5 | 交叉评审与签字：至少3名角色（产品、算法、测试）逐条确认边界是否可验证、可测试、不遗漏 | 评审通过纪要 |
4. 输入输出物
| 类型 | 名称 | 格式 | 责任方 |
|---|---|---|---|
| 输入 | 用户故事 + PRD（V0.5+） | Markdown/PDF | 产品经理 |
| 输入 | 领域风险分类目录 | Excel/CSV | 合规专员 |
| 输出 | 场景边界清单（含意图、场景、非预期、边界条件） | 结构化文档（JSON/YAML） | 评审组长 |
| 输出 | 评审签字页（含异常处理记录） | 扫描件/PDF | 项目助理 |
5. 责任边界
- 产品经理：提供用户意图原始素材，并确认意图优先级。
- 算法工程师：评估边界条件是否满足模型输入约束（如嵌入维度、token限制）。
- 测试工程师：将边界条件转化为可执行的测试用例。
- 合规专员：标识非预期场景中的合规风险（如隐私泄露、歧视）。
- 评审组长：主持评审会议，确保所有争议项记录在异常处理清单中。
6. 记录材料
- 场景边界清单（含版本号、修订历史）
- 评审会议录音/录像（至少保存至项目结束）
- 异常处理登记表（格式见下方示例）
异常处理登记表示例（节选）：
异常编号: EX-2025-003
场景: 用户意图“修改他人文档权限”
问题描述: 属于非预期场景，涉及权限越权，当前模型无法安全处理
登记人: 合规专员
处置建议: 归入边界条件，模型返回“无权限”并记录日志
处置状态: 已闭环
关联边界条目: BDR-00427. 异常处理
- 意图模糊或冲突：暂停评审，由产品经理48小时内补充用户调研或A/B测试数据，重新提交。
- 边界条件不可测试（如依赖未来硬件能力）：标记为“暂缓”并设置回顾日期，不影响当前基线。
- 非预期场景超出当前团队认知：启动外部专家咨询，咨询后更新边界清单。
- 审核签字缺位：必须获得至少2名核心角色签字，否则不得推进开发。
8. 验收标准
- 「场景边界清单」覆盖PRD中所有功能，且每个场景至少包含1个非预期场景。
- 边界条件清单中每条边界都有明确的“触发条件 + 期望行为 + 验收指标”。
- 评审签字率达到100%，并且异常处理表中所有“未闭环”项有明确的跟进人与计划关闭日期。
- 清单以机器可读格式（JSON/YAML）归档到项目知识库，并触发版本号递增。