深色模式
5.3 第二种迁移：做一个数据留在本机的机房故障台账
上一节，我们用一个单 HTML 页面把冒泡排序的过程变成了可以单步观察的课堂材料。
那个项目不需要保存共享数据，浏览器打开就能使用。现在换一个更接近日常维护的场景：机房设备故障记录。
机房台账是作者熟悉的个人数据工具样板，不是各学科老师都要做的业务。科学实验观察、体育训练记录、作品评价草稿或个人资料整理，只要由一位老师使用、数据留在本机，都可以沿用这一章的方法。
很多老师的故障记录散落在微信群、便签和临时 Excel 中。真正麻烦的不是少一个“智能平台”，而是过几天以后找不到某台电脑到底坏过什么、修到哪一步。
这一次，我们不直接建设多人报修系统。先做一个只在维护老师自己电脑上使用的本地故障台账。
先选中间路线，不急着上服务器
5.1 把校园工具分成了三类：
text
不保存共享数据：单 HTML 页面
数据留在个人电脑：本地数据工具
多人共享并长期保存：完整校园 Web 项目机房故障台账可以从第二类开始。
它需要保存数据，但首版只有一位维护老师使用，不需要账号、多人并发和校园服务器。这样既能解决历史记录难找的问题，也不会重新背上一套部署和权限负担。
先证明一个人真的愿意持续使用，再判断是否值得升级为多人系统。
## 首版只做四件事 本地台账的首版范围要非常克制：
- 登记一条设备故障。
- 按设备编号、位置或状态查询。
- 把状态改为待处理、处理中或已解决。
- 导出 CSV，作为备份或后续分析材料。
照片、消息通知、二维码、备件库存、用户角色和全校报修都不进入首版。
| 功能 | 首版是否实现 | 原因 |
|---|---|---|
| 故障登记 | 是 | 解决记录入口分散的问题 |
| 查询和筛选 | 是 | 能快速找到设备历史 |
| 状态更新 | 是 | 知道问题有没有处理 |
| CSV 导出 | 是 | 给本地数据留一条退路 |
| 用户登录 | 否 | 首版只有一位维护老师 |
| 多人同时填写 | 否 | 需要后端和权限，暂不增加 |
| 图片附件和通知 | 否 | 会明显扩大存储和维护范围 |
数据字段够用就好
| 字段 | 用途 |
|---|---|
| 设备编号 | 找到具体设备 |
| 位置 | 例如第一机房第 12 号机 |
| 故障类型 | 网络、显示器、系统、键鼠或其他 |
| 故障现象 | 用简短文字记录现场 |
| 当前状态 | 待处理、处理中、已解决 |
| 记录时间 | 知道问题何时出现 |
| 处理结果 | 记录怎样解决或为什么暂未解决 |
首版不收集学生姓名、账号密码、交换机配置和远程控制信息。设备故障工具也有数据边界，不能因为不是成绩系统就什么都往里放。
先让 Agent 解释数据放在哪里
浏览器本地存储、IndexedDB 和本地文件都可能实现保存，但它们的容量、清空风险和备份方式不同。老师不需要先学这些名词，先让 Agent 用结果来解释。
text
请先阅读机房故障台账任务书，不要立即写代码。
这是给一位负责机房维护的老师在本机使用的数据工具。
首版只做故障登记、查询筛选、状态更新和 CSV 导出，
不做用户登录、多人共享、服务器部署、照片和消息通知。
请先说明：
1. 最小数据字段和三种状态是否足够。
2. 数据适合保存在什么本地位置，各方案的容量、备份和清空风险。
3. 准备怎样拆成三个可独立验收的阶段。
4. 模拟数据应覆盖哪些正常与异常情况。
5. 怎样验证刷新、重新打开、导出和恢复后的数据一致。
6. 如果以后需要多人同时使用，哪些条件满足后才值得升级为 Web 项目。
先给出计划、数据位置、风险和验收步骤，等我确认后再修改文件。重点不是推荐最先进的数据库，而是确认关闭页面后数据是否还在、清除浏览器数据会不会丢失，以及怎样导出和恢复。
第一阶段：登记和列表
第一阶段只完成表单和记录列表。准备几条完全模拟的数据：
- PC-01：第一机房 1 号机，无法开机。
- PC-12：第一机房 12 号机，网络断开。
- DISPLAY-01：教师机显示器，画面闪烁。
验收时检查必填提示、提交后的列表、刷新后的数据和默认状态。通过后，让 Agent 解释修改并提交 Git。Git 保存的是页面和处理逻辑，不是浏览器中已经产生的故障数据。
第二阶段：查询和状态更新
第二阶段加入按设备编号、位置和状态筛选，并允许状态在三个值之间更新。
测试查询不存在设备、状态更新后刷新、已解决设备再次出现问题以及清除筛选等情况。如果 Agent 想顺手加入用户角色、操作日志或复杂审批，提醒它只处理当前阶段。
第三阶段：导出、备份和恢复
CSV 导出不是装饰功能，它是本地数据最简单的退路。
导出后核对条数、中文和字段。然后安排一次模拟恢复：先让 Agent 说明恢复会覆盖还是合并当前数据，老师确认后再执行。
| 验收动作 | 通过标准 |
|---|---|
| 刷新页面 | 记录仍然存在 |
| 关闭并重新打开 | 本地记录可以继续读取 |
| 按条件筛选 | 数量和内容正确 |
| 更新状态 | 刷新后保持新状态 |
| 导出 CSV | 条数、中文和字段正确 |
| 使用模拟备份恢复 | 恢复结果与备份一致 |
## 什么时候才值得升级为 Web 项目 只有出现多位老师同时登记、不同电脑需要同一份记录、需要明确修改权限，或者已经有固定主机和维护责任人时，才考虑升级。
升级时不需要推倒重来。保留任务书和数据字段，让 Agent 重新评估后端、数据库、权限和部署，再沿用第三、第四章的流程。
把这次迁移留下来
本篇最终只保留四类核心成果：一页任务书、一个可运行工具、一份验收记录和一份本地运行与数据备份说明。
flowchart LR
A[故障记录分散] --> B[选择本地数据路线]
B --> C[登记与列表]
C --> D[查询与状态更新]
D --> E[导出和恢复验收]
E --> F{是否真的需要多人共享}
F -->|否| G[继续本地使用]
F -->|是| H[再评估完整 Web 项目]
下一篇不再让老师照着机房案例继续开新项目。我们会把“角色、流程、数据、异常、验收”迁移到英语练习、古诗时间线、实验记录等学科场景，先形成一页属于自己的学科小工具任务书。
封面