AI 面试系统实施研究报告

1. 执行摘要

【建议】AI 面试首先是一条业务闭环，不是一个“会问答的模型”。 它从候选人材料和岗位要求出发，把岗位拆成可观察的能力，把能力映射为有依据的题目，再通过语音、文本或代码收集证据。系统随后按预先发布的评分标尺解释证据，生成带出处、覆盖范围和不确定性的反馈。用户纠错、人工复核、申诉和线上质量数据又回到题库、评分标尺和发布流程，推动下一版改进。只有材料、能力、题目、对话、证据、评分、反馈和复盘首尾相接，产品才是可管理系统；只让模型自然地问几句话，只能证明一次演示能进行。

这条闭环直接决定产品能否经营。材料必须说明来源，题目必须说明为什么被选中，追问必须受轮次和范围约束，分数必须指向回答或测试结果，技术故障必须与能力不足分开，旧报告必须能还原当时使用的题库、模型和规则。这样，团队才能回答三个基本问题：这次结果依据什么；如果错了，影响到谁；修复后怎样恢复而不改写历史。第一版因此应先交付“可重复、可解释、出错后可恢复的练习与反馈链路”，再逐步增加语音、检索、代码执行和更高风险用途。

【事实】 DeepInterview 是以实时语音为主要交互方式的模拟面试系统。固定源码覆盖网页体验、简历与职位描述解析、公司信息检索、问题规划、实时对话、逐字稿、结构化评分、报告和数据保存，并非单纯的界面样机；但真实媒体、语音识别与合成、模型、完整知识检索、云端数据库和对象存储并未在本次审计中完成端到端运行。报告页在若干尚未就绪的状态使用样例评分卡，所以页面可显示不能证明真实面试评分成功（DeepInterview 审计，报告页源码）。

【事实】 GrillKit 是单用户、本地优先的技术面试训练器。固定源码覆盖理论题、编码题、组合会话、计时、最多两轮追问、结构化 AI 评价、本地数据库、离线语音和可选的隔离代码执行。它定义了候选人可见的公开测试、仅服务端可见的隐藏测试及相应执行流程；但固定题库中 44/44 道编码题均为 AI 模式，测试执行模式、公开测试和隐藏测试的数量都为 0。因此项目说明中的“运行公开测试、提交后运行隐藏测试”是能力描述，不是当前题库已验证的体验（GrillKit 审计，task spec，run tests）。

【建议】 第一版应定位为候选人自主练习与形成性反馈工具，而非自动录用、淘汰、排名或远程监考系统。应组合 DeepInterview 的上下文准备和语音闭环，与 GrillKit 的确定性状态机、题目快照和代码执行边界；不应照搬两者的默认信任网络、未校准模型分数或不完整数据治理。招聘评估必须作为独立高风险产品线重新完成岗位效度、法律审查、公平性校准、人工复核和申诉机制。产品明确排除真实面试中的隐蔽监听、实时提词、代答、伪造身份和规避监考。

A. 一场 AI 面试如何真正完成

结论：一场面试真正完成，不是页面出现“已结束”，而是每个结论都能沿着材料、计划、回答和评分一路查回去。 以下用一个贯穿案例解释建议流程。人物、岗位、回答和数值均为示例，不代表两个参考项目已经实现或达到相同质量；引用的工程切片则来自固定源码与两份审计。

候选人林晨申请“中级后端工程师”。他的简历（CV）写到自己负责过订单服务，使用消息队列处理异步任务；职位描述（JD）要求能够设计高并发服务、排查线上故障，并解释数据一致性的取舍。系统不应从这两份材料直接跳到“给林晨打分”。CV 是候选人的自述，JD 是岗位要求，两者都不是已经证明的能力。系统要先把它们变成一份可检查、可冻结的面试计划。

B. 为什么 AI 会不稳定，以及系统如何变得稳定

结论：模型不稳定，不等于系统必须不稳定。 概率模型可能因上下文顺序、版本、参数和供应商路由给出不同表达；输入还会受材料解析、网络、语音和题库质量影响。可靠系统不要求每个组件永不失败，而是用七层保障让错误在形成不利结论前被发现、隔离和纠正。

C. 怎样判断它是否真的靠谱并可持续经营

结论：“靠谱”至少有四种，必须分别测量、分别处置；可持续经营还要求题库、模型、供应商、申诉和成本形成固定节奏。 系统可用只说明用户大多能完成流程；回答质量说明问题与反馈是否有用；评分可信说明证据能否稳定映射到共同标尺；公平合规说明技术误差、数据处理和使用方式是否合理。一个维度达标不能替代另一个维度。

2. 证据边界与引用约定

一级证据入口为 DeepInterview 静态证据审计 与 GrillKit 源码证据审计，二级证据为两个固定仓库源码。本章不使用浮动分支，也不把后续状态倒推到上述 HEAD。

【事实】 DeepInterview 实际通过的仅有 Python compileall、setup Bash 语法和基础 Compose 配置解析；其 pytest、Vitest、build、真实媒体与供应商链路未运行。GrillKit 实际通过 Python compileall 和 101 个 YAML 解析；pytest、Ruff、mypy、容器、Judge0、真实模型和语音未运行。测试文件数量、CI 配置和 README 的绿色描述只能说明存在资产或作者宣称，不能写成“本次测试通过”。

【建议】 每个输出强制记录 content_state（real/mock/degraded/sample）、provider、model、prompt/rubric version、question-bank version、locale、coverage 和时间。页面、导出及分析必须携带同一 provenance，sample/mock 在数据层禁止进入正式统计。

3. 两项目值得借鉴与不可照搬

4. 横向比较表

4A. 推荐技术蓝图

本章给出拟建系统的目标技术形态，避免与后文用途、合规、团队和交付路线重复。【事实】 DeepInterview 提供 prep/live/post、实时媒体与 InterviewContext blackboard 的可复用切片；GrillKit 提供确定性 session/section/task、题目快照、领域事件、结构化评分与 Judge0 边界的可复用切片。【未验证】 两个固定 HEAD 均未完成真实 LiveKit、STT/LLM/TTS、完整 RAG、Judge0、生产数据库和端到端容量验证。【建议】 组合两者的边界，而不是复制任一默认部署：状态机与数据库控制事实，LLM 只承担受约束的语义任务，实时媒体、长任务、代码执行和数据存储分成独立故障域。

