深色模式
4.4 能持续使用才算上线：重启、备份、恢复与交接
上一节，两三位老师已经从办公室和机房完成了小范围试用。页面能打开，登录、排座、保存和投屏也都走通了。
项目终于上线了吗？
还差最后一场考试。
Windows 更新可能让电脑重启，终端窗口可能被人关掉，MySQL 服务可能没有自动恢复，负责人也可能请假或调岗。如果只有项目作者知道怎样重新启动，那么这个工具仍然只是一次成功演示。
本篇要把“上线”重新定义为：能访问、能恢复、数据找得回来、权限边界清楚，而且不只一个人知道怎样处理。
先让 Agent 做持续运行检查
不要等项目停止后才第一次寻找日志和启动方法。趁小范围试用刚刚通过，让 Agent 先只读检查当前现场。
text
当前机房排座系统已经完成小范围内网试用。请先做持续运行和交接检查，
不要立即修改系统。
请用中文报告：
1. 当前生产服务怎样启动、停止、重启和确认运行状态。
2. 日志在哪里查看，怎样在提供给 AI 前隐藏账号、IP、路径、密钥和学生信息。
3. MySQL 中哪些数据需要备份，建议保存到哪里，恢复操作会覆盖什么。
4. 电脑或服务重启后，数据库和 Web 项目应该按什么顺序恢复。
5. 默认管理员密码、首次登录或注册策略、NEXTAUTH_SECRET、NEXTAUTH_URL、
管理入口和只读分享是否存在风险。
6. 更新项目前应该保存哪个 Git 基线、备份哪些数据，失败后有哪些恢复选择。
7. 建议写入上线交接卡的内容。
请先给出检查结果、风险和演练计划。未经我确认，不要创建系统服务，
不要修改开机启动，不要执行数据库备份或恢复，不要提交、推送或回退 Git。检查结果不是让老师记住一堆命令，而是要生成几条任何接手人都能读懂的操作路径。
先做一次服务重启
第一项演练只停止 Web 项目，不重启电脑，也不动数据库。
让 Agent 先说明它准备怎样停止当前生产服务、怎样确认端口已经释放，以及重新启动后从哪里查看日志。老师确认不会影响其他项目后，再允许执行。
服务重新启动后，不要只刷新首页。用另一台电脑完成下面几步：
- 登录测试账号。
- 打开已有的模拟布局和班级。
- 调整两个测试座位并保存。
- 刷新页面，确认数据仍然存在。
- 打开投屏和只读分享页面。
这次通过，说明老师已经拥有最小的“停止后重新启动”能力。
如果项目无法启动，把停止前、启动时和失败后的完整日志交给 Agent。不要因为端口占用就删除数据库，也不要因为一条依赖警告就重装整台主机。
再做一次电脑重启
服务重启通过后，再安排一次不会影响正常教学的电脑重启演练。
重启前先记录：
- 当前可用 Git 提交。
- 当前项目端口和访问地址。
- MySQL 服务状态。
- 测试布局和测试排座结果。
- Web 项目的启动方式。
电脑重新开机后，先检查 MySQL，再检查 Web 服务。主线项目依赖数据库，如果只启动页面服务而数据库尚未恢复，登录和数据读取仍然会失败。
完成后从另一台电脑重复登录、读取、保存和刷新流程。IP 地址如果发生变化，也要更新访问记录，并与 4.1 中确认的地址策略对照。
自动启动不是越早越好
小范围试用阶段，保留一套清楚的人工启动方法并不丢人。相比一个没人知道怎样撤销的“自动启动”，可理解、可检查的操作更可靠。
确实需要开机恢复时，可以让 Agent 根据当前 Windows 版本和学校管理要求提出任务计划程序或系统服务方案。但它必须先说明：
- 需要什么管理员权限。
- 数据库和 Web 服务的启动顺序。
- 日志输出到哪里。
- 失败后怎样停止和撤销。
- 是否会影响电脑上的其他任务。
老师和设备责任人确认后再执行，不要把“设置为开机启动”当作一句无风险的快捷指令。
日志要完整，也要先脱敏
服务出问题时，日志是 Agent 判断现场的重要依据。只截最后一句“启动失败”，往往会丢掉真正原因。
但完整日志也可能包含：
- 本机用户名和项目路径。
- 局域网 IP 和数据库地址。
- 账号、会话或请求参数。
- 学生姓名、班级和导入文件名。
- 环境变量或连接错误中的敏感片段。
把日志交给公开 AI 前，应先删除或替换这些内容，同时保留错误发生前后的完整顺序。可以用 [已隐藏IP]、[已隐藏账号] 标记替换位置，不要直接删到看不懂上下文。
Git 保护代码，备份保护数据
这是第四章最重要的一条分界线。
text
Git：项目代码改坏后，找回某个可用版本。
MySQL 备份：班级、学生、布局和排座数据丢失后，找回运行数据。把项目提交并推送到 Gitee，不代表数据库已经备份。反过来，只有数据库备份，也不能找回某次错误修改前的代码。
| 要保护的内容 | 主要保护方式 | 不能替代什么 |
|---|---|---|
| 页面、接口、配置模板和项目代码 | Git 提交与远程私有仓库 | 不能找回 MySQL 中的业务数据 |
| 班级、学生、布局和排座记录 | MySQL 备份与恢复 | 不能撤销错误代码修改 |
.env 中的密钥和密码 | 受控保管并按需重新配置 | 不应进入 Git 或公开备份 |
| 部署与维护步骤 | 部署说明和交接卡 | 不能代替代码或数据备份 |
用模拟数据做一次备份与恢复
只生成一个备份文件，却从未验证能否恢复，并不能证明数据有退路。
第一次演练继续使用模拟数据，并尽量在测试数据库或老师确认的安全范围中完成。先让 Agent 给出方案：
text
请为当前 MySQL 数据库设计一次仅使用模拟数据的备份与恢复演练。
先说明：
1. 准备备份哪个数据库、哪些数据，怎样确认不是正式数据库。
2. 备份文件准备保存在哪里，谁可以访问。
3. 备份文件是否包含学生信息，应该怎样保护。
4. 恢复操作会创建新数据库还是覆盖现有数据。
5. 演练前需要保存哪个 Git 节点和哪些现场记录。
6. 恢复完成后应该按什么业务流程验收。
7. 如果任何条件不清楚，应该在哪一步停止。
先给出方案和风险，不要执行备份、删除、覆盖或恢复操作。老师确认目标确实是测试数据、备份位置合规、恢复不会覆盖正式数据后，再让 Agent 分步执行。
恢复完成后，重新检查：
- 测试账号能否登录。
- 模拟班级和学生是否存在。
- 机房布局能否打开。
- 排座结果能否读取和调整。
- 新的保存操作能否成功。
备份文件本身也属于敏感数据。以后使用真实数据时，不能把它上传到公开仓库、公开网盘或公开 AI 对话。
再检查一次账号和访问边界
小范围试用通过后，需要把示例配置和真实使用边界对照一次。
至少让 Agent 检查：
- 示例默认管理员账号和密码是否已经更换。
NEXTAUTH_SECRET是否为随机密钥。NEXTAUTH_URL是否与正式内网访问地址一致。- 当前首次登录或注册策略会不会让无关人员创建账号。
- 管理页面和只读分享分别允许做什么。
.env、日志、数据库和导出文件是否可能从静态目录被访问。
Agent 可以解释代码中的现状和提出修改计划，但谁应该拥有管理员权限、哪些机房可以访问，仍然要由老师和学校决定。
如果权限策略不符合试用范围，不要一边使用真实学生数据一边等待以后再改。继续保留模拟数据，先完成权限调整和回归验收。
更新项目也要有固定节奏
项目上线后仍然会继续改功能。每次更新都建议沿用下面的顺序：
text
确认当前可用 Git 节点
-> 备份数据库
-> Agent 解释本次改动和部署影响
-> 老师确认
-> Agent 构建并重启服务
-> 老师跨设备验收
-> Agent 提交 Git 并报告结果代码回退和数据库恢复必须分别判断。
如果只是页面样式改坏，可能只需要回到之前的 Git 提交。如果更新同时改变了数据库结构，简单回退代码未必能让旧结构恢复，必须先让 Agent 说明兼容性和可能丢失的数据。
任何会覆盖数据库、丢弃未提交修改或强制回退的操作，都继续遵守“先解释、再确认、后执行”。
留下一张启动与故障处理卡
把最常用的恢复信息压缩成一页，让不熟悉项目的同事也知道从哪里开始。
| 项目 | 应记录的内容 |
|---|---|
| 正式访问地址 | 校内地址、端口和可访问范围 |
| 部署主机 | 电脑名称、所在位置和主机责任人 |
| 启动与停止 | 按实际验证过的步骤记录 |
| 状态检查 | 怎样判断 MySQL 和 Web 服务是否运行 |
| 日志位置 | 在哪里查看，提交 AI 前怎样脱敏 |
| 备份位置 | 受控位置、备份频率和负责人 |
| 当前可用版本 | Git 提交信息和远程仓库情况 |
| 故障联系 | 项目问题、设备问题、网络问题分别找谁 |
| 禁止操作 | 不关闭整体防火墙、不公开密钥、不直接覆盖数据库 |
卡片里不要写真实数据库密码和完整密钥。它告诉接手人“去哪里、按什么顺序处理”，敏感凭据另行受控保管。
用上线验收单收尾
现在，可以用一张清单判断项目是否仍处于试运行，还是已经具备持续使用条件。
| 验收项目 | 通过标准 |
|---|---|
| 生产运行 | 使用正式构建和生产启动方式，不依赖开发服务器 |
| 跨设备访问 | 目标办公室和机房能够完成真实业务流程 |
| 服务重启 | Web 服务停止后能够按说明恢复 |
| 电脑重启 | MySQL 和 Web 服务能够按顺序恢复 |
| 数据恢复 | 使用模拟数据完成过备份与恢复演练 |
| 权限边界 | 默认密码已更换，管理和只读范围明确 |
| 敏感配置 | .env、数据库、日志没有进入公开仓库 |
| 更新流程 | 更新前有 Git 基线和数据备份，更新后会跨设备验收 |
| 责任交接 | 主机、日志、备份和故障联系人已经记录 |
这些项目通过后，机房排座系统才从“作者电脑上能跑”走到了“校园里有人能用、出问题有人能处理”。
flowchart LR A[小范围试用通过] --> B[服务与电脑重启] B --> C[模拟数据备份恢复] C --> D[权限与配置检查] D --> E[形成故障卡和交接说明] E --> F[具备持续使用条件]
到这里，我们已经完成了一条完整的 Vibe Coding 路线：从校园痛点出发，写清需求，让 Agent 接手项目，小步修改和验收，用 Git 保存可用节点，再完成部署、内网试用、数据恢复和责任交接。
下一章要做的，不是再从头重复一个排座系统，也不是默认给每个需求都加上后端和数据库。我们会先判断一个新问题更适合单 HTML、本地数据工具，还是完整校园 Web 项目，再用离线算法可视化页和本地机房故障台账练习两种更轻的迁移路线。
最后，读者会从这些练习中选择一个代表作品，整理任务书、验收记录和运行说明，把本次经验留成下一次还能继续使用的模板。真正可以复用的，从来不只是一份代码，而是老师已经掌握的选择、协作、验收和交接方法。
封面