0 Fork 0

Files

T

wangzhibiao 9d053bf41f docs: 归档项目需求分析、一期开发说明书及Kingbase数据库审计报告

2026-09-13 23:16:37 +08:00

27 KiB

Raw Blame History

RailwaySystem 一期需求分析与业务基线 V0.1

文档状态： 内部评审稿 当前阶段： ①需求分析 / ②业务基线 本文依据：

《学员管理系统相关需求.md》

《学员管理系统功能分析_20260831.md》

《学员管理系统数据表设计_20260907_1_.md》

说明： 本文主要解决“系统做什么、业务怎么运行、有哪些核心业务对象、目前还有哪些问题没确定”。本阶段暂不确定数据库最终结构、API 路径、前端页面结构和具体代码实现。

一、需求分析

1.1 项目一期究竟要解决什么问题

RailwaySystem 一期并不是简单开发几个独立功能，例如“课程管理”“宿舍管理”“签到管理”。

这些模块最终都服务于同一件事情：

管理一次培训活动从准备、组织、报到、培训实施，到培训结束、统计分析和学员画像的完整过程。

因此整个系统应该首先从“培训全过程”理解，而不是从九个菜单理解。

一期总体业务流程

flowchart TD
    A[培训资源准备] --> B[创建开班计划]
    B --> C[确定参训学员]
    C --> D[安排教学与培训资源]

    D --> D1[教师]
    D --> D2[教室]
    D --> D3[实训场地]
    D --> D4[宿舍]
    D --> D5[课程表]

    D --> E[学员报到]

    E --> F[获取宿舍 / 教室 / 实训场地 / 课程表]
    F --> G[下发宿舍门禁权限]

    G --> H[正式开展培训]

    H --> I1[课程签到]
    H --> I2[VR / 3D / 实训]
    H --> I3[学习时长采集]
    H --> I4[成绩采集]

    I1 --> J[学习情况统计]
    I2 --> J
    I3 --> J
    I4 --> J

    J --> K[学员画像]
    K --> L[培训结束]
    L --> M[历史记录保留 / 权限失效]

因此，系统本质上管理的是：

某一批学员参加某一期培训，从培训准备到培训结束所产生的业务行为、培训资源和学习数据。

二、一期业务范围

一期需求可以从业务上分为四个层次。

flowchart LR
    A[基础资源层] --> B[培训组织层]
    B --> C[培训执行层]
    C --> D[培训结果层]

    A --- A1[教师]
    A --- A2[学员]
    A --- A3[课程]
    A --- A4[教室]
    A --- A5[实训场地]
    A --- A6[宿舍]

    B --- B1[开班计划]
    B --- B2[参训人员]
    B --- B3[教学安排]

    C --- C1[报到]
    C --- C2[住宿 / 门禁]
    C --- C3[签到]
    C --- C4[学习]
    C --- C5[成绩]

    D --- D1[统计分析]
    D --- D2[学员画像]
    D --- D3[历史记录]

可以简单理解为：

层级	回答的问题
基础资源	系统里有哪些人、课程和场地
培训组织	准备举办哪一期培训，谁参加
培训执行	学员来了以后发生了什么
培训结果	最后学得怎么样

三、一期确定功能

3.1 人员管理

人员分为两个核心对象：

flowchart TD
    A[人员管理] --> B[教师]
    A --> C[学员]

    B --> B1[基本资料]
    B --> B2[授课信息]
    B --> B3[授课履历]
    B --> B4[资质证书]
    B --> B5[在职 / 离职状态]

    C --> C1[基本资料]
    C --> C2[人脸数据]
    C --> C3[培训记录]
    C --> C4[学习记录]
    C --> C5[状态管理]

教师

教师主要承担培训授课职责。

当前需求包括：

教师基本信息；
授课信息；
授课履历时间轴；
教师资质证书；
证书到期提醒；
离职后账号冻结，但保留历史数据；
教师信息修改记录。

学员

学员是培训活动的主要参与者。

当前需求包括：

基本信息；
人脸数据；
Excel 批量导入；
课程及学习记录；
培训历史；
敏感信息保护；
生命周期学习轨迹。

四、课程管理

4.1 什么是课程

课程回答的是：

“教什么？”

例如：

钢结构检测基础
VR巡检实训
3D设备拆解
安全生产理论

课程本身不是某一次培训。

