面试题库

14 天用 Agent 搭一条 AI 短剧生产线

D1 一条 AI 短剧生产线长什么样：工序拆解、任务图架构与四类生成模型选型

• 把一条多步生成流程建成任务图，比一串顺序 await 多拿到了什么？代价是什么？What does modeling a multi-step generation pipeline as a task graph buy you over a chain of sequential awaits, and what does it cost?

  国内高频海外高频进阶#task-graph#pipeline-design

  分析过程 · 先想清楚再作答

  1. 这题的题眼在「多拿到了什么」，不在「什么是 DAG」。背出有向无环图定义的人拿不到分，答对的人会给出三样顺序版拿不到的能力，并各配一个具体场景。
  2. 怎么拆：把顺序版的三个痛点倒过来说。第一，并行的可能性被图结构直接表达——配音只依赖台词、和画面无关，顺序版里它却要排在四十次视频生成后面。第二，有断点——每个节点的产物落在磁盘固定位置，第三十七个镜头失败时前三十六个还在。第三，可观测——你能回答「现在卡在哪个节点」，顺序版只能回答「卡在某个 await」。
  3. 补一条区分度更高的：环检测。拓扑排序在发现依赖成环时抛错，这是「无环」两个字唯一的执行者；没有它，依赖写错只会表现成漏跑一步或者顺序错乱，非常难查。
  4. 结论与代价：任务图不是免费的，你必须为每个节点定义清楚输入产物与输出产物，否则它只是一张漂亮的依赖声明。这份产物契约同时也是后面做幂等与断点续跑的前提。
  5. 可预期的追问：那是不是应该直接上工作流引擎？判据是节点数与失败率——十几个节点、失败率高、需要人工介入时才值得；三五个节点的流程用一张手写的图加拓扑排序就够，引入引擎反而多一套要运维的东西。

  How to reason about it · think before answering

  1. The question is what you gain, not what a DAG is. Reciting the definition scores nothing; name three capabilities the sequential version cannot have, each with a concrete scenario.
  2. Break it down by inverting the three pains of sequential code. First, parallelism is expressed by the graph itself — voice-over depends only on the lines, yet a sequential run queues it behind forty video jobs. Second, resumability — each node writes artifacts to a fixed path, so shot 37 failing does not destroy the first 36. Third, observability — you can say which node is stuck, not merely that some await is pending.
  3. Add the higher-signal point: cycle detection. Topological sort throws when dependencies form a cycle, and that is the only thing enforcing the acyclic part. Without it, a wrong dependency silently skips a step or reorders execution, which is painful to debug.
  4. Conclusion and cost: a task graph is not free. Every node needs a declared input and output artifact set, otherwise the graph is decorative. That artifact contract is also the precondition for idempotency and resume later on.
  5. Likely follow-up: should you adopt a workflow engine instead? Judge by node count and failure rate — worth it at a dozen-plus nodes with high failure and human review; for three to five nodes a hand-written graph plus topological sort is cheaper than another system to operate.

  答题要点

  • 三样顺序版拿不到的：并行由图结构表达、失败后有断点、能说清卡在哪个节点
  • 拓扑排序顺带做环检测，这是「有向无环」里「无环」的唯一执行者
  • 代价是必须为每个节点声明输入产物与输出产物，否则图只是装饰
  • 这份产物契约同时是后续做幂等与断点续跑的前提
  • 上不上工作流引擎按节点数与失败率判断，三五个节点手写图更划算

  Key points

  • Three things sequential code cannot give: parallelism expressed by structure, resumability after failure, and knowing which node is stuck
  • Topological sort also detects cycles, the only mechanism enforcing the acyclic property
  • The cost is declaring input and output artifacts per node; without that the graph is decorative
  • That artifact contract is the precondition for idempotency and resume
  • Adopt a workflow engine based on node count and failure rate; a hand-written graph wins for three to five nodes

D2 剧本 Agent：把一句话变成人物卡、场景与分镜的结构化数据

• 多集内容要保持人物设定一致，你会把这份设定放在哪、怎么用？To keep character definitions consistent across many episodes, where do you store that state and how do you use it?

  国内高频海外高频进阶#state-management#consistency

  分析过程 · 先想清楚再作答

  1. 这题的题眼是「模型没有记忆」。答成「把前一集的输出拼进上下文」的人会被追问到崩——上下文会随集数线性膨胀，第五集时你在为前四集的全文反复付费，而且模型仍然可能漏读。
  2. 怎么拆：先分辨哪些是「跨集不变」的，哪些是「每集重算」的。不变的是世界观、人物外貌、性格、音色与几条硬规则；每集重算的是场景与分镜。把不变的那部分抽成单独的档案文件，每一集生成前原样读进去。
  3. 接着说一个容易被忽略的点：档案里的字段不只是设定，还是**下游的输入参数**。外貌描述要原样进图像提示词，音色 id 要原样进语音接口。所以它们必须和名字放在同一份档案里，一致性问题才是在一个文件里解决的，而不是散在三处各写一遍。
  4. 存放位置的判据是写入频率：档案一次生成、多次读取，分镜每跑一次就重写。生命周期不同的数据放同一个文件，你就没法只重跑一集而不动其他集。按写入频率切分文件，是这类流水线最省事的一条习惯。
  5. 结论与代价：档案本身也会漂——中途改了人物外貌，之前生成的资产就对不上了。所以档案要有版本，且资产的缓存键要包含档案版本，改档案等于让相关资产失效。这条也是把它单独存放才做得到的。
  6. 可预期的追问：那要不要上向量库做检索？多数情况下不需要。跨集共享的设定是**有限的、结构化的、必须全量注入的**，检索反而可能漏掉关键一条。检索适合的是「素材库很大且只需要相关几条」的场景。

  How to reason about it · think before answering

  1. The crux is that models have no memory. Answering just concatenate previous episodes into the context invites a fatal follow-up: context grows linearly with episode count, so by episode five you pay repeatedly for four full episodes, and the model may still miss details.
  2. Break it down by separating what is invariant across episodes from what is recomputed each time. Invariant: the world, each character's appearance, personality, voice id, and a few hard rules. Recomputed: scenes and shots. Extract the invariant part into its own file and load it verbatim before generating each episode.
  3. Add the commonly missed point: the fields in that file are not only lore, they are downstream input parameters. Appearance text goes straight into image prompts, the voice id goes straight into the speech API. Keeping them beside the name means consistency is solved in one file rather than restated in three places.
  4. Choose the storage boundary by write frequency: the profile is written once and read many times, while the shot list is rewritten on every run. Mixing lifetimes in one file makes it impossible to rerun one episode without disturbing the others.
  5. Conclusion and cost: the profile itself can drift. Change a character's appearance mid-season and previously generated assets no longer match, so version the profile and include that version in the asset cache key — editing the profile then invalidates exactly the affected assets. That is only possible because it lives on its own.
  6. Likely follow-up: should you use a vector store? Usually not. Cross-episode canon is small, structured, and must be injected in full; retrieval risks dropping the one line that matters. Retrieval fits large corpora where only a few relevant items are needed.

  答题要点

  • 模型没有记忆，跨集一致性靠外部档案而不是把前几集拼进上下文
  • 按「跨集不变」与「每集重算」切分：世界观与人物卡是档案，场景与分镜每集重来
  • 档案里的外貌与音色 id 同时是下游的输入参数，所以必须和名字放在一起
  • 按写入频率切分文件，档案读多写少，分镜每次重写，混在一起就没法只重跑一集
  • 档案要有版本并进资产缓存键，改设定才能精确地让相关资产失效

  Key points

  • Models are stateless; cross-episode consistency comes from an external profile, not from stuffing prior episodes into context
  • Split by invariant versus recomputed: world and character profiles persist, scenes and shots are regenerated per episode
  • Appearance text and voice id are downstream input parameters, so they belong beside the character's name
  • Split files by write frequency — a read-mostly profile versus a rewritten shot list — or you cannot rerun one episode alone
  • Version the profile and fold that version into the asset cache key so edits invalidate exactly the affected assets

D3 角色一致性：定妆图、参考图与风格锁定，让同一个人每一镜都还是他

