前段时间一个在 AI 应用创业公司做了三年半 Prompt 工程师的朋友找我。他刚升了 Senior Prompt Engineer——title 升了，管的范围从一条产品线的 Prompt 扩展到全公司三个产品线的 Prompt 架构。他说他想跳槽去一家大厂的 AI 平台部门——「现在的公司 Prompt 工程的天花板我摸到了，我想去一个需要设计 Prompt 系统而不是写 Prompt 的地方」。投了两个月，面了四家——两家挂在二面、一家在终面之后被养鱼、还有一家直接说「你的经验更像高级初级岗，不是我们找的中级架构岗」。
他把简历发给我。核心工作经历第一条长这样：
负责公司三个产品线的 Prompt 设计与优化。独立设计 AI 客服、AI 销售助手、AI 数据分析三条产品线的 System Prompt 和任务 Prompt 体系。运用 Few-shot、Chain-of-Thought、ReAct、Self-Consistency 等提示工程技术提升模型输出质量。建立 Prompt 效果评估机制，通过人工标注+自动指标监控 Prompt 质量。完成 GPT-4、Claude、Gemini 等多个主流模型的 Prompt 适配与效果对比。编写 Prompt 设计规范和最佳实践文档。Prompt 整体准确率提升至 90% 以上。
这段话放在任何一个做了三年 Prompt 工程师的人身上都不违和。三条产品线、五种 Prompt 技术、三个模型——关键词覆盖率堪称 Prompt 工程师简历模板大全。但面试官看完，脑子里只有一个问题：这个人的简历，跟两年前他还是初级 Prompt 工程师的时候，除了产品线变多了、模型变多了、技术名词变多了——本质上有什么不同？
他做初级的时候写「负责 AI 客服 Prompt 设计、运用 Few-shot/CoT 技术、准确率 85% 以上」。现在做 Senior 了写「负责三条产品线 Prompt 体系、运用 Few-shot/CoT/ReAct/Self-Consistency、准确率 90% 以上」。这不叫职业成长——这叫「同一份工作内容在更多的产品线上复制粘贴」。
中级 Prompt 工程师简历最致命的坑：你把一份需要 Prompt 系统架构设计能力、跨模型评估体系建设能力、Few-shot 策略工程化能力、多模型行为适配能力的综合岗位，写成了一份「初级 Prompt 工程师 Pro Max 版」的流水账。
先搞清楚：中级 Prompt 工程师的简历要证明什么
在拆具体怎么写之前，先对齐面试官的预期。中级 Prompt 工程师——工作经验通常在 2-5 年——面试官默认你已经能独立搞定单条 Prompt 的编写、诊断、迭代和评估（这些是你做初级时已经证明过的）。面试官真正在你的简历里找的是以下四样东西：
第一，你有没有设计过「Prompt 系统」而不只是「写过 Prompt」。 初级 Prompt 工程师的工作是「这个场景需要一个意图识别 Prompt——我写一个」。中级 Prompt 工程师的系统设计是：你有没有面对过一个「单条 Prompt 搞不定」的复杂场景——比如用户的一句话需要同时做意图识别、情绪分析、关键信息抽取、合规检查——然后你不是把它塞进一个超长的 System Prompt 里，而是设计了一套多 Prompt 协作架构：拆成几个子 Prompt、定义它们之间的调用顺序（串行还是并行？）、设计了路由规则（什么条件下用哪个 Prompt？什么条件下需要多个 Prompt 的结果交叉验证？）、定义了子 Prompt 之间的信息传递协议（上游输出什么格式给下游？下游发现上游可能判错了怎么办？）。面试官想看的是：这套 Prompt 系统的效果是不是单条 Prompt 永远达不到的？
第二，你有没有建过「跨模型的评估体系」而不只是「建了几个评估指标」。 初级 Prompt 工程师评估 Prompt 是「在 GPT-4 上跑 200 条测试集，看准确率」。中级 Prompt 工程师的评估体系是：当你需要把一个在 GPT-4 上跑得很稳的 Prompt 迁移到 Claude 上时——你怎么判断迁移后的 Prompt 质量？你有没有发现过「整体准确率从 92% 到 91%——看起来差不多，但拆开看某个子类别的召回率从 87% 跌到了 61%，因为 Claude 对这个类别的语义理解方式跟 GPT-4 不一样」这种跨模型的隐性退化？你有没有因为一套跨模型评估体系而成功拦截过一次「看起来没问题、实际上在某个模型上已经悄悄崩了」的 Prompt 上线？
第三，你有没有把 Few-shot 从「手艺」做成「工程」？ 初级 Prompt 工程师用 Few-shot 是「我挑了 5 个例子放进去」。中级 Prompt 工程师的 Few-shot 策略是：你有没有面对过「同一个 Prompt 模板要给三个不同行业的客户用——每个行业的示例应该不一样」的场景？你是给每个行业手动挑了一组示例——还是设计了一套「根据输入自动检索最相关示例」的动态 Few-shot 机制？你有没有为团队写过一份 Few-shot 选例标准——不只是「选有代表性的例子」这种正确的废话，而是「选例四原则：覆盖边界case优先于覆盖典型case、示例之间不能有互相矛盾的推理模式、示例的格式必须跟目标输出格式完全一致、示例数量从 3 个开始往上加、每加一个做一次 A/B 测试」？
第四，你有没有做过「多模型适配」而不只是「对比过几个模型」？ 这是中级 Prompt 工程师最有辨识度的能力。面试官想看的是：你有没有同时维护过同一套业务逻辑在 GPT-4、Claude、Gemini 三个模型上的 Prompt？你有没有踩过「同一条 Prompt——GPT-4 输出纯 JSON 没问题、Claude 前面老加一句'好的，根据您的需求……'、Gemini 偶尔把字段名的下划线写成驼峰」这种坑？你做了什么适配策略——是给每个模型各写一套独立 Prompt（维护三套——噩梦），还是设计了一套「模型感知的自适应 Prompt 模板」（一个模板+模型行为配置文件）？你有没有量过适配后的跨模型行为一致性？
带着这四个问题，下面从四个维度一个一个拆。
一、Prompt 系统设计：别写「负责 XX 场景 Prompt 开发」，写你设计的那套多 Prompt 协作系统——以及为什么单条 Prompt 搞不定那个场景
Prompt 系统设计是中级 Prompt 工程师简历里最能跟初级拉开差距的板块。初级开发可以写「负责客服意图识别 Prompt 设计、运用 CoT 技术、准确率 92%」——十个初级九个这么写。但面试官想看的是：你有没有面对过一个「单条 Prompt 怎么改准确率都突破不了 85%」的顽固场景——然后你没有继续在单条 Prompt 上加指令，而是重新设计了整个方案架构？
改前案例
负责 AI 销售助手产品线的 Prompt 设计与优化。设计销售对话 System Prompt 和 Follow-up 建议生成 Prompt。运用 CoT 让模型先分析客户意向再生成跟进建议。通过 Few-shot 示例规范输出格式和话术风格。持续优化 Prompt，模型生成的跟进建议采纳率从 61% 提升至 78%。与后端配合完成 Prompt 与 CRM 系统的数据对接。
面试官看完：你写了两条 Prompt、用了 CoT 和 Few-shot、采纳率从 61% 提到了 78%。但面试官不知道——61% 到 78% 的瓶颈卡在哪里？78% 之后为什么没继续往上提——是因为单条 Prompt 的天花板到了吗？你试过别的架构吗——还是从头到尾就是一条 Prompt 在硬撑？
改后案例
我在上一家公司真正从「写 Prompt 的人」变成「设计 Prompt 系统的人」，是 2024 年初 AI 销售助手产品的第三次大改版。此前的方案——是一条 System Prompt 包揽所有事：定义销售角色、分析客户意向、生成跟进建议。这条 Prompt 我从第一版一直优化到第七版——采纳率从最初 47% 一路提到了 78%。但 78% 到 78%——改了三个月，一动不动。
我拉出了所有不采纳的 case（销售手动修改了 AI 生成的建议——为什么改？）做了一次根因分类。结果发现 78% 的瓶颈不是 Prompt 写得不够好——是这个场景的复杂度已经超出了单条 Prompt 能承载的上限。 销售跟进这件事其实包含了三个认知层级：第一层——理解客户在说什么（客户说「价格有点贵」是真的觉得贵还是在委婉拒绝？）；第二层——判断客户的购买阶段（是刚开始了解、已经在比价、还是马上要决定了？）；第三层——生成具体的跟进动作（发什么话术、建议什么时间联系、要不要拉上技术支持一起）。一条 Prompt 同时做这三件事——模型在第二层和第三层之间频繁出错：把「还在了解阶段」的客户当成了「马上要决定」去逼单——销售收到建议的第一反应就是「这 AI 不懂客户」。
我设计了一套「三阶段级联 Prompt 系统」——把一条 Prompt 拆成三条，每条只干一件事：
第一条——客户语义理解 Prompt（Stage 1）： 只做一件事——读对话，输出结构化的客户信号分析。不是笼统的「客户意向积极/消极」，而是拆成五个信号维度：①显性需求（客户直接说了要什么）；②隐性顾虑（客户说「再看看」「不着急」——是真的不着急还是对价格/产品有没说出口的顾虑？）；③决策角色（对话人是决策者、影响者还是信息收集者？）；④竞品提及（提了哪个竞品、在对比什么维度）；⑤时间紧迫度（有没有明确的采购时间窗口）。输出格式：一个 JSON——五个字段，每个字段一个分类标签+置信度+原文依据。
第二条——购买阶段判断 Prompt（Stage 2）： 接收 Stage 1 的信号分析 JSON，只做一件事——判断客户处于哪个购买阶段（意识阶段/考虑阶段/决策阶段），并输出「当前阶段+阶段依据+下一阶段推动策略」。这条 Prompt 的核心设计是：我把判断逻辑从「让模型自己推理」改成了「给模型一套阶段定义规则」。每个阶段我写了三条硬规则——比如决策阶段的规则是：「①客户在过去三轮对话中至少两次主动询问了价格/合同/交付时间；②客户提到了具体的使用场景而非泛泛了解；③客户的顾虑已经从'要不要买'变成了'买哪个版本/怎么付款'。」有了这套硬规则之后，模型从「把还在问基础功能的客户当成马上要签单」的错误率从约 22% 降到了约 6%。
第三条——跟进建议生成 Prompt（Stage 3）： 接收 Stage 1 的信号分析 + Stage 2 的阶段判断，生成最终的跟进建议。建议包含四个部分：①推荐话术（根据客户阶段和顾虑动态生成——意识阶段客户侧重教育、决策阶段客户侧重消除最后顾虑）；②建议跟进时间（根据紧急度信号）；③建议协作角色（需不需要拉技术支持——依据 Stage 1 里客户是否问了技术问题）；④风险提示（如果客户提了竞品——附上竞品对比要点）。
三条 Prompt 之间是一个严格的线性流水线——Stage 1 的输出是 Stage 2 的输入，Stage 1+2 的输出一起喂给 Stage 3。但我在架构里加了一个关键设计：Stage 1 的置信度低于 0.7 ——不往下传——直接触发「人工介入」标记。 因为如果连客户在说什么都判断不准，后面的判断和建议大概率是错的——与其生成一个看似合理的错误建议让销售被误导，不如直接告诉销售「这个对话 AI 没把握，建议你自己看」。
上线后的效果对比： 旧方案（单条 Prompt）——采纳率 78%，但「被销售评价为'不懂客户'的 case」占比约 19%。新方案（三阶段级联 Prompt 系统）——采纳率提到 89%，「不懂客户」的 case 占比降到了 6%。最关键的一个数据：销售团队主动使用 AI 建议的比例从日均 62% 提升到了 87%——不是系统推得更频繁了，是销售觉得「AI 这次真的理解客户了」愿意主动点开看。
但这个架构真正让我骄傲的不是效果提升——是两个月后的一次突发场景验证了架构的韧性。 公司签了一个大客户——是一家教育 SaaS 公司。他们的销售场景跟之前服务的电商、SaaS、金融客户完全不同——客户决策周期长、决策链涉及校长/教研组长/一线老师三个角色、对话里经常出现教育行业的专业术语（「大单元教学」「学科素养」「课标对齐」）。如果是旧方案的单条 Prompt——我得重写整条 System Prompt。但三阶段架构下——我只需要改 Stage 1 的五个信号维度定义（加了「教育决策链角色识别」）、改 Stage 2 的阶段定义规则（教育行业的购买阶段时间窗口更长——从「三轮对话内」调成「七轮对话内」）——Stage 3 几乎不用改，因为它只消费上游的结构化 JSON，不直接读对话。新客户上线只用了两天——对比旧方案预估至少一周的适配周期。
面试官读到这里，脑子里不是一个「优化了 Prompt、采纳率 89%」的 Prompt 工程师——而是一个**「发现单条 Prompt 在 78% 天花板卡了三个月之后，没有继续在单条 Prompt 上加指令——而是停下来分析了 200 多条不采纳 case、发现根因是场景复杂度超出了单 Prompt 承载上限、然后设计了一套三阶段级联系统把语义理解/阶段判断/建议生成拆成三条独立 Prompt、Stage 之间定义结构化 JSON 传递协议、置信度低于 0.7 自动触发人工兜底、新行业客户两天适配完成——而旧方案至少一周」的 Prompt 系统架构师。**
Prompt 系统设计的写作公式
你面对了什么「单条 Prompt 搞不定」的场景（为什么搞不定——复杂度在哪个维度？场景拆分？多层推理？多目标冲突？）→ 你设计了什么系统架构（几条 Prompt、各自职责、协作模式——串行/并行/路由/投票）→ Prompt 之间的信息传递协议（上游输出什么格式、下游怎么消费、如果上游不确定怎么办）→ 系统上线后的效果 vs 单条 Prompt 旧方案（不只是准确率——系统在什么极端场景下表现出了单 Prompt 没有的韧性）。
二、效果评估体系：别写「建立 Prompt 评估机制」，写你建的跨模型评估框架——以及它发现过的那个「不拆开看就会被整体准确率掩盖」的隐性退化
到了中级，效果评估不是「我建了几个指标、搞了个测试集」。而是——你的评估体系能不能跨模型工作？能不能在模型切换的时候报警？有没有真正影响过上线决策？
改前案例
建立 Prompt 效果评估体系。定义准确率、召回率、F1-score、格式合规率等核心指标。搭建 500 条测试集的自动化评估流水线。定期运行评估并输出效果报告。多模型对比 GPT-4、Claude、Gemini 在核心场景上的表现。评估结果指导 Prompt 迭代方向。
面试官看完：你建了评估体系、有 500 条测试集、对比了三个模型。但面试官不知道——多模型对比之后你发现了什么？你的评估体系有没有发现过「不拆开看指标就会被漏掉」的问题？有没有一次评估直接改变了你选模型或者改架构的决策？
改后案例
我建的评估体系后来被全公司推广——不是因为指标多、测试集大，是因为它在一次模型切换中成功拦截了一个「整体准确率看起来没变、但实际上在最重要的用户场景上已经悄悄崩了」的 Prompt 版本。那个发现让 CTO 在全员会上说了一句：「以后任何模型切换——先跑这套评估，报告不通过不上线。」
事情是这样的。2024 年 Q3，公司决定把 AI 客服产品线的默认模型从 GPT-4 换成 Claude 3.5——原因很直接：Claude 3.5 的 API 价格比 GPT-4 低了约 40%，而且在一些公开 benchmark 上表现不相上下。产品 VP 的原话是：「效果别明显变差就行——能省 40% 的成本，值。」当时的评估方式是——把同一套 Prompt 在两个模型上各跑 500 条测试集，看整体准确率。GPT-4 的准确率是 92.1%，Claude 3.5 是 91.7%——只差了 0.4 个百分点。「几乎一样。」大家都觉得可以切了。
但我在周会上说：「等一下——我看的不是整体准确率。我建评估体系的时候给 12 个意图类别都分别算了召回率和精确率。Claude 3.5 在 10 个类别上跟 GPT-4 不相上下——但在 '投诉' 和 '紧急问题' 这两个类别上，召回率分别掉了 11 个百分点和 8 个百分点。」
这个发现让所有人沉默了。AI 客服场景里，「投诉」和「紧急问题」是占比只有约 8% 但影响 80% 用户情绪的少数关键场景。如果模型把一个用户说「我打了三次电话都没解决，你们到底管不管」的紧急投诉判成了普通咨询——用户的体验是从「已经很生气了」变成「AI 也在糊弄我」——然后直接转人工投诉，客服成本翻倍。
我花了半天排查根因。发现 Claude 3.5 在理解中文「带有强烈情绪但不直接说投诉关键词」的句子上存在系统性的保守倾向——用户说「你们这个服务我真是服了」——GPT-4 能理解这是讽刺句式并正确判为投诉，Claude 3.5 倾向于判成「咨询」或「反馈」。因为 Claude 的安全对齐策略让它在面对带有负面情绪的中文表达时更倾向于「降级处理」——避免激化冲突。这是一个隐藏得很深的跨模型行为差异——不在少数关键类别上拆开看召回率，光看整体准确率 91.7% vs 92.1%，根本发现不了。
我做了两个动作：
第一——设计了「模型感知的情绪信号增强」适配层。 没改整体 Prompt 结构——而是在 System Prompt 里加了一段「仅当检测到用户消息包含以下情绪信号时生效」的规则。定义了 15 个中文讽刺/隐晦投诉的高频句式模板——「我真是服了」「你们太厉害了（反讽）」「这是第X次了」「算了不说了」——遇到这些信号，强制模型走投诉分类路径。这段规则用{model_behavior_hint}变量包裹，只在模型是 Claude 的时候注入。
第二——在评估体系里加了一个「关键场景加权」指标。 原来的整体准确率是所有类别的算术平均——权重一样。我改成：投诉和紧急问题两个类别在总指标里占 40% 的权重（虽然它们在数据分布里只占 8%）。因为这两个类别的错判代价是其他类别的 10 倍——评估指标必须反映业务代价，而不是数据分布。
改完后，Claude 3.5 在加权指标上跟 GPT-4 的差距从 0.4 个百分点缩小到了几乎不可区分。产品 VP 最终同意切换。上线后两个月的真实数据：客服成本没有因为模型切换而上涨——这在公司内部被认为是一次「被评估体系救了」的决策。我自己在年终复盘里写了一句：「这次模型切换如果只看整体准确率就上线——三个月后客服团队大概率会投诉'AI 不如以前聪明了'，然后我们花两周排查才发现是投诉分类在悄悄崩。」
面试官读到这里，脑子里不是一个「建了评估体系」的 Prompt 工程师——而是一个**「在整体准确率只差 0.4% 的表面平静下拆开 12 个意图类别的分项指标、发现了 Claude 在投诉和紧急问题两个关键类别上召回率分别暴跌 11 和 8 个百分点、排查出根因是 Claude 的安全对齐策略对中文讽刺句式存在保守倾向、然后设计了模型感知的情绪信号增强适配+关键场景加权指标体系——最终让一次可能造成客服投诉率飙升的模型切换安全落地」的人。** 跨模型评估能力——这是中级 Prompt 工程师最值钱、最稀缺的竞争力。
效果评估体系的写作公式
你的评估体系跟初级有什么本质区别（不只是指标多——是能跨模型对比、能按业务代价加权、能发现隐藏退化）→ 具体用它发现过什么「不拆开就会被掩盖」的问题 → 这个发现影响了什么决策（拦截过模型切换？阻止过 Prompt 上线？改变了优化方向？）→ 如果当时没有这套评估体系，最坏的结果是什么。
三、Few-shot 策略工程：别写「运用 Few-shot 技术」，写你从「每次手动挑示例」到「设计了一套让示例自动匹配输入的检索系统」的进化——以及为什么手工挑示例在三个行业里玩不转了
到了中级，Few-shot 不是你用没用过——是你有没有从「手艺」进化到「工程」。
改前案例
运用 Few-shot 技术提升模型输出质量。根据不同业务场景精心设计示例模板，引导模型输出格式和推理路径。在 AI 数据分析产品线中通过 Few-shot 示例将 SQL 生成准确率从 71% 提升至 85%。累计为 20+ 个客户场景定制 Few-shot 示例集。
面试官看完：「累计 20+ 个客户场景定制示例集」——你是一个一个手动挑的吗？20+ 套示例集——维护起来是什么体验？如果客户 A 的示例集里有一条过期了——你怎么发现？新来一个同行业客户——你是重新挑一套还是复用之前的？「SQL 生成准确率 71%→85%」——这 14 个百分点里，多少是因为示例本身、多少是因为你改了 Prompt 的其他部分？
改后案例
Few-shot 这件事我在第二年遇到了一个分水岭——公司签了一个 SaaS 产品，同一个 AI 数据分析的 Prompt 模板要同时服务电商、金融、医疗三个行业的客户。每个行业的数据库 Schema 完全不同——电商有订单表/用户表/商品表，金融有交易表/账户表/风控表，医疗有患者表/诊断表/处方表。一开始我的做法是：给每个行业各挑 5 个示例——三套示例集，Prompt 模板根据客户行业加载对应示例。这个方案在前三个月撑住了。
第四个月崩了。医疗行业的一个客户上线了一个新的数据模块——「临床试验数据管理」。用户的自然语言查询里开始出现「筛选出参与 III 期临床试验且不良反应记录中包含'恶心'的患者」这种问题。但我们的示例集里没有一条关于临床试验的示例——模型面对这种问题完全不知道怎么映射到 SQL。客户投诉：「你们的 AI 分析不准了。」
我意识到：靠手工给每个行业维护一套静态示例集——这个模式在客户场景持续扩展的时候必然崩。 因为新表、新字段、新查询模式每天都在长出来——你不可能每天追着给示例集打补丁。
我做了一个从「静态示例集」到「动态示例检索系统」的架构升级：
第一步——建了一个示例向量库。 把过去一年里所有被验证过「模型生成了正确 SQL」的真实查询-SQL 对收集起来——一共 1200 多条。每条做一个向量嵌入（用 bge-large-zh-v1.5），存在向量数据库里。每条示例附带元数据——行业标签、涉及的表名、SQL 复杂度（简单查询/JOIN/子查询/窗口函数）。
第二步——在 Prompt 模板里加了一个动态示例注入逻辑。 每次用户提问时——不加载固定的 5 个示例。而是：①用用户的自然语言问题检索向量库，取 Top-5 语义最相似的示例；②根据数据库 Schema 做一层过滤——如果检索到的示例里涉及的表在当前客户的数据库里不存在，替换为下一个最相似的；③确保 5 个示例覆盖不同的 SQL 复杂度——如果 Top-5 全是简单查询，手动把第 5 名替换为最近的一个 JOIN 示例——防止模型只学会简单查询。
第三步——建了一套示例效果追踪机制。 不是示例放进向量库就一劳永逸。每次模型生成的 SQL 在用户端被执行——如果执行成功（语法正确+返回了有效结果），给这条查询当时用的示例+1 分；如果执行失败（SQL 语法错误/字段不存在），给示例-1 分。每周自动清理得分低于阈值的示例——这些示例可能在教模型做错误的事。
上线后的效果对比：
- 旧方案（行业静态示例集）——SQL 生成准确率：电商 87%、金融 84%、医疗 79%（医疗最低——因为医疗查询的多样性最高，5 个示例根本覆盖不住）。
- 新方案（动态示例检索）——SQL 生成准确率：电商 89%、金融 87%、医疗 86%。医疗提升了 7 个百分点——因为在每次查询时动态检索的示例跟当前问题语义最相关，而不是用一个行业平均的示例集。
- 最关键的数据——新客户场景的「首次查询准确率」。旧方案下，新客户（示例集里没有这个客户的 Schema）的首次查询准确率只有约 62%。新方案下——首次查询准确率提升到了 78%。因为动态检索不依赖「有没有这个客户的专用示例集」——它从全局 1200 条示例里找最接近的。
- 维护成本——旧方案：每接入一个新行业客户，我需要花半天到一天手动挑示例、测试、调优。新方案：客户接入只需配一下数据库 Schema——示例自动检索——零人工挑示例时间。
这个系统后来被团队另一位 Prompt 工程师用在了客服产品线上——做 Few-shot 示例的动态召回。 他给我发了一条消息：「你这个向量检索的思路帮我省了至少两周的示例维护时间。」我把这套方案写成了一份《动态 Few-shot 示例工程实践》文档——包括向量库搭建、检索策略、示例评分机制、注意事项——现在是我们团队 Prompt 工程师入职后第二周必读的材料。
面试官读到这里，脑子里不是一个「用了 Few-shot、准确率 85%」的 Prompt 工程师——而是一个**「发现静态行业示例集在客户场景持续扩展下必然崩盘、然后从零搭建了一套 1200 条示例的向量库+动态检索+复杂度均衡+示例评分自动清理的 Few-shot 系统工程、让 SQL 准确率最高的医疗行业提升了 7 个百分点、新客户首次查询准确率从 62% 跳到 78%、并且把每个新客户接入的示例维护时间从半天降到了零」的人。** 这是中级 Prompt 工程师的核心竞争力——不是你会用 Few-shot，是你把 Few-shot 变成了一套不依赖人工的工程系统。
Few-shot 策略工程的写作公式
你从「手工挑示例」到「工程化选例」的转折点是什么（什么场景下手工模式崩了）→ 你设计了什么工程方案（静态→动态？规则→检索？人工维护→自动评分？）→ 方案的核心技术决策是什么（检索策略？示例多样性保障？质量监控机制？）→ 工程化前后的效果和维护成本对比。
四、多模型适配：别写「完成 GPT-4/Claude/Gemini 多模型适配」，写你发现的那三个跨模型行为差异——以及你的适配策略为什么不是「给每个模型重写一套 Prompt」
这是中级 Prompt 工程师最能跟初级拉开辨识度的板块。任何看过模型对比文章的人都能说「GPT-4 推理强、Claude 长文本好、Gemini 多模态牛」。面试官想看的是——你真的在同一个业务场景下同时维护过三个模型的 Prompt，并且踩过真实的行为差异坑吗？
改前案例
完成 GPT-4、Claude、Gemini 等主流模型的 Prompt 适配工作。针对不同模型的特性调整 Prompt 结构和输出约束。对比三个模型在客服、销售、数据分析等核心场景上的表现差异。建立多模型 Prompt 版本管理机制，确保各模型上的 Prompt 效果一致性。
面试官看完：你适配了三个模型——但你是怎么适配的？是每个模型各写一套 Prompt——还是用了一套策略？三个模型的行为差异具体是什么——不只是「Claude 更保守」「GPT-4 推理更强」这种泛泛之谈？你说「确保 Prompt 效果一致性」——一致性量过吗？一致性是多少？
改后案例
多模型适配这件事，我交过一笔很贵的学费。那笔学费是一个周五晚上 11 点——客户成功经理打电话给我：「XX 客户说他们的 AI 客服突然开始跟用户讨论'什么是好的客服'了——在用户投诉的时候。你们改了什么？」
我没改任何东西。那天下午唯一的操作是——把客户的环境从 GPT-4 切换到了 Gemini 1.5 Pro——因为 Gemini 的配额更便宜，而且内部评估报告说「在客服场景上准确率相当」。但我不知道的是——同一个 System Prompt，GPT-4 和 Gemini 对「角色扮演」指令的理解方式完全不同。
我的 System Prompt 里有一句话：「你是一个专业、有同理心的客服助手。在回复用户之前，先理解用户的情绪和真实需求。」GPT-4 读到这句话的理解是——「我是一个客服，我要先分析用户情绪，然后给出客服回复。」Gemini 的理解是——「我要展示我的'同理心'——所以在回复之前，我要先跟用户确认他的情绪，表达我的理解。」所以在用户投诉「你们的产品刚用三天就坏了」的时候——GPT-4 直接回复：「非常抱歉给您带来不便。我马上帮您处理退换货……」。Gemini 回复：「我理解您现在一定非常失望和生气。作为一个客服助手，我的职责是……」——然后开始了一段关于「什么是好的客服」的自我阐述。
这件事让我意识到：「多模型适配」不是给每个模型写一套 Prompt——如果你有三条产品线、三个模型、未来还要加第四第五个模型——那就是 15 套 Prompt，维护成本爆炸。 真正要做的是——找出模型之间行为差异的维度，然后把「模型特有的行为修正」从 Prompt 主体里抽出来，变成一套可配置的「模型行为配置文件」。
我花了两周做了一件事——把三个模型在同一个业务场景下的行为差异全面测绘了一遍。 用的方法是：同一套 200 条测试集、同一个 System Prompt、三个模型各跑一遍，然后逐条对比输出。我把行为差异归类成了四个维度：
维度一——格式遵循度。 GPT-4 对「必须输出纯 JSON」的指令遵循度最高——200 条里只有 2 条在 JSON 外多输出了文字。Claude 有 11 条在 JSON 前加了「好的，以下是……」的前缀。Gemini 有 8 条在 JSON 内把规定的下划线字段名改成了驼峰（
order_id→orderId）。
适配策略： 不在三个模型上各改一遍格式要求——而是在输出解析层加了一个模型感知的后处理：如果是 Claude——正则去掉前缀文字后解析。如果是 Gemini——Json 解析时做字段名的下划线/驼峰自动映射。
维度二——推理深度 vs 过度推理。 在 AI 数据分析的 SQL 生成场景下：GPT-4 对于「用户说'上个月'」——大部分时候能正确推断为当前日期往前推一个月。Claude 在 8% 的 case 里会过度推理——用户说「最近一周」，Claude 有时会理解成「过去七个自然日」有时是「最近五个工作日」——因为它多了一层「用户在商业语境下说的'一周'可能指工作日」的揣测。Gemini 则相反——推理偏浅，用户说「销量不好的产品」，Gemini 有时直接写
WHERE sales < 100——硬编码了一个阈值，而不是去查销量排名的后 20%。
适配策略： 在 Prompt 里加了一段模型感知的推理深度控制。「如果当前模型倾向于过度推理——严格按字面含义理解，不揣测潜台词。」「如果当前模型倾向于推理不足——对模糊表达做一步合理推断，并输出推断依据。」这段指令根据模型动态注入。
维度三——安全对齐的激进程度。 Claude 最保守——任何涉及「负面评价」「投诉」「敏感行业（医疗/金融）」的内容都会触发更保守的输出策略。Gemini 在某些中文语境下会拒绝回答一些在 GPT-4 看来完全合规的问题（比如「分析一下我们公司跟竞品的优劣势对比」——Gemini 有时会拒绝对竞品做评价）。GPT-4 在这三个里最「配合」——但幻觉率也最高。
适配策略： 不做模型级的 Prompt 改动——而是在业务流程里加了一层模型能力的路由逻辑。涉及竞品对比的查询——优先路由到 GPT-4。涉及敏感数据处理（医疗/金融合规要求高的）——优先路由到 Claude（更保守意味着合规风险更低）。涉及多模态的——路由到 Gemini。
维度四——对 Prompt 长度的敏感度。 同一个 3000 字符的 System Prompt——GPT-4 稳定遵循所有指令。Claude 在 Prompt 超过约 2500 字符后，中间部分的指令遵循度开始下降——表现为偶尔漏掉某条约束。Gemini 的长 Prompt 指令遵循度波动最大——同一套 Prompt 跑三次，指令遵循度分别是 91%/87%/93%。
适配策略： 设计了一套 Prompt 优先级标注机制——每条指令前面加一个[P0]/[P1]/[P2]优先级标记。如果模型是 Claude 且 Prompt 超过 2500 字符——注入一条指令：「优先保证所有 [P0] 指令被严格执行；[P1] 尽力执行；[P2] 在上下文容量有限时可酌情省略。」这条元指令让 Claude 的长 Prompt 指令遗漏率从约 15% 降到了约 4%。
测绘完成后的产出——不是三套 Prompt，而是一份《多模型行为差异图谱》+一套模型行为配置 JSON。
图谱是一个四维矩阵——格式遵循/推理深度/安全对齐/长指令敏感——每个维度下标注三个模型的表现和推荐适配策略。
配置 JSON 只有约 40 行——定义了每个模型在四个维度上的行为参数：format_strictness: gpt4=high, claude=medium, gemini=low、reasoning_depth: gpt4=balanced, claude=deep, gemini=shallow等等。Prompt 模板里用配置变量控制行为修正指令的注入。
这套方案上线后的效果： 以前新增一个模型支持——我需要花大约一周做 Prompt 适配+测试。现在——在新模型上跑一遍 200 条测试集、对比图谱、填写行为配置 JSON——半天完成。关键业务指标——三个模型的跨模型行为一致性（同一组测试集上人工评分的一致性）：适配前约 81%，适配后约 96%。
面试官读完这段，脑子里不是一个「适配了三个模型」的 Prompt 工程师——而是一个**「因为一次 Gemini 的'客服自我阐述'事故被客户投诉、然后花了整整两周用 200 条测试集对 GPT-4/Claude/Gemini 做了四维行为差异全面测绘、发现了格式遵循/推理深度/安全对齐/长指令敏感四个维度的系统差异、设计了一套模型行为配置 JSON 替代了三套独立 Prompt、把新增模型支持的适配时间从一周压缩到半天、把跨模型行为一致性从 81% 提升到 96%」的多模型适配专家。** 面试官要找的不是「用过三个模型的人」——是「能系统性地测绘模型行为差异、并把适配方案工程化的人」。
多模型适配的写作公式
你在多模型适配上踩过的最疼的一个坑（哪个模型在什么场景下行为崩了——导致了什么业务后果）→ 你怎么测绘模型之间的行为差异（什么方法、多少测试集、拆了哪几个差异维度）→ 你设计的适配策略是什么（不是给每个模型重写 Prompt——是配置化、后处理层、路由层？）→ 适配后的量化效果（行为一致性从多少到多少、新增模型支持时间从多久到多久）。
五、自我评价：删到 4-5 行——每行 = 一个中级 Prompt 工程核心能力 + 一个具体案例 + 一个量化对比
改前案例
3 年+ Prompt 工程经验，精通 Prompt Engineering 方法论及 System Prompt 设计。熟练掌握 Few-shot、Chain-of-Thought、ReAct、Self-Consistency、Tree-of-Thought 等主流提示技术。具备丰富的多模型适配经验（GPT-4/Claude/Gemini）。熟练使用 LangChain、Dify、AutoGen 等 LLM 应用开发框架。深入理解大模型原理和行为特性。具备 Prompt 系统架构设计能力。良好的跨团队协作和项目管理能力。带领过 2 人 Prompt 工程小组。
面试官 10 秒扫完——Prompt Engineering、Few-shot/CoT/ReAct/ToT/Self-Consistency、GPT-4/Claude/Gemini、LangChain/Dify/AutoGen——每个词都是一篇 Prompt 工程入门文章的目录标题。面试官的反应：「这个列表我可以在任何一个 Prompt 工程培训班的毕业生简历上看到——我凭什么觉得这个人值中级 Prompt 工程师的薪资？」
改后案例
- Prompt 系统架构设计——面对单条 Prompt 在 78% 采纳率卡了三个月的瓶颈，设计了三阶段级联 Prompt 系统： 拆成语义理解→购买阶段判断→跟进建议生成三条独立 Prompt，Stage 间定义结构化 JSON 传递协议，置信度低于 0.7 自动触发人工兜底。上线后采纳率从 78% 提至 89%，新行业客户适配周期从一周压缩到两天。
- 跨模型评估体系——建了一套拆开 12 个意图类别分项指标+关键场景加权的评估框架： 在一次 GPT-4 到 Claude 3.5 的模型切换评估中，发现整体准确率只差 0.4% 但「投诉」「紧急问题」两个关键类别的召回率分别暴跌 11 和 8 个百分点。排查出 Claude 对中文讽刺句式存在保守倾向的根因，设计了模型感知的情绪信号增强适配。这套评估体系后来被公司定为模型切换的强制前置流程。
- Few-shot 策略工程化——把手工维护的三套行业静态示例集升级为 1200 条示例的向量库+动态检索系统： 每次查询根据语义相似度+Schema 过滤+复杂度均衡自动匹配 Top-5 示例，配合示例评分自动清理机制。医疗行业 SQL 准确率从 79% 提至 86%，新客户首次查询准确率从 62% 跳至 78%，每个新客户接入的示例维护时间从半天降为零。方案被团队复用至客服产品线，沉淀为团队入职必读文档。
- 多模型适配——用 200 条测试集对 GPT-4/Claude/Gemini 做了四维（格式遵循/推理深度/安全对齐/长指令敏感）行为差异测绘： 设计了一套 40 行模型行为配置 JSON 替代了三套独立 Prompt 的维护模式。跨模型行为一致性从 81% 提至 96%，新增模型支持的适配时间从一周压缩到半天。这套方案起源于一次 Gemini 的「客服自我阐述」线上事故——但那次事故之后没再发生过第二次。
四行。面试官 15 秒扫完，脑子里留下四个清晰的标签：这个人能把一条 Prompt 的 78% 天花板突破成一套三阶段系统做到 89%；这个人建了一套跨模型评估体系、发现并拦截过一次「整体准确率伪装下关键类别悄悄崩了」的模型切换事故；这个人把 Few-shot 从手工维护三套静态示例集升级成了一套 1200 条示例的动态检索系统工程；这个人给三个模型画了四维行为差异图谱、把适配方案配置化，一致性从 81% 拉到 96%。
自我评价的铁律： 每一行 = 一个中级 Prompt 工程核心能力 + 一个具体的系统/框架/策略 + 至少一个量化对比。删掉所有技术名词标签，只留「你设计了什么」和「它带来了什么改变」。
写完后的自检清单
- Prompt 系统设计部分——有没有一段经历是单条 Prompt 搞不定、你重新设计了多 Prompt 协作架构？不是「我把 Prompt 拆成了两条」——而是「我为什么拆、拆成几条、各自做什么、之间怎么协作、传递什么信息、异常怎么兜底」。
- 效果评估部分——你的评估体系能不能跨模型工作？有没有发现过一次「整体指标正常但分项指标暴露了隐藏问题」的案例？这个发现有没有影响过一个真实的决策？
- Few-shot 部分——有没有从「手工挑示例」到「工程化选例」的进化？动态检索？自动评分？团队复用？如果还是每次手动挑 5 个示例——这是初级写法。
- 多模型适配部分——有没有一次「同一条 Prompt 在不同模型上行为不一致」的真实案例？不是泛泛的「Claude 更保守」——是具体的「在什么场景下、模型的什么输出让你意识到了差异、你做了什么适配」。
- 自我评价删到 4-5 行。每行 = 一个中级能力 + 一个具体案例 + 一个数字。把「精通 Prompt Engineering」「熟悉多模型适配」「掌握 Few-shot 策略」全部删干净。
- 终极拷问：面试官读完你的简历，能用一句话说清楚「这个 Prompt 工程师最值钱的能力是什么」吗？是「能设计多 Prompt 协作系统突破单 Prompt 天花板」？是「能用跨模型评估体系发现隐藏的能力退化」？是「能把 Few-shot 从手工维护进化到动态检索工程」？还是「能测绘模型行为差异并设计配置化适配方案」？如果面试官只能说「会写 Prompt」——重写。
三年前你写第一份 Prompt 工程师简历的时候，证明的是「我能写 Prompt——System Prompt 会写、Few-shot 会用、CoT 会加、准确率能提到 85% 以上」。三年后你写中级 Prompt 工程师简历，要证明的是「我能设计一套让三个模型协同工作、综合准确率推到单模型永远够不到的高度的 Prompt 系统；我能建一套跨模型评估体系、在整体准确率只差 0.4 个百分点的伪装下挖出关键类别 11 个百分点的隐性退化；我能把 Few-shot 从每次花半天手工挑示例进化成一套 1200 条向量库全自动检索的工程系统；我能给三个模型画出四维行为差异图谱、用 40 行配置 JSON 替掉三套独立 Prompt 的维护噩梦。」
初级 Prompt 工程师的简历靠「一条让我改到第五版才收敛的 Prompt」来打动面试官。中级 Prompt 工程师的简历靠「一个我设计的、让团队和系统变得更强大的 Prompt 架构或方法论」来打动面试官——我设计的三阶段级联系统让采纳率从 78% 提到了 89%、我建的跨模型评估体系拦截了一次差点上线的模型切换事故、我搭的动态 Few-shot 检索系统让新客户接入从半天降为零。
写 Prompt 证明「我能让一个模型听话」。设计 Prompt 系统证明「我能让一群模型协同干活——而且比任何一个单干都强」。这两个身份之间——是你简历需要跨越的最重要的一道坎。
写好之后不确定效果？好简历的免费诊断可以帮你从 Prompt 系统架构深度、评估体系建设、Few-shot 策略工程化和多模型适配能力几个维度做一次全面扫描，每一段经历都会给出强弱项分析和改进建议。