Interview Bank

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

D8 A Workflow Engine: Turning the Pipeline Into a Resumable Task Graph

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

  Common in ChinaCommon overseasIntermediate#idempotency#caching#workflow-engine

  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.

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

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

  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.

  答题要点

  • 判据一句话：会改变产物的进键，每次都变但不影响产物的不进键。
  • 必放四样：节点标识、实现版本号、本节点输入、全部依赖的指纹。
  • 禁放：运行标识、时间戳、随机数、绝对路径与机器相关信息。
  • 命中判定看磁盘上产物是否齐全，不能只信状态文件。
  • 幂等粒度要显式选择：节点粒度实现简单，镜头粒度更省钱但图更大。
• What state must you persist to support resuming a workflow? Is per-node completion status enough?要支持断点续跑，你需要持久化哪些状态？只存每个节点的完成状态够不够？

  Common in ChinaCommon overseasDeep dive#workflow-engine#state-persistence#resume

  How to reason about it · think before answering

  1. The words 'is it enough' hint that it is not. A system storing only completion status knows a node ran, but not which version ran, so it happily skips after you change the code.
  2. Frame it as three questions a resume must answer: which nodes are done, are they the version I want now, and are their artifacts still there? Each maps to something you must persist.
  3. So beyond status you need the fingerprint and the artifact location. The fingerprint answers 'same version?', the location answers 'still there?'. Storing artifacts in a content-addressed directory named by the fingerprint collapses the third question into a file-existence check.
  4. Also separate two layers: the artifact cache is global and shared across runs, providing idempotency; node state is per run, providing resume. Collapse them and a new run id costs you full price again.
  5. Write timing is part of the answer: persist state right after each node completes, not once at the end. Hard kills, power loss and container eviction are not rare during ten-minute video jobs.
  6. Expect the follow-up 'do you delete a failed node's partial artifacts'. No. Keep them, and make the hit condition 'every declared output exists'. Missing one means redo, so partials are never mistaken for success.

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

  1. 题眼在「够不够」三个字，它在暗示你答案是不够。只存完成状态的系统，重跑时只知道「这个节点做过」，却答不出「做的是哪一版」——于是改完代码重跑，它照样跳过。
  2. 拆的角度是：续跑要回答三个问题。哪些节点做完了？它们做的是不是我现在要的那一版？它们的产物还在不在？三个问题分别对应三样要持久化的东西。
  3. 所以除了状态，还要存指纹和产物位置。指纹回答「是不是同一版」，产物位置回答「东西还在不在」。本课的做法是把产物按指纹落进内容寻址的目录，这样第三个问题退化成一次文件存在性检查，连记都不用记。
  4. 还要区分两层：产物缓存是全局的，跨运行共享，它提供的是幂等；节点状态是每次运行一份，它提供的是断点续跑。混成一层的话，换个运行标识就得重花一次钱。
  5. 落盘时机也是这题的一部分：状态必须在每个节点跑完之后立刻写，而不是整个流程结束再写一次。进程被强杀、机器掉电、容器被驱逐，在跑十几分钟的视频任务时并不罕见。
  6. 可预期的追问是「失败节点的残产物要不要删」。答：不删。留着它，下一次跑到这里判断产物齐不齐就直接得到结论；但判定必须是「outputs 里每个文件都在」才算命中，缺一个就重做，否则残产物会被当成成功的。

  Key points

  • Completion status alone is not enough: persist the fingerprint and artifact location to answer 'which version' and 'still present'.
  • Content-addressed artifact directories reduce 'still present' to a file-existence check.
  • Keep two layers: a global cache for idempotency, per-run node state for resume.
  • Persist state immediately after each node, not once at the end of the run.
  • Keep failed nodes' partial artifacts, but only count a hit when every declared output exists.

  答题要点

  • 只存完成状态不够，还要存指纹和产物位置，分别回答「哪一版」和「还在不在」。
  • 产物按指纹落进内容寻址目录后，「还在不在」退化成一次文件存在性检查。
  • 两层分开：缓存全局共享提供幂等，节点状态每次运行一份提供断点续跑。
  • 状态要在每个节点跑完后立刻落盘，不能等整个流程结束再写。
  • 失败节点的残产物保留，但命中判定必须是全部产物齐全才算数。
