面试题库
共 328 题,当前筛选 4 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#consistency4#evaluation30#cost29#reliability24#architecture22#agent-skills21#security18#observability15#streaming12#error-handling11#idempotency10#system-design10
还有 362 个标签收起标签
#api-design9#coding-agent9#distributed-systems8#multi-agent8#rag8#chunking7#debugging7#pipeline-design7#structured-output7#agent-loop6#mcp6#operations6#prompt-injection6#sse6#tool-calling6#tool-design6#context5#context-engineering5#deployment5#embeddings5#hybrid-search5#message-bus5#scheduling5#system-prompt5#agentic-rag4#behavioral4#client4#concurrency4#framework-design4#ingestion4#prompt-engineering4#rate-limiting4#retrieval4#routing4#trade-offs4#abstention3#agents-sdk3#caching3#communication3#context-window3#cost-control3#data-quality3#failure-modes3#image-generation3#interview-prep3#langgraph3#latency3#llm-as-judge3#llm-basics3#long-context3#model-migration3#model-routing3#orchestration3#ordering3#progressive-disclosure3#prompt-basics3#prompt-caching3#protocol3#provider-abstraction3#ranking3#recall3#redis-streams3#responses-api3#resume3#retry3#runtime3#scalability3#skills3#state-management3#statelessness3#subagents3#timeline3#versioning3#workflow-engine3#access-control2#agent-design2#async-task2#auth2#checkpointing2#citation-verification2#citations2#claude-md2#code-review2#compaction2#context-rot2#contextual-retrieval2#cost-tradeoff2#data-modeling2#database2#distribution2#fallback2#ffmpeg2#golden-set2#grounding2#interview-process2#long-term-memory2#media-pipeline2#memory2#multi-hop2#multi-tenancy2#oauth2#prioritization2#project-storytelling2#prompt-techniques2#query-rewriting2#react2#refusal2#reproducibility2#rerank2#retrieval-quality2#retrospective2#scripts2#sharding2#state-machine2#tool-permissions2#tooling2#tools2#tracing2#transport2#tts2#ux2#vector-database2#verification2#workflow2#agent-basics1#agent-quality1#agent-sdk1#agents-md1#altitude1#analytics1#approvals1#architecture-review1#async1#atomicity1#attention-budget1#av-sync1#backoff1#bi-encoder1#bm251#budget-control1#build-vs-buy1#cancellation1#candidate-selection1#capacity-planning1#career1#chain-of-thought1#ci1#circuit-breaker1#claude-code1#cli-design1#client-integration1#cloud1#compliance1#compression1#configuration1#confused-deputy1#consistent-hashing1#content-hash1#content-safety1#context-assembly1#context-compression1#context-management1#copyright1#coreference1#correctness1#cost-accounting1#cost-analysis1#cost-optimization1#cross-encoder1#cross-model1#customer-support1#dag1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#docker1#documentation1#embedding-migration1#encoding1#engineering-judgement1#engineering-tradeoffs1#error-propagation1#escalation1#eval1#event-driven1#evidence1#failure-analysis1#fairness1#faithfulness1#fan-out1#feedback-loop1#fencing-token1#few-shot1#filter-pushdown1#filtering1#fine-tuning1#forking1#four-elements1#framework-selection1#frontend1#global-market1#graph-rag1#guardrails1#hallucination1#handoff1#handoffs1#headless1#hnsw1#hooks1#human-in-the-loop1#hybrid1#hyde1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#integration1#intent-routing1#interrupt-merge1#invalidation1#isolation1#iterative-scan1#ivfflat1#json-parsing1#json-schema1#just-in-time1#jwt1#knowledge-organization1#labeling1#latency-budget1#lease1#least-privilege1#llm-output-quality1#long-session1#loop-guard1#maintenance1#mcp-basics1#mental-model1#messages-api1#metadata1#methodology1#metrics1#migration1#mobile1#model-selection1#moderation1#modularity1#multi-turn1#multimodal1#nodejs1#normalisation1#notifications1#ocr1#offline-testing1#openai1#overlap1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#primitives1#priority-queue1#proactive-messaging1#product-engineering1#production-readiness1#prompt1#prompt-assembly1#prompt-bloat1#prompt-design1#prompt-limits1#prompt-surface1#prompt-template1#prompt-versioning1#prompting1#protocol-versions1#quality1#quality-check1#quantization1#query-transformation1#quiet-hours1#rag-basics1#rank-fusion1#reasoning1#reconnect1#redis1#reflection1#replay1#reporting1#retrieval-failure1#retrieval-metrics1#retry-semantics1#retry-strategy1#review1#risk-assessment1#rollback1#rollout1#rrf1#safety1#sampling1#sandbox1#sandboxing1#scaling1#schema-design1#schema-validation1#scoping1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#self-reflection1#server-design1#service-architecture1#session-management1#sessions1#similarity1#skill-authoring1#skill-description1#skill-design1#spec1#split-brain1#stakeholder-communication1#star1#state-persistence1#stateless1#stdio-transport1#stopping-criteria1#storytelling1#subagent1#subscriptions1#subtitles1#task-graph1#team-governance1#test-set1#test-strategy1#testing1#thresholds1#timezone1#token-accounting1#token-budget1#tool-budget1#tool-execution1#tool-naming1#tool-schema1#trust-boundary1#tuning1#validation1#vector-index1#workflow-design1#xml-tags1#zero-downtime1
14 天用 Agent 搭一条 AI 短剧生产线
D2 剧本 Agent:把一句话变成人物卡、场景与分镜的结构化数据
多集内容要保持人物设定一致,你会把这份设定放在哪、怎么用?To keep character definitions consistent across many episodes, where do you store that state and how do you use it?
国内高频海外高频进阶#state-management#consistency分析过程 · 先想清楚再作答
- 这题的题眼是「模型没有记忆」。答成「把前一集的输出拼进上下文」的人会被追问到崩——上下文会随集数线性膨胀,第五集时你在为前四集的全文反复付费,而且模型仍然可能漏读。
- 怎么拆:先分辨哪些是「跨集不变」的,哪些是「每集重算」的。不变的是世界观、人物外貌、性格、音色与几条硬规则;每集重算的是场景与分镜。把不变的那部分抽成单独的档案文件,每一集生成前原样读进去。
- 接着说一个容易被忽略的点:档案里的字段不只是设定,还是**下游的输入参数**。外貌描述要原样进图像提示词,音色 id 要原样进语音接口。所以它们必须和名字放在同一份档案里,一致性问题才是在一个文件里解决的,而不是散在三处各写一遍。
- 存放位置的判据是写入频率:档案一次生成、多次读取,分镜每跑一次就重写。生命周期不同的数据放同一个文件,你就没法只重跑一集而不动其他集。按写入频率切分文件,是这类流水线最省事的一条习惯。
- 结论与代价:档案本身也会漂——中途改了人物外貌,之前生成的资产就对不上了。所以档案要有版本,且资产的缓存键要包含档案版本,改档案等于让相关资产失效。这条也是把它单独存放才做得到的。
- 可预期的追问:那要不要上向量库做检索?多数情况下不需要。跨集共享的设定是**有限的、结构化的、必须全量注入的**,检索反而可能漏掉关键一条。检索适合的是「素材库很大且只需要相关几条」的场景。
How to reason about it · think before answering
- The crux is that models have no memory. Answering just concatenate previous episodes into the context invites a fatal follow-up: context grows linearly with episode count, so by episode five you pay repeatedly for four full episodes, and the model may still miss details.
- Break it down by separating what is invariant across episodes from what is recomputed each time. Invariant: the world, each character's appearance, personality, voice id, and a few hard rules. Recomputed: scenes and shots. Extract the invariant part into its own file and load it verbatim before generating each episode.
- Add the commonly missed point: the fields in that file are not only lore, they are downstream input parameters. Appearance text goes straight into image prompts, the voice id goes straight into the speech API. Keeping them beside the name means consistency is solved in one file rather than restated in three places.
- Choose the storage boundary by write frequency: the profile is written once and read many times, while the shot list is rewritten on every run. Mixing lifetimes in one file makes it impossible to rerun one episode without disturbing the others.
- Conclusion and cost: the profile itself can drift. Change a character's appearance mid-season and previously generated assets no longer match, so version the profile and include that version in the asset cache key — editing the profile then invalidates exactly the affected assets. That is only possible because it lives on its own.
- Likely follow-up: should you use a vector store? Usually not. Cross-episode canon is small, structured, and must be injected in full; retrieval risks dropping the one line that matters. Retrieval fits large corpora where only a few relevant items are needed.
答题要点
- 模型没有记忆,跨集一致性靠外部档案而不是把前几集拼进上下文
- 按「跨集不变」与「每集重算」切分:世界观与人物卡是档案,场景与分镜每集重来
- 档案里的外貌与音色 id 同时是下游的输入参数,所以必须和名字放在一起
- 按写入频率切分文件,档案读多写少,分镜每次重写,混在一起就没法只重跑一集
- 档案要有版本并进资产缓存键,改设定才能精确地让相关资产失效
Key points
- Models are stateless; cross-episode consistency comes from an external profile, not from stuffing prior episodes into context
- Split by invariant versus recomputed: world and character profiles persist, scenes and shots are regenerated per episode
- Appearance text and voice id are downstream input parameters, so they belong beside the character's name
- Split files by write frequency — a read-mostly profile versus a rewritten shot list — or you cannot rerun one episode alone
- Version the profile and fold that version into the asset cache key so edits invalidate exactly the affected assets
D3 角色一致性:定妆图、参考图与风格锁定,让同一个人每一镜都还是他
生成模型的角色一致性问题是怎么来的?工程上有哪几种缓解手段,代价分别是什么?Where does the character consistency problem in image generation come from, and what engineering mitigations exist, with what trade-offs?
国内高频海外高频基础#image-generation#consistency分析过程 · 先想清楚再作答
- 这题的区分度在第一句。答「提示词写得不够细」就掉到了使用者视角;面试官想听的是「模型每次请求都是独立采样、没有跨请求记忆」这个机制层面的原因。
- 顺着机制往下推就有了完整答案:提示词只约束了你写出来的那些自由度,没写的部分每次重新掷一遍;而人脸的辨识度恰好集中在脸型、眼距、鼻梁这些你没法用文字穷尽的细节上。
- 手段按「锁得住什么」分三层说,不要混在一起:提示词模板锁风格与构图,成本几乎为零;随机种子锁同一提示词的可复现性,换提示词即失效;参考图锁人脸,但每次请求只能带一张,双人同框锁不了两个人。
- 代价这一段才是拉开差距的地方:参考图要求你先有一张基准图,于是流程里必须插入一次「定妆并由人挑一张」的环节,这是整条自动化流水线上少数值得保留的人工卡点。
- 还要主动说一个反直觉的做法:派生图必须都参考同一张基准图,不能参考上一张。参考上一张会让偏差逐张累积,第五张已经不是同一个人了。
- 可以预期的追问:一致性做不到怎么兜底?答案是改镜头语言——把双人同框拆成正反打的单人镜头、次要角色用更远的景别,用拍法回避接口能力的边界。
How to reason about it · think before answering
- The differentiator is your first sentence. Saying 'the prompt wasn't detailed enough' reads as a user, not an engineer; the answer they want is that each request is an independent sample with no memory across calls.
- Follow the mechanism: a prompt only constrains the degrees of freedom you actually wrote down, and everything unwritten gets re-sampled — while face recognizability lives exactly in the details text cannot exhaust.
- Present the mitigations in three layers by what each one actually locks: a prompt template locks style and framing at near-zero cost; a fixed seed locks reproducibility for one identical prompt and stops helping the moment the prompt changes; a reference image locks the face, but only one per request, so two faces in one frame cannot both be locked.
- The trade-off discussion is where candidates separate: using a reference image means you must first produce a base image, which forces a human 'pick the reference sheet' step into an otherwise unattended pipeline.
- Volunteer the counter-intuitive rule: every derived image must reference the same base image, never the previous one. Chaining references accumulates drift, and by the fifth image it is a different person.
- Expect the follow-up: what if consistency still fails? The answer is cinematography — split two-character frames into reverse-angle singles and push secondary characters to wider shots, working around the API's limits with shot design.
答题要点
- 根因是模型每次请求独立采样、没有跨请求记忆,提示词没约束到的自由度会被重新掷一遍
- 提示词模板锁风格与构图,成本几乎为零,但锁不住五官
- 随机种子锁的是同一提示词的可复现性,提示词一变就失效
- 参考图锁人脸,代价是必须先有基准图,且每次请求只能带一张,双人同框锁不了两个人
- 派生图统一参考同一张基准图,不要链式参考上一张,否则偏差会逐张累积
Key points
- The root cause is that each request is an independent sample with no cross-request memory, so unconstrained degrees of freedom get re-rolled
- A prompt template locks style and framing at near-zero cost but cannot lock facial detail
- A fixed seed locks reproducibility for one identical prompt and stops helping once the prompt changes
- A reference image locks the face, but you must first produce a base image and only one reference is allowed per request
- Derive every variant from the same base image rather than chaining off the previous one, or drift accumulates image by image
D5 配音、字幕与音轨:多角色语音、时间轴对齐与字幕文件
多角色配音里,怎么保证同一个角色跨集用的是同一个声音?In a multi-character pipeline, how do you guarantee the same character keeps the same voice across episodes?
国内高频海外高频基础#tts#consistency#provider-abstraction分析过程 · 先想清楚再作答
- 这题看着像配音问题,其实考的是状态该存在哪里。答「配置里写死」不算错,但只答到这一层看不出工程判断。
- 先说清楚风险来自哪:声音是角色身份的一部分,观众对它的敏感度不低于脸。跨集不一致的典型成因有三个——每集独立跑一次流程、音色靠临时映射或随机挑选、以及某次为了改一句台词的语气顺手改了这个角色的全局参数。
- 解法是把音色归档而不是归代码:角色档案里带一个音色字段,配音环节只读不写。这样一致性由档案保证,跟哪一集、哪一次运行、谁跑的都无关。这跟角色形象靠基准图归档是同一套思路。
- 但只存音色标识还不够,跨集听感一致还依赖另外两项:基调情绪与语速。同一个音色用两种语速念,听起来像两个人的状态。所以档案里要一起存这三项,单条台词只允许覆盖情绪,不允许覆盖语速。
- 再补一层防御:把音色标识连同模型名一起记进产物元数据。厂商下线或重命名一个音色是会发生的,你要能查出「第二季为什么听起来不一样」,而不是只能凭记忆猜。
- 可以预期的追问:如果厂商真的下线了那个音色怎么办?答案是把音色选择也做成 provider 抽象的一部分:档案里存的是角色的音色角色定位,映射到具体厂商音色的表放在适配层,换厂商或补映射时不动档案。
How to reason about it · think before answering
- This looks like a voice question but is really about where state lives. 'Hardcode it in config' is not wrong, but stopping there shows no engineering judgment.
- Name the risk first: voice is part of a character's identity, and audiences are about as sensitive to it as to a face. Inconsistency across episodes has three usual causes — running each episode as an independent pipeline, picking voices from an ad-hoc or random mapping, and someone tweaking a character's global parameters while fixing the delivery of one line.
- The fix is to file the voice in the character record rather than in code: the record carries a voice id, and the dubbing step only reads it. Consistency then holds regardless of episode, run or operator — the same pattern as pinning appearance to a base reference image.
- Storing the voice id alone is not enough. Perceived sameness also depends on the baseline emotion and the speaking rate; the same voice at two different rates sounds like a different state of a person. Keep all three in the record, and allow per-line overrides of emotion only, never of rate.
- Add a defensive layer: record the voice id together with the model name in the artifact metadata. Vendors do retire and rename voices, and you want to be able to answer 'why does season two sound different' from data rather than memory.
- Expect the follow-up: what if the vendor retires that voice? Make voice selection part of the provider abstraction — the record stores the character's voice archetype, and the mapping to a concrete vendor voice lives in the adapter, so swapping vendors never touches the character records.
答题要点
- 把音色存进角色档案,配音环节只读不写,一致性与集数、运行次数、操作人无关
- 档案里要同时存音色标识、基调情绪与语速;单条台词只允许覆盖情绪,不允许覆盖语速
- 把音色标识与模型名一起写进产物元数据,便于回答「为什么这一季听起来不一样」
- 跨集不一致的典型成因是每集独立跑、临时映射、以及改一句台词时顺手改了全局参数
- 音色选择应纳入 provider 抽象:档案存角色的音色定位,具体厂商音色的映射放在适配层
Key points
- Store the voice in the character record and have the dubbing step read it only, so consistency is independent of episode, run or operator
- Keep voice id, baseline emotion and speaking rate together; allow per-line emotion overrides but never rate overrides
- Write the voice id and model name into artifact metadata so you can explain why a later season sounds different
- Typical causes of drift are per-episode independent runs, ad-hoc mappings, and global tweaks made while fixing one line
- Fold voice selection into the provider abstraction: records hold the archetype, the adapter maps it to a concrete vendor voice
D14 一季五集:批量产出、作品集包装与短剧生产线面试专题
多集连续生成时,人物与画风的跨集一致性你是怎么保证的?如果要做一百集会遇到什么新问题?How do you keep characters and visual style consistent across many generated episodes, and what breaks at a hundred episodes?
国内高频海外高频进阶#consistency#prompt-assembly分析过程 · 先想清楚再作答
- 这题的区分度在于你是靠自律还是靠结构。答「每次都把提示词写得一样」的人做到第五集就会漂,因为每复制一次提示词就多一次人为改动的机会。
- 正确形态是把一致性变成结构上做不到不一致:建一份唯一的档案(人物卡含外貌与音色、风格词、场景表),再立一条硬规矩——每一镜的提示词只能由「档案加本镜描述」拼出来,不允许手写。
- 然后把这条规矩做成可判定的检查:角色是不是都在档案里、音色跨集有没有变、外貌片段是不是逐字来自档案、风格词每一镜有没有带上、集间钩子有没有首尾相接。注意这五条只看输入不看画面——画面质量是机器审片的职责,两道检查互补,谁也替代不了谁。
- 一百集会冒出三类新问题。第一是档案本身会演化:人物换了造型、加了新角色,需要给档案做版本,并记录每一集用的是哪个版本,否则回头没法解释第三十集为什么和第十集不一样。
- 第二是钩子链变长之后容易断,人工维护五条还行、维护九十九条一定出错,得让钩子校验成为开跑前的硬闸门。第三是资产库膨胀,定妆图与参考图要有索引与去重,否则同一个角色会攒出几十张互相矛盾的基准图。
- 可预期的追问是「一致性和多样性冲突吗」。答案是把两者分开:档案锁死的是身份特征(外貌、音色、风格),随机性留给运镜、构图与光线——锁错层就会得到一百集一模一样的片子。
How to reason about it · think before answering
- 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.
- 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.
- 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.
- 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.
- 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.
- 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