模拟面试智能体总评报告上线前必过三道护栏，防泄题、防夸大、防错建议

当模拟面试智能体完成一场完整问答后，系统终于能生成一份包含总分、等级与建议的复盘报告——但开发团队很快意识到：这份报告尚不能直接发给候选人。问题并非出在内容质量，而在于风险控制：报告可能无意中泄露题库答案、评分与结论相互矛盾、或给出空洞甚至自相矛盾的改进建议。第8篇实战开发聚焦于最后一道关键工序：在报告输出前设置三道确定性护栏，确保其既专业又安全。

此前的第7篇已实现“答一题、评一题”的结构化输出，每道题生成包含分数（0–100）、等级（优秀/良好/合格/待提升）、亮点、短板与建议的QuestionReview对象，并聚合为总评。这一设计使数据可落库、可追溯、可驱动后续UI展示，但尚未解决“报告能否对外发布”的核心问题。

真正的挑战来自模型的非确定性行为。尽管提示词严格限定模型“仅依据参考答案判分”，但参考答案文本仍存在于上下文之中，模型在生成点评时极易无意识复述关键词。例如，针对“Redis AOF重写触发机制”一题，模型可能直接写出“正确答案是先触发auto-aof-rewrite-percentage阈值……”，这等于向候选人明示标准答案，导致题库失效。因此，防泄题成为第一优先级。

第二类问题是语义与数值的脱节。模型并非算术引擎，它可能给出50分却标注“优秀”，或总分72分却推荐“强烈录用”。这种不一致源于模型对阈值边界的模糊记忆，高频出现在实际调用中。若放任此类报告流出，将严重损害评估公信力。

第三类问题涉及数据完整性与逻辑自洽。某题建议字段为空、总评推荐却包含不及格项——这类矛盾会让候选人无所适从，也使复盘失去指导价值。人工复核难以覆盖全量场景，必须通过自动化规则提前拦截。

第一道闸：防泄题（anti-leak）

通过预定义禁用词表（如LEAK_TOKENS），对报告全文进行字符串扫描。任何包含参考答案原文片段（如“正确答案是”“标准流程为”等引导性短语）的内容均被拦截或替换。该规则独立于模型输出路径，确保即使模型“发挥失常”，也不会让敏感信息进入最终报告。

第二道闸：防夸大（anti-inflation）

强制分数与等级、推荐结论对齐。系统内置查表函数level_of(score)与recommendation_of(total_score)，无论模型在原始输出中如何描述，最终等级与推荐均由代码根据分数映射得出。例如，50分对应“待提升”，72分对应“推荐”，杜绝“高分低评”或“低分高推”现象。

第三道闸：防错建议（anti-bad-advice）

校验建议字段非空性与逻辑一致性。具体包括：① 单题advice不能为空；② 总评中的“推荐结论”若为“推荐”或“强烈推荐”，则所有子题得分不得低于阈值（如40分封顶）；③ 亮点与短板列表长度需符合约定（通常2–3条）。一旦触发异常，系统生成告警清单而非静默修正，便于运维介入。

这三道护栏的设计哲学延续了前几篇的核心原则：“便宜确定的交给算术，语言加工交给模型”。护栏本身无需理解语义，只需执行比对、查表与校验——这类任务用模型处理反而成本高、不可测、易出错。更重要的是，护栏必须支持离线全量测试：26个单元测试覆盖边界场景，可在无API Key环境下一键跑通，确保每次发布前100%绿灯。

工程结构上，系统采用清晰的两层分离：report.py负责将结构化数据渲染为Markdown或纯文本格式；guardrails.py则作为前置过滤器，接收原始Evaluation对象，输出修正版或报错信息。二者通过统一的pydantic模型（QuestionReview/Evaluation）对接，与第7篇的rubric.py完全兼容，避免重复定义阈值。

报告最终形态支持两种输出路径：纯文本用于IM或邮件直发，Markdown版本适配知识库（如语雀、飞书文档）或鸿蒙端前端组件。关键设计是“答案不进渲染层”——所有敏感字段在guardrails阶段已被剥离，渲染器仅处理公开字段（分数、等级、亮点、短板、建议、总结），从根本上切断泄题路径。

这套机制的意义不仅在于规避风险，更在于确立人机协作的边界。模型擅长生成自然语言反馈，但不适合担任“质检员”角色。让确定性规则守好最后一关，既保障了交付物的可靠性，也降低了系统整体复杂度。在招聘技术日益自动化的背景下，评估环节的严谨性正成为AI工具能否落地的关键瓶颈。一个连报告都不敢发给候选人的系统，再流畅的对话也无法建立信任。

目前该方案已在内部灰度验证中，覆盖Redis、MySQL、操作系统等12类技术题库。后续迭代将扩展至多轮追问场景下的动态评分校准，以及候选人自主查看历史报告时的权限分级控制。但无论如何演进，“报告可交付”这一底线，始终由三道不动如山的确定性护栏守护。