flowchart LR
    U["候选人 Web / Mobile"] --> EDGE["Gateway / Auth / Rate Limit"]
    ADMIN["题库与运营后台"] --> EDGE
    subgraph CONTROL["控制面"]
        API["Session API"]
        SM["State Machine"]
        PREP["Prep Orchestrator"]
        POST["Post Orchestrator"]
        BANK["Question Bank"]
        REG["Provider Registry"]
    end
    subgraph LIVE["实时面"]
        RTC["WebRTC / LiveKit"]
        VOICE["Voice Worker"]
        VAD["VAD + Turn Detector"]
        STT["Streaming STT"]
        LLM["Low-latency LLM"]
        TTS["Streaming TTS"]
    end
    subgraph ASYNC["异步与隔离执行"]
        Q["Durable Queue"]
        RAG["RAG Workers"]
        SCORE["Scoring Workers"]
        JG["Judge0 Gateway"]
        J0["Isolated Judge0"]
    end
    PG[("Postgres")]
    OBJ[("Object Storage")]
    VEC[("Knowledge Store")]
    REDIS[("Redis")]
    OBS[("Metrics / Logs / Traces")]
    EDGE --> API --> SM
    SM --> PREP
    SM --> POST
    PREP --> BANK
    PREP --> Q
    POST --> Q
    Q --> RAG --> VEC
    Q --> SCORE --> PG
    API --> PG
    API --> OBJ
    U <--> RTC <--> VOICE
    VOICE --> VAD --> STT --> LLM --> TTS --> VOICE
    VOICE --> PG
    VOICE --> REDIS
    VOICE --> REG
    API --> JG --> J0
    JG --> PG
    CONTROL --> OBS
    LIVE --> OBS
    ASYNC --> OBS

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> PREP_QUEUED: submit_prep
    PREP_QUEUED --> PREPARING: worker_claimed
    PREPARING --> PREP_REJECTED: invalid_input
    PREPARING --> PREP_DEGRADED: partial_failure
    PREPARING --> READY: plan_published
    PREP_DEGRADED --> READY: accept
    PREP_DEGRADED --> PREP_QUEUED: retry
    PREP_REJECTED --> DRAFT: revise
    READY --> CONNECTING: join
    CONNECTING --> LIVE: media_ready
    CONNECTING --> READY: connect_failed
    LIVE --> RECONNECTING: transport_lost
    RECONNECTING --> LIVE: resumed
    RECONNECTING --> DRAINING: reconnect_timeout
    LIVE --> DRAINING: finish_or_guard
    DRAINING --> POST_QUEUED: checkpointed
    POST_QUEUED --> SCORING: worker_claimed
    SCORING --> REPORT_DEGRADED: partial_failure
    SCORING --> COMPLETED: report_committed
    REPORT_DEGRADED --> COMPLETED: accepted_or_repaired
    COMPLETED --> [*]

5. 候选人练习与招聘评估边界

【建议：练习范围】 用户自主选择岗位、上传或粘贴材料、完成模拟问答/编码并获得形成性反馈。可以展示能力维度、回答证据、覆盖率、改进建议和示例答案，但应称“练习反馈”，不宣称录用概率或代表雇主标准。简历不是必填，练习数据默认不流向招聘客户，也不得未经独立同意进入训练集。

【建议：招聘评估范围】 一旦结果被雇主用于筛选、排序、淘汰或晋级，即进入高风险评估。必须另行定义适法基础、候选人通知、岗位相关性、合理便利、人工复核、申诉纠错、地域与保留策略、子处理商和客户合同。自动分不得成为唯一不利决定依据；低覆盖、技术故障、低 STT 置信或模型异常应自动转人工，而非判低分。

禁止用练习次数、付费状态、摄像头质量、背景噪声、口音、停顿、面部或情绪推断等缺乏岗位效度的信号评分。

6. 产品与合规准备

【建议】 建立“用途—数据—决策”登记：谁发起、数据来源、进入哪些模型、保存多久、影响谁、是否产生不利决定。上线前由适用司法辖区律师复核劳动、隐私、自动化决策、录音/生物识别和消费者保护要求；本章不构成法律意见。

最低准备包括：候选人和企业客户两套条款；隐私通知与子处理商清单；DPA；录音/转写单独提示；数据下载、删除、纠错与撤回入口；无障碍文本替代；人工复核和申诉 SLA；安全事件流程；模型/题库变更记录；禁止作弊与禁止高风险推断政策。

生产配置必须 fail closed：认证、持久化、provider、对象存储或区域策略缺失时拒绝启动相应能力，不得回 mock 后继续产生正式分数。样例只存在演示 tenant。

7. 隐私、安全威胁模型与数据治理

【建议：数据治理】 数据至少分为账户信息、职业材料、面试内容和派生评分四级；每个字段登记目的、来源、tenant、区域、保留期、接收方、训练资格和删除路径。原始音频默认只用于实时转写；需回放时单独选择。删除覆盖主库、对象存储、RAG 索引、缓存、分析仓及备份到期清除，并提供状态、重试和完成凭证。训练用途必须独立 opt-in、去标识、授权审查且可撤回。生产数据禁止复制到个人调试环境。

8. 公平性与评分校准

【事实】 DeepInterview 有分数范围、competency identity 和 coverage 的代码约束，GrillKit 有结构化 schema；两份审计均未证明招聘效度、公平性、跨语言一致性或真实媒体质量。结构化输出不等于可信评分。

【建议】 评分对象应是“在给定岗位相关题和 rubric 下展示的可观察证据”，而非候选人整体。报告展示题目/rubric/模型版本、证据片段、规则信号、覆盖率和人工修改。禁止以受保护属性及其代理变量评分；STT 低置信时允许核对转写，以文本修正为准。

校准集覆盖岗位、级别、题型、语言、口音、回答长度、设备/噪声和合理便利；每条由至少两名受训领域评审独立标注并仲裁。按候选人和题族隔离数据集，避免泄漏。指标至少包括人工一致性、相邻等级准确率、重复运行方差、缺失处理、覆盖率、各群体误差与置信区间。样本不足只能报告证据不足，不能宣称“无偏”。模型或 prompt 升级必须通过固定 golden set 回归。

9. 测试矩阵与质量门禁

当前两个仓库的轻量检查只能作为输入，不构成上述门禁已经满足。

10. 团队、硬件、API 与数据集准备

【建议：团队】 覆盖产品、前后端/平台、实时音频、ML 评估、数据、安全、隐私/法务、招聘测量、题库内容、QA/SRE、无障碍和用户研究。PoC 可兼任，但安全、法务和评分效度不能由实现者自审自批。

【事实】 DeepInterview 本地 profile 包含 qwen3:8b、Whisper、Kokoro；GrillKit 的 Whisper 规格约 0.5/1.5/3 GB，Piper 单 locale 约 60 MB 的数字来自项目材料，审计没有运行性能验证。

