面试题库

5 天提示词工程零基础

D1 提示词是什么、不是什么：模型如何读指令；角色 / 任务 / 格式 / 约束四要素

• 角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？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?

  国内高频海外高频进阶#prompt-basics#four-elements

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

  1. 前半句是送分，后半句才有区分度：它在考你是否知道每个要素对应模型的哪一种「猜」，以及哪种猜错的代价最小。
  2. 拆法：把每个要素映射到一个「模型会猜错的地方」——角色对应视角与关注点，任务对应终点在哪，格式对应输出能否被程序消费，约束对应改动范围与不可碰的边界。
  3. 判断哪个可砍：看缺了之后是「结果不稳定」还是「结果不可用」。缺角色多半是关注点偏了但仍可用；缺任务的完成标准会让模型不知何时停；缺格式会让下游解析失败；缺约束会让改动面失控。
  4. 结论：多数工程场景下角色最可砍，因为任务与格式写得足够具体时视角已经被隐含；但要说明前提是任务里已经写清了关注点。
  5. 追问几乎必然是「那为什么大家还都写角色」——答案是它便宜且能一句话压缩大量隐性偏好，在任务没法写得很细的对话场景里性价比最高。

  How to reason about it · think before answering

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

  国内高频海外高频进阶#system-prompt#prompt-basics

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

  1. 题眼在「三个角度」和「做不到什么」。只答「系统提示权重高」是背概念，面试官要看的是你有没有在生产里拼过系统提示。
  2. 拆法：遵从度看多轮稀释——用户消息会被后续对话淹没，系统提示全程生效；管控看谁能改——系统提示由后端统一拼装、用户碰不到，规则放这里才能对所有用户一致；成本看缓存——提示缓存按前缀命中，系统提示是最稳定的前缀。
  3. 「做不到什么」是区分度所在：系统提示遵从度高不等于绝对，提示注入可以让模型跑偏，所以安全边界不能只靠系统提示，要在模型外用代码兜底。
  4. 结论：规则进系统提示是为了稳定、一致、省钱；但它是「强建议」不是「硬约束」，硬约束必须在代码层实现。
  5. 追问方向：系统提示可以放在对话末尾吗？可以但不推荐——多数模型对靠前指令更敏感，且会破坏缓存前缀；另一个追问是「哪些内容不该进系统提示」，答案是每次都变的任务细节，放进去会让缓存失效且难以复用。

  How to reason about it · think before answering

  1. The tell is whether you cover all three angles and name a limitation. 'System prompts carry more weight' alone reads as memorized.
  2. 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.
  3. 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.
  4. Conclusion: rules go in the system prompt for stability, consistency and cost, but it is a strong suggestion, not a hard constraint.
  5. 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、思维链、分步与自检；什么时候这些都不管用

• 思维链在什么任务上提升明显，在什么任务上是浪费？它和「分步」有什么区别？Where does chain-of-thought prompting help most, where is it a waste, and how does it differ from splitting a task into steps?

  国内高频海外高频进阶#chain-of-thought#prompt-techniques

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

  1. 题眼在「浪费」和「区别」。只会说「让模型先思考再回答效果更好」的候选人没有算过账，面试官想听的是你什么时候会主动不用它。
  2. 拆法：思维链的价值来自「中间结果可以校验下一步」，所以它在多步推理、算术、需要排除干扰项的判断上提升明显；在单步判断（分类、抽取、格式转换）上几乎没有增益，只有更慢更贵更长的输出。
  3. 区别：思维链是一次调用内让模型写出中间过程，输出预算还是同一份；分步是拆成多次调用，每步有独立的预算、独立的格式、并且后一步可以拿前一步的输出做输入。任务是「想得不够细」用思维链，任务是「一次装不下」用分步。
  4. 结论：先问任务是否需要多步推理，不需要就不用；需要的话再问一次输出装不装得下，装得下用思维链，装不下拆步。
  5. 追问：推理类模型内置了思考过程，还要写思维链吗？多数情况不用再写「一步步想」，但仍要指定最终答案的格式与位置，否则解析会很痛苦；另一个追问是思维链的内容能不能信，答案是它是「看起来合理的过程」而非真实的内部计算，只能当辅助校验不能当证据。

  How to reason about it · think before answering

  1. The discriminators are 'waste' and 'difference'. Anyone can say thinking first helps; the interviewer wants to hear when you deliberately skip it.
  2. 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.
  3. 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.
  4. 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.
  5. 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?

  国内高频海外高频进阶#prompt-limits#failure-modes

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

  1. 这题考的是「知道提示词的边界在哪」。一直往提示词上堆技巧的候选人会被判为缺乏判断力；能说出「这题不该用提示词解」才是成熟的信号。
  2. 拆法：把失效分三类。缺知识——信息在模型训练截止之后或本来就在你的私有数据里，模型不可能知道，还可能编出格式正确的假答案；缺工具——任务需要对外部世界做动作或查询（跑命令、查库、发请求），文字生成做不到；任务写错——需求本身自相矛盾或者你要的其实是另一件事。
  3. 每类给一个判据：缺知识问「这信息是昨天才出现的，模型有可能知道吗」；缺工具问「一个只能打字的人能完成这件事吗」；任务写错问「两个人读这个需求会不会得出相反的做法」。
  4. 结论：缺知识就把资料贴进上下文或接检索；缺工具就接工具调用或在代码里做完再让模型解读；任务写错回去改需求。三种都不是提示词层面的解法。
  5. 追问几乎必然是「格式越严格假答案越像真的怎么办」——答案是对事实类输出要求带出处或可验证的标识，并在代码里校验；以及「怎么在评估里提前发现这类任务」，答案是测试集里放几条模型不可能知道的样本，看它是否老实说不知道。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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 结构化输出：JSON schema、模板与变量、多语言输出

