提示词优化，是针对既定目标改进提示词的过程：更好的回答、更少的 token、更低的延迟，或更一致的格式。它与瞎折腾的区别在于度量。你先决定“更好”意味着什么，改动一处，再检查。
决定你要优化什么
一个提示词可以沿多个维度优化，而这些维度相互拉扯。
| 目标 | 度量方式 | 常见代价 |
|---|---|---|
| 质量 | 测试集上的通过率 | token |
| 一致性 | 同样的输入，同样形态的输出 | 灵活性 |
| 成本 | 每次调用的输入和输出 token | 上下文、示例 |
| 延迟 | 到首个和末个 token 的时间 | 推理深度 |
| 安全 | 对注入和泄露的抵抗力 | 部分可用性 |
选定一个主要目标，并为其他目标设定上限，例如“在不超过 800 个输入 token 的前提下提高通过率”。
优化循环
1. 先修复静态问题
有些缺陷不需要模型就能发现：没有目标、含糊的词、没有数字的大小、冲突的指令、没有输出格式、重复的句子、未加分隔的变量。在花钱调用模型之前先把它们清理掉。PromptFlowEngine 提示词分析器会逐条列出，并附上建议的修正。
2. 建立测试集
收集 20 到 50 个代表真实使用的输入。包括：
- 典型情形。
- 边缘情形：空输入、超长、混合语言、格式错误。
- 对抗性情形：试图改变指令的文字。
- 过去的失败。每个 bug 都变成一个测试。
对每个输入，写下正确输出必须包含或满足的内容。
3. 建立基线
用当前提示词运行每一个输入并记录结果。这个数字是每次改动的比较对象。没有它，你就无法区分改进和噪声。
4. 阅读失败案例
把它们分组。十个失败通常只有两三个原因。找出规律：是不是总是长输入、总是某一类、总是同一个缺失的字段？
5. 形成一个假设，做一处改动
“模型添加了说明，因为提示词没有说只返回 JSON。”做这一处改动，不要动别的。
6. 重新运行整个测试集
检查失败是否已修复，同样重要的是，检查之前通过的是否现在失败了。修好一个情形却破坏了另外两个，就是回归。
7. 保留或回退，然后重复
记录你改了什么、为什么改。版本管理参阅提示词管理。
通常有效的精修手法
| 症状 | 精修 |
|---|---|
| 输出篇幅不一 | 把表示大小的词换成数字 |
| 输出形态不一 | 添加明确的格式或 schema |
| 忽略某条规则 | 把它从段落移到列表里；消除冲突 |
| 过于泛泛 | 添加受众和领域背景 |
| 在边缘情形下出错 | 为该情形添加规则或示例 |
| 编造事实 | 提供来源，并要求缺失时写“未说明” |
| 啰嗦 | 给出字数上限，并说明可省略什么 |
通常无效的精修手法
- 给每一行都加强调（大写、“非常重要”）。
- 在多个地方重复同一条指令。
- 每遇到一个失败就追加一条特殊情形规则，却不检查冲突。
- 改动并非原因所在的措辞。
针对 token 优化
当质量可以接受后，在不改变行为的前提下降低成本：
- 删除问候语、客套话和冗词。
- 删除重复和近似重复的句子。
- 砍掉对测试集中任何答案都没有影响的上下文。
- 减少示例数量并重新测试。
- 把提示词中稳定的部分放在前面，以便服务商的缓存生效。
步骤 1 和 2 是机械的，可以放心地自动化。PromptFlowEngine 提示词优化器会完成它们，然后验证原有的每个句子、要求和受保护的片段是否仍然存在，因此更短的提示词所要求的，与更长的完全一致。详情参阅 token 优化。
自动化优化
有些工具会自动搜索更好的提示词：让模型提出变体，并在你的测试集上打分。它们能找到人容易错过的改进。它们要发挥作用需要三样东西：好的测试集、可靠的打分函数，以及对胜出提示词的审查，因为优化器会利用指标的任何弱点。
让聊天模型“改进这个提示词”时也要有类似的警惕。它会产出读起来更好的东西，也可能丢掉某条约束或添加某个假设。请把结果与原文做差异比较，并确认每条要求都还在。
何时停止
当提示词在测试集上达到目标，且进一步的改动只让结果在噪声范围内波动时，就停下来。过了这一点，更多的提升将来自更好的上下文、不同的技巧（如提示词链），或者换一个模型。
基于规则的分数能告诉你什么，不能告诉你什么
静态的质量分数，例如来自提示词评估的分数，衡量的是提示词本身的写法：清晰度、完整性、一致性和安全性。它快速且可复现，适用于每一次编辑和每一次提交。它并不衡量模型对该提示词的实际表现。用它来保持提示词的健全，用测试集来确认输出。二者都在提示词测试与评估中介绍。