Interview Bank

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.

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

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. The real question is the second half. Answering only use JSON mode signals you have never run this in production, because all the work happens after validation fails.
2. Lay out three paths: prompt constraints plus local validation; a vendor's JSON mode or structured-output parameter; or defining the data structure as a tool's parameter schema. Vendor support and field names differ, so the latter two bind that code to one vendor.
3. State the selection rule: cross-vendor or offline-capable means path one, paying with your own JSON extraction and validator; single-vendor and success-rate-driven means use their structured output. Extraction must handle code fences and surrounding chatter — parsing the whole reply directly breaks often.
4. Handle failure as a ladder, not just a retry: feed the path-annotated issues back and ask it to fix only those (more effective than upgrading the model); then degrade to a minimal required-fields-only structure; then fail the round and persist the artifact for a human — never swallow the error and return an empty array.
5. High-signal point: validate in two layers. Type and range checks catch malformed data but not wrong references — a nonexistent scene id or a duplicate shot number passes typing and explodes downstream. Referential integrity needs its own pass.
6. Likely follow-up: how many retries? Two. The first covers a disobedient model; if it still fails with concrete issues in hand, the prompt or the schema itself is wrong and more retries just buy the same error.

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

1. 这题的题眼在后半句。前半句答「用 JSON 模式」就结束的人，等于说自己没在生产里跑过——真正的活儿全在校验失败之后。
2. 先把三条路摆开：提示词约束加本地校验；厂商提供的 JSON 模式或结构化输出参数；把数据结构定义成工具的参数 schema 让模型去调。各家对后两条的支持程度和字段名都不一样，选它就等于把这段代码绑在某一家上。
3. 给出选择依据：要跨厂商、要能离线跑，就选第一条，代价是自己写抠 JSON 与校验；只服务一家且追求成功率，就用那一家的结构化输出。抠 JSON 这一步必须处理围栏与前后寒暄，直接解析整段回复在真实模型上很容易炸。
4. 校验失败的处理是一条阶梯，别只答重试：把带路径的问题原样喂回去让它只修这些（比换更大的模型有效）；仍不过就降级到只要必填字段的最小结构；再不过就整轮失败并留档，让人来看，而不是吞掉异常返回一个空数组。
5. 还有一条区分度很高：校验要分两层。判类型与范围只能挡住格式错，挡不住写错对象——引用了不存在的场景 id、镜号重复，这类稿子能通过类型检查，然后在下游某一步才爆。引用完整性必须单独查一遍。
6. 可预期的追问：重试几次合适？两次。第一次是模型没听话，第二次带着具体问题还改不对，说明是提示词或 schema 本身有问题，再重试只是花钱买同一个错误。