面试题库

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

1. 这题最容易答成「结构化更规范、更好解析」——这是形容词，不是理由。面试官想听的是一个具体的失败场景，最好是你真的调过的那种。
2. 把最锋利的一刀先亮出来：**自然语言路由的失败是静默的**。模型回「我觉得这个可以让查订单的同事看一下」，它其实判对了，但说的是人话不是 id，正则匹配不上就落进兜底，日志里只留下一个 smalltalk。模型是对的、解析是错的，而它和「模型判错了」在日志里长得一模一样。你会去调提示词，调两天才发现问题在那三行正则。
3. 然后给三个漏洞，一条一条对上结构化输出解决了什么：输出会漂移（今天回「订单查询」明天回「查订单」，正则永远追不上，模型小版本升级你就掉准确率）；没有置信度（自然语言里没有「我有多大把握」这个信息，你没法区分它很确定还是在猜）；拼错或自造的路由名要到运行时才炸（枚举是一道编译期就存在的闸门）。
4. 接着说清机制，别停在「用 zod 更规范」：把 schema 发进请求（response_format 里的 json_schema），模型的解码过程被枚举约束；回来之后**用同一份声明再校验一遍**。一份声明两用，请求与校验不会漂移。
5. 关键的反直觉点，答到这里就拉开差距了：**结构化输出不等于不用校验**。不是所有网关、所有模型都严格执行 schema，降级到备用模型时更说不准。所以解析函数的返回类型应该是「一段待校验的东西」，而不是「已经是 RouteDecision」。
6. 可以预期的追问：那不支持 json_schema 的模型怎么办？答案是退回「few-shot 加严格提示词加自己校验」，闸门仍然在你的枚举校验那一步——真正兜底的从来不是模型的自觉，是你的解析层。

How to reason about it · think before answering

1. The trap is answering structured output is cleaner and easier to parse. Those are adjectives, not reasons. The interviewer wants a concrete failure you have actually debugged.
2. Lead with the sharpest point: free-text routing fails silently. The model replies I think the order desk should look at this — it judged correctly, but it spoke prose, not an id. Your regex misses, you fall through to the default, and the log shows only smalltalk. A correct model with a broken parser looks exactly like a wrong model, so you spend two days tuning a prompt that was never the problem.
3. Then list three holes and map each to what structured output fixes: wording drifts across versions so regexes never catch up; there is no confidence signal, so you cannot tell certainty from guessing; and an invented route name only explodes at runtime, whereas an enum is a gate that exists before the request is even sent.
4. Explain the mechanism rather than stopping at zod is nicer: send the schema in the request (response_format with a json_schema), so decoding is constrained by the enum, then validate the response with the same declaration. One declaration used twice means request and validation cannot drift apart.
5. The counterintuitive point that separates candidates: structured output does not remove the need to validate. Not every gateway or model enforces the schema strictly, and a fallback model may not at all. Your parse function should return something-to-be-validated, not an already-typed decision.
6. Expect: what if the model does not support json_schema? Fall back to few-shot plus a strict prompt plus your own validation. The real gate was never the model's discipline; it is your parsing layer.

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

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.

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

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.

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

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.

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

1. 这题考取舍，判据是「谁消费输出」和「错误的代价」。答「都用」或「看情况」没有信息量，要给出可执行的判断句。
2. 推导链：分析段是输出 token，按输出价计费，且会让响应变长；它换来的是复杂任务上更高的准确率与可核对的推理过程。所以任务越复杂、错误代价越高、越需要人审计，越该要分析段；批量、简单、程序直接消费的任务，直接要结构化输出。
3. 「能不能同时要」：一旦传了 JSON Schema，输出被约束成 JSON，自由文本的分析段没地方放。两条路：在 schema 里加一个 reasoning 字段放在其他字段前面（模型会先生成它），或者依赖模型内部的 thinking——它是内部推理，你控制深度不控制内容。
4. 生产视角：结构化输出解决的是「解析可靠性」，不是「判断正确性」；schema 不支持数值范围与字符串长度约束，这些校验要自己补。
5. 可预期的追问：分析段会不会被程序误用？会，所以要用标签把分析段与答案段分开，程序只取答案段；另一个追问是 thinking 与分析段的区别——一个内部一个外显，一个控深度一个控内容。

How to reason about it · think before answering

1. This is a trade-off question; the criteria are who consumes the output and what an error costs. Give a decision rule, not 'it depends'.
2. Chain: the analysis is output tokens, billed at output rates and adding latency, in exchange for higher accuracy on complex tasks and an auditable trace. The more complex, high-stakes, or human-reviewed the task, the more you want it; bulk, simple, machine-consumed tasks go straight to structured output.
3. Can you have both? Once a JSON schema is passed the output is constrained to JSON, so free-text analysis has nowhere to go. Two options: add a reasoning field placed before the other fields, or rely on the model's internal thinking, whose depth you control but not its content.
4. Production nuance: structured output fixes parsing reliability, not judgment quality; the schema cannot express numeric ranges or string lengths, so validate those yourself.
5. Follow-ups: can the analysis leak into downstream code? Yes — separate analysis and answer with tags and parse only the answer. Thinking versus a written analysis: internal versus visible, depth versus content.

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

1. 这题考的是对「格式正确」与「内容正确」的区分，答成「有了 strict 就不用校验了」是典型的错误。
2. 先说解决了什么：strict 加 json_schema 保证输出一定能通过 schema 校验——枚举只会是给定值、必填字段一定在、类型不会错，解析层的 try/catch 与重试基本可以删掉。
3. 再说没解决什么：schema 管不了语义。verdict 一定是两个枚举之一，但判断可能是错的；数字一定是数字，但可能是编的。业务层校验一行不能省。
4. 然后是拒答分支：模型因安全原因拒绝时返回 refusal 类型的内容块，而不是硬塞一个不合法的 JSON；不处理它，下游会拿到空的解析结果直接崩，处理了才能区分「不愿意」与「没做对」。
5. 给出代码里的顺序：先查 refusal，再读 output_parsed，再做业务校验（范围、引用是否存在、与上下文是否一致），最后才落库或执行。
6. 可预期的追问：strict 对 schema 有什么限制？每个对象都要 additionalProperties 为 false、字段都要在 required 里，可选字段用可空类型表达；这些限制正是它能给出保证的原因。

How to reason about it · think before answering

1. This tests the distinction between well-formed and correct; claiming strict mode removes the need for validation is the classic mistake.
2. What it solves: strict plus json_schema guarantees the output validates against the schema, so enums are always allowed values, required fields exist and types are right; parsing-layer try/catch and retries can largely go.
3. What it does not solve: semantics. The verdict is one of two enums but may be wrong; a number is a number but may be invented. Business validation stays.
4. Then refusals: a safety refusal comes back as a refusal content block, not malformed JSON; unhandled, downstream code crashes on an empty parse, handled, you can separate unwilling from incorrect.
5. Give the order in code: check refusal, read output_parsed, run business checks (ranges, referenced entities exist, consistency with context), then persist or act.
6. Expect the follow-up: schema restrictions under strict? Every object needs additionalProperties false and all fields in required, optional fields become nullable; these constraints are exactly what makes the guarantee possible.

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

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

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.