提示工程这两年炒得火热，但一个很要命的问题是：大量顶着“提示工程师”头衔的人，日常做的最多的事，是改两个词、跑一下、看一眼、凭感觉说一句“比刚才好了”。如果你也处于这种状态，这篇文章请你一定看完。
我自己的经历，就是从这种状态里挣扎出来的。最开始我确实能靠直觉把prompt调到“看起来不错”，可一旦prompt变复杂、改动变多、团队变大，“凭感觉优化”的方式就彻底失灵了。后来我老老实实搭了一套提示评估框架，才算真正理解了什么叫“稳定的输出质量”。这篇文章会从最基础的“为什么要有评估框架”讲起，拆开评估框架的四个组成模块，再给出一条从0到1搭建的实操路线，接着聊评估指标的选型与踩坑分析，最后用一次真实劣化事故复盘完整的排查链路。适合正在做提示工程架构师、或者正被prompt反复折腾的开发者参考。
1. 为什么提示工程需要一套评估框架，而不是靠感觉调prompt
1.1 没有评估框架时，prompt优化的三个典型困境
先说三个我亲身踩过的坑。没有评估框架的时候，prompt的每个改动都没法沉淀成经验：
第一个困境是不可复现。今天改了一版prompt，测试了五个用例，感觉输出质量“明显提升”。但第二天同样输入再跑一遍，结果却完全不一样。这时候你根本分不清是prompt改好了，还是大模型自身的随机性在发挥作用。更麻烦的是，别人问你“你这版为什么好”，你只能回答“感觉就是好一些”，没有任何证据支撑。
第二个困境是不可对比。旧版prompt和新版prompt放在一起，到底哪个更好？有人说新版回答更详细，有人说旧版更精准。各有各的道理，谁也说服不了谁。一旦团队里出现这种争议，最后多半演化成比嗓门或者比资历，而不是比数据。
第三个困境是不可继承。prompt的迭代过程全靠个人经验，写prompt的人一旦休假，其他人连碰都不敢碰。我当时带过一个新人，他接手我的prompt之后，第一句话就是“这版prompt为什么在这里加了两句解释？我不敢改，怕改坏了”。这其实就是典型的不可继承。
三个困境的根源是同一个：没有把“质量”变成可测量的东西。感觉是世界上最不可靠的度量单位，因为大模型和你自己都充满随机性。
1.2 评估框架的本质：把“感觉”变成“数字”
评估框架，说白了就是一套给prompt打分的体系。它把一次性的“我觉得不错”，变成了一套可以重复执行、可以量化比较的流程。具体到形式上，它至少包含一套用例集、一组指标体系、一个执行方式和一套决策机制。
我习惯用一个类比来解释这件事：没有体重秤的时候，减脂就是玄学。你觉得自己瘦了，又好像没瘦；方案有没有效，全看当天心情。一旦有了体重秤，每天固定时间称一次，连续记录三十天，方案到底有没有用，数据会直接告诉你。prompt评估框架，就是你提示工程路上的那台体重秤。
不过要注意，评估框架测的真正对象，不是模型本身，不是某个孤立用例，而是“prompt加模型”这个组合。同一个prompt，换一个底层模型，评估结果可能会天翻地覆。所以框架里的每一条结论，都必须标注自己是在什么模型、什么参数下测出来的。
1.3 评估框架真正提升的是迭代效率
很多刚接触评估框架的人，以为它是用来“考核”prompt好坏的。这个理解不完整。它最重要的价值，是提升整个迭代过程的效率。
有了评估框架以后，我调prompt的单位，从“半天”变成了“半小时”。过去改一个版本，要在脑子里回放十几个用例的输出，反复斟酌；现在直接跑一遍回归，哪里掉了分一目了然。更重要的是，我每次改动前都会先记录基线分数，改动后看对比，如果分数掉了，我根本不需要纠结怎么向别人解释“我为什么觉得新版更好”，把对比结果甩出来就完事了。
从这个角度看，评估框架解决的不只是质量问题，还顺手解决了团队协作效率问题和沟通成本问题。
2. 评估框架的四个组成模块：用例、指标、执行与决策
2.1 第一模块：用例集，评估的“考试卷”
任何评估框架，第一块地基都是用例集。它就像一场考试的试卷，没有试卷，后面所有打分都无从谈起。
很多新手对用例集的理解是“找一批输入问题，然后看模型怎么回答”。这远远不够。我建议每一条用例，至少包含三个部分：输入、期望、约束。
输入是喂给模型的用户请求，可以是固定文本，也可以是带变量的模板。期望是理想输出的样子，可能是一段参考文本，也可能是几个必须覆盖的关键特征。约束是输出必须满足或绝对不能出现的条件，比如“不得编造数据”“必须基于给定材料回答”。
拿客服问答场景举例，一条用例可以这样设计：
- 输入：“你们的套餐能修改吗？我刚办了一个月。”
- 期望：回答中明确给出“是否支持修改”，并附带可操作的修改路径。
- 约束：不得出现“请您联系人工客服”这类没有实际帮助的托词，不得编造不存在的业务流程。
2.2 第二模块：指标体系，从“对错”到“多维度”
用例集解决的是“考什么”，指标体系解决的是“怎么算分”。最初级的指标就是准确率和通过率，但在真实项目里，只有这两个完全不够。
我常用的指标体系分两层：基础指标和进阶指标。
| 指标 | 定义 | 主要用途 |
|---|---|---|
| 准确率 | 输出符合期望的比例，适合有明确参考答案的任务 | 问答、分类、抽取 |
| 通过率 | 输出通过约束检查的比例，适合有硬性红线要求的场景 | 合规审查、格式要求 |
| 一致性 | 同一输入重复运行多次，输出之间的稳定程度 | 客服、助手类场景 |
| 鲁棒性 | 输入经过同义改写、加错别字、换语气后，输出质量是否还能保持 | 线上真实流量 |
| 延迟 | 单次请求从发出到返回的耗时 | 对实时性敏感的功能 |
| 成本 | 每次请求消耗的token数，以及折算出的费用 | 规模化上线前的估算 |
这些指标没有绝对的“哪个最重要”，关键看业务场景。客服场景里准确率和通过率优先；创意写作场景里一致性和成本可能更重要；检索增强问答里，忠实度要一票否决。
2.3 第三模块：执行方式，自动判分与人工抽检的配合
评估流程必须解决“谁来打分”的问题。我通常会用三种方式组合：
第一种是规则判分。用代码写死判断逻辑，比如检查输出中是否包含某个关键词，是否包含链接，是否超过了长度。这种方式速度快、成本低，但只能覆盖机械性的检查，对语义理解基本无能为力。第二种是大模型判分。找一个大模型当裁判，读一遍输出，按照评分标准打分。这是目前覆盖开放型任务成本最低的方式，但必须注意：裁判模型和被测模型最好是不同的，否则输出风格会偏向裁判自己。第三种是人工判分。让有经验的人逐条评阅。人工最可靠，但也最贵、最慢，所以只用来抽检争议用例和高价值核心用例。
我的习惯是：能让规则做的用规则，规则覆盖不了的交给大模型判分，大模型拿不准的再给人。三层漏斗下来，成本和质量的平衡点基本能找到。
2.4 第四模块：聚合决策，让数据回答“要不要合入”
评估结果如果只是一堆数字，那它就没有落地价值。聚合决策模块，要回答三个问题：
这版prompt比上一个基线好了还是坏了？好体现在哪些用例上，坏又坏在哪些用例上？最终结论是合入还是回退？
为此，每次评估跑完，我都要生成一份精简报告。报告里会有一个“总体分”，再加一个“分维度对比”。更关键的是要定义一个“回归线”的概念：任何prompt改动，如果核心指标提升，同时其他维度波动在容许范围内，才允许合入。如果核心指标下降了，就直接判定失败，不管它让别的什么指标变好了。
这个机制能有效避免一个最常见的团队拉扯：“虽然准确率掉了，但是回答更有礼貌了啊。”对不起，礼貌感不在核心指标里，合入免谈。
3. 从0到1搭建提示评估框架的四步实操路线
3.1 第一步：圈定核心质量维度，不要超过三个
很多人在搭框架时犯的第一个错误，就是把维度定得太全。准确率要、忠实度要、一致性要、鲁棒性要、延迟要、成本要，一口气全上，最后发现每次改动都有好几个指标在同时变化，根本没法决策。
我更推荐的做法是：先给自己现在的场景画像。问自己一个问题：什么样的输出，在业务意义上算“好”？
比如做客服机器人，你最关心的可能是“用户问题识别准确率”和“回答是否提供了实际依据”。做内容创作助手，可能是“主题相关度”和“语气一致性”。做代码助手，可能是“可执行率”和“注释清晰度”。
第一版框架最多只保留两到三个核心维度，其余维度先作为观察项记录，不参与最终决策。等框架跑顺了，数据积累多了，再扩容也不迟。宁可慢一点，也不要一开始就把体系做成大而无当的展览品。
3.2 第二步：准备好第一版用例集
用例有三个来源。第一个是线上真实请求，从日志里抽样，别忘了脱敏。第二个是历史失败案例，也就是在线下评测或线上反馈里表现不好的坏case，这一部分优先级最高。第三个是人工构造的边界case，包括空输入、超长输入、同义改写、用户故意换说法绕弯等等。
每条用例都要带上“期望”或“约束”，只有输入没有期望的用例，只能用来做“看着玩”，没法打客观分数。第一版我不建议贪多，二三十条足够起步。这二三十条里至少要有三分之二是坏case和边界case，剩下三分之一是正常流量。
我在管理用例时坚持用结构化文件，比如JSON，而不是Excel。二三十条的时候可能还感觉不到差别，等用例涨到几百条，你就明白为什么字段化、可读、可复用的管理方式如此重要了。
3.3 第三步：写一个能跑的评估脚本
评估脚本的第一版不需要多复杂，核心逻辑就是“喂一条用例，得到输出，打个分，汇总报告”。我一般会写一个类似这样的骨架：
def evaluate_prompt(prompt_template, test_cases, run_fn, judge_fn): report = [] for case in test_cases: output = run_fn(prompt_template, case["input"]) judge = judge_fn(output, case) report.append({ "case_id": case["id"], "input": case["input"], "output": output, "score": judge["score"], "detail": judge["detail"], }) return aggregate(report) def aggregate(report): scores = [r["score"] for r in report] return { "avg": sum(scores) / len(scores) if scores else 0, "pass_rate": sum(1 for s in scores if s >= 0.8) / len(scores) if scores else 0, "total_cases": len(report), }这里的run_fn，是你封装好的大模型调用函数；judge_fn，是可以替换的判分函数，初期可以先写成规则匹配，之后再升级为大模型判分。
脚本跑通之后，第一件要做的事不是调prompt，而是把当前线上版本的prompt作为基线，跑出一份基线报告。保存下来，后面所有改动都跟它做对比。
3.4 第四步：把评估流程接到prompt迭代里
评估脚本如果只在心血来潮时跑一跑，那它迟早会荒废。我从一开始就把评估流程写进了迭代规范：每次改动prompt之前，先记录当前版本的基线分数；改动完成后，在同一套用例集上跑回归；回归通过，再做人工抽检；抽检没问题，才允许合入主版本。
这一步看起来最简单，实际上最难坚持。很多团队都倒在“这版改动很小，不用跑评估”这种侥幸心理上。我后来把评估直接绑定到代码版本管理流程里：改prompt，必须附一张回归对比截图，否则不允许提交。强行把这个流程固化下来之后，掉链子的情况就很少发生了。
4. 评估指标选型的四个维度与踩坑分析
4.1 准确率与忠实度：事实性任务里“对”的内涵
准确率这个概念，在生成任务里远比在分类任务里复杂。一个输出可以读起来非常通顺、头头是道，但里面的关键事实全是错的。这时候如果只看“用户问题有没有被回答”来判断对错，就会被表面流畅骗过去。
所以在事实型任务里，我特别看重“忠实度”——也就是输出是否忠实于输入所提供的信息。比如检索增强问答场景，模型应该基于给定的资料回答，如果它绕开资料、直接调用了自己记忆里的内容，哪怕答案确实正确，我也更倾向判它有风险。原因很简单：自己记忆里的内容没有可控的来源，线上出问题很难兜底。
我踩过最深刻的一次就是：一版prompt在评测集上准确率很高，但上线后用户反馈“答案看着对，细究全错”。后来定位才发现，评测集里的用例都是模型记忆里见过的，模型“背答案”就能拿高分。诚实地说，这种假繁荣只有靠忠实度指标才能治住。
4.2 一致性：同一prompt跑多次是不是一样稳
大模型本身就是有随机性的。温度调高之后，同样的输入可能给出南辕北辙的版本。而很多产品场景，恰恰需要“稳定输出”，尤其是客服、助手、知识问答这类不能每次说法都不一样的场景。
一致性的评估方法不复杂：固定一个输入，重复跑十次，计算输出之间的差异程度。简单做法是字符串相似度，想要更贴近语义就用向量距离。不过要提醒一句：一致性不是越高越好。如果需要模型做创意发散，刻意引入随机性是合理的。所以这个指标一定要结合任务类型来解读，不要机械地认为“分数越高就是越好”。
4.3 鲁棒性：换个说法就不灵的问题
线上用户不会按照你prompt里的措辞说话。他们可能会简写、打错字、用完全不同的表达，甚至用很奇怪的语气。如果prompt只在固定说法下表现好，换个说法就崩盘，那这个prompt离上线还很远。
鲁棒性评估的做法，是在用例集里增加“扰动用例”：同义改写、换语气、加干扰信息、故意绕开你预设的关键词。有一次我测试一个“写辞职信”的prompt，输入“请帮我写一封辞职信”表现很好，改成“帮忙拟一封离职邮件”之后，输出质量直接就崩了。原因就是这个prompt里把“辞职信”这个词写得太死，模型没有迁移到“离职邮件”这种语义等价的表达上。
要治这个问题，一是prompt内多用语义化描述，少写死词汇；二是在用例集里长期维护一组“改说法”的特殊用例，让每次回归都能看到鲁棒性变化。
4.4 效率与成本：质量和花费之间的天平
做提示工程架构师的人，不能只看输出质量，还得算账。一个prompt越长，每次请求消耗的token越多，延迟也越高，成本是实打实的。
我工作中最常遇到的情况是：团队为了提升一点点质量，把prompt里的示例从两个加到六个，还加了一大段CoT引导。质量确实涨了，但每次请求成本涨了百分之三十。这时候就要像一个产品经理一样去判断：质量提升带来的业务收益，能不能覆盖额外成本？
实操方法很简单，在回归报告里加两项：平均输出token数和单次请求延迟。每次评估都记录，时间长了，你自然能建立一条“质量与成本”的曲线，知道自己在哪个区间里最划算。
5. 一次prompt劣化事故的完整排查链路
5.1 事故背景：上线后用户反馈逆行
某个客服问答项目，prompt从v3一路迭代到v7，每一版都是靠着“仔细检查输出、感觉不错再上线”的方式推进。v7全量上线一周之后，用户不满反馈显著增加，在线客服的转人工率也上去了。
最迷惑的地方在于，v7输出明显变得更长、语气更温和，看起来应该体验更好才对，为什么用户反而不满了？团队内部争论不休，谁也无法说服谁。
5.2 开始排查：把所有版本拉到同一张“考卷”上
我接手排查后的第一件事，不是去翻聊天记录，而是把所有版本找出来。好在团队当时有保留prompt版本的习惯，v3、v4、v5、v6、v7都能找到。紧接着，我用同一套用例集，给所有版本统一跑了一遍评估。
这套用例集包含三十个case，覆盖了高频用户问题、历史badcase和同义改写边界。跑完之后结果很快就出来了，所有版本放在同一张表里对比：
| prompt版本 | 核心准确率 | 平均输出长度 | 人工抽检合格率 | 备注 |
|---|---|---|---|---|
| v3 | 93% | 112字 | 90% | 上线基线 |
| v4 | 92% | 118字 | 88% | 微调 |
| v5 | 90% | 156字 | 76% | 加入语气优化指令 |
| v6 | 88% | 180字 | 70% | 继续强化语气 |
| v7 | 87% | 207字 | 62% | 全量铺垫话术 |
数字摆出来，问题就清楚了。v7的准确率从v3的93%掉到了87%，平均输出长度从112字涨到了207字，人工抽检合格率从90%掉到了62%。用户不满并不是因为“回答变长了”，而是因为核心准确率一路下跌，输出开始绕圈子。
5.3 定位根因：v5引入的语气指令与答案优先级冲突
进一步把v5和v7的prompt对比，根因逐渐浮出水面。v5的改动中，为了“语气更好”，加入了一串偏口语化的引导词，比如“首先非常感谢您的提问”“为了帮助您更好地解决问题”“如果您方便的话”等等。这些内容本意是提升亲和力，但在实际执行中，模型为了满足这些语气要求，开始拼命堆铺垫，把“直接回答问题”的优先级压到了后面。
更隐蔽的问题是，v5新增的指令与系统提示里的“简洁准确优先”产生了直接冲突。模型面对两个互相矛盾的指令，最后选择了“语气优先”，结果就是回答虽然客气，但半天摸不到关键信息。在线用户的耐心是有限的，只听了一堆客气话没有实质答案，转人工率自然就上去了。
5.4 修复与复盘：用数据决定回退什么
定位到根因之后，修复方向很清楚：v7整体保留，但把v5中引导“过度铺垫”的部分回退，把回答优先级重新调整为“先给结论、再补礼貌”。我基于v7改出了v8，在同一套用例集上重新回归。
v8的最终结果是：核心准确率回到91%，平均输出长度压到131字，人工抽检合格率回到86%。虽然没有完全恢复到v3的巅峰数值，但结合语气维度的提升来看，是一次更平衡的版本。
这次事故之后，我立了一条规矩：任何prompt的每一次改动，都要往版本记录里写上“改了什么、为什么改”。哪怕只是加了一个词，也要写。因为如果不写清楚“为什么”，下次排查劣化时，你就要把每个历史版本的意图重新猜一遍。
6. 评估框架落地过程中最容易踩的四个坑
6.1 指标不是越多越好，核心指标必须少于三个
我第一次搭评估框架时一口气定了八个指标，最后的结果是每次prompt改动都有三四个指标变好、三四个指标变坏，团队里谁也拿不定主意到底合不合入。最后我只能重新做减法：明确两个核心指标，其余全部降级为观察项。两个版本之间先比核心指标；核心指标打平，才轮得到观察项说话；观察项只能在核心指标不分胜负时当破局参考。
这个教训很简单：评估框架是指挥棒，不是考核表。指标越多，你对方向的判断反而越糊。
6.2 人工评估会疲劳，要有疲劳线和复核机制
人工判分的质量，会随着评阅数量增加而明显下降。我测试过，一次性评两百条，后半段的评分波动率和错误率比前半段高出一大截。这不是态度问题，是人的注意力真的会疲劳。
后来我把人工评估的批量控制在一个比较稳妥的范围内，每次不超过五十条，并且只在固定时间段进行。同时引入双人抽样复核：同一批case，两个人各评一遍，对分数差异大的case单独建清单讨论。虽然成本上去了，但判分质量稳定许多。
6.3 用例集要保鲜，防止出现“背题”假象
固定用例集跑久了，会出现一种隐蔽的“过拟合”：prompt慢慢学会了在用例集上拿高分，但换上真实场景又不行。原因是模型方也在持续更新，固定的公开用例容易被模型“学到”，相当于考试前泄了题。
我的应对办法是两个：第一，定期从真实请求里抽新用例混入评估集，淘汰或轮换老用例；第二，保留一小批盲测集，平时不参与回归，只在大版本决定时拿出来做side-by-side盲评。这能有效阻止prompt“背题”。
6.4 框架不接入迭代流程，就会变成废纸
评估框架最怕的结局，是报告写得漂漂亮亮，然后躺在文档库里吃灰。我见过不止一个团队，花了很大力气搭好评估体系，最后大家还是凭感觉上线。原因就是评估没有和流程绑定。
我的做法很简单：把评估变成prompt迭代的强制检查点，跟代码里跑单元测试一个地位。改动prompt的人必须提供新旧版本在同一套用例集上的回归对比。没有这个对比，不并主版本。刚开始大家嫌麻烦，但坚持一段时间后，那些“我觉得没问题”的侥幸心理基本就绝迹了。实际上，这恰恰是框架能不能发挥价值的最后一道关口。
最后分享一个我自己实践出来的小习惯：真正动手改prompt之前，先花三分钟把当前版本的基线分数跑出来，记录到随手能翻到的地方。改完之后再跑一遍，只比对差异。这个习惯坚持下来，你会发现自己对prompt的判断准度会上升一个层次，因为你的“直觉”已经被大量数字校准过了。如果你做评估框架时只能留一个指标，那就留最核心任务准确率，其他都可以往后排。我就是靠这个指标，把许多眼看要翻车的prompt救了回来。