• 固定随机种子能解决角色一致性吗？它到底锁住了什么？Does fixing the random seed solve character consistency? What does a seed actually lock?

  国内高频海外高频进阶#image-generation#reproducibility

  分析过程 · 先想清楚再作答

  1. 这是一道判断题伪装成的概念题，答「能」直接出局。题眼是「到底锁住了什么」——面试官在测你有没有把复现和一致这两件事分开。
  2. 先给定义：seed 是采样的随机起点。在模型、提示词、其余参数都不变的前提下，同一个 seed 会给出同一张图，所以它锁住的是**可复现性**。
  3. 再说为什么在短剧场景里不够用：每一镜的提示词天然不同，动作、场景、景别都在变。提示词一变，采样路径就换了，同一个 seed 出来的是完全不同的人。所以 seed 是复现开关，不是一致性开关。
  4. 但不要把它说成没用。它在两个地方非常值钱：调试时做单变量对照，只改一个词看画面怎么变；以及跟参考图叠加使用，参考图管脸，seed 管其余自由度的采样起点，两者一起才让整组图像同一天在同一个棚里拍的。
  5. 生产视角补一句：想让 seed 真的可复现，必须把提示词优化开关关掉。那个开关默认是开的，它会在服务端改写你的提示词，改写结果你看不到，可复现性也就没了。
  6. 可以预期的追问：那不同厂商的 seed 语义一样吗？答案是不保证，换厂商甚至换模型版本都可能让同一个 seed 出别的图，所以 seed 不能作为跨厂商的一致性依据——这也是要有一层 provider 抽象的原因之一。

  How to reason about it · think before answering

  1. This is a yes/no trap dressed as a concept question; answering 'yes' ends it. The hinge is 'what does it actually lock' — they are testing whether you separate reproducibility from consistency.
  2. Define it first: a seed is the random starting point of sampling. With the model, prompt and other parameters unchanged, the same seed returns the same image, so what it locks is reproducibility.
  3. Then explain why that is not enough here: every shot has a different prompt because action, scene and shot size all change. Change the prompt and the sampling path changes with it, so the same seed yields a different person. A seed is a reproducibility switch, not a consistency switch.
  4. Do not dismiss it though. It earns its place twice: single-variable debugging, where you change one word and watch the image move; and stacked with a reference image, where the reference holds the face and the seed holds the remaining degrees of freedom so a whole set looks shot on the same day.
  5. One production note: for a seed to actually reproduce anything, turn the prompt optimizer off. It defaults to on, rewrites your prompt server-side, and you never see the rewrite — which destroys reproducibility.
  6. Expect the follow-up: is seed semantics the same across vendors? No guarantee — switching vendor or even model version can make the same seed produce something else, which is one more reason to keep a provider abstraction layer.

  答题要点

  • 不能。seed 锁的是可复现性：模型、提示词与其余参数都不变时，同一个 seed 给出同一张图
  • 短剧每一镜的提示词天然不同，提示词一变 seed 就失效，所以它不是一致性手段
  • 它真正的用处是单变量调试，以及与参考图叠加——参考图管脸，seed 管其余自由度的采样起点
  • 要让 seed 可复现，必须关掉服务端的提示词优化开关，它默认开启且会改写你的输入
  • seed 语义不跨厂商也不跨模型版本，不能作为跨 provider 的一致性依据

  Key points

  • No. A seed locks reproducibility: same model, same prompt, same other parameters plus same seed returns the same image
  • Every shot in a drama has a different prompt, and a changed prompt voids the seed, so it is not a consistency mechanism
  • Its real value is single-variable debugging, and stacking with a reference image — the reference holds the face, the seed holds the rest
  • For a seed to reproduce anything you must disable the server-side prompt optimizer, which is on by default and rewrites your input
  • Seed semantics do not carry across vendors or model versions, so a seed cannot underpin cross-provider consistency

D4 从分镜到镜头：图生视频、异步任务轮询与失败重试

• 让你实现一个异步生成任务的客户端，你会考虑哪些失败情况？You are asked to implement a client for an asynchronous generation task. Which failure cases would you cover?

  国内高频海外高频进阶#async-task#error-handling

  分析过程 · 先想清楚再作答

  1. 这题的区分度不在代码，在你能列出多少种失败。只答「加个 try catch 和重试」的人，通常没在生产上跑过这类接口。
  2. 先把任务的形状说清楚，失败点才有地方挂：提交拿标识、轮询查状态、取件换地址、下载落盘，四步是四类不同的失败。
  3. 然后逐步列：提交阶段有限流、鉴权、参数无效、内容审核；轮询阶段有查询接口自己限流、状态一直不前进、任务返回失败终态；取件阶段有标识存在但取不到地址；下载阶段有地址过期、下到一半断流、写盘失败。
  4. 接着说横跨全程的两类：超时与进程重启。超时的关键在于它不是失败而是「不知道成没成」，必须先按幂等键查一遍再决定要不要重提；进程重启意味着内存里的任务标识没了，所以标识必须先落盘再发请求，否则你会有一批花了钱却找不回来的任务。
  5. 最后给一句能体现工程判断的话：这四步里只有下载是可以无脑重试的，其余每一步的重试都可能产生一次新的计费。
  6. 可以预期的追问：厂商提供回调了还需要轮询吗？需要。回调会因为服务重启、网络抖动、地址不可达而丢失，生产上的标准做法是回调为主、低频轮询兜底扫描长时间没有终态的任务。

  How to reason about it · think before answering

  1. The differentiator here is coverage, not code. Answering 'wrap it in try/catch and retry' usually means you have never run this kind of API in production.
  2. Describe the shape first so the failures have somewhere to hang: submit and get an id, poll for status, retrieve a URL, download to disk — four steps, four families of failure.
  3. Then enumerate: at submit, rate limiting, auth failure, invalid parameters, content moderation; at poll, the query endpoint rate limiting you, a status that never advances, or a terminal failure; at retrieve, a valid id that yields no URL; at download, an expired link, a stream cut halfway, a disk write error.
  4. Then the two that span the whole flow: timeout and process restart. A timeout is not a failure, it is 'I don't know' — you must look up the idempotency key before resubmitting. A restart means in-memory task ids are gone, so the id has to be persisted before or immediately after the request, or you will have paid-for tasks you can never reclaim.
  5. Close with a line that shows judgment: of the four steps, only the download is safely retryable on its own; a retry at any other step can create a new billable job.
  6. Expect the follow-up: if the vendor offers callbacks, do you still poll? Yes. Callbacks get lost to restarts, network blips and unreachable endpoints, so the standard is callback-first with a low-frequency sweep for tasks stuck without a terminal state.

  答题要点

  • 按四步拆失败：提交（限流、鉴权、参数无效、内容审核）、轮询（查询限流、状态停滞、终态失败）、取件（拿不到地址）、下载（地址过期、断流、写盘失败）
  • 超时不是失败而是状态未知，重试前必须先按幂等键查一遍已有产物，否则会为同一个任务付两次钱
  • 任务标识要及时落盘，进程重启后才能把在途任务认回来
  • 四步里只有下载可以无脑重试，其余每一步的重试都可能产生新的计费
  • 有回调也要保留低频兜底轮询，回调会丢

  Key points

  • Break failures down by the four steps: submit (rate limit, auth, invalid params, moderation), poll (query rate limit, stalled status, terminal failure), retrieve (no URL), download (expired link, cut stream, disk error)
  • A timeout means unknown, not failed: look up the idempotency key for an existing artifact before resubmitting, or you pay twice
  • Persist the task id promptly so in-flight tasks survive a process restart
  • Only the download is safely retryable on its own; retries at the other steps can create new billable jobs
  • Keep a low-frequency polling sweep even when callbacks exist, because callbacks get lost

D5 配音、字幕与音轨：多角色语音、时间轴对齐与字幕文件

