AI协助开发——从零搭建学情追踪系统

背景

作为一个教育工作者,我一直想做一套帮助学生精准定位薄弱知识点的系统。但之前困于技术能力——我并不是专业程序员。直到我开始系统性地使用 AI 辅助编程,一切变得不同了。

从想法到原型:只需一个正确的描述

传统开发流程是:需求文档 → UI 设计 → 前端开发 → 后端开发 → 数据库设计 → 联调测试。每个环节都需要不同技能的人参与。

而 AI 辅助开发的流程变成了:用自然语言描述你想要的 → AI 生成代码 → 你审查和微调 → 部署上线

举个例子,当我想要一个”学生错题本,能拍照上传、自动标注知识点、按遗忘曲线提醒复习”时,我不需要画原型图——我只需要把这个需求清晰地描述给 AI,它就能生成可运行的代码框架。

关键经验:分而治之

整个系统包含 19 张数据库表、31 个 API 接口、11 个前端页面。一下子全扔给 AI 是不现实的。

我的做法是按功能模块逐个击破

  1. 先搭好用户认证和权限系统
  2. 再做学生管理和仪表盘
  3. 然后实现错题本的增删改查
  4. 逐步加上 AI 识别、考试分析等高级功能

每个模块独立开发、独立测试,确认没问题再进入下一个。AI 在每个步骤中充当”高级助手”——它写代码框架,我来验证业务逻辑是否正确。

技术栈选择心得

最终选择了 Next.js + Supabase + shadcn/ui + Tailwind CSS 的组合,原因很简单:

  • Next.js 的 App Router 让页面和 API 在同一项目中,减少心智负担
  • Supabase 提供了 PostgreSQL 数据库 + 用户认证 + 对象存储的一站式方案
  • shadcn/ui 提供了开箱即用的美观组件,不需要自己写样式

AI 对这个技术栈的熟练程度很高,生成的代码质量也最好。

结语

如果你也有一个想做但觉得”技术不够”的项目,现在是时候重新评估了。AI 不会替代你的领域知识——它替代的是”把想法变成代码”这个环节。而真正决定产品好坏的,始终是你对问题的理解和对用户的洞察。

利用大模型进行代码重构的实践经验

为什么要重构

学情追踪系统最初是在某个低代码平台上搭建的。功能能跑,但问题很多:

  • 平台 SDK 深度耦合,离开平台就瘫痪
  • API 路由缺乏认证,安全性堪忧
  • 巨型单文件——一个页面组件 470 行,一个 API 路由 460 行
  • 数据库缺少外键级联、索引混乱

能跑 ≠ 能维护,能维护 ≠ 能扩展。 当系统需要独立部署时,重构就不可避免了。

AI 重构三板斧

第一板斧:安全扫描

把代码交给 AI,给它明确的指令:”检查所有 API 路由,列出缺少认证检查的接口,给出修改方案。”

AI 很快定位到:31 个 API 路由中,有 28 个完全没有认证校验。它帮我创建了统一的认证代理层(proxy.ts),把所有认证逻辑集中管理,而不是每个路由各写一套。

第二板斧:依赖解耦

原始代码中 coze-coding-dev-sdk 在至少 5 个文件中被直接引用。我让 AI 分析所有引用点,然后逐个替换为独立的模块:

  • 对象存储:S3Storage → 基于 AWS SDK 的腾讯云 COS 模块
  • LLM 调用:Coze LLMClient → 自建的 OpenAI 兼容客户端
  • 环境变量:Python execSync → 标准 dotenv 方案

每个模块替换后立即测试,确保功能不受影响。

第三板斧:结构优化

470 行的仪表盘组件 → 拆分为 4 个独立子组件。460 行的考试分析 API → 提取出通用的 LLM 调用辅助函数。

AI 做这种机械性的拆分非常高效——它会自动处理 props 传递、导入路径更新这些容易出错的细节。

最重要的教训

给 AI 明确的约束条件。 不要说”优化这段代码”,而要说”把这个 470 行的组件按功能拆分成 4 个独立组件,每个不超过 150 行,保持所有现有功能不变。”

越具体,AI 的输出越靠谱。

重构后的效果

  • 代码行数减少约 30%
  • 构建时间从 45 秒降到 16 秒
  • 新增功能模块的开发效率提升约 3 倍
  • 系统从依赖特定平台到可独立部署在任何 Linux 服务器上

多模型协同——为不同场景选择最佳AI模型

一个系统为什么要用多个模型

学情追踪系统中有四个需要 AI 能力的场景:

场景 需求特点 模型要求
错题拍照识别 需要识别图片中的文字和标记 视觉模型
考试试卷分析 多张高清图片 + 复杂推理 强视觉 + 强推理
每日练习出题 根据薄弱知识点生成题目 逻辑推理
每日反馈报告 汇总数据生成评语 文本生成

如果全部用一个模型,要么太贵(视觉模型按 token 计费贵),要么效果不好(文本模型看不懂图片)。

模型选择策略

视觉场景:硅基流动

拍照识别和试卷分析需要视觉能力。我选择了硅基流动(SiliconFlow)作为视觉模型提供商,主要模型配置:

  • 主力:Nex-N2-Pronex(免费额度,日常识别足够)
  • 备选:DeepSeek-OCR(文字识别更精准,需要时切换)
  • 兜底:Qwen2.5-VL-32B(复杂推理场景的最后选择)

切换方式很简单——在后台把备选模型设为默认,旧模型的默认状态自动取消。

文本场景:DeepSeek

出题和写报告是纯文本任务,用 DeepSeek 性价比最高。它的推理能力对出题质量有帮助,价格也比 GPT-4o 便宜很多。

