上个月帮一位做学校信息化的朋友收拾残局他有点兴奋地把一个小程序推到我面前“这是用大模型连续聊了三周做出来的学生综合素质评价系统功能都齐了你帮我看看能不能上线。”我打开看了一遍界面确实漂亮页面完整该有的菜单一个不少演示数据也跑得很流畅。可等我把部署环境、账号对接、数据来源这几个问题逐一问下来才意识到真正的困难根本不在代码——而是这个“能跑”的原型压根没有机会接触到真实学生。这可能是当下最容易让人误判的一件事。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 撞墙点部署、账号、数据、验收第一个撞墙点是运行环境。学校提供的服务器是几年前采购的装的是某个旧版本 LinuxJDK 还是 8数据库是 MySQL 5.7Web 容器用的是老 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 生成的代码都要推翻。判断标准很简单风险在哪个层级。页面渲染、信息展示、下拉筛选这类纯前端功能保留价值很高改动成本极低。而所有涉及账号、数据、权限、文件、金额/成绩计算、定时任务的部分一律当“需要人工审查重写”处理。下面这个清单是我改造项目时实际使用的判断框架模块类型AI 原型的通用问题处理建议页面布局、表单交互、静态图表通常代码质量足够用改动成本低保留微调样式与文案登录注册、Token 校验自建账号体系不符合统一认证要求重写改为 OAuth2/CAS 对接后端接口权限拦截常只有前端按钮控制接口无认证校验必须重写增加统一鉴权数据导入导出全量加载内存数据稍大就卡死重写改为流式解析成绩/分数/权重计算逻辑分散边界条件易错重写集中到服务层并加单元测试定时任务日期概念混乱任务无法重启恢复重写任务状态持久化学籍数据同步只处理理想数据不考虑脏数据重写增加数据清洗流程原则就一条越靠近数据越要人工把守。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 导入导出几千条就 OOMAI 初版代码在处理 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 实用排查清单快速查坑表现象可能原因解决方向首次部署启动失败运行时/依赖版本不匹配核对服务器 JDK、数据库、Web 容器版本登录总是失败对接统一认证的回调地址错误检查回调 URL、票据校验逻辑导入学籍数据报错脏数据、表头不一致增加格式化清洗先预览再入库导出报表页面崩溃全量加载内存过大改流式导出分批处理家长看到别的班学生数据数据权限过滤缺失所有查询强制追加班级/年级过滤条件定时任务执行两次集群环境没有任务锁或重启恢复逻辑缺失用数据库锁记录任务状态页面在机房电脑白屏浏览器版本过旧降低前端语法版本增加特性兼容5.7 一句实话原型快上线慢经历了这个项目以后我现在对 Vibe Coding 的态度很明确该用就用但心里必须清楚——它给的是原型速度不是生产质量。AI 帮我省掉的是搭页面、调样式、反复改界面的时间省不掉的是那几步把系统推向真实环境的工程活把身份认证接对、把数据链路跑通、把权限边界守住、把接下来几年要让人持续维护的准备做好。教育系统尤其如此。学生数据不能错家长信息不能泄露学期统计不能乱。这些东西靠的不是灵光一现的代码而是严格的数据边界、稳定的运行环境和对真实业务规则的尊重。Vibe Coding 可以帮你把“形”做得很快但“生产”这件事永远需要人沉下心来一遍遍确认。