Vibe Coding实战：从零构建K12 AI智能教育系统的完整记录

前阵子做 Vibe Coding 进阶实战我把目标锁定在一个比普通 Demo 复杂得多的方向打造 K12 AI 智能教育系统。市面上这类产品多的是但大多数只解决“能聊天”这一个爽点真拿去给学生用就会露馅——题目不敢给、错题不会记、老师端的报表更是能糊弄就糊弄。我做这套系统的初衷就是想用工程手段把“AI 辅助教育”从玩具做成能落地的工具顺便检验一下 Vibe Coding 这种方式到底能扛住多少复杂度。如果你正好打算用 AI 编程的方式做教育类产品或者已经在 Vibe Coding 里试过几个小应用、准备往更复杂的场景走这篇文章应该能接住你。下面这篇实战记录按我真实的推进顺序展开先讲需求怎么收敛再讲架构怎么先于代码落地接着是提示词调教的三个关键习惯然后拆解核心功能模块的实现过程最后聊一聊从 Demo 到可用系统必须补上的性能、安全和合规工作以及我对 Vibe Coding 能力边界的判断。1. 一次真实的需求梳理K12 场景到底先解决谁的痛点做教育类产品最大的坑不是技术而是需求侧一上来就是一团乱麻。学生要“问到答案”老师要“能减轻负担”家长要“知道孩子学得怎么样”这三件事当然都能用 AI 做但哪个先做、做到什么程度直接决定了系统的复杂度上限。如果你不先想清楚这个问题后面的提示词再怎么调教都只是在给一个不成立的产品打补丁。1.1 学生、老师、家长三方需求怎么排优先级先说说最初的需求视角。这里的用户画像其实很清晰学生端的核心痛点不是“找不到答案”而是“遇到了不会的题目身边没有随时能讲清楚的老师”。答案给得太直接会产生依赖完全不给又失去即时性所以产品要做的是“阶梯式提示”而不是“保姆式解答”。老师端要的不是花哨的交互效果而是备课出题、作业批改、学情统计这些高度重复的劳动能不能被压缩。一个能根据知识点快速生成变式题、自动整理班级薄弱点的工具比一百个酷炫功能都实在。家长端的需求最微妙他们更关心孩子最近学得怎么样、有没有真正理解而不是孩子跟 AI 聊了多少次。这个需求可以靠一份周报式的学情摘要来满足不需要实时介入。三个角色看上去都很有道理如果同时做前端要三类界面后端要三套数据权限还要处理家长和学生两种完全不同的交互距离两周根本做不完。我当时的做法是做一个优先级矩阵用两个维度打分业务价值高不高实现成本低不低。用户核心痛点对应功能价值/成本判断MVP 取舍学生不会的题没人讲讲得太透又不长记性AI 阶梯式答疑、知识点标签、错题记录价值极高成本中主场景第一个做老师出题、批改、汇总统计占用大量时间变式题生成、班级学情报表、错题导出价值极高成本中高重点差异化第二个做家长不清楚学习过程担心沉迷和隐私周报摘要、防护提醒、数据只读价值中成本低后期用静态报表先做筛选下来这个 MVP 的核心就是“学生答疑 教师出题 错题沉淀 学情汇总”四个闭环。语音互动、虚拟角色、实时课堂投屏这些听起来有亮点但实现成本高的功能我全部砍掉留到了下一版。1.2 从“AI 问答玩具”到“学习辅助系统”的差别在哪里把需求收敛成 MVP 之后另一个问题又浮出来了怎么判断我们做的不是又一个聊天玩具我在实际开发里总结出一个判断标准——看系统能不能“记得住”学习过程并且“搞得清”知识边界。真正能给教育场景用的系统至少要满足三个条件第一每次问答都要能追溯到某个知识点这样错题才有归因第二生成内容的学科边界必须受控模型不知道的内容宁可直接说“需要老师介入”也不能自由发挥第三学生的每一次作答都要沉淀成结构化的学习数据变成老师端报表的数据源。这三件事听起来和 AI 聊天没太大关系但恰恰是一个教育产品能不能落地的分水岭。为此我把系统拆成三层不是按前端后端分而是按业务职责分教学理解层负责把学生的提问意图转成知识点检索条件学科内容层负责管理教材切分、题目和解析这些有严格正确性的东西记录与反馈层负责把学习行为落库形成反馈回路。这个划分在我后来写提示词时帮了大忙因为每层的“边界提示词”都不一样AI 在每一层都只需要干一件事。2. Vibe Coding 起手式先定架构再让 AI 填格子需求清楚了接下来就到了 Vibe Coding 最常见的翻车点。很多人拿到需求的第一反应是打开对话窗口敲一句“帮我做一个 K12 教育系统”。我一开始也这么干过结果 AI 给出的东西看着挺完整实际上完全没有业务约束没有数据表设计、没有权限边界、没有接口契约改一行代码可能带出十个新问题。2.1 为什么 Vibe Coding 更应该先有架构我后来总结出一句话Vibe Coding 不是让 AI 替你想架构而是让 AI 在你画好的格子里填内容。AI 确实擅长把描述变成代码但如果你的描述是一团没有边界的概念它只能随机发挥。这就像你让一个行动力很强的新人去做事却只给一句“把项目管好”他一定会把事情做成你不想看到的样子。所以在正式写提示词之前我先花了一天时间做架构约束。这个约束不是画复杂的设计图而是用自然的语言把边界说清楚技术栈固定后端用 Python FastAPI SQLAlchemy前端组件化数据存储固定关系库只存结构化业务数据向量库专门存教材切块后的知识点向量接口边界固定所有 AI 生成能力都通过后端代理不让前端直接调模型测试要求固定每个新增功能必须有对应单元测试通过后才算完成。这些约束用大白话写在提示词的上下文里AI 生成的代码就会天然遵守规则而不是东一榔头西一棒子地自由发挥。我在实际项目里最明显的体验是有约束的 Vibe Coding每次迭代返工率低得多代码可读性也高很多因为 AI 在生成时就知道“这属于哪一层、该放在哪个目录、接口签名应该是什么样子”。2.2 数据模型和接口契约先用自然语言写一遍在让 AI 写任何代码之前我还会做一件事把数据模型和接口契约用自然语言描述出来存成一个工程文档每次给 AI 的任务都引用这个文档。这个步骤看起来有点多余实际上回报率高得惊人。举个实际的例子数据模型我是这样描述的学生表学生ID、学号、年级、班级不存真实姓名 题目表题目ID、知识点ID、学科、题型、难度、题干、选项、答案、解析 作答记录表记录ID、学生ID、题目ID、作答内容、是否正确、作答时间 知识点表知识点ID、知识点名称、所属教材版本、年级、上级知识点ID。接口契约也类似我要求生成的接口必须是“可验收”的比如POST /exercises 接收 course、knowledge_point、difficulty、count 四个参数 返回题目数组。每道题包含 stem、options、answer、explanation、knowledge_point 五个字段。answer 字段只允许老师端看到学生端接口任何时候不得返回答案。这段话看起来像是产品需求文档但它其实是给 AI 的最强提示词。当我把这些约束放进上下文之后AI 生成的代码不再是“像那么回事”而是每一行都知道自己在给哪个字段赋值。教育系统这种数据敏感的场景字段级的行为约束比什么都重要。2.3 迭代单元怎么划分让 AI 只填空不改架构有了架构和数据模型之后剩下的是把功能拆成合适的迭代单元。我的经验是一个迭代单元只做一个闭环。“题目生成”是一个单元“错题本导出”是另一个单元不要把两个功能放进同一次对话里。Vibe Coding 最大的威力在于快但它的弱点也在于“改动范围越大越容易开错门”。如果你让 AI 一次改三个功能它很可能把数据模型、路由、前端页面一起动掉你根本来不及审。我的做法是维护一个 prompts 目录把每次成功提示词按功能名存档。开始新功能时可以引用过去类似的提示词模板保持风格一致。另外迭代单元小提交回滚才方便。AI 生成的东西你永远做不到 100% 检查但只要每个提交都能单独回退出问题就不慌纯靠记忆去修 AI 的乱改才是灾难现场。3. 提示词调教实战把灵光一现变成稳定交付有些文章把提示词技巧讲得很玄其实对 Vibe Coding 来说核心就一句话让 AI 在足够的上下文里做足够小的任务然后用明确的验收标准去约束它。我把它展开成三个每天都会用的习惯。3.1 上下文注入决定能力上限第一件事是给 AI 戴上“合适的眼镜”。同一个模型你直接说“帮我写个题目生成接口”它给你的东西通常很平庸但如果你先告诉它这是什么项目、要遵守什么规则、数据模型长什么样它写出来的代码就会完全不一样。上下文不是越多越好而是要把关键约束放在最前面。我习惯在每次新会话的第一条消息里放一份“项目上下文块”。内容固定成几行这是一个 K12 AI 教育系统的后端项目。 技术栈Python 3.12 FastAPI SQLAlchemy。 规则 1. 所有接口遵循 REST 风格 2. 涉及学生数据的查询必须带班级/年级过滤条件 3. 任何 AI 生成能力都通过 service 层统一封装不能散落在路由里 4. 新功能必须同时提交单元测试 5. 学科内容一律用教材知识点标签不自己发明名词。这段内容在开头放一次后面即使每轮对话在讨论不同功能AI 也会一直记住这些约束。我踩过最典型的坑是没放上下文AI 生成的接口直接裸奔没有权限判断这在教育场景里是不能接受的。放了这个块之后虽然不能保证每次都对但至少多数轮次它不会忘记基本规则。3.2 需求拆解一次只提一个可验收的功能第二个习惯是磨需求。很多人嫌麻烦把需求笼统地写成一句“实现学生查看错题本”。这句话的问题是没有验收标准AI 可以自由发挥成十种不同风格。我一般会把需求写成小步包括触发入口、行为细节、写库逻辑。举一个当时实际用的提示词新增接口 POST /exercises/{id}/feedback。学生端对做过的题目反馈三种状态 good、confused、bad。 - good题目理解无误不需要后续处理 - confused记录到待复习队列弹窗提示“已加入待复习” - bad该题自动进入错题本并创建一个待订正记录。 输出统一为 JSON包含 code 和 message。需要补齐单元测试覆盖三种状态及非法参数。这个提示词把一个很小的功能讲得足够具体AI 生成的代码基本不用大改只有小细节需要看一遍。里面有个技巧是——尽量把用户能感知到的交互行为也描述进提示词因为代码写得好不好最终要体现在动作闭环上。上面例子里的弹窗文案都是提前定好的AI 就不用自己乱编了。3.3 纠偏的三种话术以及审查节奏无论上下文写得多好AI 总会出错。关键是出错之后怎么纠正它。和 AI 协作久了我总结出三种场景对应三种完全不同的纠正方式。第一种改动范围失控。如果你发现 AI 为了一个小功能把数据模型、路由、前端全改了一遍不要试图在对话里一点一点解释哪里错了直接说“请回退到上一次提交版本根据以下新说明重新生成”然后给出更具体的约束。第二种单点 bug。一个函数里字段赋值错了或者某一行逻辑跑不通直接贴出报错信息同时说“修复这个问题并在修复后用一个最小示例验证不要改动其他功能”。这时候只要给它定义好变更范围它通常能改得很干净。第三种AI 开始自由发挥。有一回我让 AI 生成一段简单的 JSON 解析逻辑它却顺手给整个 service 加了消息队列。这种“画蛇添足”最麻烦。我的纠正是明确重申禁止性约束“不要新增任何依赖包不要修改已有的数据模型不要引入异步任务如果实现超过 30 行请先停下来说明方案。”审查节奏上我也形成了一套流程AI 每生成一个迭代单元至少做两件事。第一看它新增的文件目录是否符合项目结构第二跑一遍它自带的单元测试。这两件事过了之后再去做人工代码审阅。这样能保证 Vibe Coding 的产出始终还是“能维护的代码”而不是一个黑盒。4. 核心功能模块实现记录答疑、出题、报表三块硬骨头架构和协作方法理顺之后真正压时间的就是三个核心模块的实现。这里面的难点都不在“让 AI 写代码”而在“怎么设计系统逻辑让 AI 写代码变得有意义”。4.1 答疑引擎不是裸调模型而是先过一道检索闸门答疑引擎的第一版特别幼稚就是把学生的问题直接发给模型然后把模型的回答渲染出来。试了不到一天就发现问题很多模型答案不稳定学科知识容易跑偏而且完全无法记录学生在哪个知识点上出了问题。后来我改成 RAG 的思路课前把教材按知识点切块每块转成向量存到向量库学生提问时系统先用提问意图匹配出相关的知识点块把检索结果塞进提示词上下文再让模型生成回答。这个改动带来的好处非常具体第一回答是有“来源”的学生问“为什么分数除法要这样算”系统先检索到分数除法的教材片段再基于这个片段组织语言第二知识边界被控住了模型拿不到教材中没有的内容就不太可能乱回答第三每次答疑都能记录它命中哪个知识点后面错题本和学情报表才有数据可依。答疑模块的提示词我到现在还在迭代其中一段关键内容是你是 K12 数学答疑助教。只根据【参考资料】中的知识点解释作答不要使用资料之外的知识。 如果资料不足以回答直接回复“这题需要老师介入”。 回答时必须采用阶梯式提示先给一个思路方向再让学生尝试如果学生继续追问再逐步给出更多步骤。 在所有输出中禁止直接展示最终答案除非题目本身明确要求写出求解步骤。这个提示词执行下来系统的答疑风格稳定了很多。你可能会说“禁止直接展示最终答案”不是会影响学生体验吗但我的判断是教育的价值恰恰在引导过程而不是给答案。用产品逻辑来说是“有引导、有反馈、有边界”这三点比单看“回答得准不准”更关键。4.2 错题本与变式题生成同考点换壳的工程实现错题本本身不难真正难的是变式题生成。学生把一道题做错了系统要自动生成同知识点、同难度、但换了情境的变式题让他再做一遍。这个功能如果让 AI 自由发挥生成的题很可能跟考点对不上甚至直接出科学错误。我采取的做法是两步走。第一步纯规则层拿到错题的知识点标签从题目库里筛选同一知识点下已有人工验证过的题作为候选第二步AI 生成层提示词要求模型只改变题干中的数字、单位和情境保留核心的运算结构和知识点标签。生成完之后还要跑一个自动校验脚本来检查题目是否可解、答案是否唯一。这个模块最值钱的踩坑总结是不要相信 AI 生成的答案“看起来对”。有一次模型生成了一道“小明从家到学校走了三分之一小时又走了 2.5 千米问总路程多少”看起来正常但实际缺了一个关键条件根本没法解出来。后来我所有生成题都会先交给一个纯规则校验器过一遍检查题干中出现的变量是否都在条件里给了检查答案是否落在合理数值区间抽查 10% 做人工复核。这样才敢把题放到学生面前。4.3 学情报表把堆数据翻译成老师能直接用的动作学情报表被很多人当成小菜一碟做起来才知道难点不在统计而在翻译。后台确实能算出班级平均分、各知识点正确率、错题数量但如果直接把原始数字堆给老师老师根本不会用。教育场景里老师要的是“哪个知识点薄弱”“建议做什么动作”而不是一张冷冰冰的统计表。我的设计是两层数据层用常规 SQL 统计出各类指标表述层再让模型生成一段“教学建议”。统计出来的指标先转成结构化的 JSON比如{ class_id: c3, week: 2025-11, weak_points: [ {knowledge_point: 分数除法, error_rate: 0.32, trend: up} ] }然后提示词再让模型基于这些 JSON 生成人话段落“本周班级最薄弱的知识点是分数除法错误率 32%且比上周上升了 6 个百分点。建议在接下来的两节课中安排 15 分钟专项训练重点关注带分数除以真分数的题型。”这层翻译做出来之后老师端的反馈明显好了一大截。我还特别留了一个安全约束模型在生成建议时只能引用数据里的事实不能给学生本人下结论性评价。比如说“该生分数除法正确率连续三次低于 40%”可以但“该生不够聪明”绝对不行。这一条写进系统规范后所有学情输出都必须过这个审计规则。5. 从 Demo 到真正能用的系统性能、安全与合规三项硬指标如果你只做到前面四章你得到的还是一个“老师演示时不出错、学生一多就崩”的 Demo。往可用系统靠拢时性能和安全是两道绕不过的坎。教育产品的使用场景非常特殊它发生在固定时间段可能同一瞬间几十个学生同时提问又因为它面对未成年用户内容安全的要求比其他产品高一个等级。5.1 AI 调用不能裸奔缓存、批处理与降级方案最开始我把答疑和出题都做成同步接口前端等后端后端等模型。学生提问一次要等七八秒老师批量生成一节课的练习题可能要等两分钟。这个等待在 Demo 里能接受但在真实课堂里就是事故。系统的改造思路是三板斧。缓存常见问答和同一知识点、同一难度的题目生成结果做短时缓存半小时内重复的请求直接拿缓存成本和时延都降下来。批处理老师端一次生成 30 道题不再用同步接口等完整生成完而是提交任务后立即返回后台慢慢跑跑完推送通知。降级如果模型服务暂时不可用答疑接口返回“老师暂时不在线你可以稍后再试或把这题加入待复习队列”错题本和报表这些不依赖模型的模块完全不受影响。这三个方案分别对应接口设计里最常见的三个问题冗余重复、长耗时任务、外部依赖故障。做教育系统尤其要重视降级因为上课时间窗口很宝贵模型服务一旦抖动学生端直接白屏是不可接受的。5.2 内容安全过滤与学科边界约束内容安全这件事我把它理解为三道防线而不是一次过滤。第一道防线是输入侧过滤掉异常长的文本、诱导模型输出违规内容的恶意提示第二道防线是输出侧对模型生成的答案做词表和规则检查命中高危内容就强制替换成“这个问题不太适合继续聊请换个方式问”第三道防线是业务侧校验针对教育特有的问题——生成的题目有没有歧义、答案是否正确、难度标签有没有超出范围。防线处理对象常用手段1 输入侧恶意提示、超长文本、低质量请求长度限制、正则检测、频控2 输出侧模型生成文本中的违规表述词表匹配、规则引擎、模型分类3 业务侧题目可解性、答案唯一性、难度合理性脚本校验、符号检查、人工抽检三道防线缺一不可。我在实际项目里遇到过最典型的情况是模型输出没有明显的违规词但生成的题目本身就是错的学生照抄就能得到错误答案。这种错误不是词表能挡住的只能用业务侧校验。做完这三层之后系统才敢放到真实学生面前。5.3 教育场景的数据合规只收集完成功能必需的数据数据合规这个话题很多教程不爱讲因为它不性感而且文档写得再好也不如代码里管得严。但在教育场景里这是绝对不能偷懒的一层。我的原则是能少存就少存能匿名就匿名能短存就短存。具体落地是几条铁律学生端不采集真实姓名统一用学号 班级做标识学号对学生而言已经足够区分个体详细作答日志只保留 30 天过期自动清理学情分析需要的聚合数据单独存储家长端只能查看自己孩子的数据并且要通过班级邀请的方式绑定禁止家长通过姓名搜索其他学生AI 生成的题目和答疑记录做完整留痕可以追溯“这道题是什么时候生成、哪个班级在用、对应的知识点标签是什么”。这几条规则在数据模型设计阶段就写进了约束提示词里也反复强调。比起事后补救把这些规则前置到架构里省心得多。我还要求越权访问的接口一律返回同样的错误包不要让接口的报错信息在外层暴露不该出现的权限结构。6. 进阶心得Vibe Coding 能做什么不能做什么整套系统的推进方式和踩坑经验讲完了最后聊点更个人的东西。几周密集实践下来我对 Vibe Coding 的定位有了非常具体的判断。6.1 越快的工具越要求你有更深的架构能力很多人以为 Vibe Coding 是“什么都不会也能写程序”我的体会恰恰相反Vibe Coding 放大了你已有的架构能力也放大了你没有架构能力时的混乱。如果一个需求本身就是含糊的AI 会很快地制造出一堆看似完整的垃圾代码但如果你能在动手前先把数据模型、接口边界、技术约束都想清楚AI 的产出效率会指数级提高。这套系统做下来我发现真正花时间的不是“让 AI 写代码”而是“想清楚这段代码在系统里应该是什么位置”。AI 写代码可能只需要几秒钟但这几秒钟之前的架构思考可能需要几个小时。6.2 永远保留 AI 生成代码的人工复核能力有一套我自己坚持了很久的工作方式AI 每个迭代单元生成之后我一定亲手阅读它新增的代码亲手运行它写的测试然后才把这一刻交给版本控制。听起来很传统但这是唯一让我在 AI 生成代码上敢持续前进的方法。我见过有人完全信任 AI 输出、从不看代码几周之后整个项目变成谁也不敢动的黑盒也见过另一种极端每行生成代码都要反复质问 AI那 Vibe Coding 就没有意义了。折中方案是看几个关键点数据模型有没有增加意外的字段接口有没有越权暴露数据有没有引入陌生依赖单元测试是不是真的在测行为而不是测实现。这四个点过一遍比逐行阅读快得多但安全系数提升非常明显。AI 在帮你做执行但判断力永远在你自己手里。6.3 一个可持续的 Vibe Coding 工作流最后把一条几乎每天都在用的工作流固定下来。第一步把项目上下文块写进会话开头包括技术栈、数据模型、接口契约第二步把功能拆成最小闭环单元一个单元一个单元地推进第三步每完成一个单元就跑测试、做提交、写存档第四步所有 AI 生成的非代码资产比如提示词、题目模板、校验规则也纳入版本管理。这套流程看起来笨但它让 AI 生成的每一段代码都有了“可以被复盘”的价值。至于 Vibe Coding 还能不能更进一步比如自动规划模块、自动生成测试、自动做回归这些方向我还在试。但至少对 K12 AI 智能教育系统这个项目来说它已经从一个时髦的写代码方式变成了一套可以稳定交付的能力。可能这就是进阶实战最实在的意义。