What exactly is being engineered in prompt engineering, and how does it differ from writing a requirements doc or a design spec?

The model completes text rather than executing commands; a prompt is context, and specificity narrows the plausible continuations What gets engineered is the missing information: perspective, completion criteria, output shape, boundaries with reasons Unlike a spec, the reader shares no background and never asks back, so completeness and explicit done-criteria matter more Engineering implies testable, versioned, comparable artifacts, not one-off clever phrasing

What problem does each of the four prompt elements — role, task, format, constraints — solve? If you could keep only three, which would you drop and why?

Role sets perspective; task sets the goal and done-criteria; format makes output mechanically checkable; constraints bound scope with reasons Each element removes one kind of guess the model would otherwise make Role is the most droppable once task and format are specific enough to imply the perspective Done-criteria and checkable format are the least negotiable because downstream code depends on them

Why do rules belong in the system prompt rather than the user message? Cover adherence, control, and cost, and name what the system prompt cannot guarantee.

Adherence: user turns get diluted over a long conversation, the system prompt stays in force Control: the backend assembles it and users cannot edit it, so rules apply to everyone Cost: prompt caching matches prefixes, so stable content in the system prompt maximizes cache hits Limit: it is not a security boundary; prompt injection can bypass it, so enforce hard rules in code

Why does few-shot prompting work, what goes wrong when you give too many examples, and how do you decide how many to include?

Examples show the continuation directly, which beats prose for conveying format and edge rules Too many examples cost context and money, overfit surface features, and amplify class bias Pick the count by how many distinct cases need coverage, typically two to five with one boundary case Order matters — put the closest match last; when examples and instructions conflict the model follows the examples

Where does chain-of-thought prompting help most, where is it a waste, and how does it differ from splitting a task into steps?

CoT helps because intermediate results check the next step; strong on multi-step reasoning and arithmetic, wasted on single-step judgments Cost is longer output, higher latency and spend, so skip it when no reasoning is needed Versus splitting: CoT stays in one call with one budget; splitting uses multiple calls with independent budgets that can chain outputs With reasoning models you rarely need 'think step by step' but still pin the answer format and location

What are the signs of a task that no amount of prompt engineering will fix, and what do you do when you hit one?

Three failure classes: missing knowledge, missing tools, and a wrongly specified task Missing knowledge is dangerous because the model fabricates well-formatted answers, and stricter formats make them more convincing Fixes live outside the prompt: paste material or add retrieval, add tool use or compute in code, or fix the requirement Seed the test set with unknowable items to check the model admits ignorance

Why should structured output be enforced with a schema instead of a 'please respond in JSON' instruction, and do you still need validation once the schema passes?

'Respond in JSON' only guarantees JSON, not which JSON: wrapper prose, key spelling, stringified numbers, extra or missing keys all slip through A schema constrains generation itself; required, enum, type and additionalProperties each block one failure class Validation is still needed after the schema passes because correct shape does not mean correct content Strict mode needs every property in required and additionalProperties false; express optional fields by allowing null

In a prompt template, what should become a variable and what should stay constant, and what goes wrong when you have too many variables?

Rule: same on the next call means constant, may differ means variable Role, task, constraints and schema are constants; input text, output language and defaults are variables Every variable is a test dimension, so keep them minimal and fold single-valued ones back into constants Multi-language is one variable affecting only human-facing fields; enums and identifiers stay fixed

When the model's JSON fails to parse or validate, how do you design the fallback — how many retries, how do you retry, and what happens after the last failure?

Three layers: validation returns an error list, one retry carries those errors back, then degrade to null and log Retries must include the error list in the user message; verbatim resends reproduce the error One retry is enough; persistent failure means the template or schema lacks coverage Never throw on degradation or use near-miss output; monitor retry rate and add failing inputs to the test set

How do you build a test set for a prompt? How would you choose ten samples, and where do the expected answers come from?

Distribution over count: three or four each of normal, edge and adversarial, plus a couple of unknowable items Normal cases guard the baseline, edge cases test defaults, adversarial cases test focus Expected answers are hand-labeled and re-checked; one wrong label skews everything Best source is real failures; add the triggering input before each prompt change

How do you version prompts? How does it differ from versioning code, and what is your first move when production misbehaves?

Prompt text lives in its own file with a version id; the changelog records change, reason, measured pass rate, known regressions Unlike code, prompt changes are global, so known regressions are mandatory; rollback is nearly free On a production issue, roll back first, then add the triggering input to the test set Record which model version was tested, since pass rates shift across models

Is using a model to grade another model's output reliable? When is it acceptable, and when must a human look?

Prefer field comparison; reserve the judge for free text with nothing to compare Judges favor long, well-formatted answers and score noisily on vague rubrics, so rubrics must list concrete points Calibrate against ten human-scored samples first, then spot-check regularly Facts, safety and money always get human review; use a different vendor or version to avoid self-preference

When you move a prompt from one model vendor to another, where does it break most often, and how do you tell a prompt problem from a genuine capability gap?

Four usual suspects: format markers, instruction strength, refusal boundaries, length habits, each with a detection method Map failing fields to one of the four first; a match means fix the vendor block Capability gaps show on normal cases; edge-only regressions are almost always prompt dialect API compatibility is not behavioral compatibility — rerun the test set even when no code changed

How should a system prompt be organized so it ports across models, and how do you decide which block a given sentence belongs to?

Three blocks: common rules that hold across vendors, a per-vendor adaptation block swapped wholesale, and per-call task variables Two deciding questions: does it still hold on another vendor; does it change every call Self-checks: the prompt stays readable with the vendor block removed; no vendor-specific tokens in the common block Order common, vendor, variables so the most stable prefix leads and cache hits are maximized

After migrating a prompt, how do you verify nothing regressed, and if the pass rate drops, what is your debugging order?

Verification requires a baseline: the same test set run on the source model before migrating Run identical cases on the target and compare pass rates and failing cases side by side Triage: normal versus edge, map failing fields to the four breakages, fix the vendor block only, rerun, and treat failures shared with the source as known regressions Any edit to the common block is a new version that must be re-run on the source; tame randomness with majority-of-three or temperature zero

Interview Bank

328 questions total; 15 shown with current filters.

