2.5 不是能访问就算完成：数据、安全与验收的最小认知

上一篇我们给代码备了一颗“后悔药”：Git。

它解决的是一个很重要的问题：

AI 把代码改坏了，我能不能回到上一个可用版本？

但校园 Web 项目真正进入使用现场以后，只保护代码还不够。

排座系统在同事电脑上能打开，说明内网连通了。

座位页面能显示，说明前端跑起来了。

点击保存有提示，说明请求大概率也走通了。

这些都很好，但还不能直接等于“项目完成”。

因为一周真实试用下来，你可能会遇到更麻烦的问题：

• 今天导入的学生名单，明天刷新后不见了。
• A 班座位表保存后，切到 B 班却串了数据。
• 任课老师本来只想查看，却不小心改掉了座位。
• 学生姓名、学号、班级信息，被不该看到的人看见了。
• 同事说“能用”，但只点开看了一眼，没有走完整流程。

这时候你会发现，能访问只是连通性验收，不是完整验收。

一个校园 Web 小工具想真正放心使用，至少要过三道门：数据可靠、安全边界清楚、验收场景真实。

能打开只是第一步

很多项目最容易停在“页面能打开”的兴奋点上。

这很正常。毕竟从一个想法，到浏览器里真的出现页面，再到同事电脑也能访问，本身已经很有成就感。

但对校园工具来说，页面能打开只说明一件事：

这条访问路通了。

它还不能说明：

• 数据已经被可靠保存。
• 刷新页面以后数据还在。
• 换一台电脑看到的是同一份数据。
• 不同班级的数据不会互相覆盖。
• 只有合适的人能查看和修改。
• 真实老师能独立走完关键流程。

所以第二章最后这一篇，我们要补上的不是复杂技术，而是一种底线意识。

以后你让 AI 做校园 Web 项目时，不要只问：

页面能不能打开？

还要继续问：

数据放在哪里？
谁能看，谁能改？
真实场景走一遍，会不会出问题？

第一关：数据要可靠

Web 项目最容易让人产生错觉的地方，是页面上“看见了”不等于系统里“记住了”。

排座系统里，老师把学生拖到座位上，页面立刻变化。这个变化可能只是浏览器当前页面里的临时状态。

如果没有真正保存到后端和数据库，刷新一下就可能没了。

所以你至少要能问清楚三件事：

• 学生名单保存在哪里？
• 班级信息保存在哪里？
• 座位表关系保存在哪里？

这里不要求你马上会设计数据库。你只需要建立一个判断标准：

凡是明天还要用、换电脑还要看、多人要共享的数据，都不能只停在页面里。

对机房排座系统来说，重要数据通常包括：

• 班级列表。
• 学生姓名、学号或其他识别信息。
• 机房座位编号。
• 学生和座位的对应关系。
• 每个班级当前使用的座位表。

这些数据如果不明确保存位置，项目就很难长期使用。

备份是给数据准备的后悔药

Git 可以保护代码，但它通常不负责保护运行中产生的数据。

这点很关键。

你把代码回退到昨天的版本，不代表昨天导入的学生名单也一定能恢复。代码和数据是两类东西。

可以这样理解：

Git 保护的是项目怎么写。
备份保护的是学校真实数据怎么找回来。

对一个早期校园小工具，不一定马上做复杂的自动备份系统。但至少要有最小备份意识。

比如：

• 重要学生名单能不能导出为 Excel 或 CSV？
• 当前座位表能不能导出一份备用文件？
• 删除班级或清空座位表前，有没有二次确认？
• 误操作以后，老师有没有办法重新导入或恢复？

这些看起来不华丽，却很救命。

真实校园现场里，最怕的不是按钮颜色不够好看，而是某个老师辛苦整理半小时的数据，一刷新、一误删、一换电脑，就没了。

第二关：安全边界要清楚

很多老师会觉得：

这个工具只在学校内网用，应该没什么安全问题吧？

内网确实比公网更封闭，但它不是保险柜。

只要地址能被别人打开，就要想清楚谁应该看见什么。尤其是项目里出现学生姓名、学号、班级、成绩、账号、联系方式等信息时，更不能只靠“大家应该不会乱点”来保护。

这一篇不展开完整网络安全体系，也不讲复杂鉴权。你先抓住一个最小问题：

这个页面被别人打开以后，会不会看到或改到不该碰的数据？

排座系统里，可以先用人话划出几条边界：

• 信息科技老师可以新建班级、导入学生、调整座位。
• 任课老师可能只需要查看座位表，不一定需要修改。
• 学生不应该随意看到完整学生名单和管理入口。
• 临时演示地址不要长期发到大群里。
• 涉及真实学生信息时，不要把数据随便交给不明来源的在线工具处理。

这些话听起来不像技术，但它们正是权限设计的起点。

你先把“谁能看、谁能改、谁不能碰”说清楚，AI 才有机会帮你把它做进项目里。

