08｜提示词的迭代优化：像调参一样调prompt

场景引入：为什么你的prompt”时灵时不灵”

你为客服团队搭建了一个AI辅助回复系统。prompt写好之后，测试了五六条用户投诉，回复质量都不错，于是上线了。

第一周反馈还行。第二周开始，客服主管找过来说：“有些回复太机械了，有些又太啰嗦，偶尔还会承诺我们根本做不到的赔偿方案。”

你回去看了看那几条问题回复，发现prompt本身没有明显的错误——只是它在某些边界情况下表现不好。比如用户用方言表达不满时AI理解偏差、用户同时投诉多个问题时AI只回应了第一个、用户要求的赔偿超出权限时AI没有适当拒绝。

这种情况太常见了。第一版prompt几乎不可能是最好的版本，就像机器学习中第一轮训练的模型不可能直接上线一样。prompt需要系统化的迭代优化，而不是凭感觉修修补补。

如果你有机器学习的背景，可以这样类比：prompt就像模型的超参数配置。模型训练有一套成熟的方法论——定义损失函数、准备验证集、调参、评估、再调参。prompt优化同样需要这套流程，只是”损失函数”变成了人工定义的评估标准，“验证集”变成了一组精心设计的测试用例。

没有机器学习背景也没关系。你可以把prompt优化想象成调一道菜的味道：先确定”好吃”的标准（评估），然后试做一次（测试），品尝后发现太咸了（分析），少放点盐再试（改进）。循环往复，直到满意。

---

迭代优化的四步循环

一个结构化的prompt优化流程包含四个步骤，反复循环：

定义评估标准 → 测试 → 分析失败案例 → 改进prompt
      ↑                                    |
      +------------------------------------+

第1步：定义评估标准

在动手改prompt之前，先明确”什么算好的输出”。没有评估标准的优化就是在碰运气。

以客服回复系统为例，评估标准可以这样定义：

维度	权重	具体标准
准确性	30%	回复中不包含错误信息或不可兑现的承诺
完整性	25%	用户提出的每个问题/诉求都被回应到
语气恰当性	20%	专业且有同理心，不过于机械也不过于随意
格式规范	15%	符合公司客服回复模板的格式要求
边界处理	10%	超出权限的请求能恰当地转接人工或说明限制

关键原则：评估标准要在优化之前定义，而不是看到输出之后临时编造。这就像考试前要先有评分标准，而不是改卷时才决定怎么打分。

第2步：测试

准备一组覆盖不同场景的测试用例，用当前版本的prompt跑一遍：

编号	测试用例描述	预期行为
T01	标准退款投诉	确认问题 → 道歉 → 说明退款流程 → 给出时间预期
T02	用户同时投诉发货慢和商品破损	两个问题都要回应
T03	用户情绪激动，使用夸张表述	先安抚情绪，再解决问题
T04	用户要求超出权限的赔偿	说明权限限制，建议转人工
T05	用户提供的信息不足以判断问题	礼貌地追问必要信息
T06	非投诉类咨询（如查物流）	直接提供信息，不必道歉
T07	用户用方言或非标准表述	能正确理解意图
T08	用户反复投诉同一问题	认可前次投诉经历，升级处理

好的测试集有三个特点：

• 覆盖面广：包含正常情况和各种边界情况
• 有预期输出：每条测试都有明确的”应该怎样回复”的预期
• 可复现：同一组测试可以在不同版本的prompt上反复运行

第3步：分析失败案例

跑完测试后，逐条对照评估标准，标记哪些通过、哪些失败。对失败案例重点分析为什么失败。

T02 失败分析：
- 现象：用户同时投诉发货慢和商品破损，AI只回应了破损问题
- 原因推断：prompt中写了"针对用户的问题给出回复"（单数），
  没有明确要求处理多个问题的情况
- 改进方向：在prompt中增加"如果用户提到多个问题，需逐一回应"的指令

T04 失败分析：
- 现象：用户要求赔偿500元，AI直接答应了
- 原因推断：prompt中没有设定赔偿权限范围
- 改进方向：在prompt中添加赔偿权限规则（如"单笔赔偿不超过100元"）

分析失败原因时，一个有效的思维框架是问自己：这是prompt缺失了什么信息/规则，还是现有的指令表述不够清晰？

• 如果是缺失 → 需要添加新的规则或约束
• 如果是不清晰 → 需要改写现有的指令，消除歧义

