面试题库

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

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

• 为什么要在厂商 SDK 之上再套一层自己的 provider 接口？什么时候这层反而是负担？Why wrap a vendor SDK in your own provider interface, and when does that layer become a liability?

  国内高频海外高频基础#provider-abstraction#architecture

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

  1. 这题在筛「有没有真的换过一次厂商」。只答「解耦、方便替换」的人，说的是一句所有人都会说的话，区分度在于你能不能给出「这层带来了什么、又赔上了什么」的具体清单。
  2. 怎么拆：先问自己「如果不套这层，哪些能力会散掉」。答案有三样，而且都能落到具体文件上——离线可跑（网络出口收敛到一处才可能打桩）、多厂商并存（业务代码写的是动作而不是某家的四步流程）、计量收口（每次调用的花费必须有唯一一处记账）。
  3. 接着说抽象的位置：接口要按业务动作定义，不按厂商的 HTTP 请求定义。异步视频任务的提交、轮询、取件、下载四步，对业务代码来说是一个 generate；把这四步漏到业务层，抽象就白做了。
  4. 结论与代价：这层会磨掉各家的独有能力（某家支持首尾帧、某家支持结构化运镜参数）。正确处理不是把接口撑大，而是留一个可选透传字段，让需要它的那一处显式承认自己绑定了某一家。
  5. 什么时候是负担：你只会用一家、也永远不会离线跑的时候；以及出现两个信号时——为加一个厂商改了接口签名让另外三个实现跟着改，或者接口里出现了只有一家有的参数名。这两个信号说明抽象抽在了厂商能力的最小公倍数上，位置错了。
  6. 可预期的追问：那要不要直接用某个统一网关或聚合 SDK？可以，但你仍然需要自己的接口，因为聚合层解决的是协议差异，解决不了你自己的落盘契约与记账口径。

  How to reason about it · think before answering

  1. The screen is whether you have ever actually swapped a vendor. Answering only decoupling and easy replacement is what everyone says; the signal is naming what the layer buys and what it costs.
  2. How to break it down: ask what you lose without the layer. Three concrete things — offline runnability (you can only stub when network egress is funneled into one place), multi-vendor coexistence (business code expresses an action, not one vendor's four-step flow), and metering (every call's cost must be recorded in exactly one place).
  3. Then place the abstraction: define it by business action, not by the vendor's HTTP request. Submit, poll, retrieve, download for an async video job is one generate to the caller; leaking those four steps upward defeats the purpose.
  4. Conclusion and cost: the layer sands off vendor-specific capabilities, such as first-and-last-frame conditioning or structured camera parameters. The fix is not a wider interface but one optional passthrough field, so the single call site explicitly admits it is vendor-bound.
  5. When it is a liability: single vendor forever and no offline path. Two warning signs — adding a vendor forced a signature change across the other implementations, or a vendor-only parameter name appeared in the interface. Both mean you abstracted the least common multiple of vendor features.
  6. Likely follow-up: why not just use an aggregation gateway or SDK? You still need your own interface, because aggregators normalize protocols but not your on-disk artifact contract or your cost ledger.

  答题要点

  • 三个理由要说具体：离线可跑、多厂商并存、计量收口，每一个都对应一处真实代码
  • 接口按业务动作定义，异步任务的提交轮询取件下载四步必须关在实现里
  • 把落盘路径写进接口契约，因为厂商返回的图片与视频链接都是会失效的临时链接
  • 代价是磨掉独有能力，用可选透传字段处理，而不是撑大公共接口
  • 两个「抽错了」的信号：加厂商要改签名、接口里出现厂商专有参数名

  Key points

  • Name three concrete reasons: offline runnability, multi-vendor coexistence, and a single metering point
  • Define the interface by business action; submit-poll-retrieve-download stays inside the implementation
  • Put the output file path in the contract, because vendor image and video URLs are short-lived temporary links
  • The cost is losing vendor-specific features; handle it with one optional passthrough field, not a fatter interface
  • Two signs you abstracted wrong: adding a vendor changes the signature, or a vendor-only parameter leaks into the interface

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

