★ FEATURED ARTICLE 1. 为什么我要做这样一个面试刷题系统做了这么多年开发每年金三银四都会有不少朋友来找我问面试题聊完之后我发现一个很普遍的问题大家刷题的方式还停留在十年前——买一本厚厚的面试题大全从头翻到尾或者在网上东拼西凑保存几百道题到收藏夹里吃灰。这种方式的效率实在太低了而且针对性很差。后来我琢磨着与其每次都临时整理资料发给朋友不如直接做一个智能面试刷题系统。一方面自己复习用另一方面也能给身边的朋友提供一个真正有用的工具。这个系统从需求梳理到最终落地前前后后花了大概一个月时间用的是前后端分离架构整体做下来效果还不错今天就把整个设计和实现过程拿出来分享一下。这套系统解决的核心问题有三个第一把零散的面试题系统化地管理起来第二通过智能算法让刷题顺序更科学而不是盲目地从头刷到尾第三模拟真实面试场景。很多人在笔试环节表现不错但一到现场面试就紧张系统里专门做了AI模拟面试功能让它来扮演面试官帮你适应面试节奏。如果你是后端开发、前端开发或者对全栈项目感兴趣想了解一个完整的前后端分离项目是如何从零到一落地实现的那这篇文章应该能给你不少参考。我会把架构设计、核心模块拆分、数据库设计、关键接口实现、以及我在开发过程中踩过的一些坑都讲一遍。2. 整体架构设计与技术选型2.1 前后端分离架构的核心思路所谓前后端分离简单理解就是前端负责页面展示和用户交互后端只负责数据处理和业务逻辑两者通过HTTP接口通信。分离之后前端完全不需要关心后端是用什么语言写的、数据库长什么样只需要拿到约定好的JSON数据就能正常工作。这么做最大的好处是职责清晰。后端接口写好了前端可以并行开发不用互相等。我当时是一个人开发但分开之后调试起来确实省了不少事——前端写页面的时候只需要mock数据后端的接口用Postman单独测最后联调的时候再对一遍字段就可以了。系统的技术栈我选了Vue 3 Spring Boot这套组合。Vue的生态成熟组件化开发效率高对个人项目来说学习曲线也比较平缓。后端用Spring Boot是因为它整合了各种常用组件开发速度极快而且Java的生态在面试系统这类业务场景下非常稳。数据库用的MySQL缓存用的Redis这些都是目前行业里的主流选择。2.2 整体架构图拆解整个系统从大方向上可以分为三层前端展示层、后端服务层、数据存储层。前端展示层负责几个主要的功能页面登录注册页、题库浏览页、刷题模式页、模拟面试页、个人中心页。后端服务层按照业务拆分为几个模块用户模块、题库模块、刷题记录模块、模拟面试模块、统计模块。数据存储层就是MySQL存业务数据Redis存会话和热点数据。这里我特别想强调一点并不是所有场景都适合用前后端分离架构。如果你的项目是内部管理系统用户量很小服务端渲染反而更简单。但是面试刷题系统这种天然需要多端适配未来可以做小程序、App、需要频繁迭代功能的场景前后端分离是更合适的选择。2.3 技术选型的几个关键考量技术选型不能光看哪个火就选哪个得结合自己的实际场景。我当时做选型的时候主要考虑了这几点第一个是团队协作效率。虽然我是一个人开发但考虑到以后可能会拉朋友一起维护前后端分离和明确的技术栈能让协作成本降到最低。第二个是生态成熟度。Vue 3配合Element Plus做后台界面非常顺手Spring Boot配合MyBatis-Plus操作数据库也很高效。这些组合都是被大量项目验证过的踩坑成本低。第三个是部署难度。前后端分离之后前端打包成静态文件扔到Nginx里后端打成jar包跑在服务器上部署链路非常清晰。这一点在后期上线的时候帮我省了不少事。第四个是AI能力的接入。面试刷题系统如果没有智能化的推荐和模拟对话功能跟普通的题库网站就没区别了。所以我在架构层面预留了AI服务接口让系统可以接入大模型API来实现智能模拟面试和题目推荐。3. 系统核心模块设计与功能拆解3.1 用户模块从注册登录到权限控制用户模块是整个系统的基础承担着用户注册、登录、个人信息管理等基本功能。别小看这个模块它的设计好坏直接影响后续所有业务功能的安全性。用户表的核心字段我设计为id、用户名、密码存的是加盐后的哈希值、昵称、头像URL、邮箱、角色、注册时间、最后登录时间。密码存储这块必须用BCrypt加密绝对不能明文存储这是最基本的底线。我在开发的时候为了方便调试曾经偷懒想用MD5但后来还是纠正了这个问题因为MD5现在已经可以被彩虹表轻松破解安全性完全不够。权限控制我用了Spring Security JWT的组合。用户登录成功后后端签发一个JWT令牌返回给前端前端每次请求都在Header里带上这个令牌。后端通过拦截器解析令牌获取当前用户ID和角色信息。这种无状态的认证方式非常契合前后端分离架构因为后端不存Session一台服务器挂了流量切到另一台也不会影响用户登录状态。角色方面我设计了两种普通用户和管理员。普通用户可以刷题、做题、查看个人统计管理员可以管理题目、查看系统数据。授权控制用注解实现比如在Controller的方法上标注只有管理员角色才能访问代码看起来非常简洁。3.2 题库模块结构化存储与高效检索题库模块是整个系统的核心资产。我一开始犯过一个大错误——把面试题简单设计成题目答案两个字段就完事了。后面做到搜索和筛选功能的时候才发现问题大了用户想按Java多线程来筛选题目如果题目表里没有结构化的标签字段查询会变得非常痛苦。后来我把题目的数据结构重新设计了下核心字段如下题目ID、题目标题、题目内容、参考答案、所属方向后端、前端、算法、数据库等、题目难度简单、中等、困难、关联标签多个标签用逗号分隔存储、来源公司信息匿名处理、题目类型选择题、简答题、编程题、创建时间、更新时间。高效的检索这里做了两层优化。第一层是MySQL的索引设计在方向、难度、标题这些高频查询字段上建立了合适的索引。第二层是Redis缓存把热门题目列表、题目总数量这些热点数据缓存起来减轻数据库压力。这里分享一个小的经验做类似系统时题目列表不要一次性全查出来一定要做分页。我当时用MyBatis-Plus自带的分页插件简单的两行配置就能给所有查询加上分页支持非常方便。3.3 刷题模块三种刷题模式的设计刷题模块我设计了三种模式每种模式对应不同的使用场景。第一种是顺序刷题模式。用户选定某个方向比如Java系统按默认顺序把题目一道一道展示出来用户可以在题目之间来回切换也可以标记已掌握或待复习。这个模式适合刚开始学习、需要系统性过一遍基础知识的时候。第二种是随机刷题模式。系统从用户指定的条件范围内随机抽取题目模拟考试的感觉。这个模式适合临考前的自我检测。随机算法这里注意一点不要用系统自带的Random然后去数据库ORDER BY RAND()数据量大的时候这样查非常慢。我当时采用了先查所有符合条件的题目ID列表然后在内存里随机取ID再按ID查具体题目的方案性能好了很多。第三种是错题重刷模式。系统自动记录用户做错的题目在错题库里按错误次数排序展示。用户可以把错题重新做一遍做对了就自动从错题库中移除做错了错误次数加一。这个模式虽然简单但实际用起来效果非常好因为大部分人的薄弱点往往集中在少数几个知识点上。3.4 智能模拟面试模块AI面试官的实现思路智能模拟面试是整个系统最吸引人的功能也是技术实现上最有挑战性的部分。这个模块的设计目标是模拟一个真实的面试场景AI作为面试官大约问15-20道题题目涉及深度递进从基础到项目经验从技术到行为问题。用户通过语音或文字作答AI根据回答质量给出评价。这个模块的底层逻辑其实是三个核心能力的组合题目动态生成、对话状态管理、回答质量评估。题目动态生成用了两种方案按场景区分。第一种是模板化方案系统预设了一批面试题模板AI根据用户所选方向从题库中抽取并组织面试流程。第二种是AI生成方案接入大模型API让AI基于用户简历和岗位方向现场生成面试题。模板化方案的优点是稳定可靠、成本低AI生成方案的优点是个性化强、更真实。实际开发中我采用了两种方案的混合先从题库结构化抽一部分高频面试题再让AI结合用户标签补充一些动态题目兼顾稳定性和智能感。对话状态管理是整个模块的核心。面试是一个多轮交互的过程AI问完一道题用户回答AI再追问或点评然后进入下一题。这里需要维护一个面试会话状态机核心状态包括面试开始、当前题目展示、等待用户回答、回答完成判断、生成追问、进入下题、面试结束、生成面试报告。这个状态机用Redis加一个自定义的状态对象来实现每个会话有一个唯一ID状态信息存Redis。状态机的流转逻辑我简单说明一下用户点击开始面试后系统给会话赋予一个初始化状态把AI的第一道题返回给前端。用户提交回答后状态从等待回答变为回答完成此时后端调AI接口让AI基于用户的回答内容生成评价和追问。AI返回内容后进入生成追问状态把追问发到前端。这个过程循环往复直到达到预设的题目数量上限或者用户点击结束。整个流程实际开发起来比想象中复杂因为每一步都要考虑异常情况——比如AI接口超时、用户断线等等。回答质量评估我用了两个维度的评分内容相关性评估和表达流畅度评估。内容相关性评估的关键技术手段叫关键词匹配加语义相似度把用户的回答文本和参考答案的关键词列表做匹配再用文本向量化技术算用户回答和标准答案的语义相似度最后按一定比例算出一个综合得分。语义相似度这里我用了一个轻量级的文本匹配方案一是速度快二是部署简单。3.5 统计模块用数据反馈刷题效果统计模块的价值在于让用户直观地看到自己的进步。我实现了三个层次的统计刷题数量趋势每日刷题量柱状图、知识点掌握度分析雷达图、模拟面试成绩历史曲线折线图。从实现层面来说统计模块的后端接口主要是聚合查询。比如按天统计刷题量本质上就是一条SQL按创建日期分组去count。但是这里有个性能问题如果用户刷题记录表数据量大了每次打开统计页面都实时做聚合查询数据库压力很大。我的解决方案是定时任务加汇总表——每天凌晨把前一天的刷题数据汇总到统计分析表里用户查询的时候直接查汇总表速度极快。另外用户刚做完一道模拟面试题目时如果回答质量得分偏低系统会自动给该题关联的知识点打上薄弱标记。这样用户在查看自己的知识点掌握度分析的时候可以看到哪些知识点还需要背记和加强这就是每周学习报告推荐逻辑的数据基础。4. 关键技术实现与核心代码解析4.1 数据库表设计从需求到落地的完整拆解数据库设计这个环节我踩过不少坑这里用核心表举个例。整个系统的数据表大概有十张我把每张表负责什么、表与表之间是怎么关联的讲清楚。用户表设计得不算复杂但是凡是要关联用户身份的数据表全部存了用户的唯一ID作为外键字段。权限这一块角色字段直接存在用户表里没有单独建权限表因为系统角色就两种单独建表反而增加复杂性。题目表是我最用心的一张表。除了常规字段外我加了一个比较特别的设计题目的内容字段用了富文本格式支持因为面试题的答案经常会包含代码片段、表格等内容纯文本根本存不了。富文本内容前端展示的时候用渲染组件进行显示。刷题记录表承载着用户所有的刷题交互数据字段包括记录ID、用户ID、题目ID、刷题模式类型、用户答案内容、判定结果正确/错误、耗时秒数、创建时间。这张表的数据量增长非常快所以我在用户ID创建时间上建了联合索引所有按用户维度查询历史的接口都走这个索引。模拟面试记录表存储每次AI面试的完整过程字段包括会话ID、用户ID、面试方向、开始时间、结束时间、总得分、面试题目快照以及每次问答的完整内容存JSON格式、AI生成的整体评价。知识点维度表与题目关联表通过题目标签字段解析后维护映射关系支撑统计模块的维度分析。下面是核心表的字段设计概览表名关键字段核心作用userid, username, password_hash, nickname, avatar, role用户基础信息与角色权限questionid, title, content, answer, category, difficulty, tags题目内容的结构化存储question_tagid, tag_name, question_count标签维护与聚合统计answer_recordid, user_id, question_id, mode, is_correct, spend_time用户每次刷题行为的流水记录interview_sessionid, user_id, direction, status, score, reportAI模拟面试的会话与会话数据interview_messageid, session_id, role, content, ai_scoreAI面试环节的每轮问答记录knowledge_pointid, name, category知识点定义user_knowledgeid, user_id, knowledge_id, mastery_level用户知识点掌握度daily_statid, user_id, stat_date, question_count, correct_count每日刷题聚合统计learning_recommendationid, user_id, content, create_time每周学习建议内容后续维护的时候注意表结构一旦上线改造成本很高。所以设计阶段宁可多花两天细想也尽量不要留隐患。4.2 核心接口设计一个完整的面试会话如何交互前后端分离架构中接口设计就是前后端的契约。我把自己在实际项目里怎么定接口规范的经验写出来很有参考价值。系统所有接口统一以/api开头然后按业务模块划分/api/auth/登录注册相关、/api/questions/题库相关、/api/answer-record/刷题记录相关、/api/interview/session/模拟面试相关、/api/statistics/统计相关、/api/user/个人信息相关。接口返回格式我也做了统一封装。不管成功还是失败后端一律返回这样的结构{ code: 200, message: success, data: { ... } }。code为200表示成功非200表示业务失败。前端在请求拦截器里统一判断code如果是200就取data渲染页面如果不是就弹错误提示。这样的统一规范看起来简单但在实际联调中能省掉大量的沟通成本。以模拟面试的核心接口为例我列出整个会话的交互流程第一步前端调用POST /api/interview/session/start参数是面试方向和目标岗位后端创建一个新的面试会话返回sessionId和AI的第一道题。第二步前端调用POST /api/interview/session/answer参数是sessionId和用户回答内容后端记录对话AI生成追评和下一题返回给前端。第三步前端调用POST /api/interview/session/finish参数是sessionId后端汇总整个会话的所有问答调用AI生成综合评分和面试报告返回给前端展示。第四步前端调用GET /api/interview/session/history 获取用户的历史面试记录列表。这个流程看起来很简单但实际实现中一个很容易踩坑的点是AI接口的响应时间是秒级的用户的请求会卡很久。这个问题我用异步化方案解决了用户提交回答后后端立即把回答内容记录到数据库然后通过异步线程去调AI接口把AI返回的结果通过WebSocket推送给前端。这样用户提交回答后马上就能看到AI正在思考的提示而不是浏览器转圈等半天。4.3 智能推荐算法如何让刷题顺序更科学推荐算法的核心逻辑其实不复杂关键因子包括用户薄弱知识点、相似用户的刷题行为、题目的难度层级以及用户的近期刷题时间分布。我用一种简单而有效的权重计算方案来给用户推荐下一道题对候选题目列表按照四个维度打分然后按总权重排序。第一维度是薄弱知识点匹配度。系统查询用户知识点掌握度表里mastery_level低于某个阈值的知识点凡是关联这些知识点的题目加权分高。第二维度是难易梯度匹配度。如果用户最近在中等难度题目上的正确率比较高题目推荐会适度加难如果正确率低则推荐容易一些的题目。第三维度是类型多样性。为了避免连续推同一个方向、同一种题型的题目我会引入一个多样性惩罚因子类似于推荐系统里的MMR最大边际相关性。第四维度是时效衰减。用户好久没做的题目关联的知识点倾向于优先推荐防止遗忘曲线效应。推荐接口的实现上我先从题目表中把符合条件方向匹配、难度匹配、类型匹配的题目ID列表捞出来然后在内存里对每一道题计算权重分数最后取前10道返回。这个方案虽然看着朴素但实测推荐效果已经比随机刷题舒服很多。如果想引入更复杂的协同过滤或矩阵分解可以等推荐数据量积累足够后再迭代。4.4 核心代码实现模拟面试状态机状态机这块我直接给出核心实现思路和关键代码。定义枚举类型表示面试的状态然后用一个类封装整个会话的状态变化。状态枚举public enum InterviewState { INITIATED, // 面试已创建等待第一道题 QUESTION_SHOWN, // 当前题目已展示等待用户作答 ANSWER_SUBMITTED,// 用户已回答AI评估中 FOLLOW_UP_GENERATED, // AI已生成追问 COMPLETED // 面试结束 }会话状态类public class InterviewSession { private String sessionId; private Long userId; private String direction; private InterviewState currentState; private int questionIndex; // 当前题目序号 private ListQaPair qaList; // 历史问答记录 private String lastAiQuestion; // AI当前给出的题 private String lastAiEvaluation; // AI上一轮评估 }推进状态的核心逻辑我放在了服务层每次前端提交回答时流程是这样的先校验当前会话状态是否为QUESTION_SHOWN如果不是就提示前端状态异常。然后把用户回答存入qaList将状态设为ANSWER_SUBMITTED。接着异步调用AI服务把用户回答和会话历史发给AI大模型拿到AI给出的评价与追问题。将AI评价存入qaList状态置为FOLLOW_UP_GENERATED然后把新的问题通过WebSocket推送给前端。这里我最想分享的一个心得是状态机的推进一定要基于数据库中的真实状态而不是前端传过来的状态。也就是说每次操作都由后端根据sessionId查出数据库中的当前状态校验通过后再推进。如果依赖前端传入的state字段很容易出现请求顺序错乱导致的状态错位。我之前就吃过亏用户快速点击下一题按钮前端连续两次请求第一次和第二次请求之间后端如果没做状态校验就会出现题目重复推进或漏掉追问的情况。所以最终方案是每条核心记录的操作都加了乐观锁用版本号字段控制并发。加了乐观锁之后这种并发问题彻底消失了。4.5 缓存策略Redis在系统里扮演的角色Redis在系统中的主要职责有两个缓存热点数据和维护实时会话状态。缓存这块我把三类数据放进了Redis题目列表的分页结果key为question:page:{pageNum}:{size}、高频访问的题目详情key为question:detail:{id}、以及系统的配置项。设置缓存的时候要注意设置过期时间我给题目列表设置了30分钟给题目详情设置了2小时。同时当管理员修改了题目内容后需要手动删除对应的缓存否则会一直命中旧数据。实时会话状态这块模拟面试的每一轮对话都是实时交互需要快速读写。我把每个进行中的AI面试会话的全部状态存放在Redis中key为interview:session:{sessionId}value为JSON格式的会话对象。只有面试结束时才把最终结果落库到MySQL。这样设计的理由是面试过程中的高频读写操作走内存性能和稳定性都更好MySQL只承担最终结果的持久化压力小得多而且还能避免中途多次写入半成品数据带来的脏读隐患。Redis的键过期时间我设置为30分钟如果用户在面试中途离开超过30分钟会话自动过期前端再提交回答时后端会给出会话已过期的提示需要重新发起面试。4.6 前端实现的关键细节前端这块我也是自己一个人写的对新手比较有借鉴意义。整个前端工程用Vue 3 Vite Element Plus Pinia Vue Router这套组合。状态管理用Pinia。全局状态里我维护了用户登录信息、当前刷题模式、模拟面试的会话状态、以及全局的题目方向筛选条件。Pinia的状态持久化用的是插件自动同步到localStorage刷新页面不会丢登录态。路由权限控制是一个很容易被忽略的点。我在Vue Router的全局前置守卫里做了登录检查如果用户未登录且访问的是需要登录的页面就跳转到登录页。如果用户是管理员就额外开放管理后台的路由普通用户访问管理路由时会看到403页面。模拟面试的交互界面是前端开发中最复杂的部分。我把它设计成聊天窗口的形式AI面试官的头像在左边消息内容是题目用户在右边回答。用户回答的输入框做成了键盘可输入和语音输入两种模式语音输入调用浏览器内置的Web Speech API做语音转文字在Chrome浏览器上识别率还挺高。每次用户发送回答后界面立刻显示一个AI正在思考的过渡动态等WebSocket推送来AI的追评和下一题后以打字机的动画效果逐字渲染到界面上。这里有一个要特别提醒的点WebSocket连接在Nginx反向代理环境下需要单独配置升级头否则连接会报错。我当时用Nginx部署前端时踩了这个坑配置里加了proxy_set_header Upgrade和Connection这两个请求头才解决。5. 系统部署上线与性能优化实战5.1 从开发到上线部署环境的完整配置流程系统的部署我采用的是单机部署加Docker容器化的方式。服务器的环境大致如下一台4核8G的云服务器装了Docker和Docker Compose。整个系统涉及的容器有MySQL、Redis、后端服务jar包、前端Nginx、AI服务网关。部署流程我梳理成这么几步第一步把MySQL和Redis这两个基础组件用Docker Compose先跑起来同时把数据库初始化的SQL脚本放进去自动执行。第二步把后端代码用Maven打成可执行jar包用Dockerfile构建成镜像通过环境变量注入数据库连接配置和AI密钥。第三步把前端代码执行npm run build打包成静态文件把dist目录挂载到Nginx容器里。第四步用Docker Compose统一编排所有容器让它们在同一内网网络里互相通信。这里有一个我强烈建议的操作后端服务的配置文件一定不要打包进镜像而是用环境变量或挂载volume的方式在运行时注入。因为镜像要在多个环境开发、测试、生产之间流转配置文件写死在里头每次换环境都得重新构建镜像极其痛苦。5.2 接口性能优化从平均800ms优化到150ms的实操记录系统开发完成初期我做了一轮性能压测发现题库列表接口的响应时间平均在800ms左右这是无法接受的——用户翻一页题库要等接近一秒交互体感非常差。我做了一系列优化最终把平均响应时间降到了150ms以下。第一步优化是SQL查询分析。我用慢查询日志一看发现题目列表在联表查询题目标签的时候做了全表扫描。优化方法很直接把标签的联表查询改成了在题目查询完成后再用IN语句按标签ID批量查关联表消除笛卡尔积问题。只改了这一点响应时间直接降到了400ms。第二步优化是分页查询的性能。当用户翻到很靠后的页码时LIMIT 20000, 10这种写法性能很差MySQL需要扫描前20000行然后丢弃。我改成了游标分页方案前端传入上一次数据的最后一条ID后端用WHERE id ? 记录的最后一条ID配合索引直接跳过去。这个改动对大数据量分页的性能提升非常明显。第三步优化是加Redis缓存。把热门题目列表页面直接缓存起来命中率非常高。第四步优化是前端层面对整个题目列表做了滚动懒加载和图片懒加载没进入视口区域的富文本内容不做渲染。前端渲染压力降低后首屏加载速度也提升了不少。6. 我踩过的那些坑和给你的避坑建议6.1 最常见的5个问题与排查思路开发过程中遇到的问题有不少我把最典型、最有代表性的5个整理了出来并附上排查过程和解决方案的对比问题现象问题原因排查与解决思路登录后刷新页面又跳回登录页Pinia状态没做持久化装Pinia的持久化插件登录态同步localStorage用户快速点击下一题AI面试追问出现重复并发请求导致状态机错乱后端引入乐观锁版本号状态推进前校验当前版本题目列表翻到第50页时接口出奇慢LIMIT深分页导致全表扫描改用基于ID的游标分页不走OFFSETAI面试的返回内容偶尔出现乱码大模型返回的JSON被截断格式化时异常对AI输出先做字符校验截断时重试请求部署后WebSocket一直连不上Nginx默认不支持WebSocket协议升级配置Upgrade和Connection请求头转发6.2 三个值得单独拿出来讲的经验第一个经验是关于AI接口调用的降级策略。AI接口偶发超时是很正常的事为了让系统在这种情况下不至于完全不可用我实现了两套降级方案第一套方案调用AI失败的时候系统自动从题库里抽取一道与当前问题同标签的题作为替代题目第二套方案如果连续三次调用AI都失败了就自动结束本轮模拟面试把已有对话记录保存为一个不完整面试提示用户可以稍后整理查看。做过这个降级策略后系统在AI服务不稳定期间的可用率从不到80%提升到了98%以上效果非常显著。第二个经验是异步任务的可观测性。引入异步线程调AI之后如果AI调用失败用户端是感受不到的可能会产生AI一直不回复的假象。所以我在异步任务里加了详细的日志埋点并配了一个告警机制如果单日异步任务失败率超过5%就推送告警消息到管理后台。没有这个机制的话出了问题都不知道去哪排查。第三个经验是富文本存储的安全问题。题库的题目内容支持富文本前端提交的HTML片段如果不做过滤很容易产生XSS攻击。我的方案是在后端用一个HTML安全过滤器对提交内容做白名单校验只允许指定的标签和属性其他一律剥掉。这个一定要做不能省。6.3 给想自己动手做类似系统的朋友的建议如果你准备自己做一套类似的刷题系统我的建议是这样的先把范围控制住不要一上来就想把所有功能都做完。我列一个功能优先级供你参考第一优先级是基础题库管理加刷题记录第二优先级是错题本和统计看板第三优先级才是AI模拟面试。如果你从第一天就引入AI功能会被AI接口的不可控性消耗掉大量精力前面基础部分反而做不扎实。再一个就是数据库设计一定是要先花时间想清楚的至少要把题目、用户、刷题记录、模拟面试会话这四张核心表的关系想明白。表结构一旦上线改动成本成倍增加特别是已经开始产生真实数据之后。最后部署上线要提前规划不要在开发全部完成之后才开始考虑部署问题。比如我在开发早期就把Nginx反向代理的配置、Dockerfile这些写好了后面每开发完一个阶段就能部署一次持续收到真实用户反馈这样项目的迭代方向会更加明确。7. 回顾一下这个项目我觉得最有价值的三个点整个系统从设计到上线大概用了一个月代码量不算多但在架构设计上的思考确实花了不少时间。回头来看这个项目对我来说最有价值的有三个点。第一个是前后端分离架构下接口契约设计的实战经验。以前做项目重心都在后端很少思考前端拿到接口数据后要做什么处理。这次自己从拿到需求到定接口、写前端、联调、部署整个过程走下来对API到底该怎么设计才能让双方都舒服这件事有了非常深的体感。好的接口设计能让前端写代码像拼积木一样顺畅。第二个是状态机思想在真实业务场景中的落地。模拟面试的多轮对话、用户的连续操作、AI的异步响应这些交织在一起用状态机来描述系统的行为边界代码不仅可读性更好而且几乎不可能出现状态错乱。这种思维模式对以后做任何复杂交互系统都非常有帮助。第三个是AI能力与业务系统的整合方式。坦白讲接入大模型API本身并不难难的是如何把AI输出的不稳定内容和自己系统的数据结构、业务流程严密地缝合起来。AI返回的结果要经过安全过滤、格式校验、语义规整之后才能落库展示这套处理链路的核心思想就是让AI当助手但最终决定权永远在自己手里。我自己的使用体会是系统的顺序刷题加错题本组合对知识复习帮助很大AI模拟面试虽然不能完全替代真人面试但用来练手感和熟悉高频问题效果已经很出色了。后面如果继续迭代这个项目我想给AI模拟面试增加更强烈的场景感——比如AI面试官可以根据用户的回答动态调整提问深度还会模拟现场追问和施压氛围让它更像一场真正的实战面试。
阅读完成 · 觉得有帮助？
