diff --git a/doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md b/doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md
new file mode 100644
index 000000000..80b677457
--- /dev/null
+++ b/doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md	
@@ -0,0 +1,1940 @@
+# RailwaySystem 智慧培训系统一期 PRD V1.0
+
+> **版本：** V1.0  
+> **文档状态：** 一期内部开发基线  
+> **修订依据：** 第二次项目会议结论  
+> **适用阶段：** 业务模型冻结 → 数据库 V2 → API 设计 → Issue 拆分 → 开发  
+> **后续版本：** 现场验证后根据甲方反馈升级 V1.1
+>
+> 本版本遵循一个核心原则：
+>
+> **一期优先完成最小可用的完整培训闭环，不提前开发需求中没有明确提出的复杂功能。**
+>
+> 对未来可能变化的需求：
+>
+> - 数值、权重、期限等采用配置方式；
+> - 结构性变化预留扩展空间；
+> - 不提前完整实现未来功能。
+
+---
+
+# 1. 产品定位
+
+RailwaySystem 是面向铁路培训基地的智慧培训管理系统。
+
+系统一期的核心不是分别建设课程、宿舍、签到、成绩等孤立模块，而是管理：
+
+> **某一批学员参加某一期培训，从培训准备、开班、排课、住宿、报到，到正式培训、考勤、成绩、学习统计以及培训结束的完整过程。**
+
+一期总体业务可以概括为：
+
+```mermaid
+flowchart TD
+    A[基础资源准备]
+    --> B[创建开班计划]
+
+    B --> C[配置本期课程]
+    B --> D[确定参训人员]
+
+    C --> E[排课 / 课次]
+    D --> F[宿舍预分配]
+
+    E --> G[形成课程表]
+    F --> H[形成住宿安排]
+
+    G --> I[学员报到]
+    H --> I
+
+    I --> J[展示宿舍 / 教室 / 场地 / 课程表]
+    J --> K[门禁授权]
+
+    K --> L[正式培训]
+
+    L --> M1[签到 / 签退]
+    L --> M2[自主学习 / VR / 3D / 实训]
+    L --> M3[成绩]
+
+    M1 --> N[统计分析]
+    M2 --> N
+    M3 --> N
+
+    N --> O[学员画像]
+    O --> P[培训结束]
+    P --> Q[历史数据保留]
+```
+
+---
+
+# 2. 一期设计原则
+
+第二次会议已经明确：
+
+> 第一版应尽量最小化，只完成当前需求真正需要的能力；业务没有明确提及的复杂功能先不加入。
+
+因此一期执行以下原则。
+
+## 2.1 业务闭环优先
+
+必须首先保证：
+
+```text
+开班
+→ 参训名单
+→ 排课
+→ 宿舍
+→ 报到
+→ 培训
+→ 考勤
+→ 学习
+→ 成绩
+→ 统计
+→ 结束
+```
+
+可以完整跑通。
+
+---
+
+## 2.2 不过度设计
+
+一期暂不为了未来可能使用而建设：
+
+```text
+复杂课程版本体系
+复杂课程审批
+复杂报名审批
+工作流引擎
+复杂画像规则引擎
+补考 / 重考体系
+复杂证书管理
+高度通用动态表单
+复杂消息中心
+```
+
+---
+
+## 2.3 可配置而不是写死
+
+例如：
+
+```text
+报到截止时间
+课程 / 项目权重
+及格线
+人数
+统计条件
+```
+
+不能直接硬编码在程序中。
+
+---
+
+## 2.4 外部系统与业务系统解耦
+
+RailwaySystem 管理业务。
+
+真实的：
+
+```text
+人脸识别
+电子班牌
+智能门锁
+VR
+3D
+电子阅览室
+```
+
+属于外部设备或系统。
+
+一期先使用 Mock 接口模拟，但 RailwaySystem 内部业务状态必须真实持久化。
+
+---
+
+# 3. 一期范围
+
+## 3.1 一期包含
+
+```mermaid
+flowchart LR
+    A[人员管理]
+    B[培训资源管理]
+    C[课程管理]
+    D[开班计划]
+    E[参训人员]
+    F[课程表 / 课次]
+    G[住宿管理]
+    H[报到]
+    I[考勤]
+    J[成绩]
+    K[学习数据接入]
+    L[统计]
+    M[学员画像]
+    N[权限与审计]
+```
+
+---
+
+## 3.2 一期不包含
+
+以下内容继续按照原计划放在二期：
+
+```text
+平板端基地控制
+平板端实训工位分配
+智慧照明
+智能工具箱
+数字孪生
+电工实训箱
+基地驾驶舱
+钢结构监测
+摄像机调阅
+其他智慧基地控制能力
+```
+
+---
+
+# 4. 用户角色
+
+系统继续复用若依 RBAC 权限体系。
+
+第二次会议明确认为权限框架本身已有能力，不需要一期重新设计权限系统。
+
+## 4.1 管理员
+
+一期主要业务操作人员。
+
+负责：
+
+- 教师管理；
+- 学员管理；
+- 培训资源管理；
+- 课程管理；
+- 开班；
+- 参训名单；
+- 排课；
+- 宿舍安排；
+- 报到异常处理；
+- 考勤管理；
+- 成绩管理；
+- 统计；
+- 画像查看。
+
+---
+
+## 4.2 教师
+
+根据权限负责：
+
+- 查看本人授课安排；
+- 查看授课课程；
+- 维护课程使用资源；
+- 查看相关学员；
+- 维护人工考勤；
+- 录入成绩；
+- 查看相关统计。
+
+具体权限通过若依角色与数据权限配置。
+
+---
+
+## 4.3 学员
+
+学员主要作为培训业务对象。
+
+一期根据实际页面需要提供本人：
+
+```text
+课程表
+报到结果
+住宿安排
+培训情况
+成绩
+```
+
+等查询能力。
+
+---
+
+# 5. 核心业务对象
+
+第二次会议以后，一期核心业务对象可以正式确定为：
+
+| 对象 | 含义 |
+|---|---|
+| 教师 | 培训授课人员 |
+| 学员 | 参加培训的人员 |
+| 课程 | 一项具体教学内容 |
+| 开班计划 | 一次完整培训班 |
+| 开班课程 | 本期培训包含哪些课程 |
+| 参训关系 | 某个学员参加某一期培训 |
+| 课次 | 某门课程在某时间的一次具体教学活动 |
+| 教室 | 普通教学空间 |
+| 实训场地 | VR、3D、实操等场地 |
+| 教学资源 | 文档、视频、VR、3D 等教学资源 |
+| 电子班牌 | 与具体教室关联的签到及课表设备 |
+| 宿舍 | 住宿资源 |
+| 床位 | 宿舍内具体可入住位置 |
+| 住宿安排 | 某参训学员本期住在哪里 |
+| 报到 | 某学员到达本期培训并完成确认 |
+| 门禁授权 | 学员在培训期间拥有的宿舍门禁权限 |
+| 考勤 | 针对具体课次产生的签到 / 签退记录 |
+| 学习记录 | 外部系统返回的自主学习记录 |
+| 成绩项目 | 本期需要计入成绩的课程或考核项目 |
+| 学员成绩 | 某学员在某成绩项目上的成绩 |
+| 统计结果 | 培训过程数据汇总结果 |
+| 学员画像 | 基于考勤、成绩、学习时长产生的简单综合分析 |
+
+---
+
+# 6. 核心业务关系
+
+本次会议已经明确：
+
+> 一个开班计划包含多门课程，并在开班前进一步安排教师、时间、教室和场地，形成课程表。
+
+因此正式业务模型调整为：
+
+```mermaid
+flowchart TD
+    P[开班计划]
+
+    P --> PC[开班课程]
+    C[课程] --> PC
+
+    P --> E[参训关系]
+    S[学员] --> E
+
+    PC --> L[课次]
+
+    T[教师] --> L
+    CR[教室] --> L
+    TS[实训场地] --> L
+
+    E --> ST[住宿安排]
+    D[宿舍 / 床位] --> ST
+
+    E --> R[报到]
+
+    ST --> DA[门禁授权]
+
+    E --> AT[考勤]
+    L --> AT
+
+    E --> LR[学习记录]
+
+    E --> SC[成绩]
+    PC --> SC
+
+    AT --> STAT[统计]
+    LR --> STAT
+    SC --> STAT
+
+    STAT --> POR[画像]
+```
+
+---
+
+# 7. 人员管理
+
+# 7.1 教师管理
+
+系统支持：
+
+```text
+新增
+查询
+修改
+停用 / 启用
+```
+
+教师基础信息以铁路培训业务实际需要为准。
+
+一期不强行使用：
+
+```text
+院系
+教授
+副教授
+讲师
+```
+
+等大学场景字段。
+
+---
+
+# 7.2 学员管理
+
+学员来源可能包括：
+
+```text
+管理员录入
+批量导入
+铁路内部业务平台导入
+```
+
+第二次会议明确提出，参训人员可能来源于铁路内部数据平台，同时一期先支持管理员录入和导入。
+
+一期至少实现：
+
+- 单个新增；
+- 编辑；
+- 查询；
+- 批量导入；
+- 人脸数据关联；
+- 身份证信息存储。
+
+---
+
+## 7.2.1 身份证保护
+
+身份证号码属于敏感信息。
+
+会议明确要求：
+
+> 数据库中不能直接保存明文，但业务未来仍可能使用，因此需要采用可逆加密方式保存。
+
+因此设计要求：
+
+```text
+数据库存储密文
++
+后端统一加密 / 解密
++
+前端默认脱敏展示
+```
+
+具体算法放入技术设计阶段确定。
+
+---
+
+## 7.2.2 学员状态
+
+由于系统面向短期培训，不再使用：
+
+```text
+休学
+退学
+```
+
+等学校学籍模型。
+
+会议倾向使用更加符合培训场景的状态，例如：
+
+```text
+正常
+请假
+培训完成
+```
+
+具体状态应尽可能作用于“参训关系”，不要把某一期培训状态永久写入学员主档案。
+
+---
+
+# 8. 培训资源管理
+
+一期需要统一维护培训使用的基础资源。
+
+---
+
+# 8.1 教室
+
+教室至少包含：
+
+```text
+教室名称 / 编号
+位置
+容纳人数
+状态
+```
+
+并能够关联电子班牌。
+
+---
+
+# 8.2 实训场地
+
+用于表示：
+
+```text
+VR室
+3D实训区
+实际操作场地
+其他培训区域
+```
+
+---
+
+# 8.3 宿舍
+
+住宿层级建议：
+
+```mermaid
+flowchart LR
+    A[楼栋]
+    --> B[楼层]
+    --> C[房间]
+    --> D[床位]
+```
+
+宿舍需要能够知道：
+
+```text
+总容量
+已入住人数
+剩余人数
+男女属性
+是否可用
+```
+
+第二次会议明确要求后续分配时能够看到当前房间入住及剩余情况。
+
+---
+
+# 8.4 教学资源
+
+教学资源用于课程关联。
+
+一期资源至少包括：
+
+```text
+文档
+视频
+3D模型
+VR资源
+外部教学链接
+其他资料
+```
+
+资源记录至少表达：
+
+```text
+资源名称
+资源类型
+访问地址
+说明
+```
+
+课程可以选择已有资源进行关联。
+
+---
+
+# 8.5 电子班牌设备
+
+电子班牌属于外部设备资源。
+
+至少需要维护：
+
+```text
+设备名称
+设备编号
+关联教室
+访问 / 接口信息
+状态
+```
+
+RailwaySystem 根据：
+
+```text
+教室
++
+课次
+```
+
+确定班牌当前应展示的课程信息。
+
+会议明确讨论了教室和电子班牌之间必须建立对应关系。
+
+---
+
+# 9. 课程管理
+
+课程回答：
+
+> **培训教什么。**
+
+---
+
+## 9.1 课程基本信息
+
+一期课程保留最必要字段：
+
+```text
+课程编码
+课程名称
+课程类型
+课程时长
+教学目标
+教学内容
+```
+
+---
+
+## 9.2 课程教学资源
+
+课程可以关联：
+
+```text
+文档
+视频
+3D模型
+VR
+实训资源
+其他外部资源
+```
+
+---
+
+## 9.3 一期删除的课程复杂功能
+
+第二次会议明确要求：
+
+> 不要把课程做得过于复杂，课程版本、草稿、归档、标签、热门、初级、进阶等一期都可以不做。
+
+因此 V1.0 删除：
+
+```text
+课程版本管理
+草稿 / 审核 / 发布 / 归档状态机
+课程标签
+热门标签
+初级 / 进阶分类
+复杂课程审批
+```
+
+课程一期只解决：
+
+> **课程是什么 + 使用什么教学资源。**
+
+---
+
+# 10. 开班计划
+
+开班计划表示：
+
+> **一次真正组织开展的培训班。**
+
+例如：
+
+```text
+沈阳铁路局2026年第1期综合培训班
+```
+
+---
+
+## 10.1 基本信息
+
+至少包括：
+
+```text
+开班名称
+开始时间
+结束时间
+培训地点
+招生 / 计划人数
+报名或参训条件
+报到截止规则
+备注
+```
+
+---
+
+# 10.2 一个开班包含多门课程
+
+本次会议已经明确：
+
+> 一个开班计划包含多门课程。
+
+因此正式关系为：
+
+```mermaid
+flowchart LR
+    P[开班计划]
+
+    P --> C1[课程A]
+    P --> C2[课程B]
+    P --> C3[课程C]
+```
+
+不能再在 `train_class_plan` 中简单使用单一：
+
+```text
+c_id
+```
+
+作为最终结构。
+
+数据库 V2 应通过独立关系表达：
+
+```text
+开班计划
+↔
+课程
+```
+
+---
+
+# 11. 参训人员管理
+
+本期培训确定以后，需要形成：
+
+> **本期到底有哪些学员参加。**
+
+会议明确讨论到需要通过一张独立关系记录：
+
+> “哪些人员参加哪个班”。
+
+因此“参训关系”升级为一期正式业务对象。
+
+---
+
+## 11.1 人员加入方式
+
+一期支持：
+
+```text
+管理员选择已有学员
+管理员单独录入
+Excel批量导入
+```
+
+未来可以支持：
+
+```text
+铁路内部系统同步
+```
+
+但一期不要求完整真实对接。
+
+---
+
+## 11.2 重复校验
+
+同一学员不能重复加入同一个开班计划。
+
+---
+
+# 12. 课次与课程表
+
+课次表示：
+
+> 某门课程在某天某个具体时间真正进行的一次教学活动。
+
+这是一期正式业务对象。
+
+---
+
+## 12.1 课次信息
+
+至少包含：
+
+```text
+所属开班计划
+所属课程
+授课教师
+开始时间
+结束时间
+教室
+或
+实训场地
+```
+
+---
+
+## 12.2 课程表生成
+
+一个开班计划的所有课次组合形成课程表：
+
+```mermaid
+flowchart TD
+    P[培训班]
+
+    P --> L1[9月20日 09:00 理论课]
+    P --> L2[9月20日 14:00 3D实训]
+    P --> L3[9月21日 09:00 VR巡检]
+
+    L1 --> T1[王老师]
+    L1 --> R1[201教室]
+
+    L2 --> T2[李老师]
+    L2 --> R2[实训区]
+
+    L3 --> T3[王老师]
+    L3 --> R3[VR室]
+```
+
+---
+
+## 12.3 冲突检查
+
+排课时需要检查：
+
+```text
+教师时间冲突
+教室时间冲突
+实训场地冲突
+同一培训班课次重叠
+```
+
+第一版可以采用：
+
+> 告警 + 管理员处理。
+
+不需要一期建设复杂自动排课算法。
+
+---
+
+# 13. 宿舍分配
+
+第二次会议基本确认：
+
+> 参训名单确定后，应在报到前完成宿舍预分配；学员报到以后直接看到已经安排好的宿舍，如有特殊情况管理员可以再调整。
+
+后续会议讨论再次确认了这一流程。
+
+---
+
+## 13.1 推荐流程
+
+```mermaid
+flowchart LR
+    A[参训名单确定]
+    --> B[生成住宿需求]
+
+    B --> C[系统推荐]
+    C --> D[管理员确认 / 调整]
+
+    D --> E[形成住宿安排]
+
+    E --> F[学员报到]
+    F --> G[直接展示住宿信息]
+```
+
+---
+
+## 13.2 分配原则
+
+一期可以支持基础推荐：
+
+```text
+男女分开
+同班学员优先安排临近房间
+同班同寝优先
+剩余床位优先
+```
+
+但不需要建设复杂智能分房算法。
+
+---
+
+## 13.3 不住宿
+
+部分学员可以：
+
+> **不住宿 / 走读。**
+
+不住宿不影响正常参加培训。
+
+---
+
+# 14. 报到管理
+
+学员到达培训基地后，通过：
+
+```text
+身份证
+或
+人脸识别
+```
+
+进行身份确认。
+
+---
+
+## 14.1 报到流程
+
+```mermaid
+flowchart TD
+    A[学员到达]
+    --> B[身份证 / 人脸识别]
+
+    B --> C{是否找到学员}
+
+    C -->|否| D[人工核验]
+    C -->|是| E[检查本期参训关系]
+
+    D --> E
+
+    E --> F{是否具备报到资格}
+
+    F -->|否| G[报到异常]
+    F -->|是| H[完成报到]
+
+    H --> I[显示课程表]
+    H --> J[显示宿舍]
+    H --> K[显示教室 / 场地]
+```
+
+---
+
+## 14.2 报到期限
+
+第二次会议确定：
+
+> 不使用全系统统一固定 X 天，而应在每个开班计划中配置。
+
+建议数据库最终使用：
+
+```text
+report_deadline
+```
+
+或者等价业务字段。
+
+---
+
+## 14.3 报到状态
+
+一期至少需要：
+
+```text
+未报到
+已报到
+请假
+放弃
+超期未报到
+```
+
+是否需要全部独立状态，可在数据库设计时根据状态模型进一步收敛。
+
+---
+
+# 15. 门禁授权
+
+宿舍安排和门禁授权是两个独立业务。
+
+```mermaid
+flowchart LR
+    A[住宿安排确定]
+    --> B[确定对应门锁]
+
+    B --> C[发送人脸 / 授权信息]
+    --> D[外部门锁系统]
+
+    D --> E[成功 / 失败结果]
+    --> F[RailwaySystem保存结果]
+```
+
+一期真实门锁不存在时使用 Mock。
+
+---
+
+# 16. 考勤管理
+
+考勤针对：
+
+> **具体课次。**
+
+而不是只记录：
+
+> “某学员参加过某门课程”。
+
+---
+
+## 16.1 自动来源
+
+主要由电子班牌等外部系统完成：
+
+```text
+人脸签到
+二维码签到
+签到
+签退
+```
+
+外部系统完成识别后，把结果返回 RailwaySystem。
+
+会议明确指出实际识别由其他系统完成，再将结果同步回来。
+
+---
+
+## 16.2 人工维护
+
+管理员 / 教师支持：
+
+```text
+补签
+修正
+人工新增
+```
+
+---
+
+## 16.3 统计
+
+后续应能够统计：
+
+```text
+某培训班整体出勤率
+某门课程出勤率
+某学员出勤率
+缺勤次数
+迟到情况
+全勤情况
+```
+
+会议明确提出考勤需要支持按培训班、课程和个人继续统计。
+
+---
+
+# 17. 成绩管理
+
+第二次会议以后，成绩模型正式调整。
+
+不再使用简单：
+
+```text
+课程成绩
+实训成绩
+考核成绩
+```
+
+三列固定模型作为最终数据库结构。
+
+---
+
+## 17.1 成绩项目
+
+一个培训班可以存在多个成绩项目：
+
+```mermaid
+flowchart TD
+    P[培训班]
+
+    P --> I1[课程A成绩]
+    P --> I2[课程B成绩]
+    P --> I3[VR实训成绩]
+    P --> I4[其他考核]
+
+    I1 --> W1[权重]
+    I2 --> W2[权重]
+    I3 --> W3[权重]
+    I4 --> W4[权重]
+
+    W1 --> S[综合成绩]
+    W2 --> S
+    W3 --> S
+    W4 --> S
+```
+
+---
+
+## 17.2 权重配置
+
+会议明确：
+
+> 不同培训班包含课程不同，因此成绩权重需要由用户自己设置，不能全系统固定。
+
+所以权重属于：
+
+> **开班级配置。**
+
+例如：
+
+```text
+安全理论    20%
+钢结构课程  30%
+VR实训      20%
+综合考核    30%
+```
+
+总权重应为：
+
+```text
+100%
+```
+
+---
+
+## 17.3 成绩来源
+
+支持：
+
+```text
+人工录入
+Excel导入
+外部实训系统接口
+```
+
+---
+
+## 17.4 一期不做补考
+
+第二次会议明确：
+
+> 一期暂不考虑补考。
+
+因此一期不设计：
+
+```text
+补考
+重考
+多次成绩择优
+```
+
+复杂逻辑。
+
+数据库可以避免完全锁死未来扩展，但不实现业务。
+
+---
+
+# 18. 学习数据接入
+
+RailwaySystem 不负责重新实现：
+
+```text
+电子阅览室
+桌面听书机
+VR
+3D拆解
+3D巡检
+其他自主学习应用
+```
+
+而是接收这些系统产生的数据。
+
+---
+
+## 18.1 学习记录
+
+至少需要：
+
+```text
+学员
+培训班
+课程 / 学习内容
+来源系统
+开始时间
+结束时间
+学习时长
+```
+
+会议明确提出：
+
+> 自主学习由外部应用自己记录使用时间，结束后将学习时长及相关记录返回 RailwaySystem。
+
+---
+
+# 19. 外部系统接口
+
+RailwaySystem 与外部系统的关系统一理解为：
+
+```mermaid
+flowchart LR
+    RS[RailwaySystem]
+
+    RS -->|人员 / 课程表 / 教室数据| EB[电子班牌]
+    EB -->|签到 / 签退| RS
+
+    RS -->|人脸 / 门禁授权| DL[智能门锁]
+    DL -->|授权结果| RS
+
+    VR[VR / 3D / 实训]
+    -->|学习时长 / 成绩| RS
+
+    INTERNAL[铁路内部业务平台]
+    -.未来人员数据.-> RS
+```
+
+---
+
+## 19.1 一期 Mock 原则
+
+当前真实接口不足时：
+
+```text
+真实接口
+↓
+使用 Mock Adapter 模拟
+```
+
+但必须保存真实业务记录。
+
+---
+
+## 19.2 数据输出
+
+第二次会议还提出：
+
+> 培训成绩、培训情况以及其他必要业务数据未来可能需要提供给其他系统使用。
+
+因此 API 设计阶段应考虑：
+
+```text
+RailwaySystem 对内 / 对外业务查询接口
+```
+
+但一期不需要提前建设复杂开放平台。
+
+---
+
+# 20. 统计分析
+
+一期统计主要围绕：
+
+```text
+开班计划
+课程
+学员
+```
+
+三个维度。
+
+---
+
+## 20.1 培训班统计
+
+包括：
+
+```text
+参训人数
+报到人数
+住宿人数
+整体出勤率
+各课程成绩
+综合成绩分布
+学习时长
+```
+
+---
+
+## 20.2 学员统计
+
+包括：
+
+```text
+个人出勤
+各课程成绩
+综合成绩
+学习总时长
+自主学习情况
+```
+
+---
+
+## 20.3 成绩下钻
+
+会议明确希望图表能够继续查看具体明细，例如：
+
+```text
+成绩区间
+↓
+对应哪些学员
+↓
+学员各门课程成绩
+```
+
+即：
+
+```mermaid
+flowchart TD
+    A[培训班成绩分布]
+    --> B[60分以上]
+
+    B --> C[学员名单]
+
+    C --> D[张三]
+    D --> E[课程A]
+    D --> F[课程B]
+    D --> G[实训]
+```
+
+并支持必要的数据导出。
+
+---
+
+# 21. 学员画像
+
+第二次会议明确认为：
+
+> 学员画像当前仍然属于不完全明确的需求。
+
+因此一期只做简单画像。
+
+---
+
+## 21.1 基础维度
+
+使用：
+
+```text
+出勤
+理论成绩
+实操成绩
+学习时长
+```
+
+---
+
+## 21.2 基础标签
+
+例如：
+
+```text
+出勤良好
+经常迟到
+理论成绩较好
+实操能力较强
+学习投入较高
+```
+
+一期不建设复杂规则引擎。
+
+---
+
+## 21.3 展示
+
+可以采用：
+
+```text
+基础雷达图
++
+简单标签
++
+主要指标
+```
+
+---
+
+# 22. 培训结束与历史数据
+
+本次会议后，结业逻辑简化。
+
+不再一期建设复杂：
+
+```text
+签到率 + 成绩 + 时长
+→ 自动结业规则引擎
+```
+
+---
+
+## 22.1 当前一期规则
+
+当前基本理解为：
+
+```mermaid
+flowchart LR
+    A[培训结束时间到达]
+    --> B[本期培训完成]
+
+    B --> C[参训记录进入历史]
+    B --> D[签到记录保留]
+    B --> E[学习记录保留]
+    B --> F[成绩保留]
+
+    C --> G[后续统计 / 画像仍可查询]
+```
+
+会议明确：
+
+> 培训结束后，本期学员的签到、成绩和实训等数据继续保留用于以后统计和查询。
+
+---
+
+## 22.2 暂不确定
+
+以下问题继续留到现场验证：
+
+```text
+是否存在培训合格 / 不合格
+是否需要培训证书
+具体及格线
+是否存在正式结业审批
+```
+
+一期不得自行复杂化。
+
+---
+
+# 23. 核心状态
+
+# 23.1 开班计划
+
+建议保持简单：
+
+```mermaid
+stateDiagram-v2
+    [*] --> 未开始
+    未开始 --> 进行中
+    进行中 --> 已结束
+
+    未开始 --> 已取消
+
+    已结束 --> [*]
+    已取消 --> [*]
+```
+
+是否保留独立“报名中”状态，在数据库 V2 状态设计时结合实际参训流程进一步决定。
+
+不要为了已有旧文档强行增加没有实际业务动作的状态。
+
+---
+
+# 23.2 参训关系
+
+建议：
+
+```text
+待报到
+已报到
+请假
+放弃
+已完成
+```
+
+超期可以采用：
+
+```text
+状态
+或
+异常标志
+```
+
+具体落库方式在数据库 V2 确定。
+
+---
+
+# 24. 页面结构建议
+
+建议后台页面尽量以业务为主，而不是以数据库表为主。
+
+```text
+智慧培训
+│
+├── 基础资料
+│   ├── 教师
+│   ├── 学员
+│   ├── 教室
+│   ├── 实训场地
+│   ├── 宿舍
+│   └── 教学 / 设备资源
+│
+├── 课程管理
+│
+├── 培训班管理
+│   ├── 开班计划
+│   ├── 本期课程
+│   ├── 参训学员
+│   ├── 课程表
+│   ├── 住宿安排
+│   └── 报到
+│
+├── 考勤管理
+│
+├── 成绩管理
+│
+├── 学习记录
+│
+├── 统计分析
+│
+└── 学员画像
+```
+
+---
+
+# 25. 培训班工作台
+
+为了减少管理员频繁跨菜单操作，推荐每个开班详情形成一个：
+
+> **培训班工作台**
+
+例如：
+
+```text
+钢结构综合培训第一期
+
+[基本信息]
+[课程]
+[参训人员]
+[课程表]
+[住宿]
+[报到]
+[考勤]
+[成绩]
+[统计]
+```
+
+这只是页面组织建议，不影响数据库模型。
+
+---
+
+# 26. 非功能要求
+
+## 26.1 数据持久化
+
+允许外部设备使用 Mock。
+
+但：
+
+> 培训、参训、住宿、报到、考勤、成绩、学习等业务数据必须真实持久化。
+
+---
+
+## 26.2 权限
+
+复用若依：
+
+```text
+用户
+角色
+权限
+数据权限
+```
+
+体系。
+
+不重新建设独立权限系统。
+
+---
+
+## 26.3 操作审计
+
+关键业务操作至少能够追踪：
+
+```text
+操作人
+操作时间
+业务对象
+操作类型
+```
+
+具体是否保存完整 before / after JSON 根据实际开发成本确定，不作为一期强制复杂要求。
+
+---
+
+## 26.4 代码可维护性
+
+第二次会议反复强调 AI 生成系统最大的风险在于：
+
+> 第一版可以生成 80%～90%，但后续细节修改可能非常困难，因此必须控制模块耦合和代码结构。
+
+开发要求：
+
+```text
+业务模块边界清晰
+Controller 不堆业务
+Service 负责业务逻辑
+不同模块通过清晰接口协作
+外部设备通过 Adapter 接入
+禁止大量跨模块直接修改数据库
+```
+
+---
+
+# 27. 一期完整验收场景
+
+一期最终至少能够完整演示以下业务。
+
+---
+
+## Step 1 基础资料
+
+管理员录入：
+
+```text
+教师
+学员
+课程
+教室
+实训场地
+宿舍
+教学资源
+电子班牌
+```
+
+---
+
+## Step 2 创建培训班
+
+创建：
+
+```text
+钢结构综合培训第一期
+```
+
+设置：
+
+```text
+培训时间
+报到截止时间
+计划人数
+```
+
+---
+
+## Step 3 添加多门课程
+
+例如：
+
+```text
+铁路安全理论
+钢结构检测
+VR巡检
+3D拆解
+```
+
+---
+
+## Step 4 添加参训人员
+
+通过：
+
+```text
+管理员选择
+或
+Excel导入
+```
+
+添加 30 人。
+
+---
+
+## Step 5 排课程表
+
+例如：
+
+```text
+9月20日 09:00 安全理论 王老师 201
+9月20日 14:00 3D拆解 李老师 实训区A
+9月21日 09:00 VR巡检 王老师 VR室
+```
+
+---
+
+## Step 6 分宿舍
+
+系统推荐后由管理员确认。
+
+张三：
+
+```text
+2号楼
+3层
+305
+1号床
+```
+
+李四：
+
+```text
+不住宿
+```
+
+---
+
+## Step 7 报到
+
+张三来到基地。
+
+通过：
+
+```text
+身份证
+或
+模拟人脸
+```
+
+识别。
+
+系统显示：
+
+```text
+住宿信息
+课程表
+教室
+实训场地
+```
+
+---
+
+## Step 8 门禁
+
+RailwaySystem 创建门禁授权。
+
+Mock 门锁返回：
+
+```text
+授权成功
+```
+
+---
+
+## Step 9 培训考勤
+
+Mock 电子班牌上传：
+
+```text
+张三
+9月20日上午安全理论
+签到成功
+```
+
+---
+
+## Step 10 自主学习
+
+Mock VR 上传：
+
+```text
+张三
+VR巡检
+开始 15:00
+结束 16:10
+学习70分钟
+```
+
+---
+
+## Step 11 成绩
+
+配置：
+
+```text
+安全理论 20%
+钢结构检测 30%
+VR实训 20%
+综合考核 30%
+```
+
+录入或 Mock 上传成绩。
+
+系统计算综合成绩。
+
+---
+
+## Step 12 统计
+
+展示：
+
+```text
+培训班整体出勤率
+课程成绩
+综合成绩分布
+个人成绩
+学习时长
+```
+
+并可下钻到具体学员。
+
+---
+
+## Step 13 画像
+
+生成简单：
+
+```text
+出勤指标
+理论指标
+实操指标
+学习时长
+基础标签
+```
+
+---
+
+## Step 14 培训结束
+
+培训结束以后：
+
+```text
+本期状态结束
+参训记录进入历史
+签到保留
+学习数据保留
+成绩保留
+```
+
+后续仍可以查询。
+
+---
+
+# 28. 当前仍需现场验证的问题
+
+第二次会议解决了大量 P0 问题，但以下内容依然不能视为甲方最终需求。
+
+| 编号 | 现场需要确认 |
+|---|---|
+| V-01 | 学员最终真实来源系统及数据字段 |
+| V-02 | 一期实际如何导入内部人员 |
+| V-03 | 宿舍是否分到具体床位还是只到房间 |
+| V-04 | 请假如何影响考勤统计 |
+| V-05 | 是否存在迟到 / 早退的具体判定规则 |
+| V-06 | 正式成绩项目有哪些 |
+| V-07 | 是否存在及格线 |
+| V-08 | 培训结束和“合格 / 结业”是否为两个概念 |
+| V-09 | 是否需要证书 |
+| V-10 | 学员画像最终需要哪些指标和标签 |
+| V-11 | 电子班牌真实接口及字段 |
+| V-12 | 智能门锁真实接口及字段 |
+| V-13 | VR / 3D / 阅览系统真实接口及字段 |
+| V-14 | 对其他系统需要开放哪些数据查询接口 |
+
+以上问题：
+
+> **不阻塞一期第一版开发，但开发时不能写死成不可修改的逻辑。**
+
+---
+
+# 29. 本版本相对 V0.9 的主要修改
+
+```text
+1. 一班一课 → 正式修改为一班多课。
+
+2. “参训关系”由设计建议升级为一期正式对象。
+
+3. “课次 Lesson”由默认假设升级为一期正式对象。
+
+4. 宿舍正式采用报到前预分配 + 后续人工调整。
+
+5. 支持不住宿学员。
+
+6. 报到逾期规则改为开班级配置。
+
+7. 成绩由固定三列改成“成绩项目 + 权重 + 学员得分”。
+
+8. 权重由培训班自行配置。
+
+9. 补考 / 重考一期删除。
+
+10. 课程版本管理删除。
+
+11. 课程草稿 / 审核 / 发布 / 归档流程删除。
+
+12. 课程标签、热门、初级、进阶删除。
+
+13. 画像规则引擎降级为简单指标 + 标签。
+
+14. 复杂结业判断删除。
+
+15. 培训结束以本期培训完成和历史数据保留为主。
+
+16. 明确电子班牌、人脸、门锁、VR 等属于外部系统。
+
+17. 明确一期继续采用 Mock 接口。
+
+18. 强调系统最小化和代码可维护性。
+```
+
+---
+
+# 30. PRD V1.0 之后的工作顺序
+
+第二次会议已经形成共识：
+
+> 业务先明确，然后把数据表、字段和 API 确定下来，再进入正式开发。
+
+所以接下来按照：
+
+```mermaid
+flowchart LR
+    A[PRD V1.0]
+    --> B[核心业务模型]
+
+    B --> C[数据库 V2]
+    B --> D[API 契约]
+
+    C <--> D
+
+    C --> E[数据库/API联合评审]
+    D --> E
+
+    E --> F[Epic / Issue]
+    F --> G[按业务模块分工]
+    G --> H[Agent开发]
+    H --> I[联调]
+    I --> J[内部完整流程测试]
+    J --> K[现场验证]
+```
+
+---
+
+# 31. 开发分工原则
+
+本次会议已经基本确认：
+
+> **不按照前端 / 后端 / 数据库拆人，而是按业务模块负责。**
+
+推荐方式：
+
+```text
+模块A
+人员 + 基础培训资源
+
+模块B
+开班 + 课程关系 + 参训 + 课程表 + 报到
+
+模块C
+宿舍 + 门禁 + 考勤
+
+模块D
+成绩 + 学习接入 + 统计 + 画像
+```
+
+每个模块负责人尽量覆盖：
+
+```text
+数据模型
+后端业务
+API
+前端页面
+基础测试
+```
+
+避免出现：
+
+```text
+前端只知道页面
+后端只知道接口
+数据库只知道表
+```
+
+最终没人真正理解完整业务。
+
+---
+
+# 32. PRD 冻结原则
+
+从 V1.0 开始：
+
+> **数据库、API、页面和开发任务以本 PRD 为业务主依据。**
+
+旧版：
+
+```text
+详细开发说明书
+railwaysystem.html
+旧数据库设计
+其他 AI 生成方案
+```
+
+只能作为：
+
+> **技术参考资料。**
+
+如果这些文档与本 PRD 冲突：
+
+> **以 PRD V1.0 为准。**
+
+其中合理的：
+
+```text
+Adapter
+参训关系
+课次
+模块解耦
+Mock接口
+```
+
+等设计思想，可以在后续技术设计阶段继续吸收。
+
+但不得因为旧文档已经写了某个复杂功能，就自动把它加入一期。