深色模式
5.1 先选对问题：把前四章经验整理成项目迁移表
第四章结束时，机房排座系统已经不只是“能打开”。
我们检查了部署主机，完成生产运行和内网试用，也做过重启、备份恢复和责任交接。
很多老师走到这里，会马上想到下一件事：
既然排座系统能做出来，我是不是可以让 AI 再做一个成绩系统、报修系统或教学平台？
可以，但先别急着开新项目。
真正值得从前四章带走的，不是排座系统的代码，而是一套判断问题、控制范围、指挥 Agent 和完成验收的方法。
这套方法不属于某一个学科。英语练习、古诗自测、科学实验记录、课堂分组和教研数据整理，都应该先做同样的判断，再决定是否值得写代码。
迁移不是更换几个业务名词
把“学生”改成“设备”，把“座位”改成“故障”，并不等于完成迁移。
新的校园问题可能有不同的使用者、数据风险和共享范围。照搬排座系统的登录、数据库和部署方式，常常会把一个简单需求做得过重。
前面其实已经经历过两种不同情形：
- 3.5 从静态 HTML 和 PRD 出发，逐步补齐后端和数据保存。
- 3.6 接手一个已有项目，只围绕真实小需求完成局部改造。
因此，面对新需求时先问：
text
这是需要从零建立一个最小工具，
还是接手已有页面、表格或项目继续改造？这一步比先选框架更重要。
先筛选值得做的问题
不是每个校园痛点都适合成为第一次独立项目。
可以先用下面几项做筛选：
| 判断项 | 建议追问 |
|---|---|
| 发生频率 | 这个问题每周、每月还是一年才出现一次 |
| 受益对象 | 是自己、一两位同事，还是全校师生 |
| 现有做法 | 现在靠纸条、Excel、微信群还是口头传递 |
| 重复劳动 | 哪一步最费时间、最容易漏掉 |
| 数据敏感度 | 是否涉及学生、成绩、账号或设备配置 |
| 失败后果 | 工具算错或停用会造成什么影响 |
| 验收条件 | 能否使用模拟数据和真实动作检查 |
| 维护责任 | 完成后谁会持续使用和负责 |
第一次迁移优先选择：
- 高频发生。
- 使用范围较小。
- 结果能够直接看见。
- 可以使用模拟数据验收。
- 出错后果可控。
- 已经有一位明确使用者。
真实成绩、财务、考勤、全校统一身份和关键审批，不适合作为第一次独立练习。AI 可以加快开发，但不会降低这些业务本身的责任。
把“工具矩阵”真正画出来
新需求不一定都要做成完整 Web 系统。先看数据要不要保存、要不要多人共享。
| 工具形态 | 适合的情况 | 典型例子 |
|---|---|---|
| 单 HTML 页面 | 不保存共享数据，主要展示和交互 | 英语练习、古诗自测、时间线排序、算法可视化 |
| 本地数据工具 | 一位老师使用，数据保存在个人电脑 | 实验观察记录、个人资料台账、机房故障台账 |
| 完整校园 Web | 多人共享、长期保存、跨设备访问 | 活动报名、协作登记、多人共享报修 |
这不是从低级到高级的升级路线。
单 HTML 能解决的问题，就不要主动增加数据库；本地工具已经够用，就不要为了“看起来专业”先上服务器。技术越重，后面的权限、备份、部署和交接责任也越多。
把判断合并成一页任务书
前面学习过问题筛选、项目迁移表和 PRD。第五章不再要求为每一步新建一份文档，而是把关键内容合并到一页任务书。
markdown
# 校园工具项目任务书
## 真实问题
谁在什么场景遇到什么麻烦？
## 当前流程
现在怎样处理，哪一步最费时间？
## 首版范围
- 必须完成：
- 明确不做：
## 数据与边界
- 输入和输出：
- 是否保存：
- 是否敏感：
- 谁能使用：
## 工具形态
单 HTML / 本地数据工具 / 完整校园 Web
选择理由：
## 模拟数据与验收
- 使用什么模拟数据：
- 完成哪些真实动作才算通过：
- 什么情况下停止增加功能：一页不是绝对的页数限制，而是提醒老师不要在项目开始前写成几十页方案。它必须足以让 Agent 看懂，也必须让老师自己能够解释。
做一次“复用、改变、删除”
选择新项目后，拿它和前面的项目做一次对照。
| 判断 | 可以写什么 |
|---|---|
| 复用 | Agent 先读后改、模拟数据验收、Git 阶段存档 |
| 改变 | 使用角色、数据字段、异常情况和运行位置 |
| 删除 | 不需要的登录、后端、数据库、统计或部署 |
例如，冒泡排序可视化页可以复用 PRD、Agent 计划和 Git，但应该删除后端、数据库、账号和服务器部署。
本地故障台账需要保存数据，因此要增加数据位置、导出和恢复说明；但只有一位老师使用时，仍然可以删除多人账号和内网服务器。
先让讨论型 AI 追问
需求还模糊时，先让讨论型 AI 帮助发现遗漏，不要立即要求写代码。
text
我是学校的一名教师，正在为自己的课堂或校园工作选择一个新的 Vibe Coding 项目。
请先作为产品顾问追问我，不要写代码。请重点询问：
1. 谁在什么场景使用。
2. 现在的流程和最费时间的步骤。
3. 输入、输出和需要保存的数据。
4. 是否涉及学生、成绩、账号等敏感信息。
5. 是个人使用还是多人共享。
6. 出错后会造成什么影响。
7. 第一版必须完成什么，哪些内容暂时不做。
8. 我能用哪些模拟数据和真实动作验收。
讨论清楚后，请帮我整理成一页项目任务书，
并判断它更适合单 HTML、本地数据工具，还是完整校园 Web 项目。
请说明判断理由、最小版本和停止条件。老师确认任务书后，再把它放进独立项目目录，交给 IDE Agent 审阅和执行。
用三个例子检查选择
冒泡排序可视化页
它不需要保存学生数据，也不需要多人共享。正确路线是单 HTML 页面，重点验收算法状态和课堂可读性。
本地机房故障台账
它需要保存和查询记录，但首版只有一位维护老师使用。正确路线是本地数据工具，重点验收数据位置、导出和恢复。
多人共享报修平台
只有多位老师确实需要在不同电脑同时填写，而且学校已经确认主机、权限和维护责任时，才进入完整校园 Web 路线。
同一个“报修”需求，因为使用人数不同，技术形态也会不同。这就是项目迁移表真正要帮助老师判断的事。
这一篇留下什么
本篇最终只留下：
- 一页项目任务书。
- 任务书中的“复用、改变、删除”说明。
- 一项明确的工具形态选择。
- 首版停止条件。
flowchart LR
A[筛选真实校园问题] --> B[判断数据与共享范围]
B --> C{选择工具形态}
C -->|不保存共享数据| D[单 HTML]
C -->|数据留在本机| E[本地数据工具]
C -->|多人共享| F[完整校园 Web]
D --> G[形成一页任务书]
E --> G
F --> G
下一篇，我们先走风险最低的单 HTML 路线，用冒泡排序可视化页完整演示一次迁移。重点不是做出炫目的动画，而是把一个教学目标做清楚、验收到位。
封面