• 提示词模板里哪些内容该做成变量，哪些该写死？变量多了会有什么问题？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

D4 迭代与评估：小样本测试集、A/B、版本管理、常见反模式

• 提示词版本化怎么做？它和代码版本管理有什么不同？线上出问题你先做什么？How do you version prompts? How does it differ from versioning code, and what is your first move when production misbehaves?

  国内高频海外高频进阶#prompt-versioning#evaluation

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

  1. 这题是海外面试里提示词工程方向出现频率最高的一道，考的是「有没有把提示词当成生产资产管理过」。答「放进 git」是最低分，面试官要听的是变更记录里写什么、以及为什么和代码不一样。
  2. 拆法：先说形态——提示词正文独立成文件、每版有 id、与业务代码解耦；再说变更记录四件事——改了什么、为什么改（对应哪几条测试失败）、跑出来的通过率、已知回退。通过率必须是脚本跑出来的数字。
  3. 不同点是区分度所在：代码改动通常是局部的，提示词改动是全局的——加一句话可能改变所有输入的行为，所以「已知回退」是必填项而代码提交信息里没有这一栏；另一点是回滚成本几乎为零，只是换一个字符串。
  4. 结论：线上出问题第一步是回滚到上一版，再拿触发问题的输入补进测试集慢慢查——前提是你有版本号可回、有测试集可跑。
  5. 追问：提示词版本要不要和模型版本绑定？要——同一份提示词在不同模型版本上通过率会变，记录里要写清是在哪个模型上测的；另一个追问是多环境怎么灰度，答案是按版本 id 分流并对比两版的线上指标，跟代码灰度一样。

  How to reason about it · think before answering

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

  答题要点

  • 提示词正文独立成文件、每版有 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
• 用模型给模型打分靠谱吗？什么时候可以用，什么时候必须人工看？Is using a model to grade another model's output reliable? When is it acceptable, and when must a human look?

  国内高频海外高频进阶#evaluation#llm-as-judge

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

  1. 这题在考「知道裁判也会错」。答「用更强的模型当裁判就行」的人没校准过裁判；答出「能用字段比对就不用裁判」才说明有判断力。
  2. 拆法：先分任务。输出是固定字段就用代码逐字段比对，不需要裁判；输出是自由文本（摘要、邮件、解释）才没有字段可比，这时裁判是唯一能规模化的办法。
  3. 再说裁判的偏差：偏向长的、格式漂亮的、和自己风格接近的回答；评分标准含糊时打分随意；对事实性错误不敏感。所以评分标准要像便签一样具体——列出信息点、每点一分——而不是「给这段摘要打 1 到 10 分」。
  4. 结论：裁判可以用，前提是先拿十条人工打过分的样本校准它，看它和人的一致率；上线后定期抽样复核；对涉及事实、安全、金额的输出必须人工看。
  5. 追问方向：裁判和被评的模型是同一家会怎样？会有自我偏好，尽量换一家或至少换一个版本；另一个追问是「裁判的成本」，每条评估都是一次完整调用，测试集大了要算钱，所以能用代码判的部分先用代码判掉。

  How to reason about it · think before answering

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

  答题要点

  • 能用字段比对就不用裁判；裁判只用于没有字段可比的自由文本
  • 裁判偏向长的、格式漂亮的回答，评分标准含糊就打得随意，所以标准要具体到信息点
  • 先用十条人工打分样本校准裁判，上线后定期抽样复核
  • 涉及事实、安全、金额的输出必须人工看；裁判尽量换一家或换版本以避免自我偏好

  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 跨模型迁移：Claude / GPT / 国产模型的差异、system prompt 组织；进入 Claude 课与 Codex 课

