06. Prompt 迭代应该怎么系统化？版本管理怎么做？
整理 Prompt 系统化迭代流程、评测集建设、版本管理与常见反模式。
简单回答
Prompt 迭代最常见的问题是"凭感觉改"——改了之后感觉更好了，但没有量化验证，也没有记录改了什么、为什么改、效果如何。系统化的 Prompt 迭代需要：有评测集（能快速验证改动效果）、有版本记录（每次改动都有记录，方便回滚）、有对比分析（新旧版本的差异对比）、以及有结构化的迭代流程（先分析失败案例，再假设原因，再改 Prompt，再验证）。规模大的系统还需要 Prompt 管理平台来支持多人协作和多环境部署。
详细解答
为什么 Prompt 迭代需要系统化
Prompt 工程在早期很容易陷入"凭直觉调"的状态——看到一个失败 case，想当然地加一句说明，感觉变好了就发布。但这种方式有几个明显问题：
修复了 A 可能破坏了 B——Prompt 的每一个修改都可能影响其他 case 的表现，不做全面评测就无法发现副作用；没有记录意味着无法回滚——一个月后发现性能下降，但不知道是哪次改动导致的；多人协作时会相互覆盖——两个工程师同时改 Prompt，没有版本管理就是灾难。
真正的 Prompt Engineering 需要像代码开发一样对待：有测试、有版本控制、有代码审查流程。
评测集是迭代的基础
没有评测集就没有系统化迭代。评测集的构建：
从生产日志中选取代表性 case，覆盖各类常见 query；专门选取模型当前容易犯错的"难 case"；每次新发现一类错误，就把这类错误的代表性 case 加入评测集（Regression Test 思路）。
评测集的规模要能快速跑完——作为迭代用的"快速验证集"，几百条在几分钟内跑完是合理的，超过几千条就会影响迭代速度。
每次 Prompt 改动，在提交前必须跑评测集对比，报告各指标的变化：哪些 case 变好了、哪些变差了，整体提升还是下降。只有明确的正向结果才能发布。
结构化的迭代流程
一个可操作的 Prompt 迭代流程：
步骤一：收集和分析失败 case。定期（比如每周）从生产日志或人工评测里收集模型表现不好的 case，按错误类型分类（格式错误、事实错误、理解偏差、过度拒绝等）。
步骤二：找根因和提假设。对每类错误，分析是 Prompt 问题（描述不清楚、缺少边界情况处理）还是模型能力问题（模型在这类任务上天花板不够），针对 Prompt 问题提出修改假设。
步骤三：在隔离环境里测试。把假设的修改在测试环境里跑，不要直接改生产 Prompt。对修改前后的 Prompt 在评测集上对比，特别关注：目标 case 变好了多少，其他 case 有没有副作用。
步骤四：小流量验证。对于有明显效果的修改，先在小比例流量上灰度发布（比如 5%~10%），观察线上指标（用户满意度、拒绝率、错误率）的变化。
步骤五：全量发布和记录。确认效果后全量发布，记录本次改动的目的、改动内容、评测结果，以及对未来可能有影响的注意事项。
版本管理方案
最轻量的方案：把 Prompt 存在 Git 仓库里，和代码一起做版本管理。每次改动提 PR，有 Code Review，commit message 记录改动原因。简单、成本低，但没有运行时的动态切换能力。
配置中心方案：把 Prompt 存在配置中心（如 Apollo、Nacos）或专用的 Prompt 管理工具（Langfuse、Promptflow、PromptLayer 等），支持：
- 运行时热更新（不重启服务就能切换 Prompt）
- A/B Test（同时运行两个版本，按比例分流）
- 版本历史和回滚（一键切回上一个版本）
- 多环境管理（开发/测试/生产各自独立的 Prompt 版本）
Prompt 管理平台（规模大时）：专门的 Prompt 管理工具如 LangSmith、Langfuse 还提供了调用链路追踪（每次请求用了哪个 Prompt 版本、输入输出是什么）、性能监控（不同版本的响应时间和成本），方便事后分析和问题定位。
常见反模式
Prompt 膨胀：随着时间推移，每次修复一个问题就加一句说明，Prompt 越来越长，最终变成难以维护的"规则大杂烩"。定期做 Prompt 审查，删去冗余和矛盾的部分，保持简洁。
Only Fix the Symptom：某个 case 失败了，只加了针对这个 case 的特殊处理，而没有解决背后的根本原因。结果 Prompt 里充满了"如果用户说了 X，那么……"这类特殊规则，脆弱且难以维护。
测试集固化：评测集如果很久不更新，会逐渐变成"被优化的测试集"——Prompt 迭代方向朝着通过测试集优化，但不代表真实效果提升。
面试时可以这样答
Prompt 迭代最大的问题是"凭感觉改"，改了感觉好了就发布，但没有量化验证，也没有记录。系统化的核心是三件事：评测集、版本管理、结构化流程。
评测集是基础，没有它就没办法客观判断改动效果。要从生产日志抽代表性 case，加上已知的失败 case，每次改动前后跑一下，看哪些变好哪些变差。规模控制在几百条，几分钟能跑完，不然迭代速度会被拖垮。
版本管理：轻量的可以直接用 Git 管 Prompt，和代码一起走 PR 流程；规模大的用 Langfuse、LangSmith 这类工具，支持运行时切换、A/B Test、一键回滚，多人协作不混乱。
迭代流程要形成习惯：收集失败 case → 分析根因 → 提假设 → 测试环境验证 → 小流量灰度 → 全量发布记录。最常见的反模式是 Prompt 越来越长越来越难维护，要定期审查清理冗余。
常见追问
- Prompt 的 A/B Test 和模型的 A/B Test，在实现上有什么区别？
- 如果发现一个 Prompt 修改在评测集上提升了 5%，但线上 A/B Test 效果不显著，什么原因？
- Prompt 和代码耦合严重（Prompt 里硬编码了很多业务逻辑），有什么重构思路？