每次改提示词全凭“手气”你改完感觉不错但说不清楚到底好在哪、坏了在哪。我接手某个项目的提示词维护时第一件事就是翻历史版本结果发现十几个版本散落在聊天记录里每个版本改了什么、为什么改、效果如何全都是一笔糊涂账。同事描述某次改动是“感觉顺了很多”另一次是“好像变蠢了”。这种纯靠体感的迭代方式在一个提示词只服务一个场景时还能勉强应付一旦要同时管十几个任务、几十个模板就完全失控。所以我给这个项目定了一条硬规矩没记录评估结果就不允许改提示词。这个「提示词评估与优化」项目本质上是把提示词迭代从“玄学”变成“工程”立标准、建评测集、做迭代记录每一步都用数据说话。这篇笔记把完整流程拆开写清楚适合两类人看一是刚上手提示词、希望有一套可复用的调优方法的初学者二是已经在业务里大量使用大模型、需要对提示词版本做精细化管理的开发者或产品负责人。1. 先搞清楚评估到底在评什么1.1 没有评估就没有优化一个反例很多调优动作是“为了改而改”。比如某个客服场景的系统提示词原先有一句“请用简洁的语言回复”。有同事觉得“简洁”太模糊改成“请用不超过50字的一句话回复”。看起来更明确了但上线后发现负面反馈增加部分答案信息量不足遇到需要列出多个可选方案的问题时50字根本装不下。改回去也一样不行——原来的“简洁”虽然没有硬长度但因为约束松散模型有概率输出一大段车轱辘话。你看两个版本各有各的问题但如果当时只是凭感觉改就不会知道问题出在哪。真正该做的事是先定义“什么叫一个好的回答”再拿同一批问题去测两个版本看各自在哪些维度上得分高、哪些维度扣分多。没有评估体系所有优化都只是立场而非结论。1.2 五个评估维度稳定性、达标率、完整度、格式合规、效率我给这套评估体系定义了五个核心维度每个维度都可以量化打分或做通过式校验维度评什么量化方式稳定性同一提示词、同一问题在多次调用中输出是否跑偏同一问题跑5次统计逻辑主干一致的次数达标率回答是否满足硬性要求字数、格式、步骤数等逐条检查计算通过比例完整度回答是否覆盖问题里的所有关键点人工或二级模型核对要点覆盖数格式合规结构化输出能否被下游直接解析JSON/XML校验错误率效率输出是否有冗余信息、是否绕弯子有效信息密度评分或按业务规则扣分稳定性是我最看重的维度也是大多数人忽略的。很多人只跑一次就下结论但大模型有随机性一个提示词可能这轮表现惊艳下一轮就语义跑偏。尤其在生产环境里稳定性比单次效果上限更重要。完整度和达标率则是业务侧的感受来源很多“模型回答质量不行”的反馈拆开看其实都是这两个维度的问题——要点漏了、硬约束没遵守。行业里还有一种做法叫“离线评估四元组”正确性、相关性、忠实度、无害性。我上面这套偏工程实践你可以按自己场景增删维度。做推荐类的项目可能要加“多样性”和“新鲜度”做代码生成类的要加“可编译率”和“测试用例通过率”做创意文案类的要加“风格一致性”。实际上这就是把你对结果的期待翻译成可测量的语言。2. 评测集是地基真题集怎么搭2.1 为什么要建私有评测集而不是直接扒公开题库评估要跑在评测集上评测集的质量直接决定评估结论的可靠性。我一开始图省事直接拿公开的通用问答数据集来测跑了几天发现没什么参考价值这些题目和我的业务场景差得太远模型在通用题库上得分高低跟它在真实任务上的表现完全是两码事。另一个隐患是数据污染——公开题库大概率已经混进模型的训练语料里了你拿它测出来的分数会虚高根本没有评估意义。所以我建议评估集一定要自己搭至少核心题目必须是针对你真实业务的。这个工作确实费时间但它是整个评估体系的压舱石这一步偷懒后面优化得再好都是空中楼阁。2.2 评测集的结构与格式评测集不是简单列一堆问题建议每道题都带三个字段输入、期望要点、校验规则。我通常用JSON格式来维护评测集既能被脚本直接读取又能保留人工可读性。下面是一个简化示例{ task: 移动端推送文案生成, cases: [ { id: case_001, input: 向用户推送本周会员日优惠主打咖啡买一送一时段是本周六和周日, expected_points: [ 包含活动名称会员日, 包含优惠内容买一送一, 包含活动时段周末两天 ], rule_checks: [ { type: length, max: 30 }, { type: keyword, must_include: [会员日, 买一送一] }, { type: keyword, must_not_include: [限时抢购] } ] } ] }这里的expected_points是人工归纳的回答必须覆盖的要点rule_checks是可程序化校验的硬规则。有了这个数据结构后面做自动化评估就有依据了——每一题都能对照检查“该说的说了没、不该说的说了没”。2.3 题量建议与迭代式扩充很多人第一次搭评测集就想搞一个几百道的“大全套”我建议别这样。评测集需要长期维护如果你一开始就堆太多题后面自己都不想跑——单次调用成本高不说人工阅卷更是噩梦。我的建议是分阶段起步阶段先整理20-30条真实业务里最常见、最典型的输入覆盖常规场景即可。目的不是追求全面而是先有一套可重复跑的基线。分桶阶段在几十条题目基础上按难度和类型分桶比如简单/中等/困难三个层级或者按功能模块划分。分桶的用途是看优化有没有“偏科”——整体分数上去了可能是简单题的全在涨难题反而退步了。补题阶段从日常bad case里不断吸收新题进评测集。线上哪个回答翻车了、用户反馈哪个问题处理得差了就把对应的输入加入评测集作为回归用例。这一步是评测集持续有效的核心驱动力。关于题目数量30题起步完全够用重点是均匀覆盖业务场景等稳定跑通后再慢慢扩充到100题以上。评测集永远在长不要指望一次性做完美。3. 多维评估方法从人工到自动化3.1 快速人工评估逐条打分与对比评测集的题量不大时人工评估依旧是最准确的方式。但纯人工打分有个致命问题——顺序效应。比如你连续看三个回答第二个明显很差第三个中等偏上你可能就给了第三个高分但如果第三个前面是一个很好的回答同一个答案你可能就打低分了。这是人的认知局限跟认真程度无关。所以人工评估时我固定用两个技巧盲评和两两对比。盲评是把答案和提示词版本分离阅卷人只看到答案本身不知道这是哪一版提示词产出的两两对比是一次只比较两个答案的优劣不直接打绝对分最后把所有对比结果汇总成排序。这样得到的结论比孤立打分可靠得多。打分标准也要提前写死不能“凭感觉给分”。比如“越狱风险”要定义清楚什么程度算低危、什么算高危最好给出正反例子让参与评估的同事都有同一个尺子。这跟你做代码评审是同一个道理没有评审标准评审就会变成个人审美大赛。3.2 程序化校验把“硬规则”扔给脚本评测集里那些没有争议的校验项应该直接自动化别浪费人工阅读时间。比如字数限制、JSON格式、敏感词过滤、必备关键词都可以写脚本跑。我实际执行时用的是这样的逻辑import json def validate_by_rules(output: str, checks: list): results {} for check in checks: if check[type] length: results[length] len(output) check[max] elif check[type] keyword: results[keyword] all(k in output for k in check[must_include]) elif check[type] forbidden: results[forbidden] not any(k in output for k in check[must_not_include]) return results这段代码只是一个简陋演示但它已经能拦截很多明确问题了。真正跑起来时结构化输出的评估还可以更进一步如果你的提示词要求模型返回JSON对象那就可以引入JSON Schema校验把“字段名对不对、类型对不对、缺没缺字段”一次性检查完。这类校验是零主观的校验结果可以直接写进测试报告成为版本对比的一部分。但要注意程序化校验永远替代不了完整度评估。机器能检查“关键词出现了没”却很难判断“一句看似在理的话是不是真正回应了用户的问题”。这类判断需要留给人工或者用大模型裁判来做。3.3 大模型裁判评估LLM-as-Judge题量变大之后全人工阅卷不现实我的做法是用一个独立的模型实例当裁判先做初筛再人工复核存疑项。这就是行业里常说的LLM-as-Judge。裁判模型的关键是给出明确的评分标准不然它打出来的分也是“玄学”。我常用的一套Judge提示词模板长这样你是一名严格的回答质量评估员。你会收到一个问题、一个参考答案要点列表、以及一个待评估的回答。 请按以下规则打分0-10 1. 先判断回答是否覆盖了所有参考答案要点每个要点覆盖得是否充分 2. 若回答包含与问题无关的信息扣2分 3. 若回答存在事实性错误每处扣2分 4. 若回答结构混乱扣1分。 输出格式 {score: 7, reason: 覆盖了1/3个要点存在一处冗余信息}这个模板有两点很关键一是给出了扣分规则而不是让模型凭感觉打“综合分”二是要求先列理由再给分把评分过程显式化方便人工追溯。实测下来带理由的评估比直接打分稳定性好得多因为这个过程强制模型做推理而不是拍脑袋。对裁判模型和被测模型我会刻意不把它们做成同一个实例。为什么因为同一模型天然偏好自己的输出风格——让模型给自己打分它容易给“跟自己风格像”的回答高分。用不同的模型实例或者不同厂商的模型做裁判能缓解这种自偏置。另一种做法是“多裁判投票”两个或三个裁判模型独立打分取中位数或均值遇到分歧过大的case再做人工复核。4. 优化实操一套可复跑的迭代闭环4.1 建立基线先找到“现在最惨也最真实”的水平优化的第一步不是“动手改”而是“别动”把当前版本的完整成绩留档。我用一张基线表来记录具体格式可以参照这个| 版本号 | v0.1-baseline | 场景 | 移动端推送文案 | | 评测集 | eval_push_v332题 | 温度 | 0.7 | | 总分 | 21.5/64 | 达标率 | 62.5%20/32 | | 稳定通过率 | 50%同题5跑3次稳定 | | 主要失分点 | 字数超标12题缺活动时段6题格式错误3题 |基线版本不追求好看它的价值在于给你一个比较的原点。后面任何一版的提示词改动都要以“比基线好多少”为衡量标准。如果改了一版分数比基线还低那就说明改动方向有问题别硬留。另外基线记录里我会固定写死几个运行参数温度、随机种子、模型版本号。为什么因为换一个模型版本或调了温度输出的分布就变了这时候说“提示词优化了15%”就是一个假命题——你根本分不清是提示词的功劳还是参数的功劳。控制变量不只在改提示词时成立在评估环境里同样成立。4.2 单变量实验一次只改一个点迭代过程中最容易掉的坑是一次改太多。常见操作是在提示词里加了示例同时改了角色设定还把输出格式从文本调成了JSON。结果分数确实涨了——但你要么说不清是谁的功劳要么某个改动其实在拖后腿只因另一个改动的正收益把它掩盖了。所以从基线之后我强制自己做单变量实验每次只改一个变量其他全部保持不变跑完评测集后把结果记录在案。这个习惯非常反直觉尤其在你“很有灵感”的时候你会特别想一口气把三个想法全塞进去试。但按我的经验老老实实做单变量实验看着慢整体效率反而高——你每一步都知道自己在验证什么假设不会出现“改了个版本效果变好了但不知下次该如何复现”的窘境。做实验的同时每一版都要做好版本留档版本号、改动内容、运行参数、评测分数、失分点明细。这个留档工作你可以在评测集里建一个history字段也可以直接用一张表格手动维护。目的是一样的任何一次改动都能追溯到原因和结果。4.3 典型优化手法与实测效果优化手法没有黄金标准不同业务形态适用的手段差别很大。但有几个高频有效的方向几乎每个项目都值得试一试。第一个是角色锚定。同一个任务把“请输出一份用户流失分析报告”改成“你是一名资深数据分析师请输出一份用户流失分析报告”效果往往有明显的差异特别是在语言风格和结构完整度上。这个手法在那些需要“专业感”输出的场景下尤其有用。但注意不要滥用过度铺陈角色背景反而会让回答变啰嗦。第二个是约束下沉。把“注意回答不要跑题”这种模糊的上层要求改成具体的、可执行的下层约束。比如“不要跑题”可以细化成“回答中每一句话都必须与用户问题中的关键词相关无关信息将视为错误”。模型对“具象可执行的规则”的遵循度远高于对“抽象原则”的遵循度这个经验在很多实测里都成立。第三个是few-shot示例注入。在提示词里给1-3个“标准答案示例”模型输出的风格方差会明显收窄比写十句“请简洁”都管用。示例的选择也很重要示例得尽量覆盖目标场景的典型输入变体让模型在模仿时有参照系。我见过有人塞了五个风格完全不同的示例进同一条提示词结果模型输出像精神分裂这就是示例之间互相打架的典型案例。示例数量建议控制在1-3个并且风格一致性要高。第四个是输出格式显式化。如果你希望模型返回JSON就直接在提示词里给出JSON模板甚至给一个填充了假数据的示例。模型对“给出模板”的遵循度远高于“描述你要什么格式”。有效的提示词公式大致是请返回以下JSON格式不要输出任何其他内容 {summary: 一句话总结, steps: [步骤1, 步骤2], risk_level: low|medium|high}实测下来这种方式把格式解析失败率从20%左右压到了3%以内代价仅仅是提示词长了几十个字符。我不太建议真的在提示词里写什么“万能公式”因为这些公式往往是经验总结而非原理推导换个场景就不灵了。更靠谱的方法是把上面这些手法当作假设池每次验证一个看评测集的分数说话。5. 常见问题与排查实录5.1 同一提示词两次跑分差很多刚开始跑评估时我遇到的最可疑的现象是同一个提示词同一套评测集早上跑一遍晚上再跑一遍总分差出20%。排查了半天最后发现原因很简单——温度没固定。早上的脚本温度是0.2下午某个同事调了一版参数之后没改回来温度变成了0.9。高温度下模型输出方差变大同一道题两次回答完全不是一回事分数自然剧烈波动。所以要做可复现评估核心经验是温度固定为0其他采样参数也不要动。评估场景跟生成场景不一样生成场景需要多样性所以要靠温度、top_p这些参数来调节评估场景要的是“同一输入测出稳定的质量下限”温度设为0才能让输出尽量可复现。即便是温度0LLM的采样也可能有少量随机性所以真正确认一个版本是否稳定最好同一问题跑3-5次看结果是否一致而不是只跑一次就下结论。5.2 LLM裁判评出来的分数不够稳大模型裁判的评分也有抖动问题。解决思路前面提到过多裁判投票和人工复核兜底。这里补充一个具体场景——长度偏置。实测下来裁判模型普遍偏爱长答案哪怕长答案里有大量废话它的情感分也天然偏高。遇到这种问题单纯修评判提示词优先级不高更有效的做法是在Judge的提示词里直接写“若答案存在冗余信息请相应扣分”并且给一个“短而准”的正面示例和一个“长而水”的反面示例。这个比只写一句“不要偏袒长答案”有用得多。另一个经典问题是“位置偏置”被测答案的顺序会影响裁判打分。解决办法是打乱顺序盲评同一组答案用不同的排列跑两轮交叉验证结论。5.3 越优化越“偏科”还有一个隐蔽但非常普遍的坑评测集里的题目越跑越熟提示词越来越像在“背题”真实场景的新问题反而处理不好。本质是评测集过拟合——你不断根据评测集的反馈调提示词提示词开始记忆评测集里的特定输入而不是归纳通用的解题规律。这个问题的典型信号是评测集分数一路走高但线上bad case率不降反升或者换了新输入后效果明显变差。对应的方法是定期往评测集里混入新题、留一份“不参与迭代的验证集”、并关注分桶分数有没有偏科。我自己的操作习惯是简单题和中等题分高不稀奇重点是难题桶的分数有没有同步提升如果难题桶长期不变甚至掉分那就说明优化在走捷径。5.4 团队协作时拿不出门禁标准最后这个问题发生在协作层面。一个人调提示词时“分数涨了”就是标准但多个人一起协作时就麻烦了。项目组里两个同事对“字数限制”的理解都不同一个人觉得是“输出总字数不超过30”另一个人觉得是“核心语句不超过30字其他可以自由发挥”。两个人各改了一版评分标准都不一样数据根本没法合并。这个问题的解法不是靠商量而是靠把评估标准写进文档并做代码化门禁。比如评测集脚本跑出分数后低于某个阈值的提示词不允许走进生产配置格式校验失败率超过5%直接亮红灯。一旦有机器可执行的门禁团队讨论就有一个共同语言了。实操层面我建议哪怕项目很小也要准备一份《评估标准说明》把每个维度的打分明确定义下来附上正面例子和反面例子。这个文档在初期看起来像“形式主义”但等团队规模超过两个人、提示词版本超过20个时它就成了救命的锚点。根据我的个人经验这套评估和优化流程跑顺之后最大的变化不是分数涨了多少而是你终于能自信地说出“为什么这个版本更好”。评估不是走流程它是把模糊的“感觉”翻译成精确的“指标”的过程。从30道题的小评测集开始从第一张基线表开始只要坚持“先评估、后优化、留记录”这三个习惯提示词工程就不再是碰运气了。