• 怎么让模型稳定输出合法的结构化数据？schema 校验失败时你会怎么处理？How do you get a model to emit valid structured data reliably, and what do you do when schema validation fails?

  国内高频海外高频基础#structured-output#schema-validation

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

  1. 这题的题眼在后半句。前半句答「用 JSON 模式」就结束的人，等于说自己没在生产里跑过——真正的活儿全在校验失败之后。
  2. 先把三条路摆开：提示词约束加本地校验；厂商提供的 JSON 模式或结构化输出参数；把数据结构定义成工具的参数 schema 让模型去调。各家对后两条的支持程度和字段名都不一样，选它就等于把这段代码绑在某一家上。
  3. 给出选择依据：要跨厂商、要能离线跑，就选第一条，代价是自己写抠 JSON 与校验；只服务一家且追求成功率，就用那一家的结构化输出。抠 JSON 这一步必须处理围栏与前后寒暄，直接解析整段回复在真实模型上很容易炸。
  4. 校验失败的处理是一条阶梯，别只答重试：把带路径的问题原样喂回去让它只修这些（比换更大的模型有效）；仍不过就降级到只要必填字段的最小结构；再不过就整轮失败并留档，让人来看，而不是吞掉异常返回一个空数组。
  5. 还有一条区分度很高：校验要分两层。判类型与范围只能挡住格式错，挡不住写错对象——引用了不存在的场景 id、镜号重复，这类稿子能通过类型检查，然后在下游某一步才爆。引用完整性必须单独查一遍。
  6. 可预期的追问：重试几次合适？两次。第一次是模型没听话，第二次带着具体问题还改不对，说明是提示词或 schema 本身有问题，再重试只是花钱买同一个错误。

  How to reason about it · think before answering

  1. The real question is the second half. Answering only use JSON mode signals you have never run this in production, because all the work happens after validation fails.
  2. Lay out three paths: prompt constraints plus local validation; a vendor's JSON mode or structured-output parameter; or defining the data structure as a tool's parameter schema. Vendor support and field names differ, so the latter two bind that code to one vendor.
  3. State the selection rule: cross-vendor or offline-capable means path one, paying with your own JSON extraction and validator; single-vendor and success-rate-driven means use their structured output. Extraction must handle code fences and surrounding chatter — parsing the whole reply directly breaks often.
  4. Handle failure as a ladder, not just a retry: feed the path-annotated issues back and ask it to fix only those (more effective than upgrading the model); then degrade to a minimal required-fields-only structure; then fail the round and persist the artifact for a human — never swallow the error and return an empty array.
  5. High-signal point: validate in two layers. Type and range checks catch malformed data but not wrong references — a nonexistent scene id or a duplicate shot number passes typing and explodes downstream. Referential integrity needs its own pass.
  6. Likely follow-up: how many retries? Two. The first covers a disobedient model; if it still fails with concrete issues in hand, the prompt or the schema itself is wrong and more retries just buy the same error.

  答题要点

  • 三条路：提示词加本地校验、厂商结构化输出参数、工具参数 schema，后两条会绑定厂商
  • 抠 JSON 要处理围栏与前后寒暄，不能直接解析整段回复
  • 失败处理是阶梯：带路径的问题喂回去只修这些、降级到最小结构、整轮失败留档给人
  • 校验分两层，类型与范围之外必须单独查引用完整性与 id 唯一性
  • 重试上限两次，再不过说明是提示词或 schema 的问题，不是运气问题

  Key points

  • Three paths: prompt plus local validation, vendor structured output, or tool parameter schema — the latter two bind you to a vendor
  • JSON extraction must handle code fences and surrounding prose; never parse the whole reply directly
  • Failure handling is a ladder: feed back path-annotated issues, degrade to a minimal structure, then fail the round and persist for a human
  • Validate in two layers — types and ranges, then referential integrity and id uniqueness
  • Cap retries at two; beyond that the prompt or schema is wrong, not luck

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

