直接答案：课程是「卖什么」，班级是「谁和谁一起上」，课次是「什么时候上、在哪里上、谁上」。三层混成一层，最直接的后果是改一次上课时间要把全班学员的记录都改一遍，而一旦漏改一个，这个学员的课时就会算错。三层分开建模之后，改课次只动课次表，学员账户只记「扣了几节」，两边互不影响。判断一套教务系统能不能用，就看它能不能在不改动学员合同的前提下，调整一次上课时间、换一个老师、合并两个班。
核心结论速览
课程是商品，班级是容器，课次是时间点。课程定义教什么、总共几课时、单课时多长、适合什么年龄段；班级定义这一批学员一起上课；课次定义某天某时某教室某老师。三者是一对多的关系，方向不能反。
学员买的是课程，上的是班级，扣的是课次。这三条关联必须都能查到：买了哪个课程包、在哪个班、已经上了哪几节、还剩几节。少一条，家长来问就答不上来。
课次从班级批量生成，不手工一条条建。班级设好「每周几、几点、共几周」，系统一次生成整学期课次，之后单独调整某一节。手工建课次的系统，一个学期二十个班就是四百条记录，没人维护得住。
课次状态至少五种：待上、已上、已取消、已调课、已完成。只有「已上」和「已完成」才扣课时，取消和调课不扣。状态少一种，扣课时就一定有算错的地方。
班级之间不共享学员。学员调班是「退出原班、加入新班」两个动作，不是把班级字段改一下。直接改字段的系统，查不出这个学员在原班待过多久、上过几节。
一、三层混在一起之后现场会发生什么
场景一：改一次上课时间，全班合同都要改。因为课次信息被直接写进了学员的课时记录里，把周六上午改成周日上午，等于要改这个班二十个学员的记录。改到第十五个的时候有人打电话来，剩下的忘了改，第二周这五个学员就按老时间去上课。三层分开之后，改课次只改一条记录，学员账户根本不知道有这回事。
场景二：中途插班，前面几节算不算。新学员在第四节课插进来，前三节他没上，课时怎么扣？如果班级和课次是同一张表，系统只会从第一节开始算，插班生的课时一进来就少三节。正确做法是按插班日期计算应扣课次，前面不补不扣，并且这条要在报名时写进须知。
场景三：同一个课程开了三个班，报表算不准。想知道「少儿编程这个课程卖得怎么样」，得看课程维度的销量；想知道「哪个班快满了」，得看班级维度的报名率。两层混在一起，两个指标都会算歪——课程销量会把同一个学员的转班算成两次销售，满班率会因为班容和课程总课时混淆而失真。
场景四：换老师之后历史课酬跟着变。课次里的老师如果只是一个文本字段，把名字改成新老师，这个班过去十节课的课酬也变成了新老师的。做法是课次上同时记「计划教师」和「实际授课教师」，课酬按实际授课教师算，已经结算过的课次锁定不动。
场景五：两个班合并，学员课时对不上。秋季班只有四个学员，要并到春季班。如果直接改班级名，原班的剩余课次消失了，学员课时却还在，两边对不上。合并的正确做法是三步：取消原班未上课次、在新班生成对应课次、把学员转到新班，课时余额不变，只改关联。
场景六：试听学员占了正式学员的座位。试听学员没有课时账户，但确实坐在教室里。班容校验如果只看正式学员，试听一多就超员，正式学员没座位。座位数要按「正式加试听」算，试听转正时再补建课时账户。
二、课程、班级、课次三张表的字段怎么定
课程表。课程名、课程编码、科目品类、适用年龄段、总课时数、单课时长（分钟）、课程包售价、有效期（月）、是否允许插班、最少开班人数、最大班容、教材或教具、课程简介、上下架状态。课程编码很重要，它是后面所有统计的主键，不要用课程名当编码——名字会改，编码不能改。
班级表。班级名、所属课程、期次、班主任、主教师、默认教室、开班日期、结班日期、计划课次数、已生成课次数、班容、已报名人数、班级状态。班级名建议用「课程名加期次加时段」的组合，比如「少儿编程2026春季周六上午」，这样在前台和老师端一眼能看出是哪个班。
班级状态要有五个。筹备（还没开始招生）、招生中、已开班、已结班、已取消。取消和结班是两件事：结班是正常结束，取消是没开起来。混成一个「结束」状态，后面做开班率分析时算不出来。
课次表。课次序号、所属班级、上课日期、开始时间、结束时间、教室、计划教师、实际授课教师、助教、课次状态、是否开放试听、备注。课次序号从班级计划课次数里来，第一节是 1，最后一节等于计划课次数。序号是后面算「上到第几节」的依据。
学员课时账户表。学员、课程、购买课时数、赠送课时数、已用课时、剩余课时、有效期起止、当前所在班级。注意「已用课时」要拆成买课已用和赠课已用两个字段，否则退费时算不清赠课用了多少。
考勤记录表。课次、学员、考勤状态、签到时间、扣课时数、操作人、操作时间。考勤是课时的单一扣减依据，所以它必须挂在具体的课次上，不能只挂班级。
三、课次生成、调整和状态流转
批量生成的规则。班级设好起止日期和周几，系统按周循环生成课次，遇到节假日可以跳过或顺延。生成时要做两件事：一是校验教师和教室的时间冲突，二是核对生成的课次数是否等于计划课次数。少生成了，后面扣课时会对不上。
单节调整的五个动作。改时间、换教室、换老师、取消、加课。每个动作都要留一条变更记录：原值、新值、原因、操作人、是否已通知学员。这条记录在家长质疑「为什么这周改到周日下午」时是主要依据。
课次状态的流转。待上到已上是到时间后自动或手动标记；已上到已完成是考勤全部登记完；待上到已取消是这节不上了，不扣课时；待上到已调课是这节改到别的时间，原课次不扣课时，新生成的课次才扣。这四条路径之外不要随便加，加一条就多一种算错的可能。
扣课时的时点有两种口径。一种是按「课次已上」扣，不管学员来没来，缺勤也扣；一种是按「实际出勤」扣，没来不扣。教培行业普遍用前者，因为老师已经付出了教学成本，场地也已经占了。这条口径必须在报名须知里写清楚，写在合同附件里比写在宣传页上有效。
补课怎么记。补课不重复扣课时，它的本质是「用掉一次待补课额度」。补课记录要同时挂到原课次和补课课次两个地方：原课次上标「已补课」，补课课次上标「补课出勤」。只挂一边，月底统计出勤率就会算错。
整班停课和顺延。停课不是删课次，是把课次置为已取消，并在停课结束后生成新的课次。顺延是把所有待上课次整体后移。两种做法都要重新做一次冲突校验，因为顺延之后很可能撞上别的班。顺延时课时有效期要不要跟着延，要有明确规则，通常是要延，否则学员的课时会凭空过期。
四、四个高频冲突场景怎么判
场景一：学员中途插班。判断依据是插班日期，不是班级第一节。系统按「插班日期之后的课次数」计算应扣课时，插班之前的课次不生成扣课记录。插班费、教材费这些一次性费用单独收，不进课时账户。插班还要校验该学员其他班的时间有没有冲突，这一点在排课那一环就要做。
场景二：一个学员同时报了两个课程。允许，但两个课程的课时账户要分开记。不能合并成一个「总课时」，因为两个课程的有效期、单价、退费规则都不一样。合并账户的系统，退其中一个课程时算不出该退多少。学员维度的时间冲突校验要覆盖他所有在报的班级。
场景三：转班。转班是两个动作：退出原班、加入新班。课时余额不变，但关联班级变了。如果两个班的课程单价不同，要么补差价，要么按课时折算，两种做法都要留一条流水记录。转班不能直接改班级字段，否则查不出这个学员曾经在哪个班、上过几节。
场景四：合班。合班要按「取消原班剩余课次、在新班生成对应课次、转移学员」三步做。转移之后，学员的课时账户不变，但课次归属变了。合班必须留记录，否则家长问「我们班怎么突然多了这么多人」时，前台只能凭印象回答。
场景五：试听学员转正。试听期间不建课时账户，只占座位。转正时补建账户，扣课时从转正那节课开始，试听的几节不扣。这条规则对成交有帮助——试听不消耗课时，家长的心理负担小。但座位数要按正式加试听算，否则试听一多，正式学员反而没位置。
判断标准可以归成一句话：任何一个学员，都要能在系统里拉出一条完整的时间线——什么时候报的什么课、进了哪个班、上了哪几节、请过几次假、补过几次课、现在还剩几节。这条线拉不出来，教务就永远在靠记忆和纸质记录补漏。
五、常见问题解答
一个课程能不能拆成几个阶段卖？
可以，做法是把每个阶段建成独立的课程，用「课程系列」字段把它们串起来，而不是在一个课程里设多个阶段。因为每个阶段的课时数、单价、有效期可能都不一样，塞在一个课程里，退费和转阶段都算不清。用系列串起来之后，既能单独售卖，又能看出这个学员在系列里读到第几阶段。
课次能不能手工建？
能，但要限制用途。手工建课次只用于三种情况：临时加课、补课、一对一单独排课。整班的常规课次必须从班级批量生成，否则会出现「计划二十节实际建了十八节」这种对不上的情况。手工建课次时要在备注里写原因，方便后面复盘。
班容满了还能插班吗？
看班容的性质。班容分「硬容量」（教室座位数、教具数量决定的物理上限）和「软容量」（教学效果考虑的理想人数）。硬容量不能超，超了就没座位；软容量可以超，但要有审批。系统层面建议两个字段分开设，报名时硬容量拦截，软容量提示并要求填写理由。
一个班两个老师，课次怎么记？
课次上设主教师和助教两个字段，主教师参与排课冲突校验，助教可选是否参与。课酬分开算：主教师按自己的口径，助教按主教师的百分比或者固定金额。如果两个老师是轮流主讲（比如单双周），那就按课次分别指定实际授课教师，不要用「主教师」一个字段笼统带过。
学员请假后课时有效期要不要延？
建议延，但设上限。做法是延期天数等于请假天数，一个课程包最多延一定天数（比如三十天）。不延的话，学员请一个月假回来发现课时过期了，这是投诉高发点；不设上限的话，有人会一直请假一直延，机构的排课和教室资源被长期占用。
课程改名会不会影响历史数据？
不会，前提是改名不改课程编码。所有报表和关联都用编码，名字只是展示。如果系统用课程名做关联，一改名历史订单和课次就全部断链。这也是为什么课程表一定要有编码字段，而且编码一经生成不再修改。
试听课要不要建课次？
要建。试听课也是课，占教室、占老师时间、占座位。建课次的好处是：老师能看到这节有试听、教室不会被重复安排、试听转化率能统计出来。区别只是试听学员不建课时账户、不扣课时。把试听做成「不占资源的咨询」，实际执行时一定乱。
六、九尾狐在这类问题上的做法
九尾狐在做教务模块时，第一件事是把「课程、班级、课次、课时账户、考勤」拆成五张独立的表，而不是想办法塞进一张大表。拆开之后，每一层的变动都只影响自己：改课次不动学员账户，改班级不动课时余额，换老师不动历史课酬。这个拆分在开发阶段看起来是多写了几个表，但它是后面所有统计和纠纷处理的基础。
第二个做法是把课次做成批量生成加单节调整，而不是纯手工。批量生成确保「计划课次等于实际课次」，单节调整让临时变化能落地，两者配合，一个学期的课表基本不用维护。手工建课次的系统，第一个月还能坚持，第二个月就开始漏。
第三个做法是给课时账户加流水。账户上只显示余额，每一笔进出都在流水里，流水带类型、关联课次、操作人和时间。家长说「我记得还剩十二节」的时候，把流水拉出来，从第几节到第几节一目了然。课时纠纷的本质都是记账不清，把账记成流水，争议自然少。
七、综上所述
课程、班级、课次这三层，看起来是数据建模问题，实际是运营秩序问题。三层分清楚，排课、考勤、扣课时、算课酬才有共同的语言；三层混在一起，每个环节都要靠人脑补，补得越多错得越多。而培训机构最容易出纠纷的两件事——课时和退费——恰恰都依赖这三层是否清楚。先把结构搭对，再谈功能，顺序不能反。