面试题库

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

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

• 一个重度依赖付费第三方生成接口的系统，怎么做到没有密钥也能开发和测试？怎么证明这套离线模式没有骗自己？For a system that depends heavily on paid third-party generation APIs, how do you make it developable and testable without keys — and how do you prove the offline mode is not fooling you?

  国内高频海外高频深入#offline-testing#test-strategy

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

  1. 这题的区分度全在后半句。前半句人人都会答「打 mock」，能答出「怎么证明它没骗自己」的才是真做过——因为绝大多数 mock 的实际效果是「保证程序不崩」，而不是「保证逻辑正确」。
  2. 怎么拆：先定桩的位置。桩只打在网络出口上，也就是每个 provider 的那一个方法里；业务代码里一个环境变量判断都不该有。一旦业务逻辑分叉，离线跑的就是另一个程序，你验的东西和线上没关系。
  3. 再定桩的质量：离线实现要产出真实形态的产物，而不是返回一个常量。做媒体流水线就用本地工具真的生成占位文件（纯色图、测试画面加音轨、正弦波音频），做检索就返回结构完整的假文档，做流式就按节奏一段段吐。目的是让下游的解析、状态机、时间轴计算真的被执行一遍。
  4. 证明它没骗自己的判据只有一条：**改一个输入，输出必须跟着变**。占位图的颜色随镜头描述变、占位音频时长随台词字数变、总时长随分镜数变——这说明中间的业务逻辑跑过了。如果换什么输入产物都一样，你验的只是没崩。
  5. 还要说收益：一次真跑几十分钟、上百块钱，一个下标写错就要等半小时才看得到；离线把这个反馈循环压到几秒，团队才会愿意持续重构这段代码。这是工程要求，不是玩具。
  6. 可预期的追问：那真实路径谁来保证？答案是分层——离线模式覆盖业务逻辑与回归测试，真实路径靠少量的冒烟用例定期跑，两者验的是不同的东西，不能互相替代。

  How to reason about it · think before answering

  1. All the signal is in the second half. Everyone says mock it; only people who have done it can say how they prove the mock is honest, because most mocks only guarantee the program does not crash.
  2. Break it down by first fixing where the stub goes: only at the network egress, inside each provider's one method. No environment check belongs in business code — the moment business logic branches, offline runs a different program and your testing says nothing about production.
  3. Then fix the quality of the stub: the offline implementation should emit artifacts of the real shape rather than a constant. For a media pipeline, actually generate placeholder files locally (solid-color frames, a test pattern with an audio track, a sine-wave clip); for retrieval, return well-formed fake documents; for streaming, emit chunks with realistic pacing. The point is to force downstream parsing, state machines, and timeline math to execute.
  4. The one test that proves it is honest: change an input and the output must change. Placeholder color tracks the shot description, placeholder audio length tracks the line length, total runtime tracks shot count. If every input yields identical artifacts, you only verified that nothing crashed.
  5. State the payoff too: a real run costs tens of minutes and real money, so an off-by-one takes half an hour to surface. Offline collapses that loop to seconds, which is what makes continued refactoring affordable. This is an engineering requirement, not a toy.
  6. Likely follow-up: who then covers the real path? Layer it — offline covers business logic and regression, while a small set of smoke tests exercises the real vendors on a schedule. They verify different things and do not substitute for each other.

  答题要点

  • 桩只打在网络出口，业务代码里不出现任何离线判断分支
  • 离线实现要产出真实形态的产物，让下游解析、状态机、时间轴计算真的执行
  • 唯一的验收判据是「改一个输入，输出跟着变」，做不到就只验了没崩
  • 收益是把几十分钟上百块的反馈循环压到几秒，团队才敢持续重构
  • 真实路径靠少量定期冒烟用例覆盖，与离线模式验的是不同的东西

  Key points

  • Stub only at the network egress; business code contains no offline branch
  • The offline implementation must emit real-shaped artifacts so downstream parsing, state machines, and timeline math actually run
  • The single acceptance test is that changing an input changes the output; otherwise you only verified it did not crash
  • The payoff is collapsing a tens-of-minutes, real-money feedback loop into seconds, which is what makes refactoring affordable
  • Cover the real path with a small scheduled smoke suite; it verifies something different from the offline mode

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

