上个月帮一位做学校信息化的朋友收拾残局，他有点兴奋地把一个小程序推到我面前：“这是用大模型连续聊了三周做出来的学生综合素质评价系统，功能都齐了，你帮我看看能不能上线。”我打开看了一遍，界面确实漂亮，页面完整，该有的菜单一个不少，演示数据也跑得很流畅。可等我把部署环境、账号对接、数据来源这几个问题逐一问下来，才意识到真正的困难根本不在代码——而是这个“能跑”的原型，压根没有机会接触到真实学生。

这可能是当下最容易让人误判的一件事。Vibe Coding 在个人工具、内部脚本、临时数据清洗这些场景里确实好用，你用自然语言描述需求，AI 就把页面和逻辑堆了出来，效率高得离谱。可一旦目标是 K12 教育系统，情况立刻不同。教育系统的生产环境不是“把代码跑起来”，而是要面对数据合规、身份认证、内网部署、学期机制、长期维护这一整套规则。每一道门槛都比写功能本身难。

这篇文章不是要否定 Vibe Coding，而是想把“从原型到生产”这段路上真实踩过的坑整理出来。对准备接教育信息化项目、或者正在用 AI 快速做系统的人，应该能省下不少试错时间。

1. Vibe Coding 的甜区，和 K12 教育系统的硬约束

1.1 “两周做出原型”确有其事

先说清楚 Vibe Coding 到底擅长什么。它的本质是人用自然语言描述目标，模型负责生成代码和页面，开发者再通过多轮对话修改细节。你可以把它理解成一个“快速建模师”——不需要你逐行敲键盘，只需要你把需求说清楚，它就能给出形态完整的作品。

这种模式特别适合三类事情。

第一类是个人工具。比如想批量重命名几百个文件、解析日志、生成一张统计图表，十几分钟就能拿到可运行的脚本，省掉大量重复劳动。第二类是内部系统原型。给团队做一个需求评审用的 Demo，给客户演示一个交互流程，给领导看看“未来系统长什么样”，Vibe Coding 的效率无与伦比。第三类是低风险场景下的临时功能，比如内部用的排班表、部门共享的通讯录，跑挂了影响不大，修一修就好。

我的实际体感是，用自然语言驱动开发，做出来的东西“看起来完成度极高”。页面布局、配色、按钮状态、表单校验，这些视觉和交互层面的东西，AI 已经做得很像样。朋友那个综合评价系统就是典型代表——学生列表、评价指标、评分表单、报告生成，两周时间全部立起来了。按这个速度，传统开发光是画原型、调接口、处理样式就得一个月，Vibe Coding 确实把“从想到形”的过程大幅压缩了。

1.2 K12 系统要应对的几类硬约束

问题出在“形”与“生产”之间。K12 教育系统跟普通互联网应用最大的区别在于，它要同时满足四类硬约束。

合规约束。学生信息几乎全是敏感个人信息：姓名、证件号、家庭住址、健康情况、成绩评价。这些数据的采集、存储、展示都有明确要求，不能随便处理。系统需要留痕、可审计、最小化采集，家长授权、教师操作记录都是必选项。

环境约束。大量学校运行在封闭内网或半封闭环境里。服务器可能是用了多年的旧机器，操作系统的版本、数据库的版本都偏老，能跑什么、不能跑什么，不是开发团队自己能决定的。

身份边界。教育系统的账号体系通常不是自己建的。学生、家长、教师都来自上级统一身份认证平台，系统自建登录页面在演示阶段没问题，进入生产环境就成了违规。

业务周期。教育系统的基本时间单位不是自然年，而是学年。9 月开学，学期、寒暑假、毕业升学、年度归档……算法一不留神就会在跨年时算错。

这些约束叠加起来，就让 H2 开头那句“Vibe Coding 很爽”变得有前提了。

1.3 “能跑”和“能上线”是两个动作