同一门课程理论上可以重复用于不同培训。

flowchart LR
    A[课程：钢结构检测] --> B[第一次开班]
    A --> C[第二次开班]
    A --> D[第三次开班]

课程内容

课程当前包括：

课程编码；
课程名称；
课程类型；
课程时长；
教学目标；
教学内容；
文档；
视频；
3D模型；
实训场景；
其他资源。

此外还要求：

flowchart LR
    A[课程] --> B[课程版本]
    A --> C[课程状态]
    A --> D[课程标签]
    A --> E[教学资源]

    C --> C1[草稿]
    C --> C2[待审核]
    C --> C3[已发布]
    C --> C4[已归档]

五、开班管理

5.1 什么是开班计划

课程解决：

教什么。

而开班计划解决：

什么时候真正组织一期培训。

例如：

钢结构检测培训2026年第1期

课程：钢结构检测
开始时间：2026-09-20
结束时间：2026-09-25
培训地点：培训基地
教师：王老师
招生人数：30人

当前业务关系可以暂时理解为：

flowchart TD
    A[课程] --> B[开班计划]

    B --> C[时间]
    B --> D[培训地点]
    B --> E[教师]
    B --> F[招生人数]
    B --> G[报名条件]

开班状态

当前需求定义：

stateDiagram-v2
    [*] --> 未开始
    未开始 --> 报名中
    报名中 --> 进行中
    进行中 --> 已结束

    未开始 --> 已取消
    报名中 --> 已取消

    已结束 --> [*]
    已取消 --> [*]

同时要求：

报名人数实时统计；
达到招生人数 90% 时提醒；
支持复制开班计划；
同一时间教师冲突告警。

六、参训人员

这里存在一个非常重要的业务概念。

假设系统里已经存在：

张三

这只能说明：

张三是一个学员。

不能说明：

张三参加了钢结构检测第一期。

这两个概念不同。

因此业务实际上应该存在：

flowchart LR
    A[学员：张三] --> C[参训关系]
    B[钢结构检测第一期] --> C

    C --> D[张三参加钢结构检测第一期]

这个“关系”后续会成为很多业务的基础。

因为：

flowchart TD
    A[张三参加某一期培训]

    A --> B[报到]
    A --> C[住宿]
    A --> D[门禁]
    A --> E[签到]
    A --> F[学习记录]
    A --> G[成绩]
    A --> H[画像]

因此建议后续业务模型中引入：

参训记录 / Enrollment

但需要特别说明：

“参训记录”是根据现有需求推导出来的业务建模建议，目前并不是原始需求明确规定的表名或功能名。

七、教学安排与课次

这是目前需求中另一个需要特别注意的问题。

需求明确规定：

学员报到完成以后，可以查看课程表。

那么系统必然要知道：

哪一天
几点到几点
上什么
谁来上
在哪里上

例如：

日期	时间	内容	教师	地点
9月20日	09:00-11:00	钢结构检测理论	王老师	201
9月20日	14:00-16:00	3D拆解实训	李老师	实训区A
9月21日	09:00-11:00	VR巡检	王老师	VR室

因此业务上实际上存在：

一次具体上课 / 一条课程表安排。

暂时称为：

课次 Lesson

flowchart TD
    A[开班计划] --> B[课次1]
    A --> C[课次2]
    A --> D[课次3]

    B --> B1[时间]
    B --> B2[教师]
    B --> B3[教室 / 场地]

    C --> C1[时间]
    C --> C2[教师]
    C --> C3[教室 / 场地]

    D --> D1[时间]
    D --> D2[教师]
    D --> D3[教室 / 场地]

为什么课次很重要

否则签到只能记录：

张三参加了“钢结构检测”

而无法准确表达：

张三参加了9月20日上午的钢结构检测课程
张三缺席了9月21日下午的实训

因此“课次”很可能是后续正式业务模型中的必要对象。

八、报到管理

8.1 报到不是简单的“刷脸”

完整业务应该理解为：

flowchart TD
    A[学员到达基地] --> B{身份证 / 人脸识别}

    B -->|识别成功| C[找到学员]
    B -->|识别失败| D[管理员人工核验]

    D -->|核验通过| C
    D -->|核验失败| E[报到失败]

    C --> F{是否属于当前培训}
    F -->|否| E
    F -->|是| G{是否具备报到资格}

    G -->|否| E
    G -->|是| H[完成报到]

    H --> I[记录报到状态和时间]

    I --> J[返回宿舍]
    I --> K[返回教室]
    I --> L[返回实训场地]
    I --> M[返回课程表]

