面试题库

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

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

• 把一条多步生成流程建成任务图，比一串顺序 await 多拿到了什么？代价是什么？What does modeling a multi-step generation pipeline as a task graph buy you over a chain of sequential awaits, and what does it cost?

  国内高频海外高频进阶#task-graph#pipeline-design

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

  1. 这题的题眼在「多拿到了什么」，不在「什么是 DAG」。背出有向无环图定义的人拿不到分，答对的人会给出三样顺序版拿不到的能力，并各配一个具体场景。
  2. 怎么拆：把顺序版的三个痛点倒过来说。第一，并行的可能性被图结构直接表达——配音只依赖台词、和画面无关，顺序版里它却要排在四十次视频生成后面。第二，有断点——每个节点的产物落在磁盘固定位置，第三十七个镜头失败时前三十六个还在。第三，可观测——你能回答「现在卡在哪个节点」，顺序版只能回答「卡在某个 await」。
  3. 补一条区分度更高的：环检测。拓扑排序在发现依赖成环时抛错，这是「无环」两个字唯一的执行者；没有它，依赖写错只会表现成漏跑一步或者顺序错乱，非常难查。
  4. 结论与代价：任务图不是免费的，你必须为每个节点定义清楚输入产物与输出产物，否则它只是一张漂亮的依赖声明。这份产物契约同时也是后面做幂等与断点续跑的前提。
  5. 可预期的追问：那是不是应该直接上工作流引擎？判据是节点数与失败率——十几个节点、失败率高、需要人工介入时才值得；三五个节点的流程用一张手写的图加拓扑排序就够，引入引擎反而多一套要运维的东西。

  How to reason about it · think before answering

  1. The question is what you gain, not what a DAG is. Reciting the definition scores nothing; name three capabilities the sequential version cannot have, each with a concrete scenario.
  2. Break it down by inverting the three pains of sequential code. First, parallelism is expressed by the graph itself — voice-over depends only on the lines, yet a sequential run queues it behind forty video jobs. Second, resumability — each node writes artifacts to a fixed path, so shot 37 failing does not destroy the first 36. Third, observability — you can say which node is stuck, not merely that some await is pending.
  3. Add the higher-signal point: cycle detection. Topological sort throws when dependencies form a cycle, and that is the only thing enforcing the acyclic part. Without it, a wrong dependency silently skips a step or reorders execution, which is painful to debug.
  4. Conclusion and cost: a task graph is not free. Every node needs a declared input and output artifact set, otherwise the graph is decorative. That artifact contract is also the precondition for idempotency and resume later on.
  5. Likely follow-up: should you adopt a workflow engine instead? Judge by node count and failure rate — worth it at a dozen-plus nodes with high failure and human review; for three to five nodes a hand-written graph plus topological sort is cheaper than another system to operate.

  答题要点

  • 三样顺序版拿不到的：并行由图结构表达、失败后有断点、能说清卡在哪个节点
  • 拓扑排序顺带做环检测，这是「有向无环」里「无环」的唯一执行者
  • 代价是必须为每个节点声明输入产物与输出产物，否则图只是装饰
  • 这份产物契约同时是后续做幂等与断点续跑的前提
  • 上不上工作流引擎按节点数与失败率判断，三五个节点手写图更划算

  Key points

  • Three things sequential code cannot give: parallelism expressed by structure, resumability after failure, and knowing which node is stuck
  • Topological sort also detects cycles, the only mechanism enforcing the acyclic property
  • The cost is declaring input and output artifacts per node; without that the graph is decorative
  • That artifact contract is the precondition for idempotency and resume
  • Adopt a workflow engine based on node count and failure rate; a hand-written graph wins for three to five nodes

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

