外观
Q17–Q20：AI 应用、多端课堂与系统设计
口语、拍照、MQTT 是简历的其他项目主线。本次教材系统不扩张实现这些产品功能；本页准备历史职责表达与设计推演。只有简历明确记载的行为可当历史事实，具体协议字段、算法或事故均按假设方案讲述。
Q17 口语对话为什么需要统一会话接口？
**考察目的：**流式交互、状态机、用户打断和多端一致性。**难度：**中高。
**主问题：**语音输入、模型回复、TTS 播报和剧情推进怎样串起来？
直接答案与 STAR
统一会话接口的价值是让客户端面对稳定的业务事件，而不是直接理解每个 ASR、LLM、TTS 服务的差异。一次会话应有会话 ID、轮次或请求 ID，明确输入完成、模型处理中、文本可显示、音频可播放、结束和失败等状态。剧情推进属于业务状态，应根据明确的规则或经过校验的结构化输出更新。
链路可串行实现，也可以在保证语义完整度的前提下流式衔接。低延迟不是尽早播放任意碎片；要处理断句、取消、顺序和失败。用户开启新一轮时，旧轮次的迟到回复或音频不能覆盖当前状态。
**STAR｜简历事实：**S：HanLink 提供自由对话和剧情口语。T：我的职责包括语音输入、回复播报与剧情推进的整合。A：简历记载通过统一会话接口处理这些环节。R：可以介绍交付的功能范围；历史首包延迟、打断策略和具体协议字段需核对记录，不能用下面的设计建议冒充原实现。
第一层追问：用户在 TTS 播放时又开始说话，怎么办？
**直接答案：**先定义产品策略：允许打断则客户端停止当前播放、结束或废弃旧轮次，服务端尝试取消下游工作；无法取消的请求仍可能完成，因此要依靠轮次校验丢弃迟到结果。取消是请求，不是“外部服务一定没计费”的证明。
**STAR｜假设方案：**S：用户打断一个较长回复。T：避免两段音频同时播放或旧回复回灌。A：递增会话轮次，取消可取消工作并在每个回调核对轮次。R：新轮次交互不被旧音频覆盖，费用是否避免要看服务取消语义。
第二层追问：模型回复已显示，但 TTS 失败，算整轮失败吗？
**直接答案：**应有分阶段结果。文本可以保留，音频标记失败并允许重试或改用文本交互；剧情状态是否已推进需要单独定义，不能因音频重试再次推进剧情。文本生成、语音合成和业务动作应分别幂等。
**STAR｜假设方案：**S：模型成功回复但配音超时。T：保留已完成结果，避免整轮重复生成。A：保存文本和剧情决策，单独恢复音频步骤。R：用户可继续阅读，重复点击配音不产生第二次剧情转移。
分支追问：怎样定位“感觉很慢”？
**直接答案：**分解录音结束、ASR 完成、模型首 token、可播报片段、TTS 首音频、实际播放等时间点，同时观察失败和取消。只看模型总耗时可能忽略端侧录音等待、网络和音频缓冲。指标需用同一时钟域或说明跨端时钟误差。
**STAR｜假设方案：**S：用户反馈回复慢，但模型请求看似正常。T：找到用户感知瓶颈。A：为各阶段加入关联 ID 与时间记录，并抽样回放端侧事件。R：定位具体等待段再优化，不在没有测量时承诺降低多少秒。
**优秀回答：**区分会话轮次、消息显示、声音播放和剧情副作用。**常见误区：**TTS 失败就重新问模型；取消请求后旧结果不会返回；流式输出天然低延迟。
**实际源码：**迁移对照：system/app/providers.py::run_model()、system/app/media.py::external_bytes()、system/app/worker.py::run_once()；本包没有原口语系统或 ASR/打断实现。
**验证与实验：**机制对照 system/tests/test_system.py::test_incremental_edit_and_old_result_protection：观察迟到结果隔离思想，不能据此声称口语轮次已实现；手工画“打断后旧音频返回”的时序。
Q18 拍照识别答错了，重试还是换模型？
**考察目的：**输入质量、错误分类与路由。**难度：**中等。
**主问题：**你简历提到无效识图响应重试或节点切换，怎么判断“无效”？
直接答案与 STAR
要把图像输入问题、服务失败、输出结构错误和业务识别错误分开。模糊、遮挡或缺少题干的图片可能需要用户重拍；网络失败可按策略重试；字段缺失可有限修复；结构完整但识别对象错误需要内容校验、低置信提示或换模型，不能把“有字符串返回”当有效。
模型路由应由场景能力、质量评测、时延和预算决定，并设定总尝试上限。换节点不只是换 URL，还要确认请求格式、视觉输入方式、结构化输出和安全策略兼容。没有可验证真值时应保留不确定性，而不是强行生成答案。
**STAR｜简历事实：**S：HanLink 有拍照学习功能。T：处理不同识图场景与无效响应。A：简历记载按场景配置模型路由，对无效识图响应重试或节点切换。R：可以说实现了这条处理链；历史失败分类细节、模型名单与识别率需要补证据，下面的分类是面试设计方案。
第一层追问：第一个模型没看清，第二个模型返回很自信的答案，能直接采用吗？
**直接答案：**不能把语气当置信度。需要看是否识别出必要对象、是否与图像内容及任务约束一致，必要时请用户确认识别出的文本。对不清楚的图片，继续换模型可能只产生更多不同猜测。
**STAR｜假设方案：**S：手写题的一个数字模糊。T：避免模型自信地按错误数字解题。A：先展示识别出的题干并标记不确定位置，请用户确认或重拍。R：错误输入被纠正后才进入解题，不能仅以回答流畅作为成功。
第二层追问：路由到备用服务后费用更高，怎么控制？
**直接答案：**记录每次尝试和原因，限制单任务尝试数与总预算，对不可恢复输入尽早停止。根据固定样本评价“主服务一次”“主备组合”的整体质量和成本，防止低价主服务频繁失败导致总成本反而更高。
**STAR｜假设方案：**S：备用模型单次费用较高。T：把它用于真正有价值的兜底。A：只对定义好的可恢复错误路由，记录最终成功是否来自备用。R：用全链路费用和纠错情况决定规则，不只比较单模型标价。
分支追问：图片上传和模型调用之间，还需要考虑什么？
**直接答案：**文件类型、大小、解码是否真实有效、访问权限、链接有效期与必要的数据处理。上传返回 URL 不证明模型能够读取。错误日志不要泄露有访问凭据的 URL；对图像方向和压缩质量也要核对。
**STAR｜假设方案：**S：网页可显示图片，外部模型却读取失败。T：定位上传链路与服务可达性。A：检查实际请求方式、链接权限和过期时间，用受控样本验证。R：明确故障发生在取图而非识别模型，避免无效地切换模型。
**优秀回答：**不把重试当万能补丁，能解释输入错误与模型错误的区别。**常见误区：**返回非空就是有效；备用模型必然更准；任何失败都重试三次。
**实际源码：**迁移对照：system/app/providers.py::run_model()、system/app/media.py::external_bytes()；本包没有原拍照产品、多模型识图路由或图像质量检测实现。
**验证与实验：**机制对照 system/tests/test_adapters.py::test_bad_structured_output_budget、test_media_http_error_classification：分别阅读校验预算和 HTTP 分类；为图片不清、无效结果、鉴权失败、服务限流各写处理方案。
Q19 MQTT 断线重入，为什么只重连还不够？
**考察目的：**消息传递与业务状态的区别。**难度：**资深核心。
**主问题：**教师暂停课堂后学生设备断网，再连接时如何回到正确进度？
直接答案与 STAR
重连恢复的是连接，未必恢复完整课堂状态。应明确课堂的权威状态，如当前课时、步骤、暂停状态和状态版本。设备重入后获取快照，再处理快照之后的事件；命令需要课堂/会话身份、序号或版本，以及适用条件。客户端丢弃过期命令并对重复消息保持幂等。
MQTT 的 QoS 描述协议交付语义，不能代替业务“只抢答一次”或“进度不回退”的保证。Retained message 可以保存某主题最近一条消息，但不等同完整事件历史；持久会话也不能替代业务快照。具体方案还要匹配实际 MQTT 版本和 Broker 配置。
**STAR｜简历事实：**S：HanLink 的教师、投屏和学生端需要按教学脚本协作。T：支持暂停、继续与断线重入后的状态恢复。A：简历记载通过 MQTT 同步课堂指令和进度。R：可以介绍实现的功能；是否采用快照+事件、具体 QoS 和冲突策略需核对原记录，不能把建议方案当历史细节。
第一层追问：QoS 2 不是 exactly-once 吗，还用业务去重？
**直接答案：**QoS 2 的保证有协议层和会话边界，不等于整条业务链跨数据库、应用重试和多端副作用只执行一次。相同业务操作可能由应用再次发布，或跨会话出现。业务操作 ID、状态版本与幂等处理仍有价值。
**STAR｜假设方案：**S：教师端请求超时后重新发送“进入下一题”。T：避免课堂跳过两题。A：为同一业务意图使用相同操作 ID，服务端确认当前状态版本。R：重复发布不导致两次业务转移，不能仅依赖 Broker 的 QoS 设置。
第二层追问：先收到事件，后收到旧快照，会倒退吗？
**直接答案：**若没有版本控制会。可先建立同步屏障：获取快照及其版本，暂存后续事件，再应用高于快照版本的事件；或每次应用都校验单调版本。发现缺口则重新同步，不靠本地时间猜顺序。多发布者还需要定义权威仲裁。
**STAR｜假设方案：**S：网络乱序使 v12 事件先于 v10 快照到达。T：避免进度回退。A：按版本接收，拒绝旧快照覆盖，缺失的中间状态通过重新同步补齐。R：客户端最终与服务器权威状态一致，且有记录说明丢弃了哪些旧数据。
分支追问：抢答要按谁的时间排序？
**直接答案：**先明确公平性规则。不能直接相信客户端本地时钟；服务器接收顺序易实现但受网络延迟影响。更强公平要求需要额外时钟同步、延迟估计和明确产品规则。面试时应承认分布式网络条件下的限制，避免承诺绝对公平。
**STAR｜假设方案：**S：两个学生几乎同时提交抢答。T：给出可解释的排序。A：采用明确公布的服务端接受规则并保留事件顺序，处理重复与过期请求。R：排序可复查，但不宣称代表真实世界的绝对点击先后。
**优秀回答：**区分连接、会话、消息与业务状态，能处理乱序与重复。**常见误区：**QoS 2 解决全部一致性；retained 是历史消息队列；用客户端时间戳决定所有顺序。
**实际源码：**迁移对照：system/app/api.py::decide()、system/app/worker.py::recover_expired()、system/app/graph.py::run_workflow()；本包不含 MQTT 客户端、快照服务或 Broker。
**验证与实验：**机制对照 system/tests/test_system.py::test_stale_decision_and_termination_recovery、test_new_process_resumes_checkpoint；这些测试不能证明 MQTT 恢复。另画 v12 事件先于 v10 快照到达的处理。
Q20 如果教材任务增长十倍，先扩哪里？
**考察目的：**容量规划、背压、隔离与生产边界。**难度：**高。
**主问题：**不要先列技术栈，说明你会怎样判断瓶颈并扩容。
直接答案与 STAR
先量化任务到达率、各阶段服务时间、外部服务并发/速率配额、排队长度和失败比例。串行调用、模型配额、数据库检索、媒体 CPU 和存储都可能成为瓶颈；单纯增加 worker 可能把限流变得更严重。按阶段设置并发和背压，优先保证已接受任务可追踪、可取消、不会无限重试。
扩容前还要检查生产边界：身份认证、租户隔离、数据访问、密钥、审计和配额。本包定位学习复现，不能直接把本地操作入口暴露成公开生产服务。数据库任务表足以表达机制，但高负载下要测锁竞争、轮询和调度公平性，再决定是否引入专用队列或拆分媒体 worker。
**STAR｜假设方案：**S：业务提出任务量增长十倍。T：制定有测量依据的扩容方案。A：先按阶段采样，再通过并发限制、缓存复用、批处理或增加对应资源解决主瓶颈。R：验收是压力下质量、完成时间和费用可控；没有负载测试就不能报告支持多少并发。
第一层追问：能不能给一个粗略容量估算？
**直接答案：**可以，先声明假设。在稳态下，平均在途任务数约等于到达率乘以平均停留时间；某阶段所需并发粗估为该阶段到达率乘平均服务时间。还要留出波动空间并受供应商配额约束。这只是计划基线，不能代替实测，长尾与重试会改变需求。
**STAR｜假设方案：**S：需要在采购前估算资源。T：给出可修正的基线。A：列出任务率、每类外部调用数和媒体时长假设，计算各阶段并发。R：测量后更新模型，而非把估算数字写成历史吞吐量。
第二层追问：两个客户同时用，会不会检索到对方的资料？
**直接答案：**若只过滤等级、语言和地区，就没有租户隔离。生产需要由认证上下文确定租户，在所有读取、检索、任务与下载路径实施授权过滤，不能相信客户端传入的租户 ID。向量检索和引用回查也必须执行同样边界；必要时使用数据库行级策略作为纵深防护。
**STAR｜假设方案：**S：单用户学习系统扩展为多租户服务。T：防止跨租户资料和交付包泄露。A：建立认证到数据查询的授权链，加入两租户负向测试。R：越权请求返回拒绝且不泄露内容；未实现前明确不支持多租户生产使用。
分支追问：既然需要安全和扩容，为什么本次不全部实现？
**直接答案：**按目标管理范围。本次重点是教材 Agent 的完整学习链路与关键可靠性，不是生产 SaaS。应把已实现的机制、实验和生产缺口写清楚，而不是堆入半成品认证、计费和运维平台。架构保留边界，但不把“可扩展”当作已完成。
**STAR｜假设方案：**S：交付时间与学习目标有限。T：保证核心实现可理解且可验证。A：优先完成生成审校、资料、版本和恢复，将生产化要求单列验收范围。R：得到可运行的学习系统和明确升级清单，不交付看似全能的空壳。
**优秀回答：**先测量再扩容，会谈配额、背压和边界，不以组件堆叠回答规模问题。**常见误区：**worker 翻倍吞吐必然翻倍；元数据过滤等于授权；能本地跑就能公开上线。
实际源码：system/app/worker.py 的 claim()、heartbeat()；system/app/retrieval.py::retrieve()；system/app/api.py::auth()。
验证与实验：system/tests/test_system.py::test_expired_lease_and_fencing、test_api_auth_and_ui 仅验证局部机制；没有容量压测或多租户隔离验收。用评测说明区分测量与估算。
官方核对资料
核对日期：2026-11-03；历史项目的实际版本与协议设置仍需本人核对。