教小伴 / TeachBuddy

面向任课教师的教学管理产品。微信小程序做日常点名，PC Web 维护资料、成绩与进度，两端共用同一工作区。

Product Context

任课教师的日常不是一张静态课表，而是一条连续的业务链：建工作区、维护班级与学生、排课、按课表点名、回看历史，再在电脑上处理作业、成绩和进度。教小伴用两个客户端承接这件事：微信小程序负责课堂入口，PC Web 负责批量维护，数据落在同一份工作区。

教师进入产品后，沿着这条路径完成教学日常：

信息架构跟着业务走：工作区是数据边界，学校与学期是容器，授课是课程 × 班级 × 学期的绑定，课表项是每周固定的一节课，点名场次则冻结当时的名单快照。之后学生增减，不会改写已经发生的那一次课。

点名不是独立功能，而是课表上的一次课。先有授课和课表，才有整班点名；结果进入历史，允许事后查询和修改。学校、学期、课程、授课以归档为主，班级和课表项才允许硬删除，避免把误建数据和真实历史混在一起。

小程序用原生 TypeScript / WXML，PC Web 用 React 19 与 Semi Design。两端直连同一个 Supabase 项目：Postgres 以工作区做 RLS 边界，微信登录和配对码登录走 Edge Functions。

以课表为点名入口，而不是让教师每次手工挑班级，点名才和真实上课时间对齐。

小程序承担课堂高频操作，PC Web 承担批量导入、成绩和进度；两端不复制两套数据，只用配对码换同一工作区会话。

点名场次保存名单快照，后续花名册变动不影响历史统计。

教学业务看起来简单，边界却多：学期切换、班级学生变动、课表调整、历史点名修改。产品要能表达这些变化，而不能假设名单永远不变。

作业、成绩与教学进度已经在 PC Web 落地。后续会继续沿着教师真实工作往前走，把课堂入口和电脑端维护做得更顺，而不是先堆功能。