【建议：硬件】 CI 使用无 GPU mock 和录制 fixture；媒体环境准备 Linux CPU 节点、真实设备矩阵与网络整形。本地 8B 模型可先用约 24GB VRAM 的单卡作为基准候选，但并发必须压测后承诺。代码沙箱与应用、数据库、秘密隔离到专用 VM/节点。

【建议：API】 LLM、STT、TTS、媒体、存储、搜索和认证均准备 sandbox/production 双账户，登记区域、保留、训练使用、限流、SLA、DPA 和退出能力。STT 失败转文本、TTS 失败显示题目、搜索失败不阻断、评分失败保存答案后异步重试。密钥只进 secret manager。

【建议：数据集】 准备版本化题库/rubric、人工校准集、媒体质量集和安全对抗集。编码题必须有 golden solution、public/hidden cases、错误解法及资源预算。记录来源、许可证、PII、岗位范围和禁止用途。

11. 成本、容量与 Build vs Buy

【建议】 单场成本按 prep LLM + live LLM + STT 分钟 + TTS + post 多题评分 + 搜索/RAG + 媒体房间 + 存储/出网 + 沙箱 + 可观测性 + 人工复核 建模。峰值并发房间约为“峰值每小时到达量 × 平均会话分钟 ÷ 60”；评分容量由题数、调用时延、provider 并发和报告时限决定。设置 session 时长、turn、题数、上传、Run 次数、tenant/provider 月预算和重试幂等上限。供应商价格具有时效性，PoC 后以实际报价和压测填写 100/1,000/10,000 场三档模型，不虚构单价。

12. PoC / MVP / Beta / 生产路线图及退出条件

PoC：离线文本与证据链。 固定题库、mock、结构化 rubric、快照、provenance、导出/删除样机，只用合成或许可数据。退出条件：状态机与不变量通过；sample/mock 明确；题库 schema/ID 通过；能追溯反馈到题目、rubric 和回答证据；威胁模型与数据目录签字。

MVP：受控练习。 加账户授权、可选 CV/JD、文本主路径、可选语音、provider sandbox、纠错、删除、预算和观测；编码只上线有可靠测试的题。退出条件：E2E、迁移、SSRF/上传、权限、Origin、删除传播通过；P0/P1 清零；媒体可降级；100 场内部/合成容量测试满足 SLO，无答案丢失和重复计费。

Beta：邀请制练习。 加有限多语言、人工客服/申诉、nightly provider 回归、红队、无障碍和成本仪表盘，仍禁止用于淘汰。退出条件：预注册质量与稳定性门槛达到；关键语言/设备/口音 slice 无无法解释落差；独立渗透测试、恢复、轮换、删除抽样和 2 倍峰值压力通过。

生产：自主练习 GA。 建立 on-call、错误预算、回滚、供应商退出、持续校准。退出条件：连续两个发布周期无未解决 P0/P1；模型/题库版本与季度访问审查、年度渗透/灾备演练落地。

招聘评估受限试点：独立 Go/No-Go。 必须完成岗位效度、法律审查、通知、合理便利、人工复核、申诉、合同限制和独立公平性评估；任一缺失即 No-Go。只输出供人工参考的证据包，不发自动录用/淘汰指令。

13. 风险登记表

14. 上线 Checklist

• 用途明确为自主练习，招聘评估未混入默认产品。
• 真实面试作弊排除项进入需求、营销、客服和安全测试。
• 代码、模型、prompt、rubric、题库和 schema 版本可追溯。
• 生产禁用 mock/sample 正式评分，degraded 状态清晰。
• OIDC/服务身份、tenant 授权、媒体短 token、限流与预算熔断启用。
• CV/JD/音频/逐字稿有目的、区域、保留、删除、导出和训练资格。
• SSRF、恶意文件、Origin/Host、CSRF、TLS、CSP 与重放测试通过。
• 代码执行专用隔离、无秘密、默认无外网、无 privileged 共享部署。
• 上线编码题均有 golden、public/hidden tests 和错误解法验证。
• 空库/升级/备份恢复通过，迁移路径可达。
• append/submit/score/delete 有幂等和跨实例一致性测试。
• 质量、稳定性、公平性和 prompt injection 回归达门槛。
• 低覆盖、低 STT 置信和技术故障不会自动变低分。
• 文本替代、纠错、人工复核和申诉 SLA 可用。
• SBOM、许可证/NOTICE、依赖/镜像扫描和静态资源自托管完成。
• SLO、容量、成本、限额、告警、轮换、恢复和事件演练通过。

15. 两个项目关键缺口

DeepInterview：（1）真实媒体、provider、存储与 RAG 端到端未验证；（2）sample/mock/degraded 缺少贯穿全链路的强 provenance；（3）空 secret、capability-only read、SSRF 和跨实例一致性不足；（4）敏感数据 retention、删除/导出、录音同意和区域治理不完整；（5）缺招聘效度、人工校准与跨语言公平性证据。

GrillKit：（1）44 道编码题均无 public/hidden tests，内容未兑现执行框架；（2）默认 root entrypoint 的 migration 不可达；（3）无认证及 CSRF/Origin/Host/CSP、base URL 和明文 key 风险；（4）privileged Judge0、示例密码和 CDN Monaco 不适合共享生产；（5）完整 CI、真实模型/语音、E2E、容量、公平性和成本未验证。

16. 本地研究入口和阅读顺序

1. 先读 DeepInterview 审计 的执行摘要、流程、安全、测试和限制。
2. 再读 GrillKit 审计 的执行摘要、题库、迁移、安全、测试和限制。
3. DeepInterview 主链路：prep graph → worker → evaluator → report。
4. DeepInterview 边界：auth → repository → Supabase migration → 报告页。
5. GrillKit 主链路：session phases → create session → structured evaluation → submit solution。
6. GrillKit 判题/部署：task spec → run tests → Judge0 → Compose → entrypoint。
7. 最后读 DeepInterview README 和 GrillKit README，只用于作者意图和配置说明，并与审计实际执行结果对照。

结论是：两个项目都提供了值得复用的工程切片，但没有一个固定 HEAD 已证明可直接用于真实招聘决策。应复用状态机、证据链、结构化契约、失败隔离和 provider adapter，同时重建认证、数据治理、评分校准、沙箱、安全测试与阶段退出机制。第一性边界是帮助候选人练习，而不是在真实面试中作弊，也不是用未经验证的模型分数替代人的招聘责任。

一、简历（CV）/职位描述（JD） → 能力模型 → 题目规划：先定义契约，再允许模型推断