• 生成加评审这种双角色循环，收敛条件该怎么定才不会一直烧钱？In a generator-plus-reviewer loop, how do you define convergence so it does not burn budget indefinitely?

  国内高频海外高频深入#agent-loop#cost-control

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

  1. 这题在考「你有没有让这种循环真的停下来过」。只答「设一个最大轮数」拿不到分，那只是防死循环，不是收敛设计。区分度在于你能不能说出三个出口以及评审本身该怎么构造。
  2. 先拆评审：评审不该是一个模型，而是两层——能被程序判定的硬伤用代码查（字段缺失、数值越界、长度超限、引用不合法），程序判不了的软伤才交给模型。这一步决定了分数稳不稳定：全交给模型，同一份稿子两次评分能差十几分，循环就没有收敛可言。
  3. 再说三个出口：达标就停（阈值是「够用」不是「完美」，追最后几分成本远高于收益）；到轮数上限就停，而且要交出历史最高分那一稿而不是最后一稿，因为评审有波动；剩下的问题全是软伤时转人工，因为让模型自己评自己改只会原地打转。
  4. 还要说计分方式：硬伤应该占大头（比如七成），软分占小头。否则模型一句好评就能盖过五条实打实的字段问题，循环会在第一轮就假装达标。
  5. 结论加代价：三个出口都需要参数，而参数必须实测调。阈值高了轮数用满，低了稿子不能看；上限大了烧钱，小了永远差一口气。上线前要把分数曲线画出来看它是不是单调上升。
  6. 可预期的追问：怎么知道循环真的在变好而不是在抖动？看硬伤条数，它是确定性的；分数会抖，硬伤条数不会。硬伤降不下去就说明写手根本没在按意见改，问题出在意见的粒度上——意见要带分类标签，模型才知道该改哪一类。

  How to reason about it · think before answering

  1. This screens whether you have ever made such a loop actually terminate. Answering only set a max round count scores nothing — that prevents an infinite loop, it is not convergence design. The signal is naming three exits plus how the reviewer itself is built.
  2. Start with the reviewer: it should not be one model but two layers. Machine-checkable defects (missing fields, out-of-range numbers, length limits, invalid references) go to code; only the judgment calls go to the model. This decides score stability — a pure-model reviewer can swing by ten-plus points on the same draft, and then convergence is meaningless.
  3. Then the three exits: stop on threshold (the threshold means good enough, not perfect — chasing the last few points costs far more than it returns); stop at the round cap, handing back the highest-scoring draft rather than the last one, because review scores fluctuate; and escalate to a human once only judgment-call issues remain, since a model reviewing and revising itself just circles.
  4. Also cover the scoring weights: hard defects should dominate, say seventy percent, with the model's soft score at thirty. Otherwise one flattering model review outweighs five real field errors and the loop declares success on round one.
  5. Conclusion and cost: all three exits need parameters, and parameters need empirical tuning. Too high a threshold burns every round; too low ships an unusable draft. Plot the score curve before shipping and confirm it rises monotonically.
  6. Likely follow-up: how do you know it is improving rather than oscillating? Track the hard-defect count — it is deterministic, while the score jitters. If hard defects do not fall, the writer is not acting on feedback, and the fix is feedback granularity: tag each issue with a category so the model knows which class to repair.

  答题要点

  • 评审分两层：硬伤用代码判，软伤才交给模型，否则分数不稳定、循环无从收敛
  • 三个出口：达标就停、到轮数上限交历史最高分那一稿、只剩软伤时转人工
  • 计分让硬伤占大头，避免模型一句好评盖过实打实的字段问题
  • 评语必须带分类标签，写手才能只改那一类，改稿才是收敛的
  • 观测收敛看硬伤条数而不是分数，分数会抖、硬伤条数是确定的

  Key points

  • Split the reviewer: code judges hard defects, the model judges only judgment calls — otherwise scores are unstable and nothing converges
  • Three exits: stop on threshold, stop at the round cap returning the best draft, escalate to a human when only soft issues remain
  • Weight hard defects heavily so a flattering model review cannot mask real field errors
  • Tag each review issue with a category so the writer repairs one class at a time
  • Measure convergence by hard-defect count, not score — the score jitters, the count does not

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