• 生成模型的角色一致性问题是怎么来的？工程上有哪几种缓解手段，代价分别是什么？Where does the character consistency problem in image generation come from, and what engineering mitigations exist, with what trade-offs?

  国内高频海外高频基础#image-generation#consistency

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

  1. 这题的区分度在第一句。答「提示词写得不够细」就掉到了使用者视角；面试官想听的是「模型每次请求都是独立采样、没有跨请求记忆」这个机制层面的原因。
  2. 顺着机制往下推就有了完整答案：提示词只约束了你写出来的那些自由度，没写的部分每次重新掷一遍；而人脸的辨识度恰好集中在脸型、眼距、鼻梁这些你没法用文字穷尽的细节上。
  3. 手段按「锁得住什么」分三层说，不要混在一起：提示词模板锁风格与构图，成本几乎为零；随机种子锁同一提示词的可复现性，换提示词即失效；参考图锁人脸，但每次请求只能带一张，双人同框锁不了两个人。
  4. 代价这一段才是拉开差距的地方：参考图要求你先有一张基准图，于是流程里必须插入一次「定妆并由人挑一张」的环节，这是整条自动化流水线上少数值得保留的人工卡点。
  5. 还要主动说一个反直觉的做法：派生图必须都参考同一张基准图，不能参考上一张。参考上一张会让偏差逐张累积，第五张已经不是同一个人了。
  6. 可以预期的追问：一致性做不到怎么兜底？答案是改镜头语言——把双人同框拆成正反打的单人镜头、次要角色用更远的景别，用拍法回避接口能力的边界。

  How to reason about it · think before answering

  1. The differentiator is your first sentence. Saying 'the prompt wasn't detailed enough' reads as a user, not an engineer; the answer they want is that each request is an independent sample with no memory across calls.
  2. Follow the mechanism: a prompt only constrains the degrees of freedom you actually wrote down, and everything unwritten gets re-sampled — while face recognizability lives exactly in the details text cannot exhaust.
  3. Present the mitigations in three layers by what each one actually locks: a prompt template locks style and framing at near-zero cost; a fixed seed locks reproducibility for one identical prompt and stops helping the moment the prompt changes; a reference image locks the face, but only one per request, so two faces in one frame cannot both be locked.
  4. The trade-off discussion is where candidates separate: using a reference image means you must first produce a base image, which forces a human 'pick the reference sheet' step into an otherwise unattended pipeline.
  5. Volunteer the counter-intuitive rule: every derived image must reference the same base image, never the previous one. Chaining references accumulates drift, and by the fifth image it is a different person.
  6. Expect the follow-up: what if consistency still fails? The answer is cinematography — split two-character frames into reverse-angle singles and push secondary characters to wider shots, working around the API's limits with shot design.

  答题要点

  • 根因是模型每次请求独立采样、没有跨请求记忆，提示词没约束到的自由度会被重新掷一遍
  • 提示词模板锁风格与构图，成本几乎为零，但锁不住五官
  • 随机种子锁的是同一提示词的可复现性，提示词一变就失效
  • 参考图锁人脸，代价是必须先有基准图，且每次请求只能带一张，双人同框锁不了两个人
  • 派生图统一参考同一张基准图，不要链式参考上一张，否则偏差会逐张累积

  Key points

  • The root cause is that each request is an independent sample with no cross-request memory, so unconstrained degrees of freedom get re-rolled
  • A prompt template locks style and framing at near-zero cost but cannot lock facial detail
  • A fixed seed locks reproducibility for one identical prompt and stops helping once the prompt changes
  • A reference image locks the face, but you must first produce a base image and only one reference is allowed per request
  • Derive every variant from the same base image rather than chaining off the previous one, or drift accumulates image by image

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

