木鸡 SteadyGame：团队第二次作业——原型设计 & 需求分析

木鸡SteadyGame 2026-10-15 17:34:50

项目	内容
这个作业属于哪个课程	202601 福大-软件工程实践-W 班
这个作业要求在哪里	软件工程实践团队第二次作业——原型设计&需求分析
团队名称	木鸡 SteadyGame
项目名称	基于计算机视觉的 Web 体感运动交互平台
这个作业的目标	完成团队项目计划、需求规格说明书、用户场景、UML 类图、界面原型、功能描述与可执行验收标准，并在答辩中说明项目范围、团队协作与后续实现计划
其他参考文献	GB/T 9385-2008《计算机软件需求规格说明规范》；MediaPipe Pose Landmarker Web 指南；MDN `getUserMedia()` 文档；《构建之法》

一、团队项目计划

1.1 项目定位与边界

1.2 功能范围与优先级（P0/P1/P2）

一、团队项目计划

1.1 项目定位与边界

一句话定位： 用普通摄像头做输入，把身体动作变成浏览器里的游戏控制器。

木鸡 SteadyGame 要做的是一个 Web 端体感运动交互平台。用户不需要购买任何外设，打开浏览器、授权摄像头、完成一次自然站姿校准，就能用身体动作控制游戏，并在每一局结束后得到明确的结果反馈。

我们真正想验证的问题不是"姿态识别能不能跑起来"——那是成熟模型的既有能力。我们要验证的是：摄像头输入能否形成一段短时、清晰、可完成的运动互动体验。

这个定位来自上一轮选题评审的反馈。评审老师与助教指出我们的竞品分析不够具体、并建议聚焦一种运动。我们复盘后统一了三件事：

问题	我们的回答
用户练什么	一套有标准版本可对照的身体活动（如传统健身功法八段锦）
系统评什么	动作过程中的重心控制表现——偏移幅度与波动
系统不评什么	动作是否标准。那是视频跟练类产品的赛道，我们不进入

产品边界（写清楚"不做什么"和"做什么"同样重要）：

本项目是娱乐与低强度体感活动工具，不具备疾病诊断、康复指导或专业体能测评资格。
成绩只表示在当前识别条件与游戏规则下的表现，不构成任何健康结论。
八段锦的"阶段完成"只说明软件规则检测到阶段顺序满足条件，不代表动作在体育教学或医学意义上标准。

与上一轮选题的衔接： 上一轮我们给出的三种玩法是"切水果、接小球、做操"。本轮结合组内会议，把它们收敛为平衡小球、体感切水果、八段锦两式跟练——三种玩法仍然共用同一套"姿态识别 → 动作/重心信号 → 游戏响应"的技术内核，区别只在交互形式。这是对"聚焦内容、不压缩玩法"这条结论的落地。

1.2 功能范围与优先级（P0/P1/P2）

我们用 P0/P1/P2 冻结范围，这是防止项目延期最主要的手段。

优先级	含义	拟开发内容	原型如何表达
P0	未来开发阶段基础必做	摄像头告知与授权、采集与错误恢复、本地姿态识别、稳定性判定、自然站姿校准、共享动作输入、游戏入口、平衡小球完整关卡、暂停/恢复/退出、单局结果	完整正常流程 + 完整异常流程
P1	课程版本计划完成	体感切水果、八段锦两式跟练、共用姿态可视化与语音音效、账号及个人成绩历史	标注"计划功能"，提供可点击交互预览
P2	有余力才考虑的拓展	成绩导出与简单趋势、外接传感器输入适配、第四种游戏	仅在文档中保留，不作为可交互功能

P0 的最小可玩闭环定义为：

打开网页 → 阅读摄像头用途 → 授权 → 自然站姿校准 → 完成一局平衡小球 → 查看本局结果

三种玩法的定位细分：

平衡小球（P0）：身体左右倾斜控制小球沿路线前进，收集光点、避开障碍、抵达终点。
体感切水果（P1）：连续采样腕点形成短轨迹，只有轨迹线段与水果目标相交才判定命中。
八段锦两式（P1）：首版只做"两手托天理三焦"和"调理脾胃须单举"，每式按准备、上举/伸展、保持、还原四阶段推进。

1.3 里程碑安排

本轮作业节点（已发生 / 进行中）：

时间	里程碑	具体交付	状态
10 月 12 日	需求讨论	明确三种玩法、P0/P1/P2、模块边界与访谈计划；形成 SRS v0.2	✅ 已完成
10 月 13 日	需求与原型初审	完成用户场景、UML 类图、可点击原型 v0.3、原型设计说明、答辩材料与评审表模板	✅ 已完成
10 月 14 日	二次修订	核查指标、补充评审材料、按反馈修改	✅ 已完成
10 月 15 日 23:59 前	作业提交	上传材料至华为云仓库，班级作业页面提交博客链接	✅ 已完成
10 月 16 日	课堂答辩	讲稿统一、原型演练、准备备用录屏；演示 P0 闭环与异常恢复	⏳ 待执行

后续开发里程碑（未来计划）：

迭代	目标	交付内容	验收方式
M1 公共底座	跑通最小链路	`Camera` / `Pose` / `Motion` 共享接口与最小 Web 工程	摄像头 → 关键点 → 动作信号链路连通；实测延迟与关键点抖动
M2 游戏实现	完成核心玩法	平衡关卡闭环、切水果轨迹切割、音效、跨设备测试	按 AT-08/11/12 执行真实试玩
M3 特色与记录	完成项目特色	八段锦两式、成绩存储、历史页、回归测试、HTTPS 部署	按 AT-13/16 执行，数据隔离通过越权测试

M1 的产出决定 M2、M3 的范围。 我们的态度是：先把手部关键点的抖动实测出来，看哪些量稳定、哪些飘，再决定用哪几个量作为正式评价指标——而不是先写结论再找依据。

二、关键点、难点与风险分析

2.1 技术风险

编号	风险/难点	等级	影响	应对措施
R-01	弱光、背光或遮挡导致关键点丢失	🔴 高	角色跳变、误计分、动作阶段无法推进	开始前给出光线与站位提示；无效输入冻结游戏；记录设备基线、有效帧比例与丢点次数
R-03	八段锦动作的视角与个体差异大	🔴 高	阶段误判；容易把规则结果误写成专业评价	首版只做两式、四阶段状态机；用真人试做调阈值；明确不做医疗或专家级评级
R-04	切水果轨迹碰撞规则难调	🟡 中	未命中被误判，或一次挥臂清空所有目标	采用腕点线段↔圆形目标相交判定；准备"相交/未相交/快速往返/重复划过"四类测试
R-05	浏览器权限与 HTTPS 约束	🟡 中	摄像头无法启动，答辩现场难以演示	提前验证演示浏览器与安全域名；准备"拒绝授权/无设备/重试"三个演示分支

技术边界的三个"还没测"（这是我们主动撤回过度表述的结果）：

上一轮我们曾写过"提踵容易量化""可测重心高度"这类说法。复盘后我们认定这属于还没验证就先下结论，现已全部撤回，并明确列为待实测项：

重心位置：用髋关节中点作近似，但它忽略了上肢摆动，而这类健身功法恰好有大量上肢动作，误差有多大目前没有数据。
支撑面：严格的支撑面应由双脚落地范围决定，现有方案能否稳定给出这个范围，还没验证。
提踵高度：只能用踝关节垂直位移间接反映，精度同样未经验证。

