FEMentor 最初的面试流程接近一份会自动评分的题单：启动会话时生成问题，用户依次回答，结束后统一复盘。它可以跑通流程，却不像真实面试，因为问题之间缺少联系。

从一次生成到运行时决策

第一轮调整保留了“主问题预先生成”的稳定性，只在回答暴露薄弱点时插入追问。早期规则很直接：分数低于阈值或存在明显弱点、当前题不是追问题、同一主问题尚未追问，才允许插入一道题。

这个限制很重要。没有上限的动态生成会让面试无法预测长度，也容易围绕同一个问题反复追问。

随着流程继续迭代，作答记录增加 question_id，题库增加来源字段。追问题不再只是一个字符串，而是带着这些关系进入系统：

  • 它追问的是哪一道主问题；
  • 来源是基础题、项目题、面经题还是模型生成；
  • 它要澄清、深入、比较、验证还是进入场景题；
  • 回答后暴露了哪些知识边界。

弱点与知识边界不是一回事

评分中的 weaknesses 适合描述表达结构、技术深度或证据不足，但不一定能直接决定下一道技术追问。

后续评分结果增加了 knowledge_boundary：

{
  "mentioned_but_shallow": [],
  "conspicuously_absent": []
}

前者表示候选人提到了但没有展开的点，后者表示在当前问题中明显缺失的关联知识。追问决策因此从“分数低就再问一道”变成“沿着回答中暴露的边界继续确认”。

动态不等于完全交给模型

这套流程最终形成三层约束：

  1. 队列控制面试总长度和主问题覆盖；
  2. 规则判断是否允许追问；
  3. LLM 负责理解回答并生成或改写具体问题。

真正困难的不是让模型生成一句追问，而是让追问在产品流程中可控、可解释、可回溯。只有这三点成立，动态追问才是面试编排能力，而不是随机对话。