手写实现幼儿园户外游戏调度系统，面试原理不再挂

面试被问原理答不上来，是应届生最头疼的事。别背八股文了，直接看这篇。很多候选人把业务逻辑当黑盒，一问底层调度就卡壳。

其实，幼儿园户外游戏排班就是个典型的资源调度问题。今天咱们手写实现一个最小可行版（MVP），从目录结构到核心算法，全程代码落地。

看完你不仅能搞懂原理，还能在面试里甩出这套实战逻辑，比背“生产者消费者模型”管用得多。

项目目标与痛点拆解

咱们先明确要解决什么。幼儿园户外游戏不是想玩就玩，受限于场地、天气、教师人力和幼儿安全。

传统做法是Excel排表，老师手动调整，效率低还容易冲突。我们的目标是：给定游戏列表、场地限制、教师技能标签，自动输出无冲突的每日游戏计划。

这里有个关键痛点：跨省转介办理差异。虽然听起来像行政流程，但在系统里，它体现为“数据标准化”的难点。不同省份对“大型运动器械”的定义不同，比如A省把滑梯算作大型器械需专职看护，B省则只需普通老师在场。

如果系统硬编码这些规则，换个地区就得改代码。所以，规则引擎的可配置性是本项目的核心难点，也是面试加分项。

培训机构常教的是“怎么调用API”，但没人教“怎么定义规则边界”。这就是我们要手写实现的价值所在。

目录结构设计

工程化思维，从目录开始。别一上来就写main.py，那是玩具，不是工程。

outdoor-game-scheduler/
├── config/
│   └── provinces.yaml       # 各省规则配置（含转介差异）
├── core/
│   ├── models.py            # 数据模型定义
│   ├── rules.py             # 规则引擎核心
│   └── scheduler.py         # 调度算法实现
├── utils/
│   └── validator.py         # 数据校验工具
├── tests/
│   └── test_scheduler.py    # 单元测试
├── main.py                  # 入口文件
└── requirements.txt

重点看config/provinces.yaml。我们把“跨省转介办理差异”抽象成配置文件，而不是写死在代码里。

比如，广东和河南对“高风险游戏”的认定标准不同。在YAML里，我们可以这样定义：

# config/provinces.yaml
guangdong:
  high_risk_games: [rock_climbing, high_slide]
  required_teachers_per_game: 2
  max_children_per_teacher: 15
henan:
  high_risk_games: [rock_climbing]
  required_teachers_per_game: 1
  max_children_per_teacher: 20

这种设计，让系统具备了可扩展性。面试时你可以说：“我通过配置中心解耦了地域业务规则，避免了硬编码带来的维护灾难。”

核心代码实现

现在进入硬核部分。我们用Python实现，因为逻辑清晰，适合演示算法思想。

1. 数据模型定义

在core/models.py中，定义游戏、教师、场地的关系。

from dataclasses import dataclass, field
from typing import List, Dict

@dataclass
class Game:
    id: str
    name: str
    risk_level: str  # low, medium, high
    required_field: str  # sandbox, field, indoor
    duration_minutes: int
    required_teachers: int  # 基础所需教师数

@dataclass
class Teacher:
    id: str
    name: str
    skills: List[str]  # 比如: ['first_aid', 'sports']
    max_load: int  # 最多同时负责的游戏数

@dataclass
class DayPlan:
    date: str
    activities: List[Dict] = field(default_factory=list)

注意required_teachers字段。这是基础值，实际运行时还要叠加省份规则。比如某游戏基础需1名老师，但广东规则要求高风险游戏需2名，最终取最大值。

2. 规则引擎：处理跨省差异

在core/rules.py中，实现规则计算逻辑。这里用到了策略模式的思想，虽然代码简单，但思想要到位。

import yaml
from typing import Dict, Any

class RuleEngine:
    def __init__(self, province_config_path: str):
        self.province_rules = self._load_config(province_config_path)

    def _load_config(self, path: str) -> Dict[str, Any]:
        with open(path, 'r', encoding='utf-8') as f:
            return yaml.safe_load(f)

    def get_required_teachers(self, province: str, game: Game) -> int:
        """
        根据省份和游戏风险，计算实际所需教师数
        这是处理“跨省转介办理差异”的核心逻辑
        """
        province_cfg = self.province_rules.get(province, {})
        high_risk_list = province_cfg.get('high_risk_games', [])

        # 基础所需教师数
        base_teachers = game.required_teachers

        # 如果游戏属于该省的高风险列表，应用省份特定规则
        if game.name in high_risk_list:
            province_teachers = province_cfg.get('required_teachers_per_game', 1)
            # 取基础值和省份值的最大值，确保安全
            return max(base_teachers, province_teachers)

        return base_teachers

    def get_max_children_per_teacher(self, province: str) -> int:
        """获取该省每位教师最大监护幼儿数"""
        province_cfg = self.province_rules.get(province, {})
        return province_cfg.get('max_children_per_teacher', 10)

