1. 项目定位为什么做面试助手而不是背题库我见过太多人面试前不准备或者准备错了方向。有人把网上那些“高赞回答”背得滚瓜烂熟结果一问到简历细节就露馅有人干脆裸面全靠临场发挥状态稍微一波动就断片。这个项目的出发点特别朴素我想做一个面试助手让 AI 先通过访谈了解用户再帮用户把话讲出来。注意这里的顺序先了解你再帮你讲。不是给一套万能话术而是让大模型先问几个问题把你的经历、岗位目标、表达习惯摸清楚生成一条专属于你的表达路径。这个项目能解决的核心问题很简单你在面试里说不出、说不清、说不像自己。适合谁适合准备跳槽的开发者、转行的人、应届生也适合那些明明做了实事但讲不出亮点的人。我自己的观察是大部分人不是没能力而是被“临时组织语言”这件事卡住了。如果有一台 AI 能提前跟你聊半小时把你简历里那些“做过XX系统”扩展成一段有逻辑、有数据、有个人角色的故事面试时你会轻松很多。我把这个项目做成了一个带对话界面的 Web 应用核心就三件事意向采集、画像建模、生成回答。下面整个文章的内容都是围绕这三件事展开的包括我怎么设计访谈问题、怎么控制生成内容的真实性、怎么去 AI 味、怎么测效果。我会尽量把踩过的坑也写出来这篇东西更像是我做完整个项目之后的复盘记录不讲太多虚的。2. 核心设计访谈式建模 个性化生成2.1 整体流程拆解先给大家一张流程图放在脑子里不用打开任何工具理解下面这条链路就够了用户进入系统 → AI 连续提 3 到 5 个问题 → 系统把回答整理成结构化画像 → 用户选择要练习的面试题 → AI 结合画像生成回答 → 用户修改/确认关键事实 → 生成最终口语稿。整个流程最关键的词是“画像”。画像不是传统意义的标签云比如“5年后端经验”“熟悉分布式”——那种东西没有任何用处。我要的画像是一份可以直接写进回答里的事实清单和表达偏好包括你过去最值得讲的一段经历是什么你当时的角色是什么这段经历里你做了哪些具体动作产生了什么可量化的结果你说话喜欢沉稳一点还是热情一点喜欢讲细节还是讲结论你对目标岗位的动机是真实存在的还是自己也说不清楚。这些信息一次性问不完硬问用户会烦所以 AI 要像真人面试官一样通过追问来逐步收敛信息。比如用户说“上个大促项目我负责稳定性保障”AI 不能直接记下来而应该追问“这个项目里你说‘负责’具体是指你独立设计预案还是执行别人的方案”。这类追问是做画像误差的主要来源也是最值得打磨的逻辑环节。2.2 用户画像建模模块怎么做我一开始的建模方案很天真直接让大模型读用户的所有对话记录然后生成一段自然语言描述。这样能用但问题特别多最明显的是模型容易漏细节。聊到第五轮的时候第一轮的重要信息已经“飘”出上下文视野了生成出来的画像经常是一堆空话比如“该用户有较强的问题解决能力”——这种东西能有什么用后来我参考了结构化思维里的“事实-观点-目标”三层法把画像拆成了固定 JSON 结构。这么做的一个原因是大模型输出 JSON 比较稳定另一个原因是后续生成回答时可以让模型严格按照字段引用减少编造空间。结构大概是这样的{ profile_version: 1, user_context: { target_role: 产品运营转数据分析, years_experience: 3, career_motivation: 想从偏执行转做决策支持, available_stories: [ { story_id: s1, event: 搭建活动数据看板, role: 运营视角提出需求并推动落地, action_details: [梳理业务指标, 对接研发资源, 验收并迭代], outcome: 看板上线后减少手工取数约70%, verification_pending: false } ] }, expression_preferences: { tone: 专业严谨, detail_level: 先结论后展开, avoid_terms: [underscore, very] } }有了这个结构以后“整体设计”才真正变得可操作。用户说出来的信息经过大模型改写被填进对应的字段没提到的故事就留空后续追问时只针对空字段提问。这样做的好处非常明显AI 不会瞎编经历也不会只根据第一轮印象生成答案。你可以把它理解成一份动态更新的采访提词器模型每次追问前先看画像里缺什么。2.3 为什么不用“通用答案库”这种省事方案做项目的时候有朋友提过建议网上那些“100 个高频面试题 满分回答”多得是直接抓下来做检索不就行了嘛。这个方案听起来成本低但我试用两天就放弃了原因很现实。通用答案是给“平均水平”的人准备的而面试本质上是“匹配”而非“考试”。同一个“你为什么离开上一家公司”的问题一个因为组织架构调整出来的人和一个因为职业天花板出来的人需要的表达方式完全不一样。前者要突出“外部原因”后者要突出“内部动机”。通用答案库没法把这层差异表达出来因为它不知道你真正的情况。所以我最终坚持的就是“先了解再生成”的路线。这不是技术炫技而是绕不开的需求本质。要让面试回答显得真诚、有细节、有个人辨识度必须有用户自己的素材作为事实底座。每一步 AI 的生成都只是帮你把素材重新组织和润色而不是从零创造。3. 实操过程从冷启动到能用的完整链路3.1 冷启动先搭一个能跑通的最小闭环这个项目我在开始写代码之前先做了逻辑验证。我拿纸列出了这条链路用户第一次进入系统应该看到什么样的界面我应该让它先填表单还是直接跟 AI 对话我选择了直接对话。原因是表单的字段永远是有限的用户填到第三行就会烦对话模式则更自然也更能让 AI 在不经意间捕捉表达习惯。冷启动版本其实简单到可怕一个输入框 一个接口 一张内存状态表。用户在网页里输入自我介绍大模型根据自我介绍自动生成第一个访谈问题然后一轮一轮往下走。每一轮用户回答后系统在后台更新画像然后判断画像够不够详细如果够就停止提问如果不够就继续追问。这个最小闭环跑通以后我发现两个特别明显的问题。第一个是模型很容易问出“太开放”的问题比如“你能详细说说你的工作吗”用户回答起来要写一大段体验很差。第二个问题是用户回答里经常出现专业术语或内部叫法比如“中台项目里的抓手”——这些词如果直接进画像后续生成回答会显得特别“黑话”。我花了不少精力在 Prompt 里加“转化原则”这里先不展开后面会专门讲。3.2 Prompt 设计实录访谈题目的生成逻辑提问是整个系统里最重要的模块因为它决定了画像的质量。我试过让模型一次性生成 5 个问题让用户回答效果非常差用户面对屏幕就像在填问卷而且回答质量越来越水。后来改成“一次只问一个问题”模型根据当前画像动态决定问什么。这其实就是在模拟一个优秀面试官的节奏先开放式提问再封闭式追问最后用确认式问题收口。下面是我使用的一个 Prompt 模板的关键片段经过多版迭代它可以稳定地让模型“先看画像再决定问什么”你是一位访谈助手。当前用户画像如下 {profile_json} 请判断画像中以下信息是否完整 1. 用户的核心经历与个人角色 2. 经历中可量化的结果 3. 用户的表达偏好 4. 用户的目标岗位动机 如果以上信息已完整请输出COMPLETE 如果还有缺失请在以下问题类型中选择一个去提问 - clarification当现有信息存在矛盾或模糊时 - deepening当某个经历细节不够时 - motivation当用户动机不清晰时 要求 - 一次只问一个问题 - 问题必须结合画像中已有的信息进行具体化不能泛泛而问 - 语气自然口语化不要让用户觉得在被盘问这里面最有价值的其实是“结合画像中已有信息进行具体化”这句话。举个例子如果画像里已经有“搭建活动数据看板”这个素材模型就不会问那种万能问题“你最有成就感的事情是什么”而会问“你提到搭建这个看板时你个人最主要解决了哪个环节的卡点”——这种问题才能带出故事细节。3.3 答案生成与语气控制访谈结束以后用户选一道面试题系统开始生成回答。这部分我用的是“两阶段生成法”。第一阶段先生成回答的骨架只包含逻辑结构和核心论点第二阶段再对骨架进行扩写加入画像里的故事细节并做语气控制。为什么要分两段第一版我让模型直接从问题生成最终回答结果特别容易翻车尤其是骨架逻辑一旦跑偏整段回答就是辞藻华丽但内容空洞。分两段以后我可以先检查骨架是否符合“结论-证据-行动-结果”的经典结构再决定要不要扩写。相当于先写提纲再写正文可控性大大提升。语气控制这块我踩过不少坑。直接在 Prompt 里写“请让回答显得真实自然”几乎没用模型该怎么端着还是怎么端着。后来我换了一种更可操作的写法比如给模型一个“模仿对象”请把下面的回答改写成一位三年经验的运营人员在面试中会说的话。 要求 - 多用第一人称“我”少用“我们团队” - 删除所有形容词堆叠如“极大地”“显著地” - 每句话信息密度要高宁可短句也不要空话 - 如果从用户画像中发现了具体数字必须在回答中自然带入 - 不能虚构任何用户未提到的数据或经历这个 Prompt 的转折点在于加了“不能虚构任何用户未提到的数据或经历”。之前没有这条约束时模型经常会说“我搭建了一个覆盖 10 个业务线的数据中台”而用户画像里根本没有这个信息这种幻觉在面试场景里是致命的。一旦用户照着读了面试官追问细节立马就会露馅。3.4 结构化输出的处理细节系统跟用户打交道的输出有两种一种是我们自己服务端用的画像 JSON另一种是给用户看的对话消息。这两种输出的处理方式完全不同。画像 JSON 我要求模型输出严格的 JSON 格式这没什么特别。但给用户看的对话消息我要求模型“不要表现得像一个生成模型”什么意思呢就是禁止在回答前面加“根据您的描述”或者“建议您可以这样说”之类的套话直接给出完整口语稿就行。为了做到这一点我用了一个非常笨但有效的办法在前端展示时把 AI 生成消息里可能出现的“开场废话”全部做替换处理比如把“当然可以”替换成“可以”把“首先/其次/最后”替换成空串。虽然算法上粗暴了一点但是对真实用户体验的提升是非常直观的。后来我发现自己替换的效率太低了才回头在 Prompt 里加了一条指令“禁止使用任何连接词作为开头的句子”。这两层保障叠加上去才把 AI 味压到可接受水平。4. 关键工具与模型选型4.1 大模型接口对比与取舍这套系统本质上是大模型应用所以模型选型直接影响成本和效果。我在项目初期对比了三种路线调用商用模型 API、部署开源模型、用规则模型做兜底。最后我选的是“商用模型 API 做核心理解 规则代码做边缘处理”的混合路线。原因主要有三个。第一访谈式建模需要很强的上下文理解能力开源小模型很容易在第四轮提问时忘记用户第一轮说了什么第二商用 API 的延迟和稳定性对我来说更重要我不想花大量时间在推理服务运维上第三成本方面访谈对话本身占据的 token 量不大主要是生成回答时多这块通过“只对最后生成的用户回答做缓存”来控制。选型时最值得关注的指标不是你有多强的基础能力而是对“指令遵循”能力的稳定性。我实测下来同样一段 Prompt 在几个主流模型上的表现差异很大尤其是“一次只问一个问题”这种定位指令有的模型就是会自作聪明一次性列三五个问题这时候选模型比调 Prompt 更有效。4.2 上下文管理的几个坑用大模型做多轮对话上下文管理是最大的隐形工作量。我第一版犯了很蠢的错误把所有历史消息全部塞进大模型的上下文结果 token 爆炸而且模型会被用户早期回答里一些无关紧要的内容带偏。后来我重新设计了一套上下文协议系统上下文中永远只放三样东西——用户画像 JSON、当前正在处理的问题、最近三轮对话记录。这套协议带来的变化很明显。第一token 成本直接下降了大概一半第二模型“失忆”的问题大大减少因为它每次主要参考的是结构化的画像而不是原始对话流。我在这里学到一句话大模型应用里关键不是让模型记住所有东西而是把重要的东西提前提炼好放在它面前。4.3 成本与延迟控制面试场景对延迟没有像对话机器人那么苛刻但也不能让用户等太久。我统计过一次完整的访谈大概要调用大模型四到六次每轮的等待时间大概在两到三秒用户勉强可以接受。真正让人崩溃的是出最终面试回答那一步因为要先生成骨架再扩写等于两次大模型调用整体耗时常常超过八秒。为了优化这个体验我做了两个操作。第一把“骨架生成”和“正文扩写”两个步骤并行化其实第二步不依赖第一步的最终文本只依赖第一步的几行框架标题所以只要前端提前把框架展示给用户再后台异步生成正文体感上就能从八秒提升到接近三秒。第二对常见的面试题做结果缓存如果用户画像变化不大同样的题第二次请求直接吐上次生成的结果代价是用户会看不到更新但换来速度上的稳定。5. 测试与调优我用了几十轮对话找出来的规律5.1 用户画像不准的三个典型现象整个系统最怕的不是生成不好看而是画像不准。测试过程中我总结出了三个高频出错的模式。第一个叫“贴标签式画像”就是模型总结了用户很会沟通但实际上用户从头到尾只说过一句话“我比较喜欢跟人打交道”这种推断属于过度解读。第二个叫“张冠李戴”用户说了两段经历模型把第一段的成果安到了第二段头上尤其当两段经历时间线挨得很近时特别容易犯错。第三个叫“补充幻觉”前面提过就不重复了。针对这三个问题我最后的解决方案比较朴实画像字段里增加一个confidence字段当模型发现用户的原始回答足够明确时confidence 才给到high如果是从语气或语义中推测的信息一律标成medium并且在前端显示为“我理解你是这么想的对吗”让用户确认。这个“确认机制”是整个系统准确性的最后一道防线。5.2 回答太像 AI 怎么办很多使用过大模型的人都有印象一段文字如果用了太多“总而言之”“首先”“不仅……而且……”这类词就会显得很假。我做过一个去掉 AI 味的专项测试最后总结出了三条有效策略。第一引入“个人视角限定词”。让模型在回答中尽可能加入“我之前负责”“我记得当时”“说实话”这类角度明确的口语化表达它们会瞬间把一段通用话术拉回个人叙事。第二给回答设定“节奏”面试口语稿不能像书面文档一样一写就是大段模型生成以后我会做一次自动分段每段不超过三句话逼着用户在面试中留出呼吸感。第三也是最有效的把“用户真实素材”深入嵌入到回答里一旦有大量具体的时间、数字、细节AI 味浓度自然会下降。5.3 如何做自动化评测我个人的经验是大模型项目不能靠肉眼测完就算完。我把核心链路做成了一个自动化测试脚本输入是一组虚拟用户的画像数据输出是三个维度的评分事实一致性、语气自然度、逻辑清晰度。模型生成结束以后脚本会重新调一次大模型让它扮演“评审官”逐条检查生成的回答是否跟画像中记录的事实一致。这个评测过程不可能做到 100% 自动化但至少能帮我把“低级幻觉”从版本发布里拦下来。我在跑了几轮测试以后还发现一个有意思的规律模型自己评估自己时往往过于宽容所以我会每隔几次人工抽查一次结果然后给评测 Prompt 增加一个“贬义倾向”的系统指令告诉它“你是挑剔的面试官请优先寻找逻辑漏洞”。这一招比直接写“请评估”效果要明显得多。6. 常见问题与排查技巧实录下面这部分整理成表格方便大家在做的过程中遇到问题时直接对着查。这些都是我在项目实际运行中验证过的解决路径。问题现象可能原因排查方向解决建议访谈阶段用户回答越来越短问题太开放用户嫌麻烦检查提问类型是否太集中在“开放式”每条问题前加限制请尽量让用户用一两句话回答必要时使用封闭式追问生成的回答里出现用户没说过的事模型幻觉检查生成 Prompt 最底部是否有“事实约束”指令在 Prompt 末尾追加“禁止虚构画像之外的任何数据或经历”并在前端加确认按钮访谈进行到第三轮开始重复提问上下文被早期信息掩盖检查是否使用了画像 JSON 作为上下文压缩把画像 JSON 放在系统提示词最前面并清除无关历史消息回答读起来像论文不像说话模型默认书面语偏好检查是否有语气模仿指令增加口语化改写步骤限制每句话长度明确禁止“首先/其次/综上所述”等连接词用户画像中动机信息缺失访谈问题没有覆盖该维度检查提问决策逻辑在提问 Prompt 中加入动机维度判定并设置最低提问轮数不能上来就完事同一道题两次生成的结果差异很大Prompt 不稳定或缺少示例检查是否提供了 few-shot 示例在生成 Prompt 中加入一个固定参考回答示例让模型模仿结构而不是内容这个表格是我在实际调试过程中反复更新出来的普通问题看前两列基本就能定位。如果遇到表格里没有的情况我的建议是先打开日志看用户最近一轮回答被模型转成了什么样的画像字段基本都能发现问题出在哪一步。最后分享一个我踩过最深的坑不要太信任大模型帮你“整理用户原话”。有一次测试中用户说“我做过一个很小的爬虫工具帮我省了大概每天一小时工作量”模型在画像里总结成“主导研发数据采集系统”语气倒是厉害了但用户如果真的照着说面试官大概率会追问技术细节。这件事让我彻底明白了一个教训面试助手产品里真实性的优先级永远高于文采。后来所有涉及事实的描述系统都会把用户原始说法保留在一个单独的字段里生成时优先引用原文而不是模型改写后的“高姿态表达”。这个项目到目前为止已经跑通了我预期里的完整闭环从让 AI 了解用户到帮用户把话讲出来整个过程里最有成就感的其实不是技术实现而是看到用户拿着生成稿改完后说“这就是我想说的”。如果你也想做一个类似的 AI 应用我建议你从小闭环开始先把访谈和生成这两步跑通再去加花哨的功能。你会发现真正有价值的部分永远是那些让 AI 更懂人的细节设计。