• 轮询间隔怎么定？为什么不能一直用固定间隔死等？How do you choose a polling interval, and why is a fixed interval a bad default?

  国内高频海外高频基础#async-task#backoff

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

  1. 这是一道送分题，但它有三个层次，只答出第一层拿不到高分。面试官想看的是你有没有真的写过这个循环。
  2. 第一层是成本：一个排队五分钟的任务，用一秒的固定间隔就是三百次无效请求。查询接口自己也有速率限制，你很可能自己把自己打到限流，然后在日志里看到「生成失败：限流」，还以为是生成接口的问题。
  3. 第二层是退避要封顶：只乘不封顶的话，退到后面已经是几分钟查一次，任务早就好了你还在睡。上限的选法是「用户能忍受的额外等待」，一般十几到二十秒。
  4. 第三层最容易写错，也是这题真正的区分点：超时判断必须放在睡觉之前，判据是「睡下去会不会越过截止时间」。先睡再判会让你在预算之外多睡整整一轮，退避到二十秒时就是白等二十秒。
  5. 另外提一条顺序：先判终态再判超时。任务恰好在最后一次查询里成功却被当成超时扔掉，等于付了钱还丢了产物。
  6. 可以预期的追问：起步间隔怎么定？按这类任务的典型耗时定，比典型耗时的十分之一略大即可；再往细说就是首次查询可以稍微延后一点，因为刚提交的任务几乎不可能立刻完成。

  How to reason about it · think before answering

  1. This looks like a giveaway, but it has three layers and only the first one is obvious. They want to know whether you have actually written this loop.
  2. Layer one is cost: a task queued for five minutes polled every second is three hundred wasted requests. The query endpoint has its own rate limit, so you can throttle yourself and then misread 'rate limited' in the logs as a generation problem.
  3. Layer two is capping the backoff: multiply without a cap and you end up polling every few minutes, sleeping long after the task finished. Pick the cap from what extra wait a user tolerates — usually in the ten-to-twenty-second range.
  4. Layer three is where people actually get it wrong: the timeout check belongs before the sleep, and the test is whether sleeping would cross the deadline. Sleeping first means overshooting the budget by a full interval, which at a twenty-second backoff is twenty wasted seconds.
  5. Mention ordering too: check terminal states before the timeout. Discarding a task that just succeeded on the final poll means paying for an artifact you then throw away.
  6. Expect the follow-up: how do you pick the initial interval? From the typical duration of this class of task, a bit above a tenth of it; and the very first poll can be delayed slightly, since a just-submitted task is almost never done.

  答题要点

  • 固定间隔要么太密造成大量无效请求并把自己打到限流，要么太疏让完成后的等待过长
  • 用指数退避：从接近典型耗时十分之一的间隔起步，每轮乘一个系数
  • 退避必须封顶，上限按用户能忍受的额外等待来定
  • 超时判断放在 sleep 之前，判据是「睡完会不会越过截止时间」，否则会在预算之外多睡一轮
  • 先判终态再判超时，避免把最后一次查询里刚成功的任务误杀

  Key points

  • A fixed interval is either too tight, wasting requests and throttling yourself, or too loose, adding dead time after completion
  • Use exponential backoff starting near a tenth of the task's typical duration
  • Cap the backoff, choosing the cap from the extra wait a user will tolerate
  • Check the timeout before sleeping, testing whether the sleep would cross the deadline, or you overshoot the budget by a full interval
  • Check terminal states before the timeout so a task that just succeeded is not discarded

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