• 语音时长和画面时长对不上，你会调哪一边？为什么？When the synthesized speech and the shot duration disagree, which side do you adjust, and why?

  国内高频海外高频进阶#timeline#tts#pipeline-design

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

  1. 这题只答「调画面」拿不到分，题眼在「为什么」——面试官要的是让步理由，以及你有没有意识到这个选择会决定整条流水线的排列顺序。
  2. 先给判断依据：哪一边的失真观众察觉得到。台词被切掉、或者被加速到语气变形，观众立刻听得出来；一镜比原计划长零点八秒，观众感觉不到。所以让步的是画面。
  3. 由这条判断反推流水线顺序：画面先按计划时长生成，语音合成完之后由真实时长回写镜头时长，剪辑台再去补足画面。为什么不倒过来先合成语音再按语音时长生成视频？因为视频接口的时长是有限档位的，你没法要求它精确生成 6.34 秒。
  4. 补一条不能省的工程细节：写进时间轴的必须是从落盘文件量出来的真实时长，不能是字数估算。估算误差是逐句累加的，第一句差两百毫秒，第十句就差两秒，成片上表现为字幕跟画面赛跑。
  5. 再说例外，这是加分项：如果这一镜的画面本身有强节奏（比如卡点、转场、动作衔接），画面就不能被随意拉长，这时候要回头改剧本把台词写短，而不是硬拉画面。所以被顶长的镜头应该被标记出来交给人复核，而不是程序默默改掉。
  6. 可以预期的追问：那不能微调语速吗？可以，但语速是有代价的——语速改变会同时改变音质与情绪表现，而且它会反过来再改一次时长，等于把一个单向流程变成了循环。留一点余量的做法是给留白参数一个可调区间，先动留白再动语速。

  How to reason about it · think before answering

  1. Answering 'stretch the shot' alone scores nothing; the hinge is 'why'. They want the reasoning for which side yields, and whether you see that this choice fixes the order of the whole pipeline.
  2. State the criterion: which distortion does the audience notice? Clipped or sped-up dialogue is audible immediately; a shot running 0.8 seconds long is not. So the picture yields.
  3. Derive the pipeline order from that: generate video at the planned duration, synthesize speech, write the measured duration back onto the shot, and let the editor pad the picture. Why not synthesize first and generate video to fit? Because video APIs expose discrete duration options — you cannot ask for exactly 6.34 seconds.
  4. Add the engineering detail that cannot be skipped: the timeline must use durations measured from the rendered files, never character-count estimates. Estimation error accumulates line by line, and by the tenth line the subtitles visibly race the picture.
  5. Then the exception, which earns points: if a shot has intrinsic rhythm — a beat cut, a transition, an action match — the picture cannot simply be stretched, and the right fix is a shorter line in the script. That is why stretched shots should be flagged for human review rather than silently rewritten.
  6. Expect the follow-up: can't you just nudge the speaking rate? You can, but it costs you — rate changes affect timbre and delivery, and they change duration again, turning a one-way flow into a loop. Make the lead-in and tail padding adjustable and spend that budget before touching the rate.

  答题要点

  • 调画面：台词被切或被加速观众立刻察觉，镜头长零点几秒观众感觉不到
  • 由此定下流水线顺序：画面按计划时长生成，语音合成后回写真实时长，剪辑台补足画面
  • 不能倒过来按语音时长生成视频，因为视频接口的时长只有有限档位
  • 时间轴必须用落盘文件量出的真实时长，字数估算的误差会逐句累加
  • 画面有强节奏的镜头是例外，这类冲突应标记出来交人复核而不是程序默默改掉

  Key points

  • Stretch the picture: clipped or sped-up dialogue is instantly audible, while a fraction of a second of extra shot length is not
  • That fixes the pipeline order: generate video at planned duration, synthesize speech, write measured duration back, pad in the edit
  • You cannot invert it and generate video to match speech, because video APIs only expose discrete durations
  • The timeline must use durations measured from rendered files; character-count estimates accumulate error line by line
  • Shots with intrinsic rhythm are the exception, so flag stretched shots for human review instead of silently rewriting them

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 一集杀青：把六个环节串成端到端流水线并算清第一笔账

• 怎么度量一条生成流水线的成本？除了钱还要量什么？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.
• 把多个已经各自跑通的环节串成一条流水线之后，哪些问题是单独调试时看不见的？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.

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.