最初想做怎样的教育机构系统

线下培训机构管理涉及一组相互关联的业务规则：机构发布课程模板并排定班级课次，学员按课程购买课时，家长经授权代办学习事务。系统需要记录课时、资金、名额与考勤，并处理它们在报名、上课和退费时的变化。

教育机构管理系统在规划之初，以毕业设计为开发背景，围绕线下培训的这些教务流程确定功能范围。

1. 业务定位：通用型线下培训的管理边界

在 2025 年底立项时，系统被定位为面向语言、编程、艺术、K12 或职业培训等通用场景的线下培训管理系统。为了在有限的开发周期内构建出坚实的业务主干，系统在需求起点便明确划定了清晰的业务边界：

• 核心聚焦：多角色协同（机构管理员、教师、学员、家长）、课程与班级排课、教室场地管理、报名与订单支付、考勤点名、请假调课、课时钱包与退费结算、学习报告与通知流转；
• 显式排除项：明确不做在线实时视频直播教学、试听课裂变营销、复杂电子合同签署、站内即时聊天（IM），以及跨课程的“通用课时包”。

其中，**“购买的课时专属于特定课程，不可跨课通用”**是一条关键的业务假设。学员购买了《少儿编程中阶班》的 20 课时，该权益仅能在该课程及其合规的换班流程中消耗，不能直接折算成机构内部的通用代币随意上其他课程。这一规则极大简化了早期的课时核算模型，避免了复杂的跨学科课时价值换算。

2. 角色与业务入口的解耦

系统设计了四类角色，但并未简单地对应四个完全孤立的网站，而是收敛为三个主要的业务门户：

在账号体系上：

• 管理员与教师：由机构自上而下添加并分配初始账号与职责；
• 学员：通过开放注册自主创建档案；
• 家长：注册后向学员发起绑定申请，经学员确认授权后才能接入该学员的学习视图。确认可以激活待激活账号，但不能解除已有的账号冻结状态。

这一机制把家长访问学员信息的依据放在已确认的绑定关系上，不能仅凭手机号获得访问权。

3. 课程体系的四层对象模型

在线下教务建模中，最容易混淆的概念是“课程”到底指什么。是一门叫《初级英语》的学科，还是张老师每周二晚上带的那个班，亦或是下周二晚上的那一节课？

为了区分这些对象，系统采用了四层课程模型：

1. 课程类别（Category）：最顶层的培训方向划分（如“少儿编程”、“艺术绘画”）；
2. 课程模板（Course Template）：定义某一标准化产品的规格基准，包括适用等级、班型（一对一/小班/大班）、基准定价与总课时数。同模板下的所有开班实例均遵循相同的课时与定价体系；
3. 开班实例（Course Instance / Class）：基于某一模板实际招生的具体班级（如“2026春季少儿编程1班”），绑定指定的授课教师、开班日期与已报名学员名单；
4. 排课课次（Course Schedule / Session）：班级在某一具体时间段、使用指定教室上课的原子单元（如“2026-03-10 18:30~20:00 在 302 教室”）。

这四层分别表达培训方向、课程规格、实际班级和每次上课安排。同一个模板可以开设多个平行班，同一班级的不同课次也可以使用不同教室；后续的排课调整就有了明确的修改对象。

4. 关键业务口径的清晰界定

在业务规则层面，系统在初期就明确了若干易混淆概念的物理边界：

4.1 班型容量不等于教室容量

• 班型容量（Class Capacity）：由课程模板决定（如小班上限 10 人，大班上限 40 人），代表该班最多招收的正式学员总人数；
• 教室容量（Room Capacity）：由物理场地的实际座位数决定（如 101 教室容纳 15 人，大礼堂容纳 50 人）。

一个小班即使临时安排在大礼堂上课，其招生上限依然受限于 10 人班型，绝不会因为场地变大而自动超额招生；反之，若班级人数已达 10 人，系统严禁将其安排至仅有 8 个座位的微型研讨室。

4.2 课时权益、订单金额与钱包资金的隔离

• 总课时与剩余课时：衡量学员享有的纯教学服务权益（如总 20 课时，已上 5 课时，剩余 15 课时）；
• 订单金额（Order Amount）：某次报名交易约定的应付金额；
• 钱包可用余额与冻结余额：可用余额可用于支付新课程；申请提现后，处理中对应的金额进入冻结余额，不可重复用于支付。课程退款另有金额计算与审核流程。

这些区分决定了后续流程操作什么对象：报名检查班级名额，排课检查具体教室，付款记录订单和钱包变化，上课与请假再影响课时权益。把对象和口径分开，才能继续讨论它们之间的联动。