CourseAll From Frontend Engineer to Agent Engineer in 30 Days Prompt Engineering From Scratch in 5 Days Mastering Claude: From Conversation to Claude Code in 5 Days Mastering Codex and the OpenAI Agents SDK in 5 Days MCP in 7 Days: Wire Tools Into Any Agent Agent Skills in 7 Days: Turn Experience Into Reusable Capability Context Engineering in 5 Days RAG in 14 Days: From Retrieval to Trustworthy Answers Build an AI Short-Drama Production Pipeline With Agents in 14 Days

WeekAll W1

MarketAll Common in China Common overseas

DifficultyAll Basic Intermediate Deep dive

Prompt Engineering From Scratch in 5 Days

D1 What a Prompt Is, and Isn't: How the Model Reads Instructions; the Four Elements of Role / Task / Format / Constraints

What exactly is being engineered in prompt engineering, and how does it differ from writing a requirements doc or a design spec?提示词工程到底在工程什么？它和写需求文档、写技术方案有什么本质区别？
Common in ChinaCommon overseasBasic#prompt-basics#mental-model
How to reason about it · think before answering
The screen here is whether the candidate knows the model completes text rather than executes commands. 'Clever wording that makes the model obey' signals chat-app experience only.
Start from the reader: a spec is read by people who share project context; a prompt is read by a completer with zero context that never asks a clarifying question, so every implicit default must be spelled out.
Then justify the word engineering: reproducibility, testability, versioning. A prompt should run against a test set, live in the repo, and diff cleanly between versions.
Conclusion: prompt engineering is making implicit context explicit and managing that text like code; phrasing tricks are a small part.
Likely follow-up: how is that different from a brief for an outsourced team? The team pushes back with questions; the model does not, so a prompt must carry its own completion criteria.
分析过程 · 先想清楚再作答
这题在筛「有没有理解模型是在补全而不是执行」。答成「用巧妙的措辞让模型听话」会被判为只会用聊天产品；答出「系统性补齐模型缺少的上下文」才算入门。
拆法：先问自己「读者是谁」。需求文档的读者是有项目背景的人，可以依赖共享默认；提示词的读者是一个没有任何项目背景、也不会停下来提问的补全器，所有默认信息都得显式写出。
再落到「工程」二字：可复现、可测试、可版本化。提示词写完要能跑测试集、要进仓库、要能对比两版差异——这才是它区别于「写一段话」的地方。
结论：提示词工程是把隐性上下文显式化、并把这段文本当代码一样管理的工程活动；措辞技巧只是其中很小的一部分。
可预期的追问：那和写给外包团队的需求说明有什么区别？答案是外包会反问，模型不会，所以提示词对完整性的要求更高，且要在没有反馈回路的前提下自带完成标准。
Key points
The model completes text rather than executing commands; a prompt is context, and specificity narrows the plausible continuations
What gets engineered is the missing information: perspective, completion criteria, output shape, boundaries with reasons
Unlike a spec, the reader shares no background and never asks back, so completeness and explicit done-criteria matter more
Engineering implies testable, versioned, comparable artifacts, not one-off clever phrasing
答题要点
模型在补全一段文本而不是执行命令，提示词是给它的上下文，写得越具体可能的下文越窄、输出越稳
工程的对象是「模型缺的信息」：视角、完成标准、输出形状、边界与理由，也就是四要素
区别于需求文档：读者没有共享背景、不会反问，所以完整性要求更高、必须自带完成标准
「工程」意味着可测试、可版本化、可对比，而不是一次性的巧妙措辞
What problem does each of the four prompt elements — role, task, format, constraints — solve? If you could keep only three, which would you drop and why?角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？
Common in ChinaCommon overseasIntermediate#prompt-basics#four-elements
How to reason about it · think before answering
The first half is a warm-up; the second half tests whether you can map each element to a specific way the model would otherwise guess, and rank the cost of each wrong guess.
Map them: role fixes perspective and focus, task fixes the finish line, format decides whether downstream code can consume the output, constraints bound the change surface.
To pick the one to drop, ask whether its absence makes results unstable or unusable. Missing role skews focus but stays usable; missing done-criteria means the model never knows when to stop; missing format breaks parsers; missing constraints lets edits sprawl.
Conclusion: in most engineering settings role is the most droppable, because a specific task plus a strict format already imply the perspective — provided the task states what to care about.
Expect the follow-up 'then why does everyone write a role?' Because it is cheap and compresses many implicit preferences into one line, which pays off in chat-style use where the task cannot be fully specified.
分析过程 · 先想清楚再作答
前半句是送分，后半句才有区分度：它在考你是否知道每个要素对应模型的哪一种「猜」，以及哪种猜错的代价最小。
拆法：把每个要素映射到一个「模型会猜错的地方」——角色对应视角与关注点，任务对应终点在哪，格式对应输出能否被程序消费，约束对应改动范围与不可碰的边界。
判断哪个可砍：看缺了之后是「结果不稳定」还是「结果不可用」。缺角色多半是关注点偏了但仍可用；缺任务的完成标准会让模型不知何时停；缺格式会让下游解析失败；缺约束会让改动面失控。
结论：多数工程场景下角色最可砍，因为任务与格式写得足够具体时视角已经被隐含；但要说明前提是任务里已经写清了关注点。
追问几乎必然是「那为什么大家还都写角色」——答案是它便宜且能一句话压缩大量隐性偏好，在任务没法写得很细的对话场景里性价比最高。
Key points
Role sets perspective; task sets the goal and done-criteria; format makes output mechanically checkable; constraints bound scope with reasons
Each element removes one kind of guess the model would otherwise make
Role is the most droppable once task and format are specific enough to imply the perspective
Done-criteria and checkable format are the least negotiable because downstream code depends on them
答题要点
角色定视角与关注点；任务定做什么与完成标准；格式定输出形状是否可机械核对；约束定不可碰的边界与理由
每个要素对应模型的一种「猜」，缺哪个就多一种不稳定
可砍的是角色：任务与格式足够具体时视角已隐含，但前提是任务里写清了关注点
任务的完成标准与格式的可核对性最不能省，因为它们直接决定输出能不能被程序消费
Why do rules belong in the system prompt rather than the user message? Cover adherence, control, and cost, and name what the system prompt cannot guarantee.为什么规则要放系统提示而不是用户消息？请从遵从度、管控和成本三个角度说明，并指出系统提示做不到什么。
Common in ChinaCommon overseasIntermediate#system-prompt#prompt-basics
How to reason about it · think before answering
The tell is whether you cover all three angles and name a limitation. 'System prompts carry more weight' alone reads as memorized.
Adherence: user turns get diluted as the conversation grows, the system prompt stays in force. Control: the backend assembles the system prompt and users cannot touch it, so rules apply uniformly. Cost: prompt caching matches on prefixes, and the system prompt is the most stable prefix.
The limitation is the differentiator: higher adherence is not a guarantee, prompt injection can still steer the model, so security boundaries need code-level enforcement outside the model.
Conclusion: rules go in the system prompt for stability, consistency and cost, but it is a strong suggestion, not a hard constraint.
Follow-ups: can the system prompt go last? Possible but unwise — models weight early instructions more and it breaks the cache prefix. What should stay out? Per-request task details, which would bust the cache and hurt reuse.
分析过程 · 先想清楚再作答
题眼在「三个角度」和「做不到什么」。只答「系统提示权重高」是背概念，面试官要看的是你有没有在生产里拼过系统提示。
拆法：遵从度看多轮稀释——用户消息会被后续对话淹没，系统提示全程生效；管控看谁能改——系统提示由后端统一拼装、用户碰不到，规则放这里才能对所有用户一致；成本看缓存——提示缓存按前缀命中，系统提示是最稳定的前缀。
「做不到什么」是区分度所在：系统提示遵从度高不等于绝对，提示注入可以让模型跑偏，所以安全边界不能只靠系统提示，要在模型外用代码兜底。
结论：规则进系统提示是为了稳定、一致、省钱；但它是「强建议」不是「硬约束」，硬约束必须在代码层实现。
追问方向：系统提示可以放在对话末尾吗？可以但不推荐——多数模型对靠前指令更敏感，且会破坏缓存前缀；另一个追问是「哪些内容不该进系统提示」，答案是每次都变的任务细节，放进去会让缓存失效且难以复用。
Key points
Adherence: user turns get diluted over a long conversation, the system prompt stays in force
Control: the backend assembles it and users cannot edit it, so rules apply to everyone
Cost: prompt caching matches prefixes, so stable content in the system prompt maximizes cache hits
Limit: it is not a security boundary; prompt injection can bypass it, so enforce hard rules in code
答题要点
遵从度：用户消息会被多轮对话稀释，系统提示全程生效
管控：系统提示由后端统一拼装，用户碰不到，规则才能对所有人一致
成本：提示缓存按前缀命中，系统提示是最稳定的前缀，不变的内容集中在这里最省钱
做不到的：它不是安全边界，提示注入可以绕过，硬约束必须在代码层兜底