报到状态当前定义为：

stateDiagram-v2
    [*] --> 未报到

    未报到 --> 已报到
    未报到 --> 请假
    未报到 --> 放弃

    请假 --> 已报到

    已报到 --> [*]
    放弃 --> [*]

其中具体状态是否允许反向变化，需要后续 PRD 再定义。

九、住宿与门禁

9.1 宿舍资源层级

当前需求希望宿舍细化为：

flowchart LR
    A[宿舍楼] --> B[楼层]
    B --> C[房间]
    C --> D[床位]

例如：

2号楼
  └── 3层
       └── 305房间
            ├── 1号床
            ├── 2号床
            ├── 3号床
            └── 4号床

宿舍状态

需求包含：

空置
部分入住
已满
维修中

9.2 住宿与门禁业务

住宿和门禁并不是同一个概念。

业务应该理解为：

flowchart TD
    A[学员参加某一期培训] --> B[分配宿舍 / 床位]

    B --> C[形成住宿安排]

    C --> D[取得对应门锁设备]

    D --> E[下发学员人脸]

    E --> F{下发成功?}

    F -->|成功| G[宿舍门禁权限生效]
    F -->|失败| H[记录失败]

    H --> I[重试]
    I --> E

    G --> J[培训结束 / 权限到期]
    J --> K[门禁权限失效]

因此业务上：

住宿安排决定“住哪里”。

门禁授权决定“能不能开门”。

后续数据库设计时不应该简单把两个概念完全混成一个东西。

十、签到管理

签到存在两个来源。

flowchart TD
    A[签到数据]

    B[电子班牌自动采集] --> A
    C[后台人工维护] --> A

    B --> B1[人脸签到]
    B --> B2[二维码签到]

    A --> D[重复签到过滤]
    D --> E[最终签到记录]
    E --> F[签到统计]

自动签到

主要来源：

电子班牌
→ 人脸识别
或
→ 二维码

人工签到

当：

设备故障；
数据漏采；
特殊情况；

管理员或教师可以进行人工维护。

重复数据

需求要求：

同一学员、同一课程一分钟内重复签到时，只保留第一条有效记录。

十一、学习数据采集

平台并不负责重新开发所有 VR、3D 和阅览系统。

这些属于外部系统。

RailwaySystem 的职责主要是：

接收、存储、整理这些系统产生的数据。

外部学习数据流

flowchart LR
    A1[电子阅览室] --> F[RailwaySystem]
    A2[桌面听书机] --> F
    A3[VR实训] --> F
    A4[3D拆解] --> F
    A5[3D巡检] --> F
    A6[实操系统] --> F

    F --> G[原始学习记录]
    G --> H[学习时长统计]
    G --> I[异常检测]

    I -->|正常| J[进入统计]
    I -->|异常| K[管理员审核]

学习记录至少需要表达：

谁学习
使用什么系统
什么时候开始
什么时候结束
学习了多久

十二、成绩管理

12.1 成绩来源

成绩不是只有教师手动输入。

目前有三种来源：

flowchart TD
    A1[管理员 / 教师手动录入] --> D[成绩中心]
    A2[Excel批量导入] --> D
    A3[外部系统自动采集] --> D

    A3 --> B1[VR]
    A3 --> B2[3D巡检]
    A3 --> B3[实操系统]

    D --> E[课程成绩]
    D --> F[实训成绩]
    D --> G[考核成绩]

    E --> H[综合成绩]
    F --> H
    G --> H

成绩状态

stateDiagram-v2
    [*] --> 草稿
    草稿 --> 已提交
    已提交 --> 已发布

    已提交 --> 草稿 : 退回修改

    已发布 --> 修改审批 : 需要修改
    修改审批 --> 已发布 : 审批完成

当前已经确定：

成绩有草稿、提交、发布状态；
发布后不能直接修改；
修改需要审批；
需要保存历史版本；
支持综合成绩计算。

但权重还没有确定。

十三、统计分析

统计不是新的原始数据。

它是对前面业务数据的加工。