• When should you write your own scheduler, and when should you adopt an off-the-shelf workflow engine?什么时候该自己写调度，什么时候该直接上现成的工作流引擎？

  Common in ChinaCommon overseasBasic#architecture#build-vs-buy#workflow-engine

  How to reason about it · think before answering

  1. This tests selection maturity. Both extremes lose points: building everything yourself shows no sense of leverage, adopting a framework for everything shows no judgment. The interviewer wants your switching signals.
  2. Give a general criterion: writing it yourself buys understanding and fit; a framework buys you past problems you have not hit yet. So the decision hinges on how much of what you need overlaps with the framework's core.
  3. Writing your own pays off when: single machine, a handful of nodes, a path you fixed yourself, and you only need topological ordering plus idempotency plus state persistence. That is under three hundred lines, and the understanding transfers to any engine you adopt later.
  4. Three signals to switch: you need cross-machine scheduling, where rolling your own scales in complexity exponentially; you need human-in-the-loop nodes, so runs suspend for hours or days and state must live in a database rather than a JSON file; or non-engineers need to see and operate it, in which case you need a product with a UI, not an engine.
  5. Conversely, adopting a heavy framework too early has a concrete cost: every business change must route around its abstractions, while its benefits only land at scale. Cost up front, payoff deferred.
  6. Expect the follow-up 'can you migrate off your own version cleanly'. Yes, if nodes were declarative from the start — dependencies, inputs, outputs, body — with scheduling and state kept out of the business code. Then migration replaces the engine, not the nodes.

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

  1. 这题考的是技术选型的成熟度。两个极端都会被扣分：什么都自己写显得不懂杠杆，什么都上框架显得没判断力。面试官想听的是你的切换信号是什么。
  2. 先给一条通用判据：自己写的收益是理解和贴合，框架的收益是省掉你还没遇到的那些问题。所以决策取决于「你现在需要的功能有多少落在框架的核心能力上」。
  3. 自己写划算的情形：单机、节点数是个位数、路径是你定死的、需要的只是拓扑排序加幂等加状态落盘这几件事。这时候自己写不到三百行，而且换来的理解是通用的——你会彻底搞懂幂等键为什么要包含依赖指纹、状态为什么必须每步落盘。
  4. 该换的三个信号：一是开始需要跨机器调度，自己实现分布式调度的复杂度是指数级上升的；二是开始需要人工介入节点，流程要挂起几小时甚至几天，状态必须外置到数据库而不是一个 JSON 文件；三是开始需要给非工程师看和操作，那你需要的其实是一个带界面的产品。
  5. 反过来说，过早引入重型框架的代价很具体：每一个业务改动都要先绕过它的抽象，而它的收益要等规模上来才兑现。这是典型的成本前置、收益后置。
  6. 可预期的追问是「自己写的那一套能不能平滑迁走」。答：能，前提是你从一开始就把节点定义成纯声明（依赖、输入、产物、执行体），调度和状态不侵入业务。这样迁移时改的是引擎，不是六个节点。

  Key points

  • Decide by how much your needs overlap the framework's core, not by a build-versus-buy stance.
  • Rolling your own wins on a single machine with few nodes and a fixed path, needing only topo order, idempotency and state persistence.
  • Three switching signals: cross-machine scheduling, human-in-the-loop suspension, and non-engineers needing to operate it.
  • Adopting a heavy framework early costs a detour around its abstractions on every change, with benefits deferred to scale.
  • Keep nodes declarative and scheduling non-invasive so a later migration replaces the engine, not the nodes.

  答题要点

  • 判据是你需要的功能与框架核心能力的重叠度，不是「自研还是选型」的立场。
  • 自己写划算：单机、节点数少、路径固定，只需要拓扑排序加幂等加状态落盘。
  • 该换的三个信号：跨机器调度、人工介入导致流程长时间挂起、非工程师要操作。
  • 过早上重型框架的代价是每次业务改动都要绕过它的抽象，收益却要等规模。
  • 把节点写成纯声明，调度与状态不侵入业务，将来迁移改的是引擎而不是节点。

D9 Concurrency and Quotas: Starting Multiple Episodes at Once Without Blowing Through Any Provider's Limits

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

  Common in ChinaCommon overseasIntermediate#rate-limiting#concurrency#scheduling

  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.

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

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

  答题要点

  • 按「厂商 + 接口类别」分桶，一家的图像和语音各一道闸门。
  • 每道闸门两个部件：令牌桶控速率（厂商给的 RPM），信号量控并发（自己定的在飞上限）。
  • 准入必须非阻塞，拿不到许可就把任务留在队列里，绝不占着工作槽干等。
  • 先抢并发票再取令牌，顺序反了会白白扣掉配额。
  • 多进程部署时桶的状态要外置到 Redis，用原子操作取令牌。
• Beyond backing off and retrying, what else should happen when you get rate limited?收到限流响应之后，除了退避重试还该做什么？

  Common in ChinaCommon overseasDeep dive#rate-limiting#error-handling#retry

  How to reason about it · think before answering

  1. This question separates people who have actually been throttled in production. Exponential backoff with jitter is only the first half of the answer.
  2. Frame it correctly: throttling is a signal, not an error. It says your current send rate exceeds what the vendor will accept right now, so it deserves a feedback action, not just a retry.
  3. Action one is to slow down on purpose: penalize the bucket so the next window or two issues half the tokens. Without that, you finish the backoff and hit the same wall at the same speed.
  4. Action two is to not hold an execution slot while waiting. Requeue the job with a not-before timestamp and hand the slot back immediately.
  5. Action three is classification. Throttling and server errors are retryable; auth failure, insufficient balance, invalid parameters and content-policy rejections are not, and retrying them just repeats one mistake five times while consuming quota. At MiniMax, 1002 is rate limiting and 1039 is the token-per-minute variant, while 1004 is auth, 1008 is balance, 2013 is bad parameters and 1026 or 1027 are content rejections.
  6. Action four is to record throttle counts as a metric. That number is the only evidence you have when you later retune the gate.
  7. Expected follow-up: how to cap the backoff. Cap it at what the business can wait for, then degrade instead of retrying: smaller resolution, shorter duration, or push the job into the next batch.

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

  1. 这题在考你有没有真在生产里被限流打过。只答「指数退避加抖动」是标准答案的前半段，面试官等的是后半段。
  2. 先把限流摆正位置：它不是错误，是信号。它告诉你此刻的发送速率超过了厂商愿意接受的速率。既然是信号，就该有反馈动作，而不只是重试。
  3. 第一个动作是主动降速：把令牌桶罚一档，接下来一两个窗口只发一半令牌。不降速的话，退避结束后你会用同样的速度再撞一次，重试次数越多越糟。
  4. 第二个动作是别在退避里占着执行流。正确做法是把任务重新入队并记一个「不早于」时间戳，槽位立刻还回去给别的任务。
  5. 第三个动作是分类：限流和服务端错误可以重试，鉴权失败、余额不足、参数错误、内容审核不通过一次都不该重试——重试只会让你在一分钟里把同一个错误犯五遍，还白占配额。MiniMax 这边 1002 是限流、1039 是 TPM 维度的限流，1004 鉴权、1008 余额、2013 参数、1026 和 1027 是内容审核。
  6. 第四个动作是把限流次数记进指标。撞得多说明闸门配小了或者配大了，这个数字是你回头调参数的唯一依据。
  7. 可预期的追问是「退避上限怎么定」。定在业务能等的时间上，超过就转降级：换更小的分辨率、更短的时长，或者干脆排到下一批。

  Key points

  • Treat throttling as a signal: back off and also penalize the bucket so the next window issues fewer tokens.
  • Requeue with a not-before timestamp instead of sleeping inside the worker slot.
  • Add jitter, or everything throttled together wakes together and collides again.
  • Separate retryable from non-retryable: auth, balance, bad parameters and content rejections get zero retries.
  • Emit a throttle counter as a metric, and switch to degradation once backoff hits its ceiling.

  答题要点

  • 把限流当信号：退避的同时给令牌桶降档，接下来的窗口只发一半令牌。
  • 退避期间把任务重新入队并记一个不早于时间戳，工作槽立刻还回去。
  • 退避要带抖动，否则同时被限的任务会同时醒来再撞一次。
  • 严格区分可重试与不可重试：鉴权、余额、参数、内容审核一次都不重试。
  • 把限流次数记成指标，它是回头调闸门参数的唯一依据；退避到上限就转降级而不是继续重试。