很多初学者把“本地跑通了”当成“系统可以交付了”，这是最危险的理解偏差。

“能跑”通常意味着：页面上能点、假数据能展示、逻辑看起来对。但“能上线”意味着真实用户能登录、真实数据能导入、安全审查能通过、连续运行不出错、出了问题有人能定位、要把源码转交给别人时对方能看懂。

这两者之间的距离，跟系统规模成正相关。个人记账软件能跑，你自己就是运维、测试、安全负责人；但一个供整所学校使用的评价系统，牵涉数百个学生、几十位教师、还有区级平台对接，所有环节都必须按生产标准来。

打个比方，Vibe Coding 做出来的原型像是一栋用积木搭好的建筑模型，远看结构清晰、户型合理。但真要住人进去，需要管线图、承重计算、消防验收。你没法拿模型图去办施工许可。

2. 我实际经历的一个项目：原型很好，上线很难

2.1 模拟项目X：某小学综合素质评价系统

用具体例子说会更清楚。朋友接的需求来自一所小学，学校希望建一个综合素质评价系统，任务就三块：老师录入学生评价、家长登录查看报告、教务处汇总班级数据。

原型阶段做得很顺。用 AI 生成学生管理、评价指标配置、评分表单、数据看板这些模块，又把查找、筛选、排序、PDF 导出都接上了。演示那天，学校信息主任看得很满意，说“小伙子做得很快嘛”。但等真正聊部署条件，问题一个接一个冒出来。

2.2 撞墙点：部署、账号、数据、验收

第一个撞墙点是运行环境。学校提供的服务器是几年前采购的，装的是某个旧版本 Linux，JDK 还是 8，数据库是 MySQL 5.7，Web 容器用的是老 Tomcat。而 AI 生成的原型用的是新框架，依赖了较新的 JDK 特性和容器化部署方式，学校环境根本不满足要求，连装环境都费劲。

第二个撞墙点是账号体系。学校系统必须对接区级统一身份认证，学生和家长都有统一账号。原型里做了一个“手机号注册 + 密码登录”的模块，这在演示里没问题，但在生产里是方向性错误。消息传回来很直接：不能用自建账号。

第三个撞墙点是数据。学校提供了一份从上级平台导出的真实学籍名单，包含姓名、证件号、班级等信息。原型的演示数据是自己造的，字段格式和真实数据对照不上，导入解析第一次跑就报错，大量身份证校验失败、班级名称映射混乱。

第四个撞墙点是验收方式。学校要求这个系统要能有人维护，源码必须规范、有文档、能交接。朋友自己对着 AI 生成的 4000 行代码看了一下，确实有点心虚——没有注释、没有测试、模块之间耦合严重，“它能跑，但我不知道它为什么能跑”。

2.3 这些门槛的共同特征

撞墙之后你会发现一个规律：这些问题没有一个是“功能代码”问题，它们全部属于工程、规则和组织协作问题。

AI 可以帮你把学生列表页面做得很漂亮，但它不知道学校的内网服务器是什么配置；它可以把评分表单生成得合理，但它不知道教师账号要从哪里来；它可以写出漂亮的导入逻辑，但不知道真实学籍表里会有“空格”、“异体字”、“班级合并”这些脏数据。这些信息只存在于真实环境里，不写进需求就无法被模型理解。

这就是为什么说“Vibe Coding 撞上 K12 教育系统”有真实门槛。原型解决的是“像不像”，生产解决的是“行不行”。

3. 教育系统为什么不是普通 Web 应用：真实门槛拆解

3.1 数据合规：未成年信息保护不是口号

K12 系统里存储的大多数数据都是未成年人信息。这意味着一件事：数据处理的姿态要从“方便采集”变成“最小化且留痕”。身份证号、家庭住址、家长联系方式、学业表现、教师评语，这些内容一旦泄露或滥用，后果远超普通产品的用户数据泄露。

生产系统里，至少要确认几件事。