• 多角色配音里，怎么保证同一个角色跨集用的是同一个声音？In a multi-character pipeline, how do you guarantee the same character keeps the same voice across episodes?

  国内高频海外高频基础#tts#consistency#provider-abstraction

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

  1. 这题看着像配音问题，其实考的是状态该存在哪里。答「配置里写死」不算错，但只答到这一层看不出工程判断。
  2. 先说清楚风险来自哪：声音是角色身份的一部分，观众对它的敏感度不低于脸。跨集不一致的典型成因有三个——每集独立跑一次流程、音色靠临时映射或随机挑选、以及某次为了改一句台词的语气顺手改了这个角色的全局参数。
  3. 解法是把音色归档而不是归代码：角色档案里带一个音色字段，配音环节只读不写。这样一致性由档案保证，跟哪一集、哪一次运行、谁跑的都无关。这跟角色形象靠基准图归档是同一套思路。
  4. 但只存音色标识还不够，跨集听感一致还依赖另外两项：基调情绪与语速。同一个音色用两种语速念，听起来像两个人的状态。所以档案里要一起存这三项，单条台词只允许覆盖情绪，不允许覆盖语速。
  5. 再补一层防御：把音色标识连同模型名一起记进产物元数据。厂商下线或重命名一个音色是会发生的，你要能查出「第二季为什么听起来不一样」，而不是只能凭记忆猜。
  6. 可以预期的追问：如果厂商真的下线了那个音色怎么办？答案是把音色选择也做成 provider 抽象的一部分：档案里存的是角色的音色角色定位，映射到具体厂商音色的表放在适配层，换厂商或补映射时不动档案。

  How to reason about it · think before answering

  1. This looks like a voice question but is really about where state lives. 'Hardcode it in config' is not wrong, but stopping there shows no engineering judgment.
  2. Name the risk first: voice is part of a character's identity, and audiences are about as sensitive to it as to a face. Inconsistency across episodes has three usual causes — running each episode as an independent pipeline, picking voices from an ad-hoc or random mapping, and someone tweaking a character's global parameters while fixing the delivery of one line.
  3. The fix is to file the voice in the character record rather than in code: the record carries a voice id, and the dubbing step only reads it. Consistency then holds regardless of episode, run or operator — the same pattern as pinning appearance to a base reference image.
  4. Storing the voice id alone is not enough. Perceived sameness also depends on the baseline emotion and the speaking rate; the same voice at two different rates sounds like a different state of a person. Keep all three in the record, and allow per-line overrides of emotion only, never of rate.
  5. Add a defensive layer: record the voice id together with the model name in the artifact metadata. Vendors do retire and rename voices, and you want to be able to answer 'why does season two sound different' from data rather than memory.
  6. Expect the follow-up: what if the vendor retires that voice? Make voice selection part of the provider abstraction — the record stores the character's voice archetype, and the mapping to a concrete vendor voice lives in the adapter, so swapping vendors never touches the character records.

  答题要点

  • 把音色存进角色档案，配音环节只读不写，一致性与集数、运行次数、操作人无关
  • 档案里要同时存音色标识、基调情绪与语速；单条台词只允许覆盖情绪，不允许覆盖语速
  • 把音色标识与模型名一起写进产物元数据，便于回答「为什么这一季听起来不一样」
  • 跨集不一致的典型成因是每集独立跑、临时映射、以及改一句台词时顺手改了全局参数
  • 音色选择应纳入 provider 抽象：档案存角色的音色定位，具体厂商音色的映射放在适配层

  Key points

  • Store the voice in the character record and have the dubbing step read it only, so consistency is independent of episode, run or operator
  • Keep voice id, baseline emotion and speaking rate together; allow per-line emotion overrides but never rate overrides
  • Write the voice id and model name into artifact metadata so you can explain why a later season sounds different
  • Typical causes of drift are per-episode independent runs, ad-hoc mappings, and global tweaks made while fixing one line
  • Fold voice selection into the provider abstraction: records hold the archetype, the adapter maps it to a concrete vendor voice

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

