深色模式
4.1 先决定部署在哪里：校园上线前的主机与权限检查
第三章结束时，机房排座系统已经用模拟数据完成验收，也保存了一个可以回退的 Git 节点。
接下来很容易产生一种冲动：既然项目已经能跑，那就赶紧把它复制到学校电脑上，再让 Agent 帮忙安装环境、开放端口。
先别急。
老师自己的笔记本会休眠、会带回家；办公室电脑可能没有管理员权限；机房电脑和办公室电脑也未必在同一个网段。项目在开发电脑上能打开，只能说明功能基本可用，并不代表它已经具备校园上线条件。
这一篇不急着安装任何软件。我们先完成一项更重要的工作：把项目准备放在哪里、给谁用、由谁负责说清楚，并形成一张部署条件确认单。
从 Git 存档开始，不拿半成品去部署
部署前的第一个动作，不是复制文件，而是回到 3.7 建立的 Git 安全带。
先用 IDE 打开机房排座项目，让 Agent 确认当前版本就是老师已经验收过的可用节点，同时检查有没有尚未确认的改动和敏感文件风险。
text
请先只读检查当前项目，不要修改文件，也不要执行提交、回退、安装或部署。
请用中文告诉我：
1. 当前分支和最近一次已验收的 Git 提交是什么。
2. 现在是否存在尚未提交的修改、新增文件或删除文件。
3. .gitignore 是否排除了 .env、数据库文件、日志和临时文件。
4. 当前目录中是否可能包含数据库密码、登录密钥或真实学生数据。
5. 这个版本是否适合作为部署规划的起点。
先解释检查结果，等我确认后再进行任何操作。如果 Agent 报告还有未提交改动，就先弄清这些改动从哪里来，并完成验收或另行处理。不要把一个“可能能用”的工作目录直接搬到正式主机上。
这里还要分清两种保护：Git 保存的是项目代码和配置模板的版本，数据库备份保护的是系统运行后产生的数据。前者已经在 3.7 建立，后者会在 4.4 正式完成，不能用一次 Git 提交代替数据库备份。
先回答三个问题，再选择主机
同一个项目，用一天、试用两周和长期运行，对电脑的要求完全不同。老师先不要被“服务器”“Linux”这些词带着走，只要回答三个朴素的问题：
- 给谁用：只有自己演示，还是两三位同事一起试用？
- 在哪里用：只在当前电脑，还是办公室和机房都要访问？
- 要用多久：临时展示几小时，试用一段时间，还是以后每天都要用？
| 使用目标 | 典型场景 | 对主机的基本要求 |
|---|---|---|
| 短期演示 | 老师自己向同事展示功能 | 演示期间保持开机，暂不追求固定地址和长期维护 |
| 小范围试用 | 两三位信息科技老师在办公室或机房使用 | 校内常开、地址相对稳定、有人负责重启，网络访问经过确认 |
| 长期运行 | 多位教师持续使用，系统中逐渐积累业务数据 | 稳定主机、明确责任人、启动恢复、备份恢复和故障处理机制 |
本书接下来的默认目标是第二种：先让两三位老师在校园内网小范围试用。 这个范围足够验证真实流程，又不会一开始就把项目推到全校使用的复杂程度。
三种放置位置，条件并不一样
确定使用目标后，再比较手头真正拥有的设备。
| 放置位置 | 适合什么情况 | 主要问题 | 本书建议 |
|---|---|---|---|
| 老师个人电脑 | 自己开发、临时演示、短时间测试 | 会休眠、关机或带离学校，其他人访问依赖这台电脑一直在线 | 适合短期演示，不作为持续试用的默认主机 |
| 校内常开 Windows 主机 | 两三位老师在内网试用，学校暂时没有专门运维人员 | 需要确认管理员权限、休眠策略、端口、防火墙、地址变化和责任人 | 非技术老师小范围试用的默认路线 |
| 学校已有 Linux 服务器 | 学校已经有服务器、维护人员和明确的部署流程 | 需要按现有运维规范申请资源、权限和网络策略 | 有现成条件时采用，不要求老师从零搭建 |
选择校内常开 Windows 主机，不是因为它在所有场景中都最好，而是因为老师通常看得见、够得着，也更容易找到谁负责开机和重启。对第一次校园试用来说，可操作、有人管，比追求一套听起来更“专业”的环境重要得多。
WSL 和 Linux 不是上线必修课
有些教程一谈部署，就先让读者安装 WSL、虚拟机或 Linux。它们当然有价值，但不会自动让校园项目更稳定。
对当前项目来说，额外引入 WSL，还要继续判断虚拟化是否可用、服务如何随电脑启动、Windows 与 WSL 之间怎样转发网络、数据库到底放在哪一侧。原本只需要确认一台主机的问题，可能因此多出一层环境。
所以，本书不把 WSL 当作必经步骤。学校已经有 Linux 服务器和维护人员，或者项目明确只能在 Linux 环境运行时，再让 Agent 按学校现有规范给出可选路线。
让 Agent 先做一次只读“体检”
主机方向基本明确后，还不能马上安装。先让 IDE Agent 阅读项目自身的说明和配置，列出它稳定运行需要什么。
机房排座系统的主线技术包括 Next.js、Node.js、MySQL、Prisma 和 NextAuth。Agent 还需要检查 README.md、package.json、.env.example、Prisma 配置与启动脚本，确认实际使用的端口、环境变量、磁盘空间和外部网络依赖。
可以把下面这段话交给 Agent：
text
请先只读检查当前机房排座项目的 README.md、package.json、.env.example、
Prisma 配置和启动脚本，不要安装软件，不要修改系统设置，也不要开放端口。
我准备把它部署到学校内网，先给两三位老师试用。请用非技术老师能理解的话说明：
1. 这个项目稳定运行需要哪些软件、数据库、端口和环境变量。
2. Next.js、Node.js、MySQL、Prisma 和 NextAuth 在项目中分别负责什么。
3. 是否需要访问校外网站，断网后哪些功能可能受影响。
4. 放在个人电脑、校内常开 Windows 主机、已有 Linux 服务器上，
分别需要什么条件、存在哪些风险。
5. 哪些操作需要管理员权限或学校信息中心确认。
6. 电脑重启、休眠、断电和 IP 地址变化会造成什么影响。
7. 你推荐哪条路线，理由是什么。
最后给出“检查结果、推荐路线、前置条件、风险、预计操作、待人工确认事项”。
先解释方案，等我确认后再执行任何修改。Agent 的报告是技术体检结果，不是最终决定。它可以从项目文件里看出需要什么，却不知道学校是否允许开放端口，也不知道办公室与机房之间是否隔着不同网段。这些信息必须由老师、设备责任人或学校信息中心确认。
不要把敏感信息发给公开 AI
让 Agent 检查环境变量的名称和用途即可，不要把真实的 .env 内容、数据库密码、NextAuth 密钥、管理员账号或真实学生数据粘贴到公开 AI 对话中。首次部署测试继续使用模拟数据。
技术能不能跑，还要经过校园条件确认
接下来，老师要带着 Agent 的体检报告去核对真实条件。下面这些问题，不能靠 Agent 猜：
- 当前账号有没有管理员权限，谁可以批准安装 Node.js、MySQL 等软件。
- 这台电脑是否允许长期运行，会不会自动休眠，放假或夜间是否断电。
- 电脑的 IP 地址是否可能变化，能否申请相对固定的校内地址。
- 项目预计使用的端口能否开放，Windows 防火墙规则由谁确认。
- 办公室和机房是否处于不同网段，跨网段访问是否需要信息中心处理。
- 谁负责日常开机、服务重启和故障联系，负责人不在时找谁。
这里尤其要守住网络边界。发现跨网段访问不通时，不要让 Agent 帮忙“绕过限制”，也不要自行关闭防火墙。把访问对象、主机地址和预计端口整理清楚，再按学校流程请信息中心判断。
填好部署条件确认单
现在，把前面的判断集中到一张表里。这张表不是写给服务器工程师看的技术档案，而是老师、设备责任人和信息中心都能核对的共同依据。
| 确认项目 | 本校实际情况或结论 | 由谁确认 | 状态 |
|---|---|---|---|
| 使用范围 | 例如：两三位信息科技老师，小范围内网试用 | 项目负责老师 | 待填写 |
| 运行时长 | 临时演示、阶段试用或长期运行 | 项目负责老师 | 待填写 |
| 部署主机 | 电脑名称、所在办公室或机房，不只写“服务器” | 设备责任人 | 待填写 |
| 操作系统 | Windows 版本；如使用现有 Linux 服务器，写明管理部门 | 设备责任人 | 待填写 |
| 主机责任人 | 谁负责开机、重启和日常查看 | 项目组 | 待填写 |
| 管理员权限 | 当前账号是否具备；安装软件由谁批准和执行 | 设备责任人或信息中心 | 待填写 |
| 项目运行条件 | Agent 检查出的 Node.js、MySQL、Prisma、NextAuth 等要求 | 项目负责老师 | 待填写 |
| 数据库位置 | 数据库准备放在哪台主机，由谁管理 | 项目组或信息中心 | 待填写 |
| 预计端口 | 由项目配置和 Agent 检查得出，尚未批准时注明“待审批” | 信息中心 | 待填写 |
| 预计访问地址 | 主机名或校内 IP 加端口；地址是否可能变化 | 信息中心 | 待填写 |
| 访问范围 | 仅本机、同办公室、机房，还是其他校内网段 | 项目负责老师与信息中心 | 待填写 |
| 网络审批 | 开放端口、防火墙和跨网段访问是否获准 | 信息中心 | 待填写 |
| 休眠与断电策略 | 是否关闭自动休眠，夜间和假期是否断电，来电后谁处理 | 设备责任人 | 待填写 |
| 外部网络依赖 | 断网时是否仍能登录和完成核心业务 | 项目负责老师 | 待填写 |
| 备份位置 | 先写计划位置；数据库备份与恢复在 4.4 验证 | 项目组 | 待填写 |
| 故障联系人 | 服务打不开、主机离线、网络不通分别联系谁 | 项目组与信息中心 | 待填写 |
填写时不要为了让表格显得完整而猜答案。暂时不确定的项目就写“待设备责任人确认”或“待信息中心审批”，它们正是部署前需要解决的条件。
当这张确认单至少明确了使用范围、部署主机、主机责任人、管理员权限和网络审批路径，老师就可以把它连同 Agent 的项目体检报告一起交回 IDE Agent，让它生成下一步计划：
text
下面是已经由相关人员核对的部署条件确认单。
请根据确认单和当前项目实际配置，整理下一步部署计划。
请逐项说明准备做什么、为什么要做、可能影响什么，以及完成后怎样验证。
涉及安装软件、修改环境变量、数据库配置、端口、防火墙或系统启动项时，
必须先解释并等待我逐步确认，不要一次性执行。这时仍然遵守第三章已经建立的顺序：
text
Agent 先检查并解释
-> 老师确认校园条件和操作影响
-> Agent 再执行
-> Agent 报告结果flowchart LR A[确认使用范围] --> B[比较部署位置] B --> C[Agent 检查项目条件] C --> D[老师确认权限与责任] D --> E[形成部署条件确认单]
先把路线选对，再开始上线
老师不必先成为服务器管理员，但要对使用范围、主机条件和责任边界心里有数。对本书的小范围试用主线，如果学校没有现成的 Linux 运维条件，优先选择一台校内常开、有人负责的 Windows 主机；Linux 服务器则保留为学校已有资源时的可选分支。
部署条件确认单一旦填清，后续操作就不再是一串来历不明的命令。下一篇，我们将以这台已经确认的 Windows 主机为基础，让 Agent 继续检查正式构建、环境配置、数据库和外部资源依赖，把项目稳稳跑起来。
封面