企业官网建设流程全解析

“面试前背了三天稿，结果考官问的问题一个都没押中”——这是我做这个项目最原始的出发点。市面上教面试的课、面经、题库多到看不完，但真正到了现场，脑子照样一片空白。问题出在哪？不是你不会，而是你从来没被“以你自己的经历为基础”训练过怎么开口。所以我用 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 应用开发最大的乐趣，是先拿一个小场景验证它到底能不能帮上忙。