“面试前背了三天稿结果考官问的问题一个都没押中”——这是我做这个项目最原始的出发点。市面上教面试的课、面经、题库多到看不完但真正到了现场脑子照样一片空白。问题出在哪不是你不会而是你从来没被“以你自己的经历为基础”训练过怎么开口。所以我用 AI 做了一个「面试助手」核心思路就一句话让 AI 先了解你再帮你把话讲出来。它不是一个套模板的答题机器而是一个能理解你的背景、你的项目、你的痛点然后用你的语气帮你组织语言的陪练。这篇文章我就把整个项目从零到一怎么搭的、Prompt 怎么设计、踩了哪些坑完整拆给你。适合正在准备面试的人也适合想用 AI 做垂直场景小工具的开发者。1. 需求拆解为什么“了解你”比“会答题”更重要先说一个我在面试别人时观察到的现象。候选人简历写了“负责某某系统重构性能提升40%”我追问“具体做了哪几个优化你怎么评估收益”很多人只能说出“用了缓存”。技术名词他会背但把名词变成有血有肉的经历绝大部分人做不到。这里面缺的不是知识而是一种“把自己的经历讲成故事”的能力。1.1 面试场景的真实痛点市面上大多数 AI 面试工具都是「题库式」的你选一个岗位它给你一堆题你答完它打分。这种工具有个致命问题——它训练的是“标准答案”不是“你的答案”。面试官问“你最大的缺点是什么”题库永远告诉你“要有诚意但别暴露硬伤”可你真正该回答的是基于你的性格短板、过往被反馈过的真实案例用你自己的经历包装出来的答案。这个项目反着做。它先花几分钟了解你的背景工作年限、技术栈、岗位方向最近做的项目、你在其中承担的角色遇到过的困难、怎么解决的、结果如何性格特点、别人对你的评价、你对自己的认知这些信息被塞进 AI 的上下文之后面试官问什么AI 就基于你的真实经历去生成回答。它生成的不是一套标准答案而是“如果是你在那个场景下你会怎么说”。这就是所谓的“先了解你”。1.2 知识库双层的设计逻辑我把整个项目拆成两层。第一层叫静态知识库也就是你提前填好的个人信息这层数据基本不变每次会话都可以复用。第二层叫动态会话上下文也就是面试官当前提的问题、你刚才的回答、AI 给你的追问这层是实时变化的。为什么这么设计因为直接把所有个人信息塞进每次请求里会碰到两个麻烦。一是 Token 消耗太大二是面试官的问题通常只关心你经历里的某一部分信息太杂反而干扰 AI 生成。所以程序里做了检索根据当前问题从个人信息里提取最相关的项目经历再和当前会话拼接成 prompt。注意这里说的“检索”不是第三方向量数据库就是一个很简单的关键词匹配筛选。但即便如此效果已经比“全量塞入”干净得多。如果你的信息有几万字全塞进去不光烧钱AI 也确实会“忘记”重点。1.3 面向用户和面向开发者的双向价值这个项目表面上是做一个“面试题库”但实际上是一个“个人经历结构化表达引擎”。它有两个用户群第一类是求职者本人。他们用这个东西的最大价值不是“记住我要说什么”而是“发现原来我做过这么重要的事”。很多人填信息时只写三五行AI 追问之后才发现原来项目里有那么多可以展开讲的亮点。第二类是像我这样对 AI 应用开发感兴趣的人。这个项目是一个很好的样板怎么把用户画像数据变成 prompt 的一部分怎么做检索增强怎么处理流式输出怎么做会话管理。麻雀虽小五脏俱全。2. 技术选型为什么不用“套壳大模型”就完事最懒的做法是写个网页把用户填的内容存下来每次提问时把内容拼到 prompt 里发给大模型。靠这个确实能用但我做了四件事让项目“真正能用起来”而不是一个课后作业级别的 demo。2.1 流式输出的体验价值大模型生成回答通常要一两秒甚至更久如果等全部生成完再显示用户盯着按钮转圈很容易焦虑。我一开始用的就是这个同步方案实测 20 秒的等待时间真的会让用户反复刷新页面、怀疑系统挂了。后来改成流式输出AI 每生成一个字就往页面上推用户看到文字一个接一个蹦出来等待感会大幅降低。这个改动没有改变任何 AI 逻辑纯粹是体验升级但对“面试练习”这种强调临场氛围的场景尤其重要——因为你还要模拟面试官等待你回答的状态。2.2 会话状态管理不止“聊天记录”那么简单普通聊天工具记住上下文只需要把历史消息都存下来。但面试助手有个特殊需求面试官问了一个问题AI 生成回答后紧接着要追问“能不能换个说法”“再精简到 30 秒”。这种追问必须基于刚才的回答而不能基于你的个人信息重新编一个。所以我在每次回答后都把“用户原始回答 / 你当前的表达建议”单独存一份状态。下次追问时这个状态会被当作“当前草稿”让 AI 基于草稿去改写而不是回到信息库重造。很多新手做这类功能容易踩的坑就是把改写请求误送到“完整知识库”里结果 AI 生成了全新的内容反而丢了你刚才想改写的重点。2.3 为什么选择云端大模型 API 而不是本地部署有朋友问过我这个工具用开源模型本地跑不更省成本吗不是不可以但代价不小。本地模型想达到商用 API 的理解水平至少要跑 7B 以上参数量的模型显存就是门槛而且面试场景的问题千奇百怪本地模型一旦理解偏了调优成本极高。用云端 API 的优势是开箱即用而且支持流式、支持复杂指令。缺点是费用和网络但个人练习场景用量不大一次完整面试练习的 token 消耗换算成成本基本可以忽略比请一个模拟面试官便宜太多了。我的建议是做垂直场景应用第一版先无脑用最强 API跑通逻辑、验证痛点有没有被解决如果日活上来了再考虑蒸馏或换小模型做优化不要一开始就在成本问题上过度设计。2.4 数据存储JSON 文件的取舍这个项目早期数据存储用的是 MongoDB后来被我用 JSON 文件替换了。原因很简单涉及到的数据量太小了每个用户几十条个人信息每天顶多几百次会话。用数据库要维护服务还要处理数据迁移直接一个 JSON 文件存本地备份就是复制粘贴。这里想分享的一个经验是技术选型要跟你的项目规模匹配。别因为“数据库是正规做法”就上全套基础设施个人项目或者小工具把复杂逻辑做进 AI prompt 里把简单数据放本地文件里寿命可能比大而全的方案更长。3. 核心模块拆解AI 怎么“了解你”并“帮你说话”这个项目的源码结构不复杂主要分四块信息录入与解析模块知识库构建模块问题理解与检索模块问答生成与会话管理模块每一块都有自己的设计细节展开聊聊。3.1 信息录入让用户“愿意填”才是难点你可能会说不就是做几个表单让用户填嘛有什么难的难点在于用户要么懒得写要么不知道自己该写什么。如果直接扔一个“请介绍一下你的项目经历”大部分人就填一两行就放弃了。我用的方式是「问卷式引导」。界面列出这样的问题你最近做过的一个最有挑战的项目是什么你在里面负责哪个模块具体做了什么事项目最后带来了什么可量化的结果如果现在让你重新做你会在哪里改进这样引导是可以的但还不够。更有效的手段是“解析导入”让用户直接把简历文本粘进来AI 自动抽取关键信息生成结构化字段用户只需要校对和补充。简历解析我用大模型做过一版效果比想象中好能把“负责订单系统重构优化高并发场景”自动拆成“项目背景 / 你的角色 / 技术难点 / 成果”这些信息直接进知识库。3.2 问题理解不轻易“教育用户”很多面试工具的套路是你输入一个岗位它问一句你答一句。我的项目更强的一点在于它能理解复杂提问。比如你手滑输入“我上家公司是做电商的主要技术栈是 Java最近做的是秒杀系统”它不会当成一个问题去回答而是提取出“电商背景 / Java / 秒杀系统”这三个关键信息自动更新知识库。这一点让信息录入环节几乎不设限。用户可以一边练习一边补充信息AI 会自动识别哪些输入是“新的经历”哪些输入是“对当前问题的回答”。这里的技术实现不复杂本质就是在用户输入之前加一个角色指令让模型判断输入的性质——是把信息存入档案还是作为面试回答给出评价。3.3 检索与拼装把最相关的经历“喂”给 AI知识库里信息多了以后不可能每次都全量塞进 prompt。设计了一个轻量级的检索函数它做的事很简单把面试官当前的问题和知识库中每条信息的标签数组做匹配。比如你在知识库里录了三条经历订单系统重构标签Java、性能优化、并发数据迁移项目标签Python、数据处理、ETL客服工单系统标签全栈、效率工具当面试官问“讲讲你在高并发场景下的实践”时检索模块会去匹配“高并发”这个关键词命中第一条。然后程序只把这条经历拼进 prompt而不是把三条都塞进去。匹配算法本质上就是对关键词做交集的计分排序代码很简单。但做这个词的匹配时遇到了一个实际问题中文表达太灵活了面试官问题里说“秒杀场景”知识库标签里却是“高并发”匹配不上。解决的办法是用大模型打标签时做一次语义扩充把“秒杀 / 高并发 / 热点缓存”都归到一组近义词标签下。这样检索命中率大幅提升。3.4 系统提示词设计AI 的“人设”来自哪里系统提示词是我花最多时间调的内容。我给它定义了三层人设第一层是“面试陪练员”它的任务不是告诉用户正确答案而是帮用户理清思路、给出表达建议。第二层是“背景知情者”明确告诉 AI 它已经了解了用户的完整背景回答时必须基于这些背景不能凭空发挥。第三层是“表达教练”要求它在给出优化建议时不只说“要更有条理”而是给出具体的改写示范“你可以说这个项目我们分三步推进第一步……第二步……”。这里有一个技巧让 AI 给出“示范表达”时要明确要求它“以用户本人的口吻”而不是“以 AI 的口吻”。如果不加这句AI 生成的示范会特别官方读起来像百科词条练了也白练。提示真正的杀手锏是让 AI 追问。面试练习不应该是一问一答而是回答完了 AI 追加一句“如果面试官接着问这里你会怎么答”这种上下文练习比单纯的问答更能提升临场反应能力。4. 实操过程全记录从简历导入到模拟面试下面用一次完整的实操过程把项目怎么用、效果怎么样从头到尾捋一遍。这个案例用的是某位有三年经验的后端开发者朋友的真实使用记录脱敏关键信息后分享出来。4.1 第一步导入简历自动结构化这位朋友直接把自己一页多的 txt 简历文本粘贴进系统。AI 抽取生成的结果是一个 JSON 格式的知识库条目{ info_type: project_experience, project_name: 订单缓存服务, role: 核心开发, background: 部门原有查询接口在高峰期响应超过 800ms影响下单转化率, actions: 引入本地热点缓存优化数据库索引增加限流降级逻辑, result: 高峰期接口耗时降到 150ms系统可用性提升到 99.9%, tech_tags: [Java, Redis, 性能优化, 高并发, 限流], keywords_expanded: [高并发, 低谷期, 秒杀, 热点数据, 缓存穿透] }这个 JSON 是自动解析后由用户确认的用户只需要看一遍把不准确的地方改掉。整个过程大约 5 分钟比手动填写快很多。4.2 第二步设置岗位和面试风格系统里可以配置面试官的风格。有人需要“温和引导型”有人需要“连续追问型”还有人需要“压力面试型”。这一步表面上是选风格实际上是设定 prompt 里的温度参数。压力面试模式的指令是面试官语气简洁、不断追问细节、对模糊表达会指出“你的回答太浅了能再具体一点吗”。温和模式则相反。这个设置在练习体验上的差别很明显我建议用“压力面试”来练因为真实面试往往不会那么温和。4.3 第三步开始练习看 AI 怎么“帮你把话讲出来”面试官提问“你做过的最有挑战的项目是什么请讲一下你在其中做的具体工作。”这位朋友的第一反应是“我做过一个订单缓存服务当时耗时很长我用 Redis 优化了一下后来快了很多。”AI 对这个回答的评价是有事实没结构缺少细节层次。然后给出了示范改写“我做过一个订单缓存服务主要背景是接口在高峰期响应超过了 800 毫秒影响了用户下单体验。我做了三件事 第一分析慢查询发现数据库索引有失效的字段重新设计了组合索引 第二引入本地热点缓存把 Top 100 的商品数据放在进程内存里减少对 Redis 的访问 第三加了限流降级在极端流量下优先保护下单主链路。 最终效果是高峰期耗时降到 150 毫秒可用性维持在 99.9%。 如果面试官接着问‘你对限流降级是怎么理解的’我会说…… ”看到这儿很多读者已经明白了这个工具的核心价值。它不是帮你背一句话而是把“你经历过的事”组织成“面试官听得懂、记得住的结构”。第一版回答只用了三句话第二次回答就有了背景、过程、细节和结果而且埋好了下一次追问的钩子。4.4 第四步用追问来打磨表达AI 还会做一件事对你刚才的示范进行追问。比如“你说的本地热点缓存跟 Redis 缓存有什么区别如果我说用 Redis 就够了你为什么要用本地缓存”这种追问特别贴近真实面试官会咬住的细节。用户需要锻炼的能力就是在追问中快速识别出面试官的“潜台词”他问你怎么实现真正关心的是你有没有遇到过缓存和数据库一致性问题他问你怎么设计限流真正关心的是你有没有压测过。这个环节我用了一个专门的功能叫“追问预测”AI 会输出三个候选追问用户可以先在心里组织答案再点击“揭晓示范”。这种先思考再对照的方式比直接看答案学到的东西多得多。4.5 第五步回顾会话导出“个人话术库”练习结束后系统会生成一份会话总结提取出用户表达中的亮点和薄弱点。比如它会分析“你在回答项目背景时用词比较准确但在回答‘你遇到过什么挫折’时缺乏具体的解决过程描述”。这些总结可以累积形成一份“个人话术库”。下次面试前你只要翻这个话术库就能想起自己所有项目的表达结构。这也是我能给出的一个建议别只把系统当成“问答机”把它当成一个会做笔记的教练那些用过的示例结构才是你下场的底牌。5. 常见问题与排查技巧实录这个项目在开发过程中遇到了不少问题列几个最有代表性的这些经验也许可以帮你绕过同样的坑。5.1 流式输出时回答被截断AI 生成长回答时流式传输偶尔会出现尾部截断。排查之后发现原因是调用接口时设定的max_tokens不够长而面试回答经常能到三四百字一旦超过了上限就会直接切断。解决办法是在流式模式下把生成参数的上限调高同时在 prompt 里限制“回答控制在 300 字以内如果内容较长优先保留核心细节”。用字数和 token 双重约束既能控制成本也能避免截断。这个问题最容易出现在用户一次性输入很长问题的时候。5.2 AI 回答跑偏不看用户信息自己去编有一次测试时AI 回答的内容明显不是用户提供过的经历。打开调试面板发现原因是知识库检索模块没命中任何条目系统于是把 prompt 里用户信息的部分留空了AI 没有可参考的信息就开始自由发挥。给系统加了一条兜底逻辑如果没有检索到相关知识先输出一条“这个经历你还没有录入需要先补充项目背景、你的角色、结果”而不是硬要生成。另外在系统提示词里明确声明回答必须基于用户信息严禁编造没有录入的经历。双重保障之下跑偏情况明显减少。5.3 用户填写的口语化内容AI 理解不准确很多用户填知识库时用的不是结构化文本而是“我这边有个系统主要是处理数据后面还做了点命令行工具”这种模糊的话。AI 虽然能理解自然语言但抽取出来的信息经常丢失关键细节。我在信息录入模块里加了一个追问机制当检测到用户提交的信息过短或不够具体时AI 会反问“你在项目里具体承担了哪个模块最终的量化结果是什么”直到获取到足够信息。这个“追问细节”的做法被我固执地保留在了各个模块里因为它最能还原面试官真实的对话节奏。5.4 面试官脚本的差异化不够一开始做模拟面试的时候我用的是一套通用的面试官 prompt结果发现不同岗位的追问风格差别极大。产品岗需要追问用户价值技术岗追问系统设计运营岗追问数据指标。甚至同样是技术岗前端面试官会更关注性能优化和交互体验后端面试官则关注并发和一致性。后来我把面试官的“岗位画像”专门做成了一个小配置模块。系统会基于用户设置的岗位方向从知识库里提取对应技术标签加载不同的追问模板。这个改动不大但用户体验好了很多因为它让“面试官”看起来更专业了。6. 从“面试助手”到“表达教练”这套思路能延伸到哪最后聊聊这个项目做完后我对“AI 辅助表达”这件事的整体感受。很多人听到“AI 面试助手”第一反应是“AI 教我怎么说”。其实项目做到后面我发现它真正的价值是帮你把脑子里一团乱麻的“经历记忆”转变成一条条有头有尾的“表达素材”。这套「先了解你再帮你把话讲出来」的思路换一个场景就是程序员做技术分享之前让 AI 先理解你的项目代码和踩坑记录帮你把演讲提纲搭出来销售谈客户之前让 AI 先了解你之前服务过的客户帮你生成推品话术内向的人在社交前让 AI 了解你的性格和表达习惯帮你把自我介绍打磨好。技术上的难度从来不在“接个大模型 API”而在于你怎么设计知识的输入形态、怎么组织上下文、怎么让 AI 的输出贴合真实用户的声音。个人经验是用 JSON 这种结构化格式存知识库是最好的AI 能准确提取程序也能精确检索而最终的表达示例一定要让 AI 以用户的身份和语气来写否则一句话都落不了地。如果你也想搭一个类似的工具我的建议是从最小版本开始先做一个能录入个人信息、能按问题输出示范回答的脚本跑通之后再考虑流式输出、追问预测、话术库这些进阶功能。别一上来就想着做产品级的东西AI 应用开发最大的乐趣是先拿一个小场景验证它到底能不能帮上忙。