• 同一份提示词从一家模型迁到另一家，最常坏在哪里？你怎么区分是提示词的问题还是模型能力的问题？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?

  国内高频海外高频进阶#model-migration#cross-model

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

  1. 这题在筛「有没有真的迁过」。没迁过的人会说「换个模型效果就差了」；迁过的人知道退步几乎都落在四处，而且多数不是能力差异。
  2. 拆法：四处断裂各配一个识别方法。格式标签——看输出里有没有出现你用来做结构的符号；指令强度——跑边界用例看是照办还是发挥；拒答边界——跑刁难用例看有没有新的拒答或多余说明；长度习惯——对比正常输入的输出长度与条目数。
  3. 区分提示词问题与能力问题：先看失败用例的字段能不能对上四处之一，能对上就改厂商适配块；对不上再看失败的是正常用例还是边界用例——能力差异通常在正常用例上也会体现，而边界用例上的退步几乎都是提示词里藏着只对某一家成立的默认。
  4. 结论：迁移退步十有九是「方言」没隔离，改厂商适配块就能恢复；真正的能力差异少见且会在正常用例上现形。
  5. 可预期的追问：接口兼容（同一份 SDK 调通）是不是就不用管了？不是——接口兼容只说明请求格式一样，四处断裂照样出现，而且更容易被忽略。

  How to reason about it · think before answering

  1. 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.
  2. 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.
  3. 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.
  4. Conclusion: nine out of ten regressions are unisolated 'dialect' fixed in the vendor block; genuine capability gaps are rare and surface on normal cases.
  5. 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.

  答题要点

  • 四处最常坏：格式标签、指令强度、拒答边界、长度习惯，各有识别方法
  • 先把失败字段对四处对号，对上就改厂商适配块
  • 能力差异会在正常用例上现形；只在边界用例上退步几乎都是提示词的方言
  • 接口兼容不等于行为兼容，代码没改也要跑测试集

  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?

  国内高频海外高频进阶#system-prompt#model-migration

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

  1. 这题看似问结构，实际在考「有没有维护过多家模型共用的一份提示词」。答「写清楚一点就能通用」的人没维护过；维护过的人会先说分块。
  2. 拆法：三块各回答一个问题。通用规则——这一句换一家模型还成立吗，成立放这里（角色、任务、完成标准、带理由的约束、schema）；厂商适配——这一句是不是只对某一家成立，是的放这里（输入包裹方式、示例风格、长度提示、拒答边界表述、结构化输出开关），每家一份整块替换；任务变量——每次调用都在变吗，是的做成参数。
  3. 两条自检是区分度：把厂商块整块删掉，剩下的还是不是一份能读懂的提示词；通用块里搜有没有任何一家的专属词（标签名、API 参数名、风格偏好）。
  4. 结论：分块的收益不只是迁移——通用块是最长最稳定的前缀，放最前面缓存命中最高；厂商块每家固定；任务变量放最后。这跟 D1 讲系统提示要放稳定内容是同一条原则的延伸。
  5. 追问：few-shot 示例算哪一块？示例的内容属于通用规则，示例的书写风格（包裹标签、代码块风格）属于厂商适配，所以示例最好也拆成「内容 + 渲染」两层，或者至少不带厂商专属标签。

  How to reason about it · think before answering

  1. It looks structural but tests whether you have maintained one prompt across vendors. 'Just write it clearly' means no; experienced people start with blocks.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

  答题要点

  • 三块：通用规则（换模型仍成立）、厂商适配（每家一份整块替换）、任务变量（每次调用的参数）
  • 判据是两个问题：换一家还成立吗；每次调用都在变吗
  • 自检：删掉厂商块剩下的仍可读；通用块里没有任何一家的专属词
  • 顺序通用、厂商、变量，最稳定的前缀在前，缓存命中最高

  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