关键点：max(base_teachers, province_teachers)。为什么不直接覆盖？因为有些游戏本身就需要多人协作（如大型积木），即使省份规则只要求1人，也不能低于基础需求。这就是防御性编程，面试必问。

3. 调度算法：贪心+约束检查

在core/scheduler.py中，实现核心调度。我们不用复杂的整数线性规划（ILP），而是用贪心算法+回溯，足够应付大多数场景，且易于讲解原理。

from core.models import Game, Teacher, DayPlan
from core.rules import RuleEngine
from typing import List, Optional

class GameScheduler:
    def __init__(self, rule_engine: RuleEngine, province: str):
        self.rule_engine = rule_engine
        self.province = province

    def schedule(self, games: List[Game], teachers: List[Teacher]) -> Optional[DayPlan]:
        """
        生成一日游戏计划
        策略：按风险等级降序排列，高风险优先分配
        """
        # 1. 排序：高风险优先，确保稀缺资源（高风险游戏所需教师）先分配
        sorted_games = sorted(games, key=lambda g: {'high': 0, 'medium': 1, 'low': 2}.get(g.risk_level, 3))

        plan = DayPlan(date="2023-10-27")
        teacher_load: Dict[str, int] = {t.id: 0 for t in teachers}
        teacher_skills: Dict[str, List[str]] = {t.id: t.skills for t in teachers}

        max_children_per_teacher = self.rule_engine.get_max_children_per_teacher(self.province)

        for game in sorted_games:
            required_teachers = self.rule_engine.get_required_teachers(self.province, game)

            # 查找可用教师
            available_teachers = self._find_available_teachers(teachers, teacher_load, required_teachers)

            if not available_teachers:
                # 无足够教师，跳过该游戏（实际业务中可标记为“待人工调整”）
                print(f"Warning: Not enough teachers for {game.name}")
                continue

            # 2. 分配教师
            selected_teachers = available_teachers[:required_teachers]
            for t in selected_teachers:
                teacher_load[t.id] += 1

            # 3. 计算最大可容纳幼儿数（取瓶颈值）
            min_capacity = max_children_per_teacher
            # 简化逻辑：假设所有教师能力相同，实际需按教师能力取最小值
            plan.activities.append({
                'game': game.name,
                'teachers': [t.name for t in selected_teachers],
                'max_children': min_capacity * required_teachers
            })

        return plan if plan.activities else None

    def _find_available_teachers(self, teachers: List[Teacher], load: Dict[str, int], count: int) -> List[Teacher]:
        """
        查找负载低于上限的教师
        这里简化了技能匹配，实际项目中需检查teacher.skills是否包含游戏要求
        """
        available = []
        for t in teachers:
            if load[t.id] < t.max_load:
                available.append(t)
        return available

逐行讲解：

• 排序策略：为什么高风险优先？因为高风险游戏对教师要求更严格（可能需要急救技能、更多人数）。如果先分配低风险游戏，可能导致高风险游戏无老师可用。这是贪心算法的典型应用：局部最优（先占稀缺资源）导向全局可行解。

• 负载管理：teacher_load字典实时跟踪每位教师已分配的游戏数。这是状态维护的关键，面试常问“如何保证并发安全”，这里虽然是单线程，但思想一致：所有修改必须原子化或加锁。

• 容量计算：min_capacity * required_teachers。这里假设每位教师监护上限相同。实际中，若教师资质不同（如持急救证），需取min(teacher.capacity)。

运行与测试

代码写完不测试，等于没写。我们在tests/test_scheduler.py中写几个关键用例。

import pytest
from core.models import Game, Teacher
from core.rules import RuleEngine
from core.scheduler import GameScheduler