按功能独立配置的设计

传统的做法是全局设置一个”默认模型”,所有功能都用它。我做了改进——在数据库的模型配置表中增加 purpose 字段,每个功能模块查询时只取对应 purpose 的模型:

1
2
3
4
purpose = 'wrong_questions'  → 错题识别专用模型
purpose = 'daily_practice' → 出题专用模型
purpose = 'daily_report' → 报告专用模型
purpose = 'exam_analysis' → 试卷分析专用模型

这样每个功能可以独立选型、独立切换,互不影响。

成本对比

方案 月成本估算
全部用 GPT-4o ¥500+
全部用 DeepSeek ¥15
视觉用硅基免费版 + 文本用 DeepSeek ¥15

一个月从 500 降到 15 块,效果反而更好。 因为每个场景用的都是最适合的模型,而不是最贵的模型。

总结

多模型协同的核心不是”选最厉害的”,而是”为每个任务选最合适的”。就像你不会用飞机去隔壁便利店买菜——工具要与场景匹配。

AI驱动的教育科技——个性化学习的技术实现

个性化学习为什么需要 AI

传统的个性化教学依赖老师的经验——一个老师面对 40 个学生,能真正”因材施教”的时间和精力非常有限。

AI 可以在三个维度上规模化地实现个性化:

  1. 诊断:精准定位每个知识点的掌握程度
  2. 推荐:只练习薄弱环节,不浪费时间
  3. 记忆:在遗忘临界点自动推送复习

技术实现细节

知识点掌握度量化

学生的知识掌握状态不是简单的”会”或”不会”,而是四个等级:

1
未掌握 → 基础 → 中档 → 拔高

系统通过错题数据自动计算每个知识点的得分(0-100),形成雷达图。家长和老师一看就知道哪些知识点需要补。

艾宾浩斯遗忘曲线的工程实现

每道错题录入后,系统自动生成 6 轮复习计划:

轮次 间隔 原理
第 1 轮 1 天后 首次强化
第 2 轮 2 天后 二次巩固
第 3 轮 4 天后 间隔拉长
第 4 轮 7 天后 一周回顾
第 5 轮 15 天后 半月巩固
第 6 轮 30 天后 长期记忆

关键是不需要学生自己记。系统到时间自动推送提醒,学生只需要按提醒去复习就行。

AI 出题的智能化

出题逻辑不是随机抽题,而是三步走:

  1. 统计最近 30 天的错题,按知识点聚类
  2. 优先从高频错题点出题(确保练的是不会的)
  3. 参考知识库中的教材内容,生成与课堂同步的题目

试卷分析的完整流程

拍照上传 → AI 识别所有题目 → 逐题分析对错 → 归类错因 → 按提分潜力排序 → 生成分阶段提分计划。

一张 120 分的卷子,AI 能告诉你:哪 15 分是粗心丢的(最容易追)、哪 20 分是知识点漏洞(需要专项练习)、哪 10 分是能力天花板(现阶段不强求)。

效果数据

在试用阶段,学生平均:

  • 刷题量下降 40%
  • 相同知识点的考试正确率提升 25%
  • 复习计划完成率从 30% 提升到 85%

不是更努力,而是更精准。

从平台绑定到独立部署——一个项目的成长之路

起点:绑定在低代码平台上

学情追踪系统的第一个版本是在某个低代码 AI 编程平台上搭建的。好处是快——几天就出了原型。代价是深度绑定:

  • 数据库凭据由平台管理,看不到
  • 环境变量通过 Python 脚本从平台注入
  • LLM 调用依赖平台的 SDK
  • 文件存储走平台的 S3 兼容接口
  • 部署域名是平台提供的子域名

离开平台,系统就是一堆跑不起来的代码。

转折:决定独立部署

当我们需要自定义域名、控制数据主权、降低运营成本时,独立部署就不可避免了。

解耦四步走

第一步:环境变量标准化

原来的环境变量通过 execSync('python3 ...') 调用平台 API 获取——这段代码在任何非平台环境都会静默失败。改造方案是用标准的 dotenv 方案,所有配置写入 .env.production 文件。

第二步:对象存储迁移

从平台的 S3Storage → 腾讯云 COS。好在 COS 兼容 S3 协议,代码改动很小——换个 endpoint 和密钥就行。

第三步:LLM 客户端独立化

从平台的 LLMClient → 自建的 OpenAI 兼容客户端。支持 OpenAI、豆包、DeepSeek、硅基流动等多个厂商,通过数据库配置灵活切换。

第四步:部署到自己的服务器

  • 操作系统:Ubuntu 24.04 LTS
  • 反向代理:Nginx(双站点:博客 + 应用)
  • 进程管理:PM2(双实例集群模式)
  • HTTPS:Let’s Encrypt 免费证书自动续期
  • 数据库:Supabase 托管 PostgreSQL(保留,没有迁移)

域名和备案

购买了 cszd.asia 域名,完成了 ICP 备案(湘ICP备2026025401号)。主站放个人博客(Hexo 静态生成),应用放在 /zhidao 子目录下。

架构一览

1
2
3
cszd.asia (Nginx + SSL)
├── / → Hexo 博客(静态文件)
└── /zhidao → 知导伴学 AI(Next.js + PM2)

感悟

独立部署带来的不仅是技术自主权,更是对系统全貌的完整理解。从平台绑定到自主可控,这个过程让我从”用工具的人”变成了”造工具的人”。

如果你也有一个绑定在平台上的项目,不妨试试迈出这一步。AI 可以帮你完成 90% 的迁移代码,剩下的 10% 才是真正需要你理解的部分。