• Priority queues starve low-priority work. How do you prevent that?优先级队列容易出现饿死，你会怎么防？

  Common in ChinaCommon overseasBasic#scheduling#priority-queue#fairness

  How to reason about it · think before answering

  1. This is the easy one, and most candidates stop after saying aging. The signal is in the two conditions they forget to attach.
  2. The mechanism first: aging, where effective priority rises with waiting time, one step per threshold crossed, with first-in-first-out inside a tier.
  3. Condition one: cap the promotion, and never let it reach the top tier. Otherwise after half an hour every queued job is top priority and the tier means nothing. Our rule is that low may rise to normal, and the top tier stays reserved for human escalation.
  4. Condition two is the one people miss: if a job waits for resources after dispatch, priority silently stops working, because worker slots are pinned by low-priority jobs waiting on quota and the urgent job is never picked up. Admission must happen before dispatch.
  5. Close with the observable: track average and maximum wait per tier plus a promotion counter. Those two numbers tell you directly whether the aging threshold is right.
  6. Expected follow-up: alternatives to aging. Reserved shares work too, where every fourth dispatch must go to a low-priority job. That is weighted fair queuing, more controllable but noisier to implement.

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

  1. 这题是送分题，但很多人只答一个「老化」就停了，拿不到区分度。区分度在两个补充条件上。
  2. 先说机制：老化，也就是等待越久有效优先级越高，每等过一个阈值就升一档。同档内按入队时间先来先服务。
  3. 第一个补充条件是升档要封顶，而且不许升进最高那一档。否则跑上半小时，队列里全是最高优先级，这一档就名存实亡了。本课的口径是低优先最多升到普通，最高档只留给人工插队。
  4. 第二个补充条件更容易被忽略：如果任务被派出去之后才开始等资源，优先级会静默失效——工作槽被一批低优先任务占着等资源，高优先任务连被取走的机会都没有。所以准入要在调度之前完成。
  5. 结论里要给出可观测量：按优先级统计平均等待与最长等待，再加一个升档次数。这两组数字能直接告诉你老化阈值配得对不对。
  6. 可预期的追问是「除了老化还有别的办法吗」。有：给低优先级预留一部分固定配额（比如每四次调度必须让一个低优先的过），这是加权公平调度的思路，比老化更可控但实现更啰嗦。

  Key points

  • Use aging: effective priority rises with wait time, first-in-first-out within a tier.
  • Cap promotion and never let it reach the top tier, or the top tier stops meaning anything.
  • Admit before dispatch, otherwise worker slots pinned on quota make priority silently useless.
  • Track per-tier average wait, max wait and promotion count, and tune the aging threshold from those.
  • The alternative is weighted fair queuing with a reserved share for low priority: more controllable, more code.

  答题要点

  • 用老化：等待时间越长有效优先级越高，同档内先来先服务。
  • 升档要封顶，绝不能升进最高那一档，否则最高档形同虚设。
  • 准入要放在调度之前，否则工作槽被低优先任务占着等资源，优先级会静默失效。
  • 按优先级统计平均等待、最长等待与升档次数，用它来校准老化阈值。
  • 备选方案是给低优先级预留固定份额的加权公平调度，比老化更可控但实现更复杂。

D10 The Review Room: A Human-in-the-Loop Backend for Previewing, Editing Lines, and Regenerating a Single Shot

