面试题库

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

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