这些不是"做不到"，而是"还没测"。把它们写成已经解决，就是拿不确定当确定。

2.2 工程与协作风险

编号	风险/难点	等级	影响	应对措施
R-02	8 人并行开发造成共享接口冲突	🔴 高	前后端字段不一致，合并后难以联调	先冻结接口与目录规范；独立分支 + PR 审阅 + 变更说明（详见第四节）
R-06	功能扩张导致延期	🔴 高	三玩法 + 硬件 + 高级评价同时推进，P0 无法收口	冻结 P0/P1/P2；外接设备、完整八式、趋势分析、第四游戏全部放 P2
R-07	用户调研与评审证据不足	🔴 高	需求只是团队内部假设，原型结论无法核验	至少完成一次真实用户访谈 + 原型试用，记录匿名意见、对应 FR 编号与修改结果

R-02 是本项目最现实的工程风险。 8 个人同时开工，如果每个人对 MotionInput 里 leanX 的含义理解不一致，联调时会出现"界面能跑但方向反了"这类极难定位的问题。我们的对策是把接口契约前置到编码之前——这也是第六节接口协作包的由来。

2.3 隐私与运动安全边界

这属于项目需求的一部分，不是事后补充的免责声明。

数据处理的硬约束：

原始摄像头画面与逐帧关键点原则上只在浏览器会话内处理，不写入日志、数据库或对象存储。
后端只接收账号信息与结算摘要（玩法、分数、时长、完成情况）。
如果未来改为服务端视觉推理，必须先召开隐私需求变更评审，重新评估采集频率、留存规则与告知方式。

安全提示（界面上必须出现）：

选择宽敞站位、避开尖锐障碍、动作缓慢、身体不适立即停止。

同意机制分离： 摄像头用途同意与成绩保存同意是两个独立的勾选，前者不替代后者。

运动安全： 项目不输出疾病风险、矫正疗效、康复结论或专业健康诊断。

三、项目分工与贡献度

3.1 模块分工

团队 8 人，每人承担一个主要代码模块，测试与文档工作交叉分担。

成员	主代码模块	主要开发交付
林晨	平台架构与训练流程	`GameCoordinator`、状态机、接口统筹、最终集成
郑雯心	摄像头与输入适配	摄像头授权、采集、资源释放、异常处理与设备测试
王婉怡	CV 识别与动作映射	MediaPipe 接入、关键点处理、校准、平滑与有效性判断
林宇扬	平衡小球	控制逻辑、目标收集、计分、结算、游戏测试
林凯	体感切水果	腕点轨迹、命中检测、水果生成、特效与得分
孙田田	八段锦跟练	两式阶段识别、提示规则、动作测试
李想	前端交互与多媒体	页面入口、摄像头准备、通用组件、语音音效、结果与历史页
刘婷婷	后端、账号与记录	身份鉴权、成绩 API、历史存储、数据隔离

⚠️ 说明： "模块负责人"指的是未来编码阶段的职责划分，不代表该模块已经开发完成。拍摄、演示、文档等横向工作由全组轮值分担。

3.2 本次作业贡献度表

本次作业（需求分析 + 原型设计）的文档工作量拟按 8 人各 12.5% 分配：

学号	工作内容	贡献度
【102400420】林晨	需求范围界定、分层架构图、游戏状态机、版本控制与最终集成	16.0%
【102400409】郑雯心	输入异常场景设计、摄像头设备方案与测试计划	12.0%
【102400408】王婉怡	CV 数据字典、动作映射需求、质量属性与风险分析	12.5%
【102400422】林宇扬	平衡小球用户场景、游戏规则与验收条目	12.0%
【102400421】林凯	切水果交互需求、碰撞规则与验收条目	11.5%
【102400407】孙田田	页面原型设计、界面验收规范与答辩演示材料	12.0%
【102400419】李想	八段锦用户场景、阶段规则与反馈设计	12.5%
【102400405】刘婷婷	数据模型、接口定义与验收矩阵	11.5%
合计	8 人文档任务拟分配	100%

四、成员协作方式

课程本轮特别强调"加强团队成员分工协作"。8 人小组最大的浪费不是有人偷懒，而是两个人做了同一件事，或者一个人做完后别人接不上。下面是我们的具体机制。

4.1 工具链与版本基线

用途	工具	说明
代码与文档版本基线	华为云代码仓库	课程要求；唯一权威版本，所有交付材料最终都从这里取
日常沟通与例会	飞书 / 微信群	例会通知、问题同步、阻塞提醒
交叉评审与评审表	腾讯共享文档	界面原型评审表、需求分析评审表
接口设计与调试	Apifox + OpenAPI 3.1	接口契约的唯一来源（见 6.1 接口协作包）
缺陷与任务跟踪	项目看板	每两天更新一次状态

原则：一份内容只在一个地方维护。 博客里的链接指向仓库里的文件，不在博客里复制粘贴文档正文，避免"博客和文档不一致"。

4.2 接口先行：让 8 个人能并行开发

这是我们认为最关键的一条协作机制。

问题： 8 个人并行开发时，如果 Camera、PoseFrame、MotionInput、GameResult 这些共享数据结构的字段、单位、有效性判定各写各的，就会出现"每个人手里都有一个不同版本的 MotionInput"，联调时会付出成倍的代价。

做法：先把契约定死，再并行写实现。

CameraAdapter ──视频帧──→ PoseRecognizer ──PoseFrame──→ MotionMapper ──MotionInput──→ GameCoordinator
                                                                                          ├─ BalanceGame
                                                                                          ├─ FruitGame
                                                                                          └─ BaduanjinGame
                                                                                          ↓
                                                                                     GameResult

我们为接口冻结设定了三条硬规则：

字段变更必须广播。 Camera / Pose / Motion / GameResult 的任何字段调整，先发布字段变更说明并同步所有消费者，再改代码。
单位与含义写死在注释里。 例如 MotionInput.leanX 明确为 [-1, 1]，负值表示画面方向左倾，正值表示右倾——镜像方向写清楚，避免"方向反了"这类返工。
接口隔离带来并行度。 三个游戏不直接调用摄像头，只消费 MotionInput。所以三个玩法的负责人可以完全独立开发，互不阻塞。

我们为此单独交付了"接口协作包"，包含 18 个对外接口 + 2 个内部 CV 接口的 OpenAPI 定义、Postman 调试集合、环境变量示例和逐项请求响应说明，让后端、CV、前端三条线能在同一份契约下开工。

4.3 分支策略与冲突处理

分支模型：

分支	用途	规则
`main`	只保留可集成版本	禁止直接推送；只能通过合并进入
`feature/<模块>-<任务号>`	各成员开发分支	例：`feature/balance-issue12`
`fix/<问题号>`	缺陷修复	修复后须复测对应需求编号

合并前检查：

至少 1 位同组成员完成代码或文档审阅；
附变更说明（改了什么、影响哪些模块、如何验证）；
合并后立即做最小链路检查（打开页面 → 授权 → 校准 → 进游戏），确认主干没被改坏。

冲突处理流程：

发现冲突
   ↓
模块负责人说明影响范围
   ↓
架构负责人 + 受影响成员共同决策
   ↓
小范围提交 / 保留可回滚版本
   ↓
合并后最小链路验证

我们的取舍： 宁可小步提交、频繁集成，也不要攒一个巨大的合并。小范围提交即使出错，回滚成本也可控。