• Where would you place human review checkpoints in an automated pipeline, and why there?一条自动化流水线要插入人工审核，你会把卡点放在哪几步？为什么？

  Common in ChinaCommon overseasBasic#human-in-the-loop#pipeline-design#cost

  How to reason about it · think before answering

  1. This one tests cost awareness. Saying a human should look at every step marks someone who has not run this in production: humans are the expensive resource, and too many gates turn a pipeline back into handwork.
  2. Offer a reusable rule: put the gate immediately before the most expensive downstream step. To decide whether a position deserves a gate, ask how much money is wasted if something is wrong here.
  3. Applied to a generative pipeline that yields three positions: after the script is locked (free to change, yet it steers every asset that follows), after the first frame but before video generation (the frame is the cheapest step and the clip is the most expensive, one to two orders of magnitude apart), and after the final cut but before publishing (this one gates risk, not quality).
  4. Add the production view: a checkpoint is not necessarily blocking. The first two can auto-continue on timeout; only the compliance gate must hard-block, because you cannot let a legal check pass by timing out.
  5. State the counterintuitive part: the first gate is the one people skip, because there are no visuals yet and it looks like there is nothing to review, while it is the only gate where changes cost nothing.
  6. Expected follow-up: what if reviewers cannot keep up. Tier it. Machines score everything, humans only see the low scores, and human attention goes where the machine is unsure.

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

  1. 这题在考你有没有成本意识。答「每一步都让人看一眼」是没做过工程的回答——人是最贵的资源，卡点多了流水线就退化成手工作坊。
  2. 给一条可复用的判据：**卡点放在「下游最贵的那一步」之前**。判断某个位置该不该设卡，只问一句「如果这里错了，往后要白花多少钱」。
  3. 按这条判据落到生成式流水线上，会得到三个位置：剧本定稿之后（此时零成本，却决定了后面所有素材的方向）、首帧出来之后视频生成之前（首帧是最便宜的一档，视频是最贵的一档，同一个镜头差出一到两个数量级）、成片合成之后发布之前（这一道拦的不是质量而是合规风险）。
  4. 补一条生产视角：卡点不等于阻塞。第一和第二道可以做成「默认放行、超时自动继续」，只有第三道必须硬卡——合规问题不能靠超时放行。
  5. 结论里要点出一个反直觉的事实：最容易被跳过的恰恰是第一道，因为这时候还没有画面，看起来没什么可审的；但它是唯一一道改起来零成本的闸门。
  6. 可预期的追问是「人来不及审怎么办」。答案是分级：机器先打分，只把低分的推给人，人的时间花在机器拿不准的那部分上。

  Key points

  • Rule: place the gate right before the most expensive downstream step, judged by wasted spend if this step is wrong.
  • Three positions: after script lock, after first frame and before video, after final cut and before publish.
  • The first-frame gate pays best: the frame is the cheapest step and the clip the most expensive, one to two orders of magnitude apart.
  • The first two gates can auto-continue on timeout; only the compliance gate hard-blocks.
  • When reviewers are the bottleneck, tier it: machines score everything, humans only see low scores.

  答题要点

  • 判据是「卡点放在下游最贵的那一步之前」，问的是这里错了往后白花多少钱。
  • 三个位置：剧本定稿后、首帧出来后视频生成前、成片合成后发布前。
  • 首帧那一道性价比最高：首帧是最便宜的一档，视频是最贵的一档，同一个镜头差出一到两个数量级。
  • 前两道可以默认放行加超时继续，只有合规那一道必须硬卡。
  • 人力不够就分级：机器先打分，人只看低分的那些。
• A user edits an intermediate input. How do you compute which downstream steps must rerun?用户改了中间一步的输入，怎么算出哪些下游需要重做？

  Common in ChinaCommon overseasIntermediate#dag#incremental-recompute#cost

  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.

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

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

  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?版本回滚要存什么？只存最终产物够不够？

  Common in ChinaCommon overseasIntermediate#versioning#rollback#data-modeling

  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.

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

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

  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 Quality Control and Compliance: Machine Review, Content Safety, Generated-Content Labeling, and Copyright Boundaries

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

  Common in ChinaCommon overseasIntermediate#quality-check#evaluation#multimodal

  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.

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

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

  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.

  答题要点

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

  Common in ChinaCommon overseasBasic#content-safety#moderation#pipeline-design

  How to reason about it · think before answering

  1. The answer is both, but the marks come from explaining that the two gates defend against different things. Saying defence in depth is safer earns nothing.
  2. The pre-check inspects the prompt you are about to send, and it saves money and account standing: a violating prompt gets rejected by the vendor's own moderation (1026 or 1027 at MiniMax), wasting a round trip, and repeated hits can trip risk controls. It is a local word list plus rules, milliseconds, and each catch saves a call.
  3. The post-check inspects what the vendor returned, and it matters more, because a clean prompt does not imply a clean result. Generative models improvise: you ask for a convenience store and get a shelf of branded packaging. The pre-check only proves you did not ask for it; the post-check protects the viewer.
  4. When the pre-check fires, do not just throw. Offer a replacement and keep going: swap the matched fragment for safe wording, print it, and record it so a human can see which line was changed and how.
  5. Call out the common misconception: vendor moderation does not replace yours. The vendor moderates its own risk, with different boundaries, and publishing liability sits with you.
  6. Expected follow-up: what to do when the post-check fails. Triage by severity: auto-fixable issues get fixed and only that node reruns; anything else blocks publishing and goes to a human. Never wave it through because the money is already spent.

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

  1. 这题的正确答案是「两边都要」，但拿分的关键不在结论，而在你能不能说清两道关**防的是不同的事**。答成「双重保险更稳妥」就是没答。
  2. 前置那道查的是你要发出去的提示词，省的是钱和账号：违规提示词发过去会命中厂商审核被拒（MiniMax 这边返回 1026 或 1027），白等一轮，严重的会触发风控。它是一层本地词表加规则，几毫秒，拦一条省一次调用。
  3. 后置那道查的是厂商还给你的成片，它更重要，理由是**提示词干净不代表结果干净**——生成模型会自己加戏，你写便利店门口，它可能给你摆一整面货架的品牌包装。前置只保证你没主动要，后置才保证观众看到的没问题。
  4. 前置被拦下之后不能只抛异常，要给替代方案并让流程继续：把命中片段替换成安全表述、打印出来、记进报告，人回头能看到哪一句被改成了什么。
  5. 还要点破一个常见误解：**厂商的审核不能替代你的审核**。厂商审的是它自己的合规风险，边界跟你的业务不同；而且发布责任在你，出事找的是发布者。
  6. 可预期的追问是「后置发现问题怎么办」。按严重程度分流：能自动修的（比如字幕里的词）就修完重跑那一个节点，修不了的直接拦住不许发布并推给人工，绝不能因为已经花了钱就放行。

  Key points

  • Both, because they defend different things: the pre-check saves spend and account standing, the post-check protects viewers and compliance.
  • The pre-check is a local rule pass in milliseconds; on a hit, substitute safe wording instead of throwing and halting the line.
  • The post-check matters more, because a clean prompt does not guarantee a clean result.
  • Vendor moderation covers the vendor's risk, not yours; publishing liability stays with you.
  • Triage post-check failures: auto-fix and rerun that node, or hard-block and escalate.

  答题要点

  • 两道都要，因为防的事不同：前置省钱与账号，后置保护观众与合规。
  • 前置是本地词表加规则，几毫秒，拦下一条就省一次调用；命中要给替代写法而不是抛异常停线。
  • 后置更重要：提示词干净不代表结果干净，模型会自己加戏。
  • 厂商的审核只兜它自己的风险，不能替代你的，发布责任在你。
  • 后置发现问题按严重度分流：能自动修的修完重跑该节点，修不了的硬拦并推人工。