• 生成类资产要做复用，缓存键你会怎么设计，才能既省钱又不会串戏？How would you design the cache key for reusing generated assets so that you save money without serving the wrong asset?

  国内高频海外高频深入#caching#cost#image-generation

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

  1. 这题考的是缓存的两类错误，而且两类的代价完全不对称。少命中只是多花钱，错命中会把上一集的道具塞进这一集——前者可量化，后者是内容事故。
  2. 推导链只有一句：**键必须由所有会改变产物的输入算出来，一项不多一项不少。** 多算了不该算的（比如输出路径），改一次目录结构缓存全部失效，白花一遍钱；少算了该算的（比如提示词），换了描述还命中老图，就是串戏。
  3. 落到这个场景，参与哈希的是：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子。用 sha1 之类取个短摘要当 id，元数据里再把这几项原样存一份，出问题能照着复现。
  4. 然后主动把边界说清楚，这是加分项：模型 id 与版本要不要进键？要。风格模板改了怎么办？它是提示词的一部分，进键之后天然全部失效——所以模板要谨慎改，或者给它一个版本号，让你能决定失效的范围。
  5. 生产视角还有一条：失败的生成不要写进缓存，否则你会稳定复用一张被审核拦下的空结果。命中缓存的那条路径也要记台账并标成命中，不然你算不出缓存到底省了多少钱。
  6. 可以预期的追问：缓存要不要过期？答案是内容型资产通常不设时间过期，而是靠版本号显式失效；时间过期会在你毫无预期的时候让一整集重新生成一遍。

  How to reason about it · think before answering

  1. This question is about two kinds of cache error with wildly asymmetric cost. A miss only costs money; a wrong hit puts last episode's prop into this one. The first is a number, the second is a content incident.
  2. The derivation is one sentence: the key must be computed from every input that changes the artifact, and nothing else. Include something irrelevant, like the output path, and one directory refactor invalidates everything and you pay again; omit something relevant, like the prompt, and a changed description silently serves the old image.
  3. Concretely, hash the asset kind, the owning entity id, the variant name, the full prompt, the reference image identity and the seed. Take a short digest as the id, and store those fields verbatim in the metadata so any artifact can be reproduced.
  4. Then name the boundaries yourself: does the model id and version belong in the key? Yes. What if the style template changes? It is part of the prompt, so it invalidates everything by construction — which is why templates should carry a version number, letting you choose the blast radius.
  5. One more production note: never cache failed generations, or you will faithfully reuse an empty result that safety review rejected. Cache hits also belong in the cost ledger, flagged as hits, otherwise you cannot report how much caching saved.
  6. Expect the follow-up: should the cache expire? Content assets usually should not expire on time; invalidate explicitly by version instead, because a time-based expiry regenerates a whole episode at the least convenient moment.

  答题要点

  • 键由所有会改变产物的输入算出：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子，再加模型 id 与版本
  • 不要把输出路径或文件名放进键，改目录结构会让缓存整体失效，白付一遍钱
  • 少算提示词这类输入会导致错命中，那是内容事故，代价远高于少命中
  • 元数据里原样保存参与哈希的各项，出问题能复现；失败的生成不写缓存
  • 命中缓存也要记台账并标成命中，否则算不出缓存省了多少；失效靠显式版本号而不是时间过期

  Key points

  • Derive the key from everything that changes the artifact: asset kind, owner id, variant, full prompt, reference image identity, seed, plus model id and version
  • Keep output paths and filenames out of the key, or one directory refactor invalidates the whole cache and you pay twice
  • Omitting inputs like the prompt causes wrong hits, which are content incidents and far costlier than misses
  • Store the hashed fields verbatim in metadata so any artifact is reproducible, and never cache failed generations
  • Record cache hits in the cost ledger flagged as hits, and invalidate explicitly by version rather than by time

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