4.4 任务同步与交叉验证机制

任务同步节奏：

每 2 天更新一次任务状态；
阻塞超过 1 天，直接在设计群同步负责人，不等到下次例会；
正式开发后每周至少 1 次集成；
阶段验收前做 1 次全链路彩排（含答辩演示环境）。

交叉验证（避免"只有一个人懂"）：

模块负责人先自测；
其他成员按验收编号（AT-xx）试玩并记录问题，而不是凭感觉说"挺好的"；
测试与文档工作轮值承担，不让任何一个人独占某个技术岗位；
访谈、演示与材料整理按阶段轮值，确保项目证据不集中在个别人手里。

问题闭环： 所有问题形成 问题 → 修改 → 验证 记录，修复后复测对应的 FR/AT 编号，而不是只看到界面没问题就关单。

五、软件需求规格说明书

5.1 文档信息与链接

材料	在线链接
《软件需求规格说明书》	SteadyGame软件需求规格说明书.docx

文档信息	内容
文档编号	`SG-SRS-2026-01`
版本 / 状态	v0.2 · 需求分析阶段拟定方案（待组内评审）
编制日期	2026 年 10 月 12 日
开发状态	尚未正式开发；本文件是本轮作业的需求设计稿

文档分层结构：

SRS 参照 GB/T 9385-2008 的组织思想，同时严格对应课程要求的"引言—用户场景—类图—界面原型—功能描述—验收验证标准"六项重点，采用

总体目标 → 用户场景 → 系统模型 → 具体需求 → 验收条目

的分层叙述，随着"层"的深入，描述内容越具体。

章	内容
1	引言（编写目的、项目背景、术语）
2	总体描述（目标、产品边界、用户群体、约束假设）
3	用户场景与需求分析（画像、用户故事、典型场景、用例图）
4	系统模型与类图（分层架构、领域类图、实现类图、状态流转）
5	详细功能需求（FR-01 ~ FR-19）
6	非功能需求与约束（NFR-01 ~ NFR-09）
7	接口与数据字典
8	界面原型设计
9	验收验证标准（AT-01 ~ AT-18）
10	项目计划与团队协作
11	需求待确认与参考资料
附录 A	访谈记录模板与评分项核对

5.2 引言与项目背景

编写目的： 澄清本项目的目标用户、功能范围、业务规则、模块边界、界面原型、质量属性与验收依据。预期读者为小组开发成员、课程教师、助教和评审同学。读者无需了解计算机视觉底层模型，也应能理解软件要完成的任务以及何时算完成。

项目背景： 项目拟解决"轻量运动交互门槛较高、普通跟练缺少即时反馈"的体验问题。团队尝试用常见电脑或手机摄像头读取用户姿态，把动作映射为屏幕中的游戏控制，同时通过关卡目标与结果记录提供正向反馈。

当前阶段： 项目处于"选题已确定 → 需求分析与界面原型设计"的课程阶段，团队尚未开始正式实现三个游戏。Vue 3、TypeScript、MediaPipe、Canvas 等仅作为拟用技术，不表示任何技术方案已开发、跑通或验收。

5.3 术语与缩略语

课程要求"所有的缩写须事先定义"，我们把术语表作为文档的强制组成部分：

缩写 / 术语	英文或标识	本文含义
CV	Computer Vision	计算机视觉，指通过图像理解人体位置和动作
Web	World Wide Web	本项目指在浏览器访问的网页应用
MVP	Minimum Viable Product	最小可验证产品，本项目指 P0 可用闭环
SRS	Software Requirements Specification	软件需求规格说明书
UML	Unified Modeling Language	统一建模语言，用于类图和关系建模
API	Application Programming Interface	模块或服务对外提供的接口
FPS	Frames Per Second	每秒处理的视觉帧数
P0 / P1 / P2	Priority level	必做 / 计划实现 / 延后拓展的需求优先级
PoseFrame	姿态帧	含关键点、时间戳和状态的本轮识别数据
MotionInput	动作信号	由姿态特征映射得到的游戏控制数据

5.4 用户场景

5.4.1 需求获取现状

作业要求访问真实用户，我们已准备访谈提纲与验证计划（见 5.4.4），并明确不预设满意度结论。

5.4.2 假设用户画像（待访谈验证）

角色	可能的使用情境	推出的需求
U1 学生体验者	在宿舍或教室利用课余时间活动；不愿穿戴额外传感器	希望在 1 分钟内开始试玩；实时知道动作是否被识别
U2 运动跟练者	对八段锦感兴趣，但仅凭视频不容易确认是否跟上节奏	希望得到阶段提醒和鼓励性反馈；不接受夸大的健康判断
U3 课堂评审者	需要直观看到系统模块间如何协作，能判断功能是否完整	希望看到一次完整体验、异常恢复和具体数据

5.4.3 用户故事与需求追踪

故事 ID	用户故事	对应需求
US-01	作为体验者，我想先了解摄像头用途，再自己决定是否授权，以便放心使用	FR-01/02
US-02	作为初次玩家，我想知道该站在哪里以及姿态是否识别成功，以便快速校准	FR-03/04/05
US-03	作为平衡游戏玩家，我想用身体左右倾斜移动小球并得到即时反馈	FR-06/08
US-04	作为体感切水果玩家，我想挥手切中指定水果，而不是只做一次挥臂就清空全部目标	FR-11/12
US-05	作为八段锦体验者，我想知道动作目前处于哪个阶段及如何调整	FR-13/14
US-06	作为用户，我想在被遮挡或暂时离开画面时自动暂停，以免错误计分	FR-04/09
US-07	作为返回的登录用户，我想查看自己的历史训练结果	FR-10/16
US-08	作为担心隐私的用户，我希望原始摄像头画面只在本机处理	FR-03/16；NFR-02

5.4.4 典型使用场景

SC-01　新玩家首次进入平衡小球

参与者：U1 学生体验者；前置条件：桌面设备具备摄像头，支持安全上下文。

进入首页，阅读摄像头用途与安全提示
选择平衡小球并允许摄像头访问
确认骨架可见，保持自然站立完成校准
左右倾斜控制小球，收集目标并抵达结束状态
查看本局分数、用时和识别情况

替代 / 异常流程： 拒绝授权 → 说明原因并提供重试或退出；离开画面 → 输入冻结，显示重新站位提示；重复点击结算 → 仅生成一条结果。

追踪到需求： FR-01/02/05/08/09/10

SC-02　切水果玩家挥手命中目标

参与者：U1 学生体验者；前置条件：姿态有效且已启动切水果关卡。

页面出现多个水果并显示剩余时间
玩家移动手腕，屏幕形成短暂轨迹
轨迹与一个水果相交，目标消失并加分
倒计时结束，汇总命中数与分数

替代 / 异常流程： 轨迹未相交 → 不计分；同一水果重复划过 → 只计一次；关键点失效 → 暂停切割事件。

追踪到需求： FR-11/12

SC-03　八段锦两式跟练与阶段提示

参与者：U2 运动跟练者；前置条件：用户已完成站位检查，选择支持的动作。

选择"两手托天理三焦"并阅读示意
系统按准备、上举、保持、还原展示阶段
用户按提示动作，规则引擎判断进度
完成后给出阶段完成情况并提供下一式入口

替代 / 异常流程： 手腕不可见 → 提示调整角度，不给错误通过；阶段顺序错误 → 保持当前阶段并给出纠正建议；不适立即点击退出 → 终止跟练。

