提示词工程 编辑复核
提示词版本变更记录
记录提示词每次改动的原因、影响、测试结果和回滚方式，让模板可以长期维护。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名提示词版本管理员。请把一次提示词改动写成可追溯的版本记录，区分意图、实际变化、测试证据和未验证风险。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 版本、日期、作者和变更原因
2. 具体改动：角色、约束、变量或输出格式
3. 受影响用户、任务和兼容性
4. 回归测试、失败样例和待观察指标
5. 回滚版本、触发条件和后续计划
输入变量：
- 旧版本（{{before}}）：提供旧提示词和版本号。
- 新版本（{{after}}）：提供新提示词和版本号。
- 改动原因（{{reason}}）：说明真实失败样例或需求。
- 测试结果（{{tests}}）：提供回归样本和结果摘要。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 变更记录绑定失败样例和测试结果，不只写“优化效果更好”。
- 生产模板保留可部署的旧版本。
WHEN IT FITS
适用判断
适合这些情况
- 提示词会持续迭代，需要记录改了什么。
- 出问题时要能回溯是哪次改动引入的。
- 多人协作，需要让他人知道版本差异。
换个做法更好
- 提示词在版本控制里：diff 已经记录了改动。
- 只改过一次：不需要变更记录。
- 你要的是优化建议：用《提示词优化器》。
FAILURE MODES
常见翻车与修正
- 变更记录只写「优化了提示词」，回溯时毫无帮助。
要求每条记录写清改了哪部分、为什么改、预期影响什么，能对应到具体位置。
- 记录里没写这次改动的验证情况。
要求每个版本标注在哪些用例上验证过、结果如何，未验证的明确标出。
- 破坏性改动没有标注，下游调用方毫无预警地失效。
要求单独标出改变输出格式或行为的改动，并说明下游需要做什么调整。
ACCEPTANCE
怎么判断输出合格
- 每条记录写清改了什么、为什么、影响什么。
- 标注了验证情况，未验证的有说明。
- 破坏性改动单独标出，附下游调整说明。
- 版本之间可以看出演进脉络。
SAFETY BOUNDARY
使用边界
- 变更记录里不要写入密钥和内部系统细节，提示词库常与代码一起分发。
- 破坏性变更必须显著标注，下游调用方看不到警告就会在升级后静默出错。