企业官网建设流程全解析

本文按当前追问规则实现整理。规则结果是代码路径，不代表我已经在线上观测过每一种降级分支。

模型说要追问，系统就一定追吗？

不一定。模型评估结果里有follow_up_needed，但它只是规则输入之一。追问次数是否超限、当前题是不是已经是追问、是否完成，以及低分和遗漏要点，都会影响最终决定。把 AI 字段直接当作流程命令，会让业务规则藏进 Prompt。

从答题流水线走到 LiteFlow

InterviewAnswerPipeline完成答案评估后会组装InterviewFollowUpRuleContext，包含题号、是否追问题、追问次数上限、分数、AI 建议和遗漏要点，再交给InterviewFollowUpRuleService。服务装载默认 chain、版本、分数阈值和最大次数，然后执行default_followup_chain。

当前链顺序是：加载上下文、检查已完成状态、追问次数守卫、AI 建议判断、低分判断、遗漏要点判断，最后汇总决策。满足任一追问条件后，后续节点通过上下文保留决定及原因；最终结果带有 reason code、chain id、规则版本和 fallback 标志，便于排查为什么触发。

评估结果 -> RuleContext -> LiteFlow 节点链 -> FollowUpDecision -> 追问生成 / 主问题推进

失败时的退路也会改变语义

规则引擎配置了fail-open。LiteFlow 执行失败时，服务会退回旧策略：只有 AI 建议追问且未达上限才追问；不会把链里的低分、遗漏要点判断原样再跑一遍。换言之，降级不是“同一规则换一种方式执行”，而是一个更窄的策略。

我会在日志里同时看reasonCode、ruleVersion和fallback。仅看前端是否出现追问，不足以确认这次采用了哪套决策逻辑。规则变更也应更新版本并覆盖正常、达到上限、引擎失败等用例。

我的复盘

把模型输出当建议、由确定性节点做最终裁决，是更可控的边界；代价是规则链配置、上下文字段和 fallback 策略都要维护。尤其 fail-open，必须把“降级后少了哪些判断”讲清楚，否则系统可用性提高了，行为却悄悄变了。

源码入口

• admin/src/main/java/com/hewei/hzyjy/xunzhi/interview/flow/answer/InterviewAnswerPipeline.java
• admin/src/main/java/com/hewei/hzyjy/xunzhi/interview/application/rule/InterviewFollowUpRuleService.java
• admin/src/main/resources/liteflow/interview-followup-chain.xml
• admin/src/main/resources/interview-followup-rule.yaml