• 生成类接口返回失败，你怎么判断该不该重试？重试几次之后该做什么？When a generation API returns a failure, how do you decide whether to retry, and what happens after the retries run out?

  国内高频海外高频深入#error-handling#retry#cost

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

  1. 这题的题眼是「判断」。按状态码首位数字一刀切是最常见的错误答案，因为生成类接口的业务错误码往往和 HTTP 状态码不在一个层面上——很多厂商的失败是 HTTP 200 加一个响应体里的业务码。
  2. 给一条可复用的判据，比背错误码表有用：问三个问题——等一等会不会好、改输入会不会好、还是必须叫人来。三个问题对应三种处置：退避重试、修请求、立刻告警。
  3. 落到具体：限流和服务端故障属于第一类，程序自己扛；参数无效与内容审核属于第二类，重试一万次都是同一个错，而且会挤占限流额度让真正该重试的排不上号；鉴权失败与余额不足属于第三类，重试只会延迟告警。
  4. 然后单独处理超时，这是最能体现经验的一条：超时不是失败，是状态未知，对方队列里那个任务可能还在跑甚至已经成了。所以超时之后不能直接重提，要先按幂等键查一遍已有产物。
  5. 重试用尽之后要做三件事，缺一不可：把这一条标成失败并记下最后一次的错误码与请求参数、继续跑批次里剩下的任务不要中断、把失败清单汇总成一次可读的告警而不是每条发一次。
  6. 可以预期的追问：重试次数怎么定？按单价定。单价越高，允许的重试次数越少，而且高单价的失败更应该先送人复核再决定要不要重做。

  How to reason about it · think before answering

  1. The hinge is 'decide'. Bucketing by the leading digit of the HTTP status is the classic wrong answer, because generation APIs often return HTTP 200 with a business error code in the body.
  2. Give a reusable test instead of reciting a code table: ask three questions — will waiting help, will changing the input help, or does a human have to step in? They map onto three dispositions: back off and retry, fix the request, alert immediately.
  3. Concretely: rate limits and server errors are the first bucket and the program handles them; invalid parameters and content moderation are the second, where retrying repeats the same error and burns rate-limit budget that genuinely retryable tasks needed; auth failure and insufficient balance are the third, where retrying only delays the alert.
  4. Handle timeout separately — this is the line that signals experience. A timeout is unknown, not failed: the job may still be running, or may have finished. So never resubmit blindly; look up the idempotency key for an existing artifact first.
  5. When retries are exhausted, do three things: mark the item failed with the last error code and the exact request parameters, keep processing the rest of the batch instead of aborting it, and aggregate the failures into one readable alert rather than one per item.
  6. Expect the follow-up: how many retries? Scale it by unit price. The more expensive the call, the fewer automatic retries, and expensive failures should go to a human for review before being redone.

  答题要点

  • 不要按状态码首位一刀切，生成类接口的业务错误码常常藏在 HTTP 200 的响应体里
  • 判据是三个问题：等一等会不会好、改输入会不会好、还是必须叫人来，分别对应退避重试、修请求、立刻告警
  • 限流与服务端故障可重试；参数无效与内容审核重试无用且会挤占限流额度；鉴权失败与余额不足必须告警
  • 超时是状态未知不是失败，重试前先按幂等键查一遍已有产物，否则会重复计费
  • 重试用尽后：标记失败并留下错误码与请求参数、不中断整批、把失败汇总成一次可读告警；重试次数按单价定

  Key points

  • Do not bucket by the leading HTTP digit; generation APIs often hide the business error code inside an HTTP 200 body
  • Use three questions — will waiting help, will changing the input help, or is a human required — mapping to back off, fix the request, alert
  • Rate limits and server errors are retryable; invalid parameters and moderation blocks are not and waste rate-limit budget; auth and balance failures need an alert
  • A timeout is unknown rather than failed: check the idempotency key for an existing artifact before resubmitting, or you pay twice
  • When retries run out, mark the item failed with its error code and request parameters, keep the batch running, and aggregate failures into one alert; scale retry counts by unit price

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

