1. 这个项目的真实价值在哪先说结论Vibe Coding 不是让你从零写代码而是让你用自然语言描述需求让 AI 帮你把基础框架搭好然后你像“技术负责人”一样去审查、修正、迭代。而“K12 AI 智能教育系统”这个例子是我个人认为最适合拿来练手做 Vibe Coding 完整流程的题材——因为它功能边界足够清晰业务逻辑不算复杂但又不是那种一晚上就能糊弄完的玩具项目刚好能逼你把“需求拆解→对话生成→人工审查→迭代优化→部署交付”整个闭环跑一遍。我模拟了这样一个场景某教育机构想做一个面向初中生的数学智能学习平台学生可以在上面做题、看知识点解析、获得个性化推荐老师可以查看班级学情报告。听起来像是一个正规软件公司要花两三个月才能交付的项目但实际上我用 Vibe Coding 的方式在一周内完成了核心原型的开发并且跑通了主流程。这篇文章就是把整个过程、每一步的关键对话、踩过的坑、以及最终的成果结构完整记录下来。适合谁看如果你已经会用 GPT 类工具写点小脚本但还没有系统性地用 AI 协作完成过一个完整项目或者你是产品经理、教育从业者想快速验证一个想法再或者你只是好奇“Vibe Coding 到底能不能做出正经产品”——这篇文章的内容都能让你直接复用。在开始之前我要先立一个原则Vibe Coding 不等于“躺平式生成”。AI 写代码你负责写“判断力”。你不需要记住每个函数的写法但你必须能看懂 AI 生成的代码在干什么能指出问题能告诉 AI 你想要什么。这个项目里我会详细展示我是怎么在每个阶段“把关”的。2. 先拆解K12 AI 智能教育系统到底要做什么我习惯在打开任意 AI 编程工具之前先自己花半小时把需求想清楚。我知道这对很多人来说很反直觉——你都有 AI 了为什么还要自己想因为模糊的需求交给 AI得到的只会是“看起来能用但哪里都不对”的东西。2.1 核心用户和典型场景这个系统我定义为面向三类角色学生登录后做选择题、填空题查看错题解析获得下一阶段学习建议老师查看班级整体正确率、各知识点掌握度、高频错题排名管理员维护题库、管理学生和老师账号典型使用场景是小明登录系统系统推荐了 10 道关于“一元二次方程”的题目他做完提交系统判定对错并针对他做错的那道题给出详细解析同时根据错题知识点调整后续题目难度。这个场景在真实教学里非常常见几乎所有 K12 在线教育产品都有类似功能。但作为 Vibe Coding 项目的切入点是绝对够格的——它包含前后端、数据库、聊天式交互、可视化报表能覆盖到编程的每个主要环节。2.2 从用户故事到功能清单我把自己当作一个只会提需求的产品经理把用户故事一个一个列出来然后翻译成功能清单。下面这张表格是我在项目开工前整理的它也是我后续跟 AI 对话的核心依据用户用户故事对应功能学生我要能登录并看到今天的推荐题目登录注册、题目推荐学生我做完题要立刻知道对错和解析答题判定、解析展示学生我要看到我的薄弱知识点和复习建议学情分析、推荐建议老师我要看到班级哪道题错得最多班级统计、错题排行老师我要知道哪些学生需要重点关注学生个人学情追踪管理员我要能维护题库且操作不麻烦题库管理界面当我拿着这张表给 AI 看的时候我不会让它“做一个系统”我会说“我们要做一个 K12 数学学习系统需要用户登录、题目列表、答题判定、学情分析、老师看板这五个模块先帮我搭建项目结构。”2.3 为什么选轻量级前后端分离方案这里要提一个很重要的取舍。市面上做教育系统的技术方案很多比如 Java Spring Boot MySQL或者 Python Django PostgreSQL再或者 Node.js MongoDB。我没有选这些重方案而是选择了前后端分离 SQLite 的轻量组合原因是项目目标是快速验证业务逻辑不是承载百万用户SQLite 不需要单独安装数据库服务文件即数据库对本地开发和演示极友好Python 的 FastAPI 框架能快速写接口且自带交互式接口文档非常适合 AI 生成代码后的验证如果你要给正式机构部署后续完全可以平滑迁移到 PostgreSQL业务代码不需要大改。这是我当时做技术选型时最重要的考量——架构轻但换轮子容易。3. 工具链搭建与第一轮对话实战3.1 我用到的工具和版本这个环节我按实际项目中使用的清单来列方便你复现编程助手某主流 AI 编程插件支持对话框对话、代码插入、文件内编辑编程语言Python 3.11后端框架FastAPI 0.95 及以上前端React Vite Tailwind CSSAI 帮我生成前端代码时这种组合出错率最低数据库SQLite配合 SQLAlchemy 操作本地测试工具浏览器 接口测试工具比如 Postman但其实 FastAPI 自带的文档页面已经够用我先新建了一个项目文件夹在 AI 编程工具里选择“将此文件夹作为工作区”然后开始了第一轮对话。3.2 第一轮对话生成项目骨架我的第一句话不是“请创建一个完整的教育系统”因为那会把 AI 打懵然后生成一堆你没有心理准备的文件。我的第一句话是请帮我搭建一个 FastAPI 项目骨架实现用户登录、题目列表、答题提交、学情统计四个基础 API数据库使用 SQLite SQLAlchemy项目结构要清晰文件不要故意合并。AI 很快就生成了如下结构edu-ai/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── database.py # 数据库连接配置 │ ├── models.py # 数据表模型 │ ├── schemas.py # 请求和响应数据格式 │ ├── routers/ │ │ ├── auth.py # 处理登录注册 │ │ ├── questions.py # 处理题目列表与答题 │ │ └── analytics.py # 学情统计 │ ├── crud.py # 操作数据库的函数 │ └── seed.py # 生成初始测试数据 ├── requirements.txt └── run.py这里要强调一个操作细节。AI 同时给我生成了很多文件后我没有直接说“很好”而是做了一件事逐个打开文件快速浏览确认它生成的代码和我脑子里的结构预期一致。这样做的好处是哪怕某个文件有问题我也不至于到最后才一并发现。我从 models.py 开始看发现它定义了四个模型分别是教师、学生、题目、答题记录。它很聪明地用了一个 User 表加 Role 字段来区分师生同时在表模型里加入了 grade 字段用于指定题目年级。但当我继续看的时候发现两个问题登录接口缺少密码加密处理直接用明文保存了题目表里缺少难度系数字段这样没法实现后续的智能推荐这两个问题我在第一轮就指出来了。这是 Vibe Coding 最关键的习惯——不要一次性生成完就接受要“审”代码。3.3 核心代码审查与修正我把问题直接告诉 AI密码要用哈希加密存储推荐使用 passlib 库。另外题目表加一个 difficulty 字段数值范围 1 到 5便于后续做难度推荐。AI 立刻调整了模型代码。下面这段是调整后的关键部分我贴出来供参考# app/models.py 片段 class User(Base): __tablename__ users id Column(Integer, primary_keyTrue, indexTrue) username Column(String, uniqueTrue, indexTrue) password_hash Column(String) role Column(String) # student / teacher / admin grade Column(Integer, nullableTrue) class Question(Base): __tablename__ questions id Column(Integer, primary_keyTrue, indexTrue) content Column(Text) option_a Column(String) option_b Column(String) option_c Column(String) option_d Column(String) answer Column(String) explanation Column(Text) # 题目解析 difficulty Column(Integer, default3) # 1-5 knowledge_point Column(String) # 例如一元二次方程看到这个模型我才有信心继续往下走。这里特别提醒在 AI 生成完代码之后你一定要看一遍字段定义这决定了后面所有功能的开发基础。如果这一步不改后面所有接口都是错误的靠后期修补会浪费大量时间。4. 核心功能实现的逐步实操记录4.1 登录注册功能的 Vibe Coding 过程我让 AI 实现注册接口和登录接口要求返回 JWT Token。这个需求如果让一个新手来写可能要写一下午但 AI 只需要一分钟。以下是我们的对话片段我请实现注册和登录接口。注册时用户名不能重复密码需要哈希存储。登录成功后返回一个 JWT Token有效期设置为 7 天。AI 生成了认证路由并且贴心地帮我处理了用户不存在和密码错误的提示。这里分享一个非常实用的经验让 AI 在生成功能的同时给接口加上异常处理的返回信息。这个逻辑你如果不在对话里提它经常默认只返回一个简单的错误码后面前端调试时会很痛苦。我在审查时注意到AI 生成的登录接口里用了datetime.timedelta(days7)作为 token 过期时间。但我需要确认一个细节——它没有提供将 token 自动带上用户角色的方式。为了让前端能区分学生和老师我追加了要求在 JWT 的 payload 里加入 role 和 user_id 字段这样前端拿到 token 后可以解析出用户身份。这个需求非常重要。后续前端要根据用户的角色来显示不同的页面一个小学生在页面上看到“班级学情分析”按钮就是功能混乱。AI 随即调整了代码最终的登录接口核心逻辑如下router.post(/login) def login(user: LoginRequest, db: Session Depends(get_db)): db_user db.query(User).filter(User.username user.username).first() if not db_user or not verify_password(user.password, db_user.password_hash): raise HTTPException(status_code401, detail用户名或密码错误) token_data { sub: str(db_user.id), role: db_user.role, } token create_access_token(token_data, expires_deltatimedelta(days7)) return {access_token: token, token_type: bearer, role: db_user.role, user_id: db_user.id}这段代码本身不复杂但对于一个 K12 系统的第一层身份验证来说已经足够。不要在原型阶段过度设计比如引入刷新令牌、黑名单机制那都是后续上线迭代的事。4.2 题库与答题判分功能AI 最适合的“体力活”题库是教育系统里最费人工的部分。如果纯手写 100 道题目既无聊又容易出错。这里我用 AI 批量生成了模拟数据。我给它提的要求非常明确生成 20 道初一数学题题型全部为选择题包含选项和答案解析。题目范围为一元一次方程、有理数运算、图形初步认识。难度分为 1 到 5越往后题目越难。输出格式为一个 Python 字典列表方便插入数据库。AI 非常高效地生成了这批数据但我在检查时发现了一个真实存在的典型问题部分选择题的答案和解析不匹配。比如有一道题答案是 C但解析里描述的是 B 选项的计算步骤。这种错误在 AI 生成内容里出现概率极高如果你直接拿去给学生使用就会导致教学事故。所以我的操作是把生成的题目数据保存到一个 JSON 文件里逐条抽查了 5 道题发现偏差后让 AI 重新生成并且在指令里加了一句“答案必须与解析严格对应请复核后再输出”。这件事给我最大的启发是AI 生成的知识性内容必须有“人审”环节尤其是教育领域。自动判分功能本身不复杂前后端配合就能完成但判分的依据一旦出错整个系统的可信度就归零了。答题判分逻辑我让 AI 用最基础的方式实现前端提交题目 id 和学生答案后端查询正确选项并比对返回是否正确和解析。以下是我认可的代码逻辑router.post(/submit) def submit_answer(answer: AnswerSubmit, db: Session Depends(get_db), userDepends(get_current_user)): question db.query(Question).filter(Question.id answer.question_id).first() if not question: raise HTTPException(status_code404, detail题目不存在) is_correct question.answer answer.selected_option record AnswerRecord( user_iduser.id, question_idquestion.id, selected_optionanswer.selected_option, is_correctis_correct ) db.add(record) db.commit() return { correct: is_correct, correct_option: question.answer, explanation: question.explanation }这一步看起来简单但它背后的一个关键点是答题记录必须存储原始答案选项而不仅仅是分数。这样后期做学情分析时才能知道学生到底错在哪一个知识点上。4.3 “类 AI 智能推荐”功能的实现思路K12 系统中的“智能推荐”是一个既不能太复杂也不能太敷衍的功能。考虑到原型阶段的数据量很小我放弃了会拖慢进度的机器学习方案而是让 AI 实现一个基于规则和知识点掌握度计算的推荐逻辑。我对 AI 的指令是学生的答题记录会被保存。我需要一个推荐接口它会统计学生在各知识点的正确率推荐正确率最低的知识点对应题目。推荐题目优先选择未做过的题目难度从简单到中等。如果这些题都做完了再推荐难度较高且错过的题目。这个逻辑用规则表达出来非常清晰AI 马上画出了一段逻辑router.get(/recommendations) def get_recommendations(userDepends(get_current_user), db: Session Depends(get_db)): records db.query(AnswerRecord).filter(AnswerRecord.user_id user.id).all() # 统计各知识点正确率 kp_stats {} for record in records: q db.query(Question).filter(Question.id record.question_id).first() kp q.knowledge_point if kp not in kp_stats: kp_stats[kp] {total: 0, correct: 0} kp_stats[kp][total] 1 if record.is_correct: kp_stats[kp][correct] 1 # 排序找出最薄弱知识点 weakest_kp sorted(kp_stats.items(), keylambda x: x[1][correct] / x[1][total])[0][0] # 推荐该知识点下难度适中的未做题目 done_ids {record.question_id for record in records} candidates db.query(Question).filter(Question.knowledge_point weakest_kp).all() recommendations [q for q in candidates if q.id not in done_ids] recommendations.sort(keylambda x: x.difficulty) return recommendations[:5]这段代码逻辑清晰但它有一个潜在问题如果一个学生新注册一条答题记录都没有直接查records[0]会报错。所以我又让 AI 加了一个默认推荐模块当没有记录时推荐初一全知识点的简单题。这也是做功能时最容易忽略的边界情况我用了一个自动化测试脚本去验证空数据场景效果很好。4.4 教师看板把数据变成可理解的学情报告老师端的核心不是“看到所有学生成绩”而是看到班级整体学习状态并有依据地调整教学。我让 AI 实现了三个基础指标整体正确率、知识点薄弱排行、高频错题 TOP5。教师看板实现过程中我对 AI 的生成结果做得最多的是“过滤”它一开始生成了很多我根本不需要的饼图、折线图但我觉得原型阶段的图表不在 HTML 里渲染反而用返回 JSON 格式的数据让前端自己选择展示方式更合理。所以我让它删掉所有图表代码只保留统计接口router.get(/classroom-report) def classroom_report(db: Session Depends(get_db), userDepends(get_current_user)): if user.role ! teacher: raise HTTPException(status_code403, detail无权限) all_records db.query(AnswerRecord).all() total_count len(all_records) correct_count sum(1 for r in all_records if r.is_correct) overall_accuracy round(correct_count / total_count * 100, 2) if total_count else 0 # 高频错题按错误次数倒序 wrong_count_map {} for r in all_records: if not r.is_correct: wrong_count_map[r.question_id] wrong_count_map.get(r.question_id, 0) 1 top_wrong_ids sorted(wrong_count_map.items(), keylambda x: x[1], reverseTrue)[:5] report [] for qid, cnt in top_wrong_ids: q db.query(Question).filter(Question.id qid).first() report.append({ question_id: qid, content: q.content, wrong_times: cnt }) return { overall_accuracy: overall_accuracy, total_records: total_count, top_wrong_questions: report }这段代码在原型阶段已经十分够用。只有在进入生产方式时我才会考虑对全班学生进行分组统计按班级字段过滤。Vibe Coding 的一个核心法则是在对话中不要提出“顺便加一个功能”的要求而是先让已有功能稳定再开新一轮对话。5. 前端页面与 AI 对话从 0 到 1 的完整页面构建5.1 前端技术选型的逻辑后端完成后我让 AI 生成了一个 React 前端。很多初学者会在这一步犯一个错误让 AI 一次性生成一个巨型单页应用结果页面不工作也不知道从哪里排查。我的方式是把页面当作一个一个小零件来组装。先实现登录页再实现学生做题页再实现老师看板页。每个页面完成之后都先在浏览器里验证通过后再进入下一步。AI 在前面的流程里帮我搭好了项目骨架我只需要在对话里描述页面需求。5.2 登录页面和做题页面的完整实现记录第一个页面是登录页我将需求描述为创建一个 React 登录页面包含用户名、密码输入框登录成功后把 token 存到 localStorage根据返回的 role 字段跳转到不同路径。跳转路径老师跳转到 /dashboard学生跳转到 /study。AI 生成的页面代码基本可用但我手动补充了在登录页面中显示“登录中”的加载状态避免用户重复点击。这个细节非常容易忽略但真实使用时体验差异很大。它也帮我加了表单校验空用户名或空密码不能提交。第二个页面是学生做题页这是整个系统里最核心的页面。我让 AI 实现了页面加载时调用推荐接口获取到五道题目以卡片形式展示每题四个选项用户点击选项后高亮选中点击“提交答题”后逐题调提交接口并显示正确与否和解析。做这个页面比较有意思因为 AI 对“用户点选项后按钮状态”的处理经常出错。第一次生成时题目提交后没有禁用页面用户还可以继续重复提交。我追加了要求题目提交后该题卡片需要锁定显示解析内容选项不可再更改。AI 随即调整了状态管理用一个submittedQues数组来存储已提交的题目 id。这个前端交互逻辑如果手写至少要半小时AI 十分钟就解决了。让我重新评价 Vibe Coding 的最大优势就是帮助大大压缩了“交互细节”的搭建时间——前提是你知道怎么描述这些细节。5.3 教师看板页面让 AI 生成数据表格教师看板页面相对简单主要是一张表格和几个统计数字卡片。需求是显示班级整体正确率、总答题次数、高频错题 Top5 表格表格有题号和题干以及错误次数。AI 实现了三个 StatCard 和一个表格组件。这张页面没有特别炫酷的设计但对于内部管理工具来说已经足够清晰。在真实项目中过于花哨的图形反而会增加开发周期和性能负担。6. 深入开发AI 个性化提分策略模块6.1 为什么要引入 AI 学习策略建议上面的推荐功能虽然能根据知识点正确率推荐题目但它缺少一个更重要的环节告诉学生“下一步该怎么学”。我做了一个学习策略建议接口它根据学生的答题数据生成三条建议。比如你在“一元一次方程”这个知识点表现较弱建议先复习基础概念再做难度 2 的练习题你的整体正确率较高可以尝试挑战更高难度题目你有 3 道做错的题目属于“有理数运算”建议重点整理错题本这类建议听起来很智能但本质上也是规则引擎。我让 AI 实现了这个逻辑并刻意要求它不用 AI 大模型去生成建议文本而是使用预置的模板拼接。这样做的原因是原型阶段不应该频繁调用大模型否则响应延迟高且成本不可控。这一段我单独拿出来讲是因为我个人觉得它才是“AI智能教育系统”这个标题里“AI”的真正体现——如果只是题库判分那叫管理系统不叫智能教育系统。有了对学习薄弱点的自动分析、对学习路径的建议才能说它具备了基础的教育智能属性。6.2 规则引擎式的 AI 策略实现我让 AI 实现的主要内容是从答题记录中提取知识点正确率生成建议。下面是核心逻辑router.get(/study-advice) def study_advice(userDepends(get_current_user), db: Session Depends(get_db)): records db.query(AnswerRecord).filter(AnswerRecord.user_id user.id).all() if not records: return {advice: [先完成几道练习题系统将为你生成个性化学习建议。]} kp_stats {} for r in records: q db.query(Question).filter(Question.id r.question_id).first() kp_stats.setdefault(q.knowledge_point, {total: 0, correct: 0}) kp_stats[q.knowledge_point][total] 1 if r.is_correct: kp_stats[q.knowledge_point][correct] 1 weak_points [] strong_points [] for kp, stat in kp_stats.items(): acc stat[correct] / stat[total] if acc 0.6: weak_points.append(kp) elif acc 0.85: strong_points.append(kp) advice [] for kp in weak_points[:2]: advice.append(f你在知识点“{kp}”上正确率偏低建议复习基础概念再完成对应练习题。) for kp in strong_points[:1]: advice.append(f你在“{kp}”掌握得不错可以挑战更高难度的综合题。) if len(advice) 2: advice.append(整体学习状态良好注意保持错题整理的习惯。) return {advice: advice}这个模块的最大价值是它把“数据和语义”衔接了起来。后端只返回知识点和正确率前端页面再把建议渲染成更友好的卡片样式。由于这里的规则逻辑清晰我把生成建议的模板单独放在一个地方方便未来增加更多建议模板而不影响主程序。7. 数据初始化别忽略的种子数据脚本系统能跑通之后我意识到一个问题如果每次新环境都要手动插入题目和管理员账号那项目就不能交付。于是我用 AI 重新生成并改写了之前顺手写的seed.py功能包括创建一个默认管理员账号用户名 admin密码 admin123创建一个教师账号和一个学生账号插入 50 道数学选择题给题库里的每道题标记知识点和难度我在审查过程中发现 AI 生成的数据虽然数量充足但知识点分布很不均匀。比如 40 道题都集中在“一元一次方程”其他知识点几乎没有。这样学生在其他知识点上就没有题目可做推荐功能也会失效。于是我给 AI 追加指令知识点分布要均衡一元一次方程、不等式、有理数运算、几何初步、数据统计每个知识点至少 8 道题。这一步是最好的例子说明在 Vibe Coding 中“人”要负责的并不是写代码而是分配数据资源和业务合理性。AI 永远不会替你思考“这个班级的老师真正需要什么”它只会按照你给的要求完成任务。8. 实测效果与问题修复实录8.1 首次完整流程测试记录系统全栈打通后我进行了一次端到端测试用户流程如下学生登录页面输入student01 / 123456成功跳转/study系统显示 5 道推荐题目页面渲染正常我提交 3 道正确、2 道错误页面正常显示解析请求/study-advice返回 3 条建议其中最薄弱知识点为“一元一次方程”教师登录查看班级报告整体正确率和高频错题显示正常管理员登录查看题库管理页面能正常增删题目整体流程非常顺利连我自己都惊讶于 Vibe Coding 协作的实际效果。但我必须承认有些问题只有真实测试才会暴露不会在生成阶段发现。8.2 Vibe Coding 最容易翻车的三个真实问题这三个问题我挨个遇到了下面直接给出解决过程和心得强烈建议保存问题一请求接口返回 500但控制台没有报错。排查思路先看浏览器请求的响应体找到具体报错信息。后来发现是前端在调用推荐接口时没有传入必需的 Authorization 请求头而后端代码中get_current_user强制要求认证。解决方式是补全 Axios 请求拦截器在每次请求时自动带上 token。这种问题如果手写调试会花很久但在这里因为是 AI 生成的代码我直接问它“帮我看一下这个报错并修复”它扫了一遍代码后指出了问题。问题二题目推荐接口在同一知识点下重复推荐题目。原因是推荐逻辑中只是把未做过的题作为一个整体候选列表但没有过滤已推荐过的题目。当学生第一次拿到 5 道题但只做了 2 道时第二次刷新又会推荐同样的题。解决方式是将已生成的推荐记录存到数据库或者简化处理每次刷新就重新生成不做会话内去重。原型阶段我采用了更简单的方案——刷新后如果还有未做题就继续返回它们直到全部完成再刷新。问题三数据库表结构中途修改后旧数据仍然残留导致接口崩溃。这个是最坑的也是新手会踩的。我在开发过程中修改了题目的 difficulty 字段但没删掉旧的 SQLite 数据库文件。旧表里没有这个字段程序读取时直接报错。解决办法是删掉旧数据库重新运行 seed.py 初始化。这个操作至关重要Vibe Coding 阶段不要保留旧数据库你改一次模型就删掉重来一次不然各种疑难杂症接踵而至。8.3 完整功能测试清单我把自己的测试清单分享出来你可以拿着逐项核对功能模块测试步骤预期结果注册注册新学生账号注册成功密码加密存储登录正确密码登录拿到 token 和 role登录错误密码登录返回错误提示题目推荐新用户请求推荐返回全知识点默认题目答题提交正确答案correct 为 true返回解析答题提交错误答案correct 为 false返回正确选项学情建议多次答题后请求建议返回薄弱知识点建议教师看板教师账号访问返回整体统计和高频错题权限学生账号访问教师接口返回 403这个清单不等于自动化测试但对于原型验证已经足够。如果你是认真投入这个项目的开发者后续再引入 pytest 写自动化接口测试。9. 从原型到可部署还有什么没做原型跑通后我给自己划了一条线这个项目到目前阶段还是一个可以 demo 的prototype不是可以直接交付的生产系统。要把它变成真正可以给学校师生使用的产品至少还要补全这些关键模块题库管理界面目前题目是存在数据库里的管理员要在界面上操作需要前端页面 后端 CRUD 接口多班级支持真实的学校有多个班级每个班级有不同教师需要增加班级表和教师-班级关联作业安排教师给不同班级布置不同作业学生只看到自己班级的作业数据安全正式系统需要更严格的密码策略管理员权限分级部署上线前端打包后放到服务器后端用服务部署数据库需要备份机制这些内容并不是一次 Vibe Coding 对话能解决的。但基于现在这个架构每一条都是清晰可控的新功能迭代你完全可以继续通过“新一轮对话”来推进。这正是 Vibe Coding 的开发节奏——你不需要一次性把所有逻辑全塞给 AI而是把工作切分成一个个可验证的阶段。我在实际做这个项目时最大的体会是Vibe Coding 真不是“偷懒神器”反而要求你对业务和代码有更强的判断力。你像一个带着 AI 助理的架构师一边描述需求一边检查结果一边指出错误。你写代码的时间变少了但思考的时间变多了。如果你刚接触这种开发方式我建议你也从一个有明确边界的业务系统入手最好是有用户、有数据、有数据可视化的小项目。别一上来就做那种抽象算法或者底层框架的东西。等你像我一样把 AI 当施工队指挥从地基到装修完完整整地走完一个项目你就会发现干活的人换了拍板的人永远是你。最后再分享一个小技巧我在每次跟 AI 对话时都会把最近一轮的功能描述、遇到的问题、期望的解决方向写成一个带编号的列表比如“1. 现在推荐接口会重复返回题目 2. 增加一个按题目 id 去重的机制 3. 如果去重后不够 5 道题则从未做过的最难题里补全”。这种结构化指令比一句话“推荐有问题修复一下”要高效得多AI 返回的代码也更精准。这个习惯我一用就是几百轮非常管用。
1. 这个项目的真实价值在哪先说结论Vibe Coding 不是让你从零写代码而是让你用自然语言描述需求让 AI 帮你把基础框架搭好然后你像“技术负责人”一样去审查、修正、迭代。而“K12 AI 智能教育系统”这个例子是我个人认为最适合拿来练手做 Vibe Coding 完整流程的题材——因为它功能边界足够清晰业务逻辑不算复杂但又不是那种一晚上就能糊弄完的玩具项目刚好能逼你把“需求拆解→对话生成→人工审查→迭代优化→部署交付”整个闭环跑一遍。我模拟了这样一个场景某教育机构想做一个面向初中生的数学智能学习平台学生可以在上面做题、看知识点解析、获得个性化推荐老师可以查看班级学情报告。听起来像是一个正规软件公司要花两三个月才能交付的项目但实际上我用 Vibe Coding 的方式在一周内完成了核心原型的开发并且跑通了主流程。这篇文章就是把整个过程、每一步的关键对话、踩过的坑、以及最终的成果结构完整记录下来。适合谁看如果你已经会用 GPT 类工具写点小脚本但还没有系统性地用 AI 协作完成过一个完整项目或者你是产品经理、教育从业者想快速验证一个想法再或者你只是好奇“Vibe Coding 到底能不能做出正经产品”——这篇文章的内容都能让你直接复用。在开始之前我要先立一个原则Vibe Coding 不等于“躺平式生成”。AI 写代码你负责写“判断力”。你不需要记住每个函数的写法但你必须能看懂 AI 生成的代码在干什么能指出问题能告诉 AI 你想要什么。这个项目里我会详细展示我是怎么在每个阶段“把关”的。2. 先拆解K12 AI 智能教育系统到底要做什么我习惯在打开任意 AI 编程工具之前先自己花半小时把需求想清楚。我知道这对很多人来说很反直觉——你都有 AI 了为什么还要自己想因为模糊的需求交给 AI得到的只会是“看起来能用但哪里都不对”的东西。2.1 核心用户和典型场景这个系统我定义为面向三类角色学生登录后做选择题、填空题查看错题解析获得下一阶段学习建议老师查看班级整体正确率、各知识点掌握度、高频错题排名管理员维护题库、管理学生和老师账号典型使用场景是小明登录系统系统推荐了 10 道关于“一元二次方程”的题目他做完提交系统判定对错并针对他做错的那道题给出详细解析同时根据错题知识点调整后续题目难度。这个场景在真实教学里非常常见几乎所有 K12 在线教育产品都有类似功能。但作为 Vibe Coding 项目的切入点是绝对够格的——它包含前后端、数据库、聊天式交互、可视化报表能覆盖到编程的每个主要环节。2.2 从用户故事到功能清单我把自己当作一个只会提需求的产品经理把用户故事一个一个列出来然后翻译成功能清单。下面这张表格是我在项目开工前整理的它也是我后续跟 AI 对话的核心依据用户用户故事对应功能学生我要能登录并看到今天的推荐题目登录注册、题目推荐学生我做完题要立刻知道对错和解析答题判定、解析展示学生我要看到我的薄弱知识点和复习建议学情分析、推荐建议老师我要看到班级哪道题错得最多班级统计、错题排行老师我要知道哪些学生需要重点关注学生个人学情追踪管理员我要能维护题库且操作不麻烦题库管理界面当我拿着这张表给 AI 看的时候我不会让它“做一个系统”我会说“我们要做一个 K12 数学学习系统需要用户登录、题目列表、答题判定、学情分析、老师看板这五个模块先帮我搭建项目结构。”2.3 为什么选轻量级前后端分离方案这里要提一个很重要的取舍。市面上做教育系统的技术方案很多比如 Java Spring Boot MySQL或者 Python Django PostgreSQL再或者 Node.js MongoDB。我没有选这些重方案而是选择了前后端分离 SQLite 的轻量组合原因是项目目标是快速验证业务逻辑不是承载百万用户SQLite 不需要单独安装数据库服务文件即数据库对本地开发和演示极友好Python 的 FastAPI 框架能快速写接口且自带交互式接口文档非常适合 AI 生成代码后的验证如果你要给正式机构部署后续完全可以平滑迁移到 PostgreSQL业务代码不需要大改。这是我当时做技术选型时最重要的考量——架构轻但换轮子容易。3. 工具链搭建与第一轮对话实战3.1 我用到的工具和版本这个环节我按实际项目中使用的清单来列方便你复现编程助手某主流 AI 编程插件支持对话框对话、代码插入、文件内编辑编程语言Python 3.11后端框架FastAPI 0.95 及以上前端React Vite Tailwind CSSAI 帮我生成前端代码时这种组合出错率最低数据库SQLite配合 SQLAlchemy 操作本地测试工具浏览器 接口测试工具比如 Postman但其实 FastAPI 自带的文档页面已经够用我先新建了一个项目文件夹在 AI 编程工具里选择“将此文件夹作为工作区”然后开始了第一轮对话。3.2 第一轮对话生成项目骨架我的第一句话不是“请创建一个完整的教育系统”因为那会把 AI 打懵然后生成一堆你没有心理准备的文件。我的第一句话是请帮我搭建一个 FastAPI 项目骨架实现用户登录、题目列表、答题提交、学情统计四个基础 API数据库使用 SQLite SQLAlchemy项目结构要清晰文件不要故意合并。AI 很快就生成了如下结构edu-ai/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── database.py # 数据库连接配置 │ ├── models.py # 数据表模型 │ ├── schemas.py # 请求和响应数据格式 │ ├── routers/ │ │ ├── auth.py # 处理登录注册 │ │ ├── questions.py # 处理题目列表与答题 │ │ └── analytics.py # 学情统计 │ ├── crud.py # 操作数据库的函数 │ └── seed.py # 生成初始测试数据 ├── requirements.txt └── run.py这里要强调一个操作细节。AI 同时给我生成了很多文件后我没有直接说“很好”而是做了一件事逐个打开文件快速浏览确认它生成的代码和我脑子里的结构预期一致。这样做的好处是哪怕某个文件有问题我也不至于到最后才一并发现。我从 models.py 开始看发现它定义了四个模型分别是教师、学生、题目、答题记录。它很聪明地用了一个 User 表加 Role 字段来区分师生同时在表模型里加入了 grade 字段用于指定题目年级。但当我继续看的时候发现两个问题登录接口缺少密码加密处理直接用明文保存了题目表里缺少难度系数字段这样没法实现后续的智能推荐这两个问题我在第一轮就指出来了。这是 Vibe Coding 最关键的习惯——不要一次性生成完就接受要“审”代码。3.3 核心代码审查与修正我把问题直接告诉 AI密码要用哈希加密存储推荐使用 passlib 库。另外题目表加一个 difficulty 字段数值范围 1 到 5便于后续做难度推荐。AI 立刻调整了模型代码。下面这段是调整后的关键部分我贴出来供参考# app/models.py 片段 class User(Base): __tablename__ users id Column(Integer, primary_keyTrue, indexTrue) username Column(String, uniqueTrue, indexTrue) password_hash Column(String) role Column(String) # student / teacher / admin grade Column(Integer, nullableTrue) class Question(Base): __tablename__ questions id Column(Integer, primary_keyTrue, indexTrue) content Column(Text) option_a Column(String) option_b Column(String) option_c Column(String) option_d Column(String) answer Column(String) explanation Column(Text) # 题目解析 difficulty Column(Integer, default3) # 1-5 knowledge_point Column(String) # 例如一元二次方程看到这个模型我才有信心继续往下走。这里特别提醒在 AI 生成完代码之后你一定要看一遍字段定义这决定了后面所有功能的开发基础。如果这一步不改后面所有接口都是错误的靠后期修补会浪费大量时间。4. 核心功能实现的逐步实操记录4.1 登录注册功能的 Vibe Coding 过程我让 AI 实现注册接口和登录接口要求返回 JWT Token。这个需求如果让一个新手来写可能要写一下午但 AI 只需要一分钟。以下是我们的对话片段我请实现注册和登录接口。注册时用户名不能重复密码需要哈希存储。登录成功后返回一个 JWT Token有效期设置为 7 天。AI 生成了认证路由并且贴心地帮我处理了用户不存在和密码错误的提示。这里分享一个非常实用的经验让 AI 在生成功能的同时给接口加上异常处理的返回信息。这个逻辑你如果不在对话里提它经常默认只返回一个简单的错误码后面前端调试时会很痛苦。我在审查时注意到AI 生成的登录接口里用了datetime.timedelta(days7)作为 token 过期时间。但我需要确认一个细节——它没有提供将 token 自动带上用户角色的方式。为了让前端能区分学生和老师我追加了要求在 JWT 的 payload 里加入 role 和 user_id 字段这样前端拿到 token 后可以解析出用户身份。这个需求非常重要。后续前端要根据用户的角色来显示不同的页面一个小学生在页面上看到“班级学情分析”按钮就是功能混乱。AI 随即调整了代码最终的登录接口核心逻辑如下router.post(/login) def login(user: LoginRequest, db: Session Depends(get_db)): db_user db.query(User).filter(User.username user.username).first() if not db_user or not verify_password(user.password, db_user.password_hash): raise HTTPException(status_code401, detail用户名或密码错误) token_data { sub: str(db_user.id), role: db_user.role, } token create_access_token(token_data, expires_deltatimedelta(days7)) return {access_token: token, token_type: bearer, role: db_user.role, user_id: db_user.id}这段代码本身不复杂但对于一个 K12 系统的第一层身份验证来说已经足够。不要在原型阶段过度设计比如引入刷新令牌、黑名单机制那都是后续上线迭代的事。4.2 题库与答题判分功能AI 最适合的“体力活”题库是教育系统里最费人工的部分。如果纯手写 100 道题目既无聊又容易出错。这里我用 AI 批量生成了模拟数据。我给它提的要求非常明确生成 20 道初一数学题题型全部为选择题包含选项和答案解析。题目范围为一元一次方程、有理数运算、图形初步认识。难度分为 1 到 5越往后题目越难。输出格式为一个 Python 字典列表方便插入数据库。AI 非常高效地生成了这批数据但我在检查时发现了一个真实存在的典型问题部分选择题的答案和解析不匹配。比如有一道题答案是 C但解析里描述的是 B 选项的计算步骤。这种错误在 AI 生成内容里出现概率极高如果你直接拿去给学生使用就会导致教学事故。所以我的操作是把生成的题目数据保存到一个 JSON 文件里逐条抽查了 5 道题发现偏差后让 AI 重新生成并且在指令里加了一句“答案必须与解析严格对应请复核后再输出”。这件事给我最大的启发是AI 生成的知识性内容必须有“人审”环节尤其是教育领域。自动判分功能本身不复杂前后端配合就能完成但判分的依据一旦出错整个系统的可信度就归零了。答题判分逻辑我让 AI 用最基础的方式实现前端提交题目 id 和学生答案后端查询正确选项并比对返回是否正确和解析。以下是我认可的代码逻辑router.post(/submit) def submit_answer(answer: AnswerSubmit, db: Session Depends(get_db), userDepends(get_current_user)): question db.query(Question).filter(Question.id answer.question_id).first() if not question: raise HTTPException(status_code404, detail题目不存在) is_correct question.answer answer.selected_option record AnswerRecord( user_iduser.id, question_idquestion.id, selected_optionanswer.selected_option, is_correctis_correct ) db.add(record) db.commit() return { correct: is_correct, correct_option: question.answer, explanation: question.explanation }这一步看起来简单但它背后的一个关键点是答题记录必须存储原始答案选项而不仅仅是分数。这样后期做学情分析时才能知道学生到底错在哪一个知识点上。4.3 “类 AI 智能推荐”功能的实现思路K12 系统中的“智能推荐”是一个既不能太复杂也不能太敷衍的功能。考虑到原型阶段的数据量很小我放弃了会拖慢进度的机器学习方案而是让 AI 实现一个基于规则和知识点掌握度计算的推荐逻辑。我对 AI 的指令是学生的答题记录会被保存。我需要一个推荐接口它会统计学生在各知识点的正确率推荐正确率最低的知识点对应题目。推荐题目优先选择未做过的题目难度从简单到中等。如果这些题都做完了再推荐难度较高且错过的题目。这个逻辑用规则表达出来非常清晰AI 马上画出了一段逻辑router.get(/recommendations) def get_recommendations(userDepends(get_current_user), db: Session Depends(get_db)): records db.query(AnswerRecord).filter(AnswerRecord.user_id user.id).all() # 统计各知识点正确率 kp_stats {} for record in records: q db.query(Question).filter(Question.id record.question_id).first() kp q.knowledge_point if kp not in kp_stats: kp_stats[kp] {total: 0, correct: 0} kp_stats[kp][total] 1 if record.is_correct: kp_stats[kp][correct] 1 # 排序找出最薄弱知识点 weakest_kp sorted(kp_stats.items(), keylambda x: x[1][correct] / x[1][total])[0][0] # 推荐该知识点下难度适中的未做题目 done_ids {record.question_id for record in records} candidates db.query(Question).filter(Question.knowledge_point weakest_kp).all() recommendations [q for q in candidates if q.id not in done_ids] recommendations.sort(keylambda x: x.difficulty) return recommendations[:5]这段代码逻辑清晰但它有一个潜在问题如果一个学生新注册一条答题记录都没有直接查records[0]会报错。所以我又让 AI 加了一个默认推荐模块当没有记录时推荐初一全知识点的简单题。这也是做功能时最容易忽略的边界情况我用了一个自动化测试脚本去验证空数据场景效果很好。4.4 教师看板把数据变成可理解的学情报告老师端的核心不是“看到所有学生成绩”而是看到班级整体学习状态并有依据地调整教学。我让 AI 实现了三个基础指标整体正确率、知识点薄弱排行、高频错题 TOP5。教师看板实现过程中我对 AI 的生成结果做得最多的是“过滤”它一开始生成了很多我根本不需要的饼图、折线图但我觉得原型阶段的图表不在 HTML 里渲染反而用返回 JSON 格式的数据让前端自己选择展示方式更合理。所以我让它删掉所有图表代码只保留统计接口router.get(/classroom-report) def classroom_report(db: Session Depends(get_db), userDepends(get_current_user)): if user.role ! teacher: raise HTTPException(status_code403, detail无权限) all_records db.query(AnswerRecord).all() total_count len(all_records) correct_count sum(1 for r in all_records if r.is_correct) overall_accuracy round(correct_count / total_count * 100, 2) if total_count else 0 # 高频错题按错误次数倒序 wrong_count_map {} for r in all_records: if not r.is_correct: wrong_count_map[r.question_id] wrong_count_map.get(r.question_id, 0) 1 top_wrong_ids sorted(wrong_count_map.items(), keylambda x: x[1], reverseTrue)[:5] report [] for qid, cnt in top_wrong_ids: q db.query(Question).filter(Question.id qid).first() report.append({ question_id: qid, content: q.content, wrong_times: cnt }) return { overall_accuracy: overall_accuracy, total_records: total_count, top_wrong_questions: report }这段代码在原型阶段已经十分够用。只有在进入生产方式时我才会考虑对全班学生进行分组统计按班级字段过滤。Vibe Coding 的一个核心法则是在对话中不要提出“顺便加一个功能”的要求而是先让已有功能稳定再开新一轮对话。5. 前端页面与 AI 对话从 0 到 1 的完整页面构建5.1 前端技术选型的逻辑后端完成后我让 AI 生成了一个 React 前端。很多初学者会在这一步犯一个错误让 AI 一次性生成一个巨型单页应用结果页面不工作也不知道从哪里排查。我的方式是把页面当作一个一个小零件来组装。先实现登录页再实现学生做题页再实现老师看板页。每个页面完成之后都先在浏览器里验证通过后再进入下一步。AI 在前面的流程里帮我搭好了项目骨架我只需要在对话里描述页面需求。5.2 登录页面和做题页面的完整实现记录第一个页面是登录页我将需求描述为创建一个 React 登录页面包含用户名、密码输入框登录成功后把 token 存到 localStorage根据返回的 role 字段跳转到不同路径。跳转路径老师跳转到 /dashboard学生跳转到 /study。AI 生成的页面代码基本可用但我手动补充了在登录页面中显示“登录中”的加载状态避免用户重复点击。这个细节非常容易忽略但真实使用时体验差异很大。它也帮我加了表单校验空用户名或空密码不能提交。第二个页面是学生做题页这是整个系统里最核心的页面。我让 AI 实现了页面加载时调用推荐接口获取到五道题目以卡片形式展示每题四个选项用户点击选项后高亮选中点击“提交答题”后逐题调提交接口并显示正确与否和解析。做这个页面比较有意思因为 AI 对“用户点选项后按钮状态”的处理经常出错。第一次生成时题目提交后没有禁用页面用户还可以继续重复提交。我追加了要求题目提交后该题卡片需要锁定显示解析内容选项不可再更改。AI 随即调整了状态管理用一个submittedQues数组来存储已提交的题目 id。这个前端交互逻辑如果手写至少要半小时AI 十分钟就解决了。让我重新评价 Vibe Coding 的最大优势就是帮助大大压缩了“交互细节”的搭建时间——前提是你知道怎么描述这些细节。5.3 教师看板页面让 AI 生成数据表格教师看板页面相对简单主要是一张表格和几个统计数字卡片。需求是显示班级整体正确率、总答题次数、高频错题 Top5 表格表格有题号和题干以及错误次数。AI 实现了三个 StatCard 和一个表格组件。这张页面没有特别炫酷的设计但对于内部管理工具来说已经足够清晰。在真实项目中过于花哨的图形反而会增加开发周期和性能负担。6. 深入开发AI 个性化提分策略模块6.1 为什么要引入 AI 学习策略建议上面的推荐功能虽然能根据知识点正确率推荐题目但它缺少一个更重要的环节告诉学生“下一步该怎么学”。我做了一个学习策略建议接口它根据学生的答题数据生成三条建议。比如你在“一元一次方程”这个知识点表现较弱建议先复习基础概念再做难度 2 的练习题你的整体正确率较高可以尝试挑战更高难度题目你有 3 道做错的题目属于“有理数运算”建议重点整理错题本这类建议听起来很智能但本质上也是规则引擎。我让 AI 实现了这个逻辑并刻意要求它不用 AI 大模型去生成建议文本而是使用预置的模板拼接。这样做的原因是原型阶段不应该频繁调用大模型否则响应延迟高且成本不可控。这一段我单独拿出来讲是因为我个人觉得它才是“AI智能教育系统”这个标题里“AI”的真正体现——如果只是题库判分那叫管理系统不叫智能教育系统。有了对学习薄弱点的自动分析、对学习路径的建议才能说它具备了基础的教育智能属性。6.2 规则引擎式的 AI 策略实现我让 AI 实现的主要内容是从答题记录中提取知识点正确率生成建议。下面是核心逻辑router.get(/study-advice) def study_advice(userDepends(get_current_user), db: Session Depends(get_db)): records db.query(AnswerRecord).filter(AnswerRecord.user_id user.id).all() if not records: return {advice: [先完成几道练习题系统将为你生成个性化学习建议。]} kp_stats {} for r in records: q db.query(Question).filter(Question.id r.question_id).first() kp_stats.setdefault(q.knowledge_point, {total: 0, correct: 0}) kp_stats[q.knowledge_point][total] 1 if r.is_correct: kp_stats[q.knowledge_point][correct] 1 weak_points [] strong_points [] for kp, stat in kp_stats.items(): acc stat[correct] / stat[total] if acc 0.6: weak_points.append(kp) elif acc 0.85: strong_points.append(kp) advice [] for kp in weak_points[:2]: advice.append(f你在知识点“{kp}”上正确率偏低建议复习基础概念再完成对应练习题。) for kp in strong_points[:1]: advice.append(f你在“{kp}”掌握得不错可以挑战更高难度的综合题。) if len(advice) 2: advice.append(整体学习状态良好注意保持错题整理的习惯。) return {advice: advice}这个模块的最大价值是它把“数据和语义”衔接了起来。后端只返回知识点和正确率前端页面再把建议渲染成更友好的卡片样式。由于这里的规则逻辑清晰我把生成建议的模板单独放在一个地方方便未来增加更多建议模板而不影响主程序。7. 数据初始化别忽略的种子数据脚本系统能跑通之后我意识到一个问题如果每次新环境都要手动插入题目和管理员账号那项目就不能交付。于是我用 AI 重新生成并改写了之前顺手写的seed.py功能包括创建一个默认管理员账号用户名 admin密码 admin123创建一个教师账号和一个学生账号插入 50 道数学选择题给题库里的每道题标记知识点和难度我在审查过程中发现 AI 生成的数据虽然数量充足但知识点分布很不均匀。比如 40 道题都集中在“一元一次方程”其他知识点几乎没有。这样学生在其他知识点上就没有题目可做推荐功能也会失效。于是我给 AI 追加指令知识点分布要均衡一元一次方程、不等式、有理数运算、几何初步、数据统计每个知识点至少 8 道题。这一步是最好的例子说明在 Vibe Coding 中“人”要负责的并不是写代码而是分配数据资源和业务合理性。AI 永远不会替你思考“这个班级的老师真正需要什么”它只会按照你给的要求完成任务。8. 实测效果与问题修复实录8.1 首次完整流程测试记录系统全栈打通后我进行了一次端到端测试用户流程如下学生登录页面输入student01 / 123456成功跳转/study系统显示 5 道推荐题目页面渲染正常我提交 3 道正确、2 道错误页面正常显示解析请求/study-advice返回 3 条建议其中最薄弱知识点为“一元一次方程”教师登录查看班级报告整体正确率和高频错题显示正常管理员登录查看题库管理页面能正常增删题目整体流程非常顺利连我自己都惊讶于 Vibe Coding 协作的实际效果。但我必须承认有些问题只有真实测试才会暴露不会在生成阶段发现。8.2 Vibe Coding 最容易翻车的三个真实问题这三个问题我挨个遇到了下面直接给出解决过程和心得强烈建议保存问题一请求接口返回 500但控制台没有报错。排查思路先看浏览器请求的响应体找到具体报错信息。后来发现是前端在调用推荐接口时没有传入必需的 Authorization 请求头而后端代码中get_current_user强制要求认证。解决方式是补全 Axios 请求拦截器在每次请求时自动带上 token。这种问题如果手写调试会花很久但在这里因为是 AI 生成的代码我直接问它“帮我看一下这个报错并修复”它扫了一遍代码后指出了问题。问题二题目推荐接口在同一知识点下重复推荐题目。原因是推荐逻辑中只是把未做过的题作为一个整体候选列表但没有过滤已推荐过的题目。当学生第一次拿到 5 道题但只做了 2 道时第二次刷新又会推荐同样的题。解决方式是将已生成的推荐记录存到数据库或者简化处理每次刷新就重新生成不做会话内去重。原型阶段我采用了更简单的方案——刷新后如果还有未做题就继续返回它们直到全部完成再刷新。问题三数据库表结构中途修改后旧数据仍然残留导致接口崩溃。这个是最坑的也是新手会踩的。我在开发过程中修改了题目的 difficulty 字段但没删掉旧的 SQLite 数据库文件。旧表里没有这个字段程序读取时直接报错。解决办法是删掉旧数据库重新运行 seed.py 初始化。这个操作至关重要Vibe Coding 阶段不要保留旧数据库你改一次模型就删掉重来一次不然各种疑难杂症接踵而至。8.3 完整功能测试清单我把自己的测试清单分享出来你可以拿着逐项核对功能模块测试步骤预期结果注册注册新学生账号注册成功密码加密存储登录正确密码登录拿到 token 和 role登录错误密码登录返回错误提示题目推荐新用户请求推荐返回全知识点默认题目答题提交正确答案correct 为 true返回解析答题提交错误答案correct 为 false返回正确选项学情建议多次答题后请求建议返回薄弱知识点建议教师看板教师账号访问返回整体统计和高频错题权限学生账号访问教师接口返回 403这个清单不等于自动化测试但对于原型验证已经足够。如果你是认真投入这个项目的开发者后续再引入 pytest 写自动化接口测试。9. 从原型到可部署还有什么没做原型跑通后我给自己划了一条线这个项目到目前阶段还是一个可以 demo 的prototype不是可以直接交付的生产系统。要把它变成真正可以给学校师生使用的产品至少还要补全这些关键模块题库管理界面目前题目是存在数据库里的管理员要在界面上操作需要前端页面 后端 CRUD 接口多班级支持真实的学校有多个班级每个班级有不同教师需要增加班级表和教师-班级关联作业安排教师给不同班级布置不同作业学生只看到自己班级的作业数据安全正式系统需要更严格的密码策略管理员权限分级部署上线前端打包后放到服务器后端用服务部署数据库需要备份机制这些内容并不是一次 Vibe Coding 对话能解决的。但基于现在这个架构每一条都是清晰可控的新功能迭代你完全可以继续通过“新一轮对话”来推进。这正是 Vibe Coding 的开发节奏——你不需要一次性把所有逻辑全塞给 AI而是把工作切分成一个个可验证的阶段。我在实际做这个项目时最大的体会是Vibe Coding 真不是“偷懒神器”反而要求你对业务和代码有更强的判断力。你像一个带着 AI 助理的架构师一边描述需求一边检查结果一边指出错误。你写代码的时间变少了但思考的时间变多了。如果你刚接触这种开发方式我建议你也从一个有明确边界的业务系统入手最好是有用户、有数据、有数据可视化的小项目。别一上来就做那种抽象算法或者底层框架的东西。等你像我一样把 AI 当施工队指挥从地基到装修完完整整地走完一个项目你就会发现干活的人换了拍板的人永远是你。最后再分享一个小技巧我在每次跟 AI 对话时都会把最近一轮的功能描述、遇到的问题、期望的解决方向写成一个带编号的列表比如“1. 现在推荐接口会重复返回题目 2. 增加一个按题目 id 去重的机制 3. 如果去重后不够 5 道题则从未做过的最难题里补全”。这种结构化指令比一句话“推荐有问题修复一下”要高效得多AI 返回的代码也更精准。这个习惯我一用就是几百轮非常管用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
