体验要求不是配置清单
“用户能准确知道车门是否锁好”是体验要求；用什么传感器、芯片或通信方案实现，是后续产品和工程选择。
SES MASTER V1.5 · 通俗说明
这份 Excel，是把用户感受变成产品要求的一套总账
它解决一个实际问题：用户说“我想随时知道车是不是安全锁好了”，产品团队怎样把这句话变成明确的体验要求、测试方法和需要建设的车辆能力？这份表把整个过程连接起来。
01 · 全页总览
从用户期待，到体验标准、检查、能力与治理
从上向下读：SES 把用户目标变成稳定的体验要求，再分流到使用场景、检查证据和产品能力；机器候选必须经过专家判断，结果才会进入评价与产品决策，并持续回写治理。
1,006具体体验要求（SES）
194用户目标
1,907检查和评分规则
540产品基础能力
02 · 用一个例子理解
例如：用户想远程确认车辆是否锁好
同一件事在表里会被拆成四种不同内容。这样用户研究、体验评价和产品工程可以说同一件事，但各自管理自己负责的部分。
用户目标我想随时放心离开车辆后，用户希望仍能掌握车辆状态。
体验要求（SES）状态完整且准确门窗和车锁状态能够被完整获取，并与车辆实际状态一致。
检查规则逐项核对状态检查手机端能否查看门、窗、锁等状态，并和实车对照。
产品基础能力状态采集与同步车辆采集状态，通过网络同步到账号和手机端。
03 · 数据结构
SES_ID 是整套数据的主轴，其他表围绕它展开
这份 Excel 可以理解成一个小型关系数据库。最核心的表是 01_SES_Master，每条体验要求有唯一的 SES_ID。其他表不重复保存整条体验要求，而是通过 ID 与它连接。
| 数据对象 | 主键 / 连接字段 | 保存什么 | 怎样影响其他数据 |
|---|---|---|---|
| 用户目标库 19_UX目标库 | UX_Goal_ID | 用户最终想获得的价值 | 通过 20_Goal-SES映射，一项目标可以拆成多条 SES |
| 体验标准主表 01_SES_Master | SES_ID | 唯一、稳定的体验要求及状态、版本、优先级 | 是评价、场景、失效、能力和成熟度数据共同引用的中心 |
| 场景与客户指标 02、03、09、13 | SES_IDScenario_ID | 体验要求适用于哪个客户指标、旅程、任务和场景 | 决定同一条 SES 在不同项目和场景中怎样被调用 |
| 评价规则库 04、21 | SES_IDAudit_Rule_ID | 验证动作、评价方法、评分和判定规则 | 把抽象的体验要求变成可执行的检查；评价结果进入车型表现指数 |
| 体验失效库 05_EFL体验失效库 | Failure_ID关联SES_ID | 用户会遇到的失败、严重度和价值损失 | 反向检查 SES 是否覆盖关键风险，并影响治理优先级 |
| 产品能力库 25_原子能力字典 | 标准能力ID | 产品需要具备的最小基础能力 | 通过 06_Design连接层与 SES 建立主能力、支撑能力关系 |
| 设计连接表 06_Design连接层 | DesignLink_IDSES_ID + 标准能力ID | 一条 SES 可能需要哪些能力，以及匹配置信度 | 把体验语言转成产品建设方向，但必须经过专家复核 |
| 证据与治理 07、15～18、22～24、26 | SES_ID 或治理事件 | 覆盖缺口、语言风险、成熟度、证据和审批记录 | 决定数据是正式、待复核、补充还是废弃，并回写主表状态 |
一对多：一个目标 → 多条体验要求
UX_Goal_ID 通过 Goal-SES 映射连接多个 SES_ID。例如“随时安心掌握车辆状态”可以拆成状态完整、数据准确、刷新及时等多条要求。
多对多：体验要求 ↔ 场景 / 客户指标
同一条 SES 可以用于多个场景和客户指标；一个场景也会调用多条 SES。因此必须用映射表，不能把所有内容塞进主表一行。
一对多：一条体验要求 → 多条检查规则
同一 SES 可以有多个验证动作、评分方式和适用版本。测试方法变化时只更新 Audit Rule，不修改 SES 的含义。
多对多：体验要求 ↔ 产品能力
一条 SES 可能需要主能力和若干支撑能力；同一项能力也可能支撑多条 SES。连接表负责保存关系、角色和置信度。
04 · 为什么有 27 张表
不是让一个人看完，而是让不同团队各管一部分
核心体验要求只保存“用户应该得到什么”。客户指标、测试评分、失效案例和产品能力分别放在其他表里。以后某个评分阈值或技术方案变化时，不必重写体验要求。
用户研究用户为什么需要管理人群、使用场景、需求强弱和用户目标
体验标准车辆应该带来什么体验保存 1,006 条统一、可复用的体验要求
项目适配这条要求用在哪里连接不同客户指标、使用场景和具体任务
体验评价怎样判断有没有做好管理检查方法、评分规则、失败案例和证据
产品设计产品需要建设什么连接产品基础能力、设计参考和工程指标
数据治理谁能修改、怎样复核管理字段定义、质量审计、修改流程和批准权限
05 · 使用时不要混在一起
三件容易混淆的事
体验要求不是评分细则
体验要求应保持稳定。测试动作、扣分方式和合格阈值可以随着项目和行业变化单独更新。
产品能力不是车型配置名
“车辆状态同步”是一项基础能力；某车型宣传册上的功能名称只是这项能力的一种产品呈现。
简单记法：体验要求负责说清楚“应该做到什么”，其他表负责回答“用在哪里、怎么检查、靠什么实现”。
06 · 当前完成到哪里
电脑已经给出能力候选，但大部分还需要人确认
系统尝试为每条体验要求寻找可能相关的产品基础能力，共生成 1,184 条关系。当前方法主要根据文字相似度初筛，只能帮助专家缩小查找范围，不能直接交给工程团队执行。
这组数字意味着什么
- 现在只是生成了候选答案，还没有匹配完成。
- 813 条属于极低把握，必须优先人工检查。
- 有些是文字相似但实际无关，有些则说明能力库还缺内容。
- 只有专家确认后，关系才能成为正式数据。
07 · 专家复核清单
专家只需要依次回答四个问题
问题 1没有这项能力，通常还能实现这条体验要求吗？
问题 2它是最主要的能力，还是只起辅助作用？
问题 3如果候选都不对，是否说明能力库缺少了一项能力？
问题 4最终应该确认、降为辅助、退回重找，还是登记能力缺口？