深色模式
5.5 整理并验收你的迁移作品：把经验留成下一次模板
走到这里，我们已经做过不少东西。
有从静态 HTML 走向后端和统计看板的热身项目，有接手改造并部署到校园内网的机房排座系统，也有本章的算法可视化页、本地机房故障台账和一页学科小工具任务书。
最后一篇不再开一个新项目。真正需要做的，是从这些作品中选一个，把它整理到过一段时间仍然能看懂、同事也能接手的程度。
项目数量不是迁移能力
用 AI 做出十个页面并不难。难的是回答这些问题：
- 它解决了谁的什么问题？
- 第一版为什么只做这些功能？
- 怎样证明它真的可用？
- 代码或数据出问题后怎样恢复？
- 换一位老师，能不能根据说明继续使用？
所以本篇只选择一个代表作品。它可以是 5.2 的冒泡排序可视化页，可以是 5.3 的本地故障台账，也可以从 5.4 的学科任务书继续完成自己的同等规模工具。
最终只保留四项核心证据
作品包不是文档竞赛。我们把前面出现过的材料压缩成四类。
| 核心证据 | 需要说清什么 |
|---|---|
| 一页项目任务书 | 问题、使用对象、首版范围、技术选择和暂不实现 |
| 一个可运行工具 | 对应哪个经过验收的 Git 节点 |
| 一份验收记录 | 模拟数据、边界情况、用户反馈和处理结果 |
| 一份运行与交接说明 | 怎样打开、数据在哪里、怎样恢复、有哪些限制 |
Git 提交属于过程证据，不需要再单独制作一份文档。六项能力量规也是检查角度，不需要为每一项新建文件。 把前面的材料合并成一页任务书
5.1 的问题筛选、项目迁移表、PRD 和范围裁剪不必分散保存。最终的一页任务书只要回答下面几项：
- 谁在什么场景使用。
- 目前最费时间或最容易出错的动作。
- 首版必须完成什么。
- 明确不做什么。
- 数据是否敏感，保存在哪里。
- 为什么选择单 HTML、本地工具或完整 Web。
- 使用什么模拟数据和动作验收。
- 什么情况下停止增加功能。
text
请作为项目审阅者，帮助我整理一个已经完成的迁移作品，不要新建项目。
请检查现有任务书、项目文件、Git 状态和验收记录，并告诉我：
1. 问题、使用对象和首版范围是否清楚。
2. 技术选择是否与数据和共享范围匹配。
3. 哪些内容可以合并成一页任务书。
4. 验收记录是否包含模拟数据、具体操作、用户反馈和处理结果。
5. 运行与交接说明还缺什么。
6. 哪些内容可以清理成下一个项目可复用的空白模板。
先给出整理建议和缺失项，未经我确认不要修改文件或 Git 历史。确认工具对应可用的 Git 节点
整理作品前，让 Agent 检查当前 Git 状态和最近的已验收提交。如果还有来源不明的改动，先说明、验收或单独处理。
同时再次检查环境变量文件、数据库和日志是否被排除，模拟数据与真实数据是否分开，以及项目说明是否与当前版本一致。
纯前端页面不需要数据库备份，但仍需要 Git 找回代码。本地故障台账除了 Git，还要保留导出的数据备份。
找一位真实使用者走一遍
作者自己知道按钮在哪里，很容易绕过不清楚的地方。找一位目标使用者按任务书操作，才能发现真正的问题。
不要只问“好不好用”，请记录使用设备、操作顺序、预期结果、实际结果和出现卡点的位置。
算法可视化页可以请一位同事按课堂脚本演示；本地故障台账可以请另一位老师登记、筛选和导出一组模拟记录。
记录一次验收发现及处理结果
这里不强制制造程序故障。一次有效的验收发现可以是按钮名称让人误解、投影不够清楚、CSV 中文乱码、范围太大需要删减，或者测试数据漏掉边界情况。
| 记录项 | 示例 |
|---|---|
| 验收发现 | 同事不知道“重置”会恢复哪组数字 |
| 原因判断 | 页面缺少当前数据来源提示 |
| 处理方式 | 让 Agent 只补充当前数组说明，不改算法 |
| 重新验收 | 同事能够正确说明重置后的状态 |
记录发现、判断、处理方式和重新验收结果即可。它比补写一段“项目一路顺利”更能证明老师掌握了迭代方法。
运行与交接说明要跟着工具类型变化
| 工具类型 | 运行与交接说明重点 |
|---|---|
| 单 HTML | 文件在哪里、怎样离线打开、怎样用 Git 恢复 |
| 本地数据工具 | 数据保存位置、导出备份、恢复和清空风险 |
| 完整校园 Web | 部署主机、访问地址、启动、日志、数据库备份和责任人 |
不要给单 HTML 页面虚构服务器部署，也不要因为本地工具没有服务器，就忽略数据导出和恢复。
用六项能力量规做最后检查
- 能选题：问题来自真实现场，使用对象明确。
- 能限界：首版与暂不实现内容清楚。
- 能指挥：Agent 先解释，老师确认后执行。
- 能验收：模拟数据、边界情况和目标用户动作都有记录。
- 能恢复：代码有 Git；涉及数据时有对应备份方法。
- 能交接：同事能根据说明找到工具、运行方式、数据位置和限制。
第一次不必达到专业团队的程度，但每一项都要有证据。暂时没有做到的内容，写清原因和下一步。
把具体作品清理成空白模板
text
校园工具模板/
├── 项目任务书.md
├── 验收记录.md
├── 运行与交接说明.md
└── 项目代码/
删除当前项目的设备编号、业务数据、账号、地址和密钥，只保留结构和检查问题。下一次遇到新需求时，从这套模板开始。 给未来 30 天留一个小动作
不要立刻列十个新项目。只写哪个工具值得继续维护、下一次只改哪一个小功能，以及哪些功能明确不继续扩张。
工具真正有人使用，才值得投入下一轮时间。无人使用的演示项目，及时停止也是一种成熟判断。
写在最后
我们从聊天框里的一句话出发，走过需求文档、Web 黑盒、IDE Agent、后端和数据库、Git、校园内网、备份恢复，再回到一个更朴素的问题：学校现场究竟需要什么。
各学科教师最不可替代的，不是记住某个框架或提示词，而是知道哪里真的需要改变、什么风险不能跨越、怎样让工具接受真实现场检验。
AI 让实现变快，中小学教师的判断让这种速度有方向、有边界，也真正服务于教学。
flowchart LR A[选择一个代表作品] --> B[合并一页任务书] B --> C[目标用户真实验收] C --> D[记录发现与处理] D --> E[完成运行与交接说明] E --> F[清理成下一次模板]
一次成功不必变成十个项目。把这一套方法留住，下一次你仍然知道从哪里开始，这就已经是很扎实的迁移能力。
封面