D12 Cost and Model Routing: Choosing a Model per Stage, Caching, Degradation, and a Budget Circuit Breaker

• How do you break down the cost of a content-generation pipeline, and which stage would you optimize first?一条内容生成流水线的成本要怎么拆？拆完你会先优化哪一环，为什么？

  Common in ChinaCommon overseasBasic#cost-analysis#observability

  How to reason about it · think before answering

  1. This question checks whether you have actually read a bill. Answering with generic advice like use more caching signals you never ran this in production; naming the breakdown dimensions and rough ratios signals you did.
  2. Establish the dimensions first: by stage (script, image, video, speech), by billing unit (per second, per item, per character, per token), and by billable status (succeeded, cache hit, failed and not charged). Drop any one of them and a whole class of spend becomes invisible.
  3. Then give orders of magnitude. Video is billed per second, so a dozen seconds already costs a few yuan, while images are cents per item, speech is fractions of a cent per character, and text is lower still. Video typically dominates at over ninety percent.
  4. So the priority is driven by what is expensive, not by what is easy to change. Attack video first, cheapest lever to most expensive: caching and idempotency, tiered routing with a cheap draft tier, degradation across resolution, duration and shot count, and only then vendor negotiation.
  5. Add a credibility note: never put an unverified unit price in the table. Mark derived prices as estimates and leave unpublished ones blank while still counting usage. Reporting an estimate as an official price is how these projects lose trust.
  6. Expect the follow-up: how do you prove the optimization worked? Run the same input twice and compare the per-stage panel, not the monthly invoice, which mixes in traffic you did not cause.

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

  1. 这题在考你有没有真的看过账单。凭感觉答「多用缓存、少调模型」的人一听就没做过；能说出「按什么维度拆、拆出来大概什么比例」的才是。
  2. 拆的维度要先立住：按环节（脚本、图像、视频、语音）、按计价单位（按秒、按张、按字符、按 token）、按是否计费（成功、命中缓存、失败未扣费）。三个维度缺一个，报表就会有一类花费永远看不见。
  3. 然后给数量级。多媒体生成这类流水线里视频按秒计价，一集十几秒就是几块钱；图像按张几分钱、语音按字符几厘钱、文本更低。结论是视频通常占九成以上，其余全是零头。
  4. 所以优化顺序不是「哪一环最容易优化」，而是「哪一环最贵」。先优化视频，手段按代价从低到高排：缓存与幂等（不重复调）、分档路由（草稿档用便宜规格）、降级（清晰度、时长、镜头数）、最后才是换厂商谈价。
  5. 补一句可信度：不确定的单价不要写进表。官方只给资源包价的档位要标明是折算值，官方没公开的档位就留空只统计用量——把估算值当官方价报上去，是这类项目最常见的翻车点。
  6. 可预期的追问是「那怎么证明优化生效了」。答案是同一份输入跑两遍，对照面板上按环节的金额与调用次数，而不是看月账单——月账单里混着别人的流量，归因不到你这次改动。

  Key points

  • Break it down three ways: by stage, by billing unit, and by whether the call was actually charged
  • Lead with the ratio: video is billed per second and usually exceeds ninety percent of per-episode cost
  • Optimize expensive first: caching and idempotency, tiered routing, degradation, vendor negotiation last
  • Leave unknown unit prices blank while still counting usage, and label derived prices as estimates
  • Validate by running the same input twice and diffing the per-stage panel, not the monthly invoice

  答题要点

  • 按三个维度拆：环节、计价单位、是否真的计费（成功 / 缓存命中 / 失败未扣费）
  • 先给比例再给结论：视频按秒计价，通常占单集成本九成以上，其余是零头
  • 优化顺序由贵到便宜：缓存与幂等、分档路由、降级、最后才谈价换厂商
  • 拿不到的单价宁可留空只统计用量，折算出来的要标明是折算值
  • 验证靠同一份输入跑两遍对照面板，不看混杂的月账单
• When should you degrade instead of retry, and which dimensions can you degrade first?什么情况下该降级而不是重试？如果决定降级，你有哪些维度可以降，怎么排先后？

  Common in ChinaCommon overseasIntermediate#degradation#retry-strategy

  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.

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

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

  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

  答题要点

  • 重试针对瞬时且与配置无关的失败，降级针对持续且由约束导致的不可完成
  • 内容安全拦截是第三类：既不重试也不降级，要改输入
  • 降级维度按察觉难度排：清晰度、时长、数量，最后才动内容本身
  • 每一步降级都要拿成本模型验证，省不出钱的那一步直接跳过
  • 降级要在开跑前决定，跑到一半再砍会留下半成品且前面的钱白花