D2 Few-Shot, Chain of Thought, Step-by-Step, and Self-Checks; When None of These Work

Why does few-shot prompting work, what goes wrong when you give too many examples, and how do you decide how many to include?few-shot 为什么有效？示例给多了会出什么问题？你怎么决定给几个？
Common in ChinaCommon overseasBasic#few-shot#prompt-techniques
How to reason about it · think before answering
The screen is whether you treat examples as signals for format and boundaries rather than as magic that makes the model smarter. 'More examples, better model' reads as untested.
Mechanism first: the model completes text, and examples show the continuation directly, which is harder to misread than prose describing a format or an edge rule. Examples are the strongest format signal.
Then the cost: each example consumes context and money; too many cause overfitting to surface features such as length, wording and order, and amplify accidental bias — three bug examples out of four nudges everything toward bug.
Conclusion: the count follows the number of distinct cases you need to cover, typically two to five, each a different case, with at least one boundary sample.
Follow-ups: does order matter? Yes, models weight the last example more, so place the one closest to the target input last. And if examples contradict the instructions, the model usually follows the examples, so they must match the format spec exactly.
分析过程 · 先想清楚再作答
这题在筛「有没有把示例当成格式与边界的信号，而不是当成让模型变聪明的魔法」。答成「示例越多模型越懂」会暴露没在生产里调过提示词。
拆法：先答原理——模型在补全，示例直接展示了「下文该长什么样」，比文字描述格式和边界规则更不容易被误读；示例是最强的格式信号。
再答代价：每个示例都占上下文与费用；示例过多会让模型过拟合示例的表面特征（长度、措辞、顺序），还会把示例里无意带进去的偏见放大，比如四个示例里三个是 bug，它就更倾向判 bug。
结论：数量由「要覆盖几种类型」决定而不是越多越好，通常两到五个，每个覆盖一种不同的情况，并且至少一个是边界样本。
可预期的追问：示例的顺序有影响吗？有，多数模型对最后一个示例更敏感，所以把最像目标输入的放最后；另一个追问是示例和说明冲突时模型听谁的，答案是多半听示例，所以示例必须与格式栏逐字一致。
Key points
Examples show the continuation directly, which beats prose for conveying format and edge rules
Too many examples cost context and money, overfit surface features, and amplify class bias
Pick the count by how many distinct cases need coverage, typically two to five with one boundary case
Order matters — put the closest match last; when examples and instructions conflict the model follows the examples
答题要点
示例直接展示下文该长什么样，比文字描述格式和边界规则更不容易被误读
示例过多的代价：占上下文与费用、过拟合表面特征、放大示例里的类别偏见
数量按「要覆盖几种不同情况」定，通常两到五个，至少一个边界样本
顺序有影响，最像目标输入的放最后；示例与说明冲突时模型多半听示例
Where does chain-of-thought prompting help most, where is it a waste, and how does it differ from splitting a task into steps?思维链在什么任务上提升明显，在什么任务上是浪费？它和「分步」有什么区别？
Common in ChinaCommon overseasIntermediate#chain-of-thought#prompt-techniques
How to reason about it · think before answering
The discriminators are 'waste' and 'difference'. Anyone can say thinking first helps; the interviewer wants to hear when you deliberately skip it.
Its value comes from intermediate results checking the next step, so it shines on multi-step reasoning, arithmetic and judgments with distractors; on single-step tasks such as classification, extraction or format conversion it adds latency, cost and length with little gain.
Difference: chain-of-thought keeps everything in one call and one output budget; splitting uses several calls, each with its own budget and format, and later steps can consume earlier outputs. Use CoT when the model thinks too shallowly, split when one answer cannot hold the work.
Conclusion: ask whether the task needs multi-step reasoning at all; if yes, ask whether one output can hold it — CoT if so, split if not.
Follow-ups: with reasoning models that think internally, do you still write 'think step by step'? Usually no, but you still pin the answer format and position. And can you trust the written reasoning? It is a plausible narrative, not the actual computation — use it as a check, not as proof.
分析过程 · 先想清楚再作答
题眼在「浪费」和「区别」。只会说「让模型先思考再回答效果更好」的候选人没有算过账，面试官想听的是你什么时候会主动不用它。
拆法：思维链的价值来自「中间结果可以校验下一步」，所以它在多步推理、算术、需要排除干扰项的判断上提升明显；在单步判断（分类、抽取、格式转换）上几乎没有增益，只有更慢更贵更长的输出。
区别：思维链是一次调用内让模型写出中间过程，输出预算还是同一份；分步是拆成多次调用，每步有独立的预算、独立的格式、并且后一步可以拿前一步的输出做输入。任务是「想得不够细」用思维链，任务是「一次装不下」用分步。
结论：先问任务是否需要多步推理，不需要就不用；需要的话再问一次输出装不装得下，装得下用思维链，装不下拆步。
追问：推理类模型内置了思考过程，还要写思维链吗？多数情况不用再写「一步步想」，但仍要指定最终答案的格式与位置，否则解析会很痛苦；另一个追问是思维链的内容能不能信，答案是它是「看起来合理的过程」而非真实的内部计算，只能当辅助校验不能当证据。
Key points
CoT helps because intermediate results check the next step; strong on multi-step reasoning and arithmetic, wasted on single-step judgments
Cost is longer output, higher latency and spend, so skip it when no reasoning is needed
Versus splitting: CoT stays in one call with one budget; splitting uses multiple calls with independent budgets that can chain outputs
With reasoning models you rarely need 'think step by step' but still pin the answer format and location
答题要点
思维链的价值是中间结果校验下一步，多步推理与算术上提升明显，单步判断上是浪费
代价是更长的输出、更高的延迟与费用，所以不需要推理的任务要主动不用
与分步的区别：思维链是一次调用内写过程，输出预算不变；分步是多次调用，每步独立预算且可传递输出
推理模型内置思考后一般不必再写「一步步想」，但仍要指定答案格式与位置
What are the signs of a task that no amount of prompt engineering will fix, and what do you do when you hit one?提示词写得再好也做不对的任务有哪些特征？遇到这类任务你会怎么办？
Common in ChinaCommon overseasIntermediate#prompt-limits#failure-modes
How to reason about it · think before answering
This tests whether you know where prompting ends. Piling techniques onto a hopeless task signals poor judgment; saying 'this is not a prompting problem' signals maturity.
Three failure classes. Missing knowledge: the fact postdates training or lives in your private data, and the model may fabricate a well-formatted answer. Missing tools: the task needs an action or query against the world. Wrong task: the requirement is contradictory or you actually want something else.
One test each: could the model plausibly know something that appeared yesterday? Could a person who can only type complete this? Would two readers of the requirement do opposite things?
Conclusion: paste the material or add retrieval for missing knowledge; add tool use or compute in code for missing tools; fix the requirement for a wrong task. None of these is a prompt change.
Follow-ups: stricter formats make fabrications look more credible — require sources or verifiable identifiers and validate in code. And to catch these early, seed the test set with a few unknowable items and check that the model admits it does not know.
分析过程 · 先想清楚再作答
这题考的是「知道提示词的边界在哪」。一直往提示词上堆技巧的候选人会被判为缺乏判断力；能说出「这题不该用提示词解」才是成熟的信号。
拆法：把失效分三类。缺知识——信息在模型训练截止之后或本来就在你的私有数据里，模型不可能知道，还可能编出格式正确的假答案；缺工具——任务需要对外部世界做动作或查询（跑命令、查库、发请求），文字生成做不到；任务写错——需求本身自相矛盾或者你要的其实是另一件事。
每类给一个判据：缺知识问「这信息是昨天才出现的，模型有可能知道吗」；缺工具问「一个只能打字的人能完成这件事吗」；任务写错问「两个人读这个需求会不会得出相反的做法」。
结论：缺知识就把资料贴进上下文或接检索；缺工具就接工具调用或在代码里做完再让模型解读；任务写错回去改需求。三种都不是提示词层面的解法。
追问几乎必然是「格式越严格假答案越像真的怎么办」——答案是对事实类输出要求带出处或可验证的标识，并在代码里校验；以及「怎么在评估里提前发现这类任务」，答案是测试集里放几条模型不可能知道的样本，看它是否老实说不知道。
Key points
Three failure classes: missing knowledge, missing tools, and a wrongly specified task
Missing knowledge is dangerous because the model fabricates well-formatted answers, and stricter formats make them more convincing
Fixes live outside the prompt: paste material or add retrieval, add tool use or compute in code, or fix the requirement
Seed the test set with unknowable items to check the model admits ignorance
答题要点
三类失效：缺知识（截止日期之后或私有数据）、缺工具（需要对外部世界做动作）、任务写错（需求自相矛盾）
缺知识的危险在于模型会编出格式正确的假答案，格式越严越像真的
解法都在提示词之外：贴资料或接检索、接工具调用或代码先算、回去改需求
测试集里放几条模型不可能知道的样本，检查它会不会老实说不知道

