面试题库

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

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.