让老师知道，下一步做什么
现有项目功能覆盖很广，已有角色视角和任务入口，但对第一次使用的老师而言，仍不够简单。主要问题是：业务对象、任务步骤和工具操作混在一起，用户需要先理解系统结构，才能知道自己要做什么。
01 / 先回答两个问题
使用起来简不简单、方不方便？
熟悉业务、知道入口的老用户可以完成很多工作；新用户需要付出较高学习成本。优点是已经有角色菜单、今日任务、独立页面链接、人工确认和演示数据。问题是入口仍随角色、课程类型和生命周期变化，老师必须记住“这件事在哪一个页面、哪一个页签”。
是不是一个页面做了太多事？
是，但不是所有页面都如此。近期代码已经把一些内容拆成页签，不能简单说“完全没有逻辑”。更准确的问题是：拆分标准不稳定。有时按对象分，有时按流程分，有时按工具分；一个任务还可能跨越多个对象页面。仅换颜色、卡片或继续增加页签，不能解决这个问题。
02 / 有源码依据的问题
| 优先级 | 现象与证据 | 用户影响 | 本稿处理 |
|---|---|---|---|
| P0 | 期次页同时承担报名归属、学员、分组、群 SOP、成交回填；页签随课程类型和开课状态改变。assets/page-sessions.js:52 | 同叫“期次”的页面进入后却不同；老师不清楚当前在哪一步。 | 任务入口固定；班主任按一节课准备，运营按一期招生推进。 |
| P0 | 服务分级把“需关注 / 高价值 / 健康 / 沉默校友”作为互斥状态；另有本期招生 ABCD。assets/page-students.js:43 | 价值、活跃度和服务紧迫性不是同一维度；高价值学员也可能急需关注。 | 任务、经营标签、招生优先级分离；新稿不实际改变原数据规则。 |
| P0 | README 写“AI 只起草，人发送”；较新发送模块又描述倒计时到点自动发。README.md 与 assets/page-send.js:24,114 | 用户难以判断点击或设置后是否会触达学员。 | 本轮统一展示草稿 → 人工确认 → 结果；自动发送策略需另行业务确认。 |
| P1 | 学员详情包含考勤、企业商机、积分、照片等；工作台并列生日、朋友圈、课程与入班处理。assets/page-students.js:156、assets/page-care.js | 资料、洞察与待办竞争注意力；找到人后仍需判断下一步。 | 默认只展示当前任务，完整资料放入档案。 |
| P1 | 角色选择收入右下角“演示”浮层；班主任与运营有不同导航名称。assets/boot.js:35–48 | 评审时容易在错误角色中找功能，难理解职责边界。 | 页面固定显示当前角色，底部提供明确的评审视角入口。 |
| P1 | 引导脚本引用仓库中没有的 data-qa-local.js；README 说明该文件只在原作者本机。assets/boot.js | 拉取后缺少真实知识内容，不能据此评估知识助理是否可靠。 | 明确区分已知事实、审核建议和占位内容。 |
| P1 | 角色可见性在前端处理，代码注明“看不到 ≠ 进不去”；演示状态保存在 sessionStorage。assets/boot.js、assets/demo-state.js | 适合需求原型，不能当作有持久化和权限控制的 CRM 直接投入业务。 | 本次继续明确为静态稿；真正业务接入列为后续工程。 |
| P2 | 主页面装载大量模块及多层叠加 CSS；README 保留大量历史版本说明。 | 后续修改容易发生入口不一致和样式覆盖，文档不易作为现行规则来源。 | 新稿只用独立 HTML 与一份 CSS；报告区分现状、建议和待确认事项。 |
03 / 重新组织老师的工作
统一顺序：先看到任务 → 知道为什么 → 查看必需信息 → 明确处理结果 → 回到待办。每项任务必须有对象、原因、负责人、截止时间、完成标准。没有这些信息的“智能建议”不应直接算作待办。
| 角色 | 首页先回答 | 主要导航 | 不应抢占首页的内容 |
|---|---|---|---|
| 班主任 | 今天先服务谁？下一节课准备好了吗？ | 今日工作、我的班级、学员跟进、消息确认 | 全量企业库、经营分析、规则设置 |
| 招生运营 | 这一期卡在哪？交接给谁？ | 今日工作、招生准备、分组与助教 | 班主任生日关怀、长期考勤资料 |
| 助教 | 我的组员是谁？今天要做哪三件事？ | 我的小组 | 其他组、全量客户库、经营金额 |
班主任路径
招生与助教路径
资料仍保留，但从具体任务按需进入。课程产品 → 班/期 → 节仍是数据关系，不要求老师从首页逐层钻取才能办事。企业生态、财务开票、积分、渠道及系统设置不在此次核心 HTML 流程内；正式产品应按岗位补充二级入口，不能直接删除这些业务能力。
04 / 分类页应该怎么改
默认视图使用“待联系、待补课、待祝福”等可执行事项。一人可以有多个事项，但同一任务避免重复出现；“高价值”等经营标签放在档案中；招生 ABCD 只出现在具体期次，提供依据和人工复核。
保留原本有价值的分类解释，但不让老师先读长篇规则才能使用。新的分类规则属于产品建议，需业务负责人确认后再迁移数据；本次没有修改评分、配额或自动流转逻辑。
05 / HTML 交付范围
本稿共 22 个页面，包含报告；没有 JavaScript、接口、数据库或本地状态保存。链接负责页面导航，原生折叠面板展示分支。编辑、创建等未实现的动作明确禁用，结果页标为独立状态示例，不伪装已经发送或保存。
| 页面组 | 交付页面 |
|---|---|
| 班主任入口 | 今日工作、我的班级 |
| 课程执行 | 课程准备、出席名单、课堂签到、课后跟进、课堂资料 |
| 学员服务 | 学员跟进、档案列表、学员详情、补课跟进、生日关怀、分类说明 |
| 消息 | 消息确认、通知核对、成功与失败结果示例 |
| 运营与助教 | 招生工作台、招生准备、分组交接、我的小组、助教任务说明 |
| 分析 | 本报告，可通过浏览器打印另存为 PDF |
06 / 后续验收用具体任务
建议邀请至少 3 位实际老师，不先讲解，让他们完成以下任务。记录找入口时间、错误跳转、能否说清当前状态。以下是验收目标，不是本次已经测得的结果。
- 打开首页后 10 秒内，说出今天应优先处理的事项与原因。
- 从首页不超过 2 次页面跳转，找到通知正文和收件人。
- 能区分“草稿”“发送成功”“确认出席”，不把三者混为一谈。
- 在补课任务里，能说明无法确定时间时应约下次联系，而非直接完成任务。
- 招生运营能找到未分组学员；助教能说出本组负责人及问题转交对象。
07 / 上线前仍需明确的边界
- 通知到底采用人工确认、一次授权后定时发送，还是自动发送：需要统一规则与文案。
- 原四种服务状态是否迁移为多标签与任务队列，需要业务确认并设计迁移方案。
- 老师与助教实际权限、转交接收与失败重试，需服务端落实，不能只靠隐藏菜单。
- 真实知识内容、报名来源、历史考勤及微信通道仍需核实。本次没有接入这些系统。
08 / 本轮验证说明
已按静态交付检查页面链接、资源引用、HTML 结构及无脚本边界，并在服务器验证页面访问及文件一致性。CSS 提供桌面、窄屏和打印布局；浏览器本地访问被审批拒绝，因此没有完成截图、视觉排版和真实交互验收，不把响应式代码检查视作视觉验收通过。
原仓库保留用于追溯，新稿独立交付。所有人物、班级、人数和状态仅为虚构设计样例。