InterviewMate：如何在 AI 能力与产品可靠性之间做取舍

核心问题： 做 AI 面试产品时，真正困难的不是“AI 能不能完成这个功能”，而是判断哪些事情应该交给 AI，哪些地方必须保留稳定规则和产品控制。

项目背景

InterviewMate 是我自己提出的项目。最开始，我只是想解决一个很个人的问题：技术面试有很多高频知识点需要复习，但单纯背题很枯燥，我希望让 AI 通过提问来检验我是不是真的掌握了这些内容。

做到一半时，我意识到，这个过程本身已经很接近一次面试。于是产品从“AI 帮我背技术题”逐渐转向“围绕目标岗位做面试训练”。这个变化看起来只是定位调整，但真正往下做以后，我开始遇到一系列更像产品问题而不是技术问题的选择：题目到底应该相信题库还是相信 AI？评分不稳定时，是继续给模型补知识，还是收紧它的判断范围？用户觉得体验不像面试时，下一步还要不要继续优化模型？

这几个选择最后构成了 InterviewMate 最重要的产品逻辑。

产品判断一｜AI 可以补充题库，但不应该替代题库

如果用户输入一个岗位 JD，最直接的方案是让 AI 根据 JD 自动生成一套面试题。这个方案很简单，也最符合“AI 产品”的直觉，但我没有选择把整个组卷过程完全交给模型。

原因是，我不认为“能生成”就等于“值得练”。

我前期整理了约 200 道公开高频技术面试题，覆盖算法、前后端、系统设计、数据库、工程实践和 AI 等常见方向。它们数量有限，但最大的价值在于稳定：这些题来自长期反复出现的高频考点，至少能够形成一个比较可信的训练基线。

AI 生成的优势则在另一边。它更灵活，可以根据不同岗位补充长尾内容，也能覆盖固定题库里没有的组合。但它的问题是质量更不稳定，难度也更难控制，有些题“看起来像面试题”，却未必真的值得用户花时间练。

因此，我最后没有在“题库”和“AI 生成”之间二选一，而是让两者承担不同职责：题库负责稳定和可信，AI 负责补充长尾和岗位定制。默认情况下，一套题以题库为主，只保留少量 AI 生成题，同时允许用户自己调整组合方式。

JD 的作用也不是“预测这家公司一定会问什么”，而是帮助系统判断哪些技术方向更值得优先训练。InterviewMate 是面试准备工具，不是面试预测工具，这个边界我希望保持清楚。

这个决定让我形成了第一个很重要的判断：AI 不应该因为“可以生成”就自动替代已经有效的稳定内容。更合理的做法，是让模型去补传统方案解决不了的部分。

产品判断二｜评分不稳定时，问题不是“模型知道得不够多”

项目早期，我引入了 RAG，希望通过知识库让出题和评分更可靠。当时这个选择有很明确的逻辑：既然是技术面试产品，如果模型能看到经过筛选的高频题和参考内容，理论上应该比完全依赖模型自己的知识更稳。

我当时的假设其实很简单：给模型更多可靠知识，结果应该更可靠。

但实际做下来以后，我发现真正的问题不是“模型不知道答案”。技术面试涉及的大部分通用知识，本身已经在模型能力范围内。更影响评分体验的，是模型到底依据什么来评分。

第一版里，模型自由度很高。它既负责出题，也负责给分和解释，而且评分时还可能看到检索出来的相关内容。结果就是：反馈看起来很丰富，但不同情况下评分依据并不完全一致。有时模型甚至会受到“相关但不是当前题目”的材料干扰。

这时我才意识到，我一开始把问题定义错了。

真正需要解决的不是：

怎么让模型知道更多？

而是：

怎么让模型只按照当前这道题的明确标准来判断？

于是我把重点从“增加知识”转向“固定评分边界”。每道题都要有明确的参考标准，评分只围绕当前题目进行；反馈从自由发挥改成固定维度，包括回答是否准确、是否覆盖关键点、表达是否清晰。重要规则也不再只写在 Prompt 里，而是由系统层继续校验。

这一步之后，RAG 在评分里的重要性反而下降了。

不是因为 RAG 本身没有价值，而是因为实际验证后，我发现它没有解决这个产品真正的瓶颈。这个场景里，模型不缺基础技术知识；评分更需要的是唯一、明确、可追溯的依据。继续增加相关材料，反而可能增加干扰和维护成本。

所以我最后对 RAG 的判断变成了：

RAG 不是 AI 产品的默认答案。只有当外部知识确实构成能力瓶颈时，它才值得承担额外复杂度。

对 InterviewMate 来说，更重要的不是让模型知道更多，而是让它只看它应该看的信息。

这也是我在这个项目里形成的第二个产品判断：如果一个规则对产品结果真的重要，就不能只期待模型“记得遵守”。Prompt 可以表达要求，但产品流程必须负责保证要求真的被执行。