第4步：改进prompt

根据分析结果修改prompt，然后回到第2步重新测试。注意：每次只改一个地方。如果同时改了三处，测试通过了你也不知道是哪个改动起了作用；测试失败了你也不知道是哪个改动引入了新问题。

这就像科学实验的控制变量法——每次只变一个因素，才能确定因果关系。

---

五种常见失败模式及修复方法

在大量的prompt优化实践中，以下五种失败模式出现频率最高。

失败模式一：输出太泛，缺乏细节

症状： AI的回复正确但空洞。比如你问”如何提升系统性能”，它回答”可以从前端、后端、数据库三方面优化”——没错，但等于没说。

诊断： prompt中缺少对具体性的要求，也没有示例来标定”多具体才算够”。

修复方法：添加具体约束和示例

修复前：

请分析这段代码的性能问题并给出优化建议。

修复后：

<task>
请分析以下代码的性能问题并给出优化建议。
</task>

<requirements>
每个性能问题需要包含：
1. 具体的代码行号或代码片段
2. 问题的技术原因（为什么这里慢）
3. 量化影响评估（如"在10万条数据下，这个操作耗时约X毫秒"）
4. 具体的修复代码（不是思路，是可以直接使用的代码）
</requirements>

<example>
问题1：第15行的嵌套循环
- 代码：for item in orders: for sku in item.skus: ...
- 原因：双重循环导致O(n*m)时间复杂度，当orders为5000条、
  每条含20个SKU时，循环体执行10万次
- 修复：用字典预构建SKU索引，将查找降为O(1)
- 修复代码：（具体代码）
</example>

失败模式二：不遵守格式要求

症状： 你要求用表格输出，AI却用了列表。你要求JSON，AI却输出了带注释的伪代码。

诊断： 格式要求和内容指令混在一起，AI在处理复杂内容时”忘记”了格式约束。

修复方法：用结构化标签隔离格式要求，必要时用示例强化

修复前：

分析以下三个方案的优缺点，用表格展示。

修复后：

<task>
分析以下三个方案的优缺点。
</task>

<output_format>
必须使用以下Markdown表格格式输出，不要使用其他任何格式：

| 方案 | 优点 | 缺点 | 推荐度 |
|------|------|------|--------|
| 方案A | （列出2-3个优点） | （列出2-3个缺点） | 高/中/低 |
| 方案B | ... | ... | ... |
| 方案C | ... | ... | ... |

表格之后，用一段话（不超过100字）总结你的推荐。
</output_format>

失败模式三：AI”编造”不存在的信息

症状： AI在回复中引用了不存在的数据、杜撰了虚假的事实、或者凭空创造了听起来合理但实际错误的技术细节。

诊断： AI天生倾向于”给出一个完整的回答”，当它不确定某个细节时，会倾向于填补空白而不是承认不知道。

修复方法：要求引用原文、明确允许说”不知道”

修复前：

根据这份技术文档回答以下问题。

修复后：

<task>
严格基于以下文档内容回答问题。
</task>

<constraints>
1. 每个回答必须先引用文档中的原始文字（用引用块格式），再给出你的分析
2. 如果文档中没有包含回答某个问题所需的信息，请明确回复
   "文档中未提供相关信息，无法回答此问题"
3. 不要基于你的通用知识来补充文档中没有的内容
4. 如果文档中的信息存在歧义，指出歧义点，给出多种可能的理解
</constraints>

这个修复的关键是给了AI一条”出路”——允许它说不知道。很多时候AI编造信息不是因为它想骗你，而是因为它觉得”必须给一个答案”。

失败模式四：输出不一致

症状： 同一个prompt、同样的输入，每次运行的输出差异很大。有时候质量很好，有时候差得离谱。

诊断： 这通常与两个因素有关——prompt本身的指令模糊（留给模型的”自由发挥空间”太大），以及模型的采样参数设置。

修复方法：增加约束减少自由度 + 调低temperature

修复前：

写一份技术方案评审意见。

修复后：

<task>
为以下技术方案撰写评审意见。
</task>

<requirements>
评审意见必须包含以下四个固定段落，不多不少：

1. 【方案概述】用1-2句话复述方案的核心思路（确认你理解了方案）
2. 【肯定之处】列出2-3个方案做得好的地方，附简要理由
3. 【改进建议】列出2-4个需要改进的地方，每个包含：
   - 当前方案的具体问题
   - 建议的改进方向
   - 改进后的预期效果