追踪到需求： FR-13/14/09

SC-04　拒绝权限与隐私控制

参与者：U1 学生体验者；前置条件：浏览器未授权摄像头。

进入准备页，看到用途说明
点击拒绝授权后得到清晰错误提示
浏览公共说明、退出或重试，而不会上传视频

替代 / 异常流程： 无设备 → 展示无摄像头文案；网络断开 → 如果模型未缓存则提示资源加载失败。

追踪到需求： FR-01/02；NFR-01/02

5.5 类图与系统模型

5.5.1 分层架构与职责边界

采用"应用页面 → 游戏流程控制 → 共享动作输入 → 姿态识别与摄像头"的分层架构。高频姿态帧在浏览器内处理；登录与结果摘要通过后端接口保存。

层级 / 组件	主要任务	依赖 / 输出
`CameraAdapter`	管理摄像头权限、轨道与视频帧	输出原始视频流，仅本地使用
`PoseRecognizer`	MediaPipe 推理、关键点及追踪状态	输出 `PoseFrame`
`MotionMapper`	校准、关键点几何特征、平滑与有效性判定	输出 `MotionInput`
`GameCoordinator`	模式选择、准备、暂停、结算与防重复提交	调用各 `GameEngine`
三个 `GameEngine`	各自维护目标、碰撞、动作阶段及计分规则	输出 `GameResult`
`RecordGateway`	认证、结果写入、个人历史查询	通过 HTTPS 到业务后端

关键设计决策：三个游戏不直接调用摄像头，统一消费 MotionInput。 未来接入新硬件时只需新增输入适配器，不改变游戏规则层。

5.5.2 核心领域类图（UML）

        ┌──────────┐
        │   User   │
        └────┬─────┘
             │ 1..*
        ┌────▼──────────┐        ┌──────────────────┐
        │  GameSession  │◄───────┤  GameDefinition  │
        └────┬─────┬────┘  引用   └──────────────────┘
             │     │
     1..1    │     │  1..1        ┌────────────────┐
   ┌─────────▼┐   ┌▼───────────┐  │  Calibration   │
   │GameResult│   │FeedbackEvent│  └────────────────┘
   └──────────┘   └─────────────┘

   PoseFrame ──映射依赖──→ MotionInput      （不进入数据库）

关系解释：

GameDefinition 描述玩法，GameSession 表示一次训练；
GameResult 与 GameSession 至多一对一（保证唯一结算）；
FeedbackEvent 可以有多条；
游客可创建本地会话，此时 userId 可以为空，仅登录后的结果允许持久保存；
PoseFrame → MotionInput 是数据映射依赖，不保存原始帧。

5.5.3 模块实现类图（UML）

实现类图采用统一接口 + 三种独立玩法 + 结果网关的结构。计划开发中 CameraAdapter、GameEngine 等可采用 TypeScript 接口与组合模式，不强制采用 Java 风格继承。

UML 类图是需求分析阶段的逻辑设计，名称及成员字段可在详细设计阶段调整，但跨模块输入输出契约必须保持兼容。

5.5.4 游戏状态流转

当前状态	合法触发	目标状态 / 系统行为
`Welcome`	选择游戏	`Setup`：展示权限与站位准备
`Setup`	授权成功 + 模型就绪	`Calibrating`：采集基线
`Calibrating`	采样满足且状态稳定	`Playing`：启动计时与输入
`Playing`	暂停 / 识别无效	`Paused`：停止位置更新
`Paused`	有效姿态恢复并确认	`Playing`：继续同一会话
`Playing`	达成目标或时间结束	`Result`：生成唯一结算
任意游戏态	主动退出	`Welcome`：释放媒体轨道与循环

注意 Paused → Playing 需要用户主动确认，不是自动恢复。这是为了避免人在重新站位时被立即带入游戏。

5.6 功能描述

需求采用 FR-序号 唯一编号，每条需求都映射到第 9 章的验收条目。"规划阶段"表示拟纳入的未来版本，不是当前代码进度或测试结果。

编号	功能	级别	精确定义 / 边界
FR-01	摄像头用途告知与权限	P0	进入相机前展示使用目的、运行环境和安全提示；用户同意后才发起授权
FR-02	摄像头采集与错误恢复	P0	支持授权/拒绝/无设备/流中断；退出或切换页面时释放 MediaStream
FR-03	浏览器本地姿态识别	P0	通过 MediaPipe 从视频帧输出关键点、可见度、时间戳与追踪状态
FR-04	姿态稳定性与新鲜度判定	P0	关键点缺失 / 置信度不足 / 数据过期时标记无效，停止动作驱动
FR-05	自然站姿校准	P0	引导玩家站稳、收集有效样本，形成当前会话基线；失败可重试
FR-06	共享动作输入接口	P0	将姿态帧映射为带时间戳、有效标记和归一化倾斜/腕点的动作信号
FR-07	游戏入口与模式选择	P0	展示三类玩法、功能状态及开始入口；未完成模式给出说明
FR-08	平衡小球完整关卡	P0	由身体左右倾斜控制小球，收集目标/避开障碍，完成条件触发结算
FR-09	会话暂停/恢复/退出	P0	主动暂停或追踪丢失时冻结计时/控制；恢复须重新满足有效输入条件
FR-10	单局结果与防重复结算	P0	生成一条唯一结果，展示游戏名、得分、完成情况、时长和基础统计
FR-11	切水果手部轨迹切割	P1	采样腕部移动轨迹；轨迹线段与水果图形相交时判定命中，冷却防重复
FR-12	切水果规则与反馈	P1	水果生成、有效命中得分、连击/失误提示、时长结束结算
FR-13	八段锦两式阶段识别	P1	首版支持"两手托天理三焦""调理脾胃须单举"，用关节特征和状态机识别阶段
FR-14	八段锦实时跟练提示	P1	展示动作名称、阶段、纠正建议及完成状态；不输出医疗等级评分
FR-15	共用姿态可视化与语音音效	P1	关键点叠加、识别状态标记、静音控制、事件音效与文字同步提示
FR-16	账号及个人成绩历史	P1	游客可体验；登录后存储结果、仅查询本人历史；提交失败有重试提示
FR-17	成绩导出与简单趋势	P2	导出仅含成绩统计的 CSV，展示个人训练次数和分数趋势
FR-18	外接传感器输入适配	P2	增加 `SensorInputAdapter`，实现与 `MotionInput` 相同的控制协议
FR-19	新增第四种游戏	P2	通过统一 `GameEngine` 接口挂接新小游戏而不修改姿态识别模块

几个关键边界的设计意图：

FR-04 / FR-06： PoseFrame 必须带单调时间戳与有效标记。滤波不得使用未来帧，过期数据不得重新播放到当前游戏。
FR-06： 动作控制采用相对基线偏移而非绝对坐标，使不同站位的用户都能操作。
FR-10： "唯一结算"是硬要求——重复点击结束不能产生两条结果。
FR-11： 首版优先使用 Pose 关键点中的手腕坐标，把连续腕点采样组成短轨迹。指尖级轨迹跟踪属于进一步优化。
FR-13： 判断依据为左右手相对肩的高度、肘部伸展、动作持续时间和顺序。动作阶段判断应有一定时间窗口与阈值容忍；低可见度时提示调整站位，不将算法猜测称为姿势错误。

5.7 非功能需求