flowchart TD
    A[签到记录] --> E[统计分析]
    B[学习记录] --> E
    C[成绩记录] --> E
    D[开班信息] --> E

    E --> F[签到率]
    E --> G[学习总时长]
    E --> H[平均成绩]
    E --> I[课程成绩分析]
    E --> J[班级培训情况]

目前确定需要支持：

学员各系统学习时长；
学员各课程签到情况；
学员各课程成绩；
各课程学员成绩；
时间范围筛选；
数据导出；
图表下钻；
同比 / 环比。

十四、学员画像

画像是整个培训数据链的最终结果之一。

它不应该凭空生成。

flowchart TD
    A[签到数据] --> E[学员画像]
    B[理论成绩] --> E
    C[实操成绩] --> E
    D[学习时长] --> E

    E --> F[雷达图]
    E --> G[画像标签]
    E --> H[综合描述]
    E --> I[历史画像快照]
    E --> J[学习资料推荐]

例如：

张三

签到率：96%
理论成绩：75
实操成绩：92
学习投入：较高

画像：

实操能力强
出勤良好
理论能力有待提升

画像需求目前已经确定。

但画像计算算法还没有完全确定。

十五、系统权限

一期基础角色包括：

flowchart TD
    A[系统用户]

    A --> B[管理员]
    A --> C[教师]
    A --> D[学员]

    B --> B1[系统和业务管理]
    C --> C1[授课相关业务]
    D --> D1[本人培训相关信息]

系统采用：

用户
→ 角色
→ 权限

的 RBAC 模型。

同时需要支持：

数据权限；
操作日志；
敏感操作审计；
登录安全。

十六、一期明确不包含的内容

以下属于二期：

flowchart LR
    A[二期]

    A --> B[平板端基地控制]
    A --> C[平板人脸签到]
    A --> D[实训工位分配]
    A --> E[帽石系统]
    A --> F[钢结构监测]
    A --> G[智慧照明]
    A --> H[智能工具箱]
    A --> I[数字孪生]
    A --> J[电工实训箱]
    A --> K[基地驾驶舱]
    A --> L[摄像机调阅]

这些功能不应该因为开发过程中“顺手可以做”就进入一期。

如果甲方要求增加，需要作为：

需求变更

单独确认。

十七、一期核心业务对象

目前能够识别出的主要对象如下。

分类	业务对象	含义
人员	教师	承担培训授课的人员
人员	学员	被管理的培训人员
教学	课程	描述“教什么”
培训	开班计划	描述“一次具体培训”
培训	参训关系	描述“谁参加哪一期”
教学	课次	描述“具体什么时候上一次课”
资源	教室	普通教学空间
资源	实训场地	VR、3D、实训空间
住宿	宿舍 / 床位	培训期间住宿资源
执行	报到	学员到场确认
执行	门禁授权	培训期间的宿舍进入权限
执行	签到	课程出勤记录
数据	学习记录	外部系统使用记录
数据	成绩	各类考核结果
分析	统计结果	对培训数据汇总
分析	学员画像	综合学习分析

十八、核心业务对象关系图

这是目前整个系统最重要的一张图。

flowchart TD
    T[教师]
    S[学员]
    C[课程]
    P[开班计划]

    E[参训关系]
    L[课次 / 教学安排]

    CR[教室]
    TS[实训场地]

    R[报到]
    ST[住宿安排]
    DA[门禁授权]

    AT[签到]
    LR[学习记录]
    SC[成绩]

    STAT[统计分析]
    POR[学员画像]

    C --> P
    T --> P

    S --> E
    P --> E

    P --> L
    T --> L
    CR --> L
    TS --> L

    E --> R
    E --> ST
    ST --> DA

    E --> AT
    L --> AT

    E --> LR
    E --> SC

    AT --> STAT
    LR --> STAT
    SC --> STAT

    STAT --> POR

这张图可以概括整个一期系统：

课程和教师支撑开班；学员通过参训关系加入开班；开班形成教学安排；学员报到以后进入住宿、签到、学习和成绩流程；最终形成统计和画像。

十九、当前数据库设计与业务需求的差异

当前数据库只能作为早期设计草案。

不能因为已经存在数据库表，就反过来改变业务需求。

19.1 开班状态不一致

功能需求：

未开始
报名中
进行中
已结束
已取消

当前数据库：

未开始
进行中
已结束
已取消

缺少：

报名中

19.2 报到状态不一致

需求：

未报到
已报到
请假
放弃

当前数据库：