• 把多个视频片段拼成一条完整的视频，什么时候可以不重新编码，什么时候必须重编码？When can you concatenate video segments without re-encoding, and when must you re-encode?

  国内高频海外高频基础#ffmpeg#encoding#media-pipeline

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

  1. 这是一道概念送分题，但送分的是「说出前提」的人。答「用 concat 就行」和答「参数一致才能流拷贝」，在面试官眼里是两个水平。
  2. 判据只有一条：拼接是不是只需要把数据包按顺序搬进新容器。只搬不算，就能流拷贝；只要有任何一帧画面是新算出来的，就必须重编码。
  3. 流拷贝的前提要能背出来：分辨率、帧率、像素格式、编码器、音频采样率、声道数全部一致。差一项，产物要么花屏掉音，要么时长错乱。
  4. 必须重编码的典型场景：转场（那几帧是新画面）、缩放补边到统一画布、混入新的音轨、改变编码参数。AI 生成的素材尺寸和音轨天然不一致，所以实际工程里几乎总要先归一化。
  5. 结论落在一个组合拳上：每一镜单独走一次滤镜图做归一化，然后用流拷贝把参数已经一致的片段拼起来。重编码的总量还是一遍，但换来了对每一镜的完全控制。
  6. 可预期的追问是「怎么判断素材参数一不一致」。答：用 ffprobe 把每段的关键字段读出来做一次比对，不一致就走归一化，这一步也是自动化流水线里必须有的前置检查。

  How to reason about it · think before answering

  1. This is a giveaway concept question, but it only gives points to people who state the precondition. 'Just use concat' and 'stream copy requires identical parameters' read as two different levels.
  2. There is exactly one criterion: does concatenation only need to move packets into a new container in order? If yes, stream copy works. If even one frame has to be newly computed, you must re-encode.
  3. Be able to recite the preconditions: resolution, frame rate, pixel format, codec, audio sample rate and channel layout must all match. Miss one and you get corruption, dropped audio, or a broken duration.
  4. Cases that force re-encoding: transitions (those frames are new), scaling and padding to a common canvas, mixing in a new audio track, or changing encoding parameters. AI-generated material varies in size and often lacks audio, so normalization is almost always required in practice.
  5. The conclusion is a combination: normalize each shot with its own filter graph pass, then stream-copy the now-identical segments together. Total re-encoding is still one pass, but you gain full control over each shot.
  6. Expect the follow-up 'how do you know whether the parameters match'. Answer: read the key fields of each segment with ffprobe and compare. That precheck belongs in any automated pipeline.

  答题要点

  • 判据是拼接是否只需要搬数据包：只搬就能流拷贝，有新算出来的帧就必须重编码。
  • 流拷贝的前提：分辨率、帧率、像素格式、编码器、采样率、声道数全部一致。
  • 转场、缩放补边、混入新音轨、改编码参数，这几类一定要重编码。
  • 实践中的组合拳：先逐镜归一化，再流拷贝拼接，重编码总量仍是一遍。
  • 用 ffprobe 比对各段参数，作为流水线里的前置检查。

  Key points

  • The criterion is whether concatenation only moves packets: if so, stream copy; if any frame is newly computed, re-encode.
  • Stream-copy preconditions: identical resolution, frame rate, pixel format, codec, sample rate and channel layout.
  • Transitions, scale-and-pad, mixing a new audio track, and changing encoding parameters all force re-encoding.
  • The practical combination: normalize per shot first, then stream-copy concatenate. Total re-encoding stays at one pass.
  • Use ffprobe to compare segment parameters as a pipeline precheck.

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

• 怎么度量一条生成流水线的成本？除了钱还要量什么？How do you measure the cost of a generation pipeline, and what besides money should you measure?

  国内高频海外高频基础#observability#cost-accounting#pipeline-design

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

  1. 这题看着是送分题，题眼其实在「除了钱」。只报一个总金额的人，做不出任何优化决策，因为总金额不告诉你该动哪里。
  2. 第一步是确定度量的粒度：**按环节摊开**。一个总数没有信息量，一张按环节分列的表能立刻告诉你钱花在哪、时间花在哪。本课量过一集：五张图一毛二五、配音不到两分、三个镜头的视频十块五，视频占了九成八——这个结论只有摊开才看得见。
  3. 第二步是把「钱」之外的三样一起量：耗时决定一天能出几集；调用次数决定会不会撞上厂商的速率限制；产物数是最朴素的完整性校验，四个镜头就该有四个视频，少一个说明某处静默失败了。
  4. 第三步是把估算和真实分开。离线或压测时拿不到真实金额，可以按公开单价折算，但**必须标明它是折算值**，而且折算逻辑和真实金额不能混在一条路径上算，否则账永远对不上。
  5. 还要提醒一句常被忽略的：离线模式下的耗时排名往往是假的。接口被打了桩，本地的编码步骤反而成了大头，照着这张图做优化会优化错地方。
  6. 可预期的追问是「量完之后先优化哪一项」。答：先优化能被数字证明收益的那一项。这个场景里是失败重跑造成的浪费，因为它直接等于账单上的金额；并发排第二，因为在产出还不稳定时并发只会让你更快地烧钱。

  How to reason about it · think before answering

  1. This looks like a giveaway, but the real question is 'besides money'. Anyone who reports a single total cannot make an optimization decision, because a total does not say where to act.
  2. First decide the granularity: break it down per stage. One number carries no information; a per-stage table immediately shows where the money and the time went. Measured on one episode here: five images cost 0.125 yuan, voice under two cents, three video shots 10.5 yuan — video is 98 percent. You only see that broken down.
  3. Second, measure three things besides money: elapsed time decides how many episodes per day, call count decides whether you hit provider rate limits, and artifact count is the crudest completeness check — four shots should yield four clips, and a missing one means something failed silently.
  4. Third, separate estimates from real spend. Offline or in load tests you have no real amounts, so derive them from published unit prices — but label them as estimates, and never mix the two on one code path or the books will never reconcile.
  5. Also worth flagging: offline timing rankings are usually fake. With the APIs stubbed, local encoding becomes the biggest slice, and optimizing against that chart targets the wrong thing.
  6. Expect the follow-up 'what do you optimize first'. Answer: whatever has a number attached. Here it is waste from failed reruns, because it equals money on the bill. Concurrency comes second — before output is stable, concurrency only burns money faster.

  答题要点

  • 按环节摊开，不要只给一个总数，否则无法定位该优化哪里。
  • 除了金额还要量耗时、调用次数、产物数，各自对应吞吐、限流、完整性。
  • 估算与真实金额分开计算，估算必须标明是折算值。
  • 注意离线模式下耗时排名不可信，别照着假图做优化。
  • 优化顺序按「收益能不能被数字证明」排，不按直觉排。

  Key points

  • Break the cost down per stage; a single total cannot tell you where to act.
  • Besides money, measure elapsed time, call count and artifact count — throughput, rate limits and completeness.
  • Keep estimated and real spend on separate paths, and always label estimates as estimates.
  • Offline timing rankings are unreliable; do not optimize against a stubbed profile.
  • Prioritize by which improvement has a number attached, not by intuition.

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

