12. 你是怎么做 Prompt 迭代的？有没有系统化的方法？

简单回答

Prompt 迭代不是"灵感来了改一下试试"，而应该有系统化的流程：收集 bad case → 分析问题类型 → 假设 Prompt 需要怎么改 → 改动后在评测集上验证 → 确认没有回归 → 记录版本和变更原因。核心工具是版本管理和评测集——每个版本的 Prompt 要记录改了什么、为什么改、效果变化如何。

详细解释

为什么 Prompt 迭代需要系统化

Prompt 在大模型应用中扮演的角色远比看上去重要——一个 System Prompt 可能承载了角色定义、行为规范、输出格式、安全约束、few-shot 示例等大量信息。随意修改一句话可能导致意想不到的回归——比如加了一句"请简洁回答"导致原来回答完整的问题变得太简略了。

迭代流程

收集问题。 从用户反馈、bad case 日志、人工抽检中收集"Prompt 导致的问题"。这些问题可能是：回答风格不对（太啰嗦或太简略）、没有遵循格式要求（该用表格的用了段落）、没有说"不知道"而是编造了答案、幻觉率偏高等。

分类和优先级。 把问题分类——哪些是 Prompt 能解决的、哪些是模型能力问题、哪些是检索问题。只有确定是 Prompt 可以解决的才动 Prompt。按问题的出现频率和严重程度排优先级。

设计修改方案。 基于问题分析设计 Prompt 的修改。比如幻觉率高 → 加强指令"如果参考资料中没有相关信息请明确说明无法回答"。回答太长 → 加字数或句数限制"请用 3~5 句话回答"。格式不对 → 加格式示例。

在评测集上验证。 改完后在评测集上跑，对比修改前后的指标变化。重点关注两个维度：目标问题是否改善了（幻觉率下降了吗）、其他方面有没有回归（之前回答正确的 case 现在还对吗）。

版本记录。 每个 Prompt 版本标注版本号、修改内容、修改原因、评测结果。方便后续回溯——如果某个版本出了问题可以快速回滚。

常用的 Prompt 优化技巧

明确的角色定义比泛泛的指令有效——"你是一个企业 HR 知识助手，专门回答公司制度相关的问题"比"你是一个有用的助手"效果好。

否定指令不如正面指令——"请基于参考资料回答"比"不要编造不在参考资料中的信息"效果好。模型对"不要做什么"的遵循度不如"要做什么"。但在关键的安全约束上，两者可以同时用。

Few-shot 示例非常有效——给 1~2 个"好回答"的示例，让模型知道你期望的回答风格和格式。但要注意示例的质量和代表性——差的示例不如不给。

指令的位置有影响——关键指令放在 System Prompt 的开头和结尾，不要埋在中间。

工程化的 Prompt 管理

在生产系统中，Prompt 不应该硬编码在代码里，而应该有独立的 Prompt 管理系统——支持版本控制、A/B 测试、快速切换和回滚。类似于代码的 CI/CD，Prompt 也应该有"CI/CD"——修改 Prompt → 自动跑评测 → 评测通过才上线。

LangSmith、PromptLayer 等工具提供了 Prompt 版本管理和评测的功能。也有很多团队自建简单的 Prompt 管理服务（本质上就是一个版本化的配置中心）。

面试时可以这样答

我做 Prompt 迭代有一套固定的流程。先从 bad case 中收集 Prompt 导致的问题并分类，确认是 Prompt 能解决的才动 Prompt。然后设计修改方案，改完在评测集上跑对比——不只看目标问题是否改善，还要做回归测试确保没打坏其他场景。每个版本记录改了什么、为什么改、效果变化。

技巧方面，明确的角色定义比泛泛的指令有效。正面指令比否定指令效果好——"基于资料回答"比"不要编造"更可靠。1~2 个高质量的 few-shot 示例通常比多写几段指令管用。关键指令放 Prompt 开头和结尾不要放中间。

工程上 Prompt 不应该硬编码在代码里，应该有版本管理和自动评测。修改 Prompt 就像改代码——要有 review、有测试、有回滚机制。

常见追问

1. 你迭代过几个版本的 Prompt？最大的一次改动是什么？
2. Few-shot 示例怎么选？放几个合适？
3. Prompt 长度增加对成本和延迟有什么影响？你怎么平衡？