标识	属性	目标要求	测试证据
NFR-01	安全上下文	摄像头只在 HTTPS 或 localhost 等安全上下文启用；非安全上下文给出明确说明	浏览器 URL 测试
NFR-02	隐私最小化	不持久化、不上传原始摄像头画面和姿态逐帧数据；后端仅接收账号和结算摘要	Network 面板 + DB 检查
NFR-03	识别连续性	计划在基准设备进行 60 秒连续识别测试，记录帧率、有效帧比例、丢点次数；完成技术验证后再确定阈值	指定设备真实测试
NFR-04	交互响应	姿态输入到游戏状态更新应可感知地连续，不出现连续跳跃；实测记录端到端延迟再确定阈值	高帧率录屏与事件时间戳
NFR-05	异常可恢复	摄像头拒绝、模型加载失败、识别中断、网络异常均有中文说明与返回/重试操作	故障注入测试
NFR-06	数据隔离	成绩读写以登录身份关联，服务端验证身份，不信任客户端传来的 userId	未授权/越权接口测试
NFR-07	浏览器适配	最低演示环境：桌面 Chromium 类浏览器与摄像头；移动端为适配目标，需实测决定支持清单	桌面和手机兼容性矩阵
NFR-08	可访问性	主要操作具备文字标签、足够对比度、可静音、允许退出；不以颜色为唯一状态提示	UI 检查表
NFR-09	训练安全	开始前提示预留空间、动作缓慢、身体不适即停止；不能宣传治疗、康复效果	文案审查 + 用户试读

5.8 接口与数据字典

5.8.1 前端内部数据格式

类型	字段	规则和示例
`PoseFrame`	`timestampMs: number`	单调时间戳，毫秒；必须用于过期检测
`PoseFrame`	`landmarks: {x,y,z,visibility}[]`	标准化人体关键点；仅会话内存使用
`PoseFrame`	`trackingState: tracking\\|unstable\\|lost`	丢点时不能继续驱动游戏
`MotionInput`	`leanX: number`	范围 `[-1, 1]`，负值左倾、正值右倾（以画面方向说明）
`MotionInput`	`leftWrist / rightWrist: {x,y}?`	归一化坐标 `[0,1]`；不可见时为空
`MotionInput`	`valid: boolean, timestampMs: number`	无效时下游必须停止接收动作事件
`GameResult`	`sessionId: UUID, mode: enum`	唯一会话标识及玩法：`balance` / `fruit` / `baduanjin`
`GameResult`	`score: number, durationMs: integer`	非负分数与毫秒时长
`GameResult`	`completed: boolean, detail: object`	玩法特有摘要：收集数、命中数或已完成阶段

5.8.2 接口协作包（18 个对外接口 + 2 个内部接口）

为了让 8 个人能在同一份契约下并行开发，我们单独整理并交付了接口协作包：

分组	接口数	主要接口
01 账号与登录	5	`GET /api/auth/csrf`、`POST /api/auth/register`、`POST /api/auth/login`、`GET /api/auth/me`、`POST /api/auth/logout`
02 游戏目录	1	`GET /api/games`
03 训练轮次与成绩	4	`POST /api/sessions`、`GET /api/sessions/{sessionId}`、`POST /api/sessions/{sessionId}/start`、`PUT /api/sessions/{sessionId}/result`
04 人体姿态与动作评估	2	`POST /api/cv/pose`、`POST /api/cv/baduanjin/evaluations`
05 运动记录与报告	3	`GET /api/records`、`GET /api/stats/summary`、`GET /api/reports/summary`
06 数据导出	3	`POST /api/exports`、`GET /api/exports/{exportId}`、`GET /api/exports/{exportId}/file`
07 CV 内部接口	2	`POST /internal/pose`、`POST /internal/baduanjin/evaluations`

协作包内容：

文件	用途
`SteadyGame-接口定义.openapi.json`	中文接口目录、参数类型、请求/响应示例、错误状态及数据模型
`SteadyGame-调试用例.postman_collection.json`	调试请求与前后置脚本，自动保存 CSRF、轮次 ID、评估 ID、导出 ID
`SteadyGame-本地环境.postman_environment.json`	调试变量（不含个人账号或有效令牌）
`SteadyGame-CV内部.openapi.json`	业务后端与 CV 之间的内部接口
`接口逐项请求与响应说明.md`	20 个接口各自的请求格式、成功返回和错误状态说明

关键契约约定：

协议采用 OpenAPI 3.1；CV 内部模型可替换，对外统一为 17 个命名关节点，缺失点为 null，不直接向游戏暴露模型内部的数组索引。
成绩提交按 sessionId 幂等，服务端按鉴权身份绑定用户。
GET /api/records 只返回当前用户成绩，按创建时间倒序分页。
导出任务只返回 pending / running / succeeded / failed 状态，不提供百分比；成功后再请求文件接口。

5.8.3 持久化数据（P1）

实体	主要字段	关系及隐私边界
`User`	`id, nickname, credentialHash, createdAt`	仅保存必要身份数据；密码须哈希
`GameSessionResult`	`sessionId, userId, mode, score, durationMs, completed, detailJson, createdAt`	`userId` 外键；`sessionId` 唯一；不保存视频或逐帧关键点

5.8.4 统一异常码

错误码	含义
`CAMERA_DENIED`	用户拒绝摄像头授权
`CAMERA_NOT_FOUND`	无可用摄像头设备
`MODEL_LOAD_FAILED`	识别模型资源加载失败
`POSE_LOST`	姿态追踪丢失
`NETWORK_ERROR`	网络异常
`UNAUTHORIZED`	未授权访问

前端将原始异常转成统一中文提示；所有帧处理逻辑不得在界面关闭后继续执行。

5.9 验收验证标准

每个 AT 测试在执行时记录：执行人、设备与浏览器版本、预置条件、观察结果、是否通过、失败截图/日志。

测试 ID	关联需求	测试条件	预期结果
AT-01	FR-01	首次点击"开始体验"	展示摄像头用途、安全提示；未同意前不调用 `getUserMedia`；拒绝仍可返回首页
AT-02	FR-02	允许/拒绝授权、无设备、正常退出	允许时见预览；拒绝或无设备显示原因及重试；退出后摄像头轨道关闭
AT-03	FR-03	普通室内光线，正面单人进入画面	应能显示身体关键点和追踪状态；帧率阈值待测试后确认
AT-04	FR-04	遮挡关键点、离开画面、输入过期	无效帧不能驱动角色；显示丢点/站位提示；恢复后不跳变
AT-05	FR-05	玩家自然站立，校准中轻微移动/离开	稳定数据收集后提示校准成功；失败提示重试；校准基线与会话绑定
AT-06	FR-06	注入 `leanX=-2、0、2` 与 `valid=false`	倾斜归一化限制在 `[-1,1]`；`valid=false` 时下游不移动；时间单位统一毫秒
AT-07	FR-07	打开首页并点击三个模式	每个模式有明确入口/说明；尚未开放的模式不得误进入运行状态
AT-08	FR-08	开始平衡小球，依次左右倾斜及收集目标	小球方向正确；轨道边缘不越界；目标只计数一次；满足完成条件进入结算
AT-09	FR-09	游戏中点击暂停、短暂丢失人体、继续	暂停期间计时与角色不变化；恢复前检验有效姿态；重复操作不造成双循环
AT-10	FR-10	正常结束、重复点击结束、退出再进入	每会话最多产生一条结算数据；能显示分数/时长/完成状态
AT-11	FR-11	腕部轨迹穿过/不穿过水果，快速往返	仅相交轨迹记命中；未相交不加分；同一水果不得重复计分
AT-12	FR-12	20 秒切水果体验（时长可配置）	得分依据有效命中；倒计时结束正确结算；水果消失/音效反馈可见
AT-13	FR-13	按预设两式的阶段顺序示范与逆序乱做	各式能按阶段前进；错误顺序不记完整；识别不稳定时不给通过
AT-14	FR-14	动作不到位 / 离框 / 正确完成	提示段具整建议；完成给出结果；不出现"诊断/治疗"等表述
AT-15	FR-15	开始、暂停、切水果命中与静音	提示文字与场景事件一致；静音后无音效；浏览器禁止自动播放时不报错
AT-16	FR-16	游客 / 登录用户 / 不同用户 / 提交失败	游客可试玩但不读写个人记录；不同用户互不可查询；失败提示可重试
AT-17	FR-17	含中文游戏名和空历史的导出请求	CSV 表头清楚、无原始视频/关键点；空数据有合理提示
AT-18	FR-18/19	新增模拟设备与第四游戏占位测试	不改原有 CV 模块即可接入输入/玩法；作为扩展性评估，不纳入初版验收

