面试题库

5 天提示词工程零基础

D3 结构化输出：JSON schema、模板与变量、多语言输出

• 结构化输出为什么要用 schema 约束，而不是在提示词里写「请输出 JSON」？schema 通过之后还需要校验吗？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?

  国内高频海外高频基础#structured-output#json-schema

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

  1. 这题在筛「有没有真的把模型输出接进过程序」。只在聊天窗口里用过模型的人会觉得「请输出 JSON」够了，因为他们是用眼睛读的。
  2. 拆法：列出「请输出 JSON」挡不住的几种踩空——外面包一段解释、字段名拼法不一致、数字变字符串、多出字段、空数组时省掉键。每一种都对应 schema 里的一个关键字：required、enum、type、additionalProperties。
  3. 再答原理：schema 在生成时约束形状，模型不是「生成完再检查」而是「只能生成这个形状」，所以稳定性是质变而不是量变。
  4. 后半句是区分度：schema 只能约束形状，不能约束内容——整数不等于 4xx，字符串不等于非空。业务规则必须在代码里再查一遍，校验函数返回错误列表供重试使用。
  5. 可预期的追问：严格模式有什么限制？所有字段都要进 required、要写 additionalProperties false、只支持 schema 子集、首次编译有开销；以及「可选字段怎么表达」——类型允许 null 而不是从 required 里去掉。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. Then the mechanism: the schema constrains generation itself, the model can only produce that shape, so the gain is qualitative rather than incremental.
  4. 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.
  5. 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 通过之后仍要校验业务规则，因为形状正确不等于内容正确
  • 严格模式要求所有字段进 required 且 additionalProperties 为 false；可选字段用允许 null 表达

  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
• 提示词模板里哪些内容该做成变量，哪些该写死？变量多了会有什么问题？In a prompt template, what should become a variable and what should stay constant, and what goes wrong when you have too many variables?

  国内高频海外高频进阶#prompt-template#structured-output

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

  1. 这题看起来是设计题，实际在考「有没有维护过一份跑在生产里的提示词」。没维护过的人会把所有能变的都做成变量，觉得灵活；维护过的人知道每个变量都是一条测试维度。
  2. 拆法：判据只有一条——下一次调用还会一样的是常量，可能不一样的是变量。角色、任务、约束、schema 通常是常量；输入文本、输出语言、团队默认值是变量。
  3. 再答代价：每多一个变量，提示词的可能形态多一个维度，测试集要覆盖的组合翻倍；变量之间还可能互相影响（语言变量与格式说明冲突）。所以变量越少越好，只取过一个值的「变量」应该变回常量。
  4. 结论：模板是一个有名字、有参数签名的函数，变量是它的参数，常量是函数体；这样提示词才有身份，才能版本化、才能写测试。
  5. 追问：多语言应该是变量还是多份模板？变量——只有一份模板，语言只影响给人读的字段，枚举与标识符不跟着变；否则改一条规则要改多份，三个月后一定分叉。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
• 模型返回的 JSON 解析或校验失败时，你会怎么设计兜底？重试几次、怎么重试、失败之后怎么办？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?

  国内高频海外高频进阶#structured-output#error-handling

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

  1. 这题是生产题，考的是「有没有见过模型抽风」。答「加个 try catch 重试三次」是新手答案，它没回答重试时发什么、也没回答最后怎么办。
  2. 拆法：分三层。校验层返回错误列表而不是布尔值；重试层把错误列表拼进用户消息，让模型知道上一次错在哪，原样重发大概率同样的错；降级层返回空值并记录，交调用方决定跳过还是人工处理。
  3. 重试次数：一次就够。两次以上还不对说明问题不在这条输入而在提示词或 schema，应该修模板而不是继续重试；每次重试都是一次完整调用的钱和延迟。
  4. 结论里最重要的一条：降级不要抛异常，也不要把「差一点」的结果凑合着用。抽取失败是正常业务分支；半对的结构化数据比没有数据更危险，因为下游会把它当真的。
  5. 追问方向：怎么区分「模型抽风」和「提示词有问题」？看失败率——偶发是抽风，某类输入稳定失败是提示词或 schema 缺覆盖，应该把那类输入加进测试集；另一个追问是重试会不会放大成本，答案是要有预算上限并监控重试率。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  答题要点

  • 三层：校验返回错误列表、带着错误原因重试一次、失败后返回空值并记录
  • 重试时必须把错误列表拼回用户消息，原样重发大概率同样的错
  • 重试一次足够，稳定失败说明模板或 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