• 什么时候该自己写调度，什么时候该直接上现成的工作流引擎？When should you write your own scheduler, and when should you adopt an off-the-shelf workflow engine?

  国内高频海外高频基础#architecture#build-vs-buy#workflow-engine

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

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

  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.

  答题要点

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

  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 并发与配额：多集同时开机，还不能把厂商额度打爆

• 优先级队列容易出现饿死，你会怎么防？Priority queues starve low-priority work. How do you prevent that?

  国内高频海外高频基础#scheduling#priority-queue#fairness

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

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

  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.

  答题要点

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

  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 审片室：能预览、能改词、能重生成单镜的人机协作后台

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

  国内高频海外高频基础#human-in-the-loop#pipeline-design#cost

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

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

  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.

  答题要点

  • 判据是「卡点放在下游最贵的那一步之前」，问的是这里错了往后白花多少钱。
  • 三个位置：剧本定稿后、首帧出来后视频生成前、成片合成后发布前。
  • 首帧那一道性价比最高：首帧是最便宜的一档，视频是最贵的一档，同一个镜头差出一到两个数量级。
  • 前两道可以默认放行加超时继续，只有合规那一道必须硬卡。
  • 人力不够就分级：机器先打分，人只看低分的那些。

  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.

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

• 内容安全审核放在生成前还是生成后？为什么两边都要有？Should content safety checks run before generation or after? Why both?

  国内高频海外高频基础#content-safety#moderation#pipeline-design

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

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

  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.

  答题要点

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

  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 成本与模型路由：按环节选模型、缓存、降级与预算熔断

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

  国内高频海外高频基础#cost-analysis#observability

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

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

  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.

  答题要点

  • 按三个维度拆：环节、计价单位、是否真的计费（成功 / 缓存命中 / 失败未扣费）
  • 先给比例再给结论：视频按秒计价，通常占单集成本九成以上，其余是零头
  • 优化顺序由贵到便宜：缓存与幂等、分档路由、降级、最后才谈价换厂商
  • 拿不到的单价宁可留空只统计用量，折算出来的要标明是折算值
  • 验证靠同一份输入跑两遍对照面板，不看混杂的月账单

  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

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

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

  国内高频海外高频基础#project-storytelling#system-design

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

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

  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.

  答题要点

  • 先定位再展开：从一句话到多平台成片，一次运行产出一季五集
  • 把最难点答成一条判断：视频占单集成本九成以上且最慢最易失败
  • 用推论链证明设计是导出来的：幂等缓存、参考图复用、草稿档、预算熔断
  • 带上四个数字：耗时、花费、失败率、人工介入次数，估算值要主动标注
  • 主动留一个追问钩子，把话题引向准备最充分的部分

  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