提示词优化

把"感觉不对就改两句"变成有依据的诊断→改进→验证循环。

使用步骤

1. 诊断现状（先找病根，别急着改）

用一批固定的测试输入跑现有 prompt，记录当前表现：

• 哪里出错：理解偏、格式不符、信息遗漏、编造/幻觉、过度冗长？
• 是"指令不清"还是"缺少示例"还是"输入没隔离"？
• 设一个基线（当前的准确/通过率），作为对比基准。

2. 从最常见的改进点依次下手（一次只改一个）

• 加角色 / 明确边界：用专业角色的定位限定行为。
• 加约束：明确禁止项（不要解释、不要问多余问题、不确定就写"不确定"）。
• 加结构：用分节标题把"任务 / 输入 / 约束 / 格式"分开。
• 加示例：针对出错最多的那类情况补 few-shot。
• 拆任务：复杂任务拆成子步骤逐段产出。
• 降幻觉：要求"仅基于给定资料回答，否则说明未找到"。

3. 改写为干净版本

• 用词精炼，避免冗余废话稀释信号。
• 关键指令置前，减少被长上下文稀释的概率。
• 把"不要"改成清晰的正向指令更好。
• 保持 prompt 短而足够：减 token 成本、提高稳定。

4. 做 A/B 测试

• 用同一批测试集跑"旧版 vs 新版"，量化对比。
• 比较指标：准确率、格式合规、长度、通过率；顺带比较 token 消耗。
• 只保留真正变好的改动；保留可复现的版本与变更记录。

5. 固化与回归

• 把有效版本存下来（带版本号/日期/用途）。
• 版本化提示词，必要时纳入 git，便于回退。

输出模板（记录一次优化）

版本号 / 日期：
目标与应用场景：
基线表现（旧版）：
诊断到的问题：
所改项（角色/约束/结构/示例/拆分）：
新版表现（A/B 对比）：
是否采纳：是 / 否（原因）

参考关联

• 基础写法与模板见 prompt-engineering 技能。
• 需要系统评估输出质量见 llm-evaluation 技能。