外观
Q13–Q16：素材、任务可靠性与评测
这组考察能否把概率性的模型能力放进可管理的工程系统。不要只讲 happy path；每道题都要求说明失败之后数据库、文件和外部服务分别处于什么状态。
Q13 图片、配音和视频为什么要有依赖关系？
**考察目的：**素材 DAG、内容版本、可复用边界。**难度：**核心。
**主问题：**一份审核通过的教材怎样变成可交付的图片、音频和视频？
直接答案与 STAR
先把批准的内容版本固定下来，再生成素材计划。图片通常依赖画面描述与图片参数，音频依赖朗读文本、语言和声音配置，视频依赖图片、音频、字幕和合成参数。相互独立的素材可以并发，视频必须等待依赖完成并核对输入版本。
Function Calling 让模型提出工具请求；程序校验请求并调度依赖；外部图片和 TTS 服务产生素材；FFmpeg 负责本地合成。这四个角色不能混淆。图片加配音字幕合成的视频是可播放的教材视频，不等于具有角色动作和复杂镜头的生成式视频。
交付前应核对内容版本、审批状态、素材类型、任务结果与文件存在性，并尽可能验证格式和时长。只有任务表写了成功但文件丢失，不算可交付。
**STAR｜学习复现：**S：教材需要同一版本的配套资源。T：让文本更新与素材更新有明确关系。A：建立依赖任务和输入指纹，先完成图片/音频，再合成视频并生成交付清单。R：验收证据是清单、可读取的资源和内容版本一致；演示图片或音频必须标记模拟，不能当成真实服务质量展示。
第一层追问：音频成功，视频失败，为什么不从生成课文重跑？
**直接答案：**故障影响范围是视频任务及其依赖条件，不是整个工作流。检查依赖仍有效后重试失败节点，复用成功素材；如果音频文件损坏则先修复该依赖。重跑整条链会增加费用，也可能产生不同内容，使版本关系更难管理。
**STAR｜学习复现：**S：人为让合成进程报错。T：验证局部恢复。A：保留图片和音频结果，只恢复视频任务，核对输入指纹未变化。R：已成功外部任务不被重新调用，最终视频仍关联原批准版本。
第二层追问：图片内容变了，但文本没变，如何判断视频是否需要更新？
**直接答案：**视频的依赖包含具体素材身份或内容哈希，而不仅是文本版本。替换图片会使视频输入指纹变化，即使教材文本版本不变，也应产生新的素材组合版本或重新合成。清单应记录实际使用的素材，不能只写“教材 v2”。
**STAR｜假设方案：**S：教研选择另一张更合适的配图。T：确保视频使用新图。A：更新选定素材引用，重新计算视频任务键并核对依赖。R：新视频清单指向新图，旧视频仍可追溯且不会冒充最新。
分支追问：字幕直接按字数平均分配时间可以吗？
**直接答案：**可作为明确标识的简化合成方案，但不是精确语音对齐。更好的方案使用 TTS 时间戳或强制对齐；也要考虑停顿、多语言断句和字幕长度。应说明当前实现边界并用实际播放检查，不能宣称逐字准确。
**STAR｜假设方案：**S：TTS 服务没有返回词级时间戳。T：先交付可用的学习视频。A：按段落分配时长并标记近似字幕，人工检查长句与停顿。R：以可读性和播放一致性验收；精确对齐列为后续扩展，不伪造能力。
**优秀回答：**能画出素材依赖、说明复用条件并承认视频能力边界。**常见误区：**只要 FFmpeg 退出码为 0 就绝对完整；文本不变就所有素材不变；模型负责执行任务调度。
实际源码：system/app/media.py 的 media_identity()、schedule_media()、make_video()、complete_delivery()、delivery_zip()。
验证与实验：system/tests/test_system.py::test_complete_revision_approval_delivery、test_corrupt_asset_blocks_delivery；system/tests/test_adapters.py::test_image_and_tts_contract；L01、L15。HTTP 契约成功不代表真实 TTS 音质验证。
Q14 外部服务超时了，到底重不重试？
**考察目的：**错误分类、结果不明、费用与幂等。**难度：**高。
**主问题：**图片服务 60 秒后没有返回，服务器重试会有什么风险？
直接答案与 STAR
超时意味着客户端没有在期限内拿到结果，不证明服务端没有执行。重新提交可能产生第二张图和第二次费用。先判断请求是否可能被接受，是否有供应商请求 ID、幂等键、状态查询或结果回调。能查询就先核对；有可靠幂等语义则使用同一业务键；不能确认时将任务标为结果不明，避免盲目自动重试。
重试还要分类：鉴权、无效参数和不支持的能力通常需要修配置或输入；限流、临时故障可在服务语义允许时退避并设置上限。5xx 也不天然证明没有副作用。重试预算包括次数、总耗时和成本，而不是一个无限循环。
**STAR｜学习复现：**S：模拟适配器接受请求后超时。T：验证系统不把未知结果当失败重发。A：保留业务请求键，进入核对或人工处理路径，记录每次尝试。R：以是否重复创建外部效果、是否清楚展示未知状态为证据；模拟只验证控制逻辑，真实服务语义需在线确认。
第一层追问：去重、幂等、重试分别是什么？
**直接答案：**重试是再次尝试完成操作；去重是识别重复请求或任务；幂等是重复执行产生与一次执行等价的业务效果。去重可能靠唯一键，幂等需要明确效果边界；二者都不能单靠客户端生成 UUID 就成立。业务键要表达相同意图，通常包含内容版本、素材类型与规范化输入。
**STAR｜学习复现：**S：同一批准触发两次相同素材请求。T：避免重复任务和重复交付。A：对相同语义使用相同任务键并检查数据库唯一约束，执行前后核对状态。R：数据库层业务任务不重复；外部收费是否幂等仍取决于服务契约。
第二层追问：为什么不把模型提示词全文直接作为幂等键？
**直接答案：**提示词里可能有时间戳、空白或无关排序，导致同一意图得到不同键；也可能遗漏模型、声音、图片尺寸等影响结果的配置。应规范化明确的业务输入后计算摘要，包含必要配置与内容版本。不能把敏感原文直接暴露在键或日志中。
**STAR｜假设方案：**S：用户只改了声音配置，却复用了旧音频。T：修正去重边界。A：将声音、语言、模型和文本纳入音频输入指纹。R：配置变更能产生新任务，相同规范化输入仍可复用。
分支追问：供应商没有查询接口，但用户坚持“立即再试”，怎么办？
**直接答案：**提供明确的人工确认操作，说明旧请求可能仍执行或计费，记录原因，并为新尝试建立可追踪关系。不能悄悄把“重试”标为完全安全，也不能把未知旧结果覆盖为从未发生。若之后旧结果到达，仍需版本和任务归属核对。
**STAR｜假设方案：**S：无法查到第一次请求结果，业务需要继续。T：让取舍可理解并可审计。A：展示未知状态与重复费用可能性，人工决定是否新建尝试。R：后续能区分两次外部请求及其结果，而非把额外费用藏在重试计数里。
**优秀回答：**明确超时的认知边界，会提出“先查再重试”及无法查询的处理。**常见误区：**超时就说明没执行；所有 5xx 可安全重试；生成随机 ID 即实现幂等。
实际源码：system/app/media.py 的 external_bytes()、reconcile()、UnknownOutcome；system/app/api.py::resolve()；system/app/worker.py::run_once()。
验证与实验：system/tests/test_adapters.py::test_real_media_timeout_is_unknown、test_media_http_error_classification；system/tests/test_system.py::test_unknown_external_result_not_silently_retried、test_media_timeout_bounded_retry；L11、L12。供应商查询未通用实现，本地回执核对不能找回供应商未知结果。
Q15 多个 worker 抢任务，如何避免旧结果覆盖新结果？
**考察目的：**租约、并发控制、版本隔离和崩溃恢复。**难度：**高。
**主问题：**一个 worker 卡住，另一个接管任务后，原 worker 又返回了，怎么办？
直接答案与 STAR
任务领取需要原子操作，例如在事务中锁定可领取任务并更新归属，避免两个 worker 同时认为自己拥有它。租约让进程失联后的任务有机会被重新领取，但租约过期不代表旧进程真的停止。
因此结果提交还要检查当前租约拥有者或递增的尝试/栅栏标识，并检查任务关联的内容版本。旧 worker 的结果可以保留诊断，但不能把新尝试状态或新版本素材覆盖掉。文件也应写到独立任务/尝试路径，再由有效提交更新清单，避免两个进程写同一最终文件。
**STAR｜学习复现：**S：某个任务执行时间超过租约后被接管。T：保证最多只有有效持有者能发布结果。A：构造先后两个领取者，延迟提交第一个结果，检查条件更新和资源关联。R：旧提交被拒绝，当前结果不变；这证明提交隔离，不说明外部服务绝无重复执行。
第一层追问：用了 SKIP LOCKED，还需要租约吗？
**直接答案：**行锁通常只保护领取事务。事务结束后，耗时外部执行并不持续持有这把锁。需要任务状态与租约记录谁在处理、何时可接管；不应为几分钟外部调用长期占用数据库事务。SKIP LOCKED 也不保证业务级公平性或无饥饿。
**STAR｜假设方案：**S：worker 领取后在外部调用时崩溃。T：让任务最终可重新处理。A：短事务领取并记录租约，到期后按策略接管。R：任务不会永久停在 running，但有副作用的任务仍需核对外部状态。
第二层追问：只检查教材版本不够吗？
**直接答案：**不够。同一教材版本的同一任务也可能有多个尝试，旧尝试可能在新尝试完成后返回。需要同时验证内容版本和任务执行身份；必要时还核对输入指纹和当前任务状态。只检查版本只能挡住跨版本覆盖，挡不住同版本旧尝试覆盖。
**STAR｜学习复现：**S：教材仍是 v2，但同一视频任务已由第二次尝试完成。T：拦截第一次尝试的迟到结果。A：比较尝试标识或租约拥有者，执行条件更新。R：迟到文件不进入有效资源清单，已有成功结果不倒退。
分支追问：那为什么不直接上 Redis/Celery？
**直接答案：**可以，但它们不能替你解决业务幂等、内容版本和外部未知结果。本项目选择数据库任务表是为了减少依赖并展示事务与状态；代价是需要自己实现调度、退避、租约和监控。更高吞吐或复杂调度可评估专门队列，仍保留业务不变量。
**STAR｜假设方案：**S：任务量增加造成数据库轮询压力。T：在不丢失业务保证的前提下扩容。A：测量瓶颈后引入队列分发，数据库仍是版本与任务结果的权威存储。R：以吞吐和故障演练验证收益，不以增加组件数量作为成熟度证明。
**优秀回答：**区分领取锁、租约与结果提交校验，知道至少一次执行与单次发布的差别。**常见误区：**锁过一次就不会重复；租约过期意味着进程已死；换队列自动解决幂等。
实际源码：system/app/worker.py 的 claim()、heartbeat()、recover_expired()、run_once()；system/app/media.py::run_media()。
验证与实验：system/tests/test_system.py::test_expired_lease_and_fencing、test_incremental_edit_and_old_result_protection；L10、L14。前者检查旧令牌更新为 0 行，后者检查旧版本任务成为 superseded。
Q16 怎样证明这套系统有效，而不是“演示看起来不错”？
**考察目的：**评测设计、质量成本权衡、证据意识。**难度：**资深核心。
**主问题：**你会用哪些指标比较检索、生成和评审方案？
直接答案与 STAR
先固定小规模样本、预期来源/问题标签和评判标准，区分开发调参集与至少一份保留验证集。检索看相关片段是否进入候选、排名和过滤正确性；生成看结构合规、内容正确、引用支持、地区/术语规则和可用性；评审看已知问题召回、误报与定位准确。端到端还看通过所需调用次数、人工介入、延迟和失败类型。
成本要区分估算与真实账单。可记录模型报告的 token 使用量、计价配置和素材请求数量进行估算，但不能把模拟 token 当真实费用。比较方案时固定输入、模型版本和配置，多次运行随机系统，记录失败样本；小样本结果不能外推生产规模。
**STAR｜学习复现：**S：准备比较有无检索或不同审校提示词。T：避免凭单个成功样例选方案。A：建立固定样本与评分准则，同时保留调用、耗时和成本记录。R：结论限定为本次样本与模式；只有实际报告的测量值可在面试中引用，模拟模式不能证明模型质量提升。
第一层追问：让一个更强模型打分不就够了吗？
**直接答案：**模型评审可扩大覆盖，但有偏差、位置效应和偏好相似表达等风险。需要校准样本、盲化方案标签、明确评分准则，并抽样人工复核；确定性约束直接程序检查。单一模型打分不应成为唯一真值。
**STAR｜假设方案：**S：模型裁判偏好更长的教材答案。T：防止分数掩盖教学难度不合适。A：把长度与等级作为独立维度，混入人工标注对照样本。R：比较模型与人工分歧，不能只公布平均分。
第二层追问：成本减少了，但质量稍降，怎么决策？
**直接答案：**先明确不可妥协约束和可接受质量阈值，再看成本/延迟。严重事实错误或地区违规不能用便宜抵消。可对低风险任务使用较轻模型，高风险或不确定样本升级处理；路由本身要评测并限制重复调用，避免“降级”变成更多费用。
**STAR｜假设方案：**S：低价模型在简单词汇生成上表现可用，但复杂审校漏检。T：控制成本同时保留关键质量。A：按任务类型与失败信号路由，固定样本比较总调用成本和漏检。R：只有满足质量底线的方案才进入成本比较。
分支追问：Demo 全通过，真实模式可以直接交付吗？
**直接答案：**不可以。Demo 证明状态转移、权限、版本和异常路径等可控逻辑；真实模式还要验证服务鉴权、请求契约、限流、超时、输出质量、使用量和文件格式。真实凭据缺失时应交付适配器与验证清单，明确尚未在线验证，不偷偷回退为模拟成功。
**STAR｜学习复现：**S：本地不具备所有外部服务凭据。T：让交付范围准确。A：完成可离线的测试，列出真实服务逐项验证步骤和失败条件。R：报告分别标明模拟、真实和未验证，面试时不把适配代码存在等同线上跑通。
**优秀回答：**指标与错误类型对应，有样本边界和证据来源，会把成本与质量同时比较。**常见误区：**模型自评高就有效；模拟全通过就代表真实服务可用；只报平均延迟不报失败。
实际源码：system/app/providers.py::run_model()、system/app/db.py::event()；system/scripts/evaluate.py 的固定评测主流程；样本 system/samples/evaluation.json。
验证与实验：system/tests/test_adapters.py::test_missing_usage_is_unknown_cost、test_no_credentials_never_falls_back；固定评测。适配器测试使用 MockTransport，质量结论还需真实模型与人工评测。
官方核对资料
核对日期：2026-11-03。外部服务的幂等和计费边界必须以实际选定服务契约为准。
资料核验说明：FFmpeg 官方页面在本次访问中超时，保留官方入口；其在线内容未完成核对。具体合成命令是否实际执行，以本包验收报告为准。