• 如果让大模型直接生成 ffmpeg 命令来合成视频，会有什么风险？你会怎么改造这个设计？What are the risks of letting an LLM generate ffmpeg command lines directly, and how would you redesign it?

  国内高频海外高频深入#prompt-injection#pipeline-design#reproducibility

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

  1. 这题考的是「Agent 到底能不能碰真实执行」这条边界，区分度在于你会不会主动说出安全之外的两条。只答「有注入风险」是及格线，答不出可复现与可调试就说明没在生产里跑过生成式流水线。
  2. 推导链很短：模型的输出是不可信输入 → 不可信输入进 shell 就是命令注入 → 而且模型输出天然不确定 → 不确定的命令意味着同样的输入产出不同的文件 → 排查时你还得先猜模型当时为什么那么写。三条风险分别对应安全、可复现、可调试。
  3. 改造的方向不是「加一层校验就放行」，而是把模型挪到另一个位置：让它只输出结构化的选择项，且每一项都从你定死的枚举里选（转场类型、裁切策略、封面取哪一镜），命令本身由你自己的纯函数从时间轴算出来。
  4. 补一句更硬的落地细节：调用外部程序不要走 shell 字符串，用参数数组（execFile 而不是 exec），从根上消掉转义问题；再加一层白名单校验，模型给出枚举外的值就退回默认值而不是报错。
  5. 可预期的追问是「那模型在这一环还有什么用」。答：用在需要审美判断的地方——情绪偏冷还是偏暖、封面选哪一镜、要不要转场。判断交给模型，执行留给程序，这是所有会产生副作用的 Agent 场景的通用分界。

  How to reason about it · think before answering

  1. This probes where you draw the line between model judgment and real execution. Saying 'injection risk' is the passing bar; missing reproducibility and debuggability signals you have not run a generative pipeline in production.
  2. The chain is short: model output is untrusted input, untrusted input into a shell is command injection, model output is also nondeterministic, nondeterministic commands mean the same input yields different files, and debugging then requires guessing what the model was thinking.
  3. The fix is not 'validate and forward'. Move the model: let it emit only structured choices drawn from an enum you fixed in advance (transition type, crop strategy, which shot the cover comes from), and compute the command yourself from the timeline with a pure function.
  4. Add the concrete detail: invoke external binaries with an argument array (execFile, not exec) so escaping stops being a class of bug, then whitelist-validate the model's choices and fall back to a default instead of erroring.
  5. Expect the follow-up 'so what is the model still good for here'. Answer: taste calls — tone, cover selection, whether to use a transition. Judgment to the model, execution to the program. That boundary generalizes to any agent with side effects.

  答题要点

  • 三条风险按严重度排：命令注入、结果不可复现、报错不可调试；只说第一条不够。
  • 改造成参数填充器：模型输出结构化选择项，取值必须落在预定义枚举里。
  • 命令由程序的纯函数从时间轴生成，用参数数组调用而不是拼 shell 字符串。
  • 白名单校验兜底，枚举外的值退回默认，而不是把错误抛给用户。
  • 分界线一句话：模型负责判断，程序负责执行。

  Key points

  • Three risks in order: command injection, non-reproducible output, undebuggable failures. Naming only the first is not enough.
  • Turn the model into a parameter filler: structured choices constrained to a predefined enum.
  • Generate the command from the timeline with a pure function, invoked via an argument array rather than a shell string.
  • Whitelist-validate and fall back to defaults for out-of-enum values instead of surfacing an error.
  • One-line boundary: the model decides, the program executes.

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

• 把多个已经各自跑通的环节串成一条流水线之后，哪些问题是单独调试时看不见的？After chaining several individually working steps into one pipeline, which problems appear that single-step debugging never shows?

  国内高频海外高频深入#integration#pipeline-design#observability

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

  1. 这题考的是系统集成的直觉。回答里如果只有「接口对不上」，说明你只集成过同步的纯函数；生成式流水线的集成问题主要出在状态和产物上，不在接口签名上。
  2. 拆解的角度是：单独调试时，是谁在做衔接？答案是你的脑子。你知道上一个脚本把文件写到哪、知道该拿哪份数据喂下一步。串起来之后这些隐式知识必须搬进代码，而搬漏的地方就是集成问题的来源。
  3. 由此可以推出三类具体问题。第一类是产物路径与命名：单独跑时随手写一个固定输出路径没问题，串起来跑第二遍就把第一遍覆盖了，失败时也分不清哪些文件属于哪一次。解法是每次运行分配一个运行标识，所有产物挂在它下面。
  4. 第二类是中间态：某一步的产物不完整但没报错，下一步照单全收，错误一路往下传，最后在离源头很远的地方炸掉。解法是每一步产出后做完整性校验，比如按数量断言。
  5. 第三类是可观测性：六个环节各打各的日志，几百行滚过去，出了事看不出是哪一环。解法是统一日志规格，终端上只留一张能一眼扫完的进度表，细节压到文件里。
  6. 可预期的追问是「怎么提前发现这些问题」。答：串联之前先约定三件事——产物目录布局、每一步的输入输出契约、日志规格。这三件事定下来，绝大多数集成问题在写代码时就被挡住了。

  How to reason about it · think before answering

  1. This tests integration instinct. If the answer is only 'interfaces do not line up', you have only integrated synchronous pure functions. In generative pipelines the integration problems live in state and artifacts, not in signatures.
  2. The framing question is: during single-step debugging, who does the gluing? Your head does. You know where the last script wrote its files and which blob to feed forward. Chaining forces that implicit knowledge into code, and whatever you fail to move becomes an integration bug.
  3. That yields three concrete classes. First, artifact paths and naming: a fixed output path is fine in isolation, but the second run overwrites the first, and on failure you cannot tell which files belong to which attempt. The fix is a run id that every artifact hangs under.
  4. Second, partial intermediate state: a step produces incomplete output without erroring, the next step accepts it, and the error propagates until it explodes far from its origin. The fix is a completeness assertion after every step, such as an expected artifact count.
  5. Third, observability: six stages each log their own way, hundreds of lines scroll past, and you cannot tell which stage failed. The fix is one log contract — a scannable progress table on the terminal, details pushed to files.
  6. Expect the follow-up 'how do you catch these earlier'. Answer: agree on three things before chaining — the artifact directory layout, each step's input/output contract, and the log format. Fix those and most integration bugs never get written.

  答题要点

  • 单独调试时是人脑在做衔接，串联的本质是把隐式知识搬进代码。
  • 产物路径与命名：每次运行一个运行标识，所有产物挂在它下面，避免覆盖与混淆。
  • 中间态不完整却不报错，错误会传到很远的地方才炸；每一步产出后做完整性校验。
  • 日志淹没：统一日志规格，终端只留进度表，细节压到文件。
  • 预防手段是串联之前先定好目录布局、输入输出契约与日志规格三件事。

  Key points

  • In isolation a human does the gluing; chaining means moving that implicit knowledge into code.
  • Artifact paths and naming: assign a run id and hang every artifact under it to avoid overwrites and confusion.
  • Incomplete intermediate state that does not error propagates far before exploding; assert completeness after every step.
  • Log flooding: adopt one log contract, keep a progress table on the terminal and push details to files.
  • Prevent it by agreeing on directory layout, per-step I/O contracts and log format before chaining anything.

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