第三关：验收要走真实动作

很多项目还有一个隐藏问题：验收太轻了。

老师自己打开页面，看见界面正常，就觉得差不多了。最多再点一下保存，看见“保存成功”，就进入下一步。

但真实使用不是这样。

真实使用会有切换、刷新、换电脑、误操作、重复导入、多人查看和临时改动。

所以验收不要只测“开心路径”。

所谓开心路径，就是一切都按理想情况发生：

打开页面 -> 导入名单 -> 安排座位 -> 点击保存 -> 显示成功

这当然要测，但不够。

排座系统至少还应该走几组更接近校园现场的动作：

• 新建一个班级，再导入学生名单。
• 保存座位表后刷新页面，看座位是否还在。
• 切换到另一个班级，再切回来，看数据是否串班。
• 换一台同事电脑访问，看能否看到同一份座位表。
• 故意重复点击保存，看系统是否稳定。
• 故意清空或删除关键数据，看有没有提示和确认。
• 让一位真实老师不看说明，独立走一遍常用流程。

验收不是为了挑刺，而是为了提前发现校园现场一定会发生的问题。

准备一张上线前最小检查单

对没有测试经验的老师来说，不需要一开始就写很专业的测试报告。

更实用的是给每个校园 Web 项目准备一张最小检查单。

检查项	要确认什么	为什么重要
页面能打开	自己电脑和同事电脑都能访问	确认连通性
数据能保存	点击保存后有明确结果	确认请求走通
刷新不丢	刷新页面后数据还在	确认已经持久化
换电脑能看	另一台电脑看到同一份数据	确认不是只存在本机页面
班级不串数据	切换班级后各自座位正确	避免真实使用混乱
错误有提示	导入失败、保存失败时说清楚原因	避免老师误以为成功
重要数据可备份	学生名单或座位表能导出	给数据留退路
敏感信息不乱露	不该看的入口和数据不要随意暴露	保护学生信息
真实老师走一遍	让目标使用者完成关键流程	避免只适合开发者自己用

这张表不追求完美。

它的价值是提醒你：项目完成不是一句“能打开了”，而是一组真实动作都能稳定通过。

可以这样要求 Coding Agent

以后你让 AI 帮你做校园 Web 项目，不妨在需求后面加一段验收要求。

比如：

请不要只实现页面效果。

这个排座系统至少要满足：
1. 学生名单、班级和座位表要保存到明确的数据位置。
2. 刷新页面后，已保存的座位表不能丢。
3. 切换班级时，不能把 A 班数据显示到 B 班。
4. 删除或清空座位表前，要有确认提示。
5. 请说明哪些页面或接口会接触学生信息。
6. 完成后给我一份最小验收清单，让我按步骤测试。

不要展开复杂安全体系，先满足校园内网试用阶段的最小可靠性。

这段话的目的，是把 AI 从“做一个看起来能用的页面”，拉回到“做一个经得起校园现场试用的小工具”。

当你能提出这样的要求，你就不再只是等 AI 输出结果，而是在指挥项目质量。

想继续查，可以认这些词

这一篇不要求你成为安全工程师或测试工程师。先认清下面这些词，以后看 AI 方案时就不容易被绕晕。

本文里的说法	专业技术名词	可以按需了解什么
数据明天还在	持久化 / Persistence	数据写入数据库或文件
数据放在哪里	数据存储 / Storage	数据库、文件、导出文件
数据找得回来	备份 / Backup	导出、恢复、定期备份
谁能看谁能改	权限 / Authorization	角色、访问控制、管理入口
先确认身份	登录 / Authentication	账号、密码、会话
不该随便公开的信息	敏感数据 / Sensitive Data	学生信息、成绩、账号
上线前走一遍	验收 / Acceptance Test	用真实流程确认项目可用
不只测顺利情况	异常场景 / Edge Case	误操作、重复提交、数据为空

带着底线进入实战

到这里，第二章的黑盒模型就基本拼出来了。

我们知道为什么校园小工具常常适合 Web。

知道一次保存请求要经过前端、后端和数据库。

知道本机能跑不等于同事能访问。

知道 AI 改代码前要有 Git 这颗后悔药。

也知道页面能打开以后，还要继续检查数据、安全和验收。

这些认知不是为了把事情变复杂。

恰恰相反，它们是为了让你在实战时少走弯路。

接下来进入第三部分，我们会先从一个更轻量的静态页面和表单统计项目开始，练会命令行、环境配置和前后端闭环，再进入机房排座系统这个主线项目。到那时，每一个按钮、每一次保存、每一次让 AI 修改代码，都不要只盯着“能不能跑”，还要顺手想一想：

数据可靠吗？
边界清楚吗？
这个流程经得起真实老师使用吗？

我们要做的不是一个只能展示的页面，而是一个能放心交给校园现场使用的小工具。

封面