D3 Structured Output: JSON Schema, Templates and Variables, Multilingual Output

Why should structured output be enforced with a schema instead of a 'please respond in JSON' instruction, and do you still need validation once the schema passes?结构化输出为什么要用 schema 约束，而不是在提示词里写「请输出 JSON」？schema 通过之后还需要校验吗？
Common in ChinaCommon overseasBasic#structured-output#json-schema
How to reason about it · think before answering
This screens for whether the candidate has ever wired model output into code. People who only read output with their eyes think 'respond in JSON' is enough.
List what that instruction cannot prevent: prose wrapped around the JSON, inconsistent key spelling, numbers as strings, extra keys, missing keys when an array is empty. Each maps to a schema keyword: required, enum, type, additionalProperties.
Then the mechanism: the schema constrains generation itself, the model can only produce that shape, so the gain is qualitative rather than incremental.
The second half is the differentiator: schemas constrain shape, not content — integer is not 4xx, string is not non-empty. Business rules still need code-level validation that returns an error list for retries.
Follow-ups: strict-mode limits — every property in required, additionalProperties false, a supported subset of JSON schema, a first-use compile cost; and how to express optional fields — allow null in the type rather than dropping the key from required.
分析过程 · 先想清楚再作答
这题在筛「有没有真的把模型输出接进过程序」。只在聊天窗口里用过模型的人会觉得「请输出 JSON」够了，因为他们是用眼睛读的。
拆法：列出「请输出 JSON」挡不住的几种踩空——外面包一段解释、字段名拼法不一致、数字变字符串、多出字段、空数组时省掉键。每一种都对应 schema 里的一个关键字：required、enum、type、additionalProperties。
再答原理：schema 在生成时约束形状，模型不是「生成完再检查」而是「只能生成这个形状」，所以稳定性是质变而不是量变。
后半句是区分度：schema 只能约束形状，不能约束内容——整数不等于 4xx，字符串不等于非空。业务规则必须在代码里再查一遍，校验函数返回错误列表供重试使用。
可预期的追问：严格模式有什么限制？所有字段都要进 required、要写 additionalProperties false、只支持 schema 子集、首次编译有开销；以及「可选字段怎么表达」——类型允许 null 而不是从 required 里去掉。
Key points
'Respond in JSON' only guarantees JSON, not which JSON: wrapper prose, key spelling, stringified numbers, extra or missing keys all slip through
A schema constrains generation itself; required, enum, type and additionalProperties each block one failure class
Validation is still needed after the schema passes because correct shape does not mean correct content
Strict mode needs every property in required and additionalProperties false; express optional fields by allowing null
答题要点
「请输出 JSON」只约束「是 JSON」，挡不住包解释文字、字段名不一致、数字变字符串、多字段、省键这几种踩空
schema 在生成时约束形状：required、enum、type、additionalProperties 各挡一种错误
schema 通过之后仍要校验业务规则，因为形状正确不等于内容正确
严格模式要求所有字段进 required 且 additionalProperties 为 false；可选字段用允许 null 表达
In a prompt template, what should become a variable and what should stay constant, and what goes wrong when you have too many variables?提示词模板里哪些内容该做成变量，哪些该写死？变量多了会有什么问题？
Common in ChinaCommon overseasIntermediate#prompt-template#structured-output
How to reason about it · think before answering
It looks like a design question but really asks whether you have maintained a prompt in production. The untested instinct is to parameterize everything; experience teaches that every variable is a test dimension.
One rule: what stays the same on the next call is a constant, what may differ is a variable. Role, task, constraints and schema are usually constants; input text, output language and team defaults are variables.
Then the cost: each variable adds a dimension to the space of prompts, doubling the combinations a test set must cover, and variables can interact. Fewer is better; a variable that only ever took one value should become a constant.
Conclusion: the template is a named function with a signature; variables are parameters, constants are the body. That identity is what makes versioning and testing possible.
Follow-up: is multi-language a variable or separate templates? A variable — one template, language affects only human-facing fields, enums and identifiers never change; separate copies drift within months.
分析过程 · 先想清楚再作答
这题看起来是设计题，实际在考「有没有维护过一份跑在生产里的提示词」。没维护过的人会把所有能变的都做成变量，觉得灵活；维护过的人知道每个变量都是一条测试维度。
拆法：判据只有一条——下一次调用还会一样的是常量，可能不一样的是变量。角色、任务、约束、schema 通常是常量；输入文本、输出语言、团队默认值是变量。
再答代价：每多一个变量，提示词的可能形态多一个维度，测试集要覆盖的组合翻倍；变量之间还可能互相影响（语言变量与格式说明冲突）。所以变量越少越好，只取过一个值的「变量」应该变回常量。
结论：模板是一个有名字、有参数签名的函数，变量是它的参数，常量是函数体；这样提示词才有身份，才能版本化、才能写测试。
追问：多语言应该是变量还是多份模板？变量——只有一份模板，语言只影响给人读的字段，枚举与标识符不跟着变；否则改一条规则要改多份，三个月后一定分叉。
Key points
Rule: same on the next call means constant, may differ means variable
Role, task, constraints and schema are constants; input text, output language and defaults are variables
Every variable is a test dimension, so keep them minimal and fold single-valued ones back into constants
Multi-language is one variable affecting only human-facing fields; enums and identifiers stay fixed
答题要点
判据：下一次调用还一样的是常量，可能不一样的是变量
角色、任务、约束、schema 是常量；输入文本、输出语言、默认值是变量
每个变量都是一条测试维度，变量越少越好，只取过一个值的变回常量
多语言是一个变量，只影响给人读的字段，枚举与标识符不变
When the model's JSON fails to parse or validate, how do you design the fallback — how many retries, how do you retry, and what happens after the last failure?模型返回的 JSON 解析或校验失败时，你会怎么设计兜底？重试几次、怎么重试、失败之后怎么办？
Common in ChinaCommon overseasIntermediate#structured-output#error-handling
How to reason about it · think before answering
A production question that checks whether you have seen a model misbehave. 'Wrap it in try/catch and retry three times' is the novice answer — it says nothing about what you resend or what happens at the end.
Three layers. Validation returns an error list, not a boolean. Retry appends that list to the user message so the model knows what to fix; resending verbatim mostly reproduces the error. Degradation returns null and logs, leaving skip-or-human to the caller.
Retry count: one is enough. Persistent failure means the prompt or schema lacks coverage, so fix the template instead of retrying; each retry costs a full call.
The key conclusion: do not throw on degradation, and do not use a near-miss result. Extraction failure is a normal branch; half-correct structured data is worse than none because downstream code trusts it.
Follow-ups: how to tell flakiness from a prompt bug? Failure rate — sporadic is flakiness, a stable failing input class is missing coverage and belongs in the test set. And does retrying inflate cost? Cap it and monitor the retry rate.
分析过程 · 先想清楚再作答
这题是生产题，考的是「有没有见过模型抽风」。答「加个 try catch 重试三次」是新手答案，它没回答重试时发什么、也没回答最后怎么办。
拆法：分三层。校验层返回错误列表而不是布尔值；重试层把错误列表拼进用户消息，让模型知道上一次错在哪，原样重发大概率同样的错；降级层返回空值并记录，交调用方决定跳过还是人工处理。
重试次数：一次就够。两次以上还不对说明问题不在这条输入而在提示词或 schema，应该修模板而不是继续重试；每次重试都是一次完整调用的钱和延迟。
结论里最重要的一条：降级不要抛异常，也不要把「差一点」的结果凑合着用。抽取失败是正常业务分支；半对的结构化数据比没有数据更危险，因为下游会把它当真的。
追问方向：怎么区分「模型抽风」和「提示词有问题」？看失败率——偶发是抽风，某类输入稳定失败是提示词或 schema 缺覆盖，应该把那类输入加进测试集；另一个追问是重试会不会放大成本，答案是要有预算上限并监控重试率。
Key points
Three layers: validation returns an error list, one retry carries those errors back, then degrade to null and log
Retries must include the error list in the user message; verbatim resends reproduce the error
One retry is enough; persistent failure means the template or schema lacks coverage
Never throw on degradation or use near-miss output; monitor retry rate and add failing inputs to the test set
答题要点
三层：校验返回错误列表、带着错误原因重试一次、失败后返回空值并记录
重试时必须把错误列表拼回用户消息，原样重发大概率同样的错
重试一次足够，稳定失败说明模板或 schema 缺覆盖，该修模板不该继续重试
降级不抛异常、不用半对的结果；监控重试率，稳定失败的输入加进测试集

