第 1 周 · D5约 3 小时

跨模型迁移：Claude / GPT / 国产模型的差异、system prompt 组织；进入 Claude 课与 Codex 课

同一份提示词换一家模型为什么会坏、坏在哪几处，怎么把系统提示组织成可迁移的结构，以及接下来该学 Claude 课还是 Codex 课。

今日目标 0/3

能说出提示词跨模型迁移最常坏的四个地方，并各给一个修法
能把系统提示组织成分块结构，让厂商相关的部分独立可替换
能用迁移检查清单把一份提示词从一家模型搬到另一家并验证通过

登录后可以勾选并保存进度。

今日目标

能说出提示词跨模型迁移最常坏的四个地方，并各给一个修法
能把系统提示组织成分块结构，让厂商相关的部分独立可替换
能用迁移检查清单把一份提示词从一家模型搬到另一家并验证通过

这是本课的最后一天。前四天你手上这份提示词一直跑在同一家模型上；今天回答一个你迟早会遇到的问题——换一家模型，它为什么会坏、坏在哪、怎么搬得不痛。结尾还有一件事：这门课是三门免费入门课的第一门，学完之后该往哪走。读完正文、做完实验之后，回到页面顶部把三条目标勾掉。

小白版讲解

为什么同一张便签换个同事就办砸

你那张写了四天、打磨得很好的便签，原来是给同事甲的。甲休假，你把一模一样的便签给了同事乙。乙的能力不比甲差，但办出来的活不一样了：他把你用方框圈起来的「重点」当成了装饰没理会；你写「简要说明」他写了两页；你写「不要碰无关文件」他理解成「碰了也别告诉你」。便签没变，人变了——每个人对同一段话的默认理解不同。

模型之间的差别就是这个。同一份提示词在两家模型上表现不同，不是因为哪家更聪明，而是它们在训练时形成的「默认理解」不一样：对什么样的标记更敏感、对指令的执行有多字面、什么话题上更谨慎、回答习惯多长。这些差别在正常输入上几乎看不出来（两位同事办常规事都没问题），全暴露在边界和刁难输入上——正好是 D4 测试集里那六七条。所以跨模型迁移的第一条纪律，跟 D4 的结论是同一句话：搬完之后跑同一份测试集，通过率就是「有没有退步」的答案，比任何「感觉差不多」都可靠。

另一个要先说清的事实：迁移的绝大多数退步都不是模型能力差异，而是提示词里藏着只对某一家成立的默认。这些默认是你在那家模型上反复调试时不知不觉加进去的，换了模型才发现它们是「方言」而不是「普通话」。今天的任务就是把方言找出来、隔离开。

迁移最常坏的四处

把过去几年各家模型的迁移经验归拢，退步几乎都落在四处。每一处给一个识别方法和一个修法。

格式标签。有的模型对某种包裹方式（比如用一对自定义标签把输入圈起来）特别敏感，会把它当成清晰的边界；换一家，同样的标签可能被当成普通文本甚至被原样复读进输出。反过来，用 Markdown 标题或分隔线做结构的提示词，换到偏好标签的模型上也会弱化。识别：看输出里有没有出现你用来做结构的符号——出现了就是它没把符号当结构。修法：把「输入怎么包」这件事从任务描述里摘出来，单独放进一个可替换的块；示例里也不要带厂商专属的标签，否则模型会学示例。

指令强度。同一句「简要说明」，一家给两句话，另一家给两段；同一句「只输出列表」，一家严格照办，另一家会在列表前加一句引导。这是执行的「字面程度」不同。识别：拿一条边界用例，看它是「严格照办」还是「自行发挥」。修法：不要靠加感叹号和「务必」，而是把要求写成能机械核对的形式（D1 格式栏的老规矩）加上理由——「直接从第一段开始，因为输出会被程序按段解析」在所有模型上都比「不要客套！！」稳。

