背景
这个任务来自一个小工具：我需要从一段非结构化的客服对话文本中，抽取出“用户问题”“客服答复”“是否解决”三个字段，并输出为 JSON。最初我觉得这是一个简单的抽取任务，直接把需求写进 Prompt 就让模型跑。
结果在 30 条测试样本上，准确率低得惊人：字段错位、JSON 格式不规范、对“未解决”场景漏判严重。这次复盘就是记录我从这个混乱状态出发，逐步把 Prompt 稳定下来的过程。
第一次尝试的问题
最初的 Prompt 大致长这样：
请从以下对话中抽取用户问题、客服答复和是否解决，并输出 JSON。
这个 Prompt 存在四个明显问题：
- 没有输出格式示例：模型有时输出对象，有时输出数组，有时还附带解释文字。
- 字段定义模糊：“客服答复”到底包含寒暄语还是只保留解决方案？模型判断不一致。
- 缺乏负样本：对于“未解决”的边界场景，模型几乎全靠猜。
- 未做后处理说明：当抽取失败时，没有要求模型返回统一的占位值。
迭代过程
第一轮：固定输出格式
我先用 Markdown 代码块给出了明确的 JSON Schema，并附加了一条指令：“只输出 JSON，不要任何解释。”这一步把格式错误率从 40% 降到了 10%。
第二轮：定义字段规则
我为每个字段写了简短规则，例如“用户问题：只保留用户表达核心诉求的句子；客服答复：只保留给出的解决步骤或建议，去掉问候语。”字段错位问题因此大幅减少。
第三轮：加入 Few-shot 示例
我挑选了 3 条有代表性的样本：一条已解决、一条未解决、一条包含多个问题。把输入和期望输出一起放进 Prompt。准确率提升到 75% 左右。
第四轮：增加 CoT 提示
对于复杂样本，我要求模型先说明判断理由，再输出 JSON。这虽然增加了少量 Token，但让“是否解决”这一类需要推理的字段准确率提升到 90%。
第五轮：容错与校验
最后我在外层加了 JSON 解析校验：如果模型输出无法解析，就记录失败样本并降级返回空对象，避免程序崩溃。同时把失败案例收集起来，作为下一版 Prompt 的优化素材。
最终方案
最终版 Prompt 的结构如下：
- 任务描述：一句话说明要做什么。
- 字段定义：逐条列出字段名、类型、取值规则和示例。
- 输出格式：给出 JSON Schema 和严格格式要求。
- Few-shot 示例：包含 2 到 3 条覆盖主要场景的示例。
- 推理要求：对复杂判断要求先给出理由。
- 失败处理：明确无法抽取时返回什么。
同时，我把 Prompt 版本化管理，每次改动只在测试集上验证后再合并到主分支。
效果对比
| 版本 | 格式正确率 | 字段准确率 | 备注 |
|---|---|---|---|
| V1 初版 | 60% | 45% | 无格式约束 |
| V2 固定格式 | 90% | 55% | 字段仍模糊 |
| V3 字段规则 | 93% | 72% | 加入规则描述 |
| V4 Few-shot | 95% | 85% | 引入示例 |
| V5 最终版 | 98% | 92% | +CoT + 校验 |
结论
Prompt 优化不是一次性的“写得更漂亮”，而是一个可验证、可回滚的迭代过程。通过固定输出格式、明确字段规则、引入示例、增加推理提示和外层校验，我把一个原本不可靠的任务变成了可上线使用的组件。
可复用的经验
- Prompt 先定输出格式，再优化内容质量，格式稳定是后续改进的前提。
- 字段必须给出类型、规则和边界示例，避免模型自由发挥。
- Few-shot 示例要覆盖真实场景中的困难案例，而不是只挑简单样本。
- 对需要判断的字段，加入 CoT 提示可以显著提升准确率。
- 外层一定要做解析校验和失败降级，不能让模型输出直接决定程序行为。
- Prompt 也需要版本管理和测试集回归，像代码一样迭代。