评审与测试流程：

环节	内容
需求评审	检查范围、术语定义、业务规则是否有歧义；问题填入腾讯共享的"需求分析评审表"
单元测试	模拟关键点、归一化边界、线段碰撞、状态机顺序、成绩防重复
集成测试	浏览器摄像头 → `PoseFrame` → `MotionInput` → 三个游戏 → `GameResult`
用户测试	当前阶段只安排访谈和静态/可点击原型的理解测试；编码后再开展真实试玩
回归测试	修复故障后复测相关需求编号，形成"问题—修改—验证"闭环

六、界面原型设计

6.1 原型材料链接

材料	在线链接
可点击交互原型	在线体验原型
原型设计说明（Markdown）	仓库 README
界面原型设计评审表	腾讯共享文档

原型如何使用： 原型是离线可点击的 HTML（index.html + style.css + app.js），双击即可用浏览器打开，无需安装、无需联网。底部有"原型演示条"，可快速切换页面、模拟授权、模拟左右倾斜、触发识别丢失与保存失败等异常状态。

6.2 原型范围与主流程

本轮原型把需求稿中的六张概念图，细化为可点击的完整交互流程，覆盖三种玩法与异常处理。三种模式共用同一条体验流程：

游戏大厅 → 摄像头准备（用途同意 + 授权） → 自然站姿校准 → 开始体验 → 本局结果 →（登录并另行同意）个人历史
                                                              ├─ 再来一次
                                                              └─ 返回大厅

优先级	拟开发内容	本次原型如何表达
P0	授权、校准、平衡小球闭环、暂停、结果	完整页面与正常/异常流程
P1	切水果、八段锦两式、反馈、账号历史	标注"计划功能"，提供交互预览
P2	导出、趋势、外接设备、更多玩法	仅保留说明，不作为可交互功能

信息架构：

游戏大厅
├─ 平衡小球（P0） ─┐
├─ 体感切水果（P1） ├─ 权限准备 → 站位校准 → 体验 → 本局结果
└─ 八段锦两式（P1） ┘                                ├─ 再来一次
                                                    ├─ 返回大厅
                                                    └─ 登录 + 另行同意保存 → 个人历史
使用指南：设备、镜像方向、暂停、隐私、活动提示
个人历史：游客引导 / 有记录 / 筛选空态 / 全部空态 / 加载失败

主导航固定为游戏大厅、训练记录、使用指南。授权、校准与游玩属于一次会话中的步骤。游戏进行时点击主导航会先暂停；退出会弹出确认。

6.3 页面清单与关键界面

页面编号	页面	信息与主要操作	对应需求
UI-P01	游戏大厅	三种模式、优先级、动作方式、开始/预览、安全提示	FR-07，NFR-09
UI-P02	摄像头准备	使用目的、镜像预览、站位与空间说明、独立用途同意、模拟授权	FR-01/02/03，NFR-01/02
UI-P03	站位校准	完整入框、自然站立、进度、失败建议、重试、成功后开始	FR-05/06
UI-P04	平衡小球	路线、起点、光点、障碍、终点、计时、得分、方向、暂停/退出	FR-08/09/10
UI-P05	体感切水果	腕点轨迹、相交命中、连击、未命中、倒计时、暂停/退出	FR-11/12
UI-P06	八段锦跟练	两式选择、动作示意、四阶段进度、建议、暂停/退出	FR-13/14
UI-P07	本局结果	玩法、分数/阶段、时长、完成摘要、再来一次、可选保存	FR-10/16
UI-P08	训练记录	游客登录引导、个人摘要、玩法筛选、详情、空态、加载失败重试	FR-16
UI-P09	使用指南	设备、镜像方向、恢复规则、隐私与活动边界	NFR-01/02/07/08/09

6.3.1 游戏大厅（UI-P01）

三种玩法使用相同的卡片结构，名称、动作方式、目标、状态和按钮位置固定，优先级和产品状态独立标注。

设计要点：

状态不混淆： P0 基础闭环与 P1 计划玩法分别用标签标识，未开放的模式不会误进入运行状态。
选择有依据： 每张卡片说明动作方式、任务目标和本局提供的反馈。
低门槛入口： 游客可体验；侧栏持续提示"动作留在这里"（画面本地处理）。
安全提醒固定在大厅底部。

6.3.2 摄像头准备与校准（UI-P02 / UI-P03）

授权与校准分两步，让用户知道发生了什么。

关键设计：

先同意，再授权。 文字明确"用于提取人体关键点，映射为游戏控制；原始画面和逐帧姿态不上传、不保存"。未勾选摄像头用途同意时，授权按钮不可用。
权限与校准分离。 授权成功后进入站位校准，校准页说明正对镜头、自然站立、完整入框，并显示模拟采样进度。
方向约定提前说明。 "左倾向左、右倾向右，与镜像画面一致"——把最容易产生困惑的一点前置。

校准失败时显示"关键点不完整"的具体建议（后退、调整镜头、保持稳定），不直接进入游戏。

6.3.3 平衡小球（UI-P04）

关卡区保持突出，侧栏提供得分、剩余时间、收集数与姿态预览。

设计要点：

方向一致： 左倾向左、右倾向右，以镜像画面方向为准（画面左下角常驻方向提示）。
目标具体： 五个光点、障碍和终点可见；单个目标只计一次。
操作易找到： 暂停和退出固定在侧栏，进度与当前状态相邻。
状态相邻： 得分、剩余时间、收集进度（2/5）与姿态预览同屏可见，用户不必切换页面就能判断"我现在怎么样"。

原型示例参数（需评审确认）： 5 个光点、每个 10 分、60 秒上限。碰撞只作提示，不扣分。 这些参数用于评审界面，不是需求文件规定的固定指标。

6.3.4 体感切水果（UI-P05）

核心规则：腕点轨迹必须穿过目标才计分。

有效命中： 轨迹线段与目标相交后，水果消失并出现加分与连击反馈。
无效操作： 未穿过目标时分数不变；同一目标只处理一次。
丢点停止判定： 停止计时与切割事件，恢复后继续同一轮。
静音后仍保留文字反馈。