权限分级。不是登录用户都能看到所有学生的评价记录，班主任只能看本班，年级组长只能看本年级，教务处才有汇总权限。权限不仅要触达到页面按钮，还要在接口层强制校验。

日志留痕。谁在什么时间查看了哪个学生的档案、修改了哪条评价，都要有操作日志。这类日志不是为了找麻烦，而是在出现争议时，系统能还原事实。

存储规范。身份证号之类的敏感字段，数据库里不建议明文存储。能脱敏展示就脱敏展示，比如列表页只显示“310***********1234”这样的形式，全量信息只在授权场景下出现。

我用一个更直白的类比解释过：卖货网站丢了用户手机号，用户最多被骚扰一下；学生档案要是出了问题，涉及的是家庭信任和学校责任。这个量级差太多了。

3.2 网络与部署环境：公办学校内网的真实棋局

很多开发者在互联网环境下长大，默认“服务器上能装 Docker、能上外网下载依赖、端口随便用”。公办学校内网根本不是这样。

校园网通常有严格的访问控制，服务器在特定网段，出外网需要申请策略，大多数情况下没有外网访问能力。这意味着 AI 生成的项目如果依赖远程 Maven 仓库、npm 镜像，部署时连依赖都拉不下来。要么在能联网的机器上下好依赖包，再离线拷进去；要么内网搭建本地源。听起来不算难，但第一次遇到的人很容易卡住大半天。

另外，老服务器跑新框架也不现实。原型用较新的运行时，到学校只有旧版环境，连启动都会失败。不要觉得升级学校服务器是理所当然——很多时候服务器的采购、维护不归开发团队管，你要做的是适配现有环境。

还有浏览器兼容问题。部分学校里的电脑还在用老版本浏览器，很多页面代码一用上较新的 CSS 语法就白屏。原型阶段在浏览器 DevTools 里看着没问题，放到学校机房打开却是另一个世界。

3.3 账号与权限：不是“加个角色”那么简单

演示系统通常是一个 users 表，里面塞一列 role 字段，登录时判断是“学生”还是“家长”还是“老师”。生产环境不可能这么单纯。

教育系统的典型账号结构是：学生账号来自学籍系统，家长账号由家长注册后绑定孩子，教师账号来自人事系统，管理员账号由区级平台分配。账号的创建、冻结、密码找回，全部要跟外部平台对接。最常见的就是统一身份认证。

这意味着系统要么支持 CAS、OAuth2 这类标准协议对接，要么接受外部平台跳转登录后回调校验用户身份。AI 生成的前端登录页在对接时要整个推翻，因为真实环境里根本没有“注册”这一步，入口全部由上端控制。

权限也不是一个角色字段能解决的。更常见的是 RBAC 加数据范围。同样是“查看学生评价”这个按钮，不同角色看到的范围不同，底层查询要动态带上学段、年级、班级这些过滤条件。

3.4 时间与运维：学期、年报、无人值守

K12 系统的时间逻辑跟业务周期强绑定。自然年是 1 月到 12 月，学年是 9 月到第二年 8 月。系统的“本学期”“上学期”“学年报告”这些概念，全部按学段计算，不能按自然年硬切。

AI 很容易把时间写简单。比如“获取当前年份的 9 月 1 日”就当作新学期开始，但真实系统要考虑：9 月之前数据归属上一学年、跨年时寒假和下学期如何划分、毕业班数据怎么归档。这些逻辑一开始不规划好，后续几乎必然出 bug。

运维压力也被很多人低估。学校通常没有专职运维，系统部署完，能接触服务器的可能就是信息老师。这意味着系统要降低维护门槛：服务要能开机自启，出错要写日志而不是静默失败，配置集中在一个文件里而不是散落各处。那些 npm install 半小时、重启要看半天命令的操作方式，在学校里是行不通的。

3.5 可维护性：AI 代码的安全交接困境