未报到
已报到
请假未到

缺少：

放弃

19.3 宿舍模型不够完整

需求希望：

楼栋
→ 楼层
→ 房间
→ 床位

现有数据库主要还是：

宿舍房间
+
床位数量

两者存在差距。

19.4 学员 / 教师字段仍偏学校模型

当前部分字段使用：

学号
院系
专业
班级
讲师
副教授
教授

但当前系统实际上面向：

培训基地在职人员培训

因此是否继续使用大学教育场景字段，需要重新确认。

19.5 当前缺少明确参训对象

目前：

学员
开班计划

之间缺少一个明确表达：

“这个人参加了这一期培训”

的核心对象。

19.6 当前缺少明确课次对象

签到表直接保存：

本节课程开始时间
本节课程结束时间

这说明系统事实上已经需要表达一次具体上课。

但是目前并没有独立教学安排 / 课次对象。

19.7 成绩模型尚未定型

当前简单使用：

课程成绩
实训成绩
考核成绩

三个字段。

但需求已经出现：

权重；
发布状态；
历史版本；
外部系统成绩；
修改审批。

因此后续成绩模型需要重新设计。

二十、目前建议明确建模的两个关键概念

20.1 参训关系 Enrollment

flowchart LR
    S[学员] --> E[参训关系]
    P[开班计划] --> E

    E --> A[报到]
    E --> B[住宿]
    E --> C[签到]
    E --> D[学习]
    E --> F[成绩]

推荐原因：

很多数据并不是属于“张三这个人”，而是属于“张三参加某一期培训”。

20.2 课次 Lesson

flowchart LR
    P[开班计划] --> L[课次]

    L --> A[日期]
    L --> B[开始时间]
    L --> C[结束时间]
    L --> D[教师]
    L --> E[教室]
    L --> F[实训场地]

    L --> G[签到]

推荐原因：

签到应该尽可能针对一次真正发生的教学活动，而不是只针对课程名称。

这两个对象属于：

当前业务推导出的建议模型。

不能直接视为甲方已经明确要求的表结构。

二十一、P0：进入正式设计前必须确认的问题

以下问题如果不确定，会直接影响数据库和系统结构。

P0-01 一个开班计划究竟是一门课程还是多门课程？

当前材料

目前更接近：

flowchart LR
    A[课程A] --> B[开班计划A]

也就是：

一个开班计划对应一门课程。

另一种现实情况可能是

flowchart TD
    A[铁路综合培训第一期]
    A --> B[课程A]
    A --> C[课程B]
    A --> D[课程C]
    A --> E[课程D]

如果实际是后一种，那么：

数据库；
课表；
教师；
签到；
成绩；

都会发生结构性变化。

必须确认

一个培训班究竟能不能包含多门课程？

P0-02 学员如何进入培训班？

当前缺少明确规则。

flowchart TD
    A[学员进入某一期培训]

    A --> B[管理员手动添加?]
    A --> C[Excel批量导入?]
    A --> D[学员自行报名?]
    A --> E[报名后管理员审核?]
    A --> F[外部系统下发名单?]

必须确认哪些是真实业务。

P0-03 课程表怎么形成？

需要确认：

flowchart TD
    A[课程表]

    A --> B[是否存在多次课次?]
    A --> C[每次是否有独立时间?]
    A --> D[每次是否指定教师?]
    A --> E[每次是否指定教室?]
    A --> F[每次是否指定实训场地?]

这个问题决定：

是否正式建立“课次 Lesson”。

P0-04 宿舍什么时候分配？

可能存在三种业务：

flowchart TD
    A[宿舍分配]

    A --> B[报到前预分配]
    A --> C[报到时自动分配]
    A --> D[报到后管理员现场分配]

同时需要确认：

是否所有参训学员都必须住宿？

P0-05 “开班后 X 日未报到”中的 X 是多少？

当前需求存在：

flowchart LR
    A[开班] --> B[X日内未报到]
    B --> C[取消参训资格]
    C --> D[释放宿舍]

但是：

X 尚未确定。

P0-06 综合成绩怎么算？

当前确定支持权重计算。

但具体规则未知。

例如：

flowchart TD
    A[综合成绩]

    B[课程成绩 ?%] --> A
    C[实训成绩 ?%] --> A
    D[考核成绩 ?%] --> A

需要确认：