• 要支持断点续跑，你需要持久化哪些状态？只存每个节点的完成状态够不够？What state must you persist to support resuming a workflow? Is per-node completion status enough?

  国内高频海外高频深入#workflow-engine#state-persistence#resume

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

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

  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.

  答题要点

  • 只存完成状态不够，还要存指纹和产物位置，分别回答「哪一版」和「还在不在」。
  • 产物按指纹落进内容寻址目录后，「还在不在」退化成一次文件存在性检查。
  • 两层分开：缓存全局共享提供幂等，节点状态每次运行一份提供断点续跑。
  • 状态要在每个节点跑完后立刻落盘，不能等整个流程结束再写。
  • 失败节点的残产物保留，但命中判定必须是全部产物齐全才算数。

  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.

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

• 收到限流响应之后，除了退避重试还该做什么？Beyond backing off and retrying, what else should happen when you get rate limited?

  国内高频海外高频深入#rate-limiting#error-handling#retry

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

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

  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.

  答题要点

  • 把限流当信号：退避的同时给令牌桶降档，接下来的窗口只发一半令牌。
  • 退避期间把任务重新入队并记一个不早于时间戳，工作槽立刻还回去。
  • 退避要带抖动，否则同时被限的任务会同时醒来再撞一次。
  • 严格区分可重试与不可重试：鉴权、余额、参数、内容审核一次都不重试。
  • 把限流次数记成指标，它是回头调闸门参数的唯一依据；退避到上限就转降级而不是继续重试。

  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.

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