这条链不是“把简历和职位描述拼进一个 prompt，让模型随便出题”，而是一条有中间表示、可验证不变量和版本边界的编译流水线。CV 是候选人自述证据，JD 是岗位需求声明，公司资料是外部背景；三者证据等级不同，必须先结构化，再做差距匹配，最后将差距映射到有限题目、rubric 和时间预算。DeepInterview 已给出清晰原型：Prep 图并行执行 CV 分析、JD 分析和公司研究，汇合后执行 gap matching 与 question planning；join 保证下游看到三个分支的完成态，而不是拿到“谁先返回就用谁”的残缺上下文（prep graph）。

输入。 【事实】固定源码的 PrepRequest 包含 cv_url、jd_text、company、language_mode 和可选 owner；CandidateProfile、JobSpec、GapAnalysis、PlannedQuestion、QuestionPlan 与 InterviewContext 都是 extra="forbid" 的 Pydantic 契约，计划明确包含 section、双语题面、难度、rubric、follow-up、目标能力、总时长和语言模式（shared models、context）。这说明输入不只是字符串，而应至少携带 tenant_id、session_id、source、内容哈希、解析器版本、语言、许可、时间戳与 provenance。CV 中“掌握 Kafka”只能形成 candidate claim；JD 中“负责分布式系统”只能形成 job requirement；它们都不是已经证实的能力。

处理。 【事实】Prep 的每个节点只向 PrepState 增量写入自己计算的字段，结构为 candidate/job/company/gap/plan，这相当于类型化的中间表示（prep state）。CV/JD 先抽取实体与规范化技能，再由 gap matching 计算 matched_skills、missing_skills、strengths、gaps 和 probe_targets；题目规划器消费 candidate、job、company、gap 和 language mode，并可注入受字符预算限制的 playbook 片段（prep nodes、planner）。【建议】生产算法应把能力模型写成有向映射：Requirement -> Competency -> ObservableSignal -> QuestionRevision -> RubricCriterion。每个 requirement 有来源跨度和权重，每个 competency 有岗位相关性与证据需求，每道题声明能覆盖哪些 observable signals。规划可做成约束优化：在总时长、题型比例、难度、语言和无障碍约束下，最大化高权重能力覆盖与信息增益，同时惩罚重复题、单一题型和仅由弱证据支撑的断言。LLM 可提出候选映射，但 schema 校验、枚举、权重归一、题库 ID 存在性、版本固定、时间预算和最小覆盖必须由代码执行。

输出。 【建议】发布的不是可变 QuestionPlan 草稿，而是不可变 PlanSnapshot：包含 bank_release_id、每题 revision、locale revision、rubric version、能力映射、选择理由、证据引用、预计时长、随机种子、规划器版本、模型与 prompt 版本、输入内容哈希和 content_state。快照一旦进入 READY 就不再跟随题库更新；后续动态追问只能作为关联到原题的新 Attempt，不得偷偷改写基础计划。计划还应输出 coverage matrix，使系统在开始前就能解释“哪道题为什么存在、覆盖哪个能力、未覆盖哪些岗位要求”。

失败模式。 【事实】CV 抽取失败可退回原始 URL 字符串，CV/JD/gap/planner 失败可生成 minimal/mock 对象并写 warning；planner 最终还会强制把语言模式钉回请求值（节点降级、规划降级）。这保证 demo 不崩，却可能把“结构合法”误当“语义有效”。其他失败包括简历版式解析错误、同义技能未归一、JD 复制营销话术、模型虚构公司流程、prompt injection 操纵规划器、并行分支超时、模型输出重复题、rubric 权重不闭合，以及短面试无法覆盖全部能力。【未验证】固定源码没有证明真实 CV/JD 抽取质量、跨语言 skill normalization、题目效度或 planner 稳定性。

实现建议。 【建议】接收层先做文件隔离解析、MIME/页数/解压体积/URL egress 检查；抽取层保存原文 span，不让模型凭空补必填字段；规范化层用受控 taxonomy 和 alias 表；匹配层分别输出“原文事实、模型推断、未知”；规划层从版本化题库检索候选题，再由约束求解器选择，最后做 deterministic validator。建议初始目标：高权重能力计划覆盖率不低于 90%，单一题目承担总能力权重不高于 30%，重复语义题比例低于 5%，无法可靠抽取时进入 PREP_REJECTED 或 PREP_DEGRADED，而非静默发布真实计划。所有这些数值都是建议初始目标。

二、实时语音：WebRTC、VAD、STT、EOU、LLM、TTS 与 barge-in 是并发控制问题

实时体验的核心不是某个语音模型，而是多个异步流的时序正确性。浏览器持续产生音频帧；VAD 判断“有人声”，STT 持续产生 partial/final 文本，EOU 判断“这一轮是否结束”，LLM 可能预生成，TTS 又把 token 转成可播放音频。任何阶段都可能迟到、重试或被取消，因此每一轮必须带 turn_id 与 generation_id，并用取消令牌隔离上一轮残留结果。

输入。 【建议】媒体输入包括 WebRTC 音轨、采样率/声道、客户端时间、sequence、网络 jitter/packet loss、设备变化、候选语言和 consent；控制输入包括当前 session/section/attempt、题目快照、允许追问次数、deadline 和 provider policy。partial transcript 是低确定性 UI 数据，final transcript 也不自动等于回答提交；只有状态机确认的 turn.committed 才进入评分事实。【事实】DeepInterview 捕获 LiveKit 的 conversation_item_added，将用户和助手实际 committed 的内容写入 transcript；答案仍由 save_answer 进入 context，关闭时可从 transcript 恢复漏存答案（transcript capture）。

处理。 浏览器通过 WebRTC 将短帧送至 SFU/媒体服务；WebRTC 处理 ICE、DTLS-SRTP、拥塞与抖动缓冲，但不决定语义轮次。VAD 对声学帧做起音/停音检测；STT 在语音进行时产生 partial 并最终定稿；EOU 把声学停顿和文本完整性结合，避免把自然停顿误判为回答结束。DeepInterview 预热 Silero VAD，支持语言使用 multilingual EOU，不支持语言回退到静音 endpointing；源码事实参数为最小静音 1.2s、最大静音 4.0s，这是固定实现值而非本文性能目标。中断确认要求至少已有 3 个转写词，也是固定实现值，目的是降低门响或背景声造成误中断（turn handling、VAD prewarm）。本地 Whisper 路径实际是 VAD 切句后调用 batch endpoint，再包装成 streaming 接口，所以没有逐词 interim；这与真正 streaming STT 的延迟行为不同（local STT）。