• 语音时长和画面时长对不上，你会调哪一边？为什么？When the synthesized speech and the shot duration disagree, which side do you adjust, and why?

  国内高频海外高频进阶#timeline#tts#pipeline-design

  分析过程 · 先想清楚再作答

  1. 这题只答「调画面」拿不到分，题眼在「为什么」——面试官要的是让步理由，以及你有没有意识到这个选择会决定整条流水线的排列顺序。
  2. 先给判断依据：哪一边的失真观众察觉得到。台词被切掉、或者被加速到语气变形，观众立刻听得出来；一镜比原计划长零点八秒，观众感觉不到。所以让步的是画面。
  3. 由这条判断反推流水线顺序：画面先按计划时长生成，语音合成完之后由真实时长回写镜头时长，剪辑台再去补足画面。为什么不倒过来先合成语音再按语音时长生成视频？因为视频接口的时长是有限档位的，你没法要求它精确生成 6.34 秒。
  4. 补一条不能省的工程细节：写进时间轴的必须是从落盘文件量出来的真实时长，不能是字数估算。估算误差是逐句累加的，第一句差两百毫秒，第十句就差两秒，成片上表现为字幕跟画面赛跑。
  5. 再说例外，这是加分项：如果这一镜的画面本身有强节奏（比如卡点、转场、动作衔接），画面就不能被随意拉长，这时候要回头改剧本把台词写短，而不是硬拉画面。所以被顶长的镜头应该被标记出来交给人复核，而不是程序默默改掉。
  6. 可以预期的追问：那不能微调语速吗？可以，但语速是有代价的——语速改变会同时改变音质与情绪表现，而且它会反过来再改一次时长，等于把一个单向流程变成了循环。留一点余量的做法是给留白参数一个可调区间，先动留白再动语速。

  How to reason about it · think before answering

  1. Answering 'stretch the shot' alone scores nothing; the hinge is 'why'. They want the reasoning for which side yields, and whether you see that this choice fixes the order of the whole pipeline.
  2. State the criterion: which distortion does the audience notice? Clipped or sped-up dialogue is audible immediately; a shot running 0.8 seconds long is not. So the picture yields.
  3. Derive the pipeline order from that: generate video at the planned duration, synthesize speech, write the measured duration back onto the shot, and let the editor pad the picture. Why not synthesize first and generate video to fit? Because video APIs expose discrete duration options — you cannot ask for exactly 6.34 seconds.
  4. Add the engineering detail that cannot be skipped: the timeline must use durations measured from the rendered files, never character-count estimates. Estimation error accumulates line by line, and by the tenth line the subtitles visibly race the picture.
  5. Then the exception, which earns points: if a shot has intrinsic rhythm — a beat cut, a transition, an action match — the picture cannot simply be stretched, and the right fix is a shorter line in the script. That is why stretched shots should be flagged for human review rather than silently rewritten.
  6. Expect the follow-up: can't you just nudge the speaking rate? You can, but it costs you — rate changes affect timbre and delivery, and they change duration again, turning a one-way flow into a loop. Make the lead-in and tail padding adjustable and spend that budget before touching the rate.

  答题要点

  • 调画面：台词被切或被加速观众立刻察觉，镜头长零点几秒观众感觉不到
  • 由此定下流水线顺序：画面按计划时长生成，语音合成后回写真实时长，剪辑台补足画面
  • 不能倒过来按语音时长生成视频，因为视频接口的时长只有有限档位
  • 时间轴必须用落盘文件量出的真实时长，字数估算的误差会逐句累加
  • 画面有强节奏的镜头是例外，这类冲突应标记出来交人复核而不是程序默默改掉

  Key points

  • Stretch the picture: clipped or sped-up dialogue is instantly audible, while a fraction of a second of extra shot length is not
  • That fixes the pipeline order: generate video at planned duration, synthesize speech, write measured duration back, pad in the edit
  • You cannot invert it and generate video to match speech, because video APIs only expose discrete durations
  • The timeline must use durations measured from rendered files; character-count estimates accumulate error line by line
  • Shots with intrinsic rhythm are the exception, so flag stretched shots for human review instead of silently rewriting them
• 字幕的时间戳你会怎么拿？接口不给时间戳时有什么替代方案？Where do you get subtitle timestamps from, and what do you do when the API does not provide them?

  国内高频海外高频进阶#subtitles#timeline

  分析过程 · 先想清楚再作答

  1. 这题在考你会不会为一个可有可无的厂商字段引入依赖。两条路都要说得出来，还要说清各自的代价，只答一条会被追问到底。
  2. 第一条是接口给：语音合成接口通常有一个字幕开关，返回按句或按词的时间戳。它的问题有三个——要多发一次请求去取内容、时间戳是相对单段音频的、字段结构随厂商变化。第三条最要命，因为它让你的字幕模块和某一家厂商绑死了。
  3. 第二条是本地对齐：你手里已经有每段音频的真实时长和每一镜的起始时刻，累加就是整集时间轴。它零额外请求、零厂商依赖，而且断句由你自己控制——按台词行断，一句一条，天然符合短剧节奏。
  4. 关键在于**就算用第一条也逃不掉第二条**：接口给的是段内相对时间，你仍然要加上这一镜在整集里的偏移。所以本地对齐这套代码无论如何都要写，那不如让它成为唯一的真相来源。
  5. 对齐的实现只有一个要点：字幕游标和镜头游标必须共用同一个原点，逐镜推进。再配一个自检——每条字幕必须落在它所属的那一镜内，越界不会报错，只会让上一镜的台词飘到下一镜的画面上。
  6. 可以预期的追问：那按词级时间戳做卡拉OK式字幕呢？那种效果确实必须依赖接口的词级时间戳，本地对齐做不了。这时的正确做法是把它做成一个可选增强，主链路仍然走本地对齐，拿不到词级数据就降级成句级。

  How to reason about it · think before answering

  1. This tests whether you would take a dependency on an optional vendor field. Name both paths and their costs; giving only one invites a follow-up you will not enjoy.
  2. Path one is the API: TTS endpoints often expose a subtitle flag returning sentence- or word-level timestamps. Three problems — it costs an extra request to fetch, the timestamps are relative to that single audio segment, and the field structure varies by vendor. The third is the worst, because it welds your subtitle module to one provider.
  3. Path two is local alignment: you already hold every clip's measured duration and every shot's start time, so accumulating them gives the episode timeline. Zero extra requests, zero vendor coupling, and you control segmentation — one line of dialogue per cue, which is exactly the rhythm short drama wants.
  4. The key insight is that path one does not free you from path two: API timestamps are segment-relative, so you still add the shot's offset within the episode. Since you must write the alignment code anyway, make it the single source of truth.
  5. The implementation has one rule: the subtitle cursor and the shot cursor share one origin and advance together. Add a check that every cue falls inside its own shot — overflow raises no error, it just floats the previous shot's line over the next shot's picture.
  6. Expect the follow-up: what about karaoke-style word-level subtitles? That genuinely requires word-level timestamps from the API. Treat it as an optional enhancement over a local-alignment main path, degrading to sentence level when word data is unavailable.

  答题要点

  • 两条来源：接口返回的时间戳，以及由音频真实时长本地累加对齐
  • 接口那条的代价是多一次请求、时间戳只相对单段音频、字段结构跟厂商绑定
  • 本地对齐零额外请求零厂商依赖，断句按台词行控制，符合短剧节奏
  • 即使用接口时间戳也仍要自己加上这一镜在整集里的偏移，所以本地对齐代码无论如何都得写
  • 实现要点是字幕游标与镜头游标共用同一原点，并自检每条字幕是否落在它所属的镜头内

  Key points

  • Two sources: timestamps returned by the API, and local alignment accumulated from measured audio durations
  • The API path costs an extra request, gives segment-relative timestamps, and couples you to one vendor's field structure
  • Local alignment needs no extra request and no vendor coupling, and lets you segment per line of dialogue
  • Even with API timestamps you must add each shot's offset within the episode, so the alignment code is unavoidable anyway
  • The implementation rule is one shared origin for the subtitle and shot cursors, plus a check that each cue stays inside its own shot

D6 剪辑台：用 ffmpeg 把素材合成一集竖屏成片

