前段时间一个在SaaS公司做了一年半Prompt工程师的朋友找我改简历。他负责公司AI客服产品线的Prompt设计与优化——日常工作是写客服意图识别Prompt、设计多轮对话的System Prompt、跟后端配合调试模型输出的JSON Schema。他说投了快五十份——AI应用公司、大模型创业团队、传统企业的AI落地部门都投了，面了七八家，有一半挂在二面。面试官总是问同一个方向的问题：「你说你设计过Prompt，能不能具体讲一条——你改过最多次的那条Prompt，每一版改了什么、为什么这样改、改完之后数据怎么变的？」
他把简历发给我。第一条工作经历长这样：
负责公司AI客服产品线Prompt设计与迭代。独立设计客服意图识别、多轮对话管理、情感安抚等场景Prompt 150+条。运用Few-shot、Chain-of-Thought、ReAct等提示技术提升模型输出质量。熟练使用LangChain、Dify等LLM应用开发框架，完成Prompt与后端API的对接联调。配合算法团队进行模型效果评估，Prompt准确率从初始版本提升至85%以上。
这段话放在任何一个做了一年半Prompt工程师的人身上都不违和。Prompt数量、Prompt技术、开发框架、准确率——该有的关键词全有了。但面试官看完只有一个感觉：这个人就像一个照着菜谱炒菜的帮厨——食谱上说放一勺盐他放一勺盐，食谱上说大火翻炒他大火翻炒。但你问他——为什么这锅菜糊了？是火太大还是油太少？为什么换了一口锅之后菜的味道变了？食谱上说放三颗八角——放了反而串味了，你试过放两颗吗？他答不上来。
这就是初级Prompt工程师简历最核心的问题：你把一份需要设计诊断实验、定位失败根因、用数据验证假设的工程工作，写成了一份「写了多少条Prompt、用了多少个框架」的技能清单。 Prompt工程这件事有一个很容易被忽视的真相——十个入行一年半的Prompt工程师九个会写System Prompt、用Few-shot、调temperature、接LangChain。这些东西是基本功，是任何一个看过三篇公众号文章的人一个下午就能照猫画虎做出来的事。面试官真正想看的，是你发现模型输出在「用户说'我想取消但又不完全想取消'」这种模棱两可的话上频繁翻车时，你能不能设计一个对比实验——不是「我觉得Few-shot应该管用」就加几个例子上去，而是先拉出50条模型翻车的case，逐条标注翻车类型（是语义歧义？是上下文窗口污染？是System Prompt里的优先级冲突？），然后基于标注结果决定到底是改System Prompt的优先级定义、还是加边界case的Few-shot示例、还是把单步推理拆成两步——先用一个Prompt判断意图的模糊程度，再用第二个Prompt决定输出哪类。你试了，你对比了数据，你知道哪条路通哪条路不通。
先搞清楚：初级Prompt工程师的简历要证明什么
在拆具体怎么写之前，先对齐面试官的预期。初级Prompt工程师——不管你在SaaS公司、AI应用创业团队、还是传统企业的AI落地部门——工作经验通常在0-3年。面试官不会指望你一个人从零设计一套完整的Agent架构，但他一定会看四样东西：
第一，你有没有「诊断Prompt失败根因」的能力。 Prompt工程最危险的心态是「输出不行就换个模型」或者「再加一段Prompt试试」。十个Prompt工程师九个会说「我优化了Prompt、效果提升了」——但面试官想看的是：你发现模型输出出问题之后，你做的第一件事是加一段指令？还是先拉数据、做分类、定位根因？你有没有在200条输出里发现「模型在涉及金额计算的问题上准确率只有53%，但不是因为它不会算——是因为System Prompt里'优先使用温和语气'和'给出精确数字'两条指令在金额场景下产生了冲突，模型为了温和选择了模糊表达」这种层级的诊断？
第二，你有没有「建立可量化的评估标准并用它驱动迭代」的能力。 「看着还行」「感觉比上一版好」——这种评估方式在Prompt工程领域一文不值。面试官想看的是：你有没有针对你负责的场景，定义过一组可量化的评估指标？不只是「准确率」这种粗略指标——你有没有拆成「意图分类准确率」「关键信息抽取完整率」「输出格式合规率」「事实性幻觉率」？你有没有用这套指标做过至少一次改前改后的对比？对比结果是什么？
第三，你有没有「不是用Prompt技术，而是选Prompt技术」的判断力。 Few-shot、CoT、ReAct、角色扮演——这些技术谁都会用，面试官想看的是：你面对一个具体问题时，有没有想过「这个场景到底需不需要Few-shot」？你有没有过「加了Few-shot之后效果反而更差」的经历——然后你分析出了原因？你有没有一次是主动选择了「不加CoT」——因为你的场景是简单的意图分类、加了CoT反而让模型过度推理导致延迟翻倍但准确率只提升不到一个百分点？选不用的勇气比全都用的勤奋更值钱。
第四，你有没有「让Prompt在系统里活着，而不是在对话框里活着」的工程意识。 Prompt不是在ChatGPT的聊天框里写一段话就叫Prompt工程。真正的Prompt工程——你的Prompt上游接的是什么数据（可能是用户语音转写文本带错别字、可能是客服系统传过来的不完整上下文、可能是多个上游Agent拼出来的拼接结果），你的Prompt输出要喂给谁（下游的NLU模块要求严格JSON Schema、业务系统要求特定字段枚举值、前端要直接渲染Markdown）。你有没有一段经历是——上游数据出问题了（字段缺失、格式异常、信息冲突），你没有等上游修数据——你在Prompt里设计了容错逻辑和兜底策略，让模型在不完美的输入下依然能稳定输出？
带着这四个问题，下面从五个维度一个一个拆。
一、Prompt设计与迭代：别写「设计Prompt 150+条」，写一条让你改了五版才收敛的Prompt
Prompt设计是简历的门面，但99%的人把它写成了功能清单：
改前案例
负责AI客服意图识别Prompt设计。运用角色扮演+输出格式约束技术，引导模型准确识别用户来电意图（投诉、咨询、退换货、账号问题等12个类别）。通过Few-shot示例提升小样本意图分类准确率。持续监控线上模型表现，根据badcase迭代优化Prompt。Prompt意图识别准确率达到87%。
这段话没有任何「工程判断」的影子。面试官完全不知道：87%这个数字是从多少变过来的？你改了什么东西才从上一个版本提到87%的？模型在哪些意图上翻车最严重——是「投诉」和「咨询」之间的模糊边界吗？你是怎么发现这个模糊边界的——是看了badcase还是跑了混淆矩阵？Few-shot示例——你选了哪几个类别做示例、为什么选这几个而不是那几个、示例数量是你随便选的还是做过对比实验？
改后案例
我有一条原则：不把Prompt当成一段写给模型看的文字——我把它当成一个'可测试的假设'。 每一条Prompt上线之前，我一定跑三轮测试：同一组测试集，三个Prompt版本，量化对比。只有数据能告诉我「这个改动是有效的」还是「只是我感觉有效」。
案例：客服意图识别Prompt——我从第一版的「一段话描述角色」一路改到第五版的「结构化角色约束+意图定义树+边界case优先级规则」，准确率从71%提到了93%。
我们AI客服的第一个版本，意图识别用的是最朴素的写法——一段System Prompt描述客服身份，然后在User Prompt里直接问用户「请问有什么可以帮您」。意图识别靠模型自己的理解。第一版上线后在200条人工标注的测试集上准确率71%。
71%意味着什么？每三个用户的来电，就有一个被模型理解成了别的东西。投诉被当成咨询——用户本来就火大，模型还跟他说「感谢您的反馈，我会记录下来」，用户直接炸了。
我没急着「加一段Prompt试试」。我先拉了100条分类错误的case，做了一件事：逐条看模型把什么错判成了什么，画了一张混淆矩阵。 然后我发现了三个规律：
第一，「退货咨询」和「投诉」之间的交叉错误占了全部错误case的41%——用户说「我买的这件衣服跟图片完全不一样，我想退了」，模型有时判成「投诉」（因为语气像投诉），有时判成「退货咨询」（因为提到了退）。模型在这两个意图之间反复横跳，说明Prompt里对这两个意图的定义边界不够清晰。
第二，「账号问题」里有一个子类——「我想注销账号」——错误率高达62%。模型经常把它判成「其他」或者「咨询」。因为「注销账号」的行为特征跟其他「账号问题」（找回密码、修改手机号、查看订单）完全不同——它不是在使用账号，是在销毁账号。
第三，有11%的错误case里用户输入非常短——「嗯」「不是」「等一下」——模型面对这种短输入时完全靠猜。
带着这三个发现，我开始一版一版改。
第二版：我把System Prompt从一段话改成了结构化定义。 原来是一段话：「你是一个专业的客服意图识别助手，请根据用户的话判断意图……」——太多模糊空间。第二版我改成了：为每个意图写了一条「定义 + 3个正例 + 2个边界反例」。比如「退货咨询」的定义是：「用户表达了退货意向，但尚未确定要投诉。核心信号词：想退、不合适、跟图片不一样、尺寸不对。与投诉的关键区别：退货咨询里用户在描述事实（'这件衣服小了'），投诉里用户在表达情绪并要求补偿（'你们这质量太差了，给我一个说法'）。」加了这层边界定义后，「退货咨询」和「投诉」之间的交叉错误从41%降到了18%。准确率从71%提到了79%。
第三版：我注意到「注销账号」这个子意图一直被误判，因为它的行为模式跟其他账号问题完全不同。 我决定不把它放在「账号问题」下面——我在意图体系里把它单拆出来，变成独立的第13个意图「账号注销」。同时我把System Prompt里「账号问题」的描述更新为：「注意：如果用户表达的是'注销/删除/关闭账号'，不属于本意图——应归为'账号注销'。」这个改动之后，「账号注销」的召回率从38%跳到了84%。准确率从79%提到了86%。
第四版：我针对短输入问题做了一件事——在System Prompt里加了一条「不完整输入处理规则」。 「如果用户输入少于5个字且不包含明确的意图信号词（退货、投诉、改密码、查订单等），不要强行分类——输出intent为'待补充'，并输出follow_up_question引导用户说出更多信息。」这条规则上线后，短输入场景下的误分类率从67%降到了21%。准确率从86%提到了90%。
第五版：我把Few-shot示例从「每个意图一个示例」改成了「只给最容易混淆的三对意图各一个边界示例」。 之前为了「覆盖全部意图」，我给每个意图都塞了一个Few-shot示例——12个示例塞在Prompt里，上下文窗口占了将近一半。但我跑了一组A/B测试：去掉8个示例，只保留最容易混淆的三对意图（退货咨询vs投诉、账号注销vs咨询、换货vs退货咨询）各一个「边界case」示例。结果——Prompt的token消耗减少了约35%，准确率反而从90%微涨到了93%。因为模型在处理那些不太容易混淆的意图时，那8个示例不提供额外信息——反而在干扰模型的注意力。
从71%到93%，五版Prompt迭代。每一版都不是「我觉得这样改应该有用」——每一版都是「我发现了某一类case的规律→做出了一个具体假设→改了Prompt的某一个具体部分→用同一组测试集验证了数据变化」。我把这五版迭代的过程写成了一份《Prompt迭代诊断手册》，后来被CTO要求推广给了另外两个产品线的Prompt工程师。
面试官读完这段，脑子里不是一个「设计了意图识别Prompt」的Prompt工程师——而是一个**「能在71%的准确率面前不慌——先画混淆矩阵发现'退货咨询'和'投诉'交叉错误占41%、然后把模糊的意图定义改成'定义+正例+边界反例'、把'注销账号'从子类别升为独立意图、给短输入加了兜底规则、最后通过A/B测试砍掉冗余的8个Few-shot示例反而把准确率推到93%」**的人。你给面试官看的不是一个Prompt——是一条完整的「发现问题→形成假设→设计实验→验证效果」的工程思维链。
Prompt设计的写作公式
你负责了什么场景的Prompt（什么模型、什么任务、输入输出格式）→ 初始版本在什么指标上表现怎么样（准确率/召回率/格式合规率/幻觉率——不要只说「效果不好」）→ 你做了什么诊断（拉了badcase？画了混淆矩阵？分析了错误分布？）→ 你发现了什么规律（某一类case集中崩、某两个意图之间边界模糊、某条指令被另一条覆盖了）→ 你每一版改了什么、为什么这样改、改完数据变了吗→ 最终版vs初始版的全量指标对比。
二、效果评估与数据驱动优化：别写「准确率提升至85%」，写你定义了哪些指标、用它们发现了什么问题
效果评估是Prompt工程师简历里最见专业功力的板块，但绝大多数人把它写成了「拍脑袋」：
改前案例
建立Prompt效果评估机制。通过人工抽检+自动脚本对Prompt输出进行质量评估。定期分析badcase，根据分析结果迭代Prompt。与算法团队协作进行多模型效果对比。持续跟踪线上指标，Prompt效果稳步提升。
面试官看完：你就是抽检了一下、看了看badcase——这叫什么评估机制？你抽检了多少条？抽检标准是什么——「看着像人写的」算合格吗？自动脚本校验了什么——格式？字段完整性？逻辑一致性？多模型对比——比了什么指标？哪个模型在什么场景下比哪个好？
改后案例
我入职第二个月做了一件事，被我的Leader在周会上公开表扬了——不是因为写出了多牛的Prompt，是因为我建立了一套「让Prompt的效果不再靠'感觉'判断」的评估体系。在那之前，团队评估Prompt的方式是——大家轮流看输出，然后说「感觉还行」或者「感觉不如上一版」。这种评价方式，同一个输出三个人能给出三个完全不同的结论。
我做了三件事：定义指标体系 → 建立评估数据集 → 把评估流程自动化。
第一件事——定义三组、九个指标。 我不满足于「准确率」这一个数字。我把Prompt的质量拆成了三个维度：
任务完成维度： ①意图分类准确率（分类任务的核心指标）；②关键信息抽取完整率（用户说了5个关键信息，模型抽出了几个？——这个指标后来帮我们发现了一个隐藏问题：模型经常漏抽'用户二次确认后的修正信息'）；③回复方案匹配度（模型给出的回复策略跟人工标注的标准策略一致吗？1-5分人工打分）。
输出质量维度： ④格式合规率（输出JSON的Schema是否正确、字段是否完整、枚举值是否在允许范围内——自动校验，不需要人工）；⑤事实性幻觉率（抽取输出中的事实陈述，逐条对比知识库——自动+人工复核）；⑥回复语气一致性（模型的语气是否符合System Prompt里定义的角色——人工打分1-5分）。
系统性能维度： ⑦首token延迟（从输入到第一个输出token的时间）；⑧端到端延迟（完整输出的总时间）；⑨Token消耗（输入+输出token数，直接影响成本）。
第二件事——建立了一个200条的黄金评估集。 之前团队评估Prompt是靠「从线上随机抽20条看看」——20条是什么概念？置信区间大得离谱，20条里多错一条准确率就波动5个百分点。我把过去三个月线上的真实用户query汇总，按意图类别做了分层抽样，凑了200条。每条我都做了三重人工标注——两个标注员独立标注意图+关键信息，不一致的交由第三个标注员仲裁。200条评估集的标注一致性（Cohen's Kappa）做到了0.91。
第三件事——写了一套评估自动化脚本。 每次Prompt改版，跑一遍200条评估集，十分钟出报告——九个指标、每个意图类别的分项得分、跟上一版的对比变化、以及自动标记出「指标退步超过5%」的意图类别。这个脚本上线后的第一个月，我们发现了一个之前没人注意到的规律：有一次Prompt改版后，整体准确率从85%微涨到86%——看起来「改好了」。但自动化报告自动标红了「投诉」类别的召回率——从78%降到了71%。因为新的Prompt在「投诉」上变得更保守了——模型倾向于把语气不够激烈的投诉判成「咨询」。如果不是九个指标拆开看，这个退化就被「整体准确率微涨」给掩盖了。我们立刻回滚了这个Prompt版本。
这个评估体系后来被公司定为「Prompt发布标准流程」的一部分——任何Prompt上线前必须通过评估集的九个指标全检，且每个意图类别的分项指标不得低于上一版本2个百分点以上。我Leader在晋升评审里写了一句：「她把团队从'凭感觉评估Prompt'拉到了'用数据驱动Prompt迭代'。」
面试官读完这段，脑子里不是一个「建立了评估机制」的Prompt工程师——而是一个**「把'感觉还行'量化成了三组九个指标、把'随机抽20条'升级成了200条分层抽样+三重标注的黄金评估集、写了自动化评估脚本十分钟出对比报告、并且因为分项指标报警而拦截了一次'整体准确率微涨但投诉召回率暴跌'的Prompt上线」**的人。评估能力，是初级Prompt工程师简历里最稀缺、最能一锤定音拉开差距的板块。
效果评估的写作公式
你接手之前的评估方式是什么样的（拍脑袋？人工抽检？没有标准？）→ 你做了什么改变（定义了哪些指标、每个指标怎么算出来的、评估集是怎么建的、样本量多大、标注一致性如何）→ 这套评估体系帮你发现过什么「如果不拆开看指标就会被掩盖」的问题 → 有没有一次评估结果直接影响了Prompt的上线/回滚决策？
三、Few-shot与示例工程：别写「运用Few-shot技术」，写你选示例那一下午想明白了什么
Few-shot是Prompt工程里最「看似简单、实则凶险」的技术——加几个示例就能提效？那所有人都是专家了。真相是：示例选错了比不加还糟糕。初级简历里对Few-shot的写法往往只有一行：
改前案例
运用Few-shot、Chain-of-Thought等技术提升模型输出质量。针对不同场景设计示例模板，通过示例引导模型输出格式和推理逻辑。在某客服场景中通过添加3-5个标注示例，模型输出准确率提升约10%。
「添加3-5个示例、准确率提升约10%」——你加了什么示例？为什么3-5个而不是2个或8个？示例是怎么选的——随机挑了几个？还是挑了边界case？「提升约10%」——从多少提到多少？什么指标？面试官看完只觉得你「用过Few-shot」，但不知道你「理解了Few-shot」。
改后案例
Few-shot这件事我交过一次学费。那之后我给自己立了一条规矩：选示例之前，先搞清楚「这个示例要教会模型什么」。如果我说不清楚——这个示例不放。
案例一：加了5个示例，准确率反而跌了——因为示例在教模型做另一件事。
我们有一个「用户来电原因总结」的Prompt——用户打完一通客服电话后，模型需要把用户的核心诉求概括成一句话（不超过30个字）。第一版不加示例，Prompt就是「请将以下对话总结为一句话，不超过30字，概括用户的核心诉求」。测试集上50条——22条合格（信息完整+字数合规+不添加对话中没有的信息），合格率44%。
常见思路：加几个示例。「我找了几条真实对话，把人工写的总结标注好扔进去当Few-shot」。加了5个示例，合格率——反而掉到了39%。
我傻了。加了示例怎么还不如不加？我把加了示例之后新增加的8条不合格case逐条拿出来看，发现了一个规律：这8条不合格case有一个共同点——模型的总结里出现了对话中用户提到的「暂时不想处理」「先这样吧」「下次再说」这类模糊信号，但模型把它总结成了「用户已解决问题」。 翻回去看我的那5个示例——3个示例里用户的诉求都是清晰且正向的（「我想改收货地址」「帮我查一下物流」「我要投诉快递员」），示例里的总结也都是确定的结论。模型从这5个示例里学到的东西不是「怎么总结」——是「总结应该是一个确定的结论」。所以当它遇到用户说「先这样吧我改天再打过来」的时候，它强行给了一个「用户确认了解决方案」的结论——因为示例里所有的总结都是这样的。
我做了两个调整：
- 把5个示例砍到3个，但3个示例覆盖了三种情况： 一个是诉求明确的（「我要改地址」）、一个是诉求模糊但用户表达了倾向的（「我想退但运费太贵了，我再想想」→总结为「用户考虑退货但犹豫运费成本」）、一个是用户明确表示暂时不处理的（「今天先不处理了，下周再说」→总结为「用户暂缓处理，计划下周跟进」）。
- 在每个示例前加了一句「指令提示」——不是给模型看，是给我自己看，帮助我判断这个示例该不该放。比如：「这个示例要教会模型——当用户表达犹豫/不确定时，总结里保留这种不确定性，不要强行定论。」
改完后，合格率从39%提到了62%。比不加示例的44%高了18个百分点。而且不合格case的分布也变了——之前被模型「强行定论」的错误从12条降到了2条。
案例二：示例的排列顺序——把「标准case」放前面还是「边界case」放前面，效果完全不一样。
同一个Prompt，我把示例排列顺序做了A/B测试：
- A版：先标准case（诉求明确的）、再模糊case（诉求犹豫的）、最后边界case（暂时不处理的）
- B版：先边界case、再模糊case、最后标准case
在50条测试集上，A版的合格率62%，B版只有51%。为什么差这么多？因为把边界case放在最前面，模型在初始注意力最强的位置学到的第一个模式是「总结可以是不确定的」——然后它把这个模式泛化过度了，把一些本来可以明确总结的case也加了不确定的措辞（「用户疑似想退货」→对话里明确说了四五次「我要退货」）。而A版让模型先建立「正常总结长什么样」的基线，再用后面的示例教它「但不是所有情况都是这样的」——这种「基线优先」的排列逻辑显然更稳。
我后来写了一个《Few-shot示例选配checklist》贴在工位上——每次加示例前过四个问题：①这个示例要教会模型什么具体行为？②如果我没有这个示例，模型最可能在这个场景下犯什么错误？③示例之间有没有互相冲突的模式？④排列顺序是「基线优先」还是「边界优先」——我的场景更需要哪个？
面试官读完这两段，脑子里不是一个「用了Few-shot」的Prompt工程师——而是一个**「能发现加了5个示例后准确率反跌、逐条分析不合格case发现是示例里的'确定性偏见'污染了模型、砍掉2个示例并加入模糊case后合格率从39%跳到62%、还通过A/B测试验证了'基线优先'的排列逻辑远优于'边界优先'」**的人。面试官要找的不是「知道Few-shot这个词的人」——是「吃过Few-shot的亏、记住了吃亏的教训、并且把教训变成了可复用的方法论」的人。
Few-shot的写作公式
你负责的什么场景的Prompt → 你用了多少示例、怎么选的 → 带来了什么效果变化（注意——如果你的一次Few-shot尝试效果反而变差了，这是更好的简历素材：写你发现了什么、分析出了什么原因、做了什么调整、调整后数据怎么样）→ 你总结出了什么关于示例选取/排列/数量的规律。
四、工具链集成与工作流设计：别写「熟悉LangChain/Dify」，写你怎么让Prompt在真实系统里稳健运行
工具链集成在初级Prompt工程师简历里极其容易被一笔带过——因为大家觉得「Prompt就是一段文本，跟工程有什么关系」。但在面试官眼里，一个只会对着ChatGPT写Prompt的人和一个能设计「Prompt→API→下游系统」完整数据链路的人，价值差了不止一倍。
改前案例
熟练使用LangChain、Dify、扣子等LLM应用开发框架。完成Prompt与后端API的对接，实现AI客服对话服务的在线调用。通过Workflow编排实现意图识别→知识库检索→回复生成的串行链路。配合后端工程师完成输入输出的数据格式对齐。
面试官的反应：LangChain、Dify、扣子——三个框架你列完了。然后呢？你用它们解决了什么实际问题？「完成对接」——对接中出过什么问题吗？「数据格式对齐」——对齐了什么？是模型输出的JSON字段跟下游要求的字段名不一致，还是上游传来的结构化数据缺字段导致Prompt崩了？
改后案例
我进公司后接手的第一个工程任务不是写Prompt——是让已经写好的Prompt「在系统里活着」。之前团队有两条Prompt——一条做意图识别、一条做信息抽取——在调试环境里跑得好好的，一接上真实客服系统的WebSocket链路就开始出问题。问题五花八门——但归根结底一个原因：调试环境里的输入是干净的，真实系统里的输入是脏的。 我的核心工作就是把Prompt从「只能在干净环境跑」改到「在脏数据里也能稳」。
案例一：上游ASR转写的锅，Prompt来背——我加了一段「错别字容错+关键实体纠错」的前置逻辑。
AI客服接收的用户输入来自ASR（语音识别）转写——不是用户打字的。这意味着每一句用户原话里都可能埋着错别字。「我要注销账户」被识别成「我要注销帐护」。「订单号是SF12345678」被识别成「订单号是SF1234567吧」——最后那个「8」被吞了，还加了个「吧」。下游的订单查询系统拿到SF1234567自然是查不到的——用户以为是我们系统坏了，其实是ASR把「8」吃掉了。
我不想等ASR团队修模型——他们的迭代周期是两个月。我做的事：在第一层Prompt（意图识别）之前，加了一个轻量的「输入预处理Prompt」——只做两件事：
- ①关键实体纠错： 识别输入中的订单号、手机号、身份证号等格式固定且有校验规则的关键实体，用正则+规则拼回去。比如「SF1234567吧」→检测到「SF」开头+数字串+「吧」结尾→去掉「吧」、检查长度是否为10位（SF+8位数字）→如果不是，标记为「order_id_incomplete」而不是瞎猜。
- ②意图信号词模糊匹配： 维护一个意图信号词的模糊匹配表——"帐护"→"账户"，"小消"→"注销"，"推款"→"退款"。当输入中出现匹配到的模糊词时，在传给下游Prompt之前做原位替换，但同时在Prompt里加一句「注意：用户原始输入可能存在语音识别错误，以下为预处理后的文本，请结合上下文确认语义」。
这个预处理Prompt上线后，因ASR错误导致的意图误分类下降了约34%。而且最意外的一个效果——我Leader在周会上说：「订单查询成功的case里，之前客服同事经常反馈'用户报了订单号但系统查不到'——这个月的反馈量降了快一半。」因为我不是在做Prompt调优，我是在修Prompt上游的数据——但最终影响的是整个链路的成功率。
案例二：让模型输出100%合规的JSON——我设计了一套「三层兜底」的结构化输出策略。
下游的NLU模块要求意图识别Prompt输出严格格式的JSON：
{"intent":"refund_request","confidence":0.92,"entities":{"order_id":"SF12345678","product":"白色T恤"},"needs_human":false}。但实际运行中，模型经常出三种问题：①多输出——JSON外面还包了文字「好的，根据用户输入，我判断……」前面这段废话下游解析不了；②字段缺失——有时候输出里没有confidence字段、有时候多了不应该出现的字段；③枚举越界——intent的值写了ask_for_refund而不是规定的refund_request。
我试过好几次「在Prompt里强调必须输出纯JSON、不能有多余文字」——仍然有3%-5%的输出带了前缀。后来我做了三层兜底：
- 第一层——Prompt约束： System Prompt里用「必须」「仅」「严格」三个词来约束输出格式——但我知道这个只能兜住95%的case。
- 第二层——正则提取+修复： 在Prompt输出和下游解析之间加了一个中间件——如果输出不是纯JSON开头，先用正则从输出里把第一个
{到最后一个}之间的内容抠出来。如果抠出来的JSON解析失败，再尝试用规则修复——缺少confidence字段就补默认值0.5、出现未知枚举值就用编辑距离匹配到最近的合法枚举值。- 第三层——Schema校验+降级： 修复后的JSON过一遍JSON Schema校验器。如果仍然不通过——不把这个结果喂给下游NLU（那会造成更严重的错误），而是触发一个「兜底回复」——客服前端显示：「正在帮您转接人工客服，请稍候」——同时在后台记录一条包含原始模型输出的日志，方便后续排查。
这套三层兜底上线后，下游NLU收到的「解析失败」错误从每月约1200次降到了不到50次。而「触发兜底转人工」的case每月不到40次——说明大部分问题在第二层正则修复就解决了。后端负责NLU的同事在群里发了一句：「你们Prompt团队最近做了什么？我这边的异常日志突然少了90%。」
面试官读完这两段，脑子里不是一个「熟悉LangChain、Dify」的工具使用者——而是一个**「能发现ASR转写的错别字导致意图误分类、不等上游团队修复而是用Prompt级预处理把误分类降低了34%；能设计'Prompt约束+正则修复+Schema校验兜底'三层策略把下游NLU解析失败率压降90%以上」的工程型Prompt工程师。** 这是面试官最愿意高看一眼的简历——因为这个人在帮团队解决「Prompt之外的工程问题」，而不是在对话框里自娱自乐。
工具链集成的写作公式
你的Prompt在系统里的位置（上游是什么数据源、下游是什么消费者）→ 你接手时遇到了什么「只在真实系统里才会出现、调试环境里完全没问题」的坑 → 你设计了什么样的工程策略（不一定要写代码——你在Prompt层面做了什么防御性设计、在Prompt外做了什么兜底逻辑）→ 这个策略上线后的量化效果（错误率降低了多少、下游投诉减少了多少、延迟/Cost变化了多少）。
五、自我评价：别写「精通Prompt Engineering」，用你真实改过的Prompt和数据来证明
Prompt工程师的自我评价是最容易写成「技术名词堆砌」的重灾区：
改前案例
1年+Prompt工程经验，精通Prompt Engineering方法论。熟悉Few-shot、Chain-of-Thought、ReAct、Tree-of-Thought等主流提示技术。熟练使用LangChain、Dify、AutoGen等LLM应用开发框架。具备扎实的NLP基础和大模型原理理解。有较强的逻辑分析能力和数据敏感度。善于从badcase中定位问题根因并设计优化方案。良好的跨团队沟通协作能力。
面试官10秒扫完：Prompt Engineering方法论（哪个Prompt工程师不说自己精通？）、Few-shot/CoT/ReAct/ToT（参加过技术分享的人都能报一遍菜名）、LangChain/Dify/AutoGen（打开GitHub点个star就等于「熟练使用」了）、逻辑分析能力强（怎么证明？）。全是标签，零证据。
改后案例
Prompt诊断与迭代能力： 不在Prompt效果不好的时候盲目加指令。客服意图识别Prompt第一版准确率71%——先画混淆矩阵发现「退货咨询」和「投诉」交叉错误占41%，把模糊的意图定义改成「定义+正例+边界反例」结构。五版迭代（结构化定义→拆分意图→短输入兜底→砍掉冗余Few-shot示例），准确率从71%提到93%。迭代过程整理成《Prompt迭代诊断手册》，被推广到另外两条产品线。
效果评估体系建设： 不靠「感觉」评估Prompt。自建三组九个指标（任务完成/输出质量/系统性能）的评估体系+200条三重标注黄金评估集+自动化评估脚本（十分钟出对比报告）。这套体系成功拦截过一次「整体准确率微涨但投诉召回率暴跌7个百分点」的上线。被公司定为Prompt发布标准流程。
Few-shot示例工程： 吃过「加示例反而降准确率」的亏。在用户来电总结Prompt上，5个示例让合格率从44%跌到39%——逐条分析发现示例里的「确定性偏见」污染了模糊场景。砍掉2个示例、加入模糊case和边界case，合格率反拉到62%。A/B测试验证「基线优先」的排列逻辑比「边界优先」高11个百分点。总结成《Few-shot示例选配checklist》。
工程化落地能力： 不只是让Prompt在对话框里跑。设计ASR错别字预处理Prompt，让因语音识别错误导致的意图误分类下降34%。自建「Prompt约束+正则修复+Schema校验」三层结构化输出兜底策略，让下游NLU的JSON解析失败从月均1200次降到50次以内——后端同事在群里说异常日志突然少了90%。
四行。面试官15秒扫完，脑子里留下四个清晰的标签：这个人能把一条Prompt从71%诊断到93%、每一版改什么都有因果；这个人自己建了一套九个指标的评估体系、还拦截过一次上线事故；这个人在Few-shot上吃过亏、记住了教训、总结成了checklist；这个人不是只在对话框里写Prompt——他能修上游ASR的错别字、能兜底下游JSON解析失败。
自我评价的铁律： 每一行 = 一个Prompt工程核心能力 + 一条你真实改过的Prompt + 至少一个可量化的数字。删掉所有技术名词标签（精通XX、熟悉XX、理解XX），只留「你解决了什么问题」和「你把它改变成了什么」。
写完后的自检清单
- Prompt设计部分——有没有一条Prompt写了它至少两版的迭代过程？不是「优化了Prompt、准确率提升了」——而是「第一版在什么case上崩了→你做了什么诊断→你做了什么假设→第二版改了哪里→崩的case变了吗→又发现了新问题→第三版……」
- 效果评估部分——你有没有定义过一组「属于你自己的」评估指标？不只是「准确率」——格式合规率？幻觉率？召回率？延迟？成本？有没有建过评估数据集、样本量多大、标注质量如何？
- Few-shot部分——有没有一段经历是「加了示例之后效果反而更差」或者「换了示例排列顺序之后效果明显变化」？如果有但你没写在简历上——这是你简历里最值钱的东西。因为面试官看了五百份「运用Few-shot」的简历，第一次看到一份「加了Few-shot反而跌了、然后我分析出了原因」的简历。
- 工具链部分——你的Prompt有没有在「真实系统」里跑过，而不是只在调试对话框里？有没有上游数据脏、下游格式要求严、你设计了什么工程策略来兜底？写出来。
- 你能不能指着简历里任何一个数字说出它从多少、变到多少、你做了什么让它变的？如果一个数字只有「最终值」没有「初始值」——或者只有一个百分比没有基数——它就不是一个证据，它只是一个数字。
- 自我评价删到只剩4条。每一条 = 一个Prompt工程能力 + 一条真实Prompt + 至少一个数字。把「精通Prompt Engineering」「熟悉大模型原理」「掌握多种提示技术」全部删干净。
- 终极拷问：五十份Prompt工程师的简历堆在面试官桌上。他每一份花15秒翻完。翻完你的——他能用一句话说清楚「这个人最擅长解决什么问题」吗？是「这个人特别擅长从badcase里精准定位Prompt的根因问题」？是「这个人自己建了一套评估体系」？是「这个人能把Prompt从对话框落地到真实的工程链路里」？如果他说不出——重写。
初级Prompt工程师写简历，最需要想明白的一件事是：你是在跟成千上万个「会写System Prompt、会用Few-shot、会调temperature、会用LangChain」的Prompt工程师竞争。System Prompt的格式大家都会套。Few-shot的思路大家都会抄。LangChain的文档大家都会看。这些东西是你的入场券，不是你的胜负手。
胜负手藏在你发现模型输出崩了之后多做的那一步里：别人看到模型在「退货咨询」和「投诉」之间反复横跳，第一反应是「把System Prompt再写长一点，多强调几遍区别」——你没有。你先拉了100条case画了混淆矩阵，发现交叉错误集中在这两个意图之间，然后你不是加文字——你是改了意图定义的结构，从一段话变成了「定义+正例+边界反例」。别人评估Prompt靠「看着还行」——你没有。你建了九个指标、200条黄金标注集、一套十分钟出报告的自动化脚本。别人加Few-shot就是「找几个标注好的例子扔进去」——你没有。你先测试了加了示例效果反而变差的场景，然后分析出是示例里的偏见污染了模型，再重新设计示例选取标准。别人把JSON格式不稳定归咎于「模型不行」——你没有。你设计了三层兜底策略，让下游NLU的解析失败率降了90%以上。
这些事情在做的时候你可能觉得「不就是多拉了一组数据、多定义了几个指标、多测试了一轮吗，谁都会」。但Prompt工程这个职业有一个残酷但公平的真相：大多数人真的不会多做那一步。 大多数Prompt工程师看到输出不行就加指令——因为「加一段话比分析一百条case快多了」。大多数Prompt工程师评估Prompt靠感觉——因为建评估集太累了。大多数Prompt工程师没试过「加了示例反而更差」——因为他们从来没对比过不加示例和加了示例之后的完整测试集指标。
而你——如果你把那些「多做了那一步」的时刻写清楚、写出你的诊断过程、写出你的实验设计、写出改前改后的数据对比——你就已经从90%的初级Prompt工程师简历里跳出来了。
把你改过最多次的那条Prompt拿出来。不是写得最顺的那条——是让你最头疼的那条。可能是那条你第一版写完觉得「完美了」、结果一上线准确率只有71%的意图识别Prompt。可能是那条你加了5个Few-shot示例自信满满觉得「这次稳了」、结果合格率反而跌了5个百分点的总结Prompt。可能是那条你在调试环境里跑得好好的、结果一接上真实客服系统的WebSocket就因为ASR错别字全线崩溃的预处理Prompt。
把这段经历写清楚——你当时面对的是什么问题、你做了什么诊断、你形成了什么假设、你设计了什么实验来验证、数据最终证明了什么。这一段写好了，比你写一百句「负责XX场景Prompt设计、运用Few-shot/CoT技术、准确率85%以上」都管用。因为你说服面试官的不是「我写过Prompt」——你说服的是「我知道怎么判断一条Prompt为什么不行、怎么让它变行、以及我能用数据证明它真的变行了」。
写好之后不确定效果？好简历的免费诊断可以帮你从项目陈述、成果量化、匹配度和表达清晰度几个维度做一次全面扫描，每一段经历都会给出强弱项分析和改进建议。