原型时期的代码，写的时候自己都没想过要给第二个人看。但学校要的是一个长期运行、随时可以找人维护的系统。这意味着源码、文档、部署手册、数据库脚本都要具备交接条件。

AI 生成的代码有两个先天的交接问题。一是没有测试，改动任何一块都可能影响别的地方，没人敢动。二是命名和结构随性，同一个概念可能出现多种叫法，人的习惯很难覆盖模型生成的随机性。我到目前拆过不少 AI 项目，感受是：AI 写代码像在“组织语言”，句子通顺，但段落之间的逻辑关系很弱。

所以进入生产前，核心模块能重写就重写，不能抱着“能跑就不动”的心态。这部分工作省不了。

4. 从“能跑”到“能上线”：我踩坑后的改造路径

4.1 保什么、重写什么：模块判断清单

不是所有 AI 生成的代码都要推翻。判断标准很简单：风险在哪个层级。页面渲染、信息展示、下拉筛选这类纯前端功能，保留价值很高，改动成本极低。而所有涉及账号、数据、权限、文件、金额/成绩计算、定时任务的部分，一律当“需要人工审查重写”处理。

下面这个清单是我改造项目时实际使用的判断框架：

原则就一条：越靠近数据，越要人工把守。

4.2 AI 写作草稿，人类写生产代码

改造过程里最有效的工作方式不是“让 AI 一步到位”，而是“AI 负责草稿，人类负责工程”。

具体操作可以这样展开。先让 AI 生成页面模板、前端交互、字段校验规则，这些部分完成度已经很高，省下的时间非常多。然后人工接管数据库表设计、数据访问层、权限拦截、事务管理这些核心逻辑，逐段审查。最后把 AI 生成的数据模型、业务方法当参考，但不要直接用于线上。

举一个例子，数据访问层。AI 最常见的写法是直接拼接 SQL，这在学校环境里是大忌。生产代码必须用参数化查询，并确保所有数据库操作都在事务里执行，避免部分成功部分失败的脏数据状态。另外一个高频问题是分页，AI 喜欢一次性读取全表做内存过滤，少量数据没问题，真实学籍数据一到几千行，性能就崩了。改造时统一改用数据库分页查询，界面保留“上一页/下一页”这类传统模式，反而更稳。

安全方面也很关键。接口层要加统一鉴权拦截器，确保即使前端不做跳转控制，恶意请求也无法绕过。演示阶段没人管接口裸奔，生产环境这是头等问题。

4.3 部署前必须摸清的学校环境清单

改造代码之前，先把环境约束搞明白，能省掉后期大改。下面是我后来做类似项目必问的一份清单：

服务器：操作系统版本、是否可联网、磁盘空间、管理员权限归属。运行环境：JDK 版本、数据库版本、Web 容器、是否有 Node 环境、是否允许用 Docker。网络策略：出外网是否受限、哪些端口可用、是否需要绑定域名。账号体系：是否对接统一认证、对接方式（CAS/OAuth2）、测试账号怎么获取。数据来源：学籍名单从哪来、什么格式、多久同步一次、是否有历史数据需要迁移。运维能力：学校有没有专人看日志、备份策略谁来定、故障响应期望时间。

这份清单花半小时就能问完，但很多人都是先写了代码再发现环境不支持，最后推倒重来。

4.4 妥协不是偷懒，工程边界要提前定

生产落地中一定会遇到“这里能不能升级一下”的诉求，但答案是不要轻易升级。

我的经验是：能用旧版本稳定跑，就不要为了“技术先进”引入新组件。JDK 8 和 MySQL 5.7 在学校里能安稳运行十年，就没必要非要用较新的运行时和数据库。部署方式也尽量简单：能用单机应用就不要上容器编排，能用一个 Tomcat 目录就不要引入一套复杂配置。教育系统的核心诉求是稳定、可维护、出问题好排查，不是技术栈炫技。

前端同样如此。页面可以做得漂亮，但尽量照顾老旧内核的兼容性，少用依赖新特性的写法。这个妥协换来的是学校机房的电脑都能正常打开，值得。