原型示例参数： 20 秒关卡、每个目标 10 分，连击显示次数但不额外倍增得分。正式产品的动态生成、真实腕点识别与时间窗口待实现。

6.3.5 八段锦两式跟练（UI-P06）

首版只设计"两手托天理三焦"和"调理脾胃须单举"，每式按准备 → 上举/伸展 → 保持 → 还原四阶段推进。

动作示意与式名放在画面上方，并标注"动作示意，非专业教学"。
阶段逐步推进： 四个阶段按顺序记录，每个阶段只记录一次；错误顺序保持当前阶段。
反馈边界清晰： 低可见度时先调整站位；画面明确写出"阶段完成不等同于专业动作评级"。

重要边界： 从第二式单独开始，只能完成该式的 4 个阶段，不把未做的第一式算入完成数。正式规则将根据手部相对肩部高度、肘部伸展和时间窗口判断，阈值与动作来源需进一步确认。

6.3.6 结果与历史（UI-P07 / UI-P08）

结果页： 展示本局玩法、分数、时长、收集或命中摘要及完成情况。游客可以直接查看；登录之后，还需要独立勾选"成绩摘要保存同意"。
唯一会话： 同一会话重复保存不会新增第二条；保存失败仍保留本局结果，允许重试。
历史页区分五种状态： 游客引导 / 有记录 / 筛选为空 / 全部空态 / 加载失败。

正式实现要求： 历史必须由服务端按登录身份隔离，不能靠前端筛选实现权限控制。原型中的示例记录已显式标记，模拟成绩只保存在页面内存。

我们特别注意了"空状态"的设计。 大多数原型只画"有数据"的样子，但用户第一次使用时看到的恰恰是空页面——如果空页面什么都不说，用户会以为功能坏了。

空状态的处理原则： 不只说"暂无数据"，而是解释为什么没有 + 提供下一步操作。同时，筛选为空与完全没有记录要分别处理，前者提示"换个筛选条件看看"，后者引导"完成一轮并同意保存"。

同意机制分离是这里的重点： 摄像头用途同意不替代成绩保存同意。用户完全可以在不保存任何成绩的前提下体验全部 P0 功能——这是隐私最小化（NFR-02）在界面上的直接体现。

6.4 异常状态与恢复设计

我们没有只画正常流程。 异常处理不是独立死路，而是通过明确提示与操作回到原流程。

下面是"识别丢失"状态的实际原型画面——这是我们认为最能体现设计取舍的一个界面：

请重点看这张图里的三件事：

弹窗说明了原因："关键点不足，已冻结计时与动作。请回到取景范围，让肩、手腕和腿部清晰可见。"——不只说"出错了"，而是告诉用户具体怎么做。
"继续本局"按钮是禁用状态（灰色），必须先点击"模拟：已重新站入画面"，等姿态恢复后按钮才可用。
背景仍显示"得分 / 阶段 20　已用时 00:01"——进度被保留，计时被冻结，用户不会因为丢了 3 秒就损失成绩。

为什么这样设计？ 如果识别丢失后自动恢复，用户可能人还没站好就被重新带入游戏，导致误计分和挫败感。所以我们选择"冻结 → 引导恢复 → 用户主动确认 → 继续同一会话"这条链路。用户始终可以点"退出"结束体验，不会被卡死。

情境	界面反馈	可执行操作	恢复条件
权限被拒绝	解释浏览器权限设置入口	重试、返回	重新获得权限
无可用摄像头	提示接入或更换设备	重试、返回	找到可用设备
资源加载失败	提示检查网络，暂不开始	重试、返回	模型资源就绪
摄像头连接中断	提示占用或连接问题	重新连接、重试	有效媒体流恢复
校准失败	提示后退、调整镜头、保持稳定	重新校准	有效稳定样本满足条件
主动暂停	保留进度，冻结计时与输入	继续、退出	用户主动继续
识别丢失	"暂时看不到你了"，继续按钮不可用	重新站位、退出	姿态有效后，用户确认继续
退出游戏	告知未完成成绩不保存	取消或确认退出	确认后停止会话
保存失败	保留当前结果，说明不会重复计入	重新保存	登录、同意与请求成功
历史为空 / 加载失败	分别解释未产生记录或网络问题	开始第一轮 / 重新加载	完成保存或重新加载成功

三条通用规则：

无效输入时不继续更新小球、不命中水果、不推进动作阶段、不计时。
页面切换会取消校准采样和模拟加载；离开游戏或标签页隐藏时会暂停。
正式版本退出还需释放媒体轨道、识别循环和相关资源。

为什么识别丢失后不自动恢复？ 避免用户在人还没站好时被立即带入游戏。恢复有效姿态后仍需用户主动确认，才继续同一会话。

6.5 视觉规范与可访问性

项目	规范
主文字 / 主要按钮	深青 `#173D3E`
页面背景	米白 `#F6F5EF`
强调 / 收集目标	暖橙 `#CF7940`
辅助 / 可用状态	浅绿 `#E2EFE6`
错误	红棕 `#A54435`，同时展示原因与操作
字体	Noto Sans CJK SC，降级到微软雅黑、苹方和系统无衬线
布局	桌面侧栏 + 主工作区；玩法区突出，状态与暂停位置固定
操作	文字标签、键盘焦点、弹窗焦点限制、可关闭提示音
窄屏	导航收窄，卡片与两列布局改为纵向；历史表在容器内滚动

可访问性设计：

主要状态不依赖颜色单独表达，文字提示同步保留；
主要按钮都有文字标签，键盘可聚焦，暂停弹窗限制焦点；
静音只关闭音效，文字反馈继续保留；
尊重系统"减少动态效果"设置。

诚实边界： 桌面 Chromium + 摄像头是最低演示目标；移动端仅提供原型布局演示。

6.6 界面原型设计评审表

原型评审表按"页面 → 需求 → 验收编号 → 检查点"的追踪链设计，共 16 项界面检查点。

编号	页面 / 维度	需求追踪	评审内容
UI-01	大厅与玩法入口	FR-07 / AT-07	三种玩法、功能优先级与入口清晰
UI-02	权限用途告知	FR-01 / AT-01	先告知用途，后发起授权
UI-03	摄像头异常	FR-02 / AT-02	拒绝、无设备、加载失败可恢复
UI-04	姿态预览与方向	FR-03/06 / AT-03/06	可见状态和镜像控制方向一致
UI-05	站位校准	FR-05 / AT-05	准备、采样、成功与失败完整
UI-06	平衡小球	FR-08 / AT-08	路线、目标、障碍与分数可理解
UI-07	暂停与恢复	FR-04/09 / AT-04/09	主动暂停和丢点恢复不丢进度
UI-08	退出与导航	FR-02/09 / AT-02/09	退出确认与返回路径完整
UI-09	切水果轨迹	FR-11/12 / AT-11/12	相交才命中，同一目标不重复计分
UI-10	八段锦两式	FR-13 / AT-13	两式与四阶段顺序清楚
UI-11	八段锦反馈	FR-14 / AT-14	纠正建议具体，不夸大动作评价
UI-12	结果与防重复	FR-10 / AT-10	结果字段充分且每会话唯一
UI-13	游客与历史	FR-16 / AT-16	游客、登录、筛选和空状态清晰
UI-14	成绩与隐私	FR-16 / NFR-02/06	成绩另行同意，失败能重试
UI-15	样式与可访问性	FR-15 / NFR-08	统一字体、状态、按钮与静音反馈
UI-16	设备与活动提示	NFR-01/07/09	桌面与窄屏可读，活动边界清楚

