prompt-versioning

提示词版本管理

提示词就是代码。它们应像软件一样经过版本管理、测试、审查和部署。把提示词当作任何人都能随意编辑的文本，会导致质量退化、行为不一致，还会让调试变得异常棘手。

为什么要对提示词进行版本管理

• 责任追溯：了解谁在何时更改了什么
• 回滚：更改导致问题时，恢复到之前的版本
• 测试：比较不同版本的表现
• 协作：多人可以同时处理提示词，而不会互相覆盖
• 审计记录：了解提示词如何演变，以及演变的原因

版本管理实践

• 源代码管理：将提示词存储在版本控制系统（Git 等）中，而不是应用配置中
• 有意义的提交：每次更改都应说明改了什么以及为什么改
• 更改类别：将更改归类为错误修复、改进、新功能或实验
• 审查流程：提示词更改应在部署前经过审查，就像代码审查一样
• 语义化版本控制：重大更改（行为转变）、次要更改（新增能力）、补丁更改（错误修复）

测试提示词更改

部署提示词更改前：

• 回归测试：使用新的版本运行黄金测试集。是否有任何方面变差？
• 定向测试：测试此次更改旨在改进的特定场景
• 边界情况测试：测试与此次更改相关的边界情况
• A/B 测试：对于重大更改，在生产环境中同时运行两个版本并进行比较
• 用户测试：对于重大的角色设定或行为更改，与真实用户进行测试

提示词更改管理

• 预发布环境：先在非生产环境中测试提示词更改
• 逐步发布：先向一定比例的用户部署，进行监控，再扩大范围
• 功能开关：无需部署即可启用或停用提示词功能
• 监控：任何提示词更改后，都要密切关注质量指标
• 回滚计划：始终明确如何在更改导致问题时进行回滚

常见的版本管理错误

• 未跟踪更改：在生产环境中编辑提示词，却没有记录更改
• 未经测试的更改：未针对已知场景进行测试就部署更改
• 大爆炸式更改：一次更改太多内容，导致无法判断哪些内容带来了帮助或造成了损害
• 丢失上下文：不了解先前版本为何如此编写，就更改提示词

设计产物

• 提示词仓库结构
• 更改审查清单
• 按更改类型划分的测试规程
• 部署和回滚流程
• 提示词更改请求模板