• AI 生成的视频对外发布，合规上你必须做哪几件事？Before publishing AI-generated video, what compliance work is mandatory?

  国内高频深入#compliance#labeling#copyright

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

  1. 这题在国内岗位上是硬考点，答不出「显式与隐式两类标识」基本就出局了。它同时也在考你是不是真读过原文，而不是转述别人的解读。
  2. 先给法规坐标：《人工智能生成合成内容标识办法》由四部门联合发布，自 2025 年 9 月 1 日起施行；配套的强制性国标是 GB 45438-2025《网络安全技术 人工智能生成合成内容标识方法》，同日实施。
  3. 然后给两类标识的定义，尽量贴原文：显式标识是在生成合成内容或者交互场景界面中添加的、以文字声音图形等方式呈现并可以被用户明显感知到的标识；隐式标识是采取技术措施在生成合成内容文件数据中添加的、不易被用户明显感知到的标识。**两者都要做，不是二选一**，并且服务提供者应当在文件元数据中添加隐式标识。
  4. 落地上要能说出具体做法：隐式标识写进容器元数据，用 ffmpeg 的 metadata 参数写、用 ffprobe 读回来验证，写了不读等于没写；显式标识最稳是烧进画面，但烧字依赖 ffmpeg 的 drawtext 滤镜，很多最小编译版本没有，所以要先探测能力再降级，并且把降级这件事明确打印出来。
  5. 还要补上标识之外的三条：不得恶意删除篡改伪造隐匿标识；不得生成真实人物形象；背景音乐与参考素材必须有授权来源。做微短剧还要按投资额分级审核，上线前片头标注许可证号或备案号。
  6. 可预期的追问是「元数据具体写哪些字段」。诚实的回答是以 GB 45438-2025 正式文本为准，第三方解读里流传的字段名不能直接照抄——这个回答比编一串字段名得分高得多。

  How to reason about it · think before answering

  1. In China-market roles this is a hard requirement, and missing the explicit-plus-implicit labelling pair usually ends the interview. It also tests whether you read the source text rather than someone's summary.
  2. Give the legal coordinates: the Measures for Labelling AI-Generated Synthetic Content, issued jointly by four authorities, in force from 1 September 2025, with the mandatory national standard GB 45438-2025 on labelling methods taking effect the same day.
  3. Then define both labels close to the source text. An explicit label is added in the content or the interaction interface, presented as text, sound or graphics, and clearly perceivable by the user. An implicit label is added by technical means into the content file data and is not easily perceivable. Both are required, not either-or, and providers are expected to add the implicit label in file metadata.
  4. Show you can ship it: write the implicit label into container metadata with ffmpeg's metadata option and read it back with ffprobe, because writing without verifying is the same as not writing. The explicit label is safest burned into the picture, but burning text needs ffmpeg's drawtext filter, which minimal builds often lack, so detect the capability, degrade deliberately, and log the degradation.
  5. Add the three items beyond labelling: do not maliciously delete, alter, forge or hide labels; do not generate the likeness of real people; and keep licensed sources for background music and reference assets. Short-form drama additionally needs tiered review by budget, with the licence or filing number shown in the opening.
  6. Expected follow-up: which metadata fields exactly. The honest answer is to follow the GB 45438-2025 text itself rather than field names circulating in third-party summaries, and that answer scores far better than inventing a schema.

  答题要点

  • 《人工智能生成合成内容标识办法》2025 年 9 月 1 日起施行，配套强制性国标 GB 45438-2025 同日实施。
  • 显式标识是用户能明显感知到的（文字声音图形），隐式标识加在文件数据里，两者都要做。
  • 服务提供者应当在生成合成内容的文件元数据中添加隐式标识；不得恶意删除篡改伪造隐匿标识。
  • 落地：元数据写入后必须读回验证；显式标识优先烧录，能力不足时降级并明确记录。
  • 另外三条：不得生成真实人物形象、背景音乐与素材要有授权、微短剧按投资额分级审核且片头标注许可证号或备案号。

  Key points

  • The labelling Measures take effect 1 September 2025, alongside mandatory national standard GB 45438-2025.
  • Explicit labels are clearly perceivable by users; implicit labels live in the file data. Both are required.
  • Providers add the implicit label into the content file metadata, and nobody may maliciously delete, alter, forge or hide labels.
  • In practice: verify metadata by reading it back, prefer burned-in explicit labels, and log any capability-driven degradation.
  • Also: no likenesses of real people, licensed music and source assets, and for short-form drama tiered review plus a licence or filing number in the opening.

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

• 给一条会调用付费接口的流水线加预算熔断，你会怎么设计？做到什么程度才算安全停机？How would you design a budget circuit breaker for a pipeline that calls paid APIs, and what makes the stop safe?

  国内高频海外高频深入#budget-control#circuit-breaker

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

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

  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.

  答题要点

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

  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 发行：多平台规格适配、封面与标题生成、批量导出与数据回收

• 内容发布之后的数据要怎么回流到生产流程里？说一条具体可落地的路径。How do you feed post-publication metrics back into the production pipeline? Describe a concrete path.

  国内高频海外高频深入#feedback-loop#analytics

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

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

  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.

  答题要点

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

  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 一季五集：批量产出、作品集包装与短剧生产线面试专题

• 如果让你重做一遍这条生产线，架构上你会怎么改？If you rebuilt this pipeline from scratch, what would you change architecturally?

  国内高频海外高频深入#architecture-review#trade-offs

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

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

  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.

  答题要点

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

  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