D4 Iteration and Evaluation: Small Test Sets, A/B Testing, Version Control, Common Anti-Patterns

How do you build a test set for a prompt? How would you choose ten samples, and where do the expected answers come from?怎么给一个提示词建测试集？十条样本该怎么挑，标准答案从哪来？
Common in ChinaCommon overseasBasic#evaluation#test-set
How to reason about it · think before answering
This screens for whether the candidate has actually built one. 'Collect some inputs and run them' means no; people who have start with distribution, because prompt errors cluster at the edges.
Three classes with three or four each: normal inputs guard the baseline; edge inputs (missing defaults, optional fields, informal phrasing) test whether default rules are explicit; adversarial inputs (distractors, mid-sentence corrections, unrelated asks) test focus. Add one or two unknowable items to check honesty.
Expected answers are labeled by hand, no shortcut; one mislabeled case skews the whole evaluation and sends you chasing a phantom prompt bug. Re-read each input after labeling to confirm the answer is unique.
Conclusion: ten is enough to start, value lies in distribution not count, and the best source is every real 'it failed again' input from the past week.
Follow-ups: how does the set grow? Add the triggering input before every prompt change. And leakage — test cases must not double as few-shot examples, or you are measuring memorization rather than generalization.
分析过程 · 先想清楚再作答
这题在筛「有没有真的建过测试集」。答「多找一些输入跑一跑」的人没建过；建过的人第一句会说分布——因为提示词的错误全集中在边界上。
拆法：三类各占三四条。正常输入守底线，新版弄坏它们就是严重回退；边界输入（没写默认值、可选字段、不规范写法）测默认规则说清没说清；刁难输入（干扰信息、中途改口、夹带无关要求）测能不能抓住重点。可以再放一两条模型不可能知道的样本，看它是否老实说不知道。
标准答案只能人工标，这一步没有捷径；标错一条整份评估就偏，而且你会误以为是提示词的问题去反复改。每条写完再读一遍输入确认答案唯一。
结论：十条够起步，价值在分布不在数量；最好的来源是过去每一次「它又错了」的真实输入，一周就能攒出比想象出来的更真实的测试集。
可预期的追问：测试集怎么增长？每次想改提示词先把触发的那条输入加进去再改；以及「测试集会不会泄漏进提示词」——用例不能直接当 few-shot 示例，否则是在测记忆而不是泛化。
Key points
Distribution over count: three or four each of normal, edge and adversarial, plus a couple of unknowable items
Normal cases guard the baseline, edge cases test defaults, adversarial cases test focus
Expected answers are hand-labeled and re-checked; one wrong label skews everything
Best source is real failures; add the triggering input before each prompt change
答题要点
价值在分布不在数量：正常、边界、刁难三类各三四条，再放一两条模型不可能知道的
正常输入守底线，边界测默认规则，刁难测抓重点
标准答案人工标注、逐条复核，标错一条整份评估就偏
最好的来源是真实出错的输入；每次想改提示词先把那条加进测试集
How do you version prompts? How does it differ from versioning code, and what is your first move when production misbehaves?提示词版本化怎么做？它和代码版本管理有什么不同？线上出问题你先做什么？
Common in ChinaCommon overseasIntermediate#prompt-versioning#evaluation
How to reason about it · think before answering
One of the most frequent prompt-engineering interview questions abroad; it tests whether you have managed prompts as production assets. 'Put it in git' is the floor; the interviewer wants the changelog contents and why prompts differ from code.
Shape first: prompt text in its own file, an id per version, decoupled from business code. Then the changelog's four items: what changed, why (which test cases failed), the measured pass rate, known regressions. The pass rate must come from the script.
The difference is the differentiator: code changes are usually local, prompt changes are global — one added sentence can shift behavior on every input, so 'known regressions' is mandatory where commit messages have no such field. Also rollback is nearly free, just swap a string.
Conclusion: when production misbehaves, roll back to the previous version first, then add the triggering input to the test set and investigate — which only works if you have version ids and a test set.
Follow-ups: bind prompt versions to model versions? Yes — pass rates shift across model versions, so record which model was used. And canarying: route by version id and compare live metrics, same as code.
分析过程 · 先想清楚再作答
这题是海外面试里提示词工程方向出现频率最高的一道，考的是「有没有把提示词当成生产资产管理过」。答「放进 git」是最低分，面试官要听的是变更记录里写什么、以及为什么和代码不一样。
拆法：先说形态——提示词正文独立成文件、每版有 id、与业务代码解耦；再说变更记录四件事——改了什么、为什么改（对应哪几条测试失败）、跑出来的通过率、已知回退。通过率必须是脚本跑出来的数字。
不同点是区分度所在：代码改动通常是局部的，提示词改动是全局的——加一句话可能改变所有输入的行为，所以「已知回退」是必填项而代码提交信息里没有这一栏；另一点是回滚成本几乎为零，只是换一个字符串。
结论：线上出问题第一步是回滚到上一版，再拿触发问题的输入补进测试集慢慢查——前提是你有版本号可回、有测试集可跑。
追问：提示词版本要不要和模型版本绑定？要——同一份提示词在不同模型版本上通过率会变，记录里要写清是在哪个模型上测的；另一个追问是多环境怎么灰度，答案是按版本 id 分流并对比两版的线上指标，跟代码灰度一样。
Key points
Prompt text lives in its own file with a version id; the changelog records change, reason, measured pass rate, known regressions
Unlike code, prompt changes are global, so known regressions are mandatory; rollback is nearly free
On a production issue, roll back first, then add the triggering input to the test set
Record which model version was tested, since pass rates shift across models
答题要点
提示词正文独立成文件、每版有 id，变更记录写改动、原因、脚本跑出的通过率、已知回退
与代码的不同：改动是全局的，所以「已知回退」必填；回滚成本几乎为零
线上出问题先回滚上一版，再把触发输入加进测试集查
版本要记录在哪个模型上测的，换模型版本通过率会变
Is using a model to grade another model's output reliable? When is it acceptable, and when must a human look?用模型给模型打分靠谱吗？什么时候可以用，什么时候必须人工看？
Common in ChinaCommon overseasIntermediate#evaluation#llm-as-judge
How to reason about it · think before answering
This tests whether you know the judge is fallible too. 'Use a stronger model as the judge' means you never calibrated one; 'prefer field comparison whenever possible' shows judgment.
Split by task: structured output gets field-by-field code comparison, no judge needed; free text (summaries, emails, explanations) has no fields, and a judge is the only scalable option.
Judge biases: longer and prettier answers score higher, stylistic similarity gets rewarded, vague rubrics produce noisy scores, factual errors are under-penalized. So the rubric must be concrete — list the information points, one point each — not 'rate this summary 1 to 10'.
Conclusion: usable once calibrated against ten human-scored samples with an agreement rate you accept; spot-check regularly; anything involving facts, safety or money still gets human review.
Follow-ups: same vendor for judge and judged? Expect self-preference, so switch vendor or at least version. And cost — every judgment is a full call, so let code handle whatever it can first.
分析过程 · 先想清楚再作答
这题在考「知道裁判也会错」。答「用更强的模型当裁判就行」的人没校准过裁判；答出「能用字段比对就不用裁判」才说明有判断力。
拆法：先分任务。输出是固定字段就用代码逐字段比对，不需要裁判；输出是自由文本（摘要、邮件、解释）才没有字段可比，这时裁判是唯一能规模化的办法。
再说裁判的偏差：偏向长的、格式漂亮的、和自己风格接近的回答；评分标准含糊时打分随意；对事实性错误不敏感。所以评分标准要像便签一样具体——列出信息点、每点一分——而不是「给这段摘要打 1 到 10 分」。
结论：裁判可以用，前提是先拿十条人工打过分的样本校准它，看它和人的一致率；上线后定期抽样复核；对涉及事实、安全、金额的输出必须人工看。
追问方向：裁判和被评的模型是同一家会怎样？会有自我偏好，尽量换一家或至少换一个版本；另一个追问是「裁判的成本」，每条评估都是一次完整调用，测试集大了要算钱，所以能用代码判的部分先用代码判掉。
Key points
Prefer field comparison; reserve the judge for free text with nothing to compare
Judges favor long, well-formatted answers and score noisily on vague rubrics, so rubrics must list concrete points
Calibrate against ten human-scored samples first, then spot-check regularly
Facts, safety and money always get human review; use a different vendor or version to avoid self-preference
答题要点
能用字段比对就不用裁判；裁判只用于没有字段可比的自由文本
裁判偏向长的、格式漂亮的回答，评分标准含糊就打得随意，所以标准要具体到信息点
先用十条人工打分样本校准裁判，上线后定期抽样复核
涉及事实、安全、金额的输出必须人工看；裁判尽量换一家或换版本以避免自我偏好

