面试题库

5 天提示词工程零基础

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
• 迁移之后怎么验证效果没有退步？如果通过率降了，你的排查顺序是什么？After migrating a prompt, how do you verify nothing regressed, and if the pass rate drops, what is your debugging order?

  国内高频海外高频深入#model-migration#evaluation

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

  1. 这题是 D4 与 D5 的合题，考的是「验证有没有流程」。答「多跑几条看看」是最低分；面试官要听的是基线、同一批用例、逐字段对号。
  2. 拆法：验证的前提是基线——迁移前在源模型上跑过同一份测试集并记录通过率与失败用例；没有基线就没有「退步」可言。迁移后用完全相同的用例在目标模型上跑，两列并排。
  3. 排查顺序：先看失败用例是正常还是边界——边界优先怀疑提示词；再把失败字段对四处断裂对号，改厂商适配块，通用块不动；再跑一遍；仍失败的用例看是否与源模型的失败重合——重合的是提示词自身的已知回退，与迁移无关，按 D4 的变更记录处理。
  4. 结论：达到与源模型相同的通过率、且通用规则块一个字没改，迁移才算完成；改了通用块就等于改了提示词版本，要重新在源模型上跑。
  5. 追问：真模型有随机性，一次运行的通过率能信吗？每条跑三次取多数或温度设 0；另一个追问是要不要在两家上长期并跑，答案是至少保留一段时间的双跑对比，因为模型版本更新会让通过率漂移，测试集是唯一能及时发现漂移的工具。

  How to reason about it · think before answering

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

  答题要点

  • 验证前提是基线：迁移前在源模型跑过同一份测试集
  • 同一批用例在目标模型上跑，两列并排看通过率与失败用例
  • 排查顺序：正常还是边界 → 失败字段对四处断裂 → 改厂商块不动通用块 → 重跑 → 与源模型重合的失败是已知回退
  • 通用块改了就是新版本，要回源模型重跑；随机性用多次取多数或温度 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