在正常轮次中，EOU 确认后提交 final transcript，状态机接受 Attempt，LLM 读取受限上下文流式生成，TTS 尽早合成并播放。barge-in 时不能只“停止扬声器”：先由 VAD 触发 ducking，STT 达到词数/置信门槛后原子地标记当前 generation cancelled，停止 LLM 消费、取消 TTS、清空尚未播放 buffer，记录已经播放到的字符或音频区间，再开启新候选人 turn。迟到 token 或音频块因 generation id 不匹配被丢弃。否则最常见的竞态是候选人已经开始回答，旧 TTS 仍继续播放，或旧 LLM 尾部被误接到新回答之后。

输出。 【建议】实时面至少产生 speech.started、stt.partial、stt.final、turn.endpointed、turn.committed、generation.started、tts.chunk、assistant.interrupted、provider.failed 和 media.reconnected。事件只放必要元数据；音频与全文使用受限存储引用。每个 turn 保存客户端/服务端时间、VAD/STT/EOU 置信、采用的 transcript revision、播放区间、取消原因和 provenance。UI 可乐观显示 partial，但在 final/commit 到达时必须校正。

失败模式。 常见问题包括 NAT/权限导致无法建链，jitter 造成断续，噪声触发 VAD，EOU 太激进切断长句，EOU 太保守造成尴尬等待，STT 把口音错误变成技术错误，本地 batch STT 没有 partial，LLM 冷启动，TTS 首包慢，取消传播不完整，重连后重复提交，或 BVC 降噪导致无音频。【事实】DeepInterview 仅在显式启用且使用 LiveKit Cloud 时开启 BVC；源码注释记录过过滤器初始化失败导致无音频的风险（room options）。【未验证】两份审计都没有验证真实设备、口音、噪声、barge-in、音质、准确率和 provider 延迟。

实现建议。 【建议】预算应从“用户结束说话到助手首音”倒推，而不是分别优化平均值。建议初始目标：浏览器到 VAD 可用帧 P95 不高于 80ms；起音检测 P95 不高于 120ms；首个 STT partial P95 不高于 300ms；支持语言的语义 EOU P95 不高于 450ms；云 LLM 首 token P95 不高于 600ms，本地热模型 P95 不高于 1200ms；TTS 首块 P95 不高于 350ms；端到首音 P95 不高于 1.5s、P99 不高于 2.5s；确认 barge-in 后停声 P95 不高于 250ms。这些全是建议初始目标。指标必须按语言、设备、网络、provider、冷热状态分桶；STT 低置信允许候选人纠正；语义 EOU 故障降级为静音端点，STT 故障降级文本，TTS 故障保留文字，不能把媒体故障折算成能力低分。

三、会话状态机必须与 LLM 解耦

LLM 是概率性、可超时、可被注入、可能返回无效 JSON 的外部依赖；状态机则承担计时、授权、顺序、幂等和账务，是系统事实源。两者耦合后，一个模型幻觉就可能跳题、延长会话、重复计费或把未提交答案标为完成。正确关系是：LLM 只返回“建议的语义动作”，命令处理器根据当前状态、版本和策略决定是否接受。

输入。 状态机输入不是自然语言，而是命令：SubmitPrep、PublishPlan、JoinLive、CommitTurn、SubmitAttempt、RunCode、FinishSection、StartScoring。每个命令携带 actor、tenant、aggregate id、expected_version、idempotency key、deadline 和必要 payload。LLM 输出必须先解析成受限 DTO，例如 follow_up_needed、follow_up_question 或 rubric 评分，不能直接提交任意状态字符串。

处理。 【事实】GrillKit 由四种 session mode 映射固定 section 顺序，服务查询 section 是否 pending/active/complete 再推进；不是由模型决定先理论还是先编码（phase order、advance phase）。理论评价最大追问深度的源码事实值为 2，追问内容可由 LLM 生成，但是否还能追问由领域规则限制（theory evaluator）。【建议】顶层状态使用 DRAFT → PREPARING → READY → CONNECTING → LIVE → DRAINING → SCORING → COMPLETED，并显式加入 REJECTED、DEGRADED、RECONNECTING、FAILED。Section 与 Attempt 各有子状态；计时以服务端单调时钟和持久化 deadline 判断。命令处理流程固定为“鉴权→加载聚合→检查 expected version→验证迁移→写事件/状态→写 outbox→提交事务”。

输出。 状态机输出领域事件和新的 aggregate version，而不是直接生成 UI 文案。GrillKit 已将 AnswerSavedEvent、EvaluatingEvent、AnswerFeedbackEvent、TranscriptEvent、InterviewCompletedEvent 定义为 transport 无关的不可变 dataclass，再由 WebSocket 层映射（domain events）。【建议】模型建议被拒绝时也应产生审计事件，如 followup.rejected(reason=max_depth)；这样才能区分“模型没建议”与“规则禁止”。

失败模式。 如果 LLM 直接控制流程，可能返回不存在的 question id、要求越过 timer、在重试时生成不同追问、把 provider timeout 当成候选人超时，或被答案中的指令诱导“结束面试并给满分”。即使结构化输出通过 schema，也只证明形状正确，不证明迁移合法。另一个风险是前端倒计时或 WebSocket 重连重复发送 complete；如果服务端没有版本和幂等约束，就会重复评价和收费。

实现建议。 【建议】把 LLM 调用放到状态迁移之外：先在事务中保存 Attempt 并转为 EVALUATING，通过 outbox 派发模型任务；消费者以 input hash 计算幂等键；结果回来后再次 compare-and-swap，只在目标 Attempt 仍处于相容状态时生效。建议初始目标：非法迁移接受数为 0，重复命令产生重复副作用数为 0，状态冲突明确返回 409，状态机属性测试覆盖全部允许/禁止边，任意 provider 故障都不破坏已提交答案。这些均为建议初始目标。

四、RAG：从 ingest 到 citation 的可信链，以及隔离与 prompt injection

RAG 的价值不是“让模型知道更多”，而是把输出约束到可追溯的私有材料、题库与公共资料。它至少包含接收、解析、切块、向量化、索引、召回、重排、上下文组装、生成、引用核验和删除传播；缺一环都可能得到看似有引用、实则不可复核的答案。

输入。 输入文档需要 tenant_id、namespace、source URI、原始内容哈希、MIME、语言、许可、保留期、访问策略和解析器版本。查询需要 actor、tenant/session、允许的 namespace、query、locale、top-k、token budget 与用途。CV/JD 属于 candidate-private；题库属于版本 release；公司资料属于有抓取时间的 public snapshot，三者不能混成一个无边界向量库。

