我认识一个后端工程师代码能力真的不弱压测方案、线上问题排查、性能优化都能说得头头是道但连续碰了两家公司的面试都挂在二面。我陪他做过好几次模拟面试坐在他对面听着听着就发现问题根本不在技术深度而是他在回答的时候完全不会讲故事——被问到你怎么解决线上故障他能对着报错日志描述三分钟操作顺序却唯独没有说清楚我为什么这么排查和最后影响范围是怎么控制的。后来我用 AI 写了一个「面试助手」思路就一句话让 AI 先了解你再帮你把话讲出来。这不是让 AI 直接甩给我一份标准答案而是让它先通过聊天把你的真实经历、表达习惯、技术栈甚至性格特点都摸清楚再以你的身份、你的口吻、你经历过的项目帮你组织出你真正能在面试现场说出口的回答。这篇文章写给两类人一是想解决面试表达问题、但不想背标准答案的求职者二是对用 AI 做垂直产品感兴趣的开发者。我会把产品的设计思路、工作流拆解、开发过程、提示词工程的核心技巧以及几轮翻车迭代的经历都摊开来讲你不仅能看明白这个产品怎么做的还能照着思路去搭你自己的版本。1. 为什么了解你比帮你说话更重要面试回答的本质是匹配不是完美我最早做这个产品的时候第一反应也是做一个输入问题直接出答案的工具。市面上的 AI 面试工具基本都是这个路子——你选岗位、选问题类型它给你生成一篇结构完整、用词高级的回答。但我拿真实简历测了几轮之后发现这类答案有个致命的毛病它太标准了。面试官一天面十个人听到的回答都是同一个味道——遇到问题我先冷静分析然后拆解任务最后复盘总结。这些话确实是对的也确实没有任何信息量。关键在于面试官判断的不是这个回答对不对而是这个坐在我面前的人到底有没有做过他嘴里说的那些事。一旦进入追问环节比如你当时具体看了什么监控指标你做的这个优化上线之后 QPS 变成了多少通用答案瞬间就露馅了因为那些细节根本不在你的经历里。所以我推翻了第一版方案把产品的核心逻辑改成了先采集后生成。原因很简单面试问答本质上是一次信息匹配面试官手里拿着岗位需求清单他是在拿你的真实经历去逐条对照而不是在欣赏你说得多流畅。如果没有你亲身经历的锚点做支撑表达越完美越容易被当成背书。对比一下两种模式就能看得很清楚对比维度通用 AI 直接生成的回答基于候选人画像生成的回答信息来源模型训练时的通用经验候选人自己填写的真实经历追问抗性经不起追问细节对不上每个点都有实际经验支撑个人痕迹几乎没有换谁都能说口吻、用词、项目细节都像本人面试官感受背过题的应试感有思考痕迹的真实交流基于这个判断产品第一版就做了一个很强制的设计你打开页面之后不能直接问问题必须先完成一轮信息采集。这个流程确实劝退了一些急性子用户但它保证了后面生成的每一条回答都有根。我当时在产品说明里写了一句很直白的话——它只会说你有的经历不会替你造经历。这句话成了后面所有设计决策的锚点。2. 产品工作流拆解一张画像怎么撑起一场面试模拟整个产品的运行流程听起来不复杂采集信息、建立画像、模拟问答、生成表达。但真正落地的时候每一步都有值得抠的细节。2.1 信息采集聊天式提问不是冷冰冰的表单第一步是让 AI 先了解你。我没有做成那种让人填写二十个字段的表单因为表单式采集有两个问题一是用户没有耐心填完二是简历里根本覆盖不到那些面试表达需要的关键信息。比如我问了这么几类问题你过往的项目里哪个是你自己认为最能打的当时你具体承担了哪个角色项目中有没有哪个问题是你查了好几天才解决的排查过程是怎么样的你平时说话是习惯先抛结论再展开还是喜欢铺垫背景你被问到没做过的东西时通常会怎么应对这些问题看起来很简单但每一个都是为后面的画像服务的。特别是沟通风格那一类问题当时很多人不理解觉得跟面试无关。可实际上让 AI 输出的回答像你自己靠的就是这些表达习惯的标签。一个人如果平时说话喜欢先结论后理由那 AI 输出的回答也得是这个结构否则就算内容是你的经历说出来也像别人的话。2.2 画像抽取把聊天记录变成结构化的 JSON用户在对话里说了那么多内容AI 不可能在每次生成回答时把所有原始记录都塞进上下文里既浪费 token又容易丢失重点。所以在采集结束后会用一次独立的调用来做画像抽取把零散对话整理成结构化 JSON。这一步是整个产品的核心枢纽。抽取出来的画像结构类似下面这样{ candidate_profile: { basic: { alias: B同学, position: 后端开发3年经验, target_role: 高级后端工程师 }, skills: { core: [Python, Go, MySQL, Redis, Kafka], secondary: [Docker, Kubernetes, Prometheus], gap: [高并发场景实战经验较少] }, projects: [ { name: 模拟项目X, role: 核心开发者, challenge: 系统在流量高峰期频繁出现数据库连接打满, actions: [ 排查发现连接池配置不合理, 引入读写分离并优化热点查询, 加了一层缓存降低读压力 ], result: 高峰期错误率从5%降到0.2%, voice_notes: 讲这个项目时习惯说排查过程不爱堆技术名词 } ], communication_style: { structure: 先结论后展开, pace: 偏慢但逻辑清楚, avoid: 不喜欢被追问到无法自圆其说的细节 }, career_goal: 希望三年内成长为能独立负责系统的工程师 } }有了这个结构后续每一次问答生成的时候只需要把这段 JSON 注入系统提示词里模型就有了你是谁、你做过什么、你怎么说话的完整上下文。画像可以存进数据库下次打开页面的时候直接读取不用每次重新聊一遍。2.3 问答生成把画像注入每一条回答问答生成阶段的技术细节主要是怎么把画像、当前问题和历史追问上下文串起来。实现上我做了两件事第一内置一个面试题库按技术深度、项目经历、行为面试、职业规划几个维度分类。用户可以选择目标岗位类型比如后端技术一面系统会从这个题库里抽题。第二生成回答时不是把问题孤零零地丢给模型而是把候选人画像 对话历史 当前题目一起发过去。这样模型生成的回答会始终贴着这个人的真实经历走而且因为带着过去的追问记录回答之间还能保持前后一致——面试官上一题问了项目背景这一题追问当时怎么监控的AI 就不会换个说法前后矛盾。整个工作流跑通之后产品的闭环就成立了你先花十分钟让 AI 认识你之后它能持续帮你把每一个问题都组织成你会说的话。3. 开发实录我是怎么用 AI 把需求聊成产品的这个项目的代码严格来说不是我一口气写出来的而是我用 AI 编程工具一步步聊出来的。我把这个过程完整记录下来是因为很多人习惯把 AI 当成自动写代码机实际上它更像个需要你明确交代需求、然后帮你快速落地的结对工程师。3.1 我给 AI 编程工具的第一版需求描述做项目之前我先花了几十分钟把产品逻辑想清楚然后把需求写成了一段结构化的描述直接丢给 AI 编程工具。那段需求描述大概长这样帮我做一个面试助手 Web 应用要求如下 1. 技术栈前端用原生 HTML Tailwind CDN后端用 Python FastAPI接口调用大模型 API。 2. 页面布局左侧是候选人信息区包含简历粘贴框、项目经历问答区、沟通风格自评三个 Tab右侧是面试模拟对话窗口。 3. 后端提供两个接口 - /api/profile把左侧填写的零散信息汇总成一份候选人画像 JSON - /api/ask接收当前面试问题结合候选人画像和历史对话生成个性化回答。 4. 生成回答时有硬性要求只允许使用画像中出现的事实信息禁止编造项目、技能或量化数据。 5. 回答要有明确的表达结构控制在 200 字以内风格口语化。 6. /api/ask 返回流式输出前端逐字显示。这一段需求里最重要的是第 4 条和第 6 条。防编造是产品底线流式输出是为了体验——面试模拟这种事你让用户干等三秒再看到一大段文字交互心理上是断裂的逐字显示反而更有对话感。AI 拿到需求后很快就搭出了一个能跑的初版后端 FastAPI 起了两个路由前端一个页面把两个区域排好接口通过流式响应把 token 推回前端。我实际跑了一遍发现有两个问题需要立刻改一是画像抽取逻辑太弱用户聊了一堆内容抽出来的画像只有三五个字段二是回答风格跟用户本人的表达方式几乎没关联。这些问题我在后面专门用了一整轮迭代去修会在第四节和第五节里展开说。3.2 让 AI 迭代功能和修 bug 的三种问法跟 AI 编程工具配合的过程中我总结出了三种非常管用的沟通方式。如果你也想用 AI 辅助开发类似产品可以参考。第一种是描述现象不给结论。比如我觉得回答太假我不会直接说你帮我加个防编造逻辑而是告诉 AI现在用户画像里没有某个量化数据但生成回答时模型自己脑补了一个 QPS 数值这种数据用户现场接不住得堵住。AI 听完之后给出的方案比我预设的还要细它会建议在系统提示词里加约束符号还会在输出里插入标记。第二种是给边界不给实现。比如我要求回答必须控制在口语表达范围内不用告诉它具体用哪种提示词写法而是把约束说清楚用户说话习惯是先抛结论再展开回答必须符合这个结构禁止使用综上所述这类书面连接词。第三种是拿真实案例锤它。每当翻车我就把那段有问题的回答原样贴给 AI让它对照画像分析哪里出了问题再重新设计规则。这种做法比抽象描述问题有效得多因为模型能从具体例句里反推出你的判断标准。4. 提示词工程实战把你自己铸进系统提示词整个产品里技术含金量最高的部分不在 Python 代码里而在系统提示词里。这个提示词决定了 AI 到底是一个答题机器人还是一个最了解你的陪练。4.1 系统提示词的三段式结构我给问答接口设计的系统提示词分了三段结构很固定你是一个面试陪练助手。你的任务不是替候选人回答问题而是基于候选人的真实经历组织出符合他口吻的表达。 候选人画像如下 {profile_json} 回答时必须遵守的规则 1. 只能使用画像中出现的事实信息不得编造任何项目、技能或量化数据。 2. 表达结构优先遵循画像中 communication_style 的标记。 3. 如果画像缺少回答所需的关键信息先在回答中输出【需要补充xxx】再给出完整的回答模板。 4. 回答控制在 120 字以内口语化表达优先使用短句。第一段是角色定义。关键在组织表达而不是替人回答这个措辞它从一开始就把模型的立场从我帮你解这道题扳到我帮你把话说顺上。第二段是画像注入把第三节里生成的 JSON 原样拼进去。第三段是约束规则每一条都是踩过坑之后加进去的。4.2 防编造机制宁可用占位符也不能现编防编造这版规则我是吃过亏才加的。最初版本没有第 3 条结果有一次测试用户画像里完全没有某个项目的性能数据模型却自动生成了一句经过优化系统 QPS 提升了三倍。这句话单独看不违和但用户本人根本不知道这个数字从哪来的面试现场被追问一句具体怎么测的就全完了。所以我加了一个非常硬性的设计不补充画像里不存在的事实缺信息就输出标记。如果某条回答需要项目指标、需要具体数字、需要技术细节但画像里没有AI 会先生成一句【需要补充这里可以说一下上线后的 QPS 数据】然后再给出完整的回答模板。这个机制后来还变成了产品的一个亮点——它不只是堵漏洞还能反过来提醒用户你看这段回答里还缺点数据面试官大概率会往这个方向追问你提前去把这个数字补上。也就是从帮你生成延伸到了帮你知道自己哪里还虚。4.3 口吻调优不是最好听的回答是最像你的回答防编造解决的是内容真实问题口吻调优解决的是表达真实问题。模型天生有一种倾向——它默认要把回答写得更完整、更书面、更高级。但现实生活中一个说话习惯先抛结论再展开的人如果 AI 给他生成一段首先、其次、最后层层递进的书面总结他看的时候觉得很好真到面试现场一开口自己都觉得别扭因为那不是他会说的话。这就是为什么画像里必须包含 communication_style 字段。我在提示词里专门有一句你的目标是生成候选人会真实说出的口语表达而不是最完美的书面总结。同时我把画像里的 voice_notes比如喜欢从排查思路切入不爱堆技术名词也注入进去这样每个项目的表达角度都能跟用户本人的习惯对齐。调优之后同样的题生成的回答从面对海量数据的处理需求我们从架构层面进行了深度优化……变成了当时主要卡在数据库连接被打满我先把慢查询捞出来看了一眼发现连接池配置太小……——后者才是人能背下来、能接得住、能被相信的话。5. 实测翻车现场三场失败推动的迭代开发过程中最值钱的不是我设计了什么而是我踩过的三个坑。这三个翻车现场基本上代表了面试助手类产品最典型的三类技术问题。5.1 翻车一满口书面语的高级感假人第一版测出来回答虽然内容用了画像里的项目信息但看着就是不像用户本人说的。问题你项目中最大的挑战是什么模型输出面对海量数据的处理需求我们从架构层面进行了深度优化通过引入分布式缓存、集群扩容与多级降级策略显著提升了系统的吞吐量与可用性……这段话没错但它的问题在于没有温度。用户实际跟我描述这个项目的时候说的是当时数据库连不上了大半夜被叫起来我先重启顶住第二天才查出来是连接池的问题。我要求的是像他说的话不是像教科书的话。修复方案有两步第一步在 communication_style 字段里补充用户的真实表达特征比如口语化程度高、习惯讲具体场景第二步在规则里增加一条禁止使用书面总结式的排比结构。从那之后生成的回答明显接地气了。5.2 翻车二画像空白时 AI 开始脑补数据这是最严重的一次翻车。用户只填了一个很简略的项目描述没有给出任何量化结果AI 在生成回答时自动补了一句性能提升了 40%。这是完全无法接受的因为面试官追问起来用户根本没法对上这个数据而且 40% 这个数字本身就是编的。修复过程前面已经提到过就是引入了【需要补充】占位符机制同时还加了一个事实检查的小功能每次生成完回答后系统会再调用一次模型专门检查回答里有没有出现画像之外的人物、项目名称、数字如果有就直接高亮出来让用户确认。这一步等于给 AI 的输出加了一道质检成本不高但非常有安全感。5.3 翻车三回答太长变成了即兴演讲模型给的回答普遍偏长动不动就三四百字这在书面阅读时觉得信息量很足但口语面试根本不是这么回事。面试官一个问题通常期望你回答 30 秒到 1 分钟撑死 150 字。你如果一口气说三分钟不是在展示深度是在消耗对方的耐心。我把回答上限调整到 120 字并强制要求如果内容超过三点只保留最重要的三点。还加了一条重要结论前置细节往后放。这个调整让生成出来的回答更接近真实对话场景——先给结论再补一句关键细节然后停下来等追问。三个翻车案例改造完之后系统提示词已经从头到尾换了一遍产品才算真正立住了。6. 这个东西到底有没有用一次模拟联调的真实反馈开发基本稳定之后我找了一位正在准备面试的朋友也就是前面画像里提到的B同学做了一次完整的模拟联调。6.1 对比测试从说不出到像自己的过程测试过程是这样的让 B 同学先花十几分钟把简历粘贴进来回答完采集阶段的问题然后选了一个后端技术二面的场景连续问了五个问题。我把他的临场发挥、通用 AI 直答和这个面试助手生成的回答放在一起做了个对比场景本人临场发挥通用 AI 直答面试助手画像回答项目中最有挑战的事流水账式复述没有主线正确但空泛没有个人痕迹从排查过程切入先说卡点再说解法口吻完全是 B 同学本人线上故障如何应对抓到什么修什么顺序混乱教科书式 SOP经不起追问按定位-止血-根因-复盘组织素材全部来自 B 同学真实经历为什么想换工作停顿很久回答笼统标准场话太假结合 B 同学真实职业规划有说服力而且他背得下来B 同学自己的反馈是它说得确实像我会说的话但我现场说不出来。这句话总结了这个产品的核心价值——不是替你创造内容而是把你自己已有的经历用你自己习惯的方式组织成完整表达。6.2 产品边界它不是作弊器是表达放大器当然这个产品有明显的边界我也在 README 里写得非常清楚面试助手不是用来在面试现场实时答题的作弊器而是一个面试前的陪练工具。它输出的所有回答都是基于用户主动填写的真实信息AI 负责的是结构组织和表达优化。如果用户自己什么都没填AI 除了给模板什么也做不了。真正把它当代答器用反而会出现另一个问题生成的回答你背得再熟只要不是你自己组织出来的面试官追问两三个为什么就能探到底。这个工具的定位从来不是帮你骗过面试官而是帮你把你已经有的东西充分倒出来。6.3 后续可以怎么玩这个项目的架构其实挺容易扩展。目前做完的部分是文字模拟问答后续我已经想好了几个方向接入语音合成和语音识别做成真正的模拟面试官语音对话场景根据每次问答的历史记录自动生成一份面试复盘报告标注出回答里哪些地方缺少数据、哪些地方逻辑跳脱把画像做成可长期积累的个人能力档案每做一次模拟就更新一次让 AI 越来越懂你。最后一个我做这个产品时最有感触的技术细节分享给你如果你也想搭类似的先了解再表达工具千万不要跳过画像抽取这一步。很多开发者图省事直接把所有聊天记录塞进上下文让模型现读但这会带来两个问题——上下文长度不可控而且模型的注意力会被大量无效信息干扰。把用户信息先提炼成一份干干净净的结构化画像再搭载到每一条生成的回答里这个先压缩再注入的模式才是稳定可控的做法。 
长河君 · 2026/10/14 5:53:35 · 阅读 1.2k AI面试助手设计实录：从候选人画像到个性化回答生成
我认识一个后端工程师代码能力真的不弱压测方案、线上问题排查、性能优化都能说得头头是道但连续碰了两家公司的面试都挂在二面。我陪他做过好几次模拟面试坐在他对面听着听着就发现问题根本不在技术深度而是他在回答的时候完全不会讲故事——被问到你怎么解决线上故障他能对着报错日志描述三分钟操作顺序却唯独没有说清楚我为什么这么排查和最后影响范围是怎么控制的。后来我用 AI 写了一个「面试助手」思路就一句话让 AI 先了解你再帮你把话讲出来。这不是让 AI 直接甩给我一份标准答案而是让它先通过聊天把你的真实经历、表达习惯、技术栈甚至性格特点都摸清楚再以你的身份、你的口吻、你经历过的项目帮你组织出你真正能在面试现场说出口的回答。这篇文章写给两类人一是想解决面试表达问题、但不想背标准答案的求职者二是对用 AI 做垂直产品感兴趣的开发者。我会把产品的设计思路、工作流拆解、开发过程、提示词工程的核心技巧以及几轮翻车迭代的经历都摊开来讲你不仅能看明白这个产品怎么做的还能照着思路去搭你自己的版本。1. 为什么了解你比帮你说话更重要面试回答的本质是匹配不是完美我最早做这个产品的时候第一反应也是做一个输入问题直接出答案的工具。市面上的 AI 面试工具基本都是这个路子——你选岗位、选问题类型它给你生成一篇结构完整、用词高级的回答。但我拿真实简历测了几轮之后发现这类答案有个致命的毛病它太标准了。面试官一天面十个人听到的回答都是同一个味道——遇到问题我先冷静分析然后拆解任务最后复盘总结。这些话确实是对的也确实没有任何信息量。关键在于面试官判断的不是这个回答对不对而是这个坐在我面前的人到底有没有做过他嘴里说的那些事。一旦进入追问环节比如你当时具体看了什么监控指标你做的这个优化上线之后 QPS 变成了多少通用答案瞬间就露馅了因为那些细节根本不在你的经历里。所以我推翻了第一版方案把产品的核心逻辑改成了先采集后生成。原因很简单面试问答本质上是一次信息匹配面试官手里拿着岗位需求清单他是在拿你的真实经历去逐条对照而不是在欣赏你说得多流畅。如果没有你亲身经历的锚点做支撑表达越完美越容易被当成背书。对比一下两种模式就能看得很清楚对比维度通用 AI 直接生成的回答基于候选人画像生成的回答信息来源模型训练时的通用经验候选人自己填写的真实经历追问抗性经不起追问细节对不上每个点都有实际经验支撑个人痕迹几乎没有换谁都能说口吻、用词、项目细节都像本人面试官感受背过题的应试感有思考痕迹的真实交流基于这个判断产品第一版就做了一个很强制的设计你打开页面之后不能直接问问题必须先完成一轮信息采集。这个流程确实劝退了一些急性子用户但它保证了后面生成的每一条回答都有根。我当时在产品说明里写了一句很直白的话——它只会说你有的经历不会替你造经历。这句话成了后面所有设计决策的锚点。2. 产品工作流拆解一张画像怎么撑起一场面试模拟整个产品的运行流程听起来不复杂采集信息、建立画像、模拟问答、生成表达。但真正落地的时候每一步都有值得抠的细节。2.1 信息采集聊天式提问不是冷冰冰的表单第一步是让 AI 先了解你。我没有做成那种让人填写二十个字段的表单因为表单式采集有两个问题一是用户没有耐心填完二是简历里根本覆盖不到那些面试表达需要的关键信息。比如我问了这么几类问题你过往的项目里哪个是你自己认为最能打的当时你具体承担了哪个角色项目中有没有哪个问题是你查了好几天才解决的排查过程是怎么样的你平时说话是习惯先抛结论再展开还是喜欢铺垫背景你被问到没做过的东西时通常会怎么应对这些问题看起来很简单但每一个都是为后面的画像服务的。特别是沟通风格那一类问题当时很多人不理解觉得跟面试无关。可实际上让 AI 输出的回答像你自己靠的就是这些表达习惯的标签。一个人如果平时说话喜欢先结论后理由那 AI 输出的回答也得是这个结构否则就算内容是你的经历说出来也像别人的话。2.2 画像抽取把聊天记录变成结构化的 JSON用户在对话里说了那么多内容AI 不可能在每次生成回答时把所有原始记录都塞进上下文里既浪费 token又容易丢失重点。所以在采集结束后会用一次独立的调用来做画像抽取把零散对话整理成结构化 JSON。这一步是整个产品的核心枢纽。抽取出来的画像结构类似下面这样{ candidate_profile: { basic: { alias: B同学, position: 后端开发3年经验, target_role: 高级后端工程师 }, skills: { core: [Python, Go, MySQL, Redis, Kafka], secondary: [Docker, Kubernetes, Prometheus], gap: [高并发场景实战经验较少] }, projects: [ { name: 模拟项目X, role: 核心开发者, challenge: 系统在流量高峰期频繁出现数据库连接打满, actions: [ 排查发现连接池配置不合理, 引入读写分离并优化热点查询, 加了一层缓存降低读压力 ], result: 高峰期错误率从5%降到0.2%, voice_notes: 讲这个项目时习惯说排查过程不爱堆技术名词 } ], communication_style: { structure: 先结论后展开, pace: 偏慢但逻辑清楚, avoid: 不喜欢被追问到无法自圆其说的细节 }, career_goal: 希望三年内成长为能独立负责系统的工程师 } }有了这个结构后续每一次问答生成的时候只需要把这段 JSON 注入系统提示词里模型就有了你是谁、你做过什么、你怎么说话的完整上下文。画像可以存进数据库下次打开页面的时候直接读取不用每次重新聊一遍。2.3 问答生成把画像注入每一条回答问答生成阶段的技术细节主要是怎么把画像、当前问题和历史追问上下文串起来。实现上我做了两件事第一内置一个面试题库按技术深度、项目经历、行为面试、职业规划几个维度分类。用户可以选择目标岗位类型比如后端技术一面系统会从这个题库里抽题。第二生成回答时不是把问题孤零零地丢给模型而是把候选人画像 对话历史 当前题目一起发过去。这样模型生成的回答会始终贴着这个人的真实经历走而且因为带着过去的追问记录回答之间还能保持前后一致——面试官上一题问了项目背景这一题追问当时怎么监控的AI 就不会换个说法前后矛盾。整个工作流跑通之后产品的闭环就成立了你先花十分钟让 AI 认识你之后它能持续帮你把每一个问题都组织成你会说的话。3. 开发实录我是怎么用 AI 把需求聊成产品的这个项目的代码严格来说不是我一口气写出来的而是我用 AI 编程工具一步步聊出来的。我把这个过程完整记录下来是因为很多人习惯把 AI 当成自动写代码机实际上它更像个需要你明确交代需求、然后帮你快速落地的结对工程师。3.1 我给 AI 编程工具的第一版需求描述做项目之前我先花了几十分钟把产品逻辑想清楚然后把需求写成了一段结构化的描述直接丢给 AI 编程工具。那段需求描述大概长这样帮我做一个面试助手 Web 应用要求如下 1. 技术栈前端用原生 HTML Tailwind CDN后端用 Python FastAPI接口调用大模型 API。 2. 页面布局左侧是候选人信息区包含简历粘贴框、项目经历问答区、沟通风格自评三个 Tab右侧是面试模拟对话窗口。 3. 后端提供两个接口 - /api/profile把左侧填写的零散信息汇总成一份候选人画像 JSON - /api/ask接收当前面试问题结合候选人画像和历史对话生成个性化回答。 4. 生成回答时有硬性要求只允许使用画像中出现的事实信息禁止编造项目、技能或量化数据。 5. 回答要有明确的表达结构控制在 200 字以内风格口语化。 6. /api/ask 返回流式输出前端逐字显示。这一段需求里最重要的是第 4 条和第 6 条。防编造是产品底线流式输出是为了体验——面试模拟这种事你让用户干等三秒再看到一大段文字交互心理上是断裂的逐字显示反而更有对话感。AI 拿到需求后很快就搭出了一个能跑的初版后端 FastAPI 起了两个路由前端一个页面把两个区域排好接口通过流式响应把 token 推回前端。我实际跑了一遍发现有两个问题需要立刻改一是画像抽取逻辑太弱用户聊了一堆内容抽出来的画像只有三五个字段二是回答风格跟用户本人的表达方式几乎没关联。这些问题我在后面专门用了一整轮迭代去修会在第四节和第五节里展开说。3.2 让 AI 迭代功能和修 bug 的三种问法跟 AI 编程工具配合的过程中我总结出了三种非常管用的沟通方式。如果你也想用 AI 辅助开发类似产品可以参考。第一种是描述现象不给结论。比如我觉得回答太假我不会直接说你帮我加个防编造逻辑而是告诉 AI现在用户画像里没有某个量化数据但生成回答时模型自己脑补了一个 QPS 数值这种数据用户现场接不住得堵住。AI 听完之后给出的方案比我预设的还要细它会建议在系统提示词里加约束符号还会在输出里插入标记。第二种是给边界不给实现。比如我要求回答必须控制在口语表达范围内不用告诉它具体用哪种提示词写法而是把约束说清楚用户说话习惯是先抛结论再展开回答必须符合这个结构禁止使用综上所述这类书面连接词。第三种是拿真实案例锤它。每当翻车我就把那段有问题的回答原样贴给 AI让它对照画像分析哪里出了问题再重新设计规则。这种做法比抽象描述问题有效得多因为模型能从具体例句里反推出你的判断标准。4. 提示词工程实战把你自己铸进系统提示词整个产品里技术含金量最高的部分不在 Python 代码里而在系统提示词里。这个提示词决定了 AI 到底是一个答题机器人还是一个最了解你的陪练。4.1 系统提示词的三段式结构我给问答接口设计的系统提示词分了三段结构很固定你是一个面试陪练助手。你的任务不是替候选人回答问题而是基于候选人的真实经历组织出符合他口吻的表达。 候选人画像如下 {profile_json} 回答时必须遵守的规则 1. 只能使用画像中出现的事实信息不得编造任何项目、技能或量化数据。 2. 表达结构优先遵循画像中 communication_style 的标记。 3. 如果画像缺少回答所需的关键信息先在回答中输出【需要补充xxx】再给出完整的回答模板。 4. 回答控制在 120 字以内口语化表达优先使用短句。第一段是角色定义。关键在组织表达而不是替人回答这个措辞它从一开始就把模型的立场从我帮你解这道题扳到我帮你把话说顺上。第二段是画像注入把第三节里生成的 JSON 原样拼进去。第三段是约束规则每一条都是踩过坑之后加进去的。4.2 防编造机制宁可用占位符也不能现编防编造这版规则我是吃过亏才加的。最初版本没有第 3 条结果有一次测试用户画像里完全没有某个项目的性能数据模型却自动生成了一句经过优化系统 QPS 提升了三倍。这句话单独看不违和但用户本人根本不知道这个数字从哪来的面试现场被追问一句具体怎么测的就全完了。所以我加了一个非常硬性的设计不补充画像里不存在的事实缺信息就输出标记。如果某条回答需要项目指标、需要具体数字、需要技术细节但画像里没有AI 会先生成一句【需要补充这里可以说一下上线后的 QPS 数据】然后再给出完整的回答模板。这个机制后来还变成了产品的一个亮点——它不只是堵漏洞还能反过来提醒用户你看这段回答里还缺点数据面试官大概率会往这个方向追问你提前去把这个数字补上。也就是从帮你生成延伸到了帮你知道自己哪里还虚。4.3 口吻调优不是最好听的回答是最像你的回答防编造解决的是内容真实问题口吻调优解决的是表达真实问题。模型天生有一种倾向——它默认要把回答写得更完整、更书面、更高级。但现实生活中一个说话习惯先抛结论再展开的人如果 AI 给他生成一段首先、其次、最后层层递进的书面总结他看的时候觉得很好真到面试现场一开口自己都觉得别扭因为那不是他会说的话。这就是为什么画像里必须包含 communication_style 字段。我在提示词里专门有一句你的目标是生成候选人会真实说出的口语表达而不是最完美的书面总结。同时我把画像里的 voice_notes比如喜欢从排查思路切入不爱堆技术名词也注入进去这样每个项目的表达角度都能跟用户本人的习惯对齐。调优之后同样的题生成的回答从面对海量数据的处理需求我们从架构层面进行了深度优化……变成了当时主要卡在数据库连接被打满我先把慢查询捞出来看了一眼发现连接池配置太小……——后者才是人能背下来、能接得住、能被相信的话。5. 实测翻车现场三场失败推动的迭代开发过程中最值钱的不是我设计了什么而是我踩过的三个坑。这三个翻车现场基本上代表了面试助手类产品最典型的三类技术问题。5.1 翻车一满口书面语的高级感假人第一版测出来回答虽然内容用了画像里的项目信息但看着就是不像用户本人说的。问题你项目中最大的挑战是什么模型输出面对海量数据的处理需求我们从架构层面进行了深度优化通过引入分布式缓存、集群扩容与多级降级策略显著提升了系统的吞吐量与可用性……这段话没错但它的问题在于没有温度。用户实际跟我描述这个项目的时候说的是当时数据库连不上了大半夜被叫起来我先重启顶住第二天才查出来是连接池的问题。我要求的是像他说的话不是像教科书的话。修复方案有两步第一步在 communication_style 字段里补充用户的真实表达特征比如口语化程度高、习惯讲具体场景第二步在规则里增加一条禁止使用书面总结式的排比结构。从那之后生成的回答明显接地气了。5.2 翻车二画像空白时 AI 开始脑补数据这是最严重的一次翻车。用户只填了一个很简略的项目描述没有给出任何量化结果AI 在生成回答时自动补了一句性能提升了 40%。这是完全无法接受的因为面试官追问起来用户根本没法对上这个数据而且 40% 这个数字本身就是编的。修复过程前面已经提到过就是引入了【需要补充】占位符机制同时还加了一个事实检查的小功能每次生成完回答后系统会再调用一次模型专门检查回答里有没有出现画像之外的人物、项目名称、数字如果有就直接高亮出来让用户确认。这一步等于给 AI 的输出加了一道质检成本不高但非常有安全感。5.3 翻车三回答太长变成了即兴演讲模型给的回答普遍偏长动不动就三四百字这在书面阅读时觉得信息量很足但口语面试根本不是这么回事。面试官一个问题通常期望你回答 30 秒到 1 分钟撑死 150 字。你如果一口气说三分钟不是在展示深度是在消耗对方的耐心。我把回答上限调整到 120 字并强制要求如果内容超过三点只保留最重要的三点。还加了一条重要结论前置细节往后放。这个调整让生成出来的回答更接近真实对话场景——先给结论再补一句关键细节然后停下来等追问。三个翻车案例改造完之后系统提示词已经从头到尾换了一遍产品才算真正立住了。6. 这个东西到底有没有用一次模拟联调的真实反馈开发基本稳定之后我找了一位正在准备面试的朋友也就是前面画像里提到的B同学做了一次完整的模拟联调。6.1 对比测试从说不出到像自己的过程测试过程是这样的让 B 同学先花十几分钟把简历粘贴进来回答完采集阶段的问题然后选了一个后端技术二面的场景连续问了五个问题。我把他的临场发挥、通用 AI 直答和这个面试助手生成的回答放在一起做了个对比场景本人临场发挥通用 AI 直答面试助手画像回答项目中最有挑战的事流水账式复述没有主线正确但空泛没有个人痕迹从排查过程切入先说卡点再说解法口吻完全是 B 同学本人线上故障如何应对抓到什么修什么顺序混乱教科书式 SOP经不起追问按定位-止血-根因-复盘组织素材全部来自 B 同学真实经历为什么想换工作停顿很久回答笼统标准场话太假结合 B 同学真实职业规划有说服力而且他背得下来B 同学自己的反馈是它说得确实像我会说的话但我现场说不出来。这句话总结了这个产品的核心价值——不是替你创造内容而是把你自己已有的经历用你自己习惯的方式组织成完整表达。6.2 产品边界它不是作弊器是表达放大器当然这个产品有明显的边界我也在 README 里写得非常清楚面试助手不是用来在面试现场实时答题的作弊器而是一个面试前的陪练工具。它输出的所有回答都是基于用户主动填写的真实信息AI 负责的是结构组织和表达优化。如果用户自己什么都没填AI 除了给模板什么也做不了。真正把它当代答器用反而会出现另一个问题生成的回答你背得再熟只要不是你自己组织出来的面试官追问两三个为什么就能探到底。这个工具的定位从来不是帮你骗过面试官而是帮你把你已经有的东西充分倒出来。6.3 后续可以怎么玩这个项目的架构其实挺容易扩展。目前做完的部分是文字模拟问答后续我已经想好了几个方向接入语音合成和语音识别做成真正的模拟面试官语音对话场景根据每次问答的历史记录自动生成一份面试复盘报告标注出回答里哪些地方缺少数据、哪些地方逻辑跳脱把画像做成可长期积累的个人能力档案每做一次模拟就更新一次让 AI 越来越懂你。最后一个我做这个产品时最有感触的技术细节分享给你如果你也想搭类似的先了解再表达工具千万不要跳过画像抽取这一步。很多开发者图省事直接把所有聊天记录塞进上下文让模型现读但这会带来两个问题——上下文长度不可控而且模型的注意力会被大量无效信息干扰。把用户信息先提炼成一份干干净净的结构化画像再搭载到每一条生成的回答里这个先压缩再注入的模式才是稳定可控的做法。