• How would you design a budget circuit breaker for a pipeline that calls paid APIs, and what makes the stop safe?给一条会调用付费接口的流水线加预算熔断，你会怎么设计？做到什么程度才算安全停机？

  Common in ChinaCommon overseasDeep dive#budget-control#circuit-breaker

  How to reason about it · think before answering

  1. The discriminator is the word safe. Most candidates can say stop when over budget; what the interviewer wants is the state the system is left in afterwards.
  2. Rule one: the check happens before you spend. Use reservation-style accounting, projecting each paid call with a pure function and deducting it from the budget before issuing the request. After-the-fact accounting only tells you that the money is already gone.
  3. Rule two: the two thresholds do different jobs. A soft limit warns once so a human can decide whether to continue or downgrade; a hard limit must actually stop. Setting both to the same value means you have no soft limit.
  4. Rule three defines a safe stop, and all three parts are required: keep every finished artifact, persist the ledger and the point of interruption, and write the cache. Miss any one and the next run with a higher budget pays again for work already paid for, turning the breaker into a waste amplifier. Calling exit is therefore wrong.
  5. Rule four is refunds: if the vendor does not charge for failed or safety-blocked calls, the reserved amount must be released, otherwise you overstate the bill and silently consume headroom. Mark those ledger rows separately and show them as their own line on the panel.
  6. Two follow-ups to expect. Under concurrency the reservation must be atomic, so a shared counter needs a single owner or an atomic operation or you will oversell. And the limits themselves should be derived from historical usage through the same projection function, not guessed.

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

  1. 这题的区分度全在「安全」两个字。多数人能答出「超预算就停」，但停完之后系统处在什么状态，才是面试官真正想听的。
  2. 先立第一条：判断必须发生在花钱之前。做法是预留式记账——每次调用付费接口前用一个纯函数预估这笔花费，从预算里扣，扣得动才发请求。事后统计只能告诉你已经超了，那时钱已经出去了。
  3. 第二条是两级上限的分工：软上限只提醒且只提醒一次，作用是让人在还有余地时决定继续还是降档；硬上限必须真的停。把两者做成同一个阈值，等于没有软上限。
  4. 第三条才是「安全停机」的定义，三个都要满足：已完成的产物一个不删、账本与停在哪一步落盘、缓存写入。少了任何一条，下一次带更高预算重跑就要把已经花掉的钱再花一遍——熔断反而成了浪费的放大器。所以直接退出进程是错的。
  5. 第四条是退款口径：失败或被内容安全拦下的调用如果厂商不计费，预扣的额度必须退回来，否则你会一边高估账单一边白占预算。台账上这类记录要单独标出来，面板上单独一行。
  6. 可预期的追问有两个。一是「并发下怎么保证不超」——预留必须是原子的，多个 worker 共享一个计数器时要走单点或原子操作，否则会超卖。二是「上限设多少」——用同一个预估函数按历史用量反推，而不是拍脑袋。

  Key points

  • Reserve before you spend: project the cost, deduct it, and skip the call if it does not fit
  • The soft limit warns once for a human decision; the hard limit must actually stop, with different thresholds
  • A safe stop keeps artifacts, persists the ledger and resume point, and writes the cache; never just exit
  • Release reservations for calls the vendor does not charge for, and show them as a separate ledger line
  • Make reservations atomic under concurrency and derive limits from historical usage via the same projector

  答题要点

  • 预留式记账：调用付费接口前先预估并扣减，扣不动就不发请求
  • 软上限只提醒一次供人决策，硬上限必须真的停，两者阈值必须不同
  • 安全停机三条：产物保留、账本与断点落盘、缓存写入，绝不直接退出进程
  • 厂商不计费的失败调用要退回预扣额度，并在台账与面板上单独标出
  • 并发下预留必须原子；上限用同一个预估函数按历史用量反推

D13 Distribution: Adapting to Multiple Platform Specs, Generating Covers and Titles, Batch Export, and Feeding Data Back

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

  Common in ChinaCommon overseasIntermediate#media-pipeline#ffmpeg

  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.

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

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

  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

  答题要点

  • 分清转码与封装：换容器、加 faststart、按时长截断都可以流复制
  • 一次渲染母版，参数取所有目标平台约束的最保守交集
  • 只有分辨率越界、编码不被接受、帧率超范围、体积超限才必须重编码
  • 判定函数返回理由列表，让每次重编码都能被解释
  • 打印编码次数计数器并与朴素做法做对照，才算证明少转了码
• When a model generates creative content such as titles and cover copy, how do you guarantee a quality floor?让模型生成标题、封面文案这类创意内容，怎么保证质量下限？

  Common in ChinaCommon overseasIntermediate#llm-output-quality#candidate-selection

  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.

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

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

  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

  答题要点

  • 按环节的价格选策略：贵的一次做对靠约束输入，便宜的多做几版靠收敛输出
  • 形态是按预设角度批量出候选，再用确定性打分函数挑前几名
  • 打分函数必须输出理由、对违规词扣重分而非过滤、同分给决胜键
  • 另加一道结构兜底：格式不合格就回落本地模板，与质量打分是两件事
  • 不让模型给自己评分，它不稳定也不可解释，最多作为打分的一项输入