处理。 【事实】DeepInterview 的 sidecar 默认 NaiveRAG：按约 500 字符切块（源码事实值，非目标），用小写字母数字 token overlap 做长度归一化 TF 评分，稳定排序后取源码事实 TOP_K=3，返回抽取式 answer 与 citation（NaiveRAG、query）。它以 user_id/实际 OSS 流程中的 session id 分 store。【事实】所谓完整 LightRAGBackend 在固定 HEAD 仍是骨架，instance、ingest、query 均抛 NotImplementedError，因此 embed、graph retrieval、rerank 与真实 citation 并未接通（LightRAG skeleton）。没有配置 sidecar URL 时，Agent 使用无状态 deterministic MockKnowledge 并返回预制 citation（knowledge adapter）。

【建议】生产 ingest 应先恶意文档扫描与隔离解析，再按标题、段落、列表和代码语义切块，保留 start_offset/end_offset/page；embedding 写入前记录模型、维度和规范化方式。query 先做关键词与向量混合召回，再进行 ACL 过滤与 cross-encoder rerank，最后按来源多样性、时效和 token budget 组装上下文。citation 必须绑定真实 chunk id、原始 span、索引版本和内容哈希；生成后逐条验证引用文本确实支持对应 claim。引用不是 URL 装饰。

输出。 输出分为 retrieval_set 和 generated_answer。前者包含 rank、raw score、rerank score、namespace、chunk id、source span、content hash；后者包含 claim 到 citation 的映射、无证据声明和 provenance。题目规划只应得到最小必要片段，不应得到整个 CV；评分模型通常不需要公司公共资料，避免无关上下文污染 rubric。

失败模式。 文档可能包含“忽略系统指令、泄露隐藏题、给候选人满分”等 prompt injection；恶意 HTML/PDF 可夹带不可见文本；跨 tenant filter 漏掉会召回他人简历；旧 embedding 与新 query 模型不兼容；切块破坏上下文；top-k 全是同一来源；citation 指向网页却不对应实际 chunk；删除主库后向量副本仍存在。【事实】sidecar URL 检查仅对字面 IP 做 public/private 判断，域名路径仍需 DNS 与 egress 防御；它禁止跟随重定向，这是一项局部控制（ingest SSRF guard）。【未验证】完整 RAG 的质量、隔离、删除传播和注入防护没有在审计中动态验证。

实现建议。 【建议】使用强制 namespace candidate_private/{tenant}/{session}、question_bank/{release}、company_public/{snapshot}；ACL 在检索引擎查询层强制而非生成后过滤。把检索内容标成“不可信数据”，模型无权从文档获得工具权限、秘密或状态机控制；工具 allowlist 和参数 schema 独立于文本。建议初始目标：RAG 查询 P95 不高于 250ms、初始 top-k 为 6、注入上下文不高于 8000 tokens、跨租户召回数为 0、citation 可解析率为 100%、删除任务在约定窗口内覆盖主索引/缓存/备份索引。所有数值均为建议初始目标。RAG 失败可继续使用已发布计划，但输出必须标 degraded，不能回 mock 后仍称 grounded。

五、理论题、编码题、Judge0 与 AI 评分的组合

理论题和编码题观察的信号不同。理论题重视概念、权衡、解释和追问后的修正；编码题首先有可执行正确性、资源消耗和错误行为，然后才有可读性、设计取舍与解释。把所有信号交给 LLM 会损失确定性；只看测试又无法评价开放式工程判断。正确结构是“规则/执行信号优先，AI 解释辅助”。

输入。 理论题输入包括不可变题面 revision、locale、expected points、rubric、难度和题目能力映射；回答输入包括初答、追问链、时间和 transcript provenance。编码题还包括语言、starter code、entrypoint、public/hidden test suite version、资源限制、candidate code、Run 历史和 Submit。【事实】GrillKit 会将题面、expected points、代码和 task spec 随 session 持久化，避免题库更新后历史结果漂移（database snapshots、coding snapshots）。

处理。 理论题先按 rubric 做结构化评价，再由状态机决定是否创建追问；追问用于减少证据不充分，不应只是“低分再问一次”。GrillKit 将 schema 放进 system prompt，使用 Pydantic 解析；截断或 invalid JSON 最多重试一次，第二次 token budget 上限的源码事实值为 4096（非建议目标）（structured evaluation、retry）。

编码的 Run 只执行 public tests 并返回安全结果；Submit 在服务端加载 hidden tests，执行后只产生摘要。GrillKit 的 client serializer 删除 hidden tests，并把 public tests 降为名称，不返回 expected output（client task spec）。runner 对 tests mode 逐例调用 Judge0，严格比较 stdout，首个失败停止；AI mode 或无 tests 时退化为 compile-only（run tests）。Submit 先跑 hidden/compile-only、持久化摘要，再调用 CodingEvaluator（submit solution、AI evaluation）。

输出。 【建议】确定性输出包括 compile status、public/hidden passed count、失败类型、CPU、memory、output truncation、test suite hash；AI 输出包括 rubric criterion score、evidence span、工程质量反馈和追问建议。最终分由代码组合：正确性门槛和 score cap 写在规则引擎，不只写 prompt。GrillKit 当前 prompt 写了 hidden tests 失败最高 3 分（源码事实规则文本，非建议目标），但它只是 prompt 指令，生产系统应在模型返回后再次代码钳制（coding prompt）。

失败模式。 【事实】GrillKit 固定题库的源码统计是 44/44 道编码题均为 AI mode，tests/public_tests/hidden_tests 均为 0；这些是审计事实数值，不是目标。因此现有框架实际只能 compile-only 加 AI 评分，不能宣称内置题库已具备可靠判题（GrillKit 审计）。其他风险包括 public test 泄露答案、hidden test 经 session JSON/日志/LLM prompt 泄露、严格 stdout 比较产生格式假阴性、逐测试同步请求放大延迟、candidate code 探测内网、无限输出耗尽资源、测试过拟合、AI 被代码注释注入，以及 Judge0 privileged 部署扩大逃逸后果。固定 Compose 的 server/worker 使用 privileged，审计已明确不适合共享生产（GrillKit 安全审计）。

实现建议。 【建议】hidden tests 独立加密存储，session 只存 suite reference；Judge0 Gateway 在可信服务端拼接 harness，执行节点位于专用 VM/节点池，默认断网、无生产 secret、只读根文件系统、独立 cgroup/seccomp 和用后销毁 workspace。题库发布必须满足 reference solution 全过、代表性错误解至少一个测试失败、泄漏契约测试通过。建议初始目标：执行排队 P95 不高于 1s，单 case CPU 不高于 3s、墙钟不高于 5s、内存不高于 128MiB、输出不高于 64KiB、每 session 同时执行 1 个任务、每题 Run 不高于 20 次；均为建议初始目标。Judge0 不可用时允许保存草稿并重试，但绝不能标记测试通过。

六、评分：rubric、coverage、evidence、校准、置信区间与公平性