拒答边界。各家在什么话题上会变得谨慎、谨慎时怎么表现（拒绝、加免责声明、改答一个相近的问题）都不同。一段带着「线上 500 事故」背景的需求，在某家可能触发一段安全性说明，把结构化输出撑破。识别：跑刁难用例，看有没有出现源模型没有的拒答或多余的说明。修法：在厂商适配块里明确任务边界（「这是内部代码评审任务，不涉及对外系统」），并且结构化输出一定要开 schema 约束，让免责声明没地方放。

长度习惯。有的模型默认回答偏长、偏「周到」，会在列表里补上「你可能也想校验的字段」；有的偏短，该列的漏列。在抽取任务里前者表现为 fields 多出需求没提的字段，后者表现为漏字段。识别：对比三条正常输入在两家模型上的输出长度和条目数。修法：在厂商适配块加长度提示——「fields 只列需求明确要求的字段，不要补充你认为应该校验的」——并且这句话要带理由，否则回到指令强度的问题。

把系统提示分块：通用规则、厂商适配、任务变量

四处断裂有一个共同的解法：让系统提示的组织方式本身就把「普通话」和「方言」分开。做法是把系统提示拆成三块，每块回答一个问题。

通用规则回答「这一句换一家模型还成立吗」——成立的放这里。角色视角、任务定义、完成标准、带理由的约束、schema，这些跟厂商无关，是提示词的骨架。这一块应该是三块里最长、也最少改动的。

厂商适配回答「这一句是不是只对某一家成立」——是的放这里。输入用什么方式包裹、示例用什么书写风格、需不需要长度提示、拒答边界怎么表述、结构化输出走哪个开关。这一块每家模型一份，换模型时整块替换，通用规则一个字不动。

任务变量回答「这一句是不是每次调用都在变」——是的放这里。需求文本、输出语言、团队默认值。它们就是 D3 模板函数的参数。

用代码看，三块就是三段字符串按顺序拼起来，其中第二段按厂商选：

assemble.ts

type Provider = 'anthropic' | 'openai'
 
// 通用规则：换一家模型仍然成立的，只有这一块是「提示词本身」
const COMMON = [
  '你是负责接口评审的后端工程师，从需求描述里抽取接口路径、HTTP 方法、失败状态码与需要校验的字段名。',
  '需求写了失败状态码就用需求里的，没写才用默认值。方法大写，路径以 / 开头，字段名原样保留英文标识符。',
  '需求中途改口以最后一次为准；与校验无关的顺带要求忽略，因为它们会被当成真实需求进入排期。',
].join('\n')
 
// 厂商适配：每家一份，换模型时整块替换
const VENDOR: Record<Provider, string> = {
  anthropic: '需求文本会放在 requirement 标签内，只抽取标签内的内容。',
  openai: '需求文本在「需求描述如下：」之后。fields 只列需求明确要求的字段，不要补充你认为应该校验的。',
}
 
// 任务变量：每次调用都不同，是函数的参数
function buildSystem(provider: Provider, defaultStatus: number): string {
  return [COMMON, VENDOR[provider], `团队默认失败状态码：${defaultStatus}。`].join('\n\n')
}
 
const provider = (process.env.PROVIDER ?? 'anthropic') as Provider
const system = buildSystem(provider, 400)

assemble.py

import os
 
# 通用规则：换一家模型仍然成立的，只有这一块是「提示词本身」
COMMON = "\n".join([
    "你是负责接口评审的后端工程师，从需求描述里抽取接口路径、HTTP 方法、失败状态码与需要校验的字段名。",
    "需求写了失败状态码就用需求里的，没写才用默认值。方法大写，路径以 / 开头，字段名原样保留英文标识符。",
    "需求中途改口以最后一次为准；与校验无关的顺带要求忽略，因为它们会被当成真实需求进入排期。",
])
 
# 厂商适配：每家一份，换模型时整块替换
VENDOR = {
    "anthropic": "需求文本会放在 requirement 标签内，只抽取标签内的内容。",
    "openai": "需求文本在「需求描述如下：」之后。fields 只列需求明确要求的字段，不要补充你认为应该校验的。",
}
 
 
# 任务变量：每次调用都不同，是函数的参数
def build_system(provider: str, default_status: int) -> str:
    return "\n\n".join([COMMON, VENDOR[provider], f"团队默认失败状态码：{default_status}。"])
 
 