• How do you feed post-publication metrics back into the production pipeline? Describe a concrete path.内容发布之后的数据要怎么回流到生产流程里？说一条具体可落地的路径。

  Common in ChinaCommon overseasDeep dive#feedback-loop#analytics

  How to reason about it · think before answering

  1. The easy wrong answer is build a dashboard and review it regularly, which is spectating rather than feedback. The discriminator is whether you can map a metric to a concrete action.
  2. Set the rule first: every conclusion must land on a specific pipeline stage. A metric that maps to no stage cannot be acted on, so it does not belong in the feedback path at all.
  3. Then give a concrete mapping. Retention curves fit naturally because their x axis is time and your timeline table records the start and end of every shot. Early drop maps to cover, title and the first frame; the steepest mid-curve drop is looked up in the timeline to a specific shot id and maps to that shot's duration and camera move; a low completion rate maps to the script's closing hook.
  4. Landing on a stage pays twice: it narrows the edit from a whole episode to a single shot, and the regeneration cost narrows with it. Say this out loud, it connects analytics to cost control and is the differentiating point of the answer.
  5. Keep the rules deliberately dumb and explainable, starting with hand-set thresholds. Replace them with learned ones once you have dozens of episodes, but never give up explainability, because you must be able to justify each recommendation from the log.
  6. Expect the follow-up: how do you merge data across platforms? You do not. Diagnose each platform separately, because the difference in how the same episode performs is itself the signal, and merging erases it.

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

  1. 这题最容易答成「建个数据看板，定期复盘」——那是看热闹，不是回流。区分度在于你能不能给出一条从指标到具体动作的映射。
  2. 先立判据：每一条结论必须落到流水线上一个具体的环节上。落不到环节的指标，看了也改不了，所以它根本不该出现在回流路径里。
  3. 然后给一条真实可落地的映射。留存曲线天然适合，因为横轴是时间，而你的时间轴表里记着每一镜的起止时间：开头几秒的掉幅映射到封面与标题、以及第一镜的首帧；中段掉幅最大的那一段用时间轴反查出具体镜头 id，映射到那一镜的时长与运镜；完播率整体偏低映射到剧本的结尾钩子。
  4. 落到环节的收益是双份的：修改范围从一整集缩到一个镜头，成本也跟着缩到几分之一。这一点要主动说，它把「数据分析」和「成本控制」连起来了，是这题的加分项。
  5. 判据要写得笨且可解释，先用手写阈值。等积累了几十集真实数据再换成从数据里学出来的，但可解释这条不能丢——你必须能对着日志说清为什么建议改这一环。
  6. 可预期的追问是「多平台数据怎么合并」。答案是不要合并，分平台各诊断一次：同一集在不同平台的表现差异本身就是信息，合并会把它抹掉。

  Key points

  • One rule: every conclusion must land on a concrete stage, otherwise it does not belong in the loop
  • Map the retention curve in three segments: opening drop to cover and first frame, steepest mid drop to a shot id via the timeline, low completion to the script hook
  • Landing on a stage shrinks both the edit scope and the regeneration cost to a single shot
  • Start with hand-set thresholds for explainability and learn them later once data allows
  • Diagnose platforms separately; the divergence between them is itself signal

  答题要点

  • 判据只有一条：每条结论必须落到流水线上一个具体环节，落不到就不该进回流路径
  • 留存曲线三段映射：开头掉幅到封面标题与首帧，中段掉幅用时间轴反查到具体镜头，完播率到剧本钩子
  • 落到环节同时缩小了修改范围与重做成本，只重生成一镜而不是重跑一集
  • 先用手写阈值保证可解释，数据够了再换成学出来的规则
  • 多平台数据分别诊断不合并，平台间的差异本身就是信息

D14 A Five-Episode Season: Batch Production, Portfolio Packaging, and a Short-Drama Pipeline Interview Deep Dive

• Walk me through the AI content pipeline you built. What was the hardest part?介绍一下你做的这条 AI 内容生产线，它最难的地方在哪？

  Common in ChinaCommon overseasBasic#project-storytelling#system-design

  How to reason about it · think before answering

  1. This is an open question that tests convergence. Narrating two weeks of work chronologically loses the interviewer in three minutes; delivering one through-line in thirty seconds is what counts as telling a project well.
  2. Open with positioning and scale: an automated pipeline from a one-line premise to publish-ready vertical episodes, one run producing a five-episode season, with humans stepping in only where judgement is required. Numbers first, detail second.
  3. Then answer hardest. That word should not be spent on debugging pain; spend it on a judgement that generates every downstream decision: video generation is the most expensive, slowest and most failure-prone stage at over ninety percent of per-episode cost, so the whole design revolves around issuing one fewer video call.
  4. Attach the chain of consequences in one sentence: idempotency and caching avoid duplicate calls, reference-image reuse reduces retries, the draft tier makes experimentation cheap, and the budget breaker stops a runaway. The chain proves your choices are derived rather than collected.
  5. Leave a deliberate hook for follow-up, such as saying the async task client turned out far harder than expected. That steers the interviewer toward your strongest material instead of a corner you never considered.
  6. Expect the follow-up: do you have real numbers? Keep four from every run: wall time, spend, failure rate and manual interventions. If spend is estimated, say so, rather than letting them assume you pasted a real invoice.

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

  1. 这是一道开放题，考的是收敛能力。把十四天的东西按时间顺序流水账讲一遍，面试官三分钟后就走神了；能在三十秒内给出一条主线，才算会讲项目。
  2. 开头两句要立住定位与规模：从一句话选题到多平台可发布成片的自动化流水线，一次运行产出一季五集，人只在需要判断的地方介入。数字先给，细节后给。
  3. 然后回答「最难」。这个词不该答成「调试很麻烦」，要答成一条能推出后续所有设计的判断：这条线上最贵、最慢、最容易失败的是视频生成，占单集成本九成以上，所以整套工程都是围着「怎么少调一次视频接口」转的。
  4. 接着一句话挂上推论链：幂等与缓存是为了不重复调，参考图复用是为了少试几次，草稿档路由是为了试错时用便宜规格，预算熔断是为了失控时能停住。这条链子证明你的技术选择不是攒来的最佳实践。
  5. 最后主动留一个可被追问的钩子，比如「异步任务的客户端比我预想的复杂得多」——把面试官引到你准备最充分的地方去，而不是等他随机挑一个你没想过的角落。
  6. 可预期的追问是「有真实数据吗」。所以复盘时必须留下四个数字：耗时、花费、失败率、人工介入次数。花费是估算的就要主动说明是估算，别让人以为你贴了张真实账单。

  Key points

  • Position first: from a one-line premise to multi-platform episodes, one run per five-episode season
  • Frame the hardest part as a judgement: video dominates cost and is the slowest, most failure-prone stage
  • Show the derivation chain: idempotency and caching, reference reuse, draft tier, budget breaker
  • Bring four numbers: wall time, spend, failure rate, manual interventions, flagging estimates as estimates
  • Plant a follow-up hook that steers the conversation to your strongest area

  答题要点

  • 先定位再展开：从一句话到多平台成片，一次运行产出一季五集
  • 把最难点答成一条判断：视频占单集成本九成以上且最慢最易失败
  • 用推论链证明设计是导出来的：幂等缓存、参考图复用、草稿档、预算熔断
  • 带上四个数字：耗时、花费、失败率、人工介入次数，估算值要主动标注
  • 主动留一个追问钩子，把话题引向准备最充分的部分