4. 【总体判断】给出通过/有条件通过/不通过的结论，附一句话理由
</requirements>

同时，如果你可以控制API参数，将temperature从默认的0.7或1.0调低到0.2-0.3，可以显著减少输出的随机性。

失败模式五：AI过度谨慎

症状： AI在每句话后面都加上”但这取决于具体情况”、“仅供参考，建议咨询专业人士”、“这只是一个初步分析”之类的免责声明，导致输出充满了水分。

诊断： AI经过安全训练后，对不确定的事情倾向于保守表达。这在某些场景下是好事（如医疗建议），但在很多工作场景下会让输出变得冗余和不实用。

修复方法：明确告知可以给出直接判断，设定信心度标注规范

修复前：

请评估这个投资项目的可行性。

修复后：

<task>
请评估以下投资项目的可行性。
</task>

<style_guide>
1. 给出明确的判断和建议，不要用"取决于具体情况"之类的模糊表述
2. 如果你的判断有不确定性，用数字量化你的信心度（如"我对此判断的
   信心度为70%，主要不确定因素是市场增速假设"）
3. 不需要添加"仅供参考"等免责声明——使用者了解这是AI辅助分析
4. 在不确定时，与其回避判断，不如给出你最倾向的判断并说明理由和
   风险点，让决策者自己权衡
</style_guide>

---

A/B测试你的prompt

当你对prompt做了一个修改但不确定是变好了还是变差了，最可靠的方法是A/B测试。

方法

1. 准备一组测试用例（至少10条，覆盖不同场景）
2. 用旧版prompt（版本A）跑一遍所有测试用例，记录输出
3. 用新版prompt（版本B）跑一遍同样的测试用例，记录输出
4. 对每条测试用例，按评估标准打分
5. 对比两个版本的总分

评分表模板

测试用例	版本A得分	版本B得分	变化	备注
T01 标准投诉	8	9	+1	新版语气更自然
T02 多问题投诉	5	8	+3	新版增加了逐一回应的指令
T03 情绪激动用户	7	7	0	无变化
T04 超权限赔偿	3	8	+5	新版增加了权限规则
T05 信息不足	6	6	0	无变化
平均分	5.8	7.6	+1.8	B版本整体更优

注意不要只看平均分。检查有没有某条测试用例退步了。如果T03从7分降到了4分，即使总分上升，也需要调查原因——你可能在解决一个问题时引入了新的问题。

---

参数与prompt的协同调优

大多数AI API提供了几个关键的采样参数，它们和prompt内容共同决定了输出质量。

temperature

控制输出的随机性。范围通常是0到2（更详细的参数说明参见第 1 章”LLM 的关键参数”一节）。

temperature值	效果	适用场景
0 - 0.3	输出高度确定，接近贪心解码	数据提取、格式化输出、事实性问答
0.4 - 0.7	适度随机，兼顾准确性和多样性	分析报告、技术方案、通用对话
0.8 - 1.2	较高随机性，更多创意和意外	创意写作、头脑风暴、多样化生成
1.3+	高度随机，可能出现不连贯	很少使用

一个重要的认知：温度不是越低越好。低温度会让AI倾向于选择最”安全”的表达，在创意任务中反而会产出平庸的结果。

top_p（核采样）

另一种控制随机性的方式。top_p=0.9意味着模型只从概率排名前90%的候选词中采样。

top_p值	效果
0.1 - 0.3	极为保守，几乎只选最高概率的词
0.5 - 0.8	适度多样性
0.9 - 1.0	保留大部分候选词

一般建议：要么调temperature，要么调top_p，不要同时调两个。同时调整会让效果难以预测。

参数与prompt的配合策略

目标	prompt策略	参数策略
精确的数据提取	严格的格式要求 + 示例	temperature=0, top_p=1
稳定的分析报告	结构化模板 + 固定段落	temperature=0.3
多样的创意方案	鼓励发散 + 不限格式	temperature=0.8-1.0
代码生成	明确的功能需求 + 语言规范	temperature=0-0.2
对话式交互	角色设定 + 语气指引	temperature=0.5-0.7

---

建立prompt changelog

专业的prompt工程师会为每个重要的prompt维护一份变更日志。这不是形式主义——当你三个月后发现某个prompt表现退步时，changelog能帮你快速定位什么时候改了什么。

格式建议

# 客服自动回复 prompt changelog