5. 常见问题与排查技巧实录（Vibe Coding 进教育系统的坑）

5.1 身份证校验：18 位不等于正确

AI 生成身份证校验是重灾区。很多模型默认“18 位就是合法”，忽略了 15 位旧证、最后一位 X 的大小写、出生日期合法性、校验位计算这些真实规则。

正确做法至少要做到：长度判断、出生日期段解析、校验位算法验证。最后一位 X 统一转大写再比对，15 位旧证根据具体情况决定是否兼容。这些规则在 AI 生成的原型里几乎不会完整出现，必须人肉补齐。

5.2 附件上传：原型能跑，生产就炸

原型阶段上传文件通常写到项目根目录下的临时目录，一切正常。生产环境常见的两个坑：一是目录没有写权限，服务一启动就先报文件系统错误；二是路径写死，换个服务器部署，文件路径就失效。

更稳妥的设计是：文件不直接放在应用目录，而是放在独立存储区，文件名由系统统一生成，数据库记录原始文件名和存储路径。这样无论服务器怎么换目录，数据对应关系都不会乱。另外要校验文件大小、扩展名，防止上传无关文件。

5.3 Excel 导入导出：几千条就 OOM

AI 初版代码在处理 Excel 时通常走“全量加载内存”的路线，几百行数据没问题，到了几千行或带公式的复杂表，内存就会撑不住。有些系统甚至因为一次年级全量导出直接卡死。

解决方案是改用流式处理。数据量超过几百行时，导入建议采用基于 SAX 事件模型的行级解析方式，导出建议用支持滑动窗口的实现，避免把所有行一次性堆进内存。我自己改造过的评价汇总导出，从“一次全量查询”调整为分批查询加流式写入，内存占用降了一个量级。

5.4 学期时间计算：跨年就翻车

AI 最容易把学期计算写成“当前自然年的 9 月 1 日到次年 1 月”，但真实学年是跨自然年的。每年 1 月、2 月的数据归属上学年第一学期，还是新学期的第二学期，必须用明确的业务表定义。

更稳妥的做法是把“学年学期”建成一个基础配置表，比如2024 学年第一学期：2024-09-01 ~ 2025-01-15，所有前端选项和统计逻辑都读取这张表，而不是在代码里硬算。这样学校调整放假安排、遇到特殊情况时，改配置就行，不用改代码。

5.5 AI 幻觉接口：它在调用不存在的东西

一个很容易让人困惑的 bug 是，前端页面调用的某个接口后端根本没有实现，但 AI 还是在代码里写了请求。因为模型在生成前端代码时“觉得”后端应该有这个接口，于是凭空调用了一个不存在的地址。演示时因为数据都是写死在 mock 层的，你不看网络面板根本发现不了。

排查方法很笨但有效：用抓包工具把所有请求列出来，和后端 controller 路由清单逐个对比，找出一一对应关系。我后来养成了习惯——先人工列出接口文档，再让 AI 按文档生成前端调用代码，杜绝它自由发挥。

5.6 实用排查清单（快速查坑表）

5.7 一句实话：原型快，上线慢

经历了这个项目以后，我现在对 Vibe Coding 的态度很明确：该用就用，但心里必须清楚——它给的是原型速度，不是生产质量。AI 帮我省掉的是搭页面、调样式、反复改界面的时间，省不掉的是那几步把系统推向真实环境的工程活：把身份认证接对、把数据链路跑通、把权限边界守住、把接下来几年要让人持续维护的准备做好。

教育系统尤其如此。学生数据不能错，家长信息不能泄露，学期统计不能乱。这些东西靠的不是灵光一现的代码，而是严格的数据边界、稳定的运行环境和对真实业务规则的尊重。Vibe Coding 可以帮你把“形”做得很快，但“生产”这件事，永远需要人沉下心来一遍遍确认。