教学平台产品共识 V0.1
面向对象：总部管理、教研、校区负责人、教师与产研团队
定位：首期教学平台的正式产品共识，不是招生宣传稿，也不是完整技术设计书
日期：2026-08-02
一、已定产品判断
平台开发顺序确定为：先建设教学平台，后研究儿童 AI 创作平台。
首期目标不是制作“儿童版 Codex”，也不是将 AI 创作工具重新开发一遍，而是先让两家校区稳定完成真实课堂教学：总部能够配置课程，教师能够发布任务，学生能够在个人账号中完成任务并沉淀作品。
一句话定义：
教学平台是面向线下小班 AI 创造课程的课程任务与学生作品平台。
它服务“老师能把课上起来、学生能在网页端跟着完成任务、家长能通过学生账号看见作品”这一首期交付目标。
它是什么
- 总部教研的智能课件与课程任务承载平台；
- 两家校区的班级、教师、学生与任务发布平台；
- 学生完成答题、HTML 互动、文字、图片和文件提交的平台；
- 学生个人作品空间的长期承载平台。
它不是什么
- 不是儿童版 Codex；
- 不是普通聊天工具或 AI 助教；
- 不是完整教务、排课、招生或校区经营系统；
- 首期不是实时课堂监控或远程控制系统；
- 不是面向全网公开的学生作品社区。
二、与课程体系及未来平台的关系
课程体系定义教育逻辑、课程任务、成长标准与评价方式；教学平台负责把这些课程任务交付给真实班级；未来学生 AI 创作平台负责支持孩子在更复杂的 AI 创作环境中完成项目。
AI 时代创造教育体系
├── 课程体系：定义教什么、怎么学、如何评价
├── 教学平台：支持总部配课、老师发布、学生学习与作品沉淀
└── 未来学生 AI 创作平台：支持孩子更深度地借助 AI 完成创作
当前阶段，学生在项目创作中仍可使用 QoderWork、WorkBuddy、Codex 等现有工具。教学平台不替代这些工具，而是承载课程任务、材料、提交和作品记录，并从真实课堂中继续识别未来必须产品化的创作能力。
三、首期服务范围
校区与课堂场景
- 首期服务已开设的第一家校区及一个月后开设的第二家校区；
- 后续半年内为校区扩张做数据结构准备，三年内预期扩展至约 200 家校区；
- 当前课程覆盖幼儿小班、中班、大班，以及小学低龄、中龄、高龄；
- 线下小班教学，每班 6—8 名学生，单节课为 60 或 90 分钟；
- 学龄前学生一人一台 Android 平板，学龄学生一人一台 Windows 电脑。
首期不以实时设备状态、学生当前步骤或教师远程控制为范围。教师应在课后或适当时查看提交结果，但系统不承担课堂全过程监控。
首期角色
| 角色 | 首期职责 |
|---|---|
| 总部管理员 | 管理校区、人员、权限与全局配置 |
| 总部教研 | 创建、编辑和发布标准课程、智能课件与任务 |
| 校区负责人 | 管理本校区教师、班级和学生，查看本校区使用情况 |
| 教师 | 向班级发布、补发、撤回任务，查看学生提交并代上传实体作品 |
| 学生 | 登录、查看任务、完成答题与课件、提交成果、查看个人作品空间 |
首期仅总部教研可以编辑标准课程。未来开放校区编辑时，校区只能基于总部课程复制形成校区版本，不得直接覆盖总部原版。
统一登录与角色工作区
平台保持一套账号、权限、代码和数据，不拆成多个相互独立的后台系统。员工从统一登录入口进入，系统在身份验证后按账号角色自动进入对应工作区：
| 角色 | 默认工作区 | 首要任务 |
|---|---|---|
| 总部教研 | 教研工作台 | 组织、编辑、预览和发布课程内容 |
| 总部管理员 | 管理工作台 | 管理校区、人员、权限与全局配置 |
| 校区负责人 | 校区工作台 | 管理本校区教师、班级、学生与使用情况 |
| 教师 | 教师工作台 | 选择班级和课程、开始授课、发送互动环节并查看结果 |
各工作区可以使用不同的路由空间和导航结构，但不得因此重复建设登录、账号、课程、任务或数据服务。用户登录后只看到与本角色主要任务有关的入口，不能依靠共享后台中的菜单删减来暗示角色差异。
学生继续使用同一平台登录页中的“学生进课堂”入口，以课堂码定位班级，再完成个人身份验证；学生不进入员工工作区。首期账号按单一角色处理，不增加工作区切换器；未来确有一个账号承担多个角色时，再为该账号显示明确的“切换工作区”入口。
登录页左上角品牌区与各角色工作区使用同一套简洁标识：只显示指定的百工猫猫形图像和单行平台名称“百工猫AI教育平台”，不再叠加英文品牌名、“AI教育平台”简称或品牌副标题。登录页其他承担登录说明的正文不受此规则影响。
教师账号与课程授权
教师账号按校区管理：总部管理员创建校区和校区负责人账号，并保留全局停用、审计和跨校区转移权限；校区负责人负责本校区教师账号的新增、密码重置、停用和班级分配。教师不开放自主注册，校区负责人不得管理其他校区人员。
课程内容发布与课程使用授权分开处理：
总部教研发布课程包
→ 总部管理员把课程包开通给指定校区
→ 该校区全部在职教师自动获得浏览和授课权限
→ 教师只能向自己负责的班级授课和发布任务
总部教研负责课程质量和发布状态，不承担校区商业授权；总部管理员负责把课程包开通到校区；校区负责人只能查看和安排使用本校区已经开通的课程包，不能自行获得未授权内容。首期不做逐教师课程开通，除非未来出现按教师收费或教师资质限制等明确业务需求。
四、课程中心与智能课件模型
课程内容统一采用以下层级：
课程体系
→ 课程包
→ 课程
→ 智能课件
→ 教学环节
“课程系列”与“课程包”指同一层级，产品界面统一使用“课程包”；课程包内一次可以独立开展的课堂内容统一称“课程”，不再另设“课次”层级。课程体系用于组织 AI 课程教育标准体系、寒暑假课程体系等内容，C1、C2 等作为具体课程包。推荐课程包只改变首页展示位置，不建立特殊数据类型。
智能课件由总部教研将图文、图片、视频、文档、PDF、网页、HTML、客观题和提交等不同类型的教学环节按顺序组装为一堂完整课程。它不是单一 PPT、单个 HTML 或 AI 自适应系统；当前“智能”首先指多媒体教学环节的结构化编排与统一预览和授课。
总部教研可以新增、删除、复制、排序、分组和预览教学环节，并完整预览整堂课程。校区教师使用相同的课程中心和课程列表，在确认班级与课程后进入只读授课播放器。首期不提供独立备课模式；未来备课指教师基于总部课程创建可编辑副本，不得覆盖总部原版。首阶段按线性顺序运行，不开发复杂条件分支、自由流程图或多人实时协作编辑。
课程内容的归档删除与恢复
课程体系、课程包和课程的“删除”统一采用归档删除（软删除）：保留数据库记录及其关联教学事实，但从正常课程库、授权列表和新建授课入口中隐藏；它不是立即物理删除文件或历史数据。
- 删除课程体系或课程包时，下级课程内容一并归档隐藏；不要求教研逐层手工清空；
- 已归档内容不得编辑、开通、开始新授课或新建课堂任务；课件、封面、教学资料等关联资源随内容隐藏，但不立即删除；
- 已结束课堂、学生提交、作品空间和授课历史必须继续可追溯，后续恢复后资源仍可用；
- 正在授课的课程不得删除，必须先明确结束课堂；
- 总部教研可归档自己管理的课程内容；总部管理员拥有全局恢复权限；教师与校区负责人不得删除或恢复总部原版；
- 总部管理员在“已删除内容”中恢复。恢复课程时，如其上级体系或课程包已归档，则自动恢复必要上级；恢复前应校验名称冲突与授权/上级完整性；
- 首期不设置自动永久清理周期或用户可见回收站以外的二次销毁入口，后续仅在数据保留、存储成本和合规要求明确后另行决定。
产品界面仍使用“删除”作为用户动作，但确认页必须明确说明“删除后从课程库隐藏，可由总部恢复”，并展示本次将一并隐藏的下级课程与相关资源数量。
智能课件负责组织整堂课程；课堂任务负责把需要学生在本人设备完成的答题、互动或提交内容发布给全班或指定学生。教师仍发布具体课堂任务，而不是一次性把整堂课程开放给学生。
课程中心、课程包详情、智能课件编辑与验收要求见专项正式文件：
教师授课、学生接收与实时学情的专项要求见：
教学平台课堂授课与学生互动产品需求V0.1.md
五、任务发布与提交
教师的课堂主路径为：
班级管理 → 选择班级 → 选择课程 → 开始授课
或
课程管理 → 选择课程 → 选择班级 → 开始授课
→ 在可发送环节向当前班级发送
→ 查看学生作答和实时学情
单选、多选和 HTML 环节可发送给学生；本阶段不增加填空题。选择题自动判分并回收答案，HTML 只下发运行，不回收答案、完成状态或内部行为。图片、视频、文档和 PDF 仅用于教师展示，不独立发送给学生。
课堂发送支持：
- 首次发送形成第 1 轮；
- 补发只面向未收到或晚到学生，沿用当前轮次；
- 重新作答向全班生成新轮次，旧轮次结果保留；
- 撤回后学生不再访问该环节，已有记录不删除；
- 实时查看已提交人数、未提交学生、选项分布、正确率和当前轮次。
每次明确开始授课形成授课记录，关联教师、班级、课程、课程版本、发送轮次和学生结果。刷新或短暂重连应恢复当前记录，而不重复开课。总部修改课程后，历史授课记录继续保留原课程版本。
同一班级同时只能有一条进行中的授课记录。教师必须明确结束授课；结束后停止新发送和作答，历史数据保留。学生端同时只呈现一个当前环节，切换前如仍有未提交学生，系统要求教师确认。单选、多选未配置正确答案时不得发布课程或发送环节。
原有独立课堂任务页继续承担历史任务查看、补发和撤回等次级管理，不再作为教师开始授课的主入口。
六、学生账号与个人作品空间
每个学生拥有独立、长期的学生账号和个人作品空间。作品属于学生，不属于某一个班级；学生换班、升龄或转校区后，作品继续保留。
学生不开放自主注册。校区负责人负责本校区学生账号的新增、批量导入、停用、分班和校内转班；教师只可为本人班级学生重置 PIN 或解除课堂登录锁定；跨校区转移由总部管理员处理。
课堂仍可通过班级码、登录链接或二维码进入，但班级入口只用于定位班级，不能替代学生身份验证。为保护个人作品空间，学生需选择本人卡通形象或姓名后以个人简单口令完成登录；教师可协助重置口令和解除设备绑定。
学龄前以卡通形象和简短口令降低操作负担；小学学生以姓名、卡通形象和个人口令登录。家长首期通过学生账号查看孩子的作品空间，不单独开发家长端账号。
作品空间是私有访问区：
- 学生和家长通过学生账号查看；
- 教师仅可查看自己所教学生的作品；
- 校区负责人仅可查看本校区学生的作品；
- 总部按权限查看；
- 不提供公开链接、游客访问、作品广场、评论、点赞或搜索展示。
七、作品与任务的关系
任务提交和学生作品是两类不同记录：
任务提交：用于教学检查，默认不作为长期展示内容
作品记录：学生长期保留的可回看成果
教研可将任务标记为“可形成作品”。学生或教师上传的成果可进入该学生的作品空间，包括：
- 学生生成的单个 HTML 页面或 ZIP 作品包；
- 课堂生成的图片；
- 学生文字说明；
- 普通文件；
- 老师拍摄并上传的实体作品照片。
作品支持草稿、已完成与已归档状态，并保留必要版本。教师可代学生上传实体作品、补充标题和说明。
八、HTML 课件与 HTML 作品
HTML 内容来源支持单个 HTML 文件和包含素材的 ZIP 包。平台应提供受控的 HTML 运行环境。
本阶段教师在授课页发送的 HTML 环节仅负责下发与运行：不回收答案、不记录完成状态、不采集内部操作行为。轻量课件 SDK 和统一通信协议作为未来可选能力保留，不属于当前开发和验收范围。
HTML 课件和学生 HTML 作品必须与主平台账号页面隔离运行：不得读取登录凭证，不得获得客户端系统权限，不得因课件脚本影响平台主页面。HTML 作品仅向有权限的登录用户开放。
九、技术路线
首期采用 Web First、API First 的单体全栈架构：业务逻辑在代码中分层，但不拆为独立前端项目和独立 Java/Python 后端服务。
网页端（总部、校区、教师、学生）
→ Next.js + React + TypeScript
→ API 与业务服务层
→ PostgreSQL + Prisma
→ 国内对象存储（图片、视频、文件、HTML 包）
界面层采用 Tailwind CSS 与 shadcn/ui。首期以网页端为唯一交付形态，Android 原生端与 Windows Electron 客户端后置。
这一选择不等于没有后端：从首期开始以版本化 API 提供账号、班级、任务、提交和作品空间能力。未来 Android 原生端、Windows Electron 客户端可复用同一后台接口；当多端、团队和后台任务规模增长时，再逐步抽离独立服务。
首期不采用微服务、Kubernetes、多套前端工程或复杂低代码平台。数据与文件部署在国内云环境，建立开发、测试、正式三套环境，数据库迁移记录、自动备份和上线前基础测试为必须项。
开发阶段质量策略
AI 参与开发不降低测试要求，但也不以追求全面覆盖率拖慢需求验证。日常开发采用“风险优先、快速反馈、分层执行”的测试策略：
- 权限、数据归属、业务状态机、上传与清理、并发与幂等属于高风险规则，新增或修改时必须同步补充自动回归；
- 课堂轮次、课程草稿与发布、任务撤回、作品提交等状态型功能，必须先形成状态与合法转移，再覆盖关键正常、拒绝和恢复路径；
- 拖拽排序、删除后预览、PDF 就绪、未保存退出、历史轮次切换和长目录操作等关键组件交互，必须验证操作后的业务结果，不能只验证按钮存在或动画出现；
- 开发工程维护可复用测试数据工厂，能够组合不同角色、校区、班级人数、内容长度、历史版本和异常状态，并确保测试数据可隔离、可精确清理；
- 开发过程中先运行秒级或分钟内完成的单元、状态机和组件测试；功能完成后运行对应模块集成测试；交付前再运行完整回归和必要的真实浏览器验收；
- 涉及文件上传的页面流程采用分层验收：安全、权限、孤儿文件与清理由 API/模块测试负责；上传、改名、排序、删除、刷新与下载等页面结果由独立 Playwright Chromium 直接向可见文件输入注入隔离夹具验证；日常 Chrome 不由自动化接管，仅在每个版本进行一次人工真实使用路径抽检；
- 普通文案、低风险样式和仍未确认的原型不强制编写重型自动化测试；测试范围服从真实风险，不以覆盖率数字作为独立目标。
每次缺陷修复至少要留下能够复现原问题的回归用例，并验证相邻旧流程未被破坏。自动化测试、接口测试和真实浏览器证据分别记录，不互相冒充。
长期演进与代码治理
平台按长期持续升级的产品建设，现阶段代码不仅要“能运行”，还必须便于现有团队、后续专业工程师和其他 AI 快速理解、定位和安全修改。总体采用边界清晰的模块化单体，在真实规模和团队协作需要出现前，不提前拆分微服务、消息队列或复杂中台。
- 代码按课程、智能课件、课堂授课、学生与班级、作品、资产、账号与权限等稳定业务域组织；页面、接口、业务规则和数据访问职责分离，跨模块依赖必须通过明确入口，不允许复制同一业务规则；
- 鉴权、文件处理、错误响应、幂等、审计、事务与测试数据等公共能力统一实现，避免不同功能各自形成一套隐含规范；
- 每个业务模块维护短小的模块说明，至少写清职责、入口、关键模型、主要状态、权限边界、依赖、测试入口和禁止事项；根目录维护面向人和 AI 的渐进式路由，使新参与者只读取当前任务所需的最小文件集；
- 重大架构取舍、被废止方案和兼容边界进入决策台账；数据库结构只通过正式迁移变更；临时兼容代码必须标注来源、退出条件和清理计划，不能无限堆积新旧双轨逻辑；
- 新功能优先进入既有业务模块；只有在职责、数据所有权、部署节奏或性能边界确实独立时，才新建模块或抽离服务；不得为了文件看起来整齐而制造无业务意义的抽象层；
- 完成定义增加“结构归位、文档同步、测试通过、无重复规则和无无主临时代码”。代码可读性、命名和文档首先服务业务理解，不以篇幅、注释数量或目录层数作为质量指标。
架构治理的最高约束是不得改变已确认业务行为。治理前先建立现状地图和回归基线；重构采用小步、可回退、逐模块方式，每一步都必须通过对应模块测试和完整关键闭环。任何需要修改数据模型、接口契约、权限、状态机或用户流程的内容，都必须从“架构整理”中拆出，重新进入产品确认和独立开发验收，不得夹带实施。
十、首期不做
- 儿童版 Codex 或自研 AI 创作 Agent；
- 实时课堂设备状态和学习步骤监控；
- 教师远程控制学生设备；
- 复杂排课、招生、收费、加盟与经营系统；
- 家长独立账号、评论、点赞和社交功能；
- 公开作品链接和作品广场；
- AI 自动评价与完整成长档案；
- Android 原生客户端与 Windows Electron 客户端；
- 离线课程包和复杂本地同步。
十一、首期验收标准
首期以两家校区连续真实使用为验证标准，而不是以功能数量为标准。至少应满足：
- 两家校区可独立管理教师、班级和学生；
- 总部管理员可创建校区负责人，校区负责人可管理本校区教师账号和班级关系，不能操作其他校区人员；
- 总部教研可创建课程、智能课件、节点与任务；
- 总部管理员可将已发布课程包开通给指定校区；本校在职教师自动可见，未开通校区不可见；
- 教师可发布、补发和撤回任务；
- Android 平板和 Windows 电脑均可登录、查看 HTML、完成客观题并提交；
- 学生可提交文字、图片和文件；授课中的 HTML 环节可运行但不回收数据；
- 教师可查看学生提交并代上传实体作品；
- 每个学生可在个人账号中查看长期作品空间；
- 课程版本、任务提交和学生作品不因后续课程修改或换班而丢失；
- 数据库可恢复，文件有备份，权限边界经上线前检查。
十二、双工程协作与文档治理
教学平台采用“产品主控工程 + 开发执行工程”的双层协作方式。目的不是增加文档，而是让每类判断只有一个权威来源，并保持理念、需求、实现和验收可追溯。
1. 两个工程的职责
| 工程 | 主要职责 | 不承担的职责 |
|---|---|---|
COS系统设计 |
讨论并确认教育理念、平台定位、产品需求、范围边界、任务拆解与最终验收 | 不重复维护与代码逐项同步的开发 PRD，不直接以实现细节替代产品判断 |
AI教学平台 |
维护代码、数据库迁移、测试、运行说明及可执行开发文档 | 不自行创造产品需求，不在未确认时扩大范围或改变教育产品判断 |
2. 唯一事实源
| 内容类型 | 权威来源 |
|---|---|
| 教育理念、体系口径、平台定位与产品边界 | COS系统设计 的正式共识与决策台账 |
| 当前可执行的功能需求与业务规则 | AI教学平台/docs/PRD.md |
| 实现取舍、架构变化与技术决策 | AI教学平台/docs/DECISIONS.md |
| 验收用例、完成状态与测试证据 | AI教学平台/docs/ACCEPTANCE.md 及自动化测试 |
| 实际系统行为、数据库结构与接口 | AI教学平台 的代码、迁移与测试 |
同一项内容只保留一个权威全文，另一工程只记录引用、摘要或由其派生的执行要求，不复制维护第二份完整 PRD。发生冲突时，已确认的最新产品决策优先于开发工程中的旧要求；不涉及产品边界的实现细节，以开发工程的决策文档和代码为准。
3. 需求传递与回传流程
- 在产品主控工程讨论理念、需求和边界；未确认内容不进入开发。
- 确认后形成决策包，至少包含背景、已定结论、受影响需求、验收标准和明确不做事项。
- 开发执行工程将决策包转化为可执行 PRD、实现决策和验收用例，再修改代码与测试。
- 开发完成后回传变更文件、测试证据、未完成项与风险。
- 产品主控创建一次性的独立验证任务。验证任务从产品需求和开发提交出发，只读检查开发工程、运行自动化和必要浏览器流程，不继承开发者的完成判断，也不直接修改代码或指挥开发。
- 独立验证失败时，由产品主控把明确问题退回原开发任务；开发修复并反馈后，再进入新的验证轮次。验证通过后，由产品主控核对产品边界、证据与风险，决定是否进入用户手工验收。
- 对用户可见的功能和体验改动，由用户在本主控窗口接收结果并进行最终手工测试。发现问题仍由产品主控统一退回开发、安排复验；用户不需要管理开发任务或验证任务。
- 开发自测、独立验证、产品主控验收和用户手工测试是四个不同证据层级，不能互相冒充。任务只有在适用层级全部通过、文档和任务队列更新后才关闭。
产品主控必须主动跟踪整条链路：开发和独立验证完成后均须主动回传主控；主控不得把“等待用户询问”作为进度管理方式。开发反馈后，主控立即组织独立验证；验证失败则主动退回开发并持续跟踪至复验通过或形成明确阻断；任务关闭或需要用户手工体验时，主控主动在本窗口报告。用户无需进入其他任务询问状态或负责催办。
教育理念不能直接作为模糊开发指令。凡理念影响产品，必须经过“理念判断 → 产品约束 → 界面、流程、字段或权限 → 验收用例”的转换后再进入开发。
4. 开发任务组织
产品主控窗口长期保留，承担产品连续性、正式决策、任务队列和最终验收；开发窗口不作为永久上下文。每个边界明确的开发或工程审查任务新建一个短周期任务，只接收目标、范围、相关正式文件、验收标准、停止条件和必要的结构化交接。任务完成、提交、反馈并验收后归档，不把旧聊天历史继续滚入下一任务。
同一开发工程同一时间默认只有一个写入任务。只有工作内容彼此独立、文件边界清晰且确有并行收益时，才允许使用隔离工作区并行；合并前必须由指定任务执行完整回归，避免多个任务同时修改同一实现。新任务的上下文来自当前代码、正式 PRD、决策台账、验收标准和上一任务交接摘要，而不是依赖旧开发聊天，因此切换窗口不等于丢失产品上下文。
独立验证任务由产品主控按交付临时创建、管理和关闭，不作为永久开发窗口。它可以读取和运行 AI教学平台 工程，但默认只读；需要修复时必须回到原开发任务。验证任务完成后关闭，下一项交付使用新的验证上下文，减少历史假设和无关 Token。
产品主控通过 教学平台主控任务队列.md 串行调度：同一开发任务完成、回传并验收前，不向该开发任务追加下一项工作。交互、安全、架构和夜间加固只在相应风险或明确任务出现时作为专项加入，不自动叠加到普通功能开发。
本规则不迁移或删除现有产品共识文件：本文件继续作为上游产品依据，开发工程的 docs/PRD.md 作为与当前代码同步的执行版本。
追溯关系
本共识补充原内部共识稿中“课程体系与产品平台的关系”，并将“教学平台先行、学生 AI 创作平台后置”的当前开发顺序具体化。相关决策登记于：
本页由 Markdown 自动生成。更新内容时请先修改源 Markdown，再重新生成网站 HTML。