调提示词的现场常常是这样：
改一版，试几个问题，觉得回答变好了；再改一版，试另几个问题，好像又变差了。
改了十几版，说不清哪一版最好，也说不清每一版具体改进了什么。
问题不在于不够努力，而在于缺少一套能给出确定答案的机制。
这篇文章给出这套机制。核心观点有点反直觉：
提示词的优化效果，主要不是靠"写出更好的措辞"，而是靠"建立能判断好坏的流程"。
第一部分：先有一份能对比的样本
没有样本集，所有改动都只能靠印象。
1.1 样本集怎么建
三个来源，按价值排序：
| 来源 | 内容 | 为什么这个顺序 |
|---|---|---|
| ① 真实失败案例 | 线上出错的、用户投诉的、人工发现不对的 | 最有价值，因为它们代表真实分布 |
| ② 业务典型问法 | 让业务同事提供"用户最常问的 20 个问题" | 覆盖高频场景 |
| ③ 边界与对抗样本 | 空输入、超长输入、矛盾要求、试图诱导 | 防止在极端情况下翻车 |
1.2 规模建议
起步 30 到 50 条就够用。
别追求一次建全 —— 重要的是每次改动都跑一遍，让它随使用逐渐丰富。
"30 到 50 条"这个量级的设计考虑：
- 太少（如 5 条） → 噪声大，改动效果看不出来；
- 太多（如 500 条） → 跑一次太慢，你会懒得跑，而"懒得跑"等于样本集不存在。
1.3 一个硬性要求
每条样本都要有"期望结果"。
这个期望可以不是唯一答案，但必须能判断"这次输出是否合格"（比如必须包含某要点、必须符合某格式）。
"不是唯一答案"这一点很重要 —— 因为大量真实任务（总结、改写、建议）没有唯一正确答案，而如果坚持要求唯一答案，你会建不出样本集。
可行的做法是定义"合格判据"：比如"必须包含这三个要点中的一个""必须返回合法的 JSON"。
1.4 这一步的投入产出比
它把"凭感觉"变成了"有对照"。
第二部分：定义指标，而不是"感觉"
样本集有了，还需要能算出来的数。
2.1 四个指标
| 指标 | 定义 | 作用 |
|---|---|---|
| ① 任务准确率 | 输出是否满足期望 | 看效果 |
| ② 格式合规率 | 输出是否符合约定的结构 | 看效果，且直接决定下游可用性 |
| ③ token 成本 | 提示词变长会让每次调用更贵 | 看代价 |
| ④ 稳定性 | 同一个输入跑多次，结果是否一致 | 看代价 |
四个指标里，前两个看效果，后两个看代价。一起看，才能判断一次改动是不是"净收益"。
2.2 关于第二、四项
格式合规率"很容易被忽略，但它直接决定下游系统能不能用" —— 因为格式不对意味着解析失败，而解析失败意味着这个功能完全不可用。
稳定性是"生产里的隐患" —— 因为一个平均值很好但波动很大的系统，用户体验是"时好时坏"。
2.3 一个常见陷阱
只看准确率。
如果为了涨两个百分点，把提示词从 500 字扩到 3000 字，成本可能涨了三倍——这笔账要一起算。
这个陷阱的机制：准确率的提升是可见的（你立刻能看到"答对了"），而成本的上升是渐进的（账单下个月才出现）。
第三部分：单变量改动 + 版本管理
这是从"瞎调"变成"实验"的分水岭。
3.1 规则一：一次只改一处
如果你同时改了角色描述、输出格式和示例，结果提升了，你不知道是哪一处起作用；结果变差了，你也不知道该回退哪一处。
"不知道该回退哪一处"这个损失很大 —— 因为它意味着你可能放弃了一个本来有效的改动（只是被另一个无效改动抵消了）。
3.2 规则二：每版都记录
记录这四项：
① 版本号与时间
② 改了什么（一句话）
③ 指标变化（四个指标的前后对比）
④ 是否采纳，若不采纳则回退
3.3 规则三：保留历史版本
提示词必须能一键回到上一个好版本，和代码没有区别。
3.4 规则四：改动进代码库
不要把提示词散落在业务代码的字面量里，它应该是一个可追溯、可评审的独立资产。
"散落在字面量里"是当前最常见的状态 —— 而它导致三个问题：
- 看不到全貌（不知道该改哪些地方）；
- 无法评审（改动不经过 review）；
- 容易不一致（训练和推理用了不同版本，这正是前面讲微调排查时那个最常见失败原因）。
3.5 做完这四条
你的调优过程就变成了一条可回溯的实验记录。这比任何"提示词技巧"都更能提升长期效率。
第四部分：四个真正有效的技巧
技巧不少，但下面这四个是有机制支撑、跨模型普遍成立的。
4.1 技巧一：用正面指令，而不是禁令
与其写"不要输出多余的解释"，不如写"只输出一个 JSON 对象"。
原理：
模型按你给出的形态生成，你描述"要什么"比"不要什么"提供了更明确的目标。禁令往往只删掉了一部分，而正面指令直接约束了输出空间。
"禁令只删掉一部分"这个观察很关键 —— 因为**"不要输出解释"并没有告诉模型"该输出什么"，它可能输出别的东西**（比如换个形式的解释）。
4.2 技巧二：给示例，常常比描述更有效
对于格式与风格类要求，一到三个真实示例的效果，往往超过三段文字描述。
原理：
示例同时传达了格式、语气、长度、粒度——这些信息很难用描述穷尽。
"很难用描述穷尽"是核心 —— 因为这些是"看起来就知道对不对"的属性，而用语言描述它们既啰嗦又不完整。
这也是为什么"few-shot"在实践中如此有效。
4.3 技巧三：把复杂任务拆成多步
一条又长又复杂的指令，不如拆成两三次独立的调用（先抽取、再判断、再生成）。
原理：
每一步的任务更单一，模型的判断空间更小、更容易做对；而且中间结果可检查、可调试。
"可检查、可调试"这个附加价值很实际 —— 因为单次调用失败时，你无法知道是哪一步错了。
4.4 技巧四：明确输出结构
如果能用结构化格式（如 JSON、固定模板），就明确指定字段与取值。
原理：
它把"自由生成"变成"填空"，大幅降低格式漂移，也让下游系统能直接解析。
4.5 注意这四个技巧都有边界
| 技巧 | 代价 |
|---|---|
| 拆解 | 增加调用次数与延迟 |
| 结构化输出 | 限制表达自由度 |
| 给示例 | 占用上下文预算 |
| 正面指令 | 需要你想清楚"到底要什么" |
按场景取舍，别一刀切。
最后一条容易被忽略 —— 因为**"想清楚要什么"本身是有成本的**，而有时候模糊的指令反而更省事（只是效果不稳定）。
第五部分：五个反模式
这些做法很常见，但往往收益极小甚至有害。
5.1 反模式一：堆砌"魔法句式"
比如"你是世界顶级的专家，请极其认真地思考这个问题"。
这类话术的边际效果通常很小，而且会占用上下文预算。
更有效的替代：明确任务目标、约束条件、输出格式，并给出示例。
为什么"魔法句式"效果小？ 因为现代模型已经经过了指令微调 —— 它默认就会尽力完成任务，不需要你"求它"。
5.2 反模式二：一条提示词改全局
系统提示被多个功能共用，改一处影响全部场景。
某个场景变好了，另一个场景崩了。
更有效的替代：分层管理 —— 通用部分（角色、全局约束）与场景部分（具体任务）分开，按需组合。
5.3 反模式三：系统提示越来越长
每次遇到问题就往上加一句，半年后变成三千字。
结果是关键约束被淹没，模型注意力被稀释。
更有效的替代：
定期做一次精简，把能移到流程里（代码校验、结构化输出）的约束移出去，只留下真正需要模型判断的内容。
"移到流程里"这个动作很关键 —— 因为用代码能保证的事，不该交给提示词去"请求"。
5.4 反模式四：改动没有记录
三周后你发现效果变差了，但不知道中间改了什么。
更有效的替代：提示词纳入版本管理，改动留痕。
5.5 反模式五：只在几个"顺手想到"的问题上验证
这等于在做一个有偏的测试集。你会优化"你记得的那几个问题"，而不是"真实分布的多数问题"。
更有效的替代：用固定的样本集，并且持续从线上失败里补充新样本。
第六部分：把它做成一条流水线
把前面所有内容串起来，形成日常流程。
6.1 六个步骤
① 改提示词（一次改一处）
② 自动跑样本集（输出四个指标）
③ 与基线对比（关注是否"净收益"——效果与成本一起看）
④ 通过则合入并记录版本；不通过则回退
⑤ 定期从线上失败案例补充样本
⑥ 定期精简（防止提示词膨胀）
6.2 这条流水线的价值
它把提示词优化从"手艺"变成了"流程"。
流程可以交给多人执行、可以持续积累、不会因为人员变动而丢失经验。
"不会因为人员变动而丢失经验"这一点值得强调 —— 因为在手艺模式下，提示词的调优经验完全存在于某个人的脑子里，而这个人一旦离开，团队就回到起点。
第七部分：什么时候该停止调提示词
最后给一个止损判断，避免无止境打磨。
7.1 四个停止信号
信号一：改动收益持续低于噪声。
连续几版改动都在指标波动范围内，说明提示词已经不是瓶颈。
信号二：失败集中在一类问题上。
比如总是差某个字段、总是漏某个约束 —— 这更适合用代码校验或结构化输出解决，而不是继续加文字。
信号三：正确信息根本不在上下文里。
那是检索或上下文工程的问题，提示词救不了。
信号四：模型能力确实不够。
换成更强的模型、或换任务拆解方式。
7.2 一个判断
这四条出现任意一条，就该把精力转到别处。知道什么时候停，比知道怎么改更重要。
"知道什么时候停比知道怎么改更重要"这句话值得记住 —— 因为无限打磨提示词是团队最容易陷入的时间黑洞。
常见误区
误区一："提示词是文案工作，不需要工程规范。"
它直接决定线上效果、成本与稳定性，应当按工程资产来管理。
误区二："多试几版总能试出好的。"
没有对照与记录，多试只是产生更多无法归因的版本。
这句"产生更多无法归因的版本"很准确 —— 因为问题不是"版本多"，而是"无法知道哪个好、为什么好"。
误区三："提示词越长越全面越好。"
过长会稀释重点、抬高成本，而且让后续改动难以归因。
"让后续改动难以归因"这一点容易被忽略 —— 因为系统提示越长，你在改一处时更可能无意中影响另一处。
误区四："A/B 测试太麻烦，看几个例子就行。"
用几个例子判断，等于在优化"你恰好想到的那几个场景"。
误区五："提示词写得好就不需要其他手段了。"
提示词有它的能力边界。
| 问题类型 | 提示词能解决吗 |
|---|---|
| 表达不清 | 能 |
| 缺知识 | 不能（要检索） |
| 格式不稳 | 部分能（结构化输出更可靠） |
| 推理能力不足 | 不能（要换模型或拆任务） |
这条误区与前面讲"微调/RAG/提示词怎么选"时是同一个道理 —— 先诊断缺哪一层，再选工具。
误区六："提示词优化是一次性的工作。"
它是持续的过程。
原因：
- 模型会升级（新模型对提示词的响应可能不同）；
- 业务会变化（新的场景、新的约束）；
- 线上会暴露新的失败模式。
所以"定期复核"应该是流程的一部分 —— 而不是"上线后就锁死"。
实战问答
Q1：面试问"你怎么优化提示词"，怎么答得像有工程经验？
A：给流程而不是技巧。
① 先建样本集（含真实失败案例与边界样本）
② 定义四项指标（准确率、格式合规率、成本、稳定性）
③ 一次只改一处并记录版本
④ 通过则合入、不通过则回退
最后补一句判断：
"当收益进入噪声区间、或失败集中在某一类可规则化的问题上，就该停手，转向结构化输出或代码校验。"
最后这句是加分项 —— 它说明你知道"何时不该继续"，而这恰恰是工程判断力的体现。
Q2：我们团队的提示词散在各个服务里，怎么治理？
A：分三步。
| 步骤 | 做法 |
|---|---|
| ① 集中 | 集中到一个可版本管理的位置（而不是硬编码在业务代码中） |
| ② 分层 | 通用角色与约束、场景任务、输出格式分开 |
| ③ 加流水线 | 改动自动跑样本集 |
第二步收益最大，因为它解决了"改一处崩一片"。
为什么"分层"收益最大？ 因为它直接消除了最常见的破坏性改动（改全局约束影响所有场景）。
Q3：加了 few-shot 示例之后效果反而变差，为什么？
A：三个常见原因。
| 原因 | 机制 |
|---|---|
| ① 示例格式不一致 | 互相矛盾，模型学出"平均版" |
| ② 示例太长吃掉预算 | 挤压了真正的任务信息 |
| ③ 示例过于贴近某个场景 | 导致模型过度拟合那个场景 |
建议示例控制在 1 到 3 个，且格式严格统一。
第一条最常见 —— 而它的表现往往是"输出风格变得不稳定"，而不是"完全不对"。
Q4：提示词要不要写得很"礼貌"？
A：不必。模型不会因为你多说"请"而更努力。
把字数花在明确任务、约束、格式和示例上，回报高得多。
这个建议的依据是"token 是有限资源" —— 每一个字都在占用上下文预算，所以应该用在能产生差异的地方。
Q5：怎么说服团队"提示词要版本管理"？
A：用一个具体的事故场景来沟通。
"三周前我们的效果还不错，现在变差了。
谁能告诉我中间改了什么？"
→ 如果答案是"不知道"，那就是一个必须解决的问题。
然后给一个低成本方案：
"我们不需要一套复杂的系统。先做一件事：把提示词从业务代码里挪出来，放在一个独立文件里，改动时写一行备注。成本几乎为零。"
这个方案的好处是"门槛低" —— 而完整的版本管理流程可以在习惯养成后再补充。
Q6：怎么判断一次改动是不是"净收益"？
A：看四项指标的组合变化。
| 情况 | 判断 |
|---|---|
| 准确率涨、格式合规率涨、成本不变 | 明显净收益 |
| 准确率涨 2%、成本涨 3 倍 | 需要讨论（看这个场景值不值） |
| 准确率涨、但稳定性下降 | 谨慎（生产环境可能不可接受） |
| 准确率不变、成本下降 | 净收益（这类改动经常被忽略） |
最后一行值得注意："简化提示词但不损失效果"也是一种净收益 —— 而它经常被忽略，因为大家习惯只关注"效果提升"。
一个实用原则：优先做"降低成本或提升稳定性、且不损失效果"的改动 —— 它们没有风险。
Q7：样本集要不要包含"模型现在答得很好"的用例？
A：要，但比例要控制。
两类样本的作用不同：
| 类型 | 作用 |
|---|---|
| 失败/困难样本 | 推动改进（它们指出了问题） |
| 正常样本 | 防止回归（它们保证你没改坏别的） |
建议比例大致是 7:3 或 6:4（失败样本略多）。
如果全是失败样本，你会看不到回归（某些改动可能让原先好的用例变差）；如果全是正常样本，你没有改进方向。
术语表
| 术语 | 含义 |
|---|---|
| 样本集 | 用于评估提示词效果的一组带期望结果的用例 |
| 单变量改动 | 一次只修改一处，以便归因 |
| 格式合规率 | 输出符合约定结构的比例，直接决定下游可用性 |
| 提示词分层 | 把通用约束与场景任务分开管理，避免互相影响 |
| 提示词膨胀 | 系统提示因不断追加而变长，导致重点被稀释 |
| 净收益 | 效果提升抵消成本与稳定性代价后的综合判断 |
结语
把这篇压缩成三句话：
第一，提示词是代码：要有样本集、要有指标、要单变量改动、要版本记录、要能回滚。
一旦把它当工程资产管理，"改来改去没方向"的困境会自动消失大半。
第二，真正的技巧只有四个：
正面指令（要什么，而非不要什么）
给示例（1~3 个，格式统一）
拆任务（每次判断空间更小）
定结构（把自由生成变成填空）
第三，最重要的能力是知道什么时候停止调整。
当收益进入噪声区间、或失败集中在"可规则化"的问题上，就该把问题交给结构化输出、代码校验或检索。
而如果只允许带走一个动作，那就是：把提示词从业务代码里挪出来，放进一个独立的、有版本记录的文件。 因为它成本极低，却是所有后续治理工作的前提。