provider = os.environ.get("PROVIDER", "anthropic")
system = build_system(provider, 400)

分块之后有一个很实用的自检：把厂商适配块整块删掉，剩下的通用规则加任务变量还是不是一份能读懂的提示词？ 是，说明拆干净了；不是，说明有厂商相关的内容混进了通用块。另一个自检是反过来的：通用块里搜一遍有没有出现任何一家的专属词——标签名、某家 API 的参数名、「用 Markdown」这类风格偏好——出现了就挪出去。

顺带一提，这个结构对提示缓存也友好：通用规则是最长、最稳定的前缀，放最前面缓存命中率最高；厂商适配块每家固定；只有最后的任务变量在变。D1 讲系统提示要放稳定内容，到今天变成了三块的顺序。

国产模型的几个特点

国内很多团队的迁移目标是国产模型，或者反过来从国产模型搬到海外模型。除了上面四处通用的断裂，有几个特点值得单独知道，但要注意下面说的都是「常见情况」而不是定论——各家迭代很快，迁移前一定要用测试集实测而不是凭印象。

中文语感。多数国产模型在中文任务上的措辞更自然、对中文口语化需求（「todos 的创建接口」这类）的还原通常更稳，但在英文标识符的处理上偶尔会「顺手翻译」——把 dueDate 写成「截止日期」。修法还是 D3 那句：字段名原样保留英文标识符，枚举值不跟语言变。

上下文长度。各家支持的窗口差别很大，而且「支持」和「用满之后效果不掉」是两件事。如果你的提示词依赖很长的示例或很长的输入材料，迁移时要单独测长输入用例。

工具调用与结构化输出的成熟度。多数国产模型提供兼容 OpenAI 接口的调用方式，工具调用和 JSON 模式基本可用，但严格模式的 schema 支持、强制调用某个工具的语义、并行工具调用的行为各家不一。迁移时结构化输出这一项要按目标模型的文档重新确认开关怎么开，并且代码里的校验层不能省——D3 的三层兜底在这里是保险。

接口兼容不等于行为兼容。能用同一份 SDK 调通，只说明请求格式一样，不说明模型对提示词的理解一样。上面四处断裂在「接口兼容」的迁移里一样会出现，而且更容易被忽略，因为代码一行没改就跑通了。

迁移检查清单：搬之前、搬之后各查什么

把今天的内容压成一张可以照着做的清单，也就是今天实验要填的那份。搬之前在源模型上做五件事：系统提示拆成三块且厂商块可整块替换；格式要求全部写成可机械核对的形式；每条约束都带理由，没有光秃秃的否定式指令；示例的输出与格式栏逐字一致且不带厂商专属标签；D4 的测试集在源模型上跑过、通过率与失败用例记录在案——这一条是基线，没有它后面的验证没有意义。

搬之后在目标模型上做五件事：按目标模型的习惯改输入的包裹方式；对比三条正常输出的长度，必要时加长度提示；跑一条边界用例看指令是照办还是发挥；跑一条刁难用例看有没有新的拒答或多余说明；结构化输出的开关换成目标模型的方式，schema 本身不变。每一项都对应上面四处断裂里的一处，清单里有一列专门标着。

最后是验证：同一份测试集在目标模型上跑，通过率与失败用例和源模型并排。退步的用例逐条对四处断裂对号，改厂商适配块，再跑。达到与源模型相同的通过率、并且通用规则块一个字没改，迁移才算完成。

接下来学什么：Claude 课与 Codex 课怎么选

五天下来，你手上有一份四要素齐全、带示例与自检、输出结构化、有十条测试集与版本记录、能在两家模型间迁移的提示词。这套方法不依赖任何一家模型，也不依赖任何工具——它是「怎么跟模型说话」的通用功。

但真正干活时你不会每次都手写 API 调用。接下来的两门配套课程，讲的是用现成的工具把这套方法用起来，两门课逐天对位、示例任务与本课相同，你可以只选一门，也可以两门都学然后对比：