评审表还包含"各小组评审与排名"表：记录被评审小组名称、项目名称、评审内容、主要评审建议、综合评价、排名、评审方小组、评审人和日期。

待验证的评审问题（已准备访谈提纲）：

建议邀请真实潜在用户（非本组成员优先）完成三项任务：

首次进入并完成一轮体验；
读懂丢点后如何恢复；
理解"摄像头同意"与"成绩保存同意"的区别。

记录匿名观察、卡住的位置、建议和对应 UI / FR 编号，再修订原型。当前尚未实施课堂评审。

七、需求分析 PPT 链接

材料	在线链接
需求分析汇报 PDF	SteadyGame需求分析报告ppt.pdf

共 18 页，按课程评分项组织：

页	内容
01–02	项目与需求；本次作业要回答的五个问题（为何开发 / 谁会使用 / 系统怎么分层 / 用户看到什么 / 怎么证明做到了）
03–04	目标与意义；范围与优先级（三个模式，一套公共底座）
05–07	需求获取现状；用户场景 SC-01；用户故事（切水果 / 八段锦 / 拒绝授权）
08–10	系统架构（一套 CV 底座驱动三个独立玩法）；UML 核心领域类图；实现类图
11–13	原型设计：大厅与站位准备；平衡小球与切水果；八段锦跟练与个人结果
14–16	功能需求（FR 编号化）；验收验证（AT 可复现）；非功能要求
17–18	分工与进度；结论与待评审的四项决定

汇报中明确写出：用户画像和满意度已真实访谈，所有性能指标已经实测。

八、界面原型设计答辩 PPT 链接

材料	在线链接
界面原型设计答辩 PDF	SteadyGame界面原型设计答辩ppt.pdf

共 16 页

页	主题
01	封面：界面原型设计答辩 v0.3
02	用户需要知道怎么开始、怎么动、何时完成
03	三个模式共用一条体验流程（P0/P1/P2）
04	完整体验路径与暂停恢复
05–06	游戏大厅；授权与校准分两步
07–08	平衡小球；识别丢失时先冻结再引导恢复
09–10	切水果轨迹必须穿过目标；八段锦四阶段提示
11–12	游客可看结果、保存需另行同意；历史页的三种状态
13–14	统一样式与文字反馈；需求编号可追踪到页面与评审项
15–16	本次原型任务建议与后续节点；现场演示与待验证事项

现场演示路径（约 60 秒）：

打开 index.html，选择平衡小球 → 阅读用途 → 勾选同意 → 模拟授权
完成校准 → 模拟左右倾斜、收集两个光点
点击"识别丢失"→ 展示继续按钮不可用且计时冻结
点击"模拟：已重新站入画面"→ 说明仍需用户主动确认继续
继续并收集剩余光点 → 展示本局结果
用演示账号登录 → 单独同意成绩保存；可演示保存失败与重试 → 查看历史
切水果：依次演示未命中 / 命中 / 重复划过，比较分数
八段锦：对比"错误顺序"与"按顺序推进阶段"

演示时必须说明： 原型可点击不等于算法、摄像头、后端和成绩保存已经实现。摄像头、骨架、账号与成绩均为课堂模拟数据。

九、自查：作业评分项逐条核对

评分模块	分值	本文对应位置	核对结果
博客排版 + 四类材料链接	2	开头信息表、第五~八节链接清单、`@[toc]` 目录	✅ 已覆盖
团队项目整体计划与里程碑	6	第一节，含 P0/P1/P2 与本轮/后续里程碑	✅ 已覆盖
关键点、难点与风险分析	5	第二节，R-01~R-07 + 技术边界三"还没测"	✅ 已覆盖
组员分工与工作量比例	7	第三节模块分工 + 贡献度表	✅ 结构已覆盖
成员协作方式	16	第四节：工具链、接口先行、分支策略、冲突处理、任务同步、交叉验证	✅ 已覆盖
SRS：引言	2	5.2 + SRS 第 1 章	✅ 已覆盖
SRS：用户场景	8	5.4：画像、8 条用户故事、SC-01~SC-04 含异常流程	✅ 已覆盖
SRS：类图	8	5.5：分层架构、领域类图、实现类图、状态流转	✅ 已覆盖
SRS：界面原型	8	第六节：UI-P01~P09 + 截图 + 视觉规范	✅ 已覆盖
SRS：功能描述	3	5.6：FR-01~FR-19 含级别与边界	✅ 已覆盖
SRS：验收验证标准	3	5.9：AT-01~AT-18 含条件与证据	✅ 已覆盖
按国标思想组织文档	12	SRS 目录、分层章节、术语定义、需求编号与引用	✅ 已覆盖
答辩：目的、意义、背景	2	需求分析 PPT 第 3 页；本文 1.1	✅ 已覆盖
答辩：研发内容（类图、原型、功能）	6	需求分析 PPT 第 8–15 页；答辩 PPT；本文第五、六节	✅ 已覆盖；课堂演示待执行
答辩：计划、分工、工作量落实	4	第一、三、四节 + PPT 第 17 页	✅ 结构已覆盖
答辩：PPT 演示	4	需求分析 PPTX/PDF、答辩 PPTX/PDF	✅ 文件已有
答辩：报告	4	SRS PDF、需求分析汇报、评审表	✅ 文件已有
合计	100	—	内容框架已按 100 分逐项核对

Checklist 覆盖情况（课程要求）：

要求项	覆盖位置
引言	5.2 + SRS 第 1 章
用户场景	5.4 + SRS 第 3 章
类图	5.5 + SRS 第 4 章
界面原型	第六节 + 原型材料
功能描述	5.6 + SRS 第 5、7 章
验收验证标准	5.9 + SRS 第 9 章
图表/文字/样式统一	统一术语表（5.3）、统一配色与组件规范（6.5）、统一 FR/AT/NFR 编号
1 篇博客随笔（含作业目录 + 评分要点核对）	本文 + 第九节
1 份界面原型设计（博客给出链接）	6.1
1 份界面原型设计答辩 PPT	第八节
1 份需求规格说明书	5.1
1 份需求分析报告 PPT	第七节
1 份界面原型设计评审表	6.6
1 份需求分析评审表	见 10.2 待办第 3 项

十、本轮的诚实边界与后续计划

10.1 我们已经做到的

✅ v0.2《软件需求规格说明书》（23 页）：含 FR-01~19、AT-01~18、NFR-01~09、UML 类图、接口数据字典、状态流转、风险表、分工与协作机制。
✅ v0.3 可点击界面原型：离线可用，覆盖 3 种玩法 + 10 类异常状态，含 index.html / style.css / app.js。
✅ 原型设计说明（15 页 PDF + Markdown）：设计依据、信息架构、页面清单、交互规则、视觉规范、演示路径。
✅ 需求分析汇报 PPT（18 页，PPTX + PDF）。
✅ 界面原型设计答辩 PPT（16 页，PPTX + PDF）+ 逐页课堂讲稿。
✅ 界面原型设计评审表（16 项检查点 + 各小组排名表，XLSX + Markdown）。
✅ 接口协作包：18 个对外接口 + 2 个内部接口的 OpenAPI 定义、Postman 调试集合、环境示例、逐项接口说明。