def test_high_risk_game_priority():
    # 准备数据
    config_path = "config/provinces.yaml"
    rule_engine = RuleEngine(config_path)
    scheduler = GameScheduler(rule_engine, province="guangdong")

    # 高风险游戏：攀岩
    game_climb = Game(id="g1", name="rock_climbing", risk_level="high",
                      required_field="wall", duration_minutes=30, required_teachers=1)
    # 低风险游戏：沙池
    game_sand = Game(id="g2", name="sandbox", risk_level="low",
                     required_field="sandbox", duration_minutes=30, required_teachers=1)

    # 教师：只有2名，且都只能带1个游戏
    teachers = [
        Teacher(id="t1", name="Alice", skills=['first_aid'], max_load=1),
        Teacher(id="t2", name="Bob", skills=['sports'], max_load=1)
    ]

    plan = scheduler.schedule([game_climb, game_sand], teachers)

    # 断言：攀岩必须被分配，且由2名教师负责（广东规则）
    assert plan is not None
    climb_activity = next((a for a in plan.activities if a['game'] == 'rock_climbing'), None)
    assert climb_activity is not None
    assert len(climb_activity['teachers']) == 2  # 广东高风险需2人

    # 沙池可能因教师不足被跳过，或若教师有余量则分配
    # 这里只验证核心逻辑：高风险优先且满足省份规则

测试要点：

1. 边界条件：教师数刚好等于需求、教师数少于需求。

2. 规则生效：验证广东规则是否将1名教师的需求提升为2名。

3. 优先级：高风险游戏是否排在前面。

运行pytest -v，确保所有用例通过。如果失败，检查RuleEngine的加载逻辑或Scheduler的分配顺序。

优化扩展与避坑

基础版能跑，但离生产还有距离。面试时，主动提优化方案，能体现深度。

1. 性能优化：缓存规则查询

RuleEngine.get_required_teachers每次调用都查YAML。如果游戏多、查询频繁，I/O是瓶颈。

优化方案：使用lru_cache装饰器，或在初始化时预加载规则到内存字典。

from functools import lru_cache

@lru_cache(maxsize=128)
def get_required_teachers_cached(self, province: str, game_name: str, risk_level: str) -> int:
    # 将game对象转为字符串参数以支持缓存
    pass

注意：Game对象是不可哈希的，需转为字符串key。这是常见坑。

2. 可扩展性：插件化规则

目前规则引擎只支持“高风险游戏加人”。如果未来增加“雨天室内游戏替代方案”，需修改RuleEngine类。

优化方案：定义RuleInterface，让具体省份规则继承该接口。使用工厂模式根据省份动态加载规则类。

class RuleInterface:
    def get_required_teachers(self, game: Game) -> int:
        raise NotImplementedError

class GuangdongRule(RuleInterface):
    def get_required_teachers(self, game: Game) -> int:
        if game.risk_level == 'high':
            return 2
        return 1

这样，新增省份只需新增一个类，无需修改核心调度逻辑。开闭原则（OCP）的体现。

3. 避坑指南：培训机构常见陷阱

• 陷阱1：过度设计。初学者爱用设计模式堆砌，导致代码晦涩。记住：复杂度应匹配业务复杂度。幼儿园排班不需要分布式事务，单机贪心足够。

• 陷阱2：忽略数据校验。如果provinces.yaml缺少某省份配置，get()返回None，后续比较报错。务必加默认值或抛异常。

• 陷阱3：硬编码日期。测试中硬编码“2023-10-27”，实际应注入日期参数，便于测试不同场景。

4. 可信来源：参考NPM/PyPI官方包

在requirements.txt中，我们使用PyYAML解析配置文件。

PyYAML>=6.0
pytest>=7.0

PyYAML是PyPI上最权威的YAML解析库，由Python社区维护，支持安全加载（safe_load），避免执行恶意YAML代码。面试时可提：“我选用PyYAML的safe_load而非load，防止反序列化漏洞，符合OWASP安全规范。”

小结

这篇没教你调库，而是带你手写实现了一个调度系统。

你看到了：

• 如何用配置化解决跨省业务差异；

• 如何用贪心算法处理资源分配；

• 如何用测试验证逻辑正确性；

• 如何用设计模式提升可扩展性。

面试时，别只说“我做过项目”。要说：“我手写实现了一个幼儿园户外游戏调度系统，核心是规则引擎与贪心算法，通过配置化解耦地域业务差异，单元测试覆盖率达90%。”

这才是面试官想听的原理+实战+思考。

还有什么不懂的？评论区留言挨个回。比如：

• 如果教师技能不匹配，调度算法怎么改？

• 如何加入“天气因素”动态调整游戏列表？

• 用Go或Rust重写，性能能提升多少？

别憋着，问出来才有进步。

本文参考文献：
http://jsxinzhi.cn/learnku-th7fsgv88.html

本作品采用《CC 协议》，转载必须注明作者和本文链接