配套课程「Claude 高效使用：从对话到 Claude Code」（/learn/claude-mastery/day-01）：从 Claude 的对话技巧一路到 Claude Code——在终端里让它读你的代码库、按 CLAUDE.md 里的规范干活、用 hooks 和 skills 扩展它。适合你的日常工作以写代码为主、想让一个 Agent 直接在你的仓库里干活。它的 D1 不重讲四要素，直接指回本课。
配套课程「Codex 与 OpenAI Agents SDK 高效使用」（/learn/codex-mastery/day-01）：同一件活在 OpenAI 这边怎么做——Codex 的用法、Agents SDK 里 Agent 与 Runner 的最小骨架、handoff 与 guardrails。适合你的团队已经在用 OpenAI 的接口，或者你想对比两家的工具链再做选择。它的 D5 会用同一个示例任务做双工具实测对比。

选择的判据很简单：你接下来一个月最可能在哪个生态里写代码，就先学哪门。两门都是免费的，先学的那门会让你在第二门里跑得很快，因为对位的天数讲的是同一件事的另一种做法。往后的付费专题——MCP、Agent Skills、RAG、评估、安全——都建在这三门免费课的基础上，到时候你会发现今天这张「便签」的四要素、测试集与分块结构一直在被反复用到。

源码导读

动手实验

🧪 D5 实验：一份跨模型迁移检查清单

代码位置：labs/prompt-engineering-5days/day-05-migration-checklist

验收标准：

三块拆完，每块至少两条，通用规则块里没有任何一句提到具体厂商的格式或语气偏好。
「搬之前」五项全部填了通过或需改，需改的都有具体的修改记录。
「搬之后」五项全部填完，格式标签与长度习惯两项写的是实际观察到的现象。
验证栏填了目标模型的通过率与失败用例，并与源模型并排；退步的写出属于哪处断裂。
把清单给一位同学，他能在不看正文的情况下照着执行一遍。

今天是文档型实验，验证那一步复用 D4 的评估脚本。打开 labs/prompt-engineering-5days/day-05-migration-checklist：

通读 solution/migration-checklist.md，注意第二部分每一项右边的「对应差异」一栏，把它和正文的四处断裂对上。
在 starter/migration-checklist.md 的第一部分，把你 D1–D2 写好的示例任务提示词拆成通用规则、厂商适配、任务变量三块，做完两条自检。
填「搬之前」五项：对着自己的提示词逐项检查，需改的当场改，并写一句修改记录。
选一个目标模型，改厂商适配块，填「搬之后」五项，其中长度与指令强度两项要写你实际观察到的现象。
到 D4 实验的 solution/ 目录把 PROVIDER 换成目标模型跑一遍测试集（没有 key 就用 MOCK=1 走流程），把通过率与失败用例填进验证栏，退步的对四处断裂对号。

面试题

今天 3 道题在下方题库区，分别对应跨模型差异的来源、系统提示的分块组织、迁移后的验证方法。这三道题是本课的收官，答的时候把前四天的测试集、模板、schema 都串进来，面试官会看到一条完整的工程链路。

检查清单与明日预告

能说出提示词跨模型迁移最常坏的四个地方，并各给一个修法
能把系统提示组织成分块结构，让厂商相关的部分独立可替换
能用迁移检查清单把一份提示词从一家模型搬到另一家并验证通过
迁移检查清单的 5 条验收标准全部通过
3 道面试题不看要点也能答出至少 2 道
回头翻一遍五天的实验产物：四要素模板、五个改写对照、抽取脚本、测试集与变更记录、迁移清单——它们合起来就是你的第一份提示词工程作品集

这是本课的最后一天，没有明日预告，只有一个方向：按上一节的判据选一门配套课程——/learn/claude-mastery/day-01 或 /learn/codex-mastery/day-01——带着你这五天写好的提示词和测试集过去。两门课的第一天都会直接指回本课的 D1–D2，不重讲基础；你会发现自己已经比大多数直接上手工具的人多了一样东西：知道怎么判断工具到底干得好不好。

面试题库