• 一集自动生成的短剧成片出现音画不同步，你的排查顺序是什么？为什么是这个顺序？An auto-generated episode comes out with audio and video out of sync. What is your debugging order, and why that order?

  国内高频海外高频进阶#debugging#av-sync#timeline

  分析过程 · 先想清楚再作答

  1. 这题的题眼在「顺序」两个字，不在「有哪些原因」。面试官想看的是你会不会按「命中率乘以排查成本」来排，而不是把想到的原因罗列一遍。
  2. 先问自己一个问题：这条流水线上，时间是从哪里来的？如果答案是「一张结构化的时间轴表」，那么第一步必然是拿表里的计划时长和素材文件的真实时长去对——这一步命中率最高、成本最低，一条 ffprobe 就能查完。
  3. 第二步查上游的产物本身：配音时长超过镜头时长时，台词会被截断，听感和不同步几乎一样，但根因完全不同。这类冲突应该在生成时间轴时就打警告，而不是留到成片阶段靠耳朵发现。
  4. 第三步才查合成环节：流拷贝拼接要求各段参数一致，时间戳对不齐就会错位；加了转场则成片整体变短，字幕若没跟着重算，表现为越到后面偏得越多。
  5. 还有一条通用招式值得说出来：三步都查不出来时，不要在成片里死磕，去播归一化之后的单镜片段，把问题缩小到某一镜身上。排查多段合成的问题永远优先缩小范围。
  6. 可预期的追问是「怎么让这类问题不再靠人耳发现」。答：在时间轴生成阶段加断言（计划时长与素材真实时长的偏差超过阈值就失败），并把成片时长与时间轴总时长的一致性做成自动校验。

  How to reason about it · think before answering

  1. The question is about ordering, not about listing causes. The interviewer wants to see you rank checks by hit rate divided by cost, not enumerate everything you can think of.
  2. Ask yourself first: where does time come from in this pipeline? If the answer is 'a structured timeline table', then step one is comparing planned durations in that table against the real durations of the media files. Highest hit rate, lowest cost, one ffprobe call.
  3. Step two is the upstream artifacts: when the voice track is longer than the shot, the line gets cut off. It sounds almost identical to drift but the root cause is different, and it should have been caught with a warning when the timeline was built.
  4. Step three is the compose stage: stream-copy concatenation requires identical parameters across segments, and misaligned timestamps shift things; adding crossfades shortens the final cut, so subtitles drift progressively unless their timecodes are recomputed.
  5. Also mention a general move: when all three fail, stop staring at the final cut and play the normalized per-shot segments to narrow the problem to one shot. Always shrink the search space before guessing.
  6. Expect the follow-up 'how do you stop relying on human ears'. Answer: assert at timeline-build time when planned and actual durations diverge beyond a threshold, and automatically verify that the final cut's duration matches the timeline total.

  答题要点

  • 先查时间轴表里的计划时长与素材真实时长是否一致，这一步命中率最高、成本最低。
  • 再查配音是否超出镜头时长导致台词被截断，这类问题应在生成时间轴时就报警告。
  • 最后查合成环节：拼接方式、时间戳对齐、转场是否让成片变短而字幕没重算。
  • 三步之外的通用招式：播单镜片段把问题缩小到某一镜，不要盯着最终产物猜。
  • 长期方案是把时长一致性做成断言与自动校验，不靠人耳兜底。

  Key points

  • Start with the timeline table: compare planned durations against the media files' real durations. Highest hit rate, cheapest check.
  • Then check whether the voice track exceeds the shot duration and truncates the line. That should be warned about at timeline-build time.
  • Only then look at compose: concat method, timestamp alignment, and crossfades shortening the cut without recomputed subtitle timecodes.
  • General move: play the per-shot normalized segments to isolate one shot instead of guessing on the final cut.
  • Long term, turn duration consistency into assertions and automated checks rather than relying on ears.

D7 一集杀青：把六个环节串成端到端流水线并算清第一笔账

• 一条多步骤的生成流水线，中间某一步失败了，你希望系统有什么行为？In a multi-step generation pipeline, one step fails. What behavior do you want the system to have?

  国内高频海外高频进阶#pipeline-reliability#idempotency#error-handling

  分析过程 · 先想清楚再作答

  1. 这题的区分度在于你会不会分层回答。只说「重试」的人默认失败都是瞬时的；真正做过的人会先问一句：这次失败是可重试的还是不可重试的，因为这一条决定了后面所有动作。
  2. 先把行为拆成三层：立刻要做的、这一次运行要做的、下一次运行要做的。立刻要做的是错误分类与有界重试，只有限流、超时、五开头这类瞬时错误才值得退避重试，鉴权失败、余额不足、内容审核不通过重试一百次也是白烧钱。
  3. 这一次运行要做的是保住已经产生的价值：把已完成步骤的产物、耗时、花费全部落盘，包括失败那一步自己已经花掉的钱。一个直接向上抛的实现会把这些一起丢掉，而它们恰恰是复盘时最该看的。
  4. 下一次运行要做的是不重复花钱：每个节点算一个幂等键，产物按内容寻址落盘，重跑时先做一次差集，已完成的跳过、只补做没做完的。判据非常硬——第二次运行的付费接口调用次数应当是 0。
  5. 在生成式流水线里这一条比传统后端更要紧，因为单步成本高得离谱：本课量过一集的账，视频那一环占了全部花费的九成八，从头重跑一次就是白烧十块多，而且是必然的，不是偶然的。
  6. 可预期的追问是「幂等键里该放什么」。答：模型 id、提示词、时长分辨率这类会影响产物的输入，加上实现版本号和全部依赖的指纹；绝不能放运行标识、时间戳、随机数，放了就永远不命中。

  How to reason about it · think before answering

  1. The discriminator is whether you answer in layers. People who just say 'retry' assume all failures are transient. Anyone who has run one of these asks first: is this failure retryable, because that decides everything downstream.
  2. Split the behavior into three layers: what to do immediately, what to do for this run, and what to do for the next run. Immediately: classify the error and retry with bounds. Only rate limits, timeouts and 5xx deserve backoff; auth failures, insufficient balance and content-policy rejections will fail a hundred more times.
  3. For this run: preserve the value already produced. Persist artifacts, elapsed time and spend for every completed step, including the money the failing step itself already burned. An implementation that just rethrows loses exactly the data a post-mortem needs.
  4. For the next run: do not pay twice. Give every node an idempotency key, store artifacts content-addressed, and make a rerun a set difference — skip what is done, redo only what is not. The bar is hard: the second run should make zero paid API calls.
  5. This matters more in generative pipelines than in ordinary backends because per-step cost is extreme. Measured on one episode in this course, the video step is 98 percent of total spend, so a full rerun burns over ten yuan, predictably rather than occasionally.
  6. Expect the follow-up 'what goes into the idempotency key'. Answer: model id, prompt, duration and resolution — anything that changes the artifact — plus an implementation version and the fingerprints of all dependencies. Never the run id, a timestamp or a random value.

  答题要点

  • 先做错误分类：可重试的才退避重试，鉴权、余额、内容审核这类重试没有意义。
  • 失败时保住已完成步骤的产物、耗时与花费，失败那一步自己花的钱也要记。
  • 下一次运行靠幂等键与内容寻址的产物做差集，只补做没做完的部分。
  • 验收判据是第二次运行的付费接口调用次数为 0，而不是「日志里没报错」。
  • 生成式流水线单步成本极高，这一条的收益能直接换算成账单上的金额。

  Key points

  • Classify errors first: only retryable ones get backoff. Auth, balance and content-policy failures gain nothing from retries.
  • On failure, preserve completed steps' artifacts, timings and spend, including what the failing step itself already cost.
  • The next run uses idempotency keys and content-addressed artifacts to compute a set difference and redo only what is missing.
  • The acceptance bar is zero paid API calls on the second run, not 'no errors in the log'.
  • Per-step cost is extreme in generative pipelines, so this work converts directly into money on the bill.

D8 工作流引擎：把流水线做成可断点续跑的任务图