## v4.2 (2026-03-10)
- 修改：增加了方言和口语化表述的处理规则
- 原因：T07测试用例连续3次不通过（方言投诉理解偏差）
- 效果：T07通过率从40%提升到85%，其他用例无退步
- 测试结果：平均分从7.6提升到7.9

## v4.1 (2026-02-28)
- 修改：将赔偿权限规则从"不超过订单金额"改为"不超过100元或订单
  金额的20%取低值"
- 原因：出现了几次小额订单给出过高赔偿承诺的情况
- 效果：T04和T08测试通过，赔偿准确率100%

## v4.0 (2026-02-20)
- 重大更新：从非结构化prompt重构为XML标签结构化版本
- 新增：<constraints>区块明确列出了7条限制规则
- 新增：<examples>区块包含3个正面和2个反面示例
- 效果：整体测试平均分从5.8提升到7.6

每条changelog记录四个要素：改了什么、为什么改、效果如何、测试数据。

---

从手动迭代到系统化评估

当你管理的prompt数量超过个位数时，手动测试每个prompt的每个测试用例会变得不可持续。这时候需要建立更系统化的评估体系。

自动化评估的思路

最简单的自动化方式是用AI来评估AI。你可以设计一个”评估用prompt”，让它按照你定义的标准对输出进行打分：

<role>
你是一个严格的质量评审员。
</role>

<task>
请根据评估标准，对以下AI回复进行打分。
</task>

<scoring_criteria>
1. 准确性（0-10分）：回复中的信息是否全部正确
2. 完整性（0-10分）：是否回应了用户的所有问题
3. 语气（0-10分）：是否专业且有同理心
4. 格式（0-10分）：是否符合规定的回复格式
</scoring_criteria>

<user_message>
{{用户的原始消息}}
</user_message>

<ai_response>
{{AI的回复内容}}
</ai_response>

<output_format>
请输出JSON格式：
{
  "accuracy": {"score": N, "reason": "..."},
  "completeness": {"score": N, "reason": "..."},
  "tone": {"score": N, "reason": "..."},
  "format": {"score": N, "reason": "..."},
  "total": N
}
</output_format>

这样你就可以批量跑测试用例，自动获取分数，然后只人工审核低分项。

从prompt优化到prompt系统

当你的优化流程成熟之后，prompt本身就只是系统中的一个组件。一个完整的prompt工程体系包括：

组件	作用
prompt模板	核心的提示词内容
测试用例集	覆盖各种场景的输入和预期输出
评估标准	明确的打分维度和权重
自动评估prompt	用于批量打分的评审prompt
changelog	每次修改的记录和效果追踪
参数配置	与prompt配套的temperature等参数

这套体系建立起来后，prompt的迭代就从”凭感觉修改”变成了”数据驱动的工程实践”。后续的系统工程篇会进一步展开这个话题。

---

本章回顾

概念	说明	关键实践
四步循环	评估标准→测试→分析→改进	每次只改一个变量
测试用例	覆盖正常和边界场景的输入集	至少10条，有明确预期
失败模式修复	5种常见问题的诊断和修复方法	输出太泛→加约束；编造→允许说不知道
A/B测试	新旧版本在相同测试集上对比	关注总分和单项是否有退步
参数协同	temperature/top_p与prompt配合	精确任务低温度，创意任务高温度
changelog	记录每次修改的原因和效果	改了什么、为什么、效果、数据

核心原则： 优秀的prompt不是一次写出来的，而是通过系统化的测试-分析-改进循环迭代出来的。定义好评估标准，用数据而不是直觉来指导优化方向——这是prompt从”个人技巧”升级为”工程实践”的关键转变。

---

思考题

1. 选择你正在使用的一个prompt，为它定义3-5个评估维度和一组至少5条测试用例。运行测试后，你最大的发现是什么？

2. 以下两个版本的prompt，你认为哪个更好？设计一个实验来验证你的判断：

   • 版本A：你是一个专业的代码审查员。请审查以下代码，给出改进建议。
   • 版本B：你是一位有15年经验的后端架构师。请审查以下代码，对每个发现的问题，说明问题原因、影响程度（高/中/低）、和具体的修复方案（给出修改后的代码）。如果代码没有明显问题，也请指出值得学习的优秀实践。

3. 回想一下你使用AI时遇到过的”编造信息”的情况。用本章介绍的修复方法，重新设计prompt来避免这个问题。测试3-5次，观察改善程度。