逐日AI

面试题库

共 328 题,当前筛选 9 题。

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

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

  • 怎么让一个会调用付费接口的生成节点是幂等的?缓存键里该放什么、不该放什么?How do you make a node that calls a paid generation API idempotent? What belongs in the cache key and what does not?
    国内高频海外高频进阶#idempotency#caching#workflow-engine

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

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

    How to reason about it · think before answering

    1. The discriminator is the second half: what must not go in. People who only say 'hash the inputs' have usually never been burned by a cache. The two failure modes point in opposite directions: never hitting, and hitting when it should not.
    2. State the criterion first: include everything that changes the artifact, exclude everything that changes every run without affecting the artifact. Both lists fall out of that.
    3. Include four things: node id, implementation version, this node's own inputs (model id, prompt, duration, resolution), and the fingerprints of all dependencies. The version and the dependency fingerprints are the two people forget — miss the version and new code reads old artifacts; miss the dependencies and an upstream script change never propagates.
    4. Exclude: run id, timestamps, random values, absolute paths, and anything carrying a hostname or temp directory. Any of those makes every key new, and you will blame the cache instead of the key.
    5. Two implementation details worth volunteering: decide 'is it done' by checking the artifacts on disk, not the state file, because files get deleted by hand; and think about granularity — four shots in one node means one failed shot redoes all four, while finer granularity saves money at the cost of a much larger graph.
    6. Expect the follow-up 'does hashing dependency keys over-invalidate'. Yes. An upstream wording change that produces an identical artifact still invalidates downstream. Hashing the dependency's artifact content instead is tighter but requires reading the artifact every time — worth it for small files, not for large videos.

    答题要点

    • 判据一句话:会改变产物的进键,每次都变但不影响产物的不进键。
    • 必放四样:节点标识、实现版本号、本节点输入、全部依赖的指纹。
    • 禁放:运行标识、时间戳、随机数、绝对路径与机器相关信息。
    • 命中判定看磁盘上产物是否齐全,不能只信状态文件。
    • 幂等粒度要显式选择:节点粒度实现简单,镜头粒度更省钱但图更大。

    Key points

    • One criterion: include what changes the artifact, exclude what changes every run without affecting it.
    • Must include: node id, implementation version, the node's own inputs, and all dependency fingerprints.
    • Must exclude: run id, timestamps, random values, absolute paths and host-specific data.
    • Decide cache hits by checking artifacts on disk, not by trusting the state file.
    • Choose the idempotency granularity explicitly: per node is simpler, per shot saves more but grows the graph.

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

  • 多个任务共用一家厂商的额度,你会怎么设计限流?Many jobs share one vendor's quota. How would you design the rate limiting?
    国内高频海外高频进阶#rate-limiting#concurrency#scheduling

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

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

    How to reason about it · think before answering

    1. The hinge is the word shared. Naming a token bucket only answers half of it; the interviewer wants your bucketing dimension and what else sits around the bucket.
    2. Dimension first: bucket per vendor and per API family, never one global bucket. Image and speech quotas at the same vendor are separate pools, and merging them lets the tight one throttle the loose one.
    3. Then the parts: one bucket is not enough. A token bucket caps rate (calls per minute, a number the vendor sets); a semaphore caps concurrency (how many are in flight, a number you set to protect memory and spend). Rate alone lets a fast endpoint fire hundreds per minute; concurrency alone lets twenty downloads pile up.
    4. The engineering detail that decides everything: admission must be non-blocking. If a job is dispatched first and then waits for a token inside the worker, low-priority work pins every worker slot and priority silently stops working. Ask the gate before dispatch, and skip to the next candidate when it says no.
    5. Finally the numbers: concurrency should not track CPU cores, since this pipeline is almost all network wait. Derive it from vendor quota and from how much work one failure forces you to redo.
    6. Expected follow-up: where does bucket state live. In-memory is fine for one process; across processes it belongs in Redis behind an atomic token-take script, or each process limits itself and the sum still blows the quota.

    答题要点

    • 按「厂商 + 接口类别」分桶,一家的图像和语音各一道闸门。
    • 每道闸门两个部件:令牌桶控速率(厂商给的 RPM),信号量控并发(自己定的在飞上限)。
    • 准入必须非阻塞,拿不到许可就把任务留在队列里,绝不占着工作槽干等。
    • 先抢并发票再取令牌,顺序反了会白白扣掉配额。
    • 多进程部署时桶的状态要外置到 Redis,用原子操作取令牌。

    Key points

    • Bucket per vendor and per API family; image and speech at one vendor get separate gates.
    • Each gate has two parts: a token bucket for rate (the vendor's RPM) and a semaphore for in-flight concurrency (your own number).
    • Admission is non-blocking: if the gate says no, the job stays queued instead of holding a worker slot.
    • Take the concurrency slot before the token, or a rejected admission silently burns quota.
    • Across processes, move bucket state to Redis and take tokens atomically.

D10 审片室:能预览、能改词、能重生成单镜的人机协作后台

  • 用户改了中间一步的输入,怎么算出哪些下游需要重做?A user edits an intermediate input. How do you compute which downstream steps must rerun?
    国内高频海外高频进阶#dag#incremental-recompute#cost

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

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

    How to reason about it · think before answering

    1. The signal lives at the two ends. Most candidates produce the middle part, propagation over a dependency graph, and drop both the direction and the finish.
    2. Direction: propagate forward along who-depends-on-me from the edited node, not backward to its dependencies. Getting it backward is insidious, because upstream nodes rerun, the output is still correct, the bill doubles, and no test catches it.
    3. Implementation: seed a set, sweep the graph repeatedly adding any node with a dependency already in the set until it stops growing, then return in topological order so the caller can just walk the array.
    4. The finish is what people forget: unaffected nodes must have their artifacts copied from the previous version, not regenerated. A perfect radius saves nothing without that copy.
    5. Then verification. Do not compare file hashes, because identical inputs often produce byte-identical output and a matching hash proves nothing. Count API calls instead; that evidence holds both offline and against a real vendor.
    6. Expected follow-up: what about forcing a rerun when nothing changed. Keep an explicit force flag and account for it separately, or you lose the ability to tell system-decided reruns from human-triggered ones.

    答题要点

    • 从被改的节点沿着「谁依赖我」正向传播,不是反向找依赖。
    • 扫图到不动点,结果按拓扑序返回,保证执行顺序不会颠倒。
    • 没受影响的节点要从上一版复制产物,否则半径算得再准也没省钱。
    • 验证要数接口调用次数,不要比文件哈希——同样的输入可能产出逐字节相同的结果。
    • 另留一个强制重跑开关,并与自动判定分开记账。

    Key points

    • Propagate forward along who-depends-on-me from the edited node, never backward.
    • Sweep to a fixed point and return in topological order so execution never runs downstream first.
    • Copy artifacts for unaffected nodes from the previous version, or the computed radius saves nothing.
    • Verify by counting API calls, not by comparing file hashes, since identical inputs can produce byte-identical output.
    • Keep a separate force-rerun switch and account for it apart from automatic decisions.
  • 版本回滚要存什么?只存最终产物够不够?What must a version record hold for rollback? Are the final artifacts enough?
    国内高频海外高频进阶#versioning#rollback#data-modeling

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

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

    How to reason about it · think before answering

    1. The hinge is are they enough, which signals the answer is no. Restate it as a claim: a version is not a backup. Saying that sentence gets you half the credit.
    2. The semantics differ. A backup means restore after an incident and only needs the latest good state. A version means both exist, side by side, switchable, with a human choosing. Review workflows need the latter.
    3. So each version stores three things: the artifacts themselves, kept in per-version directories with nothing deleted; the inputs that produced them, the line and the visual description, or nobody can explain the difference three days later; and which nodes reran plus why.
    4. The current version should be a pointer, not a copy. Rollback moves the pointer without touching files, which makes it instant and reversible, and makes switching forward again equally natural.
    5. Mention the knock-on effect, because it shows you have actually shipped this: rolling back one shot changes the whole episode timeline. If the new take of the voice is a second longer, every later shot shifts, so rollback must recompute the timeline. That part is cheap local computation.
    6. Expected follow-up: how long to keep versions. Scale it by artifact size and business value: keep small text forever, put a retention window on video, and after expiry keep only metadata and inputs so the artifact can be regenerated on demand.

    答题要点

    • 版本不是备份:备份只要最近一份好状态,版本要求新旧同时存在、能并排对比。
    • 每版要存三类:产物(按版本分目录、不删)、产生它的输入、重跑的节点与原因。
    • 当前版本是指针不是拷贝,回滚只挪指针,瞬时且可逆。
    • 回滚一镜会改变整集时间轴,回滚后要重算一次——这是纯本地计算,很便宜。
    • 保留策略按体积分级:文本长期留,大视频设保留期,过期只留元数据与输入以便按需重跑。

    Key points

    • A version is not a backup: backups keep the latest good state, versions keep old and new side by side.
    • Store three things per version: artifacts in per-version directories, the inputs that produced them, and which nodes reran and why.
    • Make the current version a pointer, not a copy, so rollback is instant and reversible.
    • Rolling back one shot shifts the episode timeline, so recompute it after rollback; it is cheap local work.
    • Set retention by size: keep text forever, expire large video and retain metadata plus inputs for regeneration.

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

  • 怎么把画面质量这种主观判断变成可自动判定的检查?How do you turn a subjective judgement like visual quality into an automatable check?
    国内高频海外高频进阶#quality-check#evaluation#multimodal

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

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

    How to reason about it · think before answering

    1. This tests decomposition. Answering just use a multimodal model to score it covers only the lazy half; the interviewer wants to see you turn a non-falsifiable statement into checkable ones.
    2. Step one is classification: split checks into locally measurable and must-be-seen-by-a-model. Resolution, audio-video duration delta, subtitle length and reading rate, and loudness all have deterministic answers from ffprobe plus arithmetic. Character consistency and visual breakdown have no reliable local proxy.
    3. The classification pays off in accounting: a failing objective check means the file really is wrong, while a failing subjective one might just mean the model misread. Merge them into one score and you cannot tell whether to fix the file or the prompt.
    4. Step two gives every check three things: what is measured, the threshold, and the corrective action. The third is the one people skip and the one that matters, because a check that fails without a prescribed fix is decoration.
    5. Step three handles model-side uncertainty: demand a structured verdict, and when it cannot be parsed mark the item as no-conclusion, needs-human, never as a pass. Conflating the model said fine with the model did not answer is the classic automated-QC incident.
    6. Expected follow-up: how to set thresholds. Backtest against human-reviewed samples and pick the threshold where machine and human verdicts agree most. Without that data you are guessing.

    答题要点

    • 先分类:本地量得出来的客观项(分辨率、音画差、字幕密度、响度)与必须看图的主观项(角色一致性、画面崩坏)分开记账。
    • 每一项配齐三样:测量对象、阈值、修正动作;没有修正动作的检查项是摆设。
    • 模型评审要求返回结构化结论,解析失败标成需人工,绝不默认通过。
    • 阈值靠人工审核样本回测确定,不拍脑袋。
    • 客观项失败说明文件有问题,主观项失败可能是模型看错——这个区分决定了排查方向。

    Key points

    • Classify first: objective local measurements (resolution, av delta, subtitle density, loudness) versus model-only judgements (character consistency, visual breakdown).
    • Give every check a measurement, a threshold and a corrective action; a check with no action is decoration.
    • Require a structured verdict from the model, and treat unparseable output as needs-human, never as a pass.
    • Set thresholds by backtesting against human-reviewed samples.
    • An objective failure means the file is wrong; a subjective failure may mean the model misread. That split drives triage.

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

  • 什么情况下该降级而不是重试?如果决定降级,你有哪些维度可以降,怎么排先后?When should you degrade instead of retry, and which dimensions can you degrade first?
    国内高频海外高频进阶#degradation#retry-strategy

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

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

    How to reason about it · think before answering

    1. The pivot is the word instead. This tests whether you separate two failure classes: retry addresses bad luck this time, degradation addresses cannot finish under this configuration. Answering retry three times then degrade misses the point.
    2. Give a reusable rule: retry fixes transient, configuration-independent problems such as rate limits, timeouts and server errors. Degradation fixes persistent, constraint-driven ones such as running out of budget, quota or time. Retrying the second class just burns resources faster.
    3. Name the class most people get wrong: a content-safety block should be neither retried nor degraded, it needs a changed input. Conflating the three is the biggest scoring mistake here.
    4. Order degradation dimensions by how noticeable they are, least to most: resolution, duration, then count of items. Touch the one that changes the content itself only as a last resort.
    5. Add an engineering rule: validate every degradation step against the cost model. If a step saves nothing on your rate card, degrading quality buys you nothing and should be skipped.
    6. Expect the follow-up: when do you decide? Project the cost with a pure function before the run starts and degrade up front. Cutting mid-run leaves a half-finished artifact and wastes everything already spent.

    答题要点

    • 重试针对瞬时且与配置无关的失败,降级针对持续且由约束导致的不可完成
    • 内容安全拦截是第三类:既不重试也不降级,要改输入
    • 降级维度按察觉难度排:清晰度、时长、数量,最后才动内容本身
    • 每一步降级都要拿成本模型验证,省不出钱的那一步直接跳过
    • 降级要在开跑前决定,跑到一半再砍会留下半成品且前面的钱白花

    Key points

    • Retry transient configuration-independent failures; degrade when the constraint makes completion impossible
    • Content-safety blocks are a third class: change the input rather than retrying or degrading
    • Order degradation by noticeability: resolution, duration, item count, content last
    • Validate each degradation step against the rate card and skip steps that save nothing
    • Decide before the run starts; cutting mid-run leaves a half-finished artifact and wastes prior spend

D13 发行:多平台规格适配、封面与标题生成、批量导出与数据回收

  • 同一条视频要发多个平台,每个平台规格不同,你会怎么设计导出流程才能少转码?The same video has to be published to several platforms with different specs. How do you design the export flow to minimize transcoding?
    国内高频海外高频进阶#media-pipeline#ffmpeg

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

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

    How to reason about it · think before answering

    1. This question tests whether you distinguish transcoding from remuxing. Rendering once per platform is not a coding failure, it is a failure to notice that every lossy re-encode costs quality.
    2. Separate the two: transcoding decodes and re-encodes, so the picture data is genuinely recompressed; remuxing just moves an already-encoded bitstream into another container without touching a byte. One takes seconds and loses quality, the other takes milliseconds and is lossless.
    3. Then give the flow: render one master using the most conservative parameters that satisfy every target, then run each platform through a decision function and stream-copy whenever possible. Container changes, faststart and duration trims all stay within stream copy.
    4. Know the cases that truly require re-encoding: out-of-range resolution, an unaccepted codec, a frame rate outside the allowed band, and a file that exceeds the size cap. Duration is the one people misjudge most, since -t with stream copy already trims it.
    5. Add an engineering rule: the decision function should return a list of reasons, not just a boolean. When someone asks why a platform got re-encoded, you answer from the log rather than rereading the code.
    6. Expect the follow-up: how do you prove it? Print an encode counter alongside the count the naive approach would have produced. A number without a baseline convinces nobody.

    答题要点

    • 分清转码与封装:换容器、加 faststart、按时长截断都可以流复制
    • 一次渲染母版,参数取所有目标平台约束的最保守交集
    • 只有分辨率越界、编码不被接受、帧率超范围、体积超限才必须重编码
    • 判定函数返回理由列表,让每次重编码都能被解释
    • 打印编码次数计数器并与朴素做法做对照,才算证明少转了码

    Key points

    • Separate transcode from remux: container swaps, faststart and duration trims are all stream copies
    • Render one master using the most conservative intersection of all target constraints
    • Re-encode only for out-of-range resolution, unaccepted codec, out-of-band frame rate, or oversize files
    • Have the decision function return reasons so every re-encode can be explained
    • Print an encode counter next to the naive baseline to prove the saving
  • 让模型生成标题、封面文案这类创意内容,怎么保证质量下限?When a model generates creative content such as titles and cover copy, how do you guarantee a quality floor?
    国内高频海外高频进阶#llm-output-quality#candidate-selection

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

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

    How to reason about it · think before answering

    1. The pivot is the word floor. The question is not how to make output better but how to keep it from being bad, and those two goals need different techniques.
    2. Start from one criterion: is this stage expensive? Expensive slow stages such as video generation must get it right once by constraining the input. Cheap fast stages such as copywriting should generate several variants and converge. A three-order-of-magnitude price gap justifies opposite strategies.
    3. So the shape is: generate one candidate per preset angle, then converge with a deterministic scoring function. The floor comes from the scorer, not from the model, because model variance is the normal case and the scorer has none.
    4. Three requirements for the scorer: emit a reason per rule, since an unexplained score cannot be iterated on; penalize banned wording heavily rather than filtering it, because filtering can leave you with nothing; and always define a tie-breaker, or two runs pick different winners and you will blame the model and start tuning temperature.
    5. Add a structural guard: model output may be too long, prefixed with explanation, or carry debug markers. Validate the shape and fall back to a local template when it fails. That layer handles uncontrollable structure, which is a different problem from uncontrollable quality.
    6. Expect the follow-up: why not let the model score itself? Because it is unstable and unexplainable. The same batch can be ranked differently twice, and you cannot justify the choice to anyone. Model judgement can be one input to the scorer, never the only judge.

    答题要点

    • 按环节的价格选策略:贵的一次做对靠约束输入,便宜的多做几版靠收敛输出
    • 形态是按预设角度批量出候选,再用确定性打分函数挑前几名
    • 打分函数必须输出理由、对违规词扣重分而非过滤、同分给决胜键
    • 另加一道结构兜底:格式不合格就回落本地模板,与质量打分是两件事
    • 不让模型给自己评分,它不稳定也不可解释,最多作为打分的一项输入

    Key points

    • Pick the strategy by stage cost: constrain input when expensive, converge output when cheap
    • Generate one candidate per preset angle, then rank with a deterministic scoring function
    • The scorer must emit reasons, penalize banned wording instead of filtering, and define a tie-breaker
    • Add a separate structural fallback for malformed output, distinct from quality scoring
    • Do not let the model judge itself; use it at most as one signal inside the scorer

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

  • 多集连续生成时,人物与画风的跨集一致性你是怎么保证的?如果要做一百集会遇到什么新问题?How do you keep characters and visual style consistent across many generated episodes, and what breaks at a hundred episodes?
    国内高频海外高频进阶#consistency#prompt-assembly

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

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

    How to reason about it · think before answering

    1. The discriminator is whether you rely on discipline or on structure. Writing the prompt the same way every time drifts by episode five, because every copy is another chance for a human edit.
    2. The right shape makes inconsistency structurally impossible: keep one archive (character cards with appearance and voice id, style tokens, scene list) and enforce one rule, that every shot's prompt is assembled from the archive plus that shot's description, never hand-written.
    3. Then turn the rule into decidable checks: are all characters in the archive, did any voice id change across episodes, is the appearance fragment verbatim from the archive, does every shot carry the style tokens, and does each episode's hook match the next one's pick-up. These five inspect inputs only; picture quality belongs to the automated review pass, and the two are complementary.
    4. At a hundred episodes three new problems appear. First the archive itself evolves as characters restyle and new ones appear, so it needs versions and each episode must record which version it used, or you cannot explain why episode thirty differs from episode ten.
    5. Second, the hook chain gets long and manual maintenance fails, so hook validation has to be a hard gate before the run starts. Third, the asset library bloats, so reference sheets need an index and deduplication or one character accumulates dozens of contradictory base images.
    6. Expect the follow-up: does consistency fight variety? Separate the layers. The archive locks identity traits such as appearance, voice and style, while randomness lives in camera movement, framing and lighting. Locking the wrong layer gives you a hundred identical episodes.

    答题要点

    • 靠结构不靠自律:唯一档案加一条硬规矩,提示词只能从档案拼出来
    • 五条只看输入的可判定检查:角色、音色、外貌逐字、风格词、集间钩子
    • 输入检查与机器审片互补,一个查有没有漂,一个查画面好不好
    • 上百集会新增三类问题:档案要版本化、钩子校验要变成硬闸门、资产库要索引去重
    • 档案锁身份特征,随机性留给运镜构图光线,锁错层会一百集雷同

    Key points

    • Rely on structure: one archive plus a rule that prompts may only be assembled from it
    • Five decidable input-only checks: cast membership, voice stability, verbatim appearance, style tokens, hook chain
    • Input checks complement automated picture review; neither replaces the other
    • At scale add archive versioning, a hard pre-run hook gate, and an indexed deduplicated asset library
    • Lock identity traits in the archive and leave randomness to camera, framing and lighting