这个项目从立项到第一个能用的版本上线我前后花了六周时间。一个人包揽产品定义、前端、后端、AI链路和部署运维听起来挺酷实际上大部分时间都花在解决“看似很简单但实际很折磨人”的问题上。现在回头看AI面试平台表面上是一个“大模型对话评分”的工具真正落地时涉及的东西远比想象中多音视频采集、语音转写、流式输出、状态机设计、并发控制、成本控制哪一环掉链子都会直接影响用户体感。这篇文章把我从0到1搭建AI面试平台过程中踩过的坑、做过的取舍、最终沉淀下来的方案完整写出来。如果你是准备独立做AI应用的全栈开发者或者公司想搭一套面试/培训评估系统这里面的经验可以直接帮你绕开我当初试错的那几周。1. 为什么一个人敢碰AI面试平台架构选型先别急着写代码很多人听到“AI面试平台”第一反应是这不就是包一层大模型API用户提问AI回答最后让AI打个分嘛。这个理解不能说错但离真正能用还差很远。AI面试的核心是“模拟真实面试流程”真实面试里有出题、追问、时间控制、突发情况处理、最终评估这些都需要一套业务状态机来管理而不是单纯一问一答。我最初的想法也很简单做一个网页候选人进入后系统出题候选人对着摄像头回答回答结束下一题全部结束后生成一份评估报告。但仔细拆解后我意识到这里有两条核心链路候选人端链路进入面试房间 - 获取题目 - 视频/语音回答 - 上传音视频 - 等待下一题 - 面试完成 - 生成报告评估端链路音视频转写 - 答案文本 - 调用大模型评估 - 结构化报告 - 持久化 - 推送给候选人1.1 面试平台的真正核心不只是聊天机器人如果只是做“AI问答”那确实没有多少技术含量。但面试平台不一样它要求整个流程可控、可中断、可恢复。我举个例子候选人面试到一半断网了或者中途误关了浏览器这时候怎么办如果是普通聊天工具重新打开继续聊就行但面试是有时间限制、题目顺序、作答记录的必须把“面试状态”持久化让用户重新进入后能恢复到“当前正在回答第几题、剩余时间多少”。这背后是一套完整的会话状态机。我最终把面试流程拆成了这几个状态IDLE未开始QUESTION_PENDING等待展示下一题ANSWERING候选人正在回答UPLOADING回答结束音视频上传中TRANSCRIBING后台转写中AI_EVALUATING评估中COMPLETED面试完成EXPIRED超时或异常终止每个状态之间的流转都通过一个中心化的状态服务来管理而不是散落在前端代码里。这个设计在开发阶段看似“过度设计”但上线后救了我很多次。1.2 一人团队的架构减法单体优先能不开新服务就不开一个人做全栈最大的敌人不是技术难度而是“维护成本”。我见过太多独立开发者一上来就搞微服务、搞Kubernetes集群最后光是维护基础设施就耗光了精力。我的原则很简单尽量用单体应用能合并的模块全部合并只把真正需要独立扩展的部分拆出去。以我的项目为例最终架构是这样的前端 业务后端Next.js单体应用既负责页面渲染也负责业务API转写服务单独跑一个Python服务部署本地语音识别模型数据库PostgreSQL存用户、面试记录、评估报告队列与状态Redis存面试会话状态和异步任务队列对象存储MinIOS3兼容存音视频文件为什么没有用微服务因为我调研后发现整个平台的核心瓶颈不在“业务API的并发”而在“大模型调用和语音转写的耗时”。这两个瓶颈通过异步队列就可以解决完全不需要拆服务。单独拆一个转写服务是因为语音识别模型对Python生态更友好而且它和Node.js主服务的部署方式差异大分开更容易管理。1.3 技术选型清单与理由直接放我的最终选型清单附带选择理由模块技术方案选择理由前端框架Next.js 14 TypeScript全栈框架前后端用一套代码减少一人维护压力UI组件Tailwind CSS shadcn/ui快速搭建不用花时间写复杂样式数据库PostgreSQL 16稳定、功能强后面接pgvector做向量检索也方便缓存/队列Redis BullMQ面试状态存储和异步任务调度的标配对象存储MinIOS3协议兼容以后换云厂商不用改代码语音转写faster-whisper本地部署隐私性更好、按量调用成本可控大模型接入主流大模型API 本地Ollama降级API质量高本地模型作为兜底与隐私方案部署Docker Compose Nginx一台服务器搞定不需要Kubernetes这个技术栈放到现在依然是合理的Next.js帮我把“全栈”压缩成了“一个项目”Redis解决了状态同步和异步任务两个难题PostgreSQL无论项目后面做到什么规模都够用。2. 从音视频到AI打分完整链路搭建与实操要点这里我开始讲真正的硬核部分。AI面试平台最核心的链路其实不是“AI聊天”而是“音视频处理”和“AI评估”。这两个环节的坑远比我想象的多。2.1 候选人端录制浏览器兼容性比想象中更坑候选人端要采集麦克风和摄像头第一反应是使用WebRTC的getUserMedia配合MediaRecorder录制。这个方案在Chrome上很顺畅但一上线就发现了问题Safari对MediaRecorder的音频格式支持跟Chrome不一致录出来的音频出现无法解码的情况另外由于系统自动降级部分设备录出来的音频采样率不一致导致后端的语音转写模型识别率下降。我最终的解决方案是使用getUserMedia获取流时明确指定音频约束const stream await navigator.mediaDevices.getUserMedia({ audio: { echoCancellation: true, noiseSuppression: true, autoGainControl: true, sampleRate: 16000, channelCount: 1 }, video: { width: 1280, height: 720, frameRate: 24 } });sampleRate: 16000和channelCount: 1我是刻意设置的因为语音识别模型对16kHz单声道音频兼容性最好这个设置直接让后续转写准确率提升了一大截。MediaRecorder录制时不要用默认格式而是显式指定audio/webm;codecsopus码率控制在32kbps左右。语音数据不需要高码率太高反而浪费存储空间。每次录制结束用timeslice参数定时分片上传避免单个大文件上传中断后全部丢失。我设置的是5000ms一个分片断网恢复后只需要重新上传最后一片。这里需要特别注意echoCancellation一定要设为true。我测试时发现如果不开启回声消除候选人外放声音会被麦克风重新拾取AI追问时会出现“自己的声音叠在AI声音上”的诡异效果识别出来的文本直接乱掉。2.2 语音转文字为什么我弃用在线API转而去本地部署面试音频转写第一反应都是用云厂商的语音识别API。但我算了一笔账如果每天有100场面试每场30分钟音频在线API的费用一个月下来非常可观而且音频要传到第三方服务很多用户会介意隐私问题。于是我改成本地部署faster-whisper模型。本地部署的核心问题有四个模型选型我试过large-v3、medium、small三个尺寸。large-v3准确率最强但在一张消费级显卡上转写30分钟音频要很久GPU占用还高small速度够快但中文识别错误率明显。最终用了medium作为主力模型速度和准确率权衡下来最合适。长音频切片Whisper模型对超过一定长度的音频处理会退化尤其是面试这种动辄20-30分钟的录音。我的做法是先把音频按静音段切分成多个片段每个片段控制在20秒以内再逐个转写最后合并结果并打上时间戳。并发控制如果你同时让多个面试的转写任务跑在一个模型上GPU会直接爆显存。我用了一个信号量限制并发数为1其余任务排队。这样单个任务速度慢一点但整体稳定。说话人分离面试包含面试官和候选人两个角色如果只简单转写成一段文本AI评估时无法区分。我的方案是用音频能量和静音间隔粗分出两个声道/时间段再通过pyannote.audio做说话人分离把文本标记为[面试官]和[候选人]。这块做得好不好直接影响后续评估的体验。命令示例本地启动转写服务的一个片段# 使用faster-whisper部署一个简单的ASR服务 python server.py --model medium --device cuda --compute_type float16 --language zh启动后我封装了一个HTTP接口业务侧上传音频返回带时间戳和说话人标记的文本。整个过程与业务解耦后面换更好的ASR模型也不需要动主服务。2.3 大模型出题与追问Prompt设计决定面试质量面试体验好不好很大程度上取决于AI出的题和追问是否自然。我的方案不是简单地拿GPT生成几个问题而是结合岗位描述JD和候选人简历来动态出题。这里用到了一个小型RAG流程从JD文本中提取技能关键词比如“React”“Spring Boot”“MySQL”等在题库中检索相关题目作为初筛候选把候选题目和候选人简历片段一起塞给大模型让它生成3-5道针对性问题并给出每道题的考察点这里有一个关键提示词设计经验不要只让AI“生成题目”而是让AI“作为资深面试官结合候选人履历设计能够验证简历真实性的问题”。这样生成的题目质量明显更高因为模型被引导去挖掘简历中的疑点而不是泛泛地问“介绍一下你的项目”。追问环节的设计我采用了“动态追问状态机”。候选人回答完一题后系统把回答文本交给大模型让它判断回答是否完整覆盖了考察点有哪些值得追问的技术细节是否出现了明显的矛盾或夸大然后根据判断结果生成追问。这个机制模拟了真人面试官的追问习惯让面试体验更真实。但注意追问次数要设上限我设置为每题最多追问2次防止候选人被无限追问导致体验崩溃。2.4 结构化评估让AI打分不再“睁眼说瞎话”评估是另一个大坑。如果只是让AI生成一段文字评价人力根本没法用。我决定把评估结果做成结构化的JSON包含多个评分维度、分数、证据引用和具体评语。我设计了一个稳定的评估Prompt核心思路是缩小评估范围逐题评估而不是整个面试一次评估。每道题按技术深度、逻辑表达、岗位匹配度三个维度打分最后汇总。强制证据引用要求AI在评估时必须引用候选人回答的原文片段作为评分依据。这样即使打错分管理者也能快速定位到对应内容。结构化输出用JSON Schema约束大模型的输出格式避免它自由发挥。我当时用的评估Prompt简化版如下你是一位资深技术面试官。请根据以下面试回答对候选人在这一题的表现进行客观评估。 要求 1. 根据考察点逐项分析 2. 每个评分必须给出依据引述候选人原话片段 3. 使用JSON格式输出{维度: {分数: 0-10, 依据: 原文引用, 评语: 分析}} 面试题目{question} 候选人回答{answer}选型提醒在调用大模型时temperature尽量调低比如0.2top_p也设小一点否则同一个回答在不同批次评估中分数波动会很大。我曾经因为忘了调参数同一个面试跑了两次评估一次打75分一次打91分这种波动在面试场景下是致命的。3. 一人全栈的工程化落地从开发到上线的细节如果说AI部分考验的是模型理解工程化部分考验的就是代码功底和运维经验。一个人开发时很多团队协作中不会遇到的细节都会被无限放大。3.1 面试状态机与断线重连面试不能“一断全废”前面提到我设计了面试状态机这里讲落地细节。由于用户可能通过不同设备刷新页面、断网重连状态绝对不能放在前端内存或后端进程变量里。我把每个面试会话的当前状态、当前题目序号、剩余时间、已上传分片索引、转写状态全部存在Redis里。伪代码大概是这样的// 面试会话状态管理 const sessionKey interview:${interviewId}; // 面试开始 await redis.hset(sessionKey, { state: QUESTION_PENDING, currentQuestion: 0, totalQuestions: 5, remainingSeconds: 600, answers: JSON.stringify([]) }); // 候选人回答结束上传音频 await redis.hset(sessionKey, state, UPLOADING); // 异步上传文件同时更新状态Redis的Key过期时间设置也要注意。我最初设置过期时间为2小时结果发现有些候选人面试进行到一半Redis里的会话数据到期被自动清掉了导致面试“凭空消失”。解决办法是把过期时间设置成面试总时长的2倍比如60分钟面试就设置120分钟并且在每次状态变更时刷新过期时间。断线重连的体验优化我这边做到了“断了几分钟也能无缝续面”。候选人重新进入时后端从Redis读取当前状态前端根据状态渲染对应界面。如果候选人正在回答中就继续显示录音界面如果音视频上传了一半会从最后成功上传的分片索引继续。这个机制很加分用户反馈明显变好。3.2 任务队列与并发控制预算是被并发烧掉的AI面试平台天然有异步任务转写、评估、生成报告这些都是耗时的操作。如果每个请求都同步调用大模型一个人开发和维护的服务器根本扛不住成本也会失控。我用BullMQ Redis搭了一个任务队列面试完成后主服务立即返回“面试已提交”给用户后台任务按顺序执行转写-评估-生成报告-通知用户并发控制方面我做了三层限流ASR服务的并发数限制为1大模型API的并发数限制为3总任务队列堆积数超过20时新任务进入“延迟队列”不再立即处理为什么这么保守因为大模型API的并发限制不仅服务端有我自己在调用的时候也踩过限流的坑。一个人开发时没有专门的SRE只能靠代码层面的限流来保护自己和云服务商之间的“友好关系”。成本控制我单独说一层所有大模型调用都必须走队列不能同步调用。我曾经图省事在请求处理中直接同步调用大模型结果一个候选人点了“提交面试”后要等30秒才看到结果而多个并发直接把API预算烧了。全部改成异步后用户体验反而更好因为页面立刻有反馈后台慢慢处理。3.3 部署与监控一个人也要撑起24小时在线一台4核16G的云服务器一个Docker Compose文件就是我全部的“基础设施”。我把主服务、PostgreSQL、Redis、MinIO、ASR服务全部编排在Compose里服务器上只需要安装Docker和Nginx。部署时的几个细节Nginx统一入口前端静态资源、后端API、上传文件的访问都通过Nginx反向代理到不同容器同时配置HTTPS证书。日志聚合每个服务的日志统一打到一个目录便于排查。一个人看多个服务的日志时如果没有聚合会非常痛苦。进程守护所有容器都配置restart: always防止偶发崩溃后服务不可用。监控方面我引入了Sentry处理前端和后端的异常报警配合一个简单的健康检查接口挂了会发邮件通知。另外用Grafana搭了一个很轻量的监控面板看CPU、内存、队列长度和API调用量。一个人开发不可能时刻盯着看板但每天瞄一眼队列堆积和API消耗还是很有必要的。4. 踩坑实录面试平台特有的疑难杂症排查这一节是我最想写出来的因为这些问题在GitHub上搜不到答案只能自己一层一层排查。我把典型的坑列出来并附上排查思路和最终解决方案。4.1 坑AI评估幻觉导致评分失真这是我最早遇到也最严重的问题候选人的回答明明很差AI评估出来却是高分或者回答里提到了一个技术名词AI就默认候选人很精通它开始无脑夸。排查后发现原因是评估Prompt中“考察点”来自系统预设但候选人的回答可能压根没有提到这个考察点。AI为了“完成任务”硬编造了符合考察点的依据。解决方法是做“证据约束”在Prompt里显式加入“如果候选人回答中没有涉及该维度请给出低分并注明缺少依据”在输出JSON中增加missing_evidence字段如果某维度没有证据该字段为true前端展示时missing_evidencetrue的维度分数用灰色标注提示管理者“该维度没有充足证据”这个改动上线后评估报告的可靠度提升非常明显敢于直接跟面试结果挂钩。4.2 坑长音频转写截断面试内容凭空消失有用户反馈面试录音保存在那里但报告里没有任何内容。后来发现是转写环节出了问题30分钟的录音文件有几十MB上传过程中被服务器的nginx client_max_body_size限制拦截了。还有个更隐蔽的问题Whisper对长音频转写时会莫名中断最后输出的文本只包含前10分钟后面20分钟的内容凭空消失。我没有仔细检查转写服务的日志就上线了结果第一周有大量报告内容缺失。解决方案分两层前端分片上传每片不超过5MB后端支持断点续传转写服务增加“音频时长-文本长度”的校验逻辑如果转写结果文本长度与音频时长严重不匹配自动报警并触发重新转写这个自动校验的方法以后会救你很多次不只是转写ASR之外凡是“输入A输出B”的AI环节都应该加一个合理性检查。4.3 坑数据库连接池被大模型拖垮有一次用户规模上来之后PostgreSQL突然报大量连接超时新建连接失败率飙升。我差点怀疑是云数据库的问题查了半天罪魁祸首是业务代码里“先查询数据库再同步调用大模型期间持有连接不释放”的逻辑。大模型API响应要3-6秒这个过程中数据库连接被白白占用并发一高连接池立刻被打满。排查路径先看数据库连接数监控发现活跃连接数等于连接池上限再看业务日志发现大量请求卡在await llm.call()处最后定位到数据库连接未及时释放。解决方案有三点数据库连接查询完后立即释放不在异步等待期间持有连接将耗时的大模型调用全部移出数据库事务边界连接池最大值调低宁可让个别请求等待也不能把整个库拖垮这个问题也导致我对“大模型调用”和“数据库访问”做了严格的层分离不给后期再犯类似错误的机会。4.4 坑Token成本失控单次面试烧掉5块钱AI面试平台成本的大头不在服务器上而在Token消耗。我做了一次成本核算发现一个中等规格的AI面试所有环节的大模型调用加起来消耗了大概12万Token。换算成主流大模型API价格单次面试成本高达5元左右这对一个高频使用的产品来说是不可接受的。我当时做了这么几件事把成本降了下来压缩对话上下文出题、追踪、评估时不把全部历史记录塞给模型而是只传当前题目和当前轮次的回答。结果发现该传的还是要传强行压缩后评估质量下降。真正能省的是“冗余文本”和“长Prompt缓存”。模型分级出题和追问用便宜的小模型只有最终评估用强模型。例如普通追问用10倍便宜的模型只有评估用高质量模型成本直接降了40%以上。评估结果缓存同一题目的相同回答不再重复调用大模型。面试者重新作答时如果文本完全一致比如从草稿粘贴直接用缓存结果。成本控制不是一个一次性动作而是一个持续监控的过程。我后来在监控面板上专门加了一个“每次面试Token消耗”的指标一旦超过预算阈值就报警。4.5 常见问题速查表这里把一个问题和解决方案速查表整理出来方便直接对照问题现象可能原因排查思路解决方案音频无法播放浏览器兼容性、格式不支持检查录制的实际格式与浏览器版本统一转码为WebM/Opus后端兜底转码转写文本只有前半段音频被截断、Whisper长音频处理异常检查上传文件大小、转写日志分片上传断点续传转写结果校验评估分数波动大大模型参数未调低、prompt不明确对比多次评估结果调低temperature/top_p强制证据引用数据库连接耗尽大模型调用期间占用连接看活跃连接数与卡住的请求移出事务边界、及时释放连接Token成本飙升无缓存、大量重复调用、模型过大看每次面试Token消耗模型分级、结果缓存、压缩上下文5. 上线三个月后的复盘与下一步计划这个平台上线三个月虽然用户量不算大但积累了非常宝贵的真实数据。我梳理了一遍数据有几个发现让我很意外。5.1 真实数据面试时长、完成率、用户反馈平均面试时长从开始到提交平均32分钟比我预期的短。细看原因是很多候选人在回答环节比较简短AI追问次数平均只有1.3次说明追问机制还不够激进。面试完成率进入面试房间后真正完成全部题目的用户比例约为68%有32%的用户中途退出。中途退出的主要原因集中在前两题应该是体验问题或题目难度问题。评估报告查看率面试完成后24小时内查看报告的用户占比高达91%说明候选人很在意AI给出的反馈这也是这个产品最大的价值点。5.2 我自己会做的优化方向复盘下来下一步我计划做这几件事第一把追问机制升级成“多轮Agent式追问”。现在的追问还是基于单一Prompt不够智能。我计划引入一个轻量级的AI Agent根据候选人的回答动态调用不同的追问策略比如针对技术深度提问、针对项目经历提问、针对逻辑表达提问。这样面试体验会更接近真人面试官。第二接入更多的评估维度。目前评估主要还是围绕技术我想加入“学习能力”“沟通协作”等软技能评估这些能力可以通过面试中的语言表达习惯、逻辑结构等信号来推断。第三把题库做成社区化。现在的题库是我自己整理的几百道题覆盖面有限。如果平台能支持用户贡献题目并审核题库的扩展速度会快很多。最后分享一点个人体会踩了这么多坑之后我最大的体会是一个人做全栈AI应用技术能力固然重要但更重要的是“做减法”的能力。哪些功能一定要做哪些可以砍掉哪些技术栈可以合并哪些流程必须自动化这些决策每天都会消耗你的精力。AI面试平台这个项目让我明白真正难的不是调用大模型而是把模型以外的那90%工程细节打磨好。无论是面试平台还是其他AI应用能跑通Demo只是第一步能稳定、便宜、可运维地跑下去才是真正的门槛。希望这些经验能帮你少走一些弯路。