比例；
是否所有课程相同；
是否允许课程自己配置。

P0-07 什么叫“培训完成 / 结业”？

可能有：

flowchart TD
    A[结业判断]

    A --> B[培训结束即结业?]
    A --> C[成绩合格?]
    A --> D[签到率达标?]
    A --> E[学习时长达标?]
    A --> F[管理员人工确认?]

这个问题会影响：

学员状态；
门禁失效；
成绩；
统计；
历史记录。

因此必须确认。

二十二、P1：PRD 阶段继续确认的问题

这些问题不会立即推翻总体数据结构，但会影响业务规则。

编号	问题
P1-01	教师时间冲突后，是禁止保存还是允许强制保存？
P1-02	招生人数是不是绝对上限？
P1-03	请假是否计入签到率分母？
P1-04	是否支持补考、重考或多次实训成绩？
P1-05	异常学习数据在审核前是否进入统计？
P1-06	学员画像不同指标如何换算成统一分值？
P1-07	学习资料“推送”采用系统内展示还是外部消息？

二十三、当前一期业务基线

截至 V0.1，可以暂时冻结以下认识：

RailwaySystem 一期围绕 一次培训全过程 展开。
课程描述“教什么”。
开班计划描述“一次具体培训”。
学员是长期存在的人员档案。
学员参加某一期培训以后，才会产生该期的报到、住宿、签到、学习和成绩。
业务上需要明确表达“某个学员参加某一期培训”。
报到是培训正式执行阶段的重要入口。
报到完成后，需要获得宿舍、教室、实训场地和课程表。
宿舍安排会进一步触发宿舍门禁授权。
培训期间最重要的三类学习数据是：

签到
学习时长
成绩

数据既可能人工产生，也可能由电子班牌、VR、3D 等外部系统产生。
培训过程数据最终进入统计分析。
学员画像建立在签到、成绩、实训和学习时长等数据基础之上。
开班计划是目前大多数培训业务的重要上下文。
当前数据库属于早期设计草案，应当在业务确认以后重新调整。
“参训关系”和“课次”是目前最值得进一步确认和正式建模的两个业务概念。
二期平板、数字孪生、智慧控制等内容不进入一期。

二十四、一期完整业务骨架

最终，当前一期可以用下面这张图整体表示。

flowchart TD

    subgraph A[基础资源]
        A1[学员]
        A2[教师]
        A3[课程]
        A4[教室]
        A5[实训场地]
        A6[宿舍 / 床位]
    end

    subgraph B[培训组织]
        B1[开班计划]
        B2[参训人员]
        B3[课次 / 课程表]
    end

    subgraph C[培训执行]
        C1[报到]
        C2[住宿安排]
        C3[宿舍门禁]
        C4[课程签到]
        C5[VR / 3D / 实训]
        C6[学习时长]
        C7[成绩]
    end

    subgraph D[培训结果]
        D1[统计分析]
        D2[学员画像]
        D3[历史记录]
    end

    A1 --> B2
    A2 --> B1
    A3 --> B1

    B1 --> B2
    B1 --> B3

    A2 --> B3
    A4 --> B3
    A5 --> B3

    B2 --> C1

    C1 --> C2
    A6 --> C2

    C2 --> C3

    B3 --> C4
    B2 --> C4

    B2 --> C5

    C5 --> C6
    C5 --> C7

    C4 --> D1
    C6 --> D1
    C7 --> D1

    D1 --> D2
    D2 --> D3

二十五、当前开发阶段所处位置

目前项目应该处在：

flowchart LR
    A[原始需求] --> B[①需求分析]
    B --> C[②业务基线]
    C --> D[确认P0问题]
    D --> E[PRD]
    E --> F[业务模型 / 状态设计]
    F --> G[数据库V2]
    G --> H[API / 页面设计]
    H --> I[Epic]
    I --> J[Issue]
    J --> K[开发]
    K --> L[联调测试]
    L --> M[Demo / 反馈]

    style B stroke-width:3px
    style C stroke-width:3px
    style D stroke-width:3px

当前：

①需求分析和②业务基线已经形成第一版。

下一步不是立即开始大规模开发。

而应该首先：

集中确认 P0 问题。

二十六、①②阶段完成标准

当前阶段完成以后，至少应该能够回答：

系统为什么做？

能够明确：

RailwaySystem 是一个培训基地全过程管理系统。

系统管理什么？