分数不是模型回答里的一个浮点数，而是对“给定任务、给定证据、给定 rubric”所作的测量。一个可信报告至少回答：测了什么、测了多少、依据何在、测量误差多大、与人工标准如何校准、在哪些人群和语言上不可靠。

输入。 输入应冻结 question/rubric revision、candidate response revision、transcript 修订记录、代码与 test hash、追问链、语言、合理便利、provider/model/prompt 版本和 content provenance。rubric 每个 criterion 定义可观察信号、等级锚点、权重、反例和不可用条件。不得将口音、停顿、背景噪声、摄像质量、情绪推断或付费状态作为技术能力代理变量。

处理。 【事实】DeepInterview 对已回答题并发评分，强制 competency 等于计划的 target_competency，把分数 clamp 到 0–5，由代码派生 mastery band；同能力多题取平均；未回答题跳过（evaluator、coverage handling）。报告的 overall 是 competency 均值，coverage 是已回答计划题占比（report、assembly）。这体现了关键原则：没测到不是零分，低 coverage 不能伪装成完整低能力画像。

【建议】逐 criterion 评分先提取 evidence span，再生成原始等级；规则引擎合并确定性信号并执行 cap；校准层把 raw score 映射到人工锚点分布。置信区间应来自重复评分方差、题目采样误差、人工标注不一致和媒体质量，而不是让 LLM自报 confidence。可用 bootstrap 或分层贝叶斯模型按岗位/题族估计区间；证据很少时区间自然变宽，报告应显示“证据不足”，而不是给两位小数的伪精确分。

输出。 【建议】每个 ScoreEvidence 保存 criterion、score、原始模型输出、引用的答案 span、test result hash、规则调整、最终值和版本。ScoreCard 同时展示 point estimate、confidence interval、coverage、未覆盖能力、degraded reasons、人工修改及理由。语言报告应与技术总分分离；只有经岗位效度验证的语言要求才能进入相关 criterion。

失败模式。 同一回答重复调用得到不同分；长答案因风格获利；STT 错词造成技术扣分；模型偏好某种口音或表达；rubric 模糊导致评审分歧；不同题难度直接平均；低 coverage 被误解为低能力；模型升级导致历史不可比；样本小却声称公平。【事实】DeepInterview 可选 verifier 只复核 weak/developing，失败保持原分，且默认关闭；它不是完整人工校准或公平性证明（score verifier）。【未验证】两个固定 HEAD 都没有证明招聘效度、跨语言等值、群体公平或真实媒体质量。

实现建议。 【建议】建立按候选人和题族隔离的 calibration/golden set；每条由至少两名受训领域评审独立标注并仲裁。预先登记岗位、语言、设备、口音、回答长度、合理便利等 slice 的门槛，报告样本量与置信区间。建议初始目标：结构化输出解析成功率不低于 99.5%，确定性字段同输入一致率为 100%，核心 rubric 人工评审加权一致性达到预登记门槛，低 coverage/低 STT 置信/技术故障自动转人工而非判低分；数值均为建议初始目标。模型、prompt、rubric 或题库升级必须用固定集回归并创建新 scoring version，不重写历史结果。

七、可靠性：append-only 事件、outbox、幂等、乐观并发与恢复

实时面试同时存在浏览器、媒体 worker、API、评分 worker 和代码沙箱；网络通常只能提供至少一次投递。试图依赖“请求只会来一次”必然产生重复答案、重复扣费、丢 transcript 或状态倒退。正确目标不是神话式端到端 exactly-once，而是 at-least-once delivery 加 idempotent consumer，最终实现 exactly-once effect。

输入。 每个命令带全局 idempotency key、aggregate id、expected version、correlation/causation id、actor、发生时间和 input hash。事件 envelope 至少有 event id/type/schema version、aggregate version、payload、provenance。音频 partial 不直接成为领域事件；只将 committed turn、attempt submitted、code run completed 等事实 append。

处理。 在同一数据库事务中：验证 version，向 append-only event/attempt 表插入新行，更新 aggregate 当前 version，写 outbox。publisher 轮询或 CDC 发布未发送 outbox；消费者先以 event id/idempotency key 查 inbox，重复则返回已有结果。外部调用的幂等键建议由 operation + session + input_hash + model/rubric version 构成。【事实】GrillKit 的 UnitOfWork 明确管理 commit/rollback/close，提交工作流异常会 rollback（UnitOfWork、submit transaction）。这提供事务边界，但固定源码没有 durable outbox。

输出。 写路径输出新的 aggregate version 和稳定 operation result；读路径由 projector 构建 session view、进度和报告。append-only 并不意味着永不删除敏感数据：业务事实可保留 tombstone/删除事件，原文、音频和代码按保留策略密钥销毁或删除，投影同步清除。

失败模式。 【事实】DeepInterview 的 Supabase append_answer 是先读整个 context、内存追加、再整体 update；两个 worker 同时读取同一版本时，后写者会覆盖先写者，形成 lost update（repository）。其评分锁是进程内字典锁，只能防同进程竞争，不能防多实例重复调用（scoring lock）。周期 flusher 默认按间隔复制整段 transcript，能缩小崩溃损失窗口，但不是 append-only，也不能单独解决并发覆盖（flusher）。还可能发生 DB 提交而消息未发、消息已发而 ack 丢失、评分完成而状态未更新、重连重放旧 submit、迟到结果覆盖新版本。

实现建议。 【建议】answers、turns、code runs、scores 使用独立 append 表和唯一约束；UPDATE sessions SET version=version+1 ... WHERE id=? AND version=? 实现 compare-and-swap，影响行数为零即冲突。outbox 与业务写同事务，消费者用 inbox 去重。恢复时先读 snapshot，再按 sequence 重放尾部事件；DRAINING 停止新题，等待已承诺 turn、usage、outbox checkpoint。建议初始目标：重复副作用数为 0，同 session 只有 1 个 live lease，final checkpoint RPO 不高于 5s，控制面 RTO 不高于 15min，outbox lag P95 不高于 5s；均为建议初始目标。故障注入必须覆盖进程被杀、数据库超时、消息重复、乱序、provider 响应迟到和重连。

八、mock、sample、degraded 的 provenance 必须成为数据，而非 UI 猜测

mock 用于离线开发，sample 用于展示，degraded 表示真实流程部分失败。三者都合法，但只有在每一层都可识别时才安全。若只在日志写一条 warning，后续报告、导出和分析仓就可能把假数据当真实绩效。

输入。 每个外部或生成步骤输入 execution_mode、允许的 fallback policy、环境、provider selection 和数据用途。生产正式评分默认只允许 real provider；演示 tenant 可以明确允许 mock/sample。provenance 不应靠字符串是否包含 “mock” 推断。