• How do you keep characters and visual style consistent across many generated episodes, and what breaks at a hundred episodes?多集连续生成时，人物与画风的跨集一致性你是怎么保证的？如果要做一百集会遇到什么新问题？

  Common in ChinaCommon overseasIntermediate#consistency#prompt-assembly

  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.

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

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

  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

  答题要点

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

  Common in ChinaCommon overseasDeep dive#architecture-review#trade-offs

  How to reason about it · think before answering

  1. This tests the quality of your self-critique. Saying nothing needs changing ends the conversation; listing trendy technologies is just as bad, because it shows you learned nothing from the build. A good answer is specific, has a cost analysis, and traces back to a concrete stumble.
  2. Set a filter first: only discuss places where you actually got tripped up and now know the right approach. Say plainly where you are still unsure, because naming the limits of your solution proves more than the solution itself.
  3. First, recomputation scope. Editing one line of dialogue currently recomputes the whole downstream subgraph. Better would be for each node to declare which input fields it depends on, so a dialogue edit triggers only speech and subtitles, never video. The cost is more complex node definitions; the benefit is redoing one synthesis instead of a whole shot.
  4. Second, the cost model. The rate card today mixes derived prices with deliberate blanks, which is fine for projection but useless for reconciliation. Once real invoices exist, back out measured unit prices from them and keep a drift alert that fires when projection and reality diverge past a threshold, which beats after-the-fact reconciliation.
  5. Third, the concurrency model. Gates are currently keyed by provider, but modelling them as quota buckets matches reality better, since different endpoints from one vendor have independent quotas while different vendors are fully independent. Rate-limit diagnosis gets far more precise.
  6. Expect the follow-up: why not build it that way originally? Answer honestly that you shipped the smallest working version and spent complexity only where data justified it. That sentence is itself an architectural judgement, and distinguishing necessary complexity from premature complexity is exactly what the interviewer is listening for.

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

  1. 这题在考自我批判的质量。答「没什么要改的」直接出局；答一堆花哨的新技术也不行，因为那说明你没从这次的实践里学到东西。好答案是具体的、有代价分析的、并且能追溯到某一次踩坑。
  2. 先立一个筛选标准：只讲那些我这次真的被绊过、而且知道正确做法的地方。不确定的部分坦白说不确定——说得出方案的边界，比说得出方案本身更能证明你做过。
  3. 第一处可以讲重算范围。审核台上改一句台词，现在是按节点依赖整体重算下游，粒度偏粗；更好的做法是让每个节点声明自己依赖输入的哪几个字段，改台词只触发配音与字幕，不碰视频。代价是节点定义变复杂，收益是重做成本从一整镜降到一次语音合成。
  4. 第二处是成本模型。现在的单价表里有折算值和留空项，估算够用但不能对账；接了真实账单之后应该改成从账单反推实测单价，并保留一个偏差告警——估算和实际差超过阈值就报警，这比事后对账有用得多。
  5. 第三处是并发模型。现在闸门是按 provider 分类做的，更贴近现实的做法是按「配额桶」建模，因为同一家厂商的不同接口配额独立，而不同厂商之间又完全独立。改了之后限流的定位会准很多。
  6. 可预期的追问是「为什么当初不那样做」。诚实回答：当时先做能跑通的最小版本，把复杂度留给已经被数据证明值得的地方。这句话本身就是架构判断——面试官想听的正是你会不会区分「必要的复杂度」和「过早的复杂度」。

  Key points

  • Only discuss stumbles you actually hit and now know how to fix; admit what you are unsure about
  • Move recomputation to field-level dependencies so a dialogue edit skips video regeneration
  • Back out measured unit prices from real invoices and add a projection-versus-actual drift alert
  • Model concurrency gates as quota buckets rather than per provider, matching per-endpoint quotas
  • Explain the original choice: ship the smallest working version and spend complexity only where data justifies it

  答题要点

  • 只讲真的踩过且知道正确做法的地方，不确定的坦白说不确定
  • 重算范围改成按字段级依赖，改台词只触发配音与字幕而不重生成视频
  • 成本模型接真实账单后反推实测单价，并加一个估算与实际的偏差告警
  • 并发闸门从按 provider 改成按配额桶建模，贴合各接口配额独立的现实
  • 解释当初为何没这么做：先做最小可跑版本，把复杂度留给数据证明值得的地方