• 怎么让一个会调用付费接口的生成节点是幂等的？缓存键里该放什么、不该放什么？How do you make a node that calls a paid generation API idempotent? What belongs in the cache key and what does not?

  国内高频海外高频进阶#idempotency#caching#workflow-engine

  分析过程 · 先想清楚再作答

  1. 这题的区分度全在「不该放什么」那一半。只答「把输入哈希一下」的人，通常没在真实项目里被缓存坑过——缓存的两种病方向相反，一种是永远不命中，一种是命中了不该命中的。
  2. 先给判据：键里应该出现的，是所有会改变产物的东西；不该出现的，是所有每次都会变但不影响产物的东西。这一条能直接推出下面两张清单。
  3. 该放的四样：节点标识、实现版本号、本节点的输入（模型 id、提示词、时长、分辨率）、以及全部依赖的指纹。版本号和依赖指纹是最容易漏的两样——漏了版本号，改完代码读到旧产物；漏了依赖指纹，上游换了剧本你还在用旧的镜头。
  4. 不该放的：运行标识、时间戳、随机数、绝对路径、以及任何带机器名或临时目录的东西。放进去等于每次都是新键，你会以为缓存写坏了，其实是键设计错了。
  5. 还有两条落地细节值得主动说：判断「做没做完」要看磁盘上产物齐不齐，不能只信状态文件，因为文件可能被手删；以及幂等的粒度要想清楚，一个节点里跑四个镜头，第三镜失败就是四镜全重做，粒度更细更省钱但任务图会大很多。
  6. 可预期的追问是「依赖指纹会不会失效得太狠」。答：会。上游只是文案改了、产物其实一样，下游也会跟着重做。更省的做法是对依赖的产物内容做哈希而不是对它的键做哈希，代价是每次都要把产物读一遍——小文件划算，大视频不划算，这是要自己量的一笔账。

  How to reason about it · think before answering

  1. The discriminator is the second half: what must not go in. People who only say 'hash the inputs' have usually never been burned by a cache. The two failure modes point in opposite directions: never hitting, and hitting when it should not.
  2. State the criterion first: include everything that changes the artifact, exclude everything that changes every run without affecting the artifact. Both lists fall out of that.
  3. Include four things: node id, implementation version, this node's own inputs (model id, prompt, duration, resolution), and the fingerprints of all dependencies. The version and the dependency fingerprints are the two people forget — miss the version and new code reads old artifacts; miss the dependencies and an upstream script change never propagates.
  4. Exclude: run id, timestamps, random values, absolute paths, and anything carrying a hostname or temp directory. Any of those makes every key new, and you will blame the cache instead of the key.
  5. Two implementation details worth volunteering: decide 'is it done' by checking the artifacts on disk, not the state file, because files get deleted by hand; and think about granularity — four shots in one node means one failed shot redoes all four, while finer granularity saves money at the cost of a much larger graph.
  6. Expect the follow-up 'does hashing dependency keys over-invalidate'. Yes. An upstream wording change that produces an identical artifact still invalidates downstream. Hashing the dependency's artifact content instead is tighter but requires reading the artifact every time — worth it for small files, not for large videos.

  答题要点

  • 判据一句话：会改变产物的进键，每次都变但不影响产物的不进键。
  • 必放四样：节点标识、实现版本号、本节点输入、全部依赖的指纹。
  • 禁放：运行标识、时间戳、随机数、绝对路径与机器相关信息。
  • 命中判定看磁盘上产物是否齐全，不能只信状态文件。
  • 幂等粒度要显式选择：节点粒度实现简单，镜头粒度更省钱但图更大。

  Key points

  • One criterion: include what changes the artifact, exclude what changes every run without affecting it.
  • Must include: node id, implementation version, the node's own inputs, and all dependency fingerprints.
  • Must exclude: run id, timestamps, random values, absolute paths and host-specific data.
  • Decide cache hits by checking artifacts on disk, not by trusting the state file.
  • Choose the idempotency granularity explicitly: per node is simpler, per shot saves more but grows the graph.

D9 并发与配额：多集同时开机，还不能把厂商额度打爆

