EPGF 新手教程 24教学模板工程是如何制作的？——教师端一次设计，学生端无限复现
EPGF白皮书摘要： 《路径治理驱动的多版本Python架构》提出Windows环境下"一次搭好、终身不乱"的Python教学开发体系。该体系通过标准化安装路径（如D:\A）、工具本地化（将uv/poetry等工具嵌入.venv）和项目级环境隔离，实现多版本Python共存与项目可迁移性。核心创新包括：1）教师端创建自包含教学模板工程（含.venv、锁定依赖和环境自检脚本）；2
EPGF 新手教程 01为什么 EPGF 能在一台 Windows 上，搞定所有虚拟环境？——一次搭好，终身不乱的 Python 环境治理逻辑（新手也能看懂）
EPGF 新手教程 02第一次安装就不踩坑：Anaconda 正确安装与路径一次性治理——把 Python 安装在 D:\A，从此不再折腾环境变量
EPGF 新手教程 07所有“虚拟环境工具”到底是什么？——一次看懂 venv / virtualenv / conda / uv / poetry / hatch（不再混乱）
EPGF 新手教程 08一次装齐所有工具链，为什么必须跟着 Python 版本走？——工具本地化，才是 Windows 上永不混乱的终极解法（新手必读）
EPGF 新手教程 09｜工具本地化：为什么项目必须自带工具链？——只有 .venv 真正“自给自足”，环境才能迁移、复现、长期不乱（新手必读）
EPGF 新手教程 11在 PyCharm（中文版 GUI）中创建 uv 环境，并把 uv 做到“项目自包含”（工具本地化为必做环节）
EPGF 新手教程 12在 PyCharm（中文版 GUI）中创建 Poetry 项目环境，并把 Poetry 做成“项目自包含”（工具本地化为必做环节）
为什么 hatch 和 pipenv 在 PyCharm 里“行为异常”？——EPGF 架构下的工具真实定位与责任边界（认知纠偏篇）
EPGF 新手教程 13在 PyCharm（中文版 GUI）中创建 Hatch 项目环境，并把 Hatch 做成“项目自包含”（工具本地化为必做环节）
EPGF 新手教程 17 IDE 不是环境：PyCharm / VS Code 与真实 Python 运行时的边界澄清——EPGF 架构中的「执行责任」与「认知纠偏」篇
EPGF 新手教程 18 到底是谁在运行你的 Python 代码？——从 IDE 点击 Run 到字节码执行的完整链路拆解（EPGF 执行真相篇）
EPGF 新手教程 19 为什么 EPGF 必须「先建 .venv，再谈工具」？——项目级环境先行，是一切可迁移与可复现的工程前提
这一篇我们稳稳地落在 EPGF 的“教学落地核心”位置上来写，不再讲零散技巧，而是把我们前面 01–23 篇已经铺好的能力真正“工程化”。
下面是 正文：
EPGF 新手教程 24
教学模板工程是如何制作的？——教师端一次设计，学生端无限复现
副标题：从“我这能跑”到“全班都能跑”，EPGF 如何把教学环境变成工程资产
一、为什么“教学模板工程”是 EPGF 教学体系的核心？
在真实教学中，教师面临的不是“我能不能搭好环境”，而是：
-
❌ 30 台学生电脑，30 种环境状态
-
❌ 学生系统版本不同、Python 路径混乱
-
❌ 课堂时间被环境问题吞噬
-
❌ 作业无法复现，助教无法统一验收
EPGF 的目标从一开始就不是“个人开发舒适度”，而是：
👉 把教学环境，变成一种可复制、可分发、可验收的工程模板
这正是 教学模板工程（Teaching Template Project） 存在的意义。
二、EPGF 教学模板工程的设计目标
一个合格的 EPGF 教学模板工程，必须同时满足：
1️⃣ 跟随项目，而不是跟随机器
-
不依赖 C 盘
-
不依赖用户目录
-
不依赖“老师电脑状态”
👉 项目目录就是全部上下文
2️⃣ 一次设计，多届复用
-
本学期
-
下学期
-
换老师
-
换实验室
👉 模板不“老化”，只会被“复刻”
3️⃣ 学生端只做“执行”，不做“决策”
-
不让学生选择 Python
-
不让学生判断版本
-
不让学生配置工具
👉 学生只负责：打开 → 运行 → 验证
三、教学模板工程在 EPGF 中的层级位置
我们先明确它在 EPGF 架构中的位置：
EPGF 教学体系（教师视角）
┌─ 父级 Python（Conda / py3xx）
│
├─ 教师模板工程（本篇）
│ ├─ .venv/ ← 项目级虚拟环境
│ ├─ pyproject.toml / lock ← 依赖定义
│ ├─ tools/ 或 scripts/ ← 教学辅助脚本
│ ├─ README.md ← 学生操作说明
│ └─ verify_env.py ← 环境自检脚本
│
└─ 学生端一键复现（第23篇）
📌 关键认知：
教学模板工程 =
“已经做完所有决策的项目环境快照”
四、教师端制作教学模板工程的完整流程
下面是你作为教师，实际要做的事情。
Step 1：确定教学所用 Python 版本（父级）
在 EPGF 中，教师端永远先从父级 Python 开始：
示例：
D:\A\envs\py311\python.exe
你要做的不是“让学生装这个”，而是：
👉 让模板工程明确绑定这个版本
Step 2：创建教学模板工程目录
建议规范命名：
AI-Course-Template/
├─ .venv/
├─ src/
├─ data/
├─ README.md
└─ verify_env.py
📌 原则：
-
一个课程 / 一类实验 = 一个模板工程
-
不混用、不拼凑
Step 3：在 PyCharm 中创建项目级 .venv
关键点（非常重要）：
-
使用 PyCharm GUI
-
环境类型：
Virtualenv / uv / poetry（按课程需求） -
Python 来源：指向父级 py3xx
示例：
Python 解释器：
D:\A\envs\py311\python.exe
📌 此时 .venv 已经：
-
跟随项目
-
可迁移
-
可被学生端完整复现
Step 4：工具本地化（教师端必须完成）
这是 EPGF 教学模板与普通项目的分水岭。
正确做法：
在 PyCharm 自动激活的终端中：
pip install uv
pip install poetry
pip install pipenv
（按你课程使用的工具）
📌 结果必须满足：
AI-Course-Template/
└─ .venv/
└─ Scripts/
├─ python.exe
├─ uv.exe
├─ poetry.exe
└─ pipenv.exe
👉 工具链完全自包含
Step 5：冻结依赖（这是“教学合同”）
你需要为学生准备明确的依赖锁定文件：
-
requirements.txt -
或
uv.lock -
或
poetry.lock -
或
Pipfile.lock
📌 教学环境 ≠ 灵活
📌 教学环境 = 确定性
Step 6：加入“环境自检脚本”（强烈建议）
示例：verify_env.py
import sys
import subprocess
print("Python:", sys.executable)
print("Version:", sys.version)
for tool in ["uv", "poetry", "pipenv"]:
try:
subprocess.run([tool, "--version"], check=True)
print(f"{tool}: OK")
except Exception:
print(f"{tool}: NOT FOUND")
👉 这是教师端验收学生环境的“裁判工具”。
五、README.md 应该怎么写？（教师模板标准）
教学模板的 README，不是开发 README。
必须包含：
1️⃣ 学生端操作步骤（极简）
1. 打开项目
2. 双击 run.bat / 执行 script
3. 看到“环境验证通过”
2️⃣ 禁止行为说明
-
❌ 不要自行创建 Python
-
❌ 不要手动 pip install
-
❌ 不要改环境变量
3️⃣ 出错时的统一处理方式
若失败：
1. 删除 .venv
2. 重新执行 restore.bat
3. 提交 verify_env.py 输出
六、为什么说这是“教师的减负神器”？
一旦你完成一次模板工程：
-
✅ 助教不再反复排错
-
✅ 作业可统一验收
-
✅ 学生可课后自复现
-
✅ 下一届直接复用
📌 教学环境第一次变成“资产”，而不是“负担”
七、本篇在 EPGF 系列中的位置说明
第24篇 = 教师端工程化能力的完成态
它承接：
-
第22篇：教学架构设计
-
第23篇：学生端一键复现
并为后续铺路：
-
多模板管理
-
跨课程复用
-
离线教学包
-
自动评分环境
八、下一篇预告（第25篇）
EPGF 新手教程 25：
教学环境的“验收与评分自动化”——助教与课程规模化实践
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
25
0- 0
已为社区贡献89条内容
所有评论(0)