企业官网建设流程全解析

如果你用过 AI 模拟面试，大概都遇到过这样的情况：答得不完整时，面试官不会直接打低分，而是再追问一两句深挖一下。这个"要不要追问、最多追几次"的决策，背后不能只靠大模型"随口一说"——它需要一套确定性的规则来裁决。

AI-Meeting是一个基于 Spring Boot 3 + Java 17 的 AI 面试平台，除了 AI 对话、语音转写，最有意思的模块就是 AI 模拟面试。它用LiteFlow 规则链把"是否追问"拆成了 7 个职责单一的小节点，串成一条可配置、可观测、失败可兜底的裁决流水线。本文用通俗的方式带你把这条链走一遍。

先看效果：追问是怎么发生的

在 AI-Meeting 的面试流程里，你回答完一题后，系统会先让"答案评分官"工作流打分，再决定三件事：

1. 要不要追问（比如答案漏了关键点、得分太低）；
2. 还能不能追问（每个主问题默认最多追问 2 次）；
3. 追问问什么（由"面试提问官"工作流生成针对性的追问）。

第 1、2 件事就是规则链裁决的范围。裁决完成后，追问问题会被缓存并以1-F1、1-F2这样的编号挂到主问题下面（见 InterviewFollowUpService.java 中的resolveMainQuestionNumber和buildFollowUpQuestionNumber方法），最后呈现在结果复盘中。

规则链从哪里被触发？

裁决的入口在答题流水线 InterviewAnswerPipeline.java 的stepAdvanceFlowAndAssemble步骤里：

• 评分工作流返回结构化结果后，解析出score（得分）、follow_up_needed（AI 建议追问）、missing_points（缺失要点）、follow_up_question（追问提示）等字段；
• decideFollowUp把这些信息装进一个规则上下文InterviewFollowUpRuleContext.java，包含会话 ID、当前题号、已追问次数、得分、是否已结束等；
• 然后调用 InterviewFollowUpRuleService.java 的decide方法，交给 LiteFlow 执行规则链，拿回一个带原因码的裁决结果。

一句话：AI 负责"给建议"，规则链负责"拍板"。

配置先行：一条 YAML 管好所有参数

规则引擎的全部参数集中在 interview-followup-rule.yaml，对应配置类 InterviewRuleEngineConfiguration.java：

而规则链本身定义在一个 5 行的 XML 文件里——liteflow/interview-followup-chain.xml：

<chain name="default_followup_chain"> THEN(loadFollowUpContext, completedStateGuard, followUpLimitGuard, aiSuggestionJudge, lowScoreJudge, missingPointsJudge, followUpDecisionFinalize); </chain>

THEN(...)表示 7 个节点严格串行执行，任何节点都可以"提前终止"整条链。

7 个节点逐个拆解

所有节点代码都在 application/rule/node/ 目录下，每个节点只干一件事：

1️⃣ loadFollowUpContext —— 参数兜底

LoadFollowUpContextNode.java 把"最多追问几次"解析成一个确定的值（缺省时取配置默认值 2），保证后续节点拿到的一定是合法数字。

2️⃣ completedStateGuard —— 结束守卫

CompletedStateGuardNode.java：如果面试已经结束（最后一题答完），直接标记不追问，原因码INTERVIEW_COMPLETED。防止"面试都收尾了还补刀"。

3️⃣ followUpLimitGuard —— 次数上限

FollowUpLimitGuardNode.java：已追问次数 ≥ 上限时，直接标记不追问，原因码FOLLOW_UP_LIMIT_REACHED。这是"深挖但不纠缠"的关键护栏。

4️⃣ aiSuggestionJudge —— AI 建议采纳

AiSuggestionJudgeNode.java：评分工作流说"这答案值得追问"（follow_up_needed=true）时，标记需要追问，原因码AI_SUGGESTED。注意它只是"投赞成票"，最终仍要过后面所有守卫。

5️⃣ lowScoreJudge —— 低分触发

LowScoreJudgeNode.java：得分低于阈值（默认 60）时，同样标记需要追问，原因码LOW_SCORE。答得差 = 多给一次解释机会。

6️⃣ missingPointsJudge —— 缺失要点触发

MissingPointsJudgeNode.java：只要答案存在"缺失要点"或评分器给出了追问提示，就标记需要追问，原因码MISSING_POINTS。比如你谈项目只说了技术栈没说难点，这里就会被捕获。

7️⃣ followUpDecisionFinalize —— 收口

FollowUpDecisionFinalizeNode.java 调用 InterviewFollowUpRuleContext.java 的finalizeDecision：如果前面没有任何规则命中，兜底记为NO_RULE_TRIGGER（不追问），并把链 ID、规则版本、最终次数上限写入裁决结果。

裁决之后发生了什么？

裁决结果回到流水线后（InterviewAnswerPipeline.java）：

• 需要追问→ 调用 InterviewFollowUpService.java 生成追问。它会带上前文、简历上下文和mode=FOLLOW_UP参数调用"面试提问官"工作流；如果工作流挂了，就降级使用评分器给出的追问提示，保证流程不断。
• 不需要追问→ 直接推进到下一道主问题，并把评分计入总分。
• 每一步决策都会打日志，带上chainId、reasonCode、ruleVersion、fallback等字段（InterviewAnswerPipeline.java），线上排查"为什么这里没追问"时一眼就能定位。

为什么这样设计比"让 AI 直接决定"更稳？

这套追问裁决链的思路，其实很适合任何做 LLM 应用的团队借鉴：

• 决策可解释：每个"追问/不追问"都有原因码（AI_SUGGESTED/LOW_SCORE/MISSING_POINTS/FOLLOW_UP_LIMIT_REACHED/INTERVIEW_COMPLETED），不是玄学；
• 护栏与智能分离：AI 只负责打分和给建议，次数上限、面试结束等硬性约束由确定性节点保证，模型"失言"也不影响流程正确性；
• 失败可兜底：fail-open=true时，LiteFlow 执行异常会回退到旧策略（AI 建议追问且未超限则追问，见 InterviewFollowUpRuleService.java 的fallbackDecision），规则引擎自身故障不会阻断面试；
• 规则即配置：调阈值、换链、加节点，只需改 YAML/XML 和 node 目录 下的类，行为可测试——单测见 InterviewFollowUpRuleServiceTest.java。

总结：一张图记住追问裁决链

评分工作流产出 → 装填规则上下文 → LiteFlow 规则链（守卫 → 判官 → 收口） → 需要追问？→ 生成追问（工作流 + 降级兜底）→ 缓存并推进流程 → 不需要追问？→ 推进下一题 → 计分

核心要点回顾：

1. LiteFlow 规则链把"是否追问"变成一条 7 节点的串行流水线，节点间通过共享上下文传递结论，任一守卫节点可提前终止；
2. 追问上限 2 次、低分阈值 60等参数全部收敛在一份 YAML 中，改配置即可调策略；
3. fail-open 兜底 + 原因码日志让这套裁决机制在线上既敢用又查得到；
4. 想让 AI 面试"深挖但不纠缠"，关键就是这套确定性规则约束非确定性模型的设计。

想动手看细节的话，从 interview-followup-chain.xml 的 5 行 XML 读起，再顺着 rule 目录 把 7 个节点过一遍，二十分钟就能吃透整条链。项目内的领域说明文档 scoring-followup-rules.md 也值得对照阅读。