产品判断三｜当模型已经够用，下一步不一定还应该优化模型

在组卷和评分逐渐稳定以后，我邀请了 10+ 名朋友在我的电脑上短暂体验产品。我原本最想验证的是题目质量、评分是否合理，以及根据 JD 组卷有没有价值。

但用户最明显的反馈却不是这些，而是：

现在主要靠打字回答，不像真实面试。

这个反馈很简单，但它直接改变了我对下一步优先级的判断。

如果只从技术角度继续推进，我当然还可以继续优化很多东西：让 AI 出题更复杂、评分更细、知识库更丰富，甚至继续增加更复杂的 AI 流程。但这些能力再强，也解决不了一个更基础的问题——真实面试是说出来的，不是打出来的。

文字回答会给用户更多思考和修改时间，而真实面试要求的是临场组织语言、口头表达和即时反应。对一个面试训练产品来说，这种交互差异比再提升一点模型能力更直接地影响产品是否“像面试”。

因此，如果再给我三个月，我现在最优先做的不是继续优化模型，而是把回答方式从文字改成语音。摄像头和更完整的模拟环境可以再往后，因为当前最明显的体验瓶颈首先是输入方式。

这次反馈让我意识到：当核心技术能力已经够用时，继续优化模型不一定是收益最高的事情。产品优先级应该跟着当前最大的用户问题移动，而不是跟着最容易继续做的技术能力移动。

对 InterviewMate 来说，这也是一次很明显的转变：从“还能让 AI 多做什么”，转向“什么变化最能让用户更接近真实面试”。

从“AI 给分”到真正的训练闭环

这几个产品决策做完以后，我对 InterviewMate 的核心价值也发生了变化。

最开始我以为，最重要的是“能不能根据 JD 出一套更好的题”。后来我越来越觉得，真正有价值的不是一次出题，而是一个连续训练过程：

根据岗位组卷 → 用户回答 → 找到薄弱点 → 调整下一轮训练 → 再练

因此，评分不能只停在一个分数上。它还应该告诉用户哪些知识点掌握不足、下一步该补什么，并让这些结果影响之后的题目和学习计划。

这让我开始把 AI 输出看成产品流程中的中间结果，而不是最终结果。如果用户答完题，AI 给一个分数，然后流程就结束，那么它更像一个自动批改器。只有当这次结果能够改变下一步训练，产品才真正形成学习闭环。

如果现在重新定义 MVP

如果今天重新做 InterviewMate，我会把 MVP 收缩到三个核心能力。

第一是组卷。重点不是每次都让 AI 生成新题，而是根据岗位和用户当前状态，选出一套值得练的问题。

第二是评分与答案改进。用户需要知道自己漏了什么、哪里表达不清，以及怎样在原回答基础上说得更完整。

第三是学习计划。一次评分不能结束在一个数字上，而应该继续影响下一轮训练。

相比之下，我不会再把 RAG 当成核心卖点，也不会因为这是一个 AI 产品，就要求每个环节都必须由 AI 完成。对我来说，真正重要的是整个训练流程是否有效，而不是模型参与了多少步骤。

如果产品真正上线，我最关心的也不会只是调用量。更重要的是：用户有没有完成训练、同一难度下表现有没有变好、薄弱知识点有没有逐渐改善，以及 AI 输出是否足够稳定、成本是否可控。

项目反思

InterviewMate 最能体现我的，不是我用了多少 AI 技术，而是我在几个关键节点上不断重新判断：现在真正限制产品效果的，到底是什么？

一开始，我以为产品需要更多灵活题目，于是加入 AI 生成；后来发现稳定题库仍然有不可替代的价值，于是把 AI 放在补充位置。我也曾认为评分不稳定可能是模型知识不足，因此引入 RAG；但实际验证后才发现，真正的问题是评分依据不够收敛，于是把重点从“更多知识”转成“更清晰的边界”。

等到模型和评分流程逐渐稳定以后，我原本仍然可以继续优化技术，但用户反馈让我看到，当前最大的体验问题已经变成“打字不像面试”。所以接下来的资源应该优先投入语音，而不是继续堆 AI 能力。

这几个选择让我逐渐形成了一套更明确的 AI 产品判断方式：先判断当前真正的产品瓶颈，再决定 AI 是否值得继续介入。

很多时候，答案并不是加更多 Prompt、更多知识库、换更大的模型，或者继续增加 AI 功能。更好的方案可能是减少模型自由度、保留传统稳定内容、调整用户流程，甚至干脆不用 AI。

最终核心收获

InterviewMate 最后留给我的两个判断很简单。

AI 产品的价值，不是模型参与得越多越好，而是产品能不能判断哪些事情适合交给模型，哪些事情必须保留稳定控制。

以及：

技术方案应该服务于当前最大的产品问题，而不是因为某项技术可用，就一定要把它放进产品。

对我来说，这也是 InterviewMate 从一个“会调用大模型的项目”变成真正产品实践的分界线。