D5 Migrating Across Models: Differences Between Claude / GPT / Domestic Chinese Models, Organizing the System Prompt; Where to Go Next — the Claude Course or the Codex Course

When you move a prompt from one model vendor to another, where does it break most often, and how do you tell a prompt problem from a genuine capability gap?同一份提示词从一家模型迁到另一家，最常坏在哪里？你怎么区分是提示词的问题还是模型能力的问题？
Common in ChinaCommon overseasIntermediate#model-migration#cross-model
How to reason about it · think before answering
This screens for whether you have actually migrated a prompt. 'The other model is just worse' means no; people who have know failures cluster in four places and are rarely capability gaps.
Four breakage points, each with a detection method: format markers — do your structural symbols leak into the output; instruction strength — does an edge case get followed literally or embellished; refusal boundaries — do adversarial cases trigger new refusals or disclaimers; length habits — compare output length and item counts on normal inputs.
To separate prompt from capability: map failing fields to one of the four; if they match, fix the vendor block. If not, check whether failures are on normal or edge cases — capability gaps show on normal cases too, while edge-only regressions are almost always vendor-specific defaults hiding in the prompt.
Conclusion: nine out of ten regressions are unisolated 'dialect' fixed in the vendor block; genuine capability gaps are rare and surface on normal cases.
Follow-up: if the SDK is API-compatible, is migration free? No — compatible requests do not mean compatible interpretation, and the four breakages are easier to miss precisely because nothing crashed.
分析过程 · 先想清楚再作答
这题在筛「有没有真的迁过」。没迁过的人会说「换个模型效果就差了」；迁过的人知道退步几乎都落在四处，而且多数不是能力差异。
拆法：四处断裂各配一个识别方法。格式标签——看输出里有没有出现你用来做结构的符号；指令强度——跑边界用例看是照办还是发挥；拒答边界——跑刁难用例看有没有新的拒答或多余说明；长度习惯——对比正常输入的输出长度与条目数。
区分提示词问题与能力问题：先看失败用例的字段能不能对上四处之一，能对上就改厂商适配块；对不上再看失败的是正常用例还是边界用例——能力差异通常在正常用例上也会体现，而边界用例上的退步几乎都是提示词里藏着只对某一家成立的默认。
结论：迁移退步十有九是「方言」没隔离，改厂商适配块就能恢复；真正的能力差异少见且会在正常用例上现形。
可预期的追问：接口兼容（同一份 SDK 调通）是不是就不用管了？不是——接口兼容只说明请求格式一样，四处断裂照样出现，而且更容易被忽略。
Key points
Four usual suspects: format markers, instruction strength, refusal boundaries, length habits, each with a detection method
Map failing fields to one of the four first; a match means fix the vendor block
Capability gaps show on normal cases; edge-only regressions are almost always prompt dialect
API compatibility is not behavioral compatibility — rerun the test set even when no code changed
答题要点
四处最常坏：格式标签、指令强度、拒答边界、长度习惯，各有识别方法
先把失败字段对四处对号，对上就改厂商适配块
能力差异会在正常用例上现形；只在边界用例上退步几乎都是提示词的方言
接口兼容不等于行为兼容，代码没改也要跑测试集
How should a system prompt be organized so it ports across models, and how do you decide which block a given sentence belongs to?系统提示应该怎么组织才方便跨模型复用？怎么判断某一句该放哪一块？
Common in ChinaCommon overseasIntermediate#system-prompt#model-migration
How to reason about it · think before answering
It looks structural but tests whether you have maintained one prompt across vendors. 'Just write it clearly' means no; experienced people start with blocks.
Three blocks, one question each. Common rules — would this sentence still hold on another vendor? Role, task, done-criteria, reasoned constraints, schema. Vendor adaptation — is this true for one vendor only? Input wrapping, example style, length hints, refusal wording, structured-output switch; one per vendor, swapped wholesale. Task variables — does this change per call? Make it a parameter.
Two self-checks are the differentiator: delete the vendor block entirely and see if what remains is still a readable prompt; grep the common block for any vendor-specific token — tag names, API parameter names, style preferences.
Conclusion: the payoff goes beyond migration — the common block is the longest, most stable prefix, so leading with it maximizes prompt-cache hits; vendor block fixed per vendor; variables last. It extends the D1 principle of keeping stable content in the system prompt.
Follow-up: where do few-shot examples go? Their content is common, their rendering (wrapping tags, code-block style) is vendor-specific, so split examples into content plus rendering, or at least keep vendor tags out of them.
分析过程 · 先想清楚再作答
这题看似问结构，实际在考「有没有维护过多家模型共用的一份提示词」。答「写清楚一点就能通用」的人没维护过；维护过的人会先说分块。
拆法：三块各回答一个问题。通用规则——这一句换一家模型还成立吗，成立放这里（角色、任务、完成标准、带理由的约束、schema）；厂商适配——这一句是不是只对某一家成立，是的放这里（输入包裹方式、示例风格、长度提示、拒答边界表述、结构化输出开关），每家一份整块替换；任务变量——每次调用都在变吗，是的做成参数。
两条自检是区分度：把厂商块整块删掉，剩下的还是不是一份能读懂的提示词；通用块里搜有没有任何一家的专属词（标签名、API 参数名、风格偏好）。
结论：分块的收益不只是迁移——通用块是最长最稳定的前缀，放最前面缓存命中最高；厂商块每家固定；任务变量放最后。这跟 D1 讲系统提示要放稳定内容是同一条原则的延伸。
追问：few-shot 示例算哪一块？示例的内容属于通用规则，示例的书写风格（包裹标签、代码块风格）属于厂商适配，所以示例最好也拆成「内容 + 渲染」两层，或者至少不带厂商专属标签。
Key points
Three blocks: common rules that hold across vendors, a per-vendor adaptation block swapped wholesale, and per-call task variables
Two deciding questions: does it still hold on another vendor; does it change every call
Self-checks: the prompt stays readable with the vendor block removed; no vendor-specific tokens in the common block
Order common, vendor, variables so the most stable prefix leads and cache hits are maximized
答题要点
三块：通用规则（换模型仍成立）、厂商适配（每家一份整块替换）、任务变量（每次调用的参数）
判据是两个问题：换一家还成立吗；每次调用都在变吗
自检：删掉厂商块剩下的仍可读；通用块里没有任何一家的专属词
顺序通用、厂商、变量，最稳定的前缀在前，缓存命中最高
After migrating a prompt, how do you verify nothing regressed, and if the pass rate drops, what is your debugging order?迁移之后怎么验证效果没有退步？如果通过率降了，你的排查顺序是什么？
Common in ChinaCommon overseasDeep dive#model-migration#evaluation
How to reason about it · think before answering
A combined D4/D5 question testing whether verification is a process. 'Run a few and see' is the floor; the interviewer wants baseline, identical cases, field-level triage.
Verification needs a baseline: the same test set run on the source model beforehand with pass rate and failing cases recorded. Then run the identical cases on the target and put the columns side by side.
Debugging order: normal versus edge failures first — edge failures point at the prompt; map failing fields to the four breakages and fix the vendor block, leaving the common block untouched; rerun; remaining failures that overlap the source model's are the prompt's own known regressions, unrelated to migration, handled through the D4 changelog.
Conclusion: migration is done when the target matches the source pass rate with zero edits to the common block; editing the common block is a new prompt version and must be re-run on the source too.
Follow-ups: single-run noise — run each case three times and take the majority, or use temperature zero. And keep dual-running for a while, because vendor model updates drift pass rates and the test set is the only thing that catches drift early.
分析过程 · 先想清楚再作答
这题是 D4 与 D5 的合题，考的是「验证有没有流程」。答「多跑几条看看」是最低分；面试官要听的是基线、同一批用例、逐字段对号。
拆法：验证的前提是基线——迁移前在源模型上跑过同一份测试集并记录通过率与失败用例；没有基线就没有「退步」可言。迁移后用完全相同的用例在目标模型上跑，两列并排。
排查顺序：先看失败用例是正常还是边界——边界优先怀疑提示词；再把失败字段对四处断裂对号，改厂商适配块，通用块不动；再跑一遍；仍失败的用例看是否与源模型的失败重合——重合的是提示词自身的已知回退，与迁移无关，按 D4 的变更记录处理。
结论：达到与源模型相同的通过率、且通用规则块一个字没改，迁移才算完成；改了通用块就等于改了提示词版本，要重新在源模型上跑。
追问：真模型有随机性，一次运行的通过率能信吗？每条跑三次取多数或温度设 0；另一个追问是要不要在两家上长期并跑，答案是至少保留一段时间的双跑对比，因为模型版本更新会让通过率漂移，测试集是唯一能及时发现漂移的工具。
Key points
Verification requires a baseline: the same test set run on the source model before migrating
Run identical cases on the target and compare pass rates and failing cases side by side
Triage: normal versus edge, map failing fields to the four breakages, fix the vendor block only, rerun, and treat failures shared with the source as known regressions
Any edit to the common block is a new version that must be re-run on the source; tame randomness with majority-of-three or temperature zero
答题要点
验证前提是基线：迁移前在源模型跑过同一份测试集
同一批用例在目标模型上跑，两列并排看通过率与失败用例
排查顺序：正常还是边界 → 失败字段对四处断裂 → 改厂商块不动通用块 → 重跑 → 与源模型重合的失败是已知回退
通用块改了就是新版本，要回源模型重跑；随机性用多次取多数或温度 0 压住