同一份提示词从一家模型迁到另一家，最常坏在哪里？你怎么区分是提示词的问题还是模型能力的问题？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
分析过程 · 先想清楚再作答
这题在筛「有没有真的迁过」。没迁过的人会说「换个模型效果就差了」；迁过的人知道退步几乎都落在四处，而且多数不是能力差异。
拆法：四处断裂各配一个识别方法。格式标签——看输出里有没有出现你用来做结构的符号；指令强度——跑边界用例看是照办还是发挥；拒答边界——跑刁难用例看有没有新的拒答或多余说明；长度习惯——对比正常输入的输出长度与条目数。
区分提示词问题与能力问题：先看失败用例的字段能不能对上四处之一，能对上就改厂商适配块；对不上再看失败的是正常用例还是边界用例——能力差异通常在正常用例上也会体现，而边界用例上的退步几乎都是提示词里藏着只对某一家成立的默认。
结论：迁移退步十有九是「方言」没隔离，改厂商适配块就能恢复；真正的能力差异少见且会在正常用例上现形。
可预期的追问：接口兼容（同一份 SDK 调通）是不是就不用管了？不是——接口兼容只说明请求格式一样，四处断裂照样出现，而且更容易被忽略。
How to reason about it · think before answering
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.
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.
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.
Conclusion: nine out of ten regressions are unisolated 'dialect' fixed in the vendor block; genuine capability gaps are rare and surface on normal cases.
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
分析过程 · 先想清楚再作答
这题看似问结构，实际在考「有没有维护过多家模型共用的一份提示词」。答「写清楚一点就能通用」的人没维护过；维护过的人会先说分块。
拆法：三块各回答一个问题。通用规则——这一句换一家模型还成立吗，成立放这里（角色、任务、完成标准、带理由的约束、schema）；厂商适配——这一句是不是只对某一家成立，是的放这里（输入包裹方式、示例风格、长度提示、拒答边界表述、结构化输出开关），每家一份整块替换；任务变量——每次调用都在变吗，是的做成参数。
两条自检是区分度：把厂商块整块删掉，剩下的还是不是一份能读懂的提示词；通用块里搜有没有任何一家的专属词（标签名、API 参数名、风格偏好）。
结论：分块的收益不只是迁移——通用块是最长最稳定的前缀，放最前面缓存命中最高；厂商块每家固定；任务变量放最后。这跟 D1 讲系统提示要放稳定内容是同一条原则的延伸。
追问：few-shot 示例算哪一块？示例的内容属于通用规则，示例的书写风格（包裹标签、代码块风格）属于厂商适配，所以示例最好也拆成「内容 + 渲染」两层，或者至少不带厂商专属标签。
How to reason about it · think before answering
It looks structural but tests whether you have maintained one prompt across vendors. 'Just write it clearly' means no; experienced people start with blocks.
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.
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.
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.
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
分析过程 · 先想清楚再作答
这题是 D4 与 D5 的合题，考的是「验证有没有流程」。答「多跑几条看看」是最低分；面试官要听的是基线、同一批用例、逐字段对号。
拆法：验证的前提是基线——迁移前在源模型上跑过同一份测试集并记录通过率与失败用例；没有基线就没有「退步」可言。迁移后用完全相同的用例在目标模型上跑，两列并排。
排查顺序：先看失败用例是正常还是边界——边界优先怀疑提示词；再把失败字段对四处断裂对号，改厂商适配块，通用块不动；再跑一遍；仍失败的用例看是否与源模型的失败重合——重合的是提示词自身的已知回退，与迁移无关，按 D4 的变更记录处理。
结论：达到与源模型相同的通过率、且通用规则块一个字没改，迁移才算完成；改了通用块就等于改了提示词版本，要重新在源模型上跑。
追问：真模型有随机性，一次运行的通过率能信吗？每条跑三次取多数或温度设 0；另一个追问是要不要在两家上长期并跑，答案是至少保留一段时间的双跑对比，因为模型版本更新会让通过率漂移，测试集是唯一能及时发现漂移的工具。
How to reason about it · think before answering
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.
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.
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.
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.
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

登录后即可参与讨论

还没有评论，来说第一句。