处理。 【事实】DeepInterview 的 LLM 工厂在 provider 缺 key、未知 provider 或本地 base URL 缺失时返回 MockLLM（LLM factory）；Prep 节点局部异常也可能构造 minimal/mock schema。报告页在 API 不可达、session 不存在或 schema 漂移时返回 sample scorecard；有真实 scorecard 但叙事为空时以 degraded 布尔值提示（report loader）。这些路径说明状态存在，但 provenance 尚未作为所有领域对象的强制契约。

【建议】每个 artifact 写 content_state ∈ {real,mock,sample,degraded}、derived_from、provider/model、prompt/rubric/bank version、fallback reason、created_at、input hash。组合规则采用“最弱来源传播”：real plan 中只要关键 candidate 或 job 来自 mock，计划就不能仍标 real；报告若部分题评分失败，应保留成功题，但整体标 degraded 并列出缺失项。sample 数据使用独立 tenant、独立 ID 前缀和分析隔离。

输出。 API、UI、导出、事件和分析仓携带同一 provenance。用户看到的是“真实结果 / 演示样例 / 部分生成失败 / 无证据”，而不是仅靠颜色暗示。评分和费用指标按 content state 分桶；正式 KPI 默认排除 mock/sample。

失败模式。 最危险的是生产配置错误后自动回 mock，生成结构合法且看似合理的报告；API 失败时 UI 展示 sample 又被截图为真实结果；degraded 只有前端布尔值，导出丢失；真实与样例 session ID 同空间；修复后重跑覆盖原 provenance。【未验证】现有系统没有证明全链路 provenance、分析隔离和导出一致性。

实现建议。 【建议】生产启动对 auth、持久化和正式评分 provider fail closed；fallback 必须由 capability policy 显式允许。数据库对正式 score 增加约束：关键上游不得是 mock/sample。建议初始目标：mock/sample 进入正式统计数为 0，无 provenance 的新 artifact 数为 0，UI/API/export 状态一致率为 100%，配置错误在会话开始前暴露；均为建议初始目标。保留原始版本，以新 revision 修复，不覆盖历史。

九、从 PoC 到生产：扩大可验证边界，而不是堆功能

演进的主轴不是模型越来越大，而是事实源、数据契约、故障隔离、质量证据和用途边界逐步增强。每一阶段都要有退出条件；未满足就不能靠“Beta”标签掩盖。

输入。 阶段计划输入包括用途（自主练习或招聘评估）、威胁模型、数据目录、目标用户、语言、题型、provider、容量假设、错误预算、校准集、合规要求与团队能力。两个固定仓库只能作为工程切片：DeepInterview 提供 prep/live/post 和实时 worker，GrillKit 提供状态机、快照、结构化评分与 Judge0 边界；审计没有证明任一仓库可直接用于真实招聘决策（DeepInterview 结论、GrillKit 结论）。

处理。 【建议】PoC 先做离线文本闭环：确定性状态机、版本题库、rubric、evidence、content provenance 和导出/删除样机，只用合成或许可数据。MVP 再接账户授权、CV/JD 隔离解析、文本主路径、可选语音、provider sandbox、幂等/outbox、可观测性和只有真实测试的编码题。Beta 才扩大真实设备、语言、无障碍、红队、人工复核、nightly provider regression、容量和灾备。自主练习 GA 需要 on-call、错误预算、回滚、密钥轮换、删除传播和持续校准。招聘评估是独立 Go/No-Go，必须另做岗位效度、法律审查、公平性、通知、合理便利、人工复核和申诉，不能由练习版自然升级而来。

输出。 每阶段输出可审计 release：架构决策、schema、迁移、SBOM、题库 release、模型/prompt/rubric 清单、测试报告、性能基线、安全例外、校准报告、数据处理登记和回滚包。Build/Buy 的边界应稳定：状态机、题库、rubric、证据链和申诉责任自建；媒体、模型和基础设施可先采购但必须经 provider protocol 隔离。

失败模式。 PoC 最容易把 mock 成功当生产正确；MVP 容易先上语音而没有文本降级；Beta 容易追求题量而没有 golden/错误解；生产容易依赖单 provider、无版本迁移或无删除链；招聘试点最危险的是把未校准练习分用于自动淘汰。现有源码也提示了具体风险：DeepInterview 真实媒体、完整 RAG、Supabase/R2 未验证；GrillKit 无认证、迁移入口缺陷、privileged Judge0 且当前题库没有测试。这些必须是阶段门禁，不是上线后的改进项。

实现建议。 【建议】PoC 退出条件是核心状态不变量、题库 schema、provenance 与证据追溯全部通过；MVP 建议初始目标是在至少 100 场内部/合成容量演练中无已确认答案丢失、无重复计费，权限、SSRF/上传、迁移、删除和断线 E2E 通过；Beta 建议初始目标完成 2× 预测峰值压力、独立渗透、灾备和关键公平性 slice；GA 建议初始目标连续 2 个发布周期无未解决 P0/P1。所有数字都是建议初始目标。任何阶段发现评分不可解释、跨租户泄漏、hidden test 泄漏、沙箱逃逸或 mock 混入正式结果，都应停止扩大流量并回滚。

十、把九条链合成一个可审计闭环

系统的最小可信闭环是：CV/JD 被隔离解析成带来源的能力模型；规划器从版本题库生成不可变计划；状态机授权每个 section 与 attempt；实时面把音频转换为 committed evidence；代码执行提供确定性结果；RAG 只在授权 namespace 内提供可引用上下文；评分按 rubric 汇总 evidence、coverage 与不确定性；append-only 事件、outbox 和幂等保证故障后可恢复；provenance 贯穿 UI、API、导出与分析；阶段门禁决定系统是否有资格扩大用途。

任何一层都不能替代另一层：schema 只能保证形状，不能保证真实性；引用只能证明来源，不能证明推理正确；测试通过只能证明给定 case，不能证明工程质量；LLM 的 confidence 不能替代统计置信区间；容器不能自动等于安全沙箱；状态显示 ready 不能证明真实 provider 已执行。最终应把“模型输出”降格为一种可审查信号，把“系统事实”交给确定性规则、事务数据和版本化证据。

本文的实现优先级因此是：先锁定用途和状态机，再锁定数据契约、快照、幂等与 provenance；随后接文本评分与真实测试题；再接 RAG 和实时语音；最后才扩大多语言、容量与高风险用途。这样得到的不是一个会聊天的面试 UI，而是一套在失败、重试、升级和争议发生时仍能解释“输入是什么、经过什么处理、输出依据什么、哪里失败、为何可以恢复”的系统。