求职过程中发现市面上的面试辅导工具不够"懂自己"，于是用 DeepSeek API + React 做了一个 AI 面试训练工具。这篇文章记录从挖掘需求到交付成品的完整产品思考过程。

一、AI PM 求职者的共性痛点

今年 AI 产品经理岗位集中爆发，但供需两端的错配也很明显。我在这轮求职中访谈了十几位同行，加上自己的面试经历，提炼出四个被反复提及的痛点：

这些痛点不是某个人的问题，而是AI PM 这个新兴岗位在行业标准成型期出现的结构性摩擦。JD 和实际面试内容不一致、候选人不知道如何展示跨界能力、面试官追问的方向难以预测——每个人都或多或少会遇到。

于是我决定做一个工具，解决”AI PM 面试训练”这件事。

二、产品定义：不做什么比做什么更重要

2.1 目标用户

正在求职的 AI 产品经理。无论是有经验在看的，还是从互联网 PM 转 AI 方向的，还是 Gap 期在准备面试的——只要你需要在面试中讲清楚你的项目，就是这个工具的目标用户。

2.2 三个设计原则

原则一：不是题库，是对话引擎

市面上已有大量面试题库产品，但刷题解决不了”说不清楚”的问题。这个工具的核心价值不是题目本身，而是听懂你说了什么、判断你是否真正回答了问题——这对 AI 来说是最难也最重要的能力。

原则二：严苛型反馈，而非鼓励型

求职者对敷衍的”很好”早已免疫。有效的训练需要直接、具体的批评。哪里逻辑断了、哪个词用得不好、怎么改——这种反馈才真正有价值。

原则三：帮助建立边界感，不只是练表达

应用层 AI PM 不需要回答模型训推、PyTorch 实现细节等问题。工具要能帮用户识别——”这类问题越界了，不是你该答的方向”，而不是让候选人在不擅长的问题上硬撑。

2.3 功能边界

• 做：模拟面试对话、每题即时反馈、语音输入、个人档案记忆、进度追踪
• 不做：多用户系统、云端存储、固定题库、视频面试
• 技术约束：纯前端 + API 调用，零服务器成本，数据全存用户本地浏览器

三、五个核心功能模块

3.1 四种面试模式，覆盖真实场景

不同角色的面试官关注点完全不同。把面试拆成四种典型场景，每种配独立的 AI 人设和追问策略：

此外支持「自定义 JD」模式——粘贴目标岗位的职位描述，AI 自动生成针对该岗位的面试题。这意味着任何人的任何岗位都可以练。

3.2 个人档案系统：让 AI 认识你

这是区别于通用 AI 聊天工具的核心设计。每位用户有一个可编辑的「个人档案」面板，结构化填入自己的信息：

档案字段（全部可编辑）

基本信息 · 教育背景 · 工作经历 · 项目详情（含数据）· 技能工具栈 · 求职筛选标准 · 已知薄弱点 · 薪资预期 · 自定义备注

档案内容自动注入每场面试的 system prompt。AI 面试官从一开始就”认识你”——知道你的项目、你的数据、你的薄弱点。不用每场面试重新交代一遍背景。所有数据存储在浏览器本地（localStorage），不上传任何服务器。

3.3 每题即时反馈（核心设计决策）

这个功能踩过坑，值得展开讲。第一版是”面试 5-8 轮 → 一次性复盘”——用户回答完所有问题后，AI 统一给分和点评。测试后发现两个致命缺陷：

1. 对话越长，复盘质量越差。30 分钟对话传入 DeepSeek，模型在超长文本中出现注意力衰减，甚至误判为”候选人未回答任何问题”。
2. 反馈延迟 = 错误固化。等到最后才知道问题在哪，前面的错误模式已经重复了好几轮。

第二版重构为「每答一题，即时反馈」：

✅ 好的 你用项目的具体数据（82% 完成率）来支撑论点，先结论后展开，逻辑清晰。

❌ 改善 第三轮追问时你绕开了核心问题——面试官问你为什么选 5 象限而不是 3 象限，你说了一分钟但始终没正面回答。

建议 直接说：”我选 5 象限是数据驱动决策——Life 和 Work 场景的问题结构完全不同，混在一起模型输出噪音。Decision 和 Reflect 的底层逻辑也不一样。”

绿色肯定正确方向、红色指出具体问题、蓝色给出改进示范。5 轮全部结束后给出总分 + 一句话总结 + 最需改进的一个点。

3.4 语音通话模式

面试最终是说话。打字练和开口说是两回事。基于浏览器原生 Web Speech API 实现了连续语音对话：

• 说话时实时转文字上屏
• 3 秒静默自动发送（保留思考停顿，不会因为你停下来想就截断）
• AI 回复通过 TTS 语音朗读
• 全程免提，像打电话一样，做家务、通勤时都能练

支持 Chrome 和 Safari（Safari 需要 HTTPS，部署后自带）。

3.5 进度追踪

每次练习自动记录：面试模式、轮数、总分、薄弱点标签。历史页面展示练习次数趋势、平均分数、反复出现的高频薄弱点——帮用户定位自己真正的短板。

四、技术实现

架构极简：纯前端静态页面 + API 调用。没有数据库、没有后端服务、没有用户系统。整个项目约 2,000 行代码，28 个文件。

五、踩过的四个坑

1. 长对话复盘不可靠。单次 API 调用传入超长文本时，DeepSeek 的注意力衰减严重。30 分钟对话的复盘准确率断崖下降。解决方案是把”事后一次性复盘”改为”每题即时反馈”，单次处理文本长度大幅缩短，准确率显著提升。
2. Safari 语音需要 HTTPS。Web Speech API 在 Safari 上要求安全上下文（HTTPS 或 localhost）。本地开发用 @vitejs/plugin-basic-ssl 生成自签名证书，生产环境 GitHub Pages 自带 HTTPS 自动解决。
3. 每轮对话必须追加明确指令。仅靠 system prompt 不够。实际测试中发现，非最后一轮如果没有追加”请先给反馈，再问下一题”的用户消息，AI 会退化为只提问不点评。改为每轮动态构造指令后问题消失。
4. localStorage 配额静默失败。长时间对话导致 localStorage.setItem 超出配额时会静默失败，面试记录丢失。全部写操作加了 try-catch，异常时提醒用户清理历史记录。

六、产品数据

• 开发周期：3 天（初始化 → 上线）
• 代码量：约 2，000 行，28 个文件
• 单场面试成本：DeepSeek Chat API，5 轮约 6，000-8，000 tokens，约 ¥0.03-0.05
• 部署：GitHub Pages 静态托管
• 隐私：零数据采集，所有个人信息仅存用户本地浏览器

七、后续计划

这个工具从需求到上线花了 3 天，目前仍在迭代中。如果你也在求职 AI 产品经理，希望能从这篇文章里获得一些产品思路上的启发。