自动排课本质上是在复杂的资源限制里，找到「既合法又合理」的课程安排方案 —— 核心是平衡「必须满足的规则」和「尽量舒服的体验」，基本步骤可以拆解成以下几步：

1. 先把「所有要考虑的因素」摸清楚

排课前得先收集全量需求，这是基础中的基础。比如：

• 班级维度：每个班要上哪些课（比如语文每周 5 节、数学 4 节）、有没有特殊要求（比如某班每周要加一节奥数）；

• 老师维度：每个老师的任课科目（比如张老师教语文和历史）、时间限制（比如李老师周三下午要教研、王老师每周二上午要送孩子上学）、个人偏好（比如尽量不连续上 3 节课）；

• 教室维度：每间教室的类型（是不是多媒体教室、有没有实验设备）、容量（能坐 40 人还是 60 人）、位置（比如 1 楼教室适合低年级，3 楼实验室适合化学课）；

• 学校规则：比如「上午前两节必须排主科」「体育课不能排上午最后一节」「同一门课不能连续两天不上」。

• 

这些信息缺一个都可能出问题 —— 比如漏了某老师的教研时间，排出来的课表肯定要返工。

2. 把需求变成「可执行的规则」，分「硬约束」和「软约束」

接下来要把零散的需求整理成明确的规则，关键是分清楚两种约束：

• 硬约束：绝对不能违反（违反了课表就无效）—— 比如同一个老师不能同时在两个教室上课、同一个教室不能同时上两节课、化学课必须用实验室、某班每周语文必须上 5 节；

• 软约束：尽量满足（不满足也能凑合用，但体验会差）—— 比如别让老师连续上 3 节课、别让班级上午最后一节上体育课、别让老师跨教学楼跑太远、尽量让老师的课集中在上午。

举个例子：「张老师不能同时上语文课和历史课」是硬约束，「张老师尽量不下午第一节上课」是软约束。

3. 把规则翻译成「算法能看懂的语言」

算法没法直接理解「别让老师跑太远」这种自然语言，得把规则建模成数学或逻辑关系。比如：

• 用变量代表「某老师在星期 X 第 Y 节，给 Z 班在 W 教室上某课」（比如变量 A=「张老师周一第 1 节，给 1 班在 101 教室上语文」）；

• 把硬约束写成「同一老师的两个变量不能在同一时间」（比如变量 A 和变量 B 如果是张老师的课，时间不能重复）；

• 把软约束写成「尽量让老师的课集中在上午」（比如给上午的课加「权重分」，算法会优先选分高的组合）。

这一步就像给算法「定游戏规则」—— 它得知道什么是「对的」，什么是「好的」。

4. 让算法开始「试错 + 找最优解」

接下来算法会用各种方法求解，核心是「在满足硬约束的前提下，尽量满足软约束」。常见的方法有几种：

• 回溯法：像「走迷宫」一样一步步试 —— 先给 1 班排周一第 1 节的语文课，选张老师和 101 教室；接着排周一第 2 节的数学课，选李老师和 102 教室；如果遇到冲突（比如李老师周一第 2 节已经有课），就退回去换一种方式（比如换王老师教数学）；

• 遗传算法：像「进化」一样优化 —— 先随机生成一批课表，然后「淘汰」违反硬约束的，「保留」软约束满足得好的，再把这些课表「杂交」（比如把 A 课表的上午安排和 B 课表的下午安排结合），不断迭代直到找到「最优解」；

• 模拟退火：像「慢慢降温」一样调整 —— 一开始允许大幅度修改（比如把某老师的课全换到下午），后来慢慢精细化（比如只调整某节课的教室），避免陷在「局部好」的课表里（比如某老师的课都在上午，但跨楼跑），找到「全局好」的解。

5. 先查「有没有错」，再调「舒不舒服」

算法算出课表后，得先验证硬约束—— 有没有老师冲突？有没有教室冲突？有没有漏课？比如：

• 检查「张老师周一第 3 节是不是同时在 1 班和 2 班上课」（硬约束）；

• 检查「1 班的语文课是不是每周 5 节」（硬约束）；

• 检查「化学课是不是用了实验室」（硬约束）。

如果硬约束都满足，再优化软约束—— 比如：

• 某老师每天都有最后一节，能不能和其他老师换一节？

• 某班级连续 3 节主科，能不能插一节副科？

• 某老师的课分散在 3 栋楼，能不能调整到同一栋？

6. 最后「落地验证」，听用户反馈

再完美的算法也不如实际用的人有话语权。比如：

• 把课表给老师看，问「这节课你能上吗？」「要不要调整？」；

• 给班级看，问「上午最后一节上体育课会不会饿？」；

• 给后勤看，问「实验室的使用时间有没有冲突？」。

很多时候算法算出来的「最优解」，实际用起来可能不舒服 —— 比如某老师的课都在上午，但他习惯下午备课，这时候就得调整。

最后：自动排课不是「算出来就行」

本质上，自动排课是「技术辅助人」，不是「技术代替人」。算法的作用是帮我们快速处理复杂的硬约束（比如避免老师冲突），但最终还是要回归到「用课表的人舒服」—— 毕竟课表是给老师和学生用的，不是给算法看的。

总结下来，步骤就是：收集需求→定规则→建模→求解→验证→优化—— 核心是「先保证对，再追求好」。