核心要点

  • 先看 badcase 找失败模式:是指令不清、格式乱、还是缺背景/示例,对症下药

  • 针对性改:明确指令、加 few-shot 示例、规定输出格式、分步 CoT、加约束边界、拆任务

  • 一次只改一处并对照评测,否则不知道是哪个改动起的作用

  • 固定一个评测集每次都跑,防止改好一个又改坏另一个(回退)

标准回答

第一步:看 badcase,找失败模式

不要凭感觉乱改。先把效果差的实际输出收集一批,分析共性:是它没听懂指令、输出格式乱、漏了关键约束、还是缺背景知识?先定位「错在哪类」。

第二步:按失败模式针对性改

指令模糊 → 把要求写明确、给清晰角色和目标;答得没谱 → 加 2–3 个 few-shot 示例示范;格式乱 → 明确规定输出格式(如只输出 JSON);推理类错得多 → 让它分步思考(CoT);越界/跑题 → 加约束和边界(「只根据给定材料回答」);任务太复杂 → 拆成多步分别处理。

第三步:一次只改一处 + 对照评测

每次只动一个地方,在固定评测集上跑前后对比,确认这处改动是涨还是跌。同时改好几处会让你分不清哪个有效、哪个有害。

第四步:固定评测集防回退

维护一个有代表性的样例集(含难例),每轮迭代都全量跑一遍,避免「按下葫芦浮起瓢」。核心是用数据驱动迭代,而不是改一句看一眼就觉得变好了。

常见误区

⚠️ 常见踩坑

凭感觉一次改一大堆,又没有评测集,看一两个例子就以为变好——很可能修了 A 又坏了 B,且无法复现哪次改动真正有效。

追问

追问 1加了 few-shot 示例还是不稳定,怎么办?

检查示例是否覆盖了易错的边界情况、是否和真实输入分布一致;示例别太长太杂;必要时把任务拆小、给更明确的格式约束或改用结构化输出。还不行就考虑 RAG 补背景知识或更强的模型。

追问 2怎么判断一次 Prompt 改动是真的更好?

在固定评测集上跑量化指标(准确率/通过率/人工打分),看整体分而非单条;样例够多再下结论。只看个别例子容易被偶然性误导,必须用数据对照。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。