• 多个任务共用一家厂商的额度，你会怎么设计限流？Many jobs share one vendor's quota. How would you design the rate limiting?

  国内高频海外高频进阶#rate-limiting#concurrency#scheduling

  分析过程 · 先想清楚再作答

  1. 这题的题眼是「共用」两个字。只回答一个令牌桶算答了一半，面试官想听的是你按什么维度分桶、以及桶之外还需要什么。
  2. 先给维度：限流要按「厂商 + 接口类别」分桶，不能全局一个桶。同一家的图像和语音是两个独立的配额池，混在一起会让紧的那个把松的那个也拖住。
  3. 再给部件：一个桶不够，要两个。令牌桶管速率（一分钟发几次，数字是厂商定的），信号量管并发（同一时刻挂着几个，数字是你自己定的用来保护内存和钱包）。只有速率控制的话，快速返回的接口一分钟能发几百次；只有并发控制的话，二十个请求同时在飞会把内存挂满。
  4. 然后是关键的工程细节：拿许可的动作必须是非阻塞的。如果任务先被派出去、再在执行流里等令牌，工作槽会被一批低优先任务占死，优先级就静默失效了。正确结构是调度器派活之前先问闸门要许可，拿不到就跳过它去看下一个候选。
  5. 最后落到取值：并发上限不该按 CPU 核数定，这条线几乎没有本地计算，全在等网络；它该按「一次失败要重跑多少东西」和厂商配额来定。
  6. 可预期的追问是「桶的状态放哪」。单进程放内存就够；多进程要放 Redis，用一个原子脚本取令牌，否则每个进程各限各的，加起来照样超。

  How to reason about it · think before answering

  1. The hinge is the word shared. Naming a token bucket only answers half of it; the interviewer wants your bucketing dimension and what else sits around the bucket.
  2. Dimension first: bucket per vendor and per API family, never one global bucket. Image and speech quotas at the same vendor are separate pools, and merging them lets the tight one throttle the loose one.
  3. Then the parts: one bucket is not enough. A token bucket caps rate (calls per minute, a number the vendor sets); a semaphore caps concurrency (how many are in flight, a number you set to protect memory and spend). Rate alone lets a fast endpoint fire hundreds per minute; concurrency alone lets twenty downloads pile up.
  4. The engineering detail that decides everything: admission must be non-blocking. If a job is dispatched first and then waits for a token inside the worker, low-priority work pins every worker slot and priority silently stops working. Ask the gate before dispatch, and skip to the next candidate when it says no.
  5. Finally the numbers: concurrency should not track CPU cores, since this pipeline is almost all network wait. Derive it from vendor quota and from how much work one failure forces you to redo.
  6. Expected follow-up: where does bucket state live. In-memory is fine for one process; across processes it belongs in Redis behind an atomic token-take script, or each process limits itself and the sum still blows the quota.

  答题要点

  • 按「厂商 + 接口类别」分桶，一家的图像和语音各一道闸门。
  • 每道闸门两个部件：令牌桶控速率（厂商给的 RPM），信号量控并发（自己定的在飞上限）。
  • 准入必须非阻塞，拿不到许可就把任务留在队列里，绝不占着工作槽干等。
  • 先抢并发票再取令牌，顺序反了会白白扣掉配额。
  • 多进程部署时桶的状态要外置到 Redis，用原子操作取令牌。

  Key points

  • Bucket per vendor and per API family; image and speech at one vendor get separate gates.
  • Each gate has two parts: a token bucket for rate (the vendor's RPM) and a semaphore for in-flight concurrency (your own number).
  • Admission is non-blocking: if the gate says no, the job stays queued instead of holding a worker slot.
  • Take the concurrency slot before the token, or a rejected admission silently burns quota.
  • Across processes, move bucket state to Redis and take tokens atomically.

D10 审片室：能预览、能改词、能重生成单镜的人机协作后台

• 用户改了中间一步的输入，怎么算出哪些下游需要重做？A user edits an intermediate input. How do you compute which downstream steps must rerun?

  国内高频海外高频进阶#dag#incremental-recompute#cost

  分析过程 · 先想清楚再作答

  1. 这题的区分度在方向和收尾两处，很多人只答出中间那段「沿依赖图传播」，前后都丢了。
  2. 方向：从被改的节点**沿着「谁依赖我」正向传播**，不是往上游找依赖。写反的后果很隐蔽——上游会被一起重跑，结果是对的，钱多花了一倍，测试也发现不了。
  3. 落到实现：把种子节点放进集合，反复扫一遍图，只要某个节点的依赖里有一个已经在集合里就把它也加进来，跑到不动点为止；最后按拓扑序返回，调用方顺着数组跑就不会先跑下游后跑上游。
  4. 收尾这一步最容易漏：**没受影响的节点，产物要从上一版复制过来，不是重新生成**。半径算得再准，少了复制这一步就一分钱没省。
  5. 然后是怎么验证。不要比文件哈希——同样的输入很可能生成逐字节相同的结果，哈希相同证明不了没重跑。要数**接口调用次数**，这才是硬证据，而且在离线与真实两种模式下都成立。
  6. 可预期的追问是「输入没变但你想重跑怎么办」。留一个强制重跑的开关，并且把它和自动判定分开记账，否则你会分不清一次重跑是系统判的还是人手动点的。

  How to reason about it · think before answering

  1. The signal lives at the two ends. Most candidates produce the middle part, propagation over a dependency graph, and drop both the direction and the finish.
  2. Direction: propagate forward along who-depends-on-me from the edited node, not backward to its dependencies. Getting it backward is insidious, because upstream nodes rerun, the output is still correct, the bill doubles, and no test catches it.
  3. Implementation: seed a set, sweep the graph repeatedly adding any node with a dependency already in the set until it stops growing, then return in topological order so the caller can just walk the array.
  4. The finish is what people forget: unaffected nodes must have their artifacts copied from the previous version, not regenerated. A perfect radius saves nothing without that copy.
  5. Then verification. Do not compare file hashes, because identical inputs often produce byte-identical output and a matching hash proves nothing. Count API calls instead; that evidence holds both offline and against a real vendor.
  6. Expected follow-up: what about forcing a rerun when nothing changed. Keep an explicit force flag and account for it separately, or you lose the ability to tell system-decided reruns from human-triggered ones.

  答题要点

  • 从被改的节点沿着「谁依赖我」正向传播，不是反向找依赖。
  • 扫图到不动点，结果按拓扑序返回，保证执行顺序不会颠倒。
  • 没受影响的节点要从上一版复制产物，否则半径算得再准也没省钱。
  • 验证要数接口调用次数，不要比文件哈希——同样的输入可能产出逐字节相同的结果。
  • 另留一个强制重跑开关，并与自动判定分开记账。

  Key points

  • Propagate forward along who-depends-on-me from the edited node, never backward.
  • Sweep to a fixed point and return in topological order so execution never runs downstream first.
  • Copy artifacts for unaffected nodes from the previous version, or the computed radius saves nothing.
  • Verify by counting API calls, not by comparing file hashes, since identical inputs can produce byte-identical output.
  • Keep a separate force-rerun switch and account for it apart from automatic decisions.
• 版本回滚要存什么？只存最终产物够不够？What must a version record hold for rollback? Are the final artifacts enough?

  国内高频海外高频进阶#versioning#rollback#data-modeling

  分析过程 · 先想清楚再作答

  1. 题眼在「够不够」三个字，它在提示答案是否定的。先把问题重述成一句判断：**版本不是备份**，这句话说出来这题就答对了一半。
  2. 两者的语义不一样。备份是「出事了拿回来」，只需要保留最近一份好状态；版本是「两个都在」，要能并排对比、来回切换，最终选哪个由人定。审核场景要的是后者。
  3. 所以每个版本要存三类东西：产物本身（按版本分目录，一个文件都不删）、产生它的输入（那一版的台词与画面描述，否则三天后没人说得清两版差在哪）、以及这一版重跑了哪些节点与原因。
  4. 当前版本要设计成一个指针，不是一份拷贝。回滚就是把指针挪回去，不搬文件，因此是瞬时且可逆的；这也让「再切回新版本」变成理所当然的操作。
  5. 有一个连带影响必须提到，提了就说明你真做过：**回滚一镜会改变整集的时间轴**。新版配音比旧版长一秒，切回去之后后面所有镜头的起止时间都要重排。所以回滚之后要重算一次时间轴，好在这是纯本地计算，很便宜。
  6. 可预期的追问是「版本存多久」。按产物体积和业务价值定：小文本无限存，视频这种大件设一个保留期，过期只留元数据和输入，需要时可以按同样的输入重跑出来。

  How to reason about it · think before answering

  1. The hinge is are they enough, which signals the answer is no. Restate it as a claim: a version is not a backup. Saying that sentence gets you half the credit.
  2. The semantics differ. A backup means restore after an incident and only needs the latest good state. A version means both exist, side by side, switchable, with a human choosing. Review workflows need the latter.
  3. So each version stores three things: the artifacts themselves, kept in per-version directories with nothing deleted; the inputs that produced them, the line and the visual description, or nobody can explain the difference three days later; and which nodes reran plus why.
  4. The current version should be a pointer, not a copy. Rollback moves the pointer without touching files, which makes it instant and reversible, and makes switching forward again equally natural.
  5. Mention the knock-on effect, because it shows you have actually shipped this: rolling back one shot changes the whole episode timeline. If the new take of the voice is a second longer, every later shot shifts, so rollback must recompute the timeline. That part is cheap local computation.
  6. Expected follow-up: how long to keep versions. Scale it by artifact size and business value: keep small text forever, put a retention window on video, and after expiry keep only metadata and inputs so the artifact can be regenerated on demand.

  答题要点

  • 版本不是备份：备份只要最近一份好状态，版本要求新旧同时存在、能并排对比。
  • 每版要存三类：产物（按版本分目录、不删）、产生它的输入、重跑的节点与原因。
  • 当前版本是指针不是拷贝，回滚只挪指针，瞬时且可逆。
  • 回滚一镜会改变整集时间轴，回滚后要重算一次——这是纯本地计算，很便宜。
  • 保留策略按体积分级：文本长期留，大视频设保留期，过期只留元数据与输入以便按需重跑。

  Key points

  • A version is not a backup: backups keep the latest good state, versions keep old and new side by side.
  • Store three things per version: artifacts in per-version directories, the inputs that produced them, and which nodes reran and why.
  • Make the current version a pointer, not a copy, so rollback is instant and reversible.
  • Rolling back one shot shifts the episode timeline, so recompute it after rollback; it is cheap local work.
  • Set retention by size: keep text forever, expire large video and retain metadata plus inputs for regeneration.

D11 质检与合规：机器审片、内容安全、生成内容标识与版权边界

• 怎么把画面质量这种主观判断变成可自动判定的检查？How do you turn a subjective judgement like visual quality into an automatable check?

  国内高频海外高频进阶#quality-check#evaluation#multimodal

  分析过程 · 先想清楚再作答

  1. 这题在考拆解能力。直接答「让多模态模型打分」只答了一半，而且是偷懒的那一半——面试官想看你怎么把一个不可判真假的命题拆成可判定的。
  2. 第一步是分类：把检查项分成「本地量得出来的」和「必须让模型看图的」。分辨率、音画时长差、字幕字数与每秒字数、配音响度，这四类用 ffprobe 加几行算术就有确定答案；角色一致性、画面崩坏则本地没有可靠代理指标。
  3. 分类的价值是账算得清：客观项出问题一定是文件真有毛病，主观项出问题可能是模型看错了。混成一个总分，事故来的时候分不清该修文件还是修提示词。
  4. 第二步是给每一项配齐三样：测量对象、阈值、**修正动作**。第三样最容易漏也最关键——一项检查不合格却说不出该怎么办，它就是摆设，你只能记一行日志继续往下走。
  5. 第三步是处理模型那一侧的不确定性：要求它只返回结构化结论，并且**解析不出来时标成无结论、需人工，绝不当成通过**。把「模型说没问题」和「模型没答上来」混为一谈，是自动质检里最常见的事故。
  6. 可预期的追问是「阈值怎么定」。用人工审核攒下来的带结论的样本回测，看阈值定在几分时机器结论与人的重合度最高；没有这份数据就只能拍脑袋。

  How to reason about it · think before answering

  1. This tests decomposition. Answering just use a multimodal model to score it covers only the lazy half; the interviewer wants to see you turn a non-falsifiable statement into checkable ones.
  2. Step one is classification: split checks into locally measurable and must-be-seen-by-a-model. Resolution, audio-video duration delta, subtitle length and reading rate, and loudness all have deterministic answers from ffprobe plus arithmetic. Character consistency and visual breakdown have no reliable local proxy.
  3. The classification pays off in accounting: a failing objective check means the file really is wrong, while a failing subjective one might just mean the model misread. Merge them into one score and you cannot tell whether to fix the file or the prompt.
  4. Step two gives every check three things: what is measured, the threshold, and the corrective action. The third is the one people skip and the one that matters, because a check that fails without a prescribed fix is decoration.
  5. Step three handles model-side uncertainty: demand a structured verdict, and when it cannot be parsed mark the item as no-conclusion, needs-human, never as a pass. Conflating the model said fine with the model did not answer is the classic automated-QC incident.
  6. Expected follow-up: how to set thresholds. Backtest against human-reviewed samples and pick the threshold where machine and human verdicts agree most. Without that data you are guessing.

  答题要点

  • 先分类：本地量得出来的客观项（分辨率、音画差、字幕密度、响度）与必须看图的主观项（角色一致性、画面崩坏）分开记账。
  • 每一项配齐三样：测量对象、阈值、修正动作；没有修正动作的检查项是摆设。
  • 模型评审要求返回结构化结论，解析失败标成需人工，绝不默认通过。
  • 阈值靠人工审核样本回测确定，不拍脑袋。
  • 客观项失败说明文件有问题，主观项失败可能是模型看错——这个区分决定了排查方向。

  Key points

  • Classify first: objective local measurements (resolution, av delta, subtitle density, loudness) versus model-only judgements (character consistency, visual breakdown).
  • Give every check a measurement, a threshold and a corrective action; a check with no action is decoration.
  • Require a structured verdict from the model, and treat unparseable output as needs-human, never as a pass.
  • Set thresholds by backtesting against human-reviewed samples.
  • An objective failure means the file is wrong; a subjective failure may mean the model misread. That split drives triage.

D12 成本与模型路由：按环节选模型、缓存、降级与预算熔断

• 什么情况下该降级而不是重试？如果决定降级，你有哪些维度可以降，怎么排先后？When should you degrade instead of retry, and which dimensions can you degrade first?

  国内高频海外高频进阶#degradation#retry-strategy

  分析过程 · 先想清楚再作答

  1. 题眼在「而不是」三个字。它考的是你能不能区分两类失败：重试针对的是「这次不巧」，降级针对的是「按当前配置根本跑不完」。答成「先重试三次再降级」就落进了套路。
  2. 给一条可复用的判据：重试解决的是**瞬时**且**与配置无关**的问题（限流、超时、服务端 5xx），降级解决的是**持续**且**由约束导致**的问题（预算不够、配额见底、截止时间快到了）。前者重试有效，后者重试只会把资源烧得更快。
  3. 顺带点出最容易被答错的一类：内容安全拦截既不该重试也不该降级，它要改输入。把三类混在一起是这题最大的失分点。
  4. 降级的维度要按「用户察觉难度」排，从低到高：清晰度、时长、数量（镜头数 / 条数）。先降察觉不到的，最后才动会影响内容本身的那一档。
  5. 还有一条工程判据：每一步降级都要拿成本模型验证一遍。如果某一档在你的单价表上省不出钱（比如更低的清晰度和当前档同价），那这一步降了只有损失，应该直接跳过。
  6. 可预期的追问是「降级要在什么时候决定」。答案是开跑之前先用纯函数预估一遍，算不过就降完再跑——跑到一半再砍，会留下半成品，前面花的钱全打水漂。

  How to reason about it · think before answering

  1. The pivot is the word instead. This tests whether you separate two failure classes: retry addresses bad luck this time, degradation addresses cannot finish under this configuration. Answering retry three times then degrade misses the point.
  2. Give a reusable rule: retry fixes transient, configuration-independent problems such as rate limits, timeouts and server errors. Degradation fixes persistent, constraint-driven ones such as running out of budget, quota or time. Retrying the second class just burns resources faster.
  3. Name the class most people get wrong: a content-safety block should be neither retried nor degraded, it needs a changed input. Conflating the three is the biggest scoring mistake here.
  4. Order degradation dimensions by how noticeable they are, least to most: resolution, duration, then count of items. Touch the one that changes the content itself only as a last resort.
  5. Add an engineering rule: validate every degradation step against the cost model. If a step saves nothing on your rate card, degrading quality buys you nothing and should be skipped.
  6. Expect the follow-up: when do you decide? Project the cost with a pure function before the run starts and degrade up front. Cutting mid-run leaves a half-finished artifact and wastes everything already spent.

  答题要点

  • 重试针对瞬时且与配置无关的失败，降级针对持续且由约束导致的不可完成
  • 内容安全拦截是第三类：既不重试也不降级，要改输入
  • 降级维度按察觉难度排：清晰度、时长、数量，最后才动内容本身
  • 每一步降级都要拿成本模型验证，省不出钱的那一步直接跳过
  • 降级要在开跑前决定，跑到一半再砍会留下半成品且前面的钱白花

  Key points

  • Retry transient configuration-independent failures; degrade when the constraint makes completion impossible
  • Content-safety blocks are a third class: change the input rather than retrying or degrading
  • Order degradation by noticeability: resolution, duration, item count, content last
  • Validate each degradation step against the rate card and skip steps that save nothing
  • Decide before the run starts; cutting mid-run leaves a half-finished artifact and wastes prior spend

D13 发行：多平台规格适配、封面与标题生成、批量导出与数据回收

• 同一条视频要发多个平台，每个平台规格不同，你会怎么设计导出流程才能少转码？The same video has to be published to several platforms with different specs. How do you design the export flow to minimize transcoding?

  国内高频海外高频进阶#media-pipeline#ffmpeg

  分析过程 · 先想清楚再作答

  1. 这题在考你分不分得清转码与封装。答成「按每个平台各渲染一遍」的人不是不会写代码，是没意识到有损编码每转一次就掉一次画质。
  2. 先把两个词分开：转码是重新解码再编码，画面数据真的被压了一遍；封装只是把已编好的码流换个容器，一个字节都没动。前者要几秒到几十秒并且掉画质，后者几十毫秒且无损。
  3. 然后给流程：先渲染一份母版，参数取所有目标平台的交集里最保守的一档；之后每个平台走一次判定函数，能流复制就流复制。换容器、加 faststart、按时长截断都属于流复制的范围。
  4. 必须重编码的情况要能背出来：分辨率越界要缩放、编码格式不被接受、帧率超范围、文件大小超限要降码率。除此之外都不该重编码——尤其时长超限这一条最容易被误判，其实 -t 配流复制就能切。
  5. 补一条工程判据：判定函数要返回理由列表，不只是布尔值。出片之后有人问「为什么这个平台转了码」，你要能拿日志回答，而不是重新读一遍代码。
  6. 可预期的追问是「怎么证明真的少转了」。答案是打印一个编码次数计数器，并同时给出朴素做法的次数做对照——没有对照的数字说服不了任何人。

  How to reason about it · think before answering

  1. This question tests whether you distinguish transcoding from remuxing. Rendering once per platform is not a coding failure, it is a failure to notice that every lossy re-encode costs quality.
  2. Separate the two: transcoding decodes and re-encodes, so the picture data is genuinely recompressed; remuxing just moves an already-encoded bitstream into another container without touching a byte. One takes seconds and loses quality, the other takes milliseconds and is lossless.
  3. Then give the flow: render one master using the most conservative parameters that satisfy every target, then run each platform through a decision function and stream-copy whenever possible. Container changes, faststart and duration trims all stay within stream copy.
  4. Know the cases that truly require re-encoding: out-of-range resolution, an unaccepted codec, a frame rate outside the allowed band, and a file that exceeds the size cap. Duration is the one people misjudge most, since -t with stream copy already trims it.
  5. Add an engineering rule: the decision function should return a list of reasons, not just a boolean. When someone asks why a platform got re-encoded, you answer from the log rather than rereading the code.
  6. Expect the follow-up: how do you prove it? Print an encode counter alongside the count the naive approach would have produced. A number without a baseline convinces nobody.

  答题要点

  • 分清转码与封装：换容器、加 faststart、按时长截断都可以流复制
  • 一次渲染母版，参数取所有目标平台约束的最保守交集
  • 只有分辨率越界、编码不被接受、帧率超范围、体积超限才必须重编码
  • 判定函数返回理由列表，让每次重编码都能被解释
  • 打印编码次数计数器并与朴素做法做对照，才算证明少转了码

  Key points

  • Separate transcode from remux: container swaps, faststart and duration trims are all stream copies
  • Render one master using the most conservative intersection of all target constraints
  • Re-encode only for out-of-range resolution, unaccepted codec, out-of-band frame rate, or oversize files
  • Have the decision function return reasons so every re-encode can be explained
  • Print an encode counter next to the naive baseline to prove the saving
• 让模型生成标题、封面文案这类创意内容，怎么保证质量下限？When a model generates creative content such as titles and cover copy, how do you guarantee a quality floor?

  国内高频海外高频进阶#llm-output-quality#candidate-selection

  分析过程 · 先想清楚再作答

  1. 题眼是「下限」两个字。它问的不是怎么让输出更好，而是怎么保证输出不会太差——这两个目标的手段完全不同，混起来答就散了。
  2. 先给一条判断依据：这个环节贵不贵。贵而慢的环节（比如视频生成）要「一次做对」，靠约束输入；便宜而快的环节（文案）应该「多做几版再挑」，靠收敛输出。价格差三个数量级，策略就该完全不同。
  3. 于是形态是：按几个预设角度各生成一版候选，再用一个确定性的打分函数收敛成前几名。下限由打分函数保证，而不是由模型保证——模型不稳定是常态，打分函数不会。
  4. 打分函数的三条要求：每一项都写出理由（分数不解释就没法迭代规则）、违规词用扣重分而不是过滤（过滤在极端情况下会一条不剩）、同分必须有决胜键（否则两次运行挑出不同结果，你会误以为是模型不稳定去调温度）。
  5. 还要有一道兜底：模型返回的东西不一定能直接用，可能太长、带解释性前缀、夹着调试符号。加一个格式校验，不通过就回落到本地模板。这一层挡的是「输出结构不可控」，和打分挡的「输出质量不可控」是两件事。
  6. 可预期的追问是「为什么不让模型自己评分」。答案是不稳定且不可解释：同一批候选问两次可能给出不同答案，而且你无法向任何人说明为什么选了第三条。模型评分可以作为打分函数的一项输入，但不能是唯一的裁判。

  How to reason about it · think before answering

  1. The pivot is the word floor. The question is not how to make output better but how to keep it from being bad, and those two goals need different techniques.
  2. Start from one criterion: is this stage expensive? Expensive slow stages such as video generation must get it right once by constraining the input. Cheap fast stages such as copywriting should generate several variants and converge. A three-order-of-magnitude price gap justifies opposite strategies.
  3. So the shape is: generate one candidate per preset angle, then converge with a deterministic scoring function. The floor comes from the scorer, not from the model, because model variance is the normal case and the scorer has none.
  4. Three requirements for the scorer: emit a reason per rule, since an unexplained score cannot be iterated on; penalize banned wording heavily rather than filtering it, because filtering can leave you with nothing; and always define a tie-breaker, or two runs pick different winners and you will blame the model and start tuning temperature.
  5. Add a structural guard: model output may be too long, prefixed with explanation, or carry debug markers. Validate the shape and fall back to a local template when it fails. That layer handles uncontrollable structure, which is a different problem from uncontrollable quality.
  6. Expect the follow-up: why not let the model score itself? Because it is unstable and unexplainable. The same batch can be ranked differently twice, and you cannot justify the choice to anyone. Model judgement can be one input to the scorer, never the only judge.

  答题要点

  • 按环节的价格选策略：贵的一次做对靠约束输入，便宜的多做几版靠收敛输出
  • 形态是按预设角度批量出候选，再用确定性打分函数挑前几名
  • 打分函数必须输出理由、对违规词扣重分而非过滤、同分给决胜键
  • 另加一道结构兜底：格式不合格就回落本地模板，与质量打分是两件事
  • 不让模型给自己评分，它不稳定也不可解释，最多作为打分的一项输入

  Key points

  • Pick the strategy by stage cost: constrain input when expensive, converge output when cheap
  • Generate one candidate per preset angle, then rank with a deterministic scoring function
  • The scorer must emit reasons, penalize banned wording instead of filtering, and define a tie-breaker
  • Add a separate structural fallback for malformed output, distinct from quality scoring
  • Do not let the model judge itself; use it at most as one signal inside the scorer

D14 一季五集：批量产出、作品集包装与短剧生产线面试专题

• 多集连续生成时，人物与画风的跨集一致性你是怎么保证的？如果要做一百集会遇到什么新问题？How do you keep characters and visual style consistent across many generated episodes, and what breaks at a hundred episodes?

  国内高频海外高频进阶#consistency#prompt-assembly

  分析过程 · 先想清楚再作答

  1. 这题的区分度在于你是靠自律还是靠结构。答「每次都把提示词写得一样」的人做到第五集就会漂，因为每复制一次提示词就多一次人为改动的机会。
  2. 正确形态是把一致性变成结构上做不到不一致：建一份唯一的档案（人物卡含外貌与音色、风格词、场景表），再立一条硬规矩——每一镜的提示词只能由「档案加本镜描述」拼出来，不允许手写。
  3. 然后把这条规矩做成可判定的检查：角色是不是都在档案里、音色跨集有没有变、外貌片段是不是逐字来自档案、风格词每一镜有没有带上、集间钩子有没有首尾相接。注意这五条只看输入不看画面——画面质量是机器审片的职责，两道检查互补，谁也替代不了谁。
  4. 一百集会冒出三类新问题。第一是档案本身会演化：人物换了造型、加了新角色，需要给档案做版本，并记录每一集用的是哪个版本，否则回头没法解释第三十集为什么和第十集不一样。
  5. 第二是钩子链变长之后容易断，人工维护五条还行、维护九十九条一定出错，得让钩子校验成为开跑前的硬闸门。第三是资产库膨胀，定妆图与参考图要有索引与去重，否则同一个角色会攒出几十张互相矛盾的基准图。
  6. 可预期的追问是「一致性和多样性冲突吗」。答案是把两者分开：档案锁死的是身份特征（外貌、音色、风格），随机性留给运镜、构图与光线——锁错层就会得到一百集一模一样的片子。

  How to reason about it · think before answering

  1. The discriminator is whether you rely on discipline or on structure. Writing the prompt the same way every time drifts by episode five, because every copy is another chance for a human edit.
  2. The right shape makes inconsistency structurally impossible: keep one archive (character cards with appearance and voice id, style tokens, scene list) and enforce one rule, that every shot's prompt is assembled from the archive plus that shot's description, never hand-written.
  3. Then turn the rule into decidable checks: are all characters in the archive, did any voice id change across episodes, is the appearance fragment verbatim from the archive, does every shot carry the style tokens, and does each episode's hook match the next one's pick-up. These five inspect inputs only; picture quality belongs to the automated review pass, and the two are complementary.
  4. At a hundred episodes three new problems appear. First the archive itself evolves as characters restyle and new ones appear, so it needs versions and each episode must record which version it used, or you cannot explain why episode thirty differs from episode ten.
  5. Second, the hook chain gets long and manual maintenance fails, so hook validation has to be a hard gate before the run starts. Third, the asset library bloats, so reference sheets need an index and deduplication or one character accumulates dozens of contradictory base images.
  6. Expect the follow-up: does consistency fight variety? Separate the layers. The archive locks identity traits such as appearance, voice and style, while randomness lives in camera movement, framing and lighting. Locking the wrong layer gives you a hundred identical episodes.

  答题要点

  • 靠结构不靠自律：唯一档案加一条硬规矩，提示词只能从档案拼出来
  • 五条只看输入的可判定检查：角色、音色、外貌逐字、风格词、集间钩子
  • 输入检查与机器审片互补，一个查有没有漂，一个查画面好不好
  • 上百集会新增三类问题：档案要版本化、钩子校验要变成硬闸门、资产库要索引去重
  • 档案锁身份特征，随机性留给运镜构图光线，锁错层会一百集雷同

  Key points

  • Rely on structure: one archive plus a rule that prompts may only be assembled from it
  • Five decidable input-only checks: cast membership, voice stability, verbatim appearance, style tokens, hook chain
  • Input checks complement automated picture review; neither replaces the other
  • At scale add archive versioning, a hard pre-run hook gate, and an indexed deduplicated asset